Könnte Wall·E mal Dezimaltrenner korrigieren?

Nakaner wrote:

@Community: Gibt es dagegen Einwände.

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.

Joachim Moskalewski wrote:

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? 😉

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

maxbe wrote:

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....

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 🙁

Gruss
walter

Joachim Moskalewski wrote:

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.

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.

wambacher wrote:

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 🙁

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.

maxbe wrote:

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....

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. 🙂

Nakaner wrote:

Wann war der?

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

Nakaner wrote:

...
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. 🙂

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)?

Nakaner wrote:

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.

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)

geri-oc wrote:

Was ist mit "m" (Maßeinheit)?

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.

Nakaner wrote:

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=<Zahlenwert>
railway:position:exact =<Zahlenwert mit mehr Dezimalen>

...

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.

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

chris66 wrote:

-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.

sennewald63 wrote:

lt.StVZO §32 darf die höchstzulässige Höhe von 4 Metern nicht überschritten werden.

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

Deshalb auch -1

Baßtölpel

sennewald63 wrote:

lt.StVZO §32 darf die höchstzulässige Höhe von 4 Metern nicht überschritten werden.i

Und nun berücksichtige bitte § 70 StVZO.

Basstoelpel wrote:

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

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.

SammysHP wrote:

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.

Als ich den Trecker- und Mopped-Lappen gemacht habe, war dafür keine Ausnahmegenehmigung nötig. Zwei Jahre später bei meinem nächsten Führerschein ('86) auch noch nicht. Bei der Heu- und Strohernte hätte sich damals auch keiner drum gekümmert, vorausgesetzt die Fuhre eckt bis zum Abladen nirgendwo an.

Baßtölpel

Hallo,

ihr beschreibt hier doch Sonderfälle zur zulässigen Höhe eines Fahrzeuges, aber gerade solche Nutzer könnten ihr wissen ja bei uns mappen wenn sie mit maxheight=4.1 nicht hin kommen, deshalb habe ich auch auf die BF3-Fahrer mit verwiesen.

Eine ausgewiesene Durchfahrtshöhe von mehr als 4.0 ist mir bisher bewußt nicht aufgefallen, ich müsste aber die Beschilderung der Rennsteigtunnelkette noch mal ansehen.
Das einzige was mir zu den 4.0 Fahrzeughöhe in Erinnerung war, dass ein LKW-Fahrer aus einem nicht näher zu nennenden Land den Sattelauflieger auf 4.2 Meter gepimpt hatte und im Rennsteigtunnel weil er verkehrsbedingt nicht mehr den Mittelstreifen zwichen die Räder nehmen konnte eine Menge Schilder abgesäbelt hatte und dann an einer Belüftungsanlage hängen geblieben ist.

Die neuen Trekker mit GPS und Navi haben ja auch das Problem, dass die Strommasten auf den Feldern nicht genau erfasst sind. Ich durfte deshalb schon zweimal mit ausrücken.

MfG

Senni