APP zum Überprüfen der amtlichen Grenzen in Deutschland

ich dachte du hättest den WIKI Artikel geschrieben ?

in der DB sind bisher 191 x de:regionalschluessel und 742 x de:amtlicher_regionalschluessel

Wegen mir könnte man für beide Sachen auch kürzere Namen verwenden,
z.B de:ags und de:rgs oder de:AGS und de:RGS

Deshalb hatte ich das einklich geändert auf:
http://wiki.openstreetmap.org/wiki/Key:de:amtlicher_regionalschluessel

wo steht jetzt noch die alte Version?

Gruß,
ajoessen

Nur ergänzt, nicht angelegt.

Abkürzungen werden nicht gerne gesehen.
Die quoten stimmen nicht mehr. Die 742 waren von mir, die Minderheit hatte ich heute der Mehrheit angepasst.
Insgesamt sind es jetzt 1155 Regionalschlüssel.

Ich änder das jetzt mal auf de:regionalschluessel in der DB und im Wiki.

EDIT: Hier gehts jetzt lang:
http://wiki.openstreetmap.org/wiki/Key:de:regionalschluessel

Heute wurde an vielen Grenzrelationen ein place-Tag angefügt und in type=boundary umgetaggt. Wurde das irgendwo diskutiert? Das durch die place-Tags jetzt doppelt in der Datenbank sind, damit kann ich mich ja noch arrangieren, aber das umgetagge betrachte ich mal als Vandalismus.

Beispiel?

Gruß,
Mondschein

62405

Ist das Vanadalismus, wenn man eine eindeutige Unterscheidung zwischen Stadt und Gemeinde; sowie zwischen Kreis und kreisfreier Stadt haben will?

Gruß,
ajoessen

Und warum wird dazu das place-Tag “missbraucht”, wozu redundante Informationen?

Und wie passt da das boundary rein, nur das habe ich als Vandalismus bezeichnet?

type=multipolygon vs. type=boundary:
http://lists.openstreetmap.org/pipermail/talk-de/2010-August/073593.html

Verstehe das Problem auch nicht.

Gruß,
Mondschein

Wie war das noch mit dem kleinen gallischen Dorf, das gegen den rest der Welt kämpft?

Gibt aber doch ein Problem, mit dem place: mkgmap unterscheidet nicht sauber zwischen city/town/village als Siedlungsfläche und als Grenze. Und bevor sich Leute aufregen, weil sie ihre Regeln anpassen müssen, hab ich die jetzt nach de:place verschoben.

Es geht darum, dass Orte zweimal eingetragen sind, einmal mit einem place-Node und einmal mit einem place an der Relation. Wie sollen zB Suchfunktionen damit vernünftig umgehen?

Das Schlimme ist, dass diese Diskussion bei weitem älter ist und der Konsens ist schon lange “In Deutschland wird multipolygon für amtliche Grenzen genutzt”. Es ist einfach nur dreist, ohne Rücksprache mit der Community daran was zu ändern!

Da Relation 17661 schon ein “type=city” hat, wäre ein “type=city” bei Relation 62405 redundant.
Was ist mit “type=country” bei Relation 22961?
Das ist doch nicht richtig?
Ist das genaue Vorgehen irgendwo nachzulesen?

Ich bin auch für die “type=multipolygon”-Lösung, allerdings scheint das so bisher nicht eindeutig dokumentiert zu sein.

Gruß,
Mondschein

Mir gehts um die Grenzpolygone und deren tags. Da nützen mir irgendwelche tags an Punkten innerhalb wenig. Innerhalb eines Landkreises gibts etliche Untergliederungen, die alle beliebige place-nodes haben können.

Stammt nicht von mir. Und wurde von mir ignoriert, weil es kein boundary=administrative und keinen AGS hat.

http://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen#Politische_Grenze
http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Relation_anlegen

Der Konsens liegt weltweit bei 169 479 Grenzrelationen, davon 109 378 type=boundary.

Aber davon ab, werden die Grenzrelationen ja sowieso nächsten Monat zerstört und von fleißigen Mappern anhand von Bing-Luftbildern im Nullkommanix wieder neu erstellt.

Gruß,
ajoessen

http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon
http://wiki.openstreetmap.org/wiki/DE:Relation:boundary
http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze

Reden wir hier nicht deutschen Grenzrelationen? Aber gut das nach Jahren mal jemand darauf aufmerksam macht.
Am besten konsequent sein und die restlichen deutschen Grenzen von multipolygon auf boundary umstellen, vielleicht gleich für Niederlande und Ecuador dazu. Nicht zu vergessen das Wiki zu ändern, vorher aber auch eine Mail an die Liste, damit jeder von der Lex ajoessen weiss.

???

Hatte übrigens jemand Antwort vom Kollegen ludwich bekommen ?

http://www.openstreetmap.org/user/ludwich

Dieses Wochenende sind noch mal einige Fehlermeldungen dazu gekommen:

http://ags.misterboo.de/

u.a. ersetzt der Kollege leider immer noch den 8 stelligen Gemeindeschlüssel mit dem 12 stelligen Regionalschlüssel.

Noch ein Wort zu der type=multipolygon vs. type=boundary Geschichte

Auch wenn es bei uns anders ist als im Rest der Welt … es war bisher einheitlich !! Es gibt nicht viele Sachen in der OSM DB die vollständig und einheitlich sind, die Grenzen in Deutschland waren dies bis vor kurzem: komplett und einheitlich type=multipolygon.

Ich denke wir sollten woodpeek von der geofabrik zu dieser Frage nochmal was sagen lassen. Ich habe mir seine Argumente mal rausgesucht und finde diese sehr sinnvoll, überhaupt generell seine Gedanken zum OSM Datenmodell. Und wie ich die Sache so überblicke, gehört er zu den recht wenigen Fachleuten die von der Programmierung her überhaupt den Durchblick haben und an der nächsten api Version mitarbeiten. Meiner Meinung nach wird das sowie so eine Mammutaufgabe werden, das Datenmodell von OSM an zukünftige Anforderungen anzupassen.

Aber egal wie man sich hoffentlich gemeinsam einigt: ein Durcheinander im tagging wie es sich momentan abzeichnet, sollte unbedingt vermieden werden.

Da teile ich deine Meinung, dass dies völlig daneben ist.
Der Regionalschlüssel ist nun einmal etwas anderes als der Gemeindeschlüssel.
Daher sollte dafür auch ein anderer Key benutzt werden.

Es war nie einheitlich. Es gab auch in DE immer Gebiete wo type=boundary genutzt wurde.

Das Flächenmodell wie es durch type=multipolygon favorisiert wird, unterschlägt die zweite Seite von Grenzen, nämlich die Linie, die zwischen zwei Gebieten existiert. Denke nur mal an Begriffe wie Deutsch-Französische Grenze oder Seegrenze (Staat / internationales Gewässer).

Von daher bevorzuge ich das französische Modell mit boundary_segments für jede solche Grenze zwischen zwei Gebieten. Nur leider kann man daraus keine Multipolygone für die Flächen der Gesamtheit aller Grenzen bilden. Multipolygone erlauben leider nur einfache Wege als Mitglieder und nicht Realtionen, die ihrerseits einen kontinuierlichen Weg darstellen. So gibt es immer die doppelte Datenhaltung für Segmente und für die Fläche. Dass man in Multipolygonen weder label noch admin_centre (üblicherweise Punkte) als Rollen als angeben kann, sei nur als ein weiterer Mangel angemerkt.

Edbert (EvanE)

Nö, da kram ich doch mal den alten Thread raus. Und das war nur die Küste
http://forum.openstreetmap.org/viewtopic.php?id=12203

Hat immer noch niemand den Kollegen erreichen können ? Ich habe ihn schon 2 x angeschrieben und erst
gestern seine letzten Änderungen wieder korrigiert. Antwort habe ich leider keine bekommen.

http://www.openstreetmap.org/user/ludwich/edits

Langsam wird es etwas nervig.

http://ags.misterboo.de

Heute hat er wieder bei einigen Gemeinden den Regionalschlüssel in den tag de:amtlicher_gemeindeschluesel geschrieben.

Für den Fehler 1 zeichne ich verantwortlich… :slight_smile:
habe einfach mal versucht, die 10 Gemeindefreien Gebiete dieses einen Landkreises, die ja unterschiedliche AGS haben, zu einer collection zusammenzufassen;
dieser habe ich dann den Einheits-AGS und Regionalschlüssel aus der Destatis-Datei verpasst.

siehe auch Post #65 in diesem Faden.

Ich lass das erstmal so, bis das ganze Gezerre um type=multipolygon bzw type=boundary sich in irgendeiner Weise gelegt/vereinheitlicht hat hat, oder gibt es
zu meiner type=collection Probleme?

hi,

ich komme eigentlich ganz gut zurecht mit den beiden Versionen - ich behandle sie als gleichwertige Synonyme. Allerdings krieg ich die Krise, wenn hier plötzlich noch ne dritte Variante auftaucht.

Gruss
Walter