Danke, ich warte noch ab, bis alles in trockenen Tüchern ist. 
Hallo,
vielen Dank für die Erstellung des Proposals! 
Die Möglichkeit Paketshops zu taggen, fehlte bisher tatsächlich.
Soll das Proposal auch “vollwertige” Postfilialen im Einzelhandel umfassen? Da gab es bisher - zumindest laut deutschsprachigem Wiki - die Möglichkeit, einfach post_office=yes zu taggen. Das war schön einfach. Alle Service-Leistungen einzeln aufzuzählen, scheint mir dagegen für so einen Fall zu kompliziert. Neben den im Proposal aufgeführten Services bietet die Post z.B. auch noch Einschreiben oder Wertbriefe an (sowohl zum Abholen als auch zum Absenden).
Warum es post_partner:brand und post_partner:brand:operator braucht, habe ich auch nicht ganz verstanden. Reicht es nicht, einfach den operator (Hermes, DHL, Deutsche Post, …) anzugeben?
Soweit meine Anmerkungen, ich hoffe es ist okay dass ich sie hier poste und nicht im englischen Wiki.
@SafetyIng Danke für die Rückmeldung bzw. den Input 
Was bedeutet das? Ich würde mich einfach freuen, wenn ich e n d l i c h die Paketshops ohne Stirnrunzeln, Rumsuchen und trotzdem halb-schlechtem Gewissen mappen könnte. Und im Moment will und kann ich mir die Zeit nehmen, das Thema zu treiben, aber in 1 Woche sieht das schon wieder ganz anders aus - da erwartet mich viel PC-Arbeit und danach will ich die Kiste nimmer sehen.
craft, bspw. gerade Änderungsschneider sind öfters Paketshop. Sonst habe ich auf den ersten 585 Einträgen von https://taginfo.openstreetmap.org/keys nichts gefunden, was in meinem Sichthorizont nennenswert oft Paketshops wären - am ehesten kann ich mir das noch für office=travel_agent (wird aber 10x häufiger als shop gemappt) und information=office und leisture=* und sport=* vorstellen.
Nein, denn wie Du selbst schreibst, gibt es dafür ja schon verbreitete & geeignete Tags Es geht beim Proposal um “die anderen Orte” (mathematisch/logisch gesagt das Komplement), also an denen eben gerade nicht alle Service-Leistungen eines Postamts angeboten werden, sondern nur eine mehr oder minder kleine Auswahl.
Gute Frage! Wenn ich jetzt nochmal darüber nachdenke, fällt mir mit dem aktuellen Proposal-Stand kein Grund mehr ein 
Mit wie vielen Logistik-Konzernen ein Shop kooperiert, geht ja aus der Anzahl von post_partner:-Präfixes hervor, und die Namen aus dem jeweiligen wikidata bzw. operator Tag. **Hat irgendjemand ne Idee, wofür wir post_partner:brand noch brauchen?
Machen wir ja auch und genau dafür gibt’s mehrere Sprach-Varianten der Wikiseiten usw.
Jein, eigentlich wäre es konsequent diese auch dann als Postpartner (nichts anderes sind diese ja offiziell) zu taggen. Problem: In Dänemark gibt es sowas auch - wird garnicht getaggt. In Frankreich, besonders in kleinen Orten, gibt es sowas, aber da wird es idR mit post_office:type=post_partner getaggt. Es gibt einfach keine Einheitlichkeit.
Hat ein einfachen Grund - nicht alles, was unter einer Marke passiert, passiert durch den Gleichen operator. Für Deutschland gibt es da eine schöne Übersicht: https://wiki.openstreetmap.org/wiki/Deutsche_Postdienstleister - deswegen unterscheidet man tendenziell brand und operator.
Was aber auch schon im Wiki vorgeschlagen wurde, den Tag post_partner:brand=* in den post_partner=* zu integrieren und finde ich auch sehr sinnvoll.
Gerne, wird schon mit berücksichtigt.
Naja, du arbeitest halt so viel zu, da möchte ich nur nicht am Ende die Lorbeeren alleine einheimsen.
thx - hatte craft nicht mal auf dem Schirm… - naja office=travel_agent hat sich ja nie durchgesetzt (mMn sogar zurecht)
Vor dem Hintergrund wäre doch nochmal wünschenswerter, wenn eine wikidata-ID angegeben würde - setzt man die auf Ebene des operators, sind die übergeordneten Ebenen (Brand/Make als auch europäische Operator-Holing) auch eindeutig identifizierbar. Dazu könnte die von Dir verlinkte Liste ja einfach um die wikidata-IDs der operators ergänzt werden. Dann könnte post_partner:brand und post_partner:brand:operator entfallen, solange post_partner::operator:wikidata=* gefüllt ist (den Tag-Namen müssten wir im Proposal noch anpassen).
Danke für’s Angebot - das kannst Du machen, wenn Du es für passend hälst; wichtig ist mir sowas nicht.
wow das nimmt ja ganz schön Fahrt auf.
Wegen der verschiedenen Schreibweisen gibt es ja den name-suggestion-index kurz nsi. Hier werden gerade umfassende Änderungen vorgenommen. Dieser nsi ist im iD Editor integriert und es gibt auch eine Vorlage für JOSM. Mit einem Klick werden dann etliche Tags automatisch gesetzt. Im nsi gibt es bereits 139 amenity=post_office Einträge: https://nsi.guide/index.html?t=operators&k=amenity&v=post_office und genausoviel amenity=post_box Einträge: https://nsi.guide/index.html?t=operators&k=amenity&v=post_box
Da sind natürlich auch Paketshops dabei d.h. es müssten dort auch Anpassungen vorgenommen werden.
Ich bräuchte einmal Hilfe - in der Talk Seite wird gerade von einem Mapper aus den US vorgeschlagen das post_partner::* weg zu lassen und durch folgendes zu ersetzen:
shop=kiosk
name=Lotto Kiosk
post_partner:letter:brand=Deutsche Post
post_partner:stamps:brand=Deutsche Post
post_partner:parcel_send_in:brand=DHL
post_partner:parcel_send_in:operator=DHL Paket GmbH
post_partner:parcel_mail_in:brand=DHL
post_partner:parcel_mail_in:operator=DHL Paket GmbH
post_partner:parcel_pickup:brand=DHL
post_partner:parcel_pickup:operator=DHL Paket GmbH
post_partner:parcel_mail_in:brand=Hermes PaketShop
post_partner:parcel_mail_in:operator=Hermes Logistik Gruppe Deutschland
post_partner:parcel_pickup:brand=Hermes PaketShop
post_partner:parcel_pickup:operator=Hermes Logistik Gruppe Deutschland
Ich finde diese Lösung (auch wenn vielleicht für Computer besser auswertbar) - nicht sinnvoll, v.a. da es keine reale Lesbarkeit mehr gewährleistet.
V.a. wenn man beim einpflegen der Daten 5 tausend Mal die Namen ausschreiben muss - das ist einfach weltfremd…
Aber ja, man müsste in den Tag eine festgelegte Systematik bekommen. Ich würde aber z.B. diese deutsche Wikiseite eher anführen.
Fällt jemandem ein Beispiel aus OSM ein, wo solche Subkey analog schon eingesetz werden?
post_partner:parcel_mail_in:brand=DHL
post_partner:parcel_mail_in:brand=Hermes PaketShop
Kann man nicht zusammen an ein Objekt taggen, Schlüssel müssen eindeutig sein.
post_partner:parcel_mail_in:brand=DHL;Hermes
wäre möglich, aber meines Erachtens nicht besser und dann kommt man wieder durcheinander, wenn nur einer “parcel_pickup” anbietet, aber zwei Anbieter “parcel_mail_in”…
Sehr weit von Paketdiensten abgelegenes Beispiel: climbing:grade::min=* mit “brand=uiaa|saxon|french”, vermutlich auch andere Dinge, wo weltweit viele Skalen parallel verwendet werden.
Derweil habe ich das Proposal auf der Tagging-Mailingliste veröffentlicht.
https://lists.openstreetmap.org/pipermail/tagging/2021-February/059485.html
Mal gucken, was dabei so herum kommt…
Ja, das aktuelle NSI-JOSM-Plugin (Danke für den Tipp! :)) trägt beim Erstellen neuer Einträge mehrere Keys gleich mit den richtigen Werten auf einen Rutsch ein, daher ist ein zusätzlicher key kein manueller Mehraufwand. Aber einen Mehrwert durch post_partner:brand=* sehe ich auch mit NSI nicht, denn key post_partner::wikidata=* würde zur Identifizierung durch Menschen ( ist sprechend) als auch Maschinen (Wert des Keys) völlig reichen und vermeidet Aufwand, Schreibvarianten und Inkonsistenzen in den Fällen, die NSI noch nicht unterstützt: 1) Bei Änderungen bspw. wenn ein Laden von Brand A zu B wechselt, muss man manuell ran, wodurch “alles wie früher” ist. 2) Durch die noch nicht unterstützte Editoren wie maps.me, die laut Statistik allerdings nur einen kleinen Teil der User als auch Edits ausmachen.
Insofern fände ich auch angesichts NSI besser, nur den key post_partner::wikidata=* einzuführen (und gerne bequem per NSI zu füllen) und post_partner:brand=* nicht einzuführen.
Hallo in die Runde,
da sich die Zeit etwas weiter gedreht hat, ist in der Konsensbildung aus post_partner eine Abwandlung zu post_office geworden.
Das aktualisierte Proposal findet sich immernoch unter https://wiki.openstreetmap.org/wiki/Proposed_features/shop_as_post-partner
Wenn jemand noch Anmerkungen hat - her damit! Ansonsten würde ich das demnächst in Richtung Voting schieben.
Grüße
SafetyIng
Warum so kompliziert, wenn es einfach auch geht.
**offtopic: **Lass mich raten. Du machst hauptberuflich irgendwas mit IT
Was meinst du mit kompliziert?
Paketshop/Postservices in einem shop/amenity → (nun halt) post_office=brands && post_office:type=post_partner
Und dann halt entsprechende Tags optional als “Verfeinerung”. Die aber nicht angegeben werden müssen.
Unschön bzw. verwirrend ist, dass die englische Version der Seite post_office=* beschreibt, während auf der deutschen Seite post_partner=* vorgeschlagen wird.
Es tut mir sehr leid, aber ich musste irgendwann sehen, dass ein doppeltes Pflegen doof ist - eigentlich sollte da die Warnmeldung sein 
Die Warnmeldung ist nun eingepflegt.
Soweit finde ich es auch gut, wobei ich eigentlich bevorzugen würde, den Schlüssel post_office in post_office:brand umzubenennen. (Bei anderen Taggingstandards wird der Basisschlüssel tendenziell für den Typ verwendet – hier also wenn überhaupt dann eher für das, was bei dir post_office:type heißt. Die Marken direkt in post_office zu packen läuft den Konventionen für Tags m.E. zuwider.)
Wo ich das Proposal aber doch etwas umständlich finde ist bei der Auflistung der angebotenen Dienstleistungen. Das sieht man auch an den Beispielen, wo dieselbe Marke bzw. dieselbe Wikidata-ID ohne Not mehrmals wiederholt werden muss.
Ich würde daher die Einführung eines Schlüssels post_office:services=* vorschlagen, der dann die mit Semikolon getrennte Liste der angebotenen Dienstleistungen enthält. Das sollte mit der Empfehlung verbunden werden, die weitere Aufschlüsselung nur dort zu verwenden, wo sie wirklich nötig ist.
Damit könnte das vollständige Tagging fürs erste Beispiel im Proposal dann so aussehen:
name=Handy Shop
shop=mobile_phone
post_office:type=post_partner
post_office:services=parcel_pickup; parcel_send_in; parcel_mail_in
post_office:brand=Hermes PaketShop
post_office:brand:wikidata=Q105702843
Das ist eh schon ziemlich detailliert, aber immer noch deutlich kompakter als der aktuelle Vorschlag mit
post_office:parcel_send_in:brand:wikidata=Q105702843
post_office:parcel_mail_in:brand:wikidata=Q105702843
post_office:parcel_pickup:brand:wikidata=Q105702843
post_office:parcel_send_in:brand=Hermes PaketShop
post_office:parcel_mail_in:brand=Hermes PaketShop
post_office:parcel_pickup:brand=Hermes PaketShop
Wenn die deutsche Version so stark abweicht, dass sie eher verwirrt als hilft, sollte die Sprachleiste vielleicht ganz rausgenommen werden.
Und noch was: Ich sage regelmäßige Verwechslungen zwischen parcel_mail_in und parcel_send_in voraus. Habe aber leider keinen besseren Vorschlag parat.
So als Fazit: Eigentlich finde ich das alles schon gründlich durchdacht und schön dokumentiert, ich würde mir aber noch etwas Feintuning an der “Benutzerfreundlichkeit” für gängige Fälle wünschen.
Damit lässt sich schon eher arbeiten. Ja, wurde auch schon im Wiki angemerkt. War halt vorher anders herum gewünscht 
Aber um im bekannten Schema zu bleiben, gerne - die Info ist ja so oder so da. ?
Ja, ist mir bewusst. Das Problem, was ich dabei habe - ich kenne z.B. hier in der Ecke mehrere Läden, die als Paketshop für DHL fungieren und gleichzeitig für den lokael DP-Konkurenten Briefmarken vergeben/Briefe annehmen… Das muss man auch irgendwie anzeigen können.
Die primäre Idee war :{brand}:services=[…Liste…] zu wählen, was aber aus seite der Datenkonsumenten ultra schlecht ist…
Ich kann das auch verstehen - aber ich persönlich fände zwei verschiedene Vorgehensweisen verwirrender… Da dann doch eher das zuerst vorgeschlagene
Da gab es auch im Wiki schon den Vorschlag “from” “to” "return"´zu verwenden - sage ich klar - wäre ich nicht drauf gekommen, weil ich einfach die Sprache verwendet habe, die ich für diese Elemente kenne. Aber eigentlich ist das auch sehr schlüssig und deutlicher.
Das ist ja auch sinn und Zweck des Proposals
Fände ich gut. Inhaltlich ändert sich natürlich nichts, aber es kommt dann beim Erstkontakt mit dem Taggingschema ein bisschen weniger überraschend.
Dass du es möglich machen willst, diese komplexeren Situationen auch zu erfassen, kann ich voll nachvollziehen – und dass du lieber eine einheitliche Lösung hast als eine für einfache + eine für schwierige Fälle an sich auch. Du machst damit im Ergebnis eben auch einfache Situationen etwas komplexer. Meine Designphilosophie wäre eher “Easy things should be easy, and hard things should be possible.” Ist aber sicher eine Abwägungssache, ich sehe schon auch für deinen Ansatz Argumente.
Falls dein Unbehagen mit daran hängen sollte, dass in einem Fall die Services im Schlüssel wären und im anderen Fall als Liste im Wert, könntest du alternativ noch über das recycling-Modell nachdenken. Also z.B. post_office:parcel_pickup = yes (und nur dort, wo eine Dienstleistung nicht für alle Marken angeboten wird, dann zusätzlich oder stattdessen den Unterschlüssel post_office:parcel_pickup:brand = *).