OpenGeoDB

Wetterauer · 2021-12-04 11:48:37

Beim Bearbeiten von Objektdaten bin ich auf folgendes gestoßen:

https://www.openstreetmap.org/edit?edit … 09/8.73702

is_in=Rockenberg,Wetteraukreis,Darmstadt,Hessen,Bundesrepublik Deutschland,Europe
name=Rockenberg
openGeoDB:auto_update=population
openGeoDB:community_identification_number=06440022
openGeoDB:is_in=Wetteraukreis (Hessen),Darmstadt,Hessen,Bundesrepublik Deutschland,Europe
openGeoDB:is_in_loc_id=297
openGeoDB:license_plate_code=FB
openGeoDB:loc_id=23168
openGeoDB:name=Rockenberg
openGeoDB:population=4091
openGeoDB:postal_codes=35519
openGeoDB:sort_name=ROCKENBERG
openGeoDB:telephone_area_code=06033
openGeoDB:type=Gemeinde
openGeoDB:version=0.2.6.11%20/%202007-12-04%20/%20http://fa-technik.adfc.de/code/opengeodb/dump/
opengeodb:lat=50.4301091
opengeodb:lon=8.7370993
place=town
population=4009

Die openGeoDB tags wurden 2012 vom "OSMF Redaction Account - Redaction bot" eingetragen.

Im Wiki ist darüber nicht viel zu finden
https://wiki.openstreetmap.org/wiki/OpenGeoData
https://wiki.openstreetmap.org/wiki/OpenGeoDB

Weiß jemand dazu etwas genaueres?
Gibt es diesen BOT noch?
Sind diese Einträge erhaltenswert oder sollten hier die üblichen "normalen" Einträge für Städte Tags eingetragen werden?

FraukeLeo · 2021-12-04 13:07:52

Was mich eher erstaunt sind solche Tags wie population=*. Geht irgend jemand nach jeder Aktualisierung der Einwohnerzahlen alle place-nodes durch und ändert das? Und wozu wurde Wikidata erfunden, wenn nicht dazu, dass man objektbezogene Informationen an einem Ort zentral sammelt und sie nur dort pflegen muss? (OpenGeoDB ist dann wohl eine ähnliche Einrichtung ...)

Edit: Was weg kann, ist is_in, seit jemandem mal aufgefallen ist, dass das eine geospatiale Datenbank selbst rausfinden kann, in was der Node is.

Last edited by FraukeLeo (2021-12-04 13:08:54)

Jo Cassel · 2021-12-04 13:39:56

@Wetterauer
Das Datenpaket enthält folgenden Subtext:

"Lieder Mapper, wenn Du diese veralteten Daten an einem place-node findest,
besteht meist Verbesserungsbedarf,
so solltest Du schauen, ob sich zum place-node eine passende Grezrelation findet:
https://www.openstreetmap.org/relation/446620
und sehen ob sich der place-node dort als "label" oder "admin_centre" einbinden lässt
[hier admin_centre weil Ort=Verwaltungssitz der Gemeinde]
danach solltest Du den ganzem Krempel löschen - und is_in=* gleich mit"

Würde ich aber nicht unbedingt mit ID machen...

@FraukeLeo
das population=* an place-nodes dient wohl auch dazu Verdrängungspropleme beim Rendern zu lösen. Ob das wo dokumentiert ist, kann ich nicht sagen, aber was dabei regelmäßig schiefläuft kann man hier gut sehen:
population=4009
ist ja wohl die Zahl für die ganze Gemeinde - das ist aber (inzwischen) der place-node des Ortes, Wikipedia: "OT Rockenberg zählt 2.297 Einwohner[...]"

SammysHP · 2021-12-04 21:27:05

Wetterauer wrote:

Die openGeoDB tags wurden 2012 vom "OSMF Redaction Account - Redaction bot" eingetragen.

Das ist so nicht ganz richtig. Der Bot ist lediglich der letzte sichtbare Bearbeiter, nachdem die Informationen hinzugefügt wurden. Bei der Lizenzumstellung damals (so lange ist das schon wieder her… wie schnell doch die Zeit vergeht) mussten viele Informationen aus der Datenbank entfernt werden und dann kam es zu solchen interessanten Situationen.

streckenkundler · 2021-12-04 21:56:06

Ich halte diesen ganzen opengeodb-Schrott für komplett entbehrlich...

Ich sehe da keinen opengeodb-Tag, der noch zu was nützt, in einen anderen Tag verschoben zu werden...

Wahllose Beispiele aus und fürs Land Brandenburg Abfrage: https://overpass-turbo.eu/s/1dLK:

openGeoDB:telephone_area_code=03361 ... Witzlos... letztendlich richtet sich das an den Zuschnitten der Telefonnetze, die im Grenzbereich mal abweichen können.
openGeoDB:license_plate_code=LOS ... Witzlos... da auch ältere Kennzeichenkürzel weiterhin gültig sind...
openGeoDB:combination_of_public_administration=Amt Wandlitz ... Witzlos, da per Admin-Relation abgebildet.
openGeoDB:population=5716 ... veraltet... kann für die administrative Einheit aus destatis entnehmen... daher am Node eh falsch...
openGeoDB:name=Dallgow-Döberitz vs. openGeoDB:sort_name=DALLGOW-DOEBERITZ Hä???
richtig schön: https://www.openstreetmap.org/node/240034661

Für mich sollte ein Bot alles was is_in=* und openGeoDB:*=* ist sang und klanglos eliminieren.

Alles was openGeoDB:*=* ist habe ich in meinem Hauptbereich Südbrandenburg bereits nach diversen Forenbeiträgen 2014 (!!) eliminiert...

Sven

FraukeLeo · 2021-12-04 23:25:40

streckenkundler wrote:

openGeoDB:name=Dallgow-Döberitz vs. openGeoDB:sort_name=DALLGOW-DOEBERITZ Hä???

sort_name gibt die alphabetische Sortierung an. Das passt schon so. Also rein logisch.

aighes · 2021-12-05 03:27:13

streckenkundler wrote:

Ich halte diesen ganzen opengeodb-Schrott für komplett entbehrlich...

Das mag mittlerweile so stimmen. Damals, als die Daten hinzugefügt wurden, war die OpenGeoDB in dieser Hinsicht aber deutlich weiter als OSM und man wusste nicht, welches Projekt sich wie entwickeln würde. Daher finde ich deine Wortwahl ein wenig daneben.

Die Daten wurden von uns(=OSM) nicht mehr gepflegt und sind daher obsolet und können entfernt werden. Man kann es aber auch als Aufgabe ansehen, zu schauen, wo diese Daten noch vorhanden sind und ob unsere Daten besser sind, so wie du ja auch schreibst.

dieterdreist · 2021-12-05 09:36:42

Jo Cassel wrote:

aber was dabei regelmäßig schiefläuft kann man hier gut sehen:
population=4009

genau, da ist viel Unschärfe, die Zahlen beziehen sich eigentlich immer auf administrative Objekte, sie sind aber oft an place nodes.
Andererseits ist das auch für viele Anwendungen gut genug, weil da nur Größenordnungen interessieren, und relative Größen

seichter · 2021-12-05 11:59:53

dieterdreist wrote:

Jo Cassel wrote:
aber was dabei regelmäßig schiefläuft kann man hier gut sehen:
population=4009
genau, da ist viel Unschärfe, die Zahlen beziehen sich eigentlich immer auf administrative Objekte, sie sind aber oft an place nodes.
Andererseits ist das auch für viele Anwendungen gut genug, weil da nur Größenordnungen interessieren, und relative Größen

Ohne Stichtag sind solche Zahlen auf Einzelpersonen herunter ziemlich sinnfrei.
Als Hilfe für die Priorisierung beim Rendern würde die Beschränkung auf k oder M genügen, also hier 4k.

Wenn es Zahlen für das admin-Objekt sind, gehören sie in die Relation.
An den place-node nur solche Tags, die sich allein auf das Objekt beziehen, für die der node steht.

Announcement

#1 2021-12-04 11:48:37

OpenGeoDB

#2 2021-12-04 13:07:52

Re: OpenGeoDB

#3 2021-12-04 13:39:56

Re: OpenGeoDB

#4 2021-12-04 21:27:05

Re: OpenGeoDB

#5 2021-12-04 21:56:06

Re: OpenGeoDB

#6 2021-12-04 23:25:40

Re: OpenGeoDB

#7 2021-12-05 03:27:13

Re: OpenGeoDB

#8 2021-12-05 09:36:42

Re: OpenGeoDB

#9 2021-12-05 11:59:53

Re: OpenGeoDB

Board footer