Ich bin kein DWG-Mitglied und strebe eine Mitgliedschaft auch nicht an (Das steht seit ein paar Monaten auch auf der Profilseite von Nakaner-repair und jetzt auch auf der Profilseite des Benutzerkontos Nakaner). Es steht mir jedoch frei, Sperren anzudrohen, wenn sie angemessen sind und man davon ausgeht, dass die Sperre auch verhängt werden wird, wenn darum gebeten wird. (Mein erster Sperrantrag liegt mittlerweile circa fünf Jahr zurück. Ich denke, dass ich recht gut abschätzen kann, welche Anträge durchgehen und welche abgelehnt werden)
Die Nichtteilnahme an einer Diskussion ist ein Grund für eine vorübergehende Benutzerkontensperre. GER17 wurde am 17. Juli gebeten, seine Änderungen zu diskutieren. Der Bitte wurde nicht nachgekommen. Stattdessen hat er versucht, seine Löschungen von label-Nodes und admin_centre-Nodes an Verwaltungsgrenzrelationen schönzureden. woodpeck hat daraufhin eine dreitägige Sperre verhängt (ich hatte nur um 0 Stunden gebeten), diese aber vorzeitig aufgehoben, damit GER17 sich überhaupt im Forum einloggen kann.
Am 4. August fuhr er mit seinen Änderungen wieder fort und ergänzte weitere Kfz-Kennzeichen an Kreisgrenzen. Er wurde von streckenkundler und geri-oc nochmals an diesen Diskussionfaden hier im Forum erinnert.
Ich habe keine Antwort von ihm hier seitdem gesehen. Stattdessen hat er seine Arbeit gestern Abend fortgesetzt.
Gegen die Kfz-Kennzeichen wurde berechtigte Kritik vorgebracht, gegen die er nichts erwidert hat.
seichter hat auf die wieder eingeführte Vergabe alter Kennzeichen hingewiesen. Man müsse einen neuen Grenzrelationstype einführen. Der erforderliche Aufwand der Pflege sei nicht angemessen.
Chensi (keine Kritik) hat auf Wikidata hingewiesen
Ich habe es abgelehnt, weil es die Boundarietis fördert.
Die Frage nach der Quelle ist AFAIR nicht beantwortet worden.
OSM ist ein Gemeinschaftsprojekt. Alleingänge schaden der Community. Dass er die Haltung “ach was soll das Zeug da, ich lösch das” bislang noch nicht abgelegt hat, lässt Zweifel aufkommen, ob er den Ernst der Lage begriffen hat.
Anders als in der Wikipedia, sind bei OSM sind viele Regeln nicht geschrieben, sondern ergeben sich im Laufe der Zeit durch Anwendung.
Sehe ich eigentlich nicht so. Denn meines Wissens kann ein solches “altes” Kennzeichen dann im ganzen “neuen” Kreis beantragt werden.
Was aber definitiv beachtet werden müsste: Zulassungsbezirke sind meistens Kreise, können aber davon abweichen: manchmal haben (wie bereits geschrieben wurde) kreisfreie Stadt und gleichnamiger Landkreis dasselbe Unterscheidungszeichen, manchmal gibt es (wie bei den Mittelstädten im Saarland, aber auch bei der Stadt Hanau) abweichende Unterscheidungszeichen, obwohl sich der Zulassungsbezirk innerhalb eines Landkreises befinden.
Von daher würde man eher hierfür einen neuen Grenztyp einführen. Da sich die entsprechenden Bereiche jedoch auch auf anderem Wege definieren ließen, sieht man davon ab, da es nicht gewünscht ist.
Warum? Ignorier sie halt für deine Zwecke. Du kannst sie auch vor dem Import in deine Datenbanken z.B. mit osmfilter wegfiltern, oder ein custom-Profil für osm2pgsql nehmen, in dem die gelöscht/nicht importiert werden.
Was willst du eigentlich tun, und wobei stören die dich da?
Nochmal konkret: Ich bin bis auf Weiteres ausdrücklich gegen die Löschung der Punkte aus den Relationen!
Ohne jetzt alles im Detail durchzulesen, 2 kurze Info’s dazu:
Ich stehe nicht auf seiner Seite, ich würde die KFZ-IDs on-the-ground erfassen (wie erwähnt) und sie vorerst nur an den nächstgelegenen place-node hängen. Dagegen dürfte nichts sprechen.
Ich stimme zu, dass sich die Verteilung der KFZ-IDs wegen dieser Umzugsgeschichte vermischen kann.
Mal eine Frage dazu: (fiktive Geschichte) Jemand zieht von HH nach B um, und belässt an seinem Anhängerwagen das HH Zeichen. Nach 2 Jahren verkauft er den Anhängerwagen. Der neue Eigentümer hat seinen Wohnsitz auch in Berlin (B). Bekommt dann der Anhängerwagen nach dem Verkauf ein B Schild oder verbleibt am Anhängerwagen immer noch ein HH Schild?
Ich habe jetzt nur kurz den ersten node: 2666413593 angeschaut, welcher sich in Relation https://www.openstreetmap.org/relation/62681 befindet. Ja, eine Löschung würde mich sehr stören. Bitte lese Dir mal dazu folgenden Thread durch: http://gis.19327.n8.nabble.com/Relation-boundary-td5919377.html
Und im speziellen die zweite Antwort von Sarah mit dem Beispiel von Bayern: http://gis.19327.n8.nabble.com/Relation-boundary-td5919377.html#a5919427
Von daher vergebe dem node-2666413593 lieber sinnvolle Eigenschaften. Welche das sind/wären können wir hier oder wo anderes gerne besprechen, gibt es Vorschläge?
Von mir aus darf jede administrative Grenzrelation (auch in den unteren Ebenen / also höhere Zahl des admin_level) Knoten (Nodes) für label und admin_centre in entsprechender Relation besitzen.
Also wie oben im Beispiel für obere Admin-G. z.B. Bayern dieses Schema einfach analog dazu auf die unteren administrativen Grenzrelationen anwenden.
Zur Auswertung von role=admin_centre oder role=label : Auch mkgmap verwendet das, um Labels in Garmin Karten dort zu positionieren.
Mir fällt auch kein Grund ein, warum man solche Nodes löschen sollte.
Nur sind eben diese Punkte noch nicht so häufig in den Grenzrelationen als label aufgenommen, kann ja noch kommen
Nebenbei, von mir aus darf dann gleich eine Reduzierung der redundanten (botmässig eingetragen) openGeoDB-Eigenschaften vorgenommen werden… Oder gibt es auch einen „Lösch-Bot“ für die openGeoDB-Merkmale?
Technisch hast du natürlich recht, das würde klare Verhältnisse schaffen.
ABER:
Wir haben in OSM schon viel zu viele Grenzen, deren Sinn sich nicht jedem auftut, wofür keine Anwendung/Karte bekannt ist und deren unvollständige Daten sowieso nur solange gepflegt werden, bis der “Verursacher” als “Einzelkämpfer” die Lust daran verliert.
@Nakaner: bitte walte deines nicht vorhandenen amtes: Node 311118422 hat er heute mal wieder gelöscht… und KFZ Kennzeichen trägt er gerade im Moment auch wieder ein.
Was meinst du mit “mich stören die”? Es ist durchaus üblich, diejenigen Daten zu ignorieren, die nicht benötigt werden. Dazu gibt es diverse Programme, die filtern können. Löschen - zumindest ohne vorherige Nachfrage - geht überhaupt nicht. Das ist ein absolutes Nogo bei OSM.
Wenn du uns sagst, wobei dich diese Nodes stören, kann man dir evtl weiterhelfen.
Und dass uns “deine” Daten auch stören, kommt dir wohl nicht in den Sinn.
Mir sind z.B. Grenzen in Grönland - speziel Thule - zu Zeit sehr wichtig, obwohl ich im Taunus wohne. Und da du ja gerade eine Bundesweite Aktion durchziehst, ist mit Verlaub deine Anmerkung ziemlich unpassend.
Wir schlagen der DWG schon mal vor, dass ein unkooperativer Mapper angesprochen werden sollte (genau das hat nakaner getan), aber die Entscheidung, eine Sperre zu verhängen, liegt nicht bei ihm.
Klaro, “androhen” könntest du jederzeit und du könntest dich auch an die DWG wenden, aber du wirst dort keinen Erfolg haben.
Ob du “unglaubliches Wissen über KFZ-Kennzeichen” hast oder nicht, spielt gar keine Rolle - dein Verhalten, das du von Anfang an an den Tag legst, zeigt, du hast das System OSM nicht verstanden.
Zum Thema Respekt zeigen: Du respektierst anderer Leute Arbeit nicht und wirfst anderen mangelnden Respekt vor? Junge, Junge…
Also, es mag ja Autisten/Inselbegabte geben, welche in der Tat in gewissen Bereichen ein sehr gutes Wissen haben … aber nur habe ich bis jetzt noch keinen kennengelernt, welcher mit seinem Wissen prahlen würde.
Was an deinem Wissen ist denn soo umglaublich, das man es nicht jetzt schon bei Wikipedia bzw. Wikidata nachsehen könnte?
… und du bitte etwas vor der Gemeinschaft. Wenn du etwas in deiner Heimatgemeinde veränderst, wird sicher keiner etwas dagegen haben, wenn es kein Fehler ist. Wenn du aber länderübergreifend Änderungen machen willst, solltest du schon Gemeinschaftsregeln beachten.
Du kannst dir auch eine eigene Karte mit deinen Wissen um KFZ-Kennzeichen bauen.
Ich möchte kurz auf die label-node Löschungen eingehen, das ist zwar leicht Offtopic (bzgl KFZ…), aber es hat ja zur 2. Sperrung geführt und es gab immerhin hier im KFZ Thread die Bekanntmachung der Löschung, siehe folgende Mitteilung.
