Ortsangaben ausmisten (openGeoDB)

EvanE · 2012-07-06T13:23:17.000Z

efred:

bin dafür, dass die openGeoDB-Tags entfernt werden. Diese sind für OSM recht sinnlos.
Was man aber vielleicht stattdessen machen könnte, wäre einen tag erstellen, auf den jeweiligen Eintrag bei openGeoDB… also z.b.
openGeoDB:website=http://fa-technik.adfc.de/code/opengeodb.pl?locid=17644;c=DE
Falls jemand irgendwelche Auswertungen machen möchte, kann man somit jederzeit eine Verknüpfung der OSM-Daten mit den openGeoDB machen und die Daten direkt dort abfragen.

Meiner Meinung nach würde das openGeoDB:loc_id=17644 reichen, um eine Verknüpfung mit der openGeoDB herstellen zu können. Irgendeines der openGeoDB:* Tags sollte man meiner Meinung nach auch behalten, um klar zu machen, dass die Information ursprünglich aus der openGeoDB stammt.

Wenn man schon einmal dabei ist, den Knoten zu ändern, sollte man auch überlegen einen Link zur passenden Wikipedia-Seite und/oder OSM-Wiki-Seite zu ergänzen.

Edbert (EvanE)

efred · 2012-07-06T13:33:37.000Z

Oli-Wan:

Sofern überhaupt eine solche Verknüpfung bleiben soll, dann lieber openGeoDB:loc_id

stimmt auch wieder. das reicht völlig.
somit bin auch ich dafür, dass man die openGeoDB-Tags löscht, ausser den openGeoDB:loc_id=*

fkv · 2012-07-06T13:43:31.000Z

efred:

bin dafür, dass die openGeoDB-Tags entfernt werden. Diese sind für OSM recht sinnlos.

Wenn Tags wie opengeodb:population=* automatisch aktualisiert werden, können sie für Mapper eine Hilfe sein und die Werte ggf. manuell in die entsprechenden “Echt”-Tags übernommen werden. Aber die meisten opengeodb-Tags sind nutzlos, das ist auch meine Meinung.

EvanE:

Irgendeines der openGeoDB:* Tags sollte man meiner Meinung nach auch behalten, um klar zu machen, dass die Information ursprünglich aus der openGeoDB stammt.

Dafür gibt es source=* bzw. source:=*. Wobei ich beides als unnötige Belastung empfinde, weil bei jeder Änderung der entsprechende source-Tag angepasst werden muss. In der History sieht man eh, welche Infos vom Opengeodb-Bot kommen.

Oli-Wan · 2012-07-06T13:53:53.000Z

fkv:

efred:

bin dafür, dass die openGeoDB-Tags entfernt werden. Diese sind für OSM recht sinnlos.

Wenn Tags wie opengeodb:population=* automatisch aktualisiert werden, können sie für Mapper eine Hilfe sein und die Werte ggf. manuell in die entsprechenden “Echt”-Tags übernommen werden.

Nun ja, wenn. Das war ja (wie bei anderen Importen auch) ursprünglich wohl mal vorgesehen, ist dann aber (wie bei anderen Importen auch) tatsächlich nie geschehen. Aber eigentlich reicht es auch, wenn Daten in openGeoDB aktualisiert werden und in OSM die openGeoDB:loc_id verbleibt. Dann kann man gezielt in der openGeoDB nachsehen, ob dort neuere Daten liegen, und diese ggf. übernehmen. (Wobei ich damit auch vorsichtig wäre - wer weiß, aus welcher Quelle deren Daten stammen.) Der wenig versierte Gelegenheitsmapper wird zwar diese openGeoDB-Abfrage nicht machen - aber derselbe Mapper wird auch nicht erkennen (können), ob er z.B. ein automatisch aktualisiertes openGeoDB:population nun in population übernehmen kann/soll oder nicht.

r-michael · 2012-07-06T14:27:33.000Z

Wozu überhaupt noch irgendwelche hinweisende Tags zur openGeoDB belassen?
Zum einen ist die openGeoDB, wie ich schon erwähnte, sowieso nur für ganze 5 Länder zuständig und zum anderen wird sie nur recht stiefmütterlich gepflegt.
Wenn ich z.B. die Einwohnerzahl auf den aktuellesten Stand bringen möchte, so tue ich dies direkt in OSM und gehe nicht erst noch jedesmal den Umweg über openGeoDB, zumal ein automatisches Update dieser Daten in OSM sowieso ausbleibt.
Wem nutzen die Daten in der openGeoDB alleine sowieso etwas; ist das Ganze nicht vielmehr ein Relikt aus grauer Vorzeit?

