Ich habe gerade etwas in meiner Kreisstadt gemapt. Dabei ist mir aufgefallen, dass da im Moment einige Leute Hydranten mit voller Adresse erfassen z.B. http://www.openstreetmap.org/node/2747546823 http://www.openstreetmap.org/node/2739740403 (hier mit addr:housenumber=südlich Kaserne)
Ich finde das als zusätzliche Information ja gut, aber als Adresse passt das irgendwie nicht. Mal ganz abgesehen davon, dass da auf der Standardkarte Zahlen und Texte irgendwo in der Gegend auftauchen. Mir fällt jetzt auch nicht ein, wie man das anders unterbringen könnte. Hat jemand eine Idee?
Kann Theodin nur zustimmen. Addr kann man soweit nutzen, sollte aber die tags addr:housename & addr:housenumber nicht benutzen, da es sonst für das Routing unschön ist.
Ggf als Location wurde ich noch akzeptieren. Alles andere bringt Die Auswerrter fur diesen wichtigen Tagbereich durcheinander und verschlechtert eine Förderung der QA.
Das hat nichts mit dem Routing zu tun, und die übrigen addr:*-Tags sind genauso falsch wie addr:housenumber. Ein Hydrant hat schlichtweg keine Adresse (oder kann man ihm eine Postkarte schicken?), sondern neben seiner Position (meist) eine Referenznummer und/oder in besonderen Fällen einen Namen (nicht: “Hydrant”).
Dem Änderungssatzkommentar zufolge wurden die Objekte mit einer “OpenFireApp 1.0.7” erstellt. Vermutlich (ich habe sie nicht ausprobiert bzw. gefunden) bietet diese mal wieder Felder zum Ausfüllen an und suggeriert (gewollt oder ungewollt), daß alle ausgefüllt werden müssen. In dem Fall läge der Hauptfehler nicht beim Endnutzer, sondern - mal wieder - beim Autor eines Spezialeditors.
Hallo zusammen,
ich bin der “Übertäter”.
Ich kann eurer Argumentation voll folgen. Wir werden die addr:*-Tags auf jeden Fall entfernen.
Der sogenannte Spezialeditor ist eine Testversion von uns (Mitglieder der örtlichen Freiwilligen Feuerwehr) und sehr überlegt programmiert worden (wobei die Gedanken mit dem addr:-Tags komplett falsch waren).
Die Ortsangabe ist aber zwingend notwendig. In der App werden die Hydranten in 1 km Umkreis heruntergeladen und in einer Liste angezeigt. In dieser Liste ist jeder Hydrant mit seiner örtlichen Position (Straße Hausnummer) angegeben. Zusätzlich wird die Hydrantennummer mit angezeigt. Die Hydrantennummer (ref-Tag) ist leider vor Ort nicht immer vorhanden (15% fehlen) Diese Liste lässt sich für ein menschliches Wesen nur so lesen. Ich kann IDs bzw. GSP-Positionen keiner Örtlichkeit ohne Karte zuordnen. Ein neuer Hydrant wird dann mittels GPS in der Liste aufgenommen. Sollte sich in 5 m Umkreis bereits ein Hydrant befinden, wird dieser dem User angezeigt. Die neuen Hydranten werden dann hochgeladen.
Wir haben uns jetzt überlegt, den Tag note zu verwenden. Hier sollen die Angaben Straße; Hausnummer (oder örtliche Beschreibung); PLZ; Ort durch Semikolon getrennt eingetragen werden.
Beispiel: http://www.openstreetmap.org/node/2739740403
Spricht etwas gegen diese Vorgehensweise?
Über eine Antwort freut sich
Matthias
Hallo Sven,
Deine Idee finde ich ausgezeichnet.
Jeder Hydrant würde eine lesbare Ortsbeschreibung (street, housenumber, topographies) erhalten, der Konflikt mit der Adresse wäre gelöst.
Kann man weiterhin addr:postcode und addr:city verwenden? Oder sollten diese Angaben auch fire_hydrant:postcode usw. gemapt werden?
Gruß
Matthias
Ich finde, eine Postadresse sollte mindestens prinzipiell dazu gedacht sein, dass dort Post zugestellt werden kann. Also meine Meinung: Besser konsequent trennen.
Reicht es nicht, wenn man die nächst gelegene Adresse heraussucht?
Es sollte einfach sein, die nächste Strasse und danach die nächste Adresse dieser Strasse zu finden.
Ich weiss nicht genau wie OSM Inspector und andere Tools das im Detail lösen, aber ich fände dies eine bessere Lösung als überall redundant Adressen anzugeben.
Weshalb mir diese Idee mißfällt: Der nächste möchte eintragen, daß ein Briefkasten vor Haus 1 steht, der übernächste nimmt sich analog die Telefonzelle vor Haus 3 vor und Jan den Kackatütenspender vor Haus 5. Konsequenterweise und mit gleichem Recht braucht man dann post_box:housenumber, telephone:housenumber und vending_machine:housenumber. Im Ergebnis haben wir eine Proliferation völlig sinnloser Schlüssel - keines dieser Objekte besitzt tatsächlich eine Hausnummer.
Gibt es im Bereich des Hydrantentaggings bereits einen Freitext-Schlüssel zur Ortsbeschreibung? note halte ich jedenfalls für keine gute Wahl - das Tag ist für Hinweise an andere Mapper gedacht, nicht für “Produktivdaten”.
Ansonsten schließe ich mich mdk an: Das auswertende Programm sollte nach der nächstgelegenen Adresse suchen. Grundsätzlich ist das eine Aufgabe für einen Reverse Geocoder, aber wenn man z.B. von der Overpass API nur Hausnummern in einem kleinen Rechteck um den Hydranten herum herunterlädt, reicht auch eine einfache lineare Suche darin. Wenn vor Ort die entsprechenden Adressen noch fehlen, kann man zumindest die nächstgelegenen ja beim Hydrantenmapping gleich mit erfassen. Dann haben ganz nebenbei sogar noch andere Nutzer etwas davon.
Mußt Du mir nicht erklären. Bei vielen anderen Objekten leitet sich die ref im Allgemeinen nicht von einer nahegelegenen Adresse ab, Briefkästen (in DE, anderswo nicht notwendigerweise) bilden da eine “zufällige” Ausnahme (Trafoboxen je nach Ort eine weitere). Und wenn ein Briefkasten eben abweichend vom gängigen Schema z.B. die ref=AVV Eilendorf Markt nach der nahegelegenen Bushaltestelle hat, “braucht” doch wieder jemand ein Tag wie das angedeutete (oder eben addr:), wenn er die Position relativ zur Bebauung beschreiben will. Nicht, daß ich das für sinnvoll halte (s.o.), aber ich habe schon Bushaltestellen, Toiletten u.v.m. mit addr: gesehen (und oft genug die Adresstags rausgeworfen bzw. sinnvoller umgetaggt).
Wenn man regelmäßiger Pendler ist, wie ich, hat man Zeit über solche Dinge nachzudenken.
Es stimmt, solche Adress-Information ist eine vollständig redundante, unnötige in fehlerbehaftete Information, die man nicht braucht.
Wie würde denn ein möglicher Brandfall seitens des Meldeweges ablaufen??
[Eine kurze Darlegung von jemanden der Feuerwehr würde sicher helfen.]
Mein Gedankenweg wäre:
→ 1. Haus in Straße x Nummer y brennt… Alarm. (=Adressinformation des Hauses mit den Koordinaten)
→ 2. Zeige mir alle Hydranten (z.B.) in 100m Umkreis (Auswertung der erfassten Hydranten in einem definierten Umkreis auch mit definierten Koordinsten).
Der Rest ist doch vergleichbar mit einem Straßenrouting, also navigiere mich auf dem kürzesten Weg nach 2 und zeige mir den kürzesten Weg von 2 nach 1 oder navigiere micht zu 1 und zeige mir den den nahesten Hydranten zu 1.
Alleine dadurch, daß einerseits das Haus (oder eine Adresse) vorhanden ist und andererseits der Hydrant sind alle Dinge gegeben; beides ja als Vektorobjekt mit ihrerseits zugehörigen definierten Koordinaten und Tags. Es sollten alle nötigen Dinge gegeben sein.
Da stimme ich zu. Was aber, wenn kein Objekt mit Adresse in der Nähe liegt, so dass es sich für eine Ortsbeschreibung eignet(z.B. am Ortsrand) ? Da ist die Beschreibung jetzt z.B. sowas wie “Feldweg südlich Kaserne”. Oder bei größeren Gebäuden z.B. “Auf der Nordseite des Gebäudes”. Ich denke ohne die Möglichkeit eines Freitextes kommt man nicht aus.
das sehe ich genauso - aus eigener Erfahrung.
Und daher plädiere ich schlicht für “description”.
Vorhanden, etabliert, Freitext - und reicht für den erforderlichen Zweck vollkommen aus - auch für die Befehlsgabe an den Wassertrupp.
