Wenn ich ein Objekt bearbeite, an dem noch Tags des offenbar toten Projekts OpenGeoDB sind, kann ich die einfach löschen oder gibt es die theoretische Möglichkeit, dass das noch jemand braucht?
Beispiel:
Seit dieser Diskussion im alten Forum:
OpenGeoDB / users: Germany / OpenStreetMap Forum
lösche ich konsequent alle OpenGeoDB-Tags, wenn ich ein Objekt sowieso wegen etwas anderem bearbeiten muss.
8 Likes
+1
Und wenn am Objekt auch noch is_in eingetragen ist, kann das gleich mit weg.
2 Likes
Vor dem Löschen aber nachsehen, ob nicht doch eine für OSM-Tags verwertbare Information vorhanden ist.
Wenn mit Bot, dann deshalb nur einzelne Tags, die definitiv nicht für OSM gebraucht werden wie Sortierbenennung in Großbuchstaben oder OpenGeoDB-interne Schlüssel.
Der Rest dürfte sehr überschaubar sein.
1 Like
Das kann ich mir allenfalls für population vorstellen (wobei die Bevölkerungszahlen auch schon über zehn Jahre alt sind). Alle anderen Informationen aus der OpenGeoDB sind bei uns entweder als Relation erfasst (administrative Gliederung, Gemeindekennziffer) oder wollen wir in OSM grundsätzlich nicht haben (Kfz-Kennzeichen, Telefonvorwahl).
Wieso wollen wir keine Telefonvorwahlen oder Kfz-Kennzeichen?
1 Like
Zu den Kfz-Kennzeichen hatten wir einen längeren Thread im alten Forum, der Tenor war einhellig “wollen wir nicht”: Ergänzung deutscher Kfz-Kennzeichen / users: Germany / OpenStreetMap Forum
Bei der Telefonvorwahl ist die Argumentation m. W. ähnlich. Zumal die Telefonvorwahl ohnehin an jedem POI mit Telefonnummer getaggt ist.
3 Likes
Zumal die Telefonvorwahl ohnehin an jedem POI mit Telefonnummer getaggt ist.
das ist ein guter Punkt
Ok, weg damit, habe meine HZ schon ein bisserl bereinigt.
Antworte hier nur, wenn:
- du zusätzliche Details hast.
- die Lösung für dich nicht funktioniert.
Wenn du ein anderes Problem hast, erstelle bitte stattdessen [ein neues Thema]
Da bin ich dagegen, Herr DiscoBot. 
@Nakaner
Was kam dabei heraus?
license_plate_code ist ja immer noch 790x getaggt.
openGeoDB:license_plate_code gibt es sogar 8510x .
Also is_in, als auch der opengeodb-Kram ist hier in Südbrandenburg sein Jahren raus…
- is_in für Brandenburg https://overpass-turbo.eu/s/1oxX
- opengeodb für Brandenburg (in verschiedenen Ausprägungen): https://overpass-turbo.eu/s/1oxY
Bevölkerungszahlen zu übernehmen ist wenig zielführend, da zum einen hoffnungslos veraltet und am Punktobjekt eh in der Regel falsch. Das gehört für mich nur an die zugehörige Admin-Relation. So sind auch diese statistischen Zahlen zu verstehen.
Telefonvorwahlen bringen auch nicht viel, denn da ist die Zuordnung meiner Ansicht nach ähnlich wie bei PLZ, vielleicht noch undurchsichtiger, gerade wenn Admin-Grenzen durch Siedlungsbereiche verlaufen, haben wir hier im Spreewald zur Genüge.
license_plate_code: für meinen Heimatkreis kam license_plate_code=LDS;KW;LC;LN z.B. mit https://www.openstreetmap.org/changeset/76416587 rein. eigentlich nicht wirklich gut auswertbar und ich sehe das als Datengrab.
Mit was ich mich allerdings anfreunden könnte, wäre ein Schlüssel, der die gängige Abkürzung eines Kreises benennt. für meinen Heimatkreis wäre das “LDS”. Da ist aber license_plate_code der falsche Schlüssel…
Sven
1 Like
zumal man inzwischen auch bei Umzug sein bisheriges Kennzeivhen behalten darf.
2 Likes
Da gab es einen noch älteren Thread:
FluxBB: Ortsangaben ausmisten (openGeoDB)
in dem wohl das Ergebnis war, dass die openGeoDB-Merkmale bis auf
openGeoDB:is_in_loc_id
openGeoDB:loc_id
entfernt werden können.
Und durch die ID’s der Zusammenhang über die Webseite
https://fa-technik.adfc.de/code/opengeodb.pl
hergestellt werden kann.
Da nun mittlerweile scheinbar
https://fa-technik.adfc.de/code/opengeodb.pl
den Dienst eingestellt hat, steht der vollständigen Löschung wohl nichts mehr im Wege.
2 Likes
Genau, das kommt nämlich hinzu, war im alten Beitragsfaden auch irgendwo angesprochen worden. Sven