Paketshops

[SafetyIng (Robin)]

@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