name_suggestion_index (NSI) - DHL Packstation

Hallo,

@ Jo Cassel: Danke für den Hinweis aus der Dokumentation. Der Aufbau des Adressschemas ergibt sehr viel Sinn. Würdest du dann in unserem konkreten Fall als “object” das Wort “vending_machine” oder “vending” einsetzen? Also entweder “vending:postcode=" oder "vending_machine:postcode=”?

Sprechen sich noch mehr von euch gegen den Wikipedia-Link aus?

Hi all, just to give context to the proposal:

Because

  1. parcel lockers are a big thing in Poland
  2. people want them on the map
  3. approval would be the first step to displaying them on openstreetmap-carto

tomczk wrote his first proposal, on which many member of the Polish community voted.

He wanted to address any and all comments, hence the change to amenity=parcel_machine as somebody complained about the tag: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/amenity%3Dparcel_locker#locker_or_lockers_.3F

Now we’re back at amenity=parcel_locker, which seems to be preferred English term…

würde das KISS bei object:[…] belassen, es geht ja nur darum bei Automaten eher besser kein addr:[…] zu verwenden.
Gerade diese Disk, zeigt ja, dass vieles im OSM-Fluss ist, und da macht es keinen Sinn, Spezial-Keys zu verankern die morgen (vielleicht) obsolet sind …

das object braucht gar nicht ersetzt werden, es kann bereits genutzt werden für alles, was nicht Gebäude oder ein Shop/Büro u. ä. ist.

Hallo,
ok, alles klar. Ich bin davon ausgegangen, dass “object” für einen Platzhalter steht. Da hab ich wieder etwas gelernt, danke.

Dann könnte man evtl. das Attribut “object:postcode=*” automatisch vorschlagen lassen, abhängig davon wo sich eine Packstation befindet?

Genaugenommen steht:
addr:* für die Daten einer Zustelladresse und
object:* für die Daten, wo sich ein Objekt im urbanen Raum befindet, also eher im Sinne: vor Haus Nr. , in der Nähe von Haus Nr. …, gegenüber von Haus Nr. …
Klassische Beispiele dafür sind Stolpersteine, Kunstwerke im öffentlichen Raum usw. Das ist praktisch, wenn an sich orientieren oder navigieren will, ohne GeoKoordinaten nutzen zu müssen/können

Bei den Packstationen haben wir glaube eine besondere Situation:
object:* gibt an, wo sich die Packstation befindet, als in der Nähe welcher Adresse, in welcher Straße in welchem Ort.
aber: eine Packstation (zumindest vending=parcel_pickup) hat bzw. ist ja auch eine Zustelladresse. Insoweit ist sind dann auch Angaben wie addr:postcode=* und addr:city=* möglich - wenn man diese korrekt kennt. Die könnte ja auch von der Briefzustelladresse eines in der Nähe liegenden Gebäudes verschieden sein.

ich begrüße den Vorstoß, die widersprüchliche Verwendung von Verkaufsautomatentagging für automatisierte Systeme wo man nichts kaufen kann, zu reparieren. Ähnliches wäre evtl. auch bei den “berühmten” Hundekottütenspendern sinnvoll, wobei da die Lage noch etwas vertrackter ist, weil die Tüten manchmal verkauft und manchmal verschenkt werden.

Bei Packstationen™ würde ich es sachdienlich finden, zusätzlich einen tag für den genauen Typ zu haben, das sind ja nur eine Handvoll, und die unterscheiden sich durchaus. Das muss man evtl. nicht unbedingt international diskutieren, andererseits habe ich in Rom auch schon welche gesehen (nur in Bahnhöfen), d.h. vielleicht betrifft es doch eine größere Community als nur die deutsche.

Das hat dann ja aber nichts mehr mit dem NSI zu tun…

… das würde mich wundern, die Paketautomaten stehen (in D) halt auf vorhandenen erschlossenen Grundstücken (z.B. Rewe-Gelände) mit vorhandener Anschrift.
Daher soll diese beim Versand ausdrücklich nicht verwendet werden, schreibt DHL, stattdessen

  • als Straßenangabe: “Packstation”
  • als (Haus)Nr. Angabe: Nummer der Packstation (unser ref)
    PLZ und Ort sind identisch, aber mischen würde ich oject: mit addr:-Schema besser nicht.

Das habe ich auch nirgendwo geschrieben!

steht das irgendwo “offiziell” dass das immer so ist? solange ich fa nichts definitives gelesen habe, halte ich es zumindest nicht für ausgeschlossen, dass ähnlich wie bei Postfächern auch eigene PLZ vergeben werden könnten.