Keine Standards in Administrativen Namen?

Communities Deutschland (Germany)
1

Hi, ist Overpass API nicht einfach nur ein Abfrage-Tool der OSM Datenbank? Die Sache ist absolut fein, doch scheint es entweder keine weltweit einheitlichen Standards zu geben oder Autonomie!

http://overpass-api.de/api/interpreter?data=[out:json];is_in(48.386824,9.064375);out;

6	
type	"area"
id	3602811874
tags	
TMC:cid_58:tabcd_1:Class	"Area"
TMC:cid_58:tabcd_1:LCLversion	"8.00"
TMC:cid_58:tabcd_1:LocationCode	"302"
admin_level	"5"
boundary	"administrative"
de:amtlicher_gemeindeschluessel	"084"
de:regionalschluessel	"084"
name	"Regierungsbezirk Tübingen"
type	"boundary"

Ergebnis für admin_level “5” name: “Regierungsbezirk Tübingen”

http://overpass-api.de/api/interpreter?data=[out:json];is_in(48.343030,12.041670);out;

7	
type	"area"
id	3602145274
tags	
TMC:cid_58:tabcd_1:Class	"Area"
TMC:cid_58:tabcd_1:LCLversion	"8.00"
TMC:cid_58:tabcd_1:LocationCode	"294"
admin_level	"5"
boundary	"administrative"
de:amtlicher_gemeindeschluessel	"091"
de:regionalschluessel	"091"
name	"Oberbayern"
name:prefix:de	"Regierungsbezirk"
short_name	"Obb"
type	"boundary"

Ergebnis für admin_level “5” name: “Oberbayern”

In BaWü ist das Prefix im Namen. In Bayern gibt es ein Prefix.

Bei den admin_levels mit höheren Zahlen wird es noch wilder. Da werden dann teilweise sogar Abkürzungen verwendet, und wenn ich mich recht erinnere, die sogar nach dem eigentlichen Namen bei name eingetragen sind.

http://overpass-api.de/api/interpreter?data=[out:json];is_in(48.532535,9.899336);out;

11	
type	"area"
id	3602951681
tags	
admin_level	"7"
boundary	"administrative"
de:regionalschluessel	"084255009"
name	"Gemeindeverwaltungsverband Lonsee-Amstetten"
type	"boundary"

http://overpass-api.de/api/interpreter?data=[out:json];is_in(48.050101,11.821944);out;

8	
type	"area"
id	3602984857
tags	
admin_level	"7"
boundary	"administrative"
de:regionalschluessel	"091755114"
description:de	"Verwaltungsgemeinschaft Glonn"
name	"Glonn (VGem)"
type	"boundary"

Keine Prefix verwendet, stattdesse sogar Abkürzung hinter den Namen bei name und in Klammern…

Wo ist das Problem? Wenn man aus den Daten ganze Sätze bilden will, die per if else geregelt werden. So ist das aber eine schier unendliche Angelegenheit alle Möglichkeiten abzudecken. Dann lass es halt? Ja, so sieht das Ergebnis aus: unbrauchbar. Zuviel Aufwand, weil Chaos in der Datenbank. Standards sind was feines. Ohne wirds ein Datendump.

Ob das jemals einer aufräumt? Könnte evtl. ein Bot machen.

2

Hallo,

das ist kein Problem der Overpass-API. Die Overpass-API ist nur eine lesende Schnittstelle für den Zugriff auf OSM-Rohdaten. Ich möchte dich daher bitten, den Betreff zu korrigieren.

Viele Grüße

Michael

3

Na, ich tippe mal auf https://de.wikipedia.org/wiki/F%C3%B6deralismus_in_Deutschland
statt overpass API

4

@lorissa: ich denke mal, da kann wambacher auch ein Liedchen von singen, war erst neulich wieder so eine Diskussion (und ich glaube wambacher hatte dazu sogar eine Liste gemacht), finde sie leider gerade nicht… letztendlich handelt es sich hier eher um “Datenmüll” (mal man sich in vielerlei Hinsicht eben nicht einig ist, wie man was in welchen Schreibweisen erfasst, etc.), auch wenn die Grenzen bzw. Grenzverläufe an sich mittlerweile ganz gut sind.

Nachtrag: Daher wie in #3 schon geschrieben, sollte der Thread besser “Keine Standards in Administrativen Namen?” umbenannt werden.

5

Das ist ein altbekanntes Problem, intensiv auch schon diskutiert in Zusammenhang mit OSMsuspects! und den addr:city-Namen.

Das ist nicht mal unbedingt allein ein Problem der inkonsistenten Eingabe durch Mapper, sondern dass der Name in der Hauptsatzung der Kommune, auf den Ortsschildern, auf dem Bahnhof und der umgangssprachliche jedesmal verschieden sein können.
Mit einer Aufteilung auf short_name, prefix, postfix, official_name usw. kann man dem data consumer das Leben leichter machen, aber Zweifelsfälle wird es trotzdem immer noch geben.

Das echte Leben ist nun mal nicht SQL-konform.

6

Gut erkannt seichter!
Es benötigt eine Anleitung zur Aufteilung. Solche Anleitungen springen mir ab und an in die Suchergebnisse. Doch die hätte es vor dem Befüllen der Datenbank benötigt. Jetzt ist das Schlamassel groß.

PS: Titel wie gewünscht geändert.

7

Mit freundlicher Genehmigung von wambacher darf ich auf seine Liste (prefix_list_deu.txt) verlinken.

Grundsätzlich ging es bzgl. “prefix” auch gleich auf der ersten Seite bei Pflege und Korrektur der deutschen Admin-Grenzen hoch her.

8

Interessante Diskussion, 20 Seiten lang.
Die prefix-liste in UTF-8 wäre fein.

Ich habe da etwas von “verkleben” gelesen. Also ja, es gibt Grenzen, die nach natürlichen Gegebenheiten ausgerichtet sind. Solange sich an diesen natürlichen Gegebenheiten nichts ändert, ändert sich nichts am Grenzverlauf. Doch wenn doch, dann gibt es Ärger und Streit, wo die Grenze denn nun verläuft (Flußbegradigung, Veränderung des Mäandern, Veränderung von Straßenverläufen, …). Das gibt es in Groß zwischen Russland und China, aber auch im Kleinen. Auf Nachbarschaftsebene regeln solche Streite dann meistens die Grenzsteine, wenn vorhanden. Es ist also für zukunftssicheres mappen nicht förderlich zu “verkleben”.

Zudem erfahre ich nun von einer offiziellen amtlichen Liste der Namen. Wo liegt das Problem, diese Daten nicht einfach bürokratisch zu übernehmen, wie alles nach dem Komma in prefix und das davor in name? Wer dann noch Sonderwünsche hat kann sich ein name:alt und prefix:alt alternativ anlegen, wenn gewünscht ist alles sogar in veschiedenen Sprachen möglich :de. Das soll doch nicht das Problem sein, bzw. ist kein Streit wert. Über die amtlichen Bezeichnungen, und seien sie noch so kurios, zu urteilen, sollte nicht in Mappers Hand liegen. Die werden sich schon was dabei gedacht haben und wenn nicht: selber schuld. Dann machen sie sich zum Affen und nicht die Mapper. Ist also kein OSM Problem, sondern deren. 1:1 Übernahme der Daten und gut is.
Anhand solcher Zusammenfassungen, wie in der anderen Diskussion gezeigt, können dann if else Regeln für das Bilden ganzer Sätze erstellt werden.
https://forum.openstreetmap.org/viewtopic.php?pid=396832#p396832
Es geht beim Sätze bilden ja nur um Zwischenwörter wie “im”, “in der” oder “der”.
Wenn da aber jeder seins macht und prefixe im Namen auftauchen, dann wirds endlos.

Einfach die amtliche Liste regelmäßig einpflegen und fertig.

9

Noch interessanter wird das bei internationalen Darstellungen :slight_smile:

Hier in Schweden gibt es eine Verwaltungseinheit die heisst “län” - was man auch wörtlich mit “Land” übersetzen könnte. Passt nicht so ganz, daher kam jemand auf die Idee “län” mit “Province” zu übersetzen.

Aber das län bleibt trotzdem im Namen.

Auf vielen Karten (zB openstreetmap.de) führt das jetzt zu Bandwurmwörtern a la “Province Kalmar län” - was man garantiert nirgendwo on THE ground findet. …

Wo da sinnige Stellschrauben sind, ist mir völlig unbekannt. Aber es ist teilweise schon sehr verwirrend…

10

Das ist auch schon durchdekliniert worden: Natürliche Grenzen (fast immer Gewässer) nur dann als Grenzhlinie verwenden, wenn sie ausdrücklich in offiziellen Vereinbarungen/Grenzverträgen vereinbart wurden.

Zwischen Gemeinden erfolgen bei Verlaufsänderungen z.B. nach Unwetter dann gelegentlich Gebietsausgleiche, ein Automatismus ist das aber nicht.

11

Die Liste ist in UTF-8, da es ein Report aus PostgreSQl ist. Nur “fuscht” der Webserver/Client da rum und verstümmelt das leider.

Hier mal als ZIP: https://wambachers-osm.website/images/osm/data/prefix_list_deu.zip

Gruss
walter

12

Das ist z.B. mit der Grenze Deutschland-Polen so (Oder-Neiße) Als Grenze ist hier die Tiefenwasserlinie definiert, die sich logischerweise ständig verändert. Meines Wissens wird in mehrhährigem Abstand anhand von Fixpunkten auf dem Festland die Grenze neu festgestellt.

Hier mal eine Abfrage vom Zusammenfluss Neiße-Oder: http://overpass-turbo.eu/s/EJs (Achtung: 20 MB Daten, da Staats- und andere Admin-Grenzen und div. Schutzgebiete): rot: admin-Grenze, Grün: Schutzgebietsgrenze, blau: Gewässerachse.

Theoretisch müssten mindestens die Grenzen, streng genommen das Ganze auch mit dem Fluß verklebt werden. Rein praktisch hat das hier bisher keiner gemacht, da die Bearbeitbarkeit erheblich einschränken würde. Ich lasse aus diesem Grunde auch die Finger davon.

Ähnlich ist es oft mit allen anderen Admin-Grenze z.B. von Kreisen oder Gemeinden (oder anderen Admin-Hierachien). Hier sind auch oft (katastermäßig) die Gewässermitte als Gemarkungs-Grenze(*) definiert, was sich wiederum auf höhere Admin-Einheiten niederschlagen würde. Im Kataster werden solche Veränderungen, wie sie z.B. durch Gewässermäandrierung, Begradigungen, ect. entstanden sind, nur bei Bedarf herausgemessen und verändert… Verfahren, vgl. z.B. https://vermessung.brandenburg.de/sixcms/media.php/1071/83002500.pdf. Eine kontinuierliche Pflege solcher Grenzen findet nicht statt. Die Abweichung von der Admin-Grenze und der Realität des Gewässers ist somit Standard.

(*) Wir erfassen zwar nicht die Gemarkungsgrenze des Katasters, aber die Grenzen der Ortsteile, Gemeinden, Ämter, Kreise, ect. basieren auf den Katastergrenzen (Enklaven-Exklaven-Regelungen mal ausgenommen).

Sven

13

Welche “amtliche Liste” meinst du? Die von DESTATIS? Oder die VG250 von Geodatenzentrum? Egal, dürften es wie immer die Lizenzproblematik sein.

14

Auch ein sehr schönes Thema, weil ich grad boundarys mittels OpenLayer Polygon anzeigen lassen. Daran habe ich noch gar nicht gedacht. kompliziert, kompliziert.

Ich weiß nicht was du jetzt meinst. Ich meinte iwo hier gelesen zu haben, dass es eine Liste der area Namen gibt. (nicht boundary). Aber das geht mir jetzt zu weit, kenne ich mich nicht aus.