Wiki zu Packstation führt zu Fehleingaben?

Bin ich dafür. Da gibt es aber auch noch einen anderen Kandidaten: Hundekot-Tüten-Spender. Sollte gleich mit verarztet werden.

+1

ganz genau

Da bin ich auch dafür. Was wäre dann der Hauptschlüssel, amenity=packstation ?
In der Wiki-Seite ist erwähnt, daß es Packstationen auch in Italien gibt. Weiß jemand etwas über die dortigen Bauformen?

Im Englischen Sprachraum spricht man bei solchen Objekten meist als “parcel locker”.

packstation sollte schon deswegen nicht unbedingt im Tagging auftauchen, weil es bei anderen Anbietern mit gleichen Angebot (Amazon Locker zb) unpassend wäre.

“Packstation” ist außerdem eine eingetragene Marke der Deutschen Post (siehe https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=003488475 ).

Ich finde den Hinweis von kartonage gut und wäre für

amenity=parcel_locker
parcel_locker=cabinet
parcel_locker:parcel_pickup=yes
parcel_locker:parcel_mail_in=yes

die beiden die ich gesehen habe waren Typ Schrank, jeweils in einem Bahnhof

Ich war leider zwei Tage auf Dienstreise: Ich wollte mit der Bereinigung des Wikis nicht unbedingt Trompete spielen und direkt weitere Mauern einreißen :).
Ich habe den letzten Stand mal ins Wiki übertragen und etwas mit den möglichen Ausprägungen geschärft: Siehe https://wiki.openstreetmap.org/wiki/DE_talk:Packstation#Schl.C3.BCssel_f.C3.BCr_Packstation-Typen

Wer kann das in die Taggingliste transportieren?


amenity=parcel_locker
parcel_locker=[cabinet|circular|parcel_box]
parcel_locker:parcel_pickup=[yes|no] <persönliche Anmerkung/Vorschlag:default sollte yes sein>
parcel_locker:parcel_mail_in=[yes|no] <persönliche Anmerkung/Vorschlag:default sollte no sein>

taginfo sagt aktuell für amenity Werten mit parcel…
parcel_lockers=14 (Wiki vorhanden: siehe https://wiki.openstreetmap.org/wiki/Proposed_features/Parcel_lockers_and_parcel_postbox)
parcel_box=13
parcel_pickup=6
parcel_service=4
parcel_point=1
parcel_locker=1
parcel_mail_in=1

edit: Taginfo angehängt

Das Proposal kannte ich noch nicht, danke für den Link. Allerdings werden dort getrennte Tags für Senden und Empfangen vorgeschlagen obwohl die meisten Vorkommen “vending=parcel_pickup;parcel_mail_in” sind.
Diskutiert man sowas dann in den existierenden Vorschlag oder erstellt man einen Gegenvorschlag? Ohne proposal gibt es ja nie ein approved tag :slight_smile:
Aus der Diskussion dort würde ich noch mitnehmen


parcel_locker:parcel_sending=[yes|no] <statt parcel_mail_in>
parcel_locker:mail_sending=[yes|no] <default in DE sollte no sein, "In the Netherlands, parcel lockers usually (maybe always) contain an integrated postbox" >

Useful combinations
brand=[DHL|Amazon|...]
collection_times=*: the times at which parcels are collected
operator=*: name of the company that operates the parcel lockers or the parcel postbox
opening_hours=*: hours when the parcel lockers are accessible (e.g. 24/7)

Idee hinter brand=Amazon: Derzeit wäre dann parcel_sending=yes nur Retouren an Amazon. Wenn Amazon morgen universeller Paketdienstleister wie DHL werden würde müsste nichts umgetaggt werden.
Operator und brand müssen ja nicht das gleiche sein, und es gibt auch private Packetstationen an Mehrfamilienhäuser (ohne parcel_sending und ohne brand, aber mit Operator. Der Betreiber einer DHL oder Amazon Station könnte auch ein Einkaufszentrum sein.
parcel_locker:parcel_mail_in (um Verwirrung mit Briefen zu vermeiden vielleicht besser parcel_sending statt parcel_mail_in)

als Betreiber würde ich denjenigen sehen, der die Pakete reinpackt bzw. aufgegebene Pakete abholt. Macht sowas ein Einkaufszentrum?

Nein. Aber ich würde als Betreiber denjenigen sehen der es reparieren lässt wenn es kaputt ist bzw. entscheidet von wem es wie genutzt werden darf. Und das kann auch die Eigentümergemeinschaft eines Mehrfamilienhaus sein, die das für die Nachbarschaft mit anbietet. Googel mal z. B. “parcellock”, das sind dann Kästen in die mehrere Paketdienste Pakete reinlegen. Und sowas möchte ich auch erfassen können.

Ich wäre auch entweder für parcel_sending=yes und parlcel_receiving=yes

oder eben für parcel_mail_in=yes und parlcel_pickup=yes, eben alles ohne weitere Bestandteile um Key. Denn diese Tags könnte man dann, wie ich einem anderen Thread auch schon mal vorgeschlagen habe, 1:1 auch auf Paketshop übertragen, für die ja auch noch ein Tagging Schema gesucht wird…

in dem Fall wäre z.B. die Eigentümergemeinschaft der Betreiber (und Besitzer), aber das ist auch ein ziemlich anderes Ding als eine Packstation der Post, eher so eine Art privater Gemeinschaftspaket"briefkasten".

Ich finde das nicht so viel anders. Die Post ist nur Marktführer (in Deutschland). In anderen Ländern sieht das ggf. anders aus, und auch in Deutschland versuchen andere Anbieter sich zu etablieren. Siehe auch https://www.heise.de/newsticker/meldung/Parcellock-Hermes-DPD-und-GLS-stellen-Paketkasten-vor-2838511.html
Für mich als Nutzer ist das doch alles das gleiche, ich bekomme ein Paket und hole es aus so einem Kasten ab. Bzw. ich möchte wissen welche Zustell- und Abholmöglichkeiten es im gewünschten Gebiet gibt und suche daher entsprechend getaggte Objekte.

dass es unterschiedliche Anbieter gibt ist klar, was ich meine ist, dass das eine von einem bestimmten Anbieter betrieben wird, und man dort Pakete aufgeben und abholen kann, das andere ist eine Art Briefkasten, wo diverse bzw. jeglicher Paketdienst Pakete abgeben kann, wo man aber als Kunde keine aufgeben kann. Ersteres ist z.B. auch typisiert / standardisiert (wird also z.B. in der Regel auch mehr als Orientierungspunkt dienen als ein Objekt mit unbekanntem und ggf. unauffälligem Aussehen) und kann von jedermann genutzt werden (steht im Öffentlichen Raum, bzw. ggf. auch im halböffentlichen Raum (Einkaufszentrum, Bahnhof etc.), während die anderen private Briefkästen sind, die vermutlich überwiegend nicht allgemein zugänglich sein dürften, und wo der Nutzerkreis stark einschränkt ist (privat). Es gibt also sogar auch deutliche physische Unterschiede, was z.B. beim Unterschied einer öffentlichen Dusche (amenity=shower) im Vergleich zu einer privaten (die wir überhaupt nicht taggen) nicht der Fall ist.
Der parcellock aus dem o.g. Heise-Artikel verdient m.E. denselben tag wie die postbetriebenen Stationen (sieht zumindest so aus, als wäre das ein öffentliches Angebot für jedermann und nicht ein Paketkasten für ein Mietshaus, wo ggf. auch die Nachbarn aus Freundlichkeit heraus ihre Pakete ablegen lassen dürfen, auf individueller Vereinbarung).

Ich wäre für unterschiedliche tags, anhand dessen, was hier beschrieben wurde und was ich mir darunter vorstelle, ich kenne solche privaten Paketbriefkästen allerdings nicht aus eigener Erfahrung.

Ich hole das Thema nochmal hervor. Hier hatte User sundew zwei Packstationen u.a. mit type=Schrank ergänzt, was ich zu type=cabinet geändert habe. Ich kannte aus dem Wiki (DE:Packstation) nur diese Variante.

sundew war so nett und hat mich dann aber aufgeklärt, dass type=Schrank tatsächlich immer noch der vorherrschende Tag ist (siehe CS-Kommentar).

Ich persönlich bin dafür das zu ändern. Luskas458 schlägt hier die Verwendung von model=* vor. Diesen Vorschlag finde ich gut.

type soll sowieso nur für Relationen verwendet werden

Gibt es noch Meinungen zu model=*?

Es ist doch letzten Endes egal, welches Tag nun benutzt wird. Viel schlimmer ist, dass es verschiedene Tagwerte für ein und dieselbe Eigenschaft gibt. Und durch ein neues Basistag (model=*) wird es am Ende noch viel mehr Varianten geben: überprüfte Packstationen mit alten Tags / mit beiden Tags / nur mit neuem Tag, unüberprüfte Packstationen in allen Varianten, vorgeblich mittels unerlaubter Quellen geprüfte, usw…

Eigentlich kann es auch nicht sein, dass am Ende mal wieder das Wiki undiskutiert geändert wird, nur weil niemand hier im Forum widersprochen hat. Das Interesse hier scheint auch nicht sonderlich groß zu sein.
Es betrifft aber schließlich nicht nur tausende Packstationen von DHL deutschlandweit, sondern auch andere Anbieter, z.B. hier im Norden Amazon, Yoursafe24, Hamburg-Box, usw… Wie das derzeit weltweit aussieht, vermag ich nicht zu sagen.

Da sollte man sich wirklich erstmal in der OSM-Community einig werden. Es müssten alle Mapping-App-Entwickler ins Boot geholt gewerden, denn die Vielzahl derzeit aktiver Apps richtet schon genug Tagging-Chaos an. Es sollten Aktionen, wie z.B. Wochenaufgaben, organisiert werden, um umzutaggende Stationen vorher vor Ort zu prüfen. An einen Mechanical-Edit mag ich gar nicht erst zu denken - die Hürden wären unüberwindbar.

Sowas kann man nicht mal schnell husch-husch übers Knie brechen. Und schon gar nicht mitten im Restsommer, wenn jede(r) genug mit eigenen Outdoormapping-Projekten beschäftigt ist.
Also bitten keinen unnötigen Aktionismus. Lasst uns erstmal in Ruhe darüber nachdenken, wie man das ggf. umsetzen kann, und dann zum Jahreswechsel da mehr Energie rein stecken. Oder halt den Mut zu haben, es ganz bleiben zu lassen.

sundew

PS: Corona-safe ist das Erfassen neuer DHL-Packstationen mittlerweile geworden - Referenznummer und Postleitzahl stehen bei neuen Maschinen jetzt draußen dran. Eine Bedienung der schmierigen Touchscreen ist nicht mehr nötig.

Ich sehe ein, dass die Verwendung von type und die deutschen Werte für type aktuell hauptsächlich in Verwendung sind und damit den aktuellen “Standard” darstellen. Meine Änderung zu type=cabinet war daher nicht richtig. Ich ändere das deshalb wieder zurück zu type=Schrank.

Außerdem habe ich die deutschen Werte im Wiki dokumentiert und den Hinweis ergänzt, dass die deutschsprachigen Werte aktuell am meisten verwendetet werden.