Das ist der springende Punkt… Der Ottonormal–Mapper sieht aber eben zuerst das Schild! …er denkt sich: Schild ist relevant, aber was ist denn da erfasst… Dann kommen eben die drei ???
Darum hier meine Meinung: erfassen, was ist (Vorrang Beschilderung, + note/ description → Zeitnahe Korrektur der Beschilderung → Korrektur OSM…
Das ist auch die Krux an solchen Importen. Besser wäre es gewesen:
Bestand lassen
fehlerhaftes (ob Lage und/oder Inhalt) belassen und nur entsprechend kommentieren
ggf. den Bestand erst mal nur Lage korrigieren
nur neues (nach Ankündigung!) importieren
sich zeitnah um Korrekturen der Beschilderung kümmern (z.B. Wasserversorger)
erst wenn Beschilderung korrigiert ist: jetzt restliche OSM-Daten korrigieren
So sehe ich das. …und wie geschrieben: eine korrekte Hydrantenbeschilderung sehe ich auch als gute, vorbeugende Brandbekämpfung. Im Notfall muß man sich auf solche Beschilderung verlassen können. Anderenfalls kann sein, daß man verlassen ist.
Genau, und dann kommt der nächste Otto-Normalmapper da vorbei, sieht das Schild und korrigiert den Wert, dann kommt der Experte usw.
In OSM ist richtig, was OTG vorhanden ist. Nicht nur bei Hydrantenschildern, auch bei allem anderen. Wenn an meinem Haus die Hausnummer 5 dran steht, habe ich in OSM die Hausnummer 5, da kann in der Datenbank der Stadt noch so schön drin stehen, dass ich die 7 hätte. Die Abweichung kann man in OSM als note=Hat in der städtischen DB die Hausnummer 7, aber addr:housenumber ist 5.
Wenn jemand diesen Thread findet und einen Zusammenhang mit dem Standrohr herstellt - zumindest habe ich es so interpretiert - fehlt da jetzt notwendiger Hintergrund.
das ist allerdings nicht so ohne weiteres maschinenlesbar, wenn jemand die städtische DB mit OSM abgleichen will, dann ist diese Art der Abbildung wenig hilfreich. Eine Formalisierung wie man solche Abweichungen dokumentieren will, hätte durchaus Vorteile.
Dem stimme ich zu.
Ein fire_hydrant:diameter:plate/real oder wie auch immer, also per Namensraum, wäre dabei auswertefreundlicher als ein neues Tag a la fire_hydrant:diameter_real.
Ob und welches dieser Werte dann in einem fire_hydrant:diameter priorisiert landen, wäre für mich zweitrangig.
Dieser Ansatz könnte vielleicht auch manch andere “OTG-Streitpunkte” lösen.
BTW: Das ist inzwischen schon ein eigenes Thema abweichend von “Hochladen und Löschen”.
Du verstehst das falsch. Das OTG-Prinzip in OSM dient gerade dazu Meinungsverschiedenheiten zu lösen. Sind sich zwei uneinig, geht man vor Ort und nimmt das in die OSM-Datenbank auf, was man vor Ort feststellen kann.
Das geht natürlich auch mit einer Schaufel oder einem Bagger. ;-) Weil auch ein Tag wie fire_hydrant:diameter:real muss vor Ort verifizierbar sein.
Im Prinzip fast immer ok.
Wenn der Eintrag vor Ort aber definitiv falsch ist, hätte ich gerne einen gut auswertbaren Hinweis darauf, dass ein anderer Wert richtig ist. Also in der Art:
key:otg=falscher Wert & key:real=richtiger Wert.
Das kommt halt nicht nur auf Hydrantenschildern vor, sondern auch bei Wegweisern (falsche Namen, falsche Richtung, falsche Entfernung) oder bei Adressen auf Webseiten usw.
Das nicht, aber wenn sie in OSM übernommen wurden. Die Website ist da OTG in übertragenem Sinn (überprüfbar).
Hatte ich mal, als ein Hotel bei der Adresse im Web lieber in Titisee als in Hinterzarten sein wollte. Die Straße (und alle anderen in der Straße) gehörten aber postalisch zu Hinterzarten. Die Auswirkung ist marginal: Der Postbote weiß idR schon Bescheid, aber falsch ist falsch .
Der Punkt ist doch aber viel mehr, woher weiß man welcher Wert richtig ist? Wenn du beim Beispiel der Hausnummer bleibst, wird die Stadt sagen: Ganz klar, mein Wert ist richtig. Der Bewohner wird sagen: Seit 20 Jahren bekomme ich meine Post an meine Adresse, Besucher kommen zur richtigen Tür, mein Wert ist richtig. Und nun?
OSM hat sich auf die Fahne geschrieben, dass der Wert den man OTG sehen kann der richtige ist. Der Mapper geht zu dem Haus hin, sieht eine “5” und das ist dann für OSM die Hausnummer. Es steht aber natürlich jedem frei an dem Haus ein ref:Musterstadt_GIS=M12345 zu taggen und dann über diese Referenz die Hausnummer der Stadt zu ermitteln.
Genauso bei irgendwelchen Rohrdurchmessern. In OSM gehört was man vor Ort sehen kann. Wenn man der Ansicht ist, diese Info sei Unfug kann man eine Referenz auf eine Wasserleitungs-DB setzen und dann daraus die Werte sich ziehen.
Wie schon oft geschrieben ist der Leitungsdurchmesser für die Feuerwehr interessant. Sie liest den Wert dann auch vom Schild ab. Was machen wir in OSM denn bei Überflurhydranten? Da ist der Wert auch interessant, steht aber leider nirgendwo auf einem Schild…Würdet ihr dann benachbarte Schilder als “Grundlage” heranziehen oder den Leitungsdurchmesser nicht angeben?
Dan trage ich keinen Wert ein und mahne bei der Kommune das fehlende Schild an. Auch ein Überflurhydrant braucht ein Schild von dem der Feuerwehrmann den Leitungsdurchmesser ablesen kann.
Grundsätzlich sollte nichts anderes in unserer Datenbank stehen als das, was auf dem Schild steht, denn genau das ist der Durchmesser der Leutung.
Es mag wie immer begründete Ausnahmefälle geben, die sind dann aber mindestens in einer note zu beschreiben.
Bei Überflurhydranten ist der Rohrdurchmesser meistens direkt auf dem Hydranten aufgeprägt, z.B. DN 80 = 80er Leitung. Außerdem steht noch eine zweite Angabe z.B. PN 10 daneben, was das bedeutet habe ich noch nicht rausgefunden.
.