Paketshops

schoschi · 2021-02-01T11:53:59.000Z

bingo:

müsste man dann auch noch
post_partner::wikidata
post_partner::wikipedia
post_partner::operator:wikidata
post_partner::operator:wikipedia
ergänzen?

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.

SafetyIng · 2021-02-01T12:59:32.000Z

schoschi:

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?

Ich würde es so lassen, soll ja auch ggf. Firmen geben, die nicht (vollständig) auf wikidata verzeichnet sind.

schoschi:

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.

Die Frage wäre auch, welchen Mehrwert bietet es… Ich sehe da so adhoc keinen… Wikidata ist schon eher sinnvoll.

schoschi:

Negreheb:

Eher “ref:post_partner=*” weil ref ja eigentlich der Haupttag ist. Zumindest meiner Meinung nach.

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.

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?

WST1961 · 2021-02-01T19:34:38.000Z

FvGordon:

WST1961:

bingo:

@WST1961 mit dem key ref würde ich meinen

Das musst Du mir genauer erklären, versteh ich nicht was Du meinst.

Wir verwenden bei den Packstationen auch den ref-Key für die Nummer der Packstation. Hier ein Beispiel: https://www.openstreetmap.org/node/5453409909 ref=240.

Danke, ich warte noch ab, bis alles in trockenen Tüchern ist.

klnkengi · 2021-02-01T20:32:55.000Z

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.

schoschi · 2021-02-01T22:31:15.000Z

@SafetyIng Danke für die Rückmeldung bzw. den Input

SafetyIng:

@schoschi - du bringst dich hier so gut ein - ich würde dich gerne mit als proposal user mit auflisten…

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.

SafetyIng:

Ansonsten was würden euch für Bereiche einfallen, die noch durch diesen Vorschlag affektiert sind? (Features/Pages affected)

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.

schoschi · 2021-02-01T22:57:27.000Z

klnkengi:

Soll das Proposal auch “vollwertige” Postfilialen im Einzelhandel umfassen?

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.

klnkengi:

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?

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?

klnkengi:

Soweit meine Anmerkungen, ich hoffe es ist okay dass ich sie hier poste und nicht im englischen Wiki.

Machen wir ja auch und genau dafür gibt’s mehrere Sprach-Varianten der Wikiseiten usw.

SafetyIng · 2021-02-01T23:23:08.000Z

klnkengi:

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

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.

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?

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.

Soweit meine Anmerkungen, ich hoffe es ist okay dass ich sie hier poste und nicht im englischen Wiki.

Gerne, wird schon mit berücksichtigt.

schoschi:

Was bedeutet das? smile

Naja, du arbeitest halt so viel zu, da möchte ich nur nicht am Ende die Lorbeeren alleine einheimsen.

craft ; office=travel_agent

thx - hatte craft nicht mal auf dem Schirm… - naja office=travel_agent hat sich ja nie durchgesetzt (mMn sogar zurecht)

schoschi · 2021-02-02T09:19:47.000Z

SafetyIng:

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?

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.

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

SafetyIng:

schoschi:

Was bedeutet das? smile

Naja, du arbeitest halt so viel zu, da möchte ich nur nicht am Ende die Lorbeeren alleine einheimsen.

Danke für’s Angebot - das kannst Du machen, wenn Du es für passend hälst; wichtig ist mir sowas nicht.

bingo · 2021-02-02T10:18:52.000Z

wow das nimmt ja ganz schön Fahrt auf.

schoschi:

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?

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.

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.