Ortsangaben ausmisten (openGeoDB)

r-michael · 2012-07-06 13:48:23

Sollte man denn nicht mal endlich diesen alten Müll aus den Ortsangaben entfernen bzw. ersetzen?
Wenn ich dort was von "auto_update" lese lache ich mich kaputt; das hat doch noch nie so richtig funktioniert.
Auch eine angegebene Jahreszahl der DB-Version mit 2007 sorgt nur für Gelächter.
Mein Vorschlag wäre: "raus mit dem Müll!"
Für viele Sachen gibt's neue Tags und Mancherlei könnte gar wegfallen.

Ich möchte mal versuchen das Ganze am Beispiel der Stadt Guben zu erläutern:

is_in=Spree-Neiße(Lausitz),Brandenburg,Bundesrepublik Deutschland,Europe
name=Guben
openGeoDB:auto_update=population,is_in
überflüssig, da Update nicht funktioniert
openGeoDB:community_identification_number=12071160
ersetzbar durch de:amtlicher_gemeindeschluessel=* (siehe http://wiki.openstreetmap.org/wiki/DE:A … %C3%BCssel )
openGeoDB:is_in=Spree-Neiße(Lausitz),Brandenburg,Bundesrepublik Deutschland,Europe
überflüssig, da bereits vorhanden
openGeoDB:is_in_loc_id=559
irrelevant
openGeoDB:layer=6
irrelevant
openGeoDB:license_plate_code=SPN
ersetzen z.B. durch car_license_plate=*
openGeoDB:loc_id=17644
irrelevant
openGeoDB:name=Guben
überflüssig, da bereits vorhanden
openGeoDB:population=21804
überflüssig, da bereits vorhanden
openGeoDB:postal_codes=03172
ersetzbar durch postal_code=* (siehe http://wiki.openstreetmap.org/wiki/Key:postal_code )
openGeoDB:sort_name=GUBEN
irrelevant
openGeoDB:telephone_area_code=03561
ersetzbar z.B. durch phone_area_code=*
openGeoDB:type=Stadt
überflüssig, da bereits in place=* vorhanden
openGeoDB:version=0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/
irrelevant
opengeodb:lat=51.9522244
irrelevant
opengeodb:lon=14.7147269
irrelevant
place=town
population=21804
wikipedia=Guben

Damit wäre auch die gesamte Wiki-Seite unter http://wiki.openstreetmap.org/wiki/OpenGeoDB überflüssig.
Die gesamte openGeoDB ist doch eigentlich sowieso nur für Deutschland, Österreich, Schweiz, Liechtenstein und Belgien relevant und hat international keinerlei Bedeutung.

Also weiter mitschleppen als Klotz am Bein oder mal renovieren ?

mfG Michael

efred · 2012-07-06 14:07:01

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.

Oli-Wan · 2012-07-06 14:19:53

efred wrote:

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.

Sofern überhaupt eine solche Verknüpfung bleiben soll, dann lieber openGeoDB:loc_id. Die Website-Angabe ist hinfällig, wenn z.B. openGeoDB irgendwann umzieht oder die Schnittstelle ändert. Aller übrige Krempel kann weg oder in reguläre OSM-Tags überführt werden, sofern sinnvoll. Aber das wird nur sehr bedingt automatisch funktionieren.

EvanE · 2012-07-06 14:23:17

efred wrote:

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-06 14:33:37

Oli-Wan wrote:

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-06 14:43:31

efred wrote:

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 wrote:

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:<tag>=*. 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-06 14:53:53

fkv wrote:

efred wrote:
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.

Last edited by Oli-Wan (2012-07-06 14:54:24)

r-michael · 2012-07-06 15:27:33

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-06 15:34:34

r-michael wrote:

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-06 16:06:18

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:A … %C3%BCssel
[2] http://wiki.openstreetmap.org/wiki/DE:K … schluessel

r-michael · 2012-07-06 16:19:00

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-06 16:45:21

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-06 16:54:39

wambacher wrote:

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/opengeod … on=changes sind auch nicht gerade ein kräftiges Lebenszeichen. Also wohl nicht tot, aber zumindest komatös.

Harald Hartmann · 2014-10-18 21:24:13

wambacher wrote:

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-18 21:42:57

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-18 21:46:37

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

Harald Hartmann · 2014-10-18 22:23:56

aighes wrote:

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-19 05:45:03

Prince Kassad wrote:

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-19 05:48:29

Harald Hartmann wrote:

aighes wrote:
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-19 10:33:07

aighes wrote:

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-19 11:06:59

Harald Hartmann wrote:

aighes wrote:
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-23 09:45:37

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-23 09:47:39

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.).

chris66 · 2014-10-23 10:12:53

Die openGeoDB an sich existiert ja noch.
Nur der Import der Daten nach OSM und anschließend kümmert sich keiner mehr drum, ist das was hier als Problem gesehen wird.

Ich empfehle also, dass Du dir die Daten direkt von OpenGeoDB ziehst.

chris66 · 2014-10-23 13:08:10

Ich wäre dafür diesen ungepflegten Mist endlich auszumisten.

Announcement

#1 2012-07-06 13:48:23

Ortsangaben ausmisten (openGeoDB)

#2 2012-07-06 14:07:01

Re: Ortsangaben ausmisten (openGeoDB)

#3 2012-07-06 14:19:53

Re: Ortsangaben ausmisten (openGeoDB)

#4 2012-07-06 14:23:17

Re: Ortsangaben ausmisten (openGeoDB)

#5 2012-07-06 14:33:37

Re: Ortsangaben ausmisten (openGeoDB)

#6 2012-07-06 14:43:31

Re: Ortsangaben ausmisten (openGeoDB)

#7 2012-07-06 14:53:53

Re: Ortsangaben ausmisten (openGeoDB)

#8 2012-07-06 15:27:33

Re: Ortsangaben ausmisten (openGeoDB)

#9 2012-07-06 15:34:34

Re: Ortsangaben ausmisten (openGeoDB)

#10 2012-07-06 16:06:18

Re: Ortsangaben ausmisten (openGeoDB)

#11 2012-07-06 16:19:00

Re: Ortsangaben ausmisten (openGeoDB)

#12 2012-07-06 16:45:21

Re: Ortsangaben ausmisten (openGeoDB)

#13 2012-07-06 16:54:39

Re: Ortsangaben ausmisten (openGeoDB)

#14 2014-10-18 21:24:13

Re: Ortsangaben ausmisten (openGeoDB)

#15 2014-10-18 21:42:57

Re: Ortsangaben ausmisten (openGeoDB)

#16 2014-10-18 21:46:37

Re: Ortsangaben ausmisten (openGeoDB)

#17 2014-10-18 22:23:56

Re: Ortsangaben ausmisten (openGeoDB)

#18 2014-10-19 05:45:03

Re: Ortsangaben ausmisten (openGeoDB)

#19 2014-10-19 05:48:29

Re: Ortsangaben ausmisten (openGeoDB)

#20 2014-10-19 10:33:07

Re: Ortsangaben ausmisten (openGeoDB)

#21 2014-10-19 11:06:59

Re: Ortsangaben ausmisten (openGeoDB)

#22 2014-10-23 09:45:37

Re: Ortsangaben ausmisten (openGeoDB)

#23 2014-10-23 09:47:39

Re: Ortsangaben ausmisten (openGeoDB)

#24 2014-10-23 10:12:53

Re: Ortsangaben ausmisten (openGeoDB)

#25 2014-10-23 13:08:10

Re: Ortsangaben ausmisten (openGeoDB)

Board footer