Paketshops

SafetyIng · 2021-02-08T12:13:30.000Z

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?

maxbe · 2021-02-08T17:42:01.000Z

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

SafetyIng:

Fällt jemandem ein Beispiel aus OSM ein, wo solche Subkey analog schon eingesetz werden?

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.

bingo · 2021-02-09T08:31:21.000Z

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

SafetyIng · 2021-02-11T16:38:45.000Z

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…

schoschi · 2021-02-15T22:16:12.000Z

bingo:

Wegen der verschiedenen Schreibweisen gibt es ja den name-suggestion-index kurz nsi. … Dieser nsi ist im iD Editor integriert und es gibt auch eine Vorlage für JOSM.

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.

SafetyIng · 2021-04-17T10:17:40.000Z

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

aeonesa · 2021-04-17T11:01:40.000Z

Warum so kompliziert, wenn es einfach auch geht.

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

SafetyIng · 2021-04-17T11:13:51.000Z

aeonesa:

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.

rainerU · 2021-04-17T14:20:35.000Z

SafetyIng:

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.

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

SafetyIng · 2021-04-17T15:36:01.000Z

rainerU:

SafetyIng:

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.

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.

Tordanik · 2021-04-20T16:05:17.000Z

SafetyIng:

Was meinst du mit kompliziert?
Paketshop/Postservices in einem shop/amenity → (nun halt) post_office=brands && post_office:type=post_partner

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

SafetyIng:

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

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.

SafetyIng · 2021-04-20T16:36:22.000Z

Tordanik:

SafetyIng:

Was meinst du mit kompliziert?
Paketshop/Postservices in einem shop/amenity → (nun halt) post_office=brands && post_office:type=post_partner

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

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

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.

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

Und noch was: Ich sage regelmäßige Verwechslungen zwischen parcel_mail_in und parcel_send_in voraus. Habe aber leider keinen besseren Vorschlag parat.

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.

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.

Das ist ja auch sinn und Zweck des Proposals

Tordanik · 2021-04-20T18:16:18.000Z

SafetyIng:

Aber um im bekannten Schema zu bleiben, gerne - die Info ist ja so oder so da. ?

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

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

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

SafetyIng · 2021-04-20T18:21:59.000Z

Tordanik:

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

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

SafetyIng · 2021-04-20T21:27:39.000Z

Tordanik:

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

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.

HirschKauz · 2021-05-22T06:24:16.000Z

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

OSM_RogerWilco · 2021-05-22T07:06:22.000Z

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

HirschKauz:

PS Ich freue mich schon auf die Integration in den Editoren

Und ich auf die Integration in die Datenauswerter wie osmand.

SafetyIng · 2021-05-22T08:04:21.000Z

HirschKauz:

PS Ich freue mich schon auf die Integration in den Editoren

OSM_RogerWilco:

Und ich auf die Integration in die Datenauswerter wie osmand.

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

schoka · 2021-05-23T22:55:06.000Z

Daumen hoch fürs angenommene Proposal.

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

SafetyIng · 2021-05-24T09:40:02.000Z

schoka:

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

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…