Ich bin auch geneigt für die Paketshop Dienstleistung ein eigenes Node in der Tankstelle oder dem jeweiligen Geschäft zu erstellen.
Was mir nicht gefällt ist der tag post_office:type=post_partner bei Dienstleistern wie UPS, Hermes usw… und widerspricht meines Erachtens dem Wiki https://wiki.openstreetmap.org/wiki/DE:Key:post_office:type . Mit post_partner ist doch eher der operator gemeint, der die Dienstleistung der Deutschen Post anbietet, oder sehe ich das falsch?
Ein Extra-Node erscheint mir nicht so sinnvoll. Eigenschaften wie Öffnungszeiten oder Rollstuhlzugänglichkeit gelten ja für den eigentlichen Laden und die Paketshop-Dienstleistung gleichermaßen. Das müsste also immer doppelt eingetragen werden. Und wenn sich z.B. die Öffnungszeiten ändern oder der Laden schließt, müsste man immer beide Nodes anpassen.
Ganz im Gegenteil. Eine Tankstelle mag 24h geöffnet sein, aber wenn nachts nur der Nachtschalter offen ist, kann die Gabe bestimmter Waren oder mit Dienstleistung verbundene Waren (Pakete) und Geräte (portable Druckluftpumpe) durchaus eingeschränkt sein. Einfach weil die Luke für einiges nicht groß genug ist (und das ja aus gutem Grund).
@OSM_RogerWilco danke für die Verlinkung, den Thread hatte ich noch nicht im Blick. Dort gibt es auch ein paar interessante Vorschläge aber als Fazit bleibt, dass es keinen Standard gibt
@klnkengi und @jengelh ich kann beide Argumente nachvollziehen, was es natürlich nicht einfacher macht
Danke, für die lieben Worte Ja die englische Version ist schon in der Planung, hatte einfach bisher noch nicht die Zeit @schoschi auch für die bisherige gute Unterstützung.
Mir ist gerade aufgefallen, da fehlen ja noch die Paketshop Nummern. Bei DHL weiß ich es auf alle Fälle, dass die sog. Postfilialen/Paketshops nummeriert sind. Ein Paket mit postnummer und Postfiliale 123 + PLZ und Ort kommt an. Wie könnte man so eine Nummer dazu taggen?
Stimmt. In DE ist die Angabe der Paketshop-Nummer bei DHL Pflicht (im Hausnummern-Feld, Quelle), daher sollten wir dafür auch einen Key definieren - habe ich eben im Proposal ergänzt. Bei Hermes und DPD soll nach meiner Recherche dagegen die normale postalische Anschrift des Shops auf dem Versandetikett notiert werden.
Puh… Aus logischer bzw. akademischer Sicht sehe ich gleich gute Gründe dafür, alle ref-Tags beieinander zu gruppieren (also als primäre/wichtigere Angabe zu sehen), und alle post_partner-Tags beieinander zu gruppieren. Bei anderen Zwecken wird das mal so mal so gehandhabt, bspw. ist bei Skipisten die Nummer auch piste:ref und nicht ref:piste weil alle anderen Tags der Piste wie etwa name oder lanes auch den Präfix piste tragen und keinen Suffix.
Aus alltagspraktischer Sicht: Als Mapper als auch Data Consumer fände ich übersichtlicher, wenn alle Eigenschaften zu einem post_partner: direkt beieinander stünden, denn sobald ein Shop mal 2-3 Brands unterstützt, übersieht man sonst leichter mal, dass zum obersten brand “irgendwo unten” bei ref:post_partner:brand auch noch eine Angabe steht.
Nach meinem Verständnis von Key:wikidata und Key:wikipedia ist das implizit für alle Keys definiert, d.h. man *braucht *es beim einzelnen key nicht notieren.
Speziell bei wikidata fände ich eine explizite Nennung aber sinnvoll, weil dieser Identifier diverse Mehrwerte erlaubt, bspw. auf einer Karte das jeweilige Logo anzeigen, die korrekte Übersetzungen anzeigen, oder eine zuverlässige Rückwärtssuche, also “Liste mir alle Paketshops in 15km Umkreis, die Teil im Hermes-Netzwerk sind” was mit dem operator-Key nicht zuverlässig geht (bspw. wenn jemand grenznah sucht, würden 2 verschiedene Schreibweisen des Operators gefunden, und woher soll ein Programm wissen, dass diese beiden dasselbe sind?). Wenn wir wikidata explizit erwähnen, dann fände ich für die Mapper einen netten Service, in der jeweiligen Sprach-Version der post_partner-Wikiseite und des JOSM-Presets auch gleich eine Liste der wikidata-IDs der brands anzubieten, die im jeweiligen Sprachraum aktiv sind, also bei der DE Wikiseite die in DE, CH, AT operierenden brands, bei der FR Wikiseite die in FR, Belgien,… operierenden brands usw. Das geht, denn mehr als wenige Dutzend werden das ja selbst in großen Ländern/Sprachgemeinschaften wohl nicht. Und wenn wir am einzelnen Shop gemäß brand:wikidata die wikidata-ID pflegen, dann können wir den operator-Key weglassen - diesen Bezeichner können Karten etc. automatisch generieren, wodurch wir vermeiden würden, über die tausenden Paketshops hinweg für denselben operator x verschiedene Schreibweisen (Name der DE Tochtergesellschaft oder EU-Holding? Mit oder ohne Rechtsform wie AG oder GmbH? etc.) in der Datenbank zu haben. Ich habe ins Proposal einen ersten Wurf für wikidata eingebaut, damit wir alle eine konkrete & einheitliche Vorstellung haben, also eine Diskussionsgrundlage. Was meint ihr?
Dagegen sehe ich wenig Mehrwert, bei jedem einzelnen Paketshop einen Link zum Wikipedia-Artikel nicht des Ladens sondern jedes Partner-Logistik-Konzerns zu pflegen. An dessen Wikipedia-Eintrag kommt man ja sofort via wikidata dran, könnte also in data consumern (zB Karte aller Paketshops aller Konzerne) ganz einfach einen Wikipedia-Link generieren.
Ich würde es so lassen, soll ja auch ggf. Firmen geben, die nicht (vollständig) auf wikidata verzeichnet sind.
Die Frage wäre auch, welchen Mehrwert bietet es… Ich sehe da so adhoc keinen… Wikidata ist schon eher sinnvoll.
Dem würde ich mich auch anschließen.
@schoschi - du bringst dich hier so gut ein - ich würde dich gerne mit als proposal user mit auflisten…
Ansonsten sehe ich das soweit gut ausgearbeitet, dass man den RFC-Prozess zu starten.
Ansonsten was würden euch für Bereiche einfallen, die noch durch diesen Vorschlag affektiert sind? (Features/Pages affected)
Ich hätte adhoc gesagt:
shop=* ; amenity=* ; amenity=post_office ; post_office:type=*
Müsste nicht eigentlich post_office:type=post_partner dann als “outdated” markieren?
Ja die englische Version ist schon in der Planung, hatte einfach bisher noch nicht die Zeit