Paketshops

Communities Deutschland (Germany)
49 
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.

50

zur Info:
das Proposal findet Erwähnung in der Wochennotiz http://weeklyosm.eu/de/archives/14248

51

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…

52

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.

53

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

54

Warum so kompliziert, wenn es einfach auch geht.

**offtopic: **Lass mich raten. Du machst hauptberuflich irgendwas mit IT

55

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.

56

Unschön bzw. verwirrend ist, dass die englische Version der Seite post_office=* beschreibt, während auf der deutschen Seite post_partner=* vorgeschlagen wird.

57

Es tut mir sehr leid, aber ich musste irgendwann sehen, dass ein doppeltes Pflegen doof ist - eigentlich sollte da die Warnmeldung sein :confused:
Die Warnmeldung ist nun eingepflegt.

58

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.

59

Damit lässt sich schon eher arbeiten. Ja, wurde auch schon im Wiki angemerkt. War halt vorher anders herum gewünscht :smiley: 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 :smiley:

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

60

Fände ich gut. Inhaltlich ändert sich natürlich nichts, aber es kommt dann beim Erstkontakt mit dem Taggingschema ein bisschen weniger überraschend. :slight_smile:

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 = *).

61

Ich hadere gerade allgemein mit “brand” genauer zu definieren (im Sinne der post_office-Tags). Und da ggf. post_office:service_provider=* noch hinzu zufügen und mit diesem den Post-Dienstleister zu erfassen.
Dann kann man die Marke des Shops, die also auf dem Schild steht und den Postdienstleister besser unterscheiden und es gibt keine Verwirrung mit dem vormals genutzten operator-Tag…

Wenn man nun feste Werte für den service_provider findet und im Wiki dokumentiert, dann kann der ja ähnlich dem System der Recyclingpunkte genutzt werden und das Wikidata fällt weg… Wäre mMn sogar ein intuitiver Zweck…?

62

So ähnlich gelöst:
post_office:=yes | Liste mit Postdienstleistern

Ich glaube, das sollte so passen und wurde auch vorgeschlagen.

Insgesamt gab es noch dazu Änderungen in:

  • Änderung des Wertes post_office=* zu den Werten aus post_office:type=* und wegfall von letzterem.
  • Die “Marke” des Paketshops/Postshops unter post_office:brand
  • post_office:service_provider als indikator für den Postdienstleister (da ja nicht immer gleich dem operator) + dann eine Liste mit den Einträgen.
63

auch zur Info:
das Porposal ist approved!!

Gratuliere SafetyIng!! - war ne ganze Menge Arbeit und Diskussionen.

PS Ich freue mich schon auf die Integration in den Editoren :wink:

64

Ich finde es auch gut, dass wir endlich ein Schema dafür haben.

Und ich auf die Integration in die Datenauswerter wie osmand.

65

Dann tretet es breit! Ich freue mich auf Unterstützung! Dann wird das sicher relativ schnell passieren.
Das ist halt immer ein Problem bei den Änderungen:
a) “Verlust an Datenzugriff” vs b) Support erst bei “Ausreichender Wichtigkeit”… :smiley:

66

Daumen hoch fürs angenommene Proposal.

@SafetyIng: Mach doch einen Maproulette.org-Task dann könnte das ziemlich schnell umgestellt werden.

67

Ich stimme micht noch auf der Tagging-ML ab.
Ich glaube, ich werde erstmal das alte post_office:type via automatischem Edit zu post_office machen und dann können wir gerne zum Überprüfen aller post_office (amenity und ohne) eine QA-Task in Deutschland machen… Mir ist bisher schon aufgefallen, dass da doch relativ viel auch so durcheinander ist… :smiley:

68

Hallo @SafetyIng, was ist bei den Absprachen von 2021 weiter herausgekommen?
2023 haben wir jetzt leider immer noch die verwirrende Situation mit

  1. dem angenommen Proposal

  2. aber einer gegensätzlichen Tagging-Realität (zumindest in Deutschland) :

Dazu aktuell folgender Thread: DHL Postfiliale, Paketshop - Communities / Deutschland (Germany) - OpenStreetMap Community Forum

Kannst du / die anderen Beteiligten hier weiterhelfen?
Danke