Für mich stünde jetzt nur noch in Frage die Einsetzbarkeit von Tags wie z.B.
car_license_plate=* und phone_area_code=* denn dies war nur ein Vorschlag meinerseits da ich nichts Vergleichbares im Wiki fand.

Oli-Wan · 2012-07-06T14:34:34.000Z

r-michael:

car_license_plate=* und phone_area_code=* denn dies war nur ein Vorschlag meinerseits da ich nichts Vergleichbares im Wiki fand.

license_plate_code: 159 Verwendungen laut Taginfo (159 mehr als car_license_plate und etwa 1/100 von openGeoDB:license_plate_code)
telephone_area_code: 182 Verwendungen laut Taginfo; alle “Alternativen” (die teils wie C-Makros anmuten) stammen aus Importen wie openGeoDB.

okilimu · 2012-07-06T15:06:18.000Z

Bitte vorerst den Key

openGeoDB:community_identification_number

unbedigt noch belassen. Darin ist der amtliche Gemeindeschlüssel (heute [1] oder noch neuer [2]) gepflegt und von mir auch aktualisiert worden, wo notwendig und in der Straßenlistenauswertung erforderlich.

Wenn ein Bot da etwas entfernen sollte, dann bitte den Wert des o.g. Keys in de:amtlicher_gemeindeschluessel überführen, wenn nicht vorhanden.

Grüße

Dietmar

[1] http://wiki.openstreetmap.org/wiki/DE:Amtlicher_Gemeindeschl%C3%BCssel
[2] http://wiki.openstreetmap.org/wiki/DE:Key:de:regionalschluessel

r-michael · 2012-07-06T15:19:00.000Z

Eventuell müsste sowieso mal Jemand das Wiki bezüglich der notwendigen Tags ergänzen.
Wenn ich z.B. mal unter http://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dcity schaue, so ist bezüglich Postleitzahl, KFZ-Kennzeichen, Telefonvorwahl und Gemeindeschlüssel nichts zu finden.
Nun gut, ein Gemeindeschlüssel ist wohl nicht international, aber eventuell gibt’s etwas Äquivalentes.
Es wäre schon recht hilfreich, besonders für Neulinge, wenn man solch einer Wiki-Seite gleich diese Angaben entnehmen könnte.

wambacher · 2012-07-06T15:45:21.000Z

war opengeodb denn nicht schon mal tot?
Ich hatte die schon “abgeschrieben”. scheint ja wieder reaninmiert worden zu sein. http://opengeodb.org/wiki/OpenGeoDB

Dabei könnte ich mir vorstellen, dass das ganze Projekt in OSM hätte aufgehen können - aber nu ist es wohl zu spät.

Gruss
walter

ach ja: dann raus damit bis auf das absolute Minimum.

Oli-Wan · 2012-07-06T15:54:39.000Z

wambacher:

war opengeodb denn nicht schon mal tot?

Das war anscheinend nur deren Wiki, nicht die openGeoDB selbst.
Aber 250 Änderungen in >4 Monaten http://fa-technik.adfc.de/code/opengeodb.pl?action=changes sind auch nicht gerade ein kräftiges Lebenszeichen. Also wohl nicht tot, aber zumindest komatös.

Harald_Hartmann · 2014-10-18T20:24:13.000Z

wambacher:

ach ja: dann raus damit bis auf das absolute Minimum.

Und was ist das absolute Minimum, wo ist das dokumentiert?
Und was müsste von den Daten jetzt nun als wikidata eingetragen werden?
Und was ist mit diesem “is_in” Angaben? Irgendwann hab ich mal was gelesen, finde es aber nicht mehr, dass das auch totaler Quatsch ist/sein soll.
Und ist opengeodb in OSM nun wirklich tot? Wenn ja, warum ist dann im Wikieintrag OpenGeoDB kein “deprecated” Hinweis?
Ach und so ganz nebenbei kann man doch mittlerweile diese Place-Nodes komplett löschen, zumindest lese ich das aus den Antworten zu Beselich: Name der Gemeinde wird nicht angezeigt … wenn denn das mit dem Anzeigen eben nicht wäre.

Ich bin schon wieder total konfus

Hier mein aktuelles Beispiel: Auengrund … saucool ist v.a. die Vergabe von place=town für eine Gemeinde

aighes · 2014-10-18T20:42:57.000Z

Warum sollte man die Wiki-Seite depreacen? Neues Zueg wird zumindest hier nicht importiert und die Seite dient der Dokumentation des damaligen Imports. Weißt du, ob nicht in anderen Regionen der Welt evtl. die DB genutzt wird?

Zu is_in und den anderen in deinen Augen überflüssigen Tags: Was stört dich dran, dass die noch da sind? Du bzw. andere müssen sie ja nicht auswerten. Neu eintragen ist in gewissen Regionen sinnlos. Aber das bedeutet ja nicht, dass man die Einträge löschen muss. Andere könnten evtl. schon Interesse daran haben.

Prince_Kassad · 2014-10-18T20:46:37.000Z

Es ist nervig wenn man Ortsnamen korrigieren will, dass man dabei jedesmal auch noch die openGeoDB-Daten anpassen muss.

Harald_Hartmann · 2014-10-18T21:23:56.000Z

aighes:

Warum sollte man die Wiki-Seite depreacen?

Naja, weil die aktuelle Wiki-Seite zumindest in meinen Augen die Tatsache vermittelt sie wäre noch aktuell zu praktizierendes Tagging. Ob man sie jetzt (für Deutschland) deprecated oder in Vergangenheitsform schreibt, ist ja wieder eine andere Diskussion

aighes · 2014-10-19T04:45:03.000Z

Prince Kassad:

Es ist nervig wenn man Ortsnamen korrigieren will, dass man dabei jedesmal auch noch die openGeoDB-Daten anpassen muss.

Naja wenn es fehlerhaft ist würde ich das gesamte Tag-Paket der opengeoDB löschen.

aighes · 2014-10-19T04:48:29.000Z

Harald Hartmann:

aighes:

Warum sollte man die Wiki-Seite depreacen?

Naja, weil die aktuelle Wiki-Seite zumindest in meinen Augen die Tatsache vermittelt sie wäre noch aktuell zu praktizierendes Tagging. Ob man sie jetzt (für Deutschland) deprecated oder in Vergangenheitsform schreibt, ist ja wieder eine andere Diskussion

Es ist ja auch das, was aktuell praktiziert wird, wenn man Daten aus der opengeoDB importieren wollen würde.

Harald_Hartmann · 2014-10-19T09:33:07.000Z

aighes:

importieren wollen würde.

das ist mir zu schwammig und für mich hat es sich bisher so dargestellt, dass man das nicht wirklich will, sonst hätte man vermutlich nicht wikidata mit ins Boot geholt, was ja nun ähnliche und teils sogar dieselben Angaben aufführt wie OpenGeoDB

wambacher · 2014-10-19T10:06:59.000Z

Harald Hartmann:

aighes:

importieren wollen würde.

das ist mir zu schwammig und für mich hat es sich bisher so dargestellt, dass man das nicht wirklich will, sonst hätte man vermutlich nicht wikidata mit ins Boot geholt, was ja nun ähnliche und teils sogar dieselben Angaben aufführt wie OpenGeoDB

Soweit ich das noch in Erinnerung habe, haben wir GeoData für tot erklärt und können die Daten ruhig rausnehmen. Nur ein pauschales Löschen wurde abgelehnt.

Daher werfe ich die Geo-Tags immer dann raus, wenn ich eh was an den Daten ändere.

Gruss
walter

PowerStat · 2014-10-23T08:45:37.000Z

Hallo,
als Neuling und eher Anwender dieser Daten möchte ich sagen, daß ich es schade Finde, das diese Daten für tot erklärt wurden.
Ich persönlich würde mir wünschen, daß diese Daten in einem eigenen Layern quasi als extra Dateien bereitgestellt werden, da Daten wie PLZ, KfZ und Vorwahlen sehr gut für die Visualisierung geeignet sind und für viele Menschen auch hilfreich sein können.

Viele Grüße

PowerStat

PowerStat · 2014-10-23T08:47:39.000Z

Sorry noch ein Nachtrag:

insbesondere Adressen von Geschäften etc. sollten in ein extra Layer (Datei) ausgelagert werden, da sich hier gerade in Zeiten der Wirtschaftskrise doch sehr schnell Änderungen ergeben gegenüber den reinen Geostrukturen (Strassen etc.).