Da waren Maintainer des NSI bisschen schneller und haben das schon für die DHL Packstation angepasst https://github.com/osmlab/name-suggestion-index/pull/5899
Meine Persönliche Meinung ist, dass DHL eigentlich kein Operator in Deutschland sein kann, da DHL im Post/Paketversand effektiv in Deutschland nur eine Marke der Deutschen Post ist… Das ist dann aber schon Korinthenkackerei
Ähnlicher Brei, aber nicht ganz der selbe.
Hier geht es um den NSI und das aktuelle Tagging von Packstationen
In dem Proposal geht es darum, allgemein das Tagging von Packstationen anzupassen.
…warum muß unbedingt für ein als hinreichend etabliert anzusehendes Tagging unbedingt was Neues erfunden werden? Das bringt nur Chaos… Das bestehende Taggingschema ist gut und nachvollziehbar! Darum habe ich es abgelehnt…
Ich habe bisher nicht abgestimmt, weil ich mir unsicher bin, aber so:
empfinde ich es nicht unbedingt nachvollziehbar, eine Packstation als “Verkaufsautomat” zu bezeichnen. Aber da ist die Betrachtung natürlich subjektiv.
Wie ist denn deine persönliche Meinung zu dem Ursprungsthema, @streckenkundler ?
Subjektiv ist genau richtig… Natürlich mag das Tagging nicht immer sauber bezeichungsmäßig passen, man kann sich mit etwas Weitblick hinreichend arragieren… Im Vergleich zum Proposal sehe ich z.B. auch die Versuche das boundary-Schema aufzuweichen und kaputt zu machen extrem kritisch…
Zurück zum Thema…
…da hab ich noch keine abschließende Meinung… Aber als User, der erst seit Mitte/Ende November 2021 mit Edits aktiv ist, schätze ich das Thema name_suggestion_index (NSI) da als extrem harte Kost ein… An sowas traue ich mich selbst in meinen fast 10 Jahren OSM-Aktivität nicht ran… Aber auch wenn ich im Ausgangsbeitrag schon iD lese, rollen sich bei mir alle Fußnägel hoch… iD will eine Art eierlegende Wollmilchsau im OSM-Tagging sein/werden, bekommen es aber nicht hin, grundsätzliche Geometriefehler zu vermeiden…
Ich bin auch der Meinung, daß es nicht unbedingt sinnvoll und zielführend ist, für alles und jeden einen Wikipedia- und/oder Wikidata-Tag zu setzen, bloß weil man es machen kann…
verstehe auch nicht, was
brand:wikipedia=de:Packstation +
operator:wikipedia=de:DHL
zusätzlich zu den wikidata-Tags so leisten soll, bzw. wem das in der Praxis denn nutzen soll?
@HirschKauz Danke für den Hinweis. Mein Anliegen ist nicht ganz so weitreichend wie dass das dort in dem Wiki vorgestellt wird. Ich bin gespannt wie es ausgeht, grad weil ich den Begriff “parcel_machine” nicht kenne.
@SafetyIng Danke für den Link. Ja, das NSI Team war unerwartet schneller. Ich freue mich, dass sie es angepasst haben und finde meinen ersten Vorschlag ganz gut. Ich bin aber auch weiterhin für alle Einwände offen.
Beim Hinzufügen der beiden Tags “brand:wikipedia=de:Packstation” und “operator:wikipedia=de:DHL” bin ich mir auch nicht ganz sicher.
Ein Vorteil könnte sein, dass man auf die entsprechenden Seiten unmittelbar verlinken kann. Ausserdem könnte man evtl. auch auf die Idee kommen die Wikipedia Links mit den Wikidata tags zu vergleichen um auf diese Weise Diskrepanzen zu finden. Letzteres funktionierte natürlich nicht wenn beide Einträge falsch wären.
Aber letztlich weiß ich nicht was man alles mit den Links machen könnte.
@streckenkundler Ich kann deine Meinung gut nachvollziehen. Ich glaube nur, da der name_suggestion_index schon in der Breite verwendet wird, dass es wichtig ist sich mit dem Thema weiterhin zu beschäftigen. Es ist meiner Meinung nach wichtig nicht nur herauszufinden was ein solches Tool kann sondern ebenfalls was es nicht kann, um entsprechende Anpassungen vorzuschlagen. Sonst besteht weiterhin das Risiko, dass sich deine Bedenken unter Umständen in Zukunft bestätigen.
Ich freue mich weiterhin über Beiträge und Feedback. Ich bin weiterhin für Vorschläge offen.
Es werden Tags gesetzt, die kein Mensch braucht,
aber mit deren Hilfe maschinell überprüft werden kann, ob genau diese Tags wirklich korrekt gesetzt sind…
Statt derartigen Nonsens würde ich empfehlen über sinnvolles nachzudenken
ref=*
object:city=*
object:street=*
object:full=*
?
Dazu hat man sich offenbar bereits “Gedanken” gemacht
ref wird nämlich mittlweile nach “branch=” (sic!) dupliziert. Total absurd.
Das ganze System aus ID-Autokorrektur + NSI scheint völlig aus dem Ruder zu laufen…
Es gibt aber Hoffnung auf Besserung, beim ID-Editor hat ja jetzt Martin Raifer aus Heidelberg (der Erfinder von Overpass Turbo) die Zügel in der Hand (siehe https://blog.openstreetmap.org/2021/11/05/self-introduction-of-the-new-id-developer/)), und da werden die gröbsten Auswüchse der alten “der großartige ID-Editor-Autor weiss alles besser und die Community kann ihn mal”-Kultur hoffentlich schrittweise ausgebügelt
Naja, hat schon so einen sinnvollen Hintergedanken, also absurd würde ich es nicht nennen, eher unnötig.
Denn wenn du ein Objekt mit name=Edeka Musterdorf hast, macht iD Mithilfe des NSI ein “name=EDEKA + branch=Musterdorf” draus…
branch bedeutet ja hauptsächlich in diesem Kontext Niederlassung, Zweigstelle, etc…
Wobei ich da halt sagen muss, muss das überhaupt in den "name=" und dann kommt man drauf, dass die Kombi brand=+branch=* zusammen schon Sinn ergibt.
Und jetzt müsste man sich erstmal darüber streiten, was denn besser und treffender für Firmen und Filialen wäre; brand=* oder name=* oder gar was anderes…?
Ich muss ehrlich sagen, wenn ich das so betrachte: Für Filialen von irgendeiner Kette (von wem auch immer geführt) passt brand=* + branch=* semantisch deutlich besser… Für eigenstehende Firmen passt eher name=*
Nur wissen das viele Mapper vor Ort nicht zu unterscheiden. Zumal die Übergänge auch fließend sein können.
Hilfreich wäre allerdings, wenn die Standardkarte brand+branch auch rendern würde.
Die Nummer einer Paketstation gehört in der Tat nicht nach branch
branch wird scheint es von einigen missverstanden: branch ist nicht eine Branche (siehe Beispiele in #6) und eine Nummer ist keine Filiale
+1, keine Ahnung, warum das alles so überstürzt wird.
Im Augenblick wird, für nur einen einzelnen Zusatz einiges Umgekrempelt und alle anderen Probleme auf die Seite geschoben. Wenn dann bitte richtig, ein ausgereiftes Proposal, was eben die Probleme angeht und eine Vereinheitlichung mit ähnlichen Tags aus der selben Rubrik (post_office) bewirkt.
Wenn es allerdings ein gutes, ausgereiftes Proposal gibt, könnte ich mich schon für eine Zustimmung erwärmen. Aber alleine so, wie es jetzt abgelaufen ist, ist es vom Prozess her für mich nicht zustimmungsfähig. Ich hätte mir hier Zeit gewünscht, darüber in Ruhe nachzudenken und mir es im einzelnen anzuschauen…
Ja, das bist du bei vielem… Aber manchmal ist es halt einfach in einer Demokratie so, dass man sich dem Mehrheitswillen beugt,… Vor allem, da kein verfahrenstechnischer Fehler begangen wurde.
Wenn aber deine Meinung ist, dass das Verfahren zu ändern ist, besteht bei dir eindeutig die Möglichkeit, dies durch ein Proposal zu ändern. Ich würde das sogar wahrscheinlich unterstützen, aber so wie es gerade geregelt ist, ist es halt iO. Und ein Chaos sehe ich da nicht wirklich…
Das mag sein, so wie das aber abgelaufen ist, ist das aber nicht gut gewesen… Ich hab das Gefühl, hier soll was nicht 100% durchdachtes durch was anderes nicht 100% durchdachtes ersetzt werden. Ich hätte mir gewünscht: Proposal zu ende laufen lassen, auf Kritik und Vorschlägen eingehen, in Ruhe ein neues erstellen, disskutieren, neue Abstimmung. Das vermisse ich. Dieser verfahrenstechnische Ablauf hier ist für mich kein guter Weg und sollte so in der Form in Zukunft verhindert werden.
Da kommen wir zum Hauptproblem vieler, einschließlich mich… Ich quäle mich mit meinem 80er-Jahre-DDR-Nachmittags-Schulenglisch herum. Vielfach verstehe ich den Sinn, nutze aber Deepl und Co um den tieferen Sinn zu verstehen. Ich persönlich sehe mich außer Stande, sowas zu erstellen. So ergeht es sicher vielen. Darum muß für mich bei sowas dem Nutzer Zeit gegeben werden, sich das Neue in Ruhe anzuschauen.
Ich schon. Ich bin auch beruflich Verarbeiter von Geodaten standartisierter Form (z.B. Daten der Biotopkartierung Brandenburg). Ich weiß, was es heißt, wenn Geodaten vermeintlich gut gemeint, geändert werden und wie weitgreifend diese Änderungen sich erstrecken können. Darum bin ich bei sowas immer sehr vorsichtig, und plädiere dafür, sich das in Ruhe zu überlegen und nachzudenken, wo es Probleme geben könne, was damit verbunden ist, wo man Bestehendes nachnutzen könnte…
Es gibt das bisher genutzte etablierte Tagging über amenity=vending_machine + vending=parcel_pickup. Die Doppelangabe vending=parcel_pickup;parcel_mail_in ist sicher nicht schön, auch auswertetechnisch nicht. Da sehe ich z.B. durchaus Verbesserungsbedarf.
Das erste Proposal amenity=parcel_machine ist gestoppt.
Das zweite Proposal amenity=parcel_locker läuft…
In beiden wurde zugleich hingewiesen amenity=parcel_lockers verwendet werden sollte.
Damit haben wir schon 4 first-Level-Keys…
Es geht nicht draus hervor, ob vending=parcel_pickup;parcel_mail_in und co. ersetzt werden soll, wenn ja durch was?
Es wurde auf https://wiki.openstreetmap.org/wiki/Key:post_office hingewiesen, worauf nicht wirklich gut drauf eingegangen wurde.
Es gibt schon wieder komische Dafür-Stimmen bei diesem Proposal, z.B. fallen durch eine Stichprobe Benutzer auf, die im Wiki existieren, keine Benutzerseite haben und der gleiche Name auf OSM nicht vergeben ist. Z.B.:
