Könnte Wall·E mal Dezimaltrenner korrigieren?

Hallo Oli-Wan, hallo restliche Interessierte,

in der OSM-DB schlummern in Deutschland noch viele Leichen im Keller, nämlich Hektometertafeln von Eisenbahnen, die ein Komma als Dezimaltrenner haben. Innerhalb der Eisenbahnmapper-Community besteht die Einigkeit, dass diese Hektometertafeln von Kommata auf Punkte als Dezimaltrenner umgetaggt gehören. Zu finden sind solche Tafeln vor allem noch in Mitteldeutschland. Getaggt sind sie mit:

railway=milestone
railway:position=
railway:position:exact =

Auch manch anderes Eisenbahninfrastrukturobjekt hat ein railway:position- oder railway:position:exact-Tag. Das sind meistens Bahnübergänge.

Hinweis: Wenn Strecken verlegt werden, entstehen in der Kilometrierung Lücken oder Sprünge. Lücken werden bei der Deutschen Bahn meistens durch ±Hektometer “geflickt”. So gibt es z.B. zwischen Petersroda und Delitzsch unter Bahnhof zwischen km 57,9 und 58,0 die Tafeln 57.9+1 bis 57.9+14. Dennoch sollte in Deutschland ein simples Ersetzen von Komma durch Punkt genügen.

Und wenn der Bot schon Dezimaltrenner korrigiert, könnte er dasselbe auch mit maxheight, height, ele, ele:*, maxwidth, width, maxweight usw. tun. JOSM weißt zwar darauf hin, wenn man ein kommagetrenntes Objekt anfasst, aber nicht jedes falsch getaggte Objekt wird oft bearbeitet.

@Oli-Wan: Könnte dein Bot die mal korrigieren?
@Community: Gibt es dagegen Einwände.

Viele Grüße

Michael

Nein.

Sven

Vorsicht: Quer über eine Datenbank ist das vollautomatische Vereinheitlichen von Dezimaltrennern technisch nicht möglich, denn je nach Kultur ist z.B. “1,234” auch “1234”, und nicht nur “1.234” (Komma als Tausenderzeichen). Die Thematik klingt zunächst nur trivial, eine Umsetzung wird aber entweder viele Fälle nicht anfassen dürfen oder Fehler produzieren.

Danke für den Hinweis - allerdings “kümmert” sich der Bot von Oli-Wan wohl nur um Deutschland (oder DACH?).

Oder gibt es hier auch so gravierende kulturelle Unterschiede, wenn man mal von den Bayern absieht? :wink:

Zudem ist es (mir) jederzeit möglich, solche Änderungen auf Länderbasis zu machen. Man brauch in der Planet-DB “nur” die Administrativen Grenzen mittels Spatialer Abfragen zu berücksichtigen.

Grüsse aus Hessen
Walter

NACHTRAG: Oder doch die brutale Methode? Nur Punkte sind als Dezimaltrenner erlaubt. Alles andere ist (in OSM) falsch. Erst recht der Punkt als optischer Trenner ohne besondere Funktion.

Ich kenne mich nur bei ele aus, weil ich damit rechnen muss und deshalb oft mit Werten kämpfe, die sich beim besten Willen nicht als Zahl interpretieren lassen… Aber speziell beim Austausch “Komma gegen Punkt” sehe ich keine Probleme.

Punkte als Tausendertrennzeichen können vorkommen, aber ich hab keine gefunden, die zusammen mit Kommas vorkommen (1.234,5 wäre ja noch “interpretierbarer” als 1.234.5) und ohne Komma wäre auch ein Punkt als Tausendertrenner nicht eindeutig (1,234 oder 1.234 ist gleichwertig).

Im Ausland mag das anders sein. Spanien hatte z.B. einen Import von massig Vermessungspunkten der Form “ele=1,234 m.”. Aber um die geht es ja nicht…

Grüße, Max

Warum denn nicht? Nur weil dein Bot das derzeit nicht kann, ist es doch nicht unwichtig. Sind wir ein internationales Projekt oder nicht?
Immer dieser blöde Tellerrand, über den ihr nicht blicken wollt :frowning:

Gruss
walter

Meine Anfrage bezieht sich erstmal nur auf Hektometertafeln in Deutschland. Da kenne ich mich aus und glaube (fast) alle Schikanen zu kennen.

railway:positon sollte nur umgestellt werden, wenn folgender regulärer Ausdruck zutrifft: [-][:digit:][,]{1}[:digit]{1}
railway:positon:exact sollte nur umgestellt werden, wenn folgender regulärer Ausdruck zutrifft: [-][:digit:][,]{1}[:digit]{3}

Bei maxheight, height usw. ist es nicht so einfach (Gefahr von 1000er-Trennern). Hier wäre mal für Deutschland eine Auswertung interessant, die ausgibt, wie oft [-][:digit:][,]{1}[:digit]* und [-][:digit:][.]{1}[:digit]* nicht zutrifft. Wahrscheinlich wird der häufigste Treffer sein, dass am Ende noch ein " m" oder “m” oder " cm" angehängt ist.

Weder ich noch ein Bot von mir interessiert sich überhaupt für Spaniens Höhen. Aber man müsste das vielleicht den Spaniern erklären und ich weiss gerade nicht, was “blöder Tellerrand” auf spanisch heisst.

Wann war der? Dieser Import sollte IMHO revertiert werden, da so ein Tagging schlicht und einfach schlechte fachliche Praxis ist. Wurde der Import überhaupt diskutiert? Ich persönlich wäre bereit, den Revertantrag bei der DWG zu stellen. Ich kann damit leben, wenn mich ein paar spanische Mapper hassen. :slight_smile:

Mir sind nur die vielen Kommas mit Punkten aufgefallen. Dieses Changeset gehört dazu und an den nodes hängt “This is a point from an official geodetic network. Use it as a reference, but do NOT move it”. source=Instituto Geográfico Nacional. Das war im Oktober 2010.

Grüße, Max

Auch die vorherigen Versionen zeigen “,” - reverten würde ich es nicht gleich, vielleicht gibt es auch eine Zustimmungbestätigung?

Auf alle Fälle würde ich die Werte entsprechend dem WIKI korrigieren - dies steht auf allen Sprachseiten (1,234. → 1234) - Was ist mit “m” (Maßeinheit)?

mehr als du denkst, da reine zahlen nicht ausgeblendet werden:


select tags->'maxheight' from planet_osm_roads
 where tags ? 'maxheight'
   and st_contains((select way from planet_osm_polygon where osm_id=-51477),way)
   and tags->'maxheight' !~ '[\-]*[:digit:]*[,]{1}[:digit]*'
   and tags->'maxheight' !~ '[\-]*[:digit:]*[.]{1}[:digit]*'
 limit 10;
 ?column? 
----------
 none
 4
 none
 3
 none
 4
 4
 4
 none
 4
(10 rows)

muttu wohl noch ein wenig anpassen.

Gruss
walter

EDIT: Hab es mal dennoch etwas modifiziert laufen lassen, ohne die Pattern zu ändern:


select tags->'maxheight' "maxheight", count(tags->'maxheight') 
  from planet_osm_roads
 where tags ? 'maxheight'
   and st_contains((select way from planet_osm_polygon where osm_id=-51477),way)
   and tags->'maxheight' !~ '[\-]*[:digit:]*[,]{1}[:digit]*'
   and tags->'maxheight' !~ '[\-]*[:digit:]*[.]{1}[:digit]*'
 group by tags->'maxheight'
 order by count desc,tags->'maxheight';

 maxheight | count 
-----------+-------
 none      |  2118
 4         |   750
 default   |   210
 unsigned  |    58
 3         |    18
 4 m       |     6
 5         |     5
 4m        |     3
 300       |     2
 FIXME     |     2
 120       |     1
 2         |     1
 3m        |     1
 70        |     1
 8         |     1
 keine     |     1
 n         |     1
 no        |     1
 no_sign   |     1
(19 rows)

 height | count 
--------+-------
 4      |    10
 26     |     4
 4 m    |     4
 42     |     3
 0      |     2
 107    |     2
 16     |     2
 18     |     2
 21     |     2
 25     |     2
 35     |     2
 40     |     2
 41     |     2
 52     |     2
 11     |     1
 12     |     1
 19     |     1
 2      |     1
 23     |     1
 24     |     1
 28     |     1
 30     |     1
 32     |     1
 38     |     1
 3m     |     1
 70     |     1
 75     |     1
 85     |     1
(28 rows)

Die sind im Wiki unterschiedlich geregelt: Bei ele muss es Meter ohne Einheit sein, bei maxwidth dürfen Einheiten dabei sein, maxwidth=7’9" oder maxwidth=2.3 m z.B.

Grundsätzlich kann man Meter also weglassen, Füsse (je nach Mapper als “ft” oder ') und Zölle müsste man umrechnen, deshalb würde ich generell die Finger von Einheiten lassen. Das Problem ist übrigens nicht auf Länder mit zölligem System beschränkt, im Umkreis von Flugplätzen tauchen auch auf dem Kontinent in Füssen gemessene Höhen auf.

Hallo miteinander, ich klinke mich mal mit ein paar Tagen Verspätung ein. Zur Ausgangsfrage: Ja, das traue ich meinem Bot zu; ich hätte wohl demnächst auch die nötige Zeit für die Umsetzung, nachdem Wall·E die letzten Monate ziemlich auf Sparflamme gelaufen ist. Und die Änderung als solche erscheint zumindest mir auch sinnvoll.

Ich würde das in zwei Schritten machen. Erst die - klar abgegrenzten - Objekte im Eisenbahnbereich, später ggf. weitere Tags.
In jedem Fall würde ich noch weiteres Feedback abwarten wollen, und mindestens ein heads-up an talk-de wäre geboten (Michael?), zumal es sich ja um eine “völlig neue” Änderung handelt, die nicht nur eine logische Erweiterung bestehender Tasks von Wall·E ist. Bei Ausbleiben von Widerspruch könnte ich mich an die Vorbereitung machen; aber bis zur Fertigstellung werden vermutlich so oder so noch einige Wochen ins Land gehen, da um das reine replace-regexp herum noch Filterung, Ausschlußregeln, Testen und Doku im Wiki nötig sind.
Zum räumlichen Anwendungsbereich: was im deutschen Forum diskutiert und abgesegnet wird, läuft (von meiner Seite aus) nur in Deutschland. (In diesem Fall genügt voraussichtlich auch die losere Definition “nach Geofabrik-Extrakt”, da die Änderung keine als solche länderspezifischen Tags betrifft.) Wenn jemand die Idee später auch in ein anderes Land tragen möchte und sie dort auf Interesse trifft, steht Wall·E aber grundsätzlich auch dafür zur Verfügung.

Das Problem mit Komma als Tausendertrenner kann man vermeiden, wenn man Fälle mit genau 3 Ziffern hinter dem Komma ausschließt. In speziellen Fällen wie den deutschen Eisenbahntags kann der Ausschluss natürlich ggf. entfallen.

Im allgemeinen Fall wäre auch noch zu prüfen, ob das Komma nicht eine Auflistung zweier unabhängiger Zahlen darstellen könnte. Aus diesem Grunde wird man sich auf bekannte Schlüssel beschränken müssen.

Hallo,

ich würde es noch begrüßen wenn maxheight=non auf maxheight=4.1 gesetzt würde.
Begründung:
lt.StVZO §32 darf die höchstzulässige Höhe von 4 Metern nicht überschritten werden.
Regelmäßig wird aber die Höhe von 4.0 Metern noch per Schild gekennzeichnet, deshalb bedeutet eine in Natura nicht vorhandene
Durchfahrtshöhenangabe (maxheight=non) mindestens 4.1 Meter.

BF3-Fahrer dürfen natürlich ihre ermittelten Durchfahrtshöhen gern bei openstreetmap eintragen.

MfG

Senni

-1

Begründung: Die StVZO schreibt fahrzeugseitig eine maximale Höhe des Fahrzeuges vor, Zeichen 265 streckenseitig. Dass ein höheres Fahrzeug nicht zulassungsfähig ist (Sondergenehmigungen ausgenommen) brauchen wir nicht zu taggen. Wer eine Sondergenehmigung hat kann auch Strassen mit ohne Zeichen 265 nutzen, nicht aber welche mit. Ein maxheight!=none würde das jedoch verhindern.

Seit wann bitte darf landwirtschaftlicher Verkehr nicht mehr über 4 Meter hoch sein?

Deshalb auch -1

Baßtölpel

Und nun berücksichtige bitte § 70 StVZO.

Wenn es keine Ausnahmegenehmigung nach § 70 StVZO gibt, darf er das nicht. Seit wann das so ist, weiß ich nicht, dürfte aber schon länger so sein.