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.:
Danke… Ich schreibe lieber nicht, was ich darüber denke…
Aber das sollte man tunlichst genaustens weiter beobachten… Ich ahne was…
Beachte… es gibt zwischen OSM-Account und Wiki Groß-Kleinschreibungsunterschiede… alle 7 Nutzer habe ich per http://whosthat.osmz.ru/ (mit Unterschieden in der Groß-Kleinschreibung) gefunden… Dieser Unterschied ist nicht schön und missfällt mit auch, zumal er auch Tür und Tor für Zweit- und Dritt-Accounts öffnet…
…und noch: die oben verlinkte OSM-User-Names-Database scheint am 30.9.2021 kein Update mehr erfahren zu haben…
Mir missfällt das grundsätzliche Vorgehen der allgemeine Ablauf… Beenden… Ändern und gleich wieder zur Abstimmung stellen… Ohne eine erneute Disskussion, ob es noch Ergänzungen/ Anderungen geben könnte.
Auch wenn der Ablauf sicherlich den Regularien entsprechen möge… im Sinne einer möglichst großen internationalen Zustimmung ist es für mich das denkbar schlechteste Vorgehen… Für mich geht es auch ein Stück weit ums Prinzip… Saubere und nachvollziehbare Abläufe, was ich hier vermisse…
Wurde von der beendeten Abstimmung parcel_machine noch mehr geändert in der neuen Abstimmung zu parcel_locker? Für mich sieht das nur nach der Umbenennung des Wortes aus, weil es korrekter so ist.
Wenn es dir ums Prinzip geht, kann ich nicht weiterhelfen fürchte ich. Da es den Regularien entspricht, finde ich das hier auch nachvollziehbar. Es ist im Wiki dokumentiert. Was wäre konkret sauberer oder nachvollziehbarer darzustellen?
Bis zum 3. Januar läuft die Abstimmung noch. Da bleibt über die Feiertage vielleicht ein bisschen Zeit, um über die Abstimmung nachzudenken, ob es noch wichtige Einwände gibt.
Erkenntnis während des Proposals ist da, daß ein anderer Name nun doch besser ist… Gut… Entweder Proposal mit negativen Ergebnis zu Ende laufen lassen oder gleich abbrechen… (Ergebnis wäre das selbe)
Dann ändern und ggf. Änderungsvorschläge einarbeiten… Neu disskutieren… und nach entsprechender Zeit neu starten… Das wäre eine hinreichend sauberer Weg gewesen…
Aber Zwischendrin alles zu ändern… und von einem Tag auf den anderen wird man von einem Proposal auf ein offensichtlich neues Proposal per Link weitergeleitet, welches sich bereits auch schon in der Abstimmung befand, fand ich reichlich schräg… Das ist keine gute Arbeitsweise…
Gerade beim Thema Packstationen kommt es doch nun wirklich nicht auf Tage an… Das kann man in Ruhe disskutieren…
Zur Diskussion “parcel_locker” etc. habe ich bisher keine inhaltlichen Verbesserungsvorschläge.
@Jo Cassel: Deinen Vorschlag finde ich sehr gut.
Allerdings kann man ref nicht automatisiert über den name_suggestion_index hinzufügen lassen, da die Referenz Nummer für jede Packstation individuell vergeben wird. Folglich wären die tags “object:city=" und "object:street=” interessant als zusätzliche Tags eine automatische Vervollständigunb via NSI. Jedoch gibt es bereits auch das Tag “postal_code=*” für Packstationen, dass im Endeffekt die gleiche Information enthällt. Deshalb würde ich das Tag “postal_code” als zusätzliches Tag für den NSI Eintrag von DHL Packstationen vorschlagen. Haltet ihr dieses Tag für eine gute Erweiterung?
Sagt Bescheid, wenn ihr neue Vorschläge im Bezug auf die NSI tags für DHL Packstationen habt. Ich freue mich weiterhin über alle konstruktiven Beiträge.
Edit: Ich habe doch noch eine allgemeine Frage. Haltet ihr Wikipedia links für eine gute Idee oder sagt ihr dass man diese besser weg lassen sollte? Ich denke bei meiner Frage auch an andere Objekte bei denen über den NSI Wikipedia Artikel verlinkt werden.
Bei einer minimalen Änderung eines Tags? Da ist nichts an der Bergündung oder sonst was geändert worden! Da wurde einfach parcel_mashine durch parcel_locker ersetzt! Irgendwo muss man doch mal fünf gerade sein lassen. Wenn man hier irgendeine große Bedeutung geändert hätte, ja okay. Alles andere wurde schon vorher weit und breit diskutiert.
Naja, aber die Argumentation gilt ja nur, weil es in dem Proposal für post_office so definiert wurde, weil da Packstationen garnicht betrachtet wurden. Man könnte ja die Verwendung auch aufweiten. Es geht ja aber einen Schritt weiter:
Man erzeugt zwei Taggings, die sich mit dem selben Thema beschäftigen, aber für selbe Systeme “Paket hinsenden”, “Paket absenden” und “Verpasste Sendungen abholen” unterschiedliche Notation verwenden. Das führt doch nur zu absoluter Unübersichtlichkeit und am Ende wird es irgendwer durcheinander schmeißen… Warum dann nicht von vornhereit einheitlich machen?
… logisch, Quelle für eine Kennung ist entweder ein (freies) Kataster des Aufstellers ODER eine vor-Ort-Beschriftung.
Vorsicht in der Doku lese ich:
“You can tag ways and areas with postal_code=* to describe the postal code of an area or a street.
Other tagging schemes
For buildings and nodes…
This postal_code key has been used on buildings and nodes too, however the Karlsruhe scheme has become more well established (see addr=). The tag addr:postcode= should be used in the context of addresses for buildings and nodes. […]”
Es wird meiner Erfahrung nach aber nicht von allen gern gesehen, addr:[…] anders als an klassischen Wohn/Geschäftsadressen zu verwenden.
Daher mein Hinweis auf das object:[…]-Schema, das 1:1 analog zum addr-Schema verwendet werden kann, auch mit
object:postcode=*
(Und in Tags wie (beispielsweise)
object:full=Ausfahrt Rewe-Parkplatz an der Berliner Allee
color=yellow
sehe ich mehr Enduser-Potential als im DHL-Wikipedia-Link)
