Haben Motorradparkplätze oder Recyclingcontainer Adressen?

Das Problem liegt drin das per Definition die Adressen in den addr Tags -postalische Adressen- sind, d.h. z.B. auch das addr:city der postalischer Ort ist, sprich man müsste Post dorthin schicken können. Im Schnitt ist das bei einem Motorradparkplatz nicht der Fall :slight_smile:

Dies ist etwas unbefriedigend, denn einerseits ist der postalischer Ort meistens nicht vor Ort beobachtbar und deshalb auch nicht erfassbar (ich rede hier nicht nur von Deutschland), resp. wenn addr:city erfasst wird ist es häufig falsch. Anderseits gibt es doch viele Regionen die allen Gebäuden Hausnummern zuweisen und das passt nicht so richtig ins Schema (da eben Postadressen).

Trotzdem wäre es durchaus sinnvoll diese “Adressen” in irgendeiner einfachen Form kompatibel mit dem addr Tagging zu erheben, da man einerseits so einfacher die Vollständigkeit der Erfassung überprüfen kann und anderseits es durchaus hilfreich für die Navigation etc sein kann wenn man nach solchen “Adressen” suchen kann.

Simon

@kreuzschnabel: das ref-Tag ist möglicherweise bereits durch eine Kennziffer o.ä. belegt.

Ich kenne das Problem nur allzugut und zitiere mich hier mal selbst: “… Warum definiert man ein addr:-Schema, das dann nur für Postanschriften verwendet werden soll/darf[?] und macht sich nicht gleichzeitig Gedanken um Standortangaben allgemein? …”

Das ganze Elend und meine + eine andere Lösung unter

https://wiki.openstreetmap.org/wiki/DE_talk:Tag:natural%3Dtree#Standortangabe_bei_Stadt-B.C3.A4umen

1 Like

Einfach:

ref:street
ref:housenumber

(analog zu addr:street, addr:housenumber)

Das ist sauber, weil ref=* abstrakte Bezeichnungen abbildet, während addr: für Postanschriften gedacht ist.

–ks

Naja, diese “saubere” Lösung wartet aber noch auf ihren großen Durchbruch:
https://taginfo.openstreetmap.org/keys/ref:street
demgegenüber
https://taginfo.openstreetmap.org/keys/object:street

Wow,
ich bin beeindruckt von den vielen Antworten bzw. Replies meiner Frage oben.

Vielen Dank für das Feedback. Mir ist jetzt einiges klarer geworden. Die Richtung, in die die Antworten gehen, scheint eindeutig zu sein. Des Weiteren wurden interessante Lösungsansätze für das “Problem”, z. B. vom User kreuzschnabel, geliefert.
Danke für eure Hilfe!

Das ging bislang keiner sauberen Lösung anders :slight_smile: Es ist auch nicht so, dass ich sie direkt forciere.

–ks

Hallo Leute,
Parkplätze brauchen auf jeden Fall eine Adresse.
Wenn man mit dem Auto zu einem bestimmten Parkplatz fahren will, so muss man eine Adresse ins Navi eingeben. Genauso verhält es sich auch bei Trafostationen, wo Mitarbeiter diese Stationen finden müssen.

Hausnummern markieren lediglich ein Objekt, um sie besser finden zu können. Hauptsächlich markieren Hausnummern zwar Häuser. Aber das muss nicht ausschließlich so sein. Welche Objekte (z.B. Parkplätze, Trafostationen, Spielplätze, Pumpstationen) eine Hausnummer bekommen sollten, darüber kann natürlich diskutiert werden.

Eine Postzustellung ist dabei nicht zwingend nötig. Die Post braucht lediglich eine Hausnummer, um sie einfacher zustellen zu können. Übrigens gibt es auch Länder, wo Post ohne Hausnummern zugestellt werden müssen.

Meine Bitte ist, entspannt euch, wenn eine Adresse eingegeben wird. Sie stört nicht - kann aber sehr hilfreich sein, dieses Objekt zu finden.

Schöne Grüße
Niederpruem

1 Like

Meine Meinung hat sich innerhalb der 7 Jahre nicht geändert. :yum:

Wenn man den Objekten eine Adresse zuteilen will, dann mit object:street / object:housenumber.

4 Likes

https://wiki.openstreetmap.org/wiki/DE:Key:object

Was ich ja auch erstaunlich finde: da wurde vor 7 Jahren ein konkretes Beispiel gezeigt, wo auch noch viel mehr im Argen liegt (Parkplatz hat nicht nur Adresse, sondern geht durch Gebäude und über Fußweg, diverse Lagekorrekturen erforderlich etc) und bislang hats keiner geändert.

Aber schön, dass hier ab und an alte Thread ausgegraben werden …

2 Likes

Ich denke, das ist eine Fehlinterpretation deinerseits. Adressen sind nicht notwendig, um ein Objekt in OSM zu finden und auch nicht, um zu ihm zu navigieren. Wenn eine Anwendung, welche du nutzt, die wiederum auf OSM-Daten basiert, dies erfordert, sollte die Anwendung verbessert werden.

Wir wollen in OSM nur wirklich existierende Adressen haben, und diese auch nur so oft, wie unbedingt notwendig. Meistens ist das einmal.

Insofern geht es nicht um Entspannung, sondern um ein Verständnis für die Daten.

9 Likes

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) :wink:

1 Like

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 :slightly_smiling_face:

Ansonsten stört es allerdings auch nicht sonderlich (z.B. zu Orientierungszwecken).

power=substation Aachen Lütticher Straße 288

Sehe ich auch so.

1 Like

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:

https://wiki.openstreetmap.org/wiki/DE:Key:object

3 Likes

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

1 Like

Wie bereits gesagt, um Dingen wie Parkplätzen etc. Adressangaben zuzuteilen, sollte man statt dem addr:-Schema das object:Schema nutzen:

https://wiki.openstreetmap.org/wiki/DE:Key:object

sieht aus wie „is_in_2.0“, was im übrigen ein schönerer Schlüssel gewesen wäre. Viel Spaß beim reverse geocoden…

1 Like

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

2 Likes

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.