OpenGeoDB

From OpenStreetMap Wiki
Jump to navigation Jump to search

broom

This article or section may contain out-of-date information: The project appears to be dead[1], though the data is apparently still available on GitHub or GitLab
If you know about the current state of affairs, please help keep everyone informed by updating this information. (Discussion)

OpenGeoDB is an open source database which was started for Central Europe (Germany, Austria, Switzerland, Liechtenstein, Belgium, more to come). It contains hierarchical structures, postal codes, inhabitants, area etc. OpenGeoDB data is used together with lists of road names in order to verify the OSM level of completeness.

import bot

The user OpenGeoDB is a bot user, used by the opengeodb2osm.pl script, to import this information to OSM. It was created and started by User:Sven Anders in January 2008. Due to a number of problems with the import, it is unclear if there will any future updates from OpenGeoDB.

OpenGeoDBImport.png

OSM / opengeodb data structure

OpenGeoDB takes use of the SQL format for data exchange. This data is structured as

OpenGeoDB Key OSM Key example
loc_id openGeoDB:loc_id=* 13893
500100000 name Bad Dürkheim an der Weinstraße
500100002 openGeoDB:sort_name=* BADDUERKHEIM
400100000 openGeoDB:is_in_loc_id=* 434
400200000 openGeoDB:layer=* 6
400300000 openGeoDB:type=* Stadt
500300000 openGeoDB:postal_codes=* 67098
500600000 openGeoDB:community_identification_number=* 07332002
500100003 openGeoDB:ISO-3166-2 ‘‘n.a.‘‘
500500000 openGeoDB:license_plate_code=* DÜW
500400000 openGeoDB:telephone_area_code=* 06322
600700000 population and
openGeoDB:population=*
18830
200100000/lat openGeoDB:lat 49.46860
200100000/lon openGeoDB:lon 8.16639
derived from 400100000 is_in and
openGeoDB:is_in=*
...
derived from 100*00000 openGeoDB:location=* town
openGeoDB:version=*
openGeoDB:auto_update=*

data source

The homepage of opengeodb is http://opengeodb.org. Apart of further documentation, wiki or mailing list this will provide the GeoClassPHP.

Dumps of the data are released at sourceforge on occasions.

Data can be edited any time via a basic wiki user interface on http://fa-technik.adfc.de/code/opengeodb.pl. Any changes there are undoable. Data is always available for direct download in text format, while dumps are created whenever needed.

hierarchical data

Political Structures in the states may be organized in different levels. In Germany these may be:

  • federal state (Bundesland), openGeoDB:layer=3, openGeoDB:community_identification_number=two digits
  • county? (Regierungsbezirk), openGeoDB:layer=4, openGeoDB:community_identification_number=three digits
  • district? (Kreis: Landkreis, kreisfreie Stadt), openGeoDB:layer=4, openGeoDB:community_identification_number=five digits
  • community? (Gemeinde), openGeoDB:layer=5, openGeoDB:community_identification_number=eight digits
  • place? (Ort), openGeoDB:layer=6
  • ... (Stadtteil), openGeoDB:layer=7

This means that a town may appear several times on different layers. Example: The "town state" of "Hamburg" is both one of the 16 German federal states, it is a district with the licence car plate "HH" and for consistency a community. Thus it is given with the according community identification numbers (Amtlicher Gemeindeschlüssel, AGS) 02, 02000 and 02000000.

Data can be inherited from the level above via an is_in relation from the current loc_id to its parent's loc_id.

openGeoDB:auto_update

A special field is openGeoDB:auto_update. This can be changed by the user to: population', place, name, is_in, any combination of these or NONE.

Each field which is named within the openGeoDB:auto_update may be overwritten automatically be the next bot's update.

The bot must not overwrite any other field, except of created_by and any field with the openGeoDB: prefix. If the bot finds an existing place, it will append missing data.

If you observe a place where this went wrong, please report it as a bug to the author!

If a place is created by the bot, the openGeoDB:auto_update is set to population,place,name,is_in.

FAQ

What is OpenGeoDB

Q: What is OpenGeoDB?

A: OpenGeoDB is a database which contains various data such as hierarchies, postal code, community numbers, car license plate codes, inhabitants, area etc. It is Public Domain. Thus it is not permitted by OSM license to feed back data into OpenGeoDB.

What area does OpenGeoDB cover

Q: What area does OpenGeoDB cover?

A:

  • Germany,
  • Belgium,
  • Liechtenstein,
  • Austria and
  • Switzerland.

Is there a website with more information about OpenGeoDB

Q: Is there a website with more information about OpenGeoDB?

A: Yes, the OpenGeoDB wiki (in German language).

The city of ... now exists twice

Q: The city of ... now exists twice, but it shall only exists once. How do I fix this?

A: This happens often, when the two comuinty areas are Named the same. Example: In Hamburg there is a Bezirk (District) named "Harburg", and also a suborb of the district is named "Harburg". Please delete the place tag of one of the nodes. You can also delete the name tag. Then change the openGeoDB:auto_update to the "openGeoDB:NONE" value. You can delete everything, but please leave the openGeoDB:loc_id and the openGeoDB:auto_update.

A2: Hamburg is not only the city which you might expect. It got both the status of a federal state (Bundesland), the status of a town (kreisfreie Stadt: "Freie und Hansestadt Hamburg"), it is the capital of the Bundesland Hamburg, it is a community etc. opengeodb names all of these relevant political structures (Bundesland, Kreis, Gemeinde), although some of them are more or less virtual entries. It's still unclear whether you should ignore or delete them. Best choice for display might depend on the zoom level of your map.

The place is at a wrong lat/lon

Q: The place is at a wrong lat/lon, how do i correct this?

A: Please move the point to the new loaction. You can also correct this in OpenGeoDB (see above), but as long as you leave the openGeoDB:loc_id intact, a new import should go right.

The name has a addition in OpenGeoDB, but this should not be displayed on the Map

Q: The name has a addition in OpenGeoDB, but this should not be displayed on the Map

A: Please change the name tag to the right value (in OpenStreetMap). You must also remove name from the openGeoDB:auto_update. If afterwards the openGeoDB:auto_update is empty, you should set it to: openGeoDB:NONE Do not change the value in OpenGeoDB. The long version is the correct OpenGeoDB entry for this field

Correct data in OpenGeoDB

Q: There are some data wrong in OpenGeoDB, where can I correct it?

A: Go to: http://fa-technik.adfc.de/code/opengeodb.pl and change the data directly.

There is a question, which is not answered here

Q: There is a question, which is not answered here

A: Put it on this Wiki-Page, User:Sven Anders will try to answer it soon.

German FAQ

Ein Ort existiert zweimal auf der Karte

F: Ein Ort existiert zweimal auf der Landkarte, obwohl es ihn nur einmal gibt. Wie kann ich das ändern?

A: Dies passiert manchmal, weil zwei Verwaltungs-Gliederungen gleich benannt sind. In Hamburg gibt es zum Beispiel einen Bezirk Harburg und einen Stadtteil Harburg. Man kann einfach einen der zwei Punkte soweit abspecken, dass von ihn nichts mehr übrig bleibt: das Place-Tag löschen. Auch das Name-Tag kann gelöscht werden. Wichtig ist es, das openGeoDB:auto_update-Tag anzupassen, z.B. indem man es auf "openGeoDB:NONE" setzt. Wichtig: openGeoDB:loc_id und openGeoDB:auto_update an dem Node lassen.

Der Ort ist an einer falschen Stelle

F: Der Ort ist an einer falschen Stelle, wie korrigiere ich das?

A: Verschiebe einfach den Ort an die richtige Stelle. Schön wäre, wenn du es in OpenGeoDB auch korrigierst (die Lizenzbedinungen verbieten es uns, das automatisch zu machen) wie das geht, steht auch in dieser FAQ. Wichtig ist, dass der Ort an der neuen Stelle die gleiche openGeoDB:loc_id hat.

Der Name hat einen Zusatz, der aber nicht in OpenStreetMap angezeigt werden soll

F: Der Name hat einen Zusatz, der aber nicht in OpenStreetMap angezeigt werden soll

A: Bitte passe den Namen entsprechend in OpenStreetMap an. Außerdem musst du den Wert: "name" aus dem openGeoDB:auto_update entfernen. Wenn das Tag dann leer wäre, setze es bitte auf: openGeoDB:NONE. In OpenGeoDB sollte der Name nur geändert werden, wenn er wirklich falsch geschrieben ist. Dort wird die lang-Version bevorzugt um Orte besser unterscheiden zu können.

Sollen Punkte oder Flächen für Orte verwendet werden?

F: Soll der Ort als Punkt (Zentrum oder Verwaltungsgebäude?) oder als Fläche (Ortsgrenze oder Gemeinde?) eingegeben werden? Wirkt sich dies auch auf die Suche aus, das POI in Orten und nicht in der nähe von Orten gefunden werden?

A: OpenGeoDB unterstuetzt bisher erst die Eingabe von Punkten. Flaechen ergeben sich implizit durch Hierarchien und die Koordinaten der darin enthaltenen Eintraege - z.B. Deutschland (eine Koordinate) -> Bundeslaender (16) -> Regierungsbezirke -> Kreise -> Gemeinden -> Ortsteile -> Strassen -> Haeuser...

Zusammengelegte Orte

F: Wie sind verwaltungstechnisch zusammengelegt Orte zu handhaben?

Beispiel: Hier in der Gegend wurden Dörfer zu Gemeinden zusammengelegt und tragen in der OpengeoDB einen Doppelnamen (Schmogrow-Fehrow oder Dissen-Striesow). Das sind aber weiterhin deutlich getrennte Orte bzw. (verwaltungstechnisch) Ortsteile, die auch in der Karte so auftauchen sollten. Beim Beispiel Schmogrow-Fehrow liegt der OpengeoDB-Eintrag mittig zwischen den beiden Orten im "Nichts", verwirrt also mehr als er hilft.

Soll der OpengeoDB-Eintrag einem der Orte zugeordnet werden und reicht es ansonsten die Werte so zu ändern wie bei Namen mit unerwünschtem Zusatz? --Lobelt 12:52, 20 January 2008 (UTC)

A: Wenn du das so machst, also einen Ort dem zuschlägst und dafür sorgst (name aus auto_update entfernen) das der Name nicht mehr überschrieben wird, hat das ja andere folgen (z.B. stimmt die Bevölkerungszahl nicht mehr...), deshalb würde ich alle OSM Tags (die ohne das Pefix: OpenGeoDB:) entfernen und dann bei openGeoDB:auto_update den Wert: OpenGeoDB:NONE einstellen. Den Ort würde ich dort lassen, er sollte ja nicht stören (=gerendet werden). OpenGeoDB wächst ja auch noch, deshalb werden die einzel Orte evtl. auch irgendwann in OpenGeoDB aufgenommen und bekommen dann eine eigene loc_id.

Daten in OpenGeoDB korrigieren

F: Da sind Daten in OpenGeoDB falsch. Wie korrigiere ich sie?

A: Gehe zu http://fa-technik.adfc.de/code/opengeodb.pl, suche dort nach dem Ort, klicke auf den Namen und ändere die Daten. Bei Löschungen kann eine Anmeldung erforderlich sein.

Ort wird nicht importiert

F: Was kann ich tun, wenn ein Ort gar nicht aus OpenGeoDB in OpenStreetMap importiert wird?

Beispiel: Der place=town-Node von Wittlich enthält keine OpenGeoDB-Daten, ein Eintrag in OpenGeoDB exisitiert aber.

A: Die Updates mit OpenGeoDB sind sehr kompliziert, und es gab bereits beim ersten Import diverse Probleme. Deshalb findet kein Update statt (wenn sich jemand berufen fühlt, kann er sich an mich wenden). Lege den Ort einfach von Hand an. Sven Anders 06:57, 29 May 2009 (UTC)

Meine Frage wurde hier nicht beantwortet

F: Meine Frage wurde hier nicht beantwortet

A: Schreibe sie einfach hier dazu! User:Sven Anders wird sie hoffentlich bald beantworten.

Example Data

Header:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.5' generator='opengeodb2osm'>

A node will be inserted when there are lon and lat information in OpenGeoDB. If there is a node in OSM with a place tag and the same name as in OpenGeoDB, it will be extended:

<node id="34587339" visible="true" lat="48.5277377" lon="9.8086712" action="modify"  timestamp="JuergenL">
<tag k="openGeoDB:loc_id" v="1" />
<tag k="opengeodb:lat" v="48.5277377" />
<tag k="opengeodb:lon" v="9.8086712" />
   <tag k="name" v="Aichen"/>
   <tag k="place" v="hamlet"/>
<tag k="openGeoDB:sort_name" v="AICHEN" />
<tag k="openGeoDB:postal_codes" v="89191" />
<tag k="openGeoDB:license_plate_code" v="UL" />
<tag k="openGeoDB:name" v="Aichen" />
<tag k="openGeoDB:community_identification_number" v="08425084" />
<tag k="openGeoDB:is_in_loc_id" v="21328" />
<tag k="openGeoDB:combination_of_public_administration" v="Verwaltungsgemeinschaft Laichinger Alb" />
<tag k="openGeoDB:layer" v="9" />
<tag k="is_in" v="Nellingen (Alb),Alb-Donau-Kreis,TÃŒbingen,Baden-WÃŒrttemberg,Bundesrepublik Deutschland,Europe" />
<tag k="openGeoDB:is_in" v="Nellingen  (Alb),Alb-Donau-Kreis,TÃŒbingen,Baden-WÃŒrttemberg,Bundesrepublik Deutschland,Europe" />
<tag k="created_by" v="opengeodb2osm0.4.2" />
<tag k="openGeoDB:version" v="0.2.6.11 / 2007-12-04 /  http://fa-technik.adfc.de/code/opengeodb/dump/" />
<tag k="openGeoDB:auto_update" v="population,is_in" />
</node>
<node id="123803255" visible="true" lat="48.5419078" lon="9.8305004" action="modify"  timestamp="2007-11-29T08:49:12+00:00">
<tag k="openGeoDB:loc_id" v="2" />
<tag k="opengeodb:lat" v="48.5419078" />
<tag k="opengeodb:lon" v="9.8305004" />
   <tag k="name" v="Oppingen"/>
   <tag k="is_in" v="Nellingen,Alb-Donau-Kreis,Baden-WÃŒrttemberg,Deutschland"/>
   <tag k="place" v="village"/>
<tag k="openGeoDB:sort_name" v="OPPINGEN" />
<tag k="openGeoDB:postal_codes" v="89191" />
<tag k="openGeoDB:license_plate_code" v="UL" />
<tag k="openGeoDB:name" v="Oppingen" />
<tag k="openGeoDB:community_identification_number" v="08425084" />
<tag k="openGeoDB:combination_of_public_administration" v="Verwaltungsgemeinschaft Laichin ger Alb" />
<tag k="openGeoDB:is_in_loc_id" v="21328" />
<tag k="openGeoDB:layer" v="9" />
<tag k="openGeoDB:is_in" v="Nellingen (Alb),Alb-Donau-Kreis,TÃŒbingen,Baden-WÃŒrttemberg,Bundesrepublik Deutschland,Europe" />
<tag k="created_by" v="opengeodb2osm0.4.2" />
<tag k="openGeoDB:version" v="0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/" />
<tag k="openGeoDB:auto_update" v="population" />
</node>

A Relation is inserted if the OpenGeoDB data of this place has at least one children.

<relation id="-38775" visible='true'>
<tag k="openGeoDB:loc_id" v="110" />
<tag k="openGeoDB:sort_name" v="BADEN-WUERTTEMBERG" />
<tag k="openGeoDB:license_plate_code" v="BW" />
<tag k="name" v="Baden-WÃŒrttemberg" />
<tag k="openGeoDB:name" v="Baden-WÃŒrttemberg" />
<tag k="openGeoDB:type" v="Bundesland" />
<tag k="openGeoDB:community_identification_number" v="08" />
<tag k="openGeoDB:is_in_loc_id" v="105" />
<tag k="openGeoDB:layer" v="3" />
<tag k="is_in" v="Bundesrepublik Deutschland,Europe" />
<tag k="openGeoDB:is_in" v="Bundesrepublik Deutschland,Europe" />
<tag k="openGeoDB:location" v="state" />
<tag k="place" v="state" />
<tag k="created_by" v="opengeodb2osm0.4.2" />
<tag k="openGeoDB:version" v="0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/" />
<tag k="openGeoDB:auto_update" v="population,place,name,is_in" />
<member type='relation' ref="-38776" role='child' />
<member type='relation' ref="-38792" role='child' />
<member type='relation' ref="-38805" role='child' />
<member type='relation' ref="-38817" role='child' />
</relation>

More data can be found on:

http://svenanders.openstreetmap.de/opengeodb/

You can load the file into Josm and test it. !!But please do not upload it now!!

See also (More about opengeodb)

See also (osm opengeodb import)

Open Questions

  • Shall we import all information from OpenGeoDB to OSM? Or just a subset?
  • I`m not a native English speaker, so please correct the fields above if you find a better term for it. Sven Anders 14:36, 12 January 2008 (UTC)
    • Should it be: openGeoDB:license_plate_code or openGeoDB:car_plate_code
  • Shall there be a openGeoDB:name key in an entry, if it is the same as name?

Discussion

(moved to Talk:OpenGeoDB)