Doch, das tut sie!
Wenn man eine konkrete Adresse sucht, dann will man in der Trefferliste nicht den Parkplatz daneben finden, von dem irgendjemand meint, dass er diese Adresse haben sollte, weil irgendwo daneben ein echtes Objekt mit dieser Adresse existiert. Oder er eine eigene Nummer interpoliert, die vor Ort naturgemäß nicht auffindbar ist.
Wer aufräumen will: addr:* tags on non-addressable places (Bayern und Tschechien habe ich im Griff) 
Glaubst Du wirklich, daß Mitarbeiter/Techniker/Wartungspersonal etc. von Trafostationen auf die Daten (darunter Straßennamen) von OSM angewiesen sind, um ihren Einsatzort zu finden? Nee, wa …! Sag jetzt bitte nicht ja 
Ansonsten stört es allerdings auch nicht sonderlich (z.B. zu Orientierungszwecken).
power=substation Aachen Lütticher Straße 288
Sehe ich auch so.
mit Adressen haben wir grundsätzlich ein Problem, weil wir die Grundstücke, auf die sich die Adressen in Deutschland beziehen, nicht mappen, außer sie sind “POIs”, es gibt daher für alle diese Adressen, kein wirklich geeignetes Objekt.
Hilfsweise mappen wir die Adressen darum auf Dingen wie Gebäuden. Da es sowieso eine Annäherung ist, würde ich die Adressen eher nicht auf jedem Kieselstein ergänzen, aber es ist auch nicht “verboten”. Je detaillierter gemappt ist, um so eher würde mir ein umschließendes Polygon um den Geltungsbereich der Adresse ausreichen, weil die Karte in der Regel stabiler ist wenn mehr gemappt ist. Wenn dagegen alles noch ein bisschen grob ist, würde ich durch survey erfasste Adressen (z.B. von Läden oder Restaurants, Museen etc.) auch dann auf den (als Punkt erfassten) POIs anbringen, wenn sie schon auf einem umschließenden building sitzt, weil ich die Arbeit der Erfassens schützen wollen würde vor versehentlichem Verschieben.
Wie bereits gesagt, um Dingen wie Parkplätzen etc. Adressangaben zuzuteilen, sollte man statt dem addr:-Schema das object:Schema nutzen:
@Niederpruem aber auf jeden Fall ein dickes danke, dass du dich hier beteiligst.
Ich denke, es ist immer wichtig und sinnvoll, wenn auch andere Mapper sich bei einem Thema einbringen können und ihre Sichtweise darlegen können. Das ist hiermit erfolgt.
(Das Wieder-Hochholen des Threads beruhte auf folgender Changesetdiskussion:
Changeset: 121016792 | OpenStreetMap )
Wie bereits gesagt, um Dingen wie Parkplätzen etc. Adressangaben zuzuteilen, sollte man statt dem addr:-Schema das object:Schema nutzen:
sieht aus wie „is_in_2.0“, was im übrigen ein schönerer Schlüssel gewesen wäre. Viel Spaß beim reverse geocoden…
…wenn man hier aber auf die allgemeine Verbreitung schaut, komme ich zu mindestens dahin, daß es nett ist das zu erfassen, wirklich durchgesetzt hat es sich hingegen nicht und wird real für das Routing nicht gebraucht und nicht verarbeitet.
Sven
Ja…
ich weiß auch nicht. Nutze das Schema selbst nur ab und zu und dass es für das Routing nicht gebraucht wird, dem stimme ich zu. Es soll allerdings eine Alternative zum addr:-Schema sein, ein nutzbarer Vorschlag um denjenigen ein Angebot machen zu können, die unbedingt “Adressen” bspw. an Parkplätzen haben wollen. Zu dieser “Fraktion” gehöre ich nicht und halte das auch für nicht erforderlich.
Es soll allerdings halt ermöglichen, das addr:-Schema zu umgehen, da wir uns relativ einig darüber sind, dass das addr:-Schema nur für echte Adressen verwendet werden soll.
Was ich by the way iD-Nutzern auch immer wieder mal erklären muss…
Ich verstehe gar nicht so ganz, weswegen die eigentlich an Parkplätzen immer noch dieses Adressfeld im Preset haben. Ich meine, bei Parkhäusern ist es relativ logisch, aber bei Freiflächenparkplätzen? Sollte da vlt. mal ein Ticket auf GitHub zu aufmachen, ob man da irgendwie eine Anpassung vornehmen könnte.
Also wenn ich mit amenity=parking einen neuen anlege, kommt da kein Preset für Adressen.
Ja, es ist unter den hinzufügbaren Feldern…
Danke noch für’s Wiederhochladen dieses Threads! Wie ich bei einem kurzen Blick in unsere Daten sehe, ist er leider immer noch aktuell: es gibt immer noch Parkbänke etc. mit Postanschrift.
Ja, aber das muss der Mapper aktiv hinzufügen. Das kann man m. E. mit jedem Editor.
Eben, und das object:-Schema ist in Erfassung und (pot. individueller) Auswertung genauso mächtig, wie das addr:-Schema, insofern sehe ich keinen Grund diese Alternative abzuwerten.
sehe ich keinen Grund diese Alternative abzuwerten.
ich schon. Wenn es keine echten Adressen sind, was ist es dann? Echte Adressen in der Nähe? Beschreibungen der Lage?
z.B. verwende ich ein “alternatives addr” für Baumkataster, bzw. für eine menschenlesbare Lage z.B. von als Naturdenkmal ausgewiesenen Bäumen - Gemeinde, Ortsteil und Lagebeschreibung als Freitext (analog addr:full=*).
z.B. verwende ich ein “alternatives addr” für Baumkataster, bzw. für eine menschenlesbare Lage z.B. von als Naturdenkmal ausgewiesenen Bäumen - Gemeinde, Ortsteil und Lagebeschreibung als Freitext (analog addr:full=*).
das Baumkataster würde m.E. einen spezifischen tag verdienen, die Lagebeschreibung sähe ich in description, aber dafür kann man natürlich auch einen eigenen tag verwenden, das stimmt schon. Mein Ansatz ist da meistens eher, zu versuchen die Sachen auf die sich die Lagebeschreibung beziehen würde, auch zu mappen
Grds. hat man dieses Problem ja auch, wenn ein Mapper bspw. addr:-Tags an einen Parkplatz pappt (sehr beliebt). Das dort erfasste Adresse ist dann (für den Parkplatz gesehen) auch keine echte Adresse, sondern z. B.
Zugegeben definiert das object:-Schema nicht, was genau man da jetzt reinschreiben soll. Das ist richtig, dass das so’n bisschen jedem irgendwie selbst überlassen bleibt.
wieso? Ein Parkplatz wird sich doch auf einem Grundstück befinden, und das wird eine Nummer haben. Vielleicht nicht immer, aber den Fall gibt es sicher häufig.
Wenn ein Objekt keine Adresse hat, würde ich auch keine mappen, weder eine nahegelegene, noch eine ausgedachte. Und auch wenn es eine “hat”, würde ich die nicht immer mappen, z.B. hat jeder Baum im Garten eines Hauses normalerweise auch die gleiche Adresse wie das Haus (sofern sich die Adresse auf das Grundstück bezieht). Bäume mit Adressen haben wir aber praktisch keine.
