Fehler bei dem Grenzverlauf visualisieren

Ich habe gelernt dass das Thema administrative Grenzen in vielen Gegenden diese rWelt eher locker behandelt wird.
Gibt es irgendwo ein Tool mit dem man automatisiert die Grenzverläufe (am besten mit dem Schalter für Anzeige einzelner Admin_Levels)
darstellen und automatisiert korrigieren kann?

Wenn nicht, wäre jemand in der Lage sowas zu schreiben?
Es pasiert immer wieder dass sich die Grenzen überschneiden - es entstehen Lücken bzw. Doppelbelegung von Areas…

das ist logisch, wenn Grenzen nicht als Multipolygone erfasst werden und sich somit die Grenzstücke “teilen”.
Ansonsten beschäftigt sich doch dieser Endlosthread mit dem Thema.

Gruss
walter

Man kann richtig anzeigen, was richtig gezeichnet wurde, wenn man die Regel dafür berücksichtigt.
Mir geht es um die zeichnerische Ungenauigkeiten / Schlamperei beim Zeichnen.
Und davon gibt es weltweit leider jede Menge.

Was meinst du mit zeichnerischer Schlampigkeit? Abweichung Soll/Ist? Dazu müsste man dann ja erstmal Soll kennen und als legal nutzbare Quelle zur Verfügung haben. Wenn dies so ist, kann man die Grenzen damit auch einfach ersetzen :wink:

Dann schreib das bitte auch, denn das ist ja ganz was anderes. Wir können die Grenzen nur so gut erfassen wie wir legale Quellen haben. Allerdings kann man auch bei den besten Quellen Mist bauen, indem man sie nicht richtig erfasst.
So kürzlich bei Koblenz geschehen, wo ein rechtlich sauberer Import technisch total versaut wurde.

Gruss
walter

Na ja, wenn ich ungefähr einen Grenzverlauf weiß, zeichne ich das auch ungefähr. Das stimmt schon.
Es sollten aber trotzdem unsaubere Verschneidungen vermieden werden.

Ich glaube du meinst einige Probleme, die bisher nicht klar geworden sind:
Grenzen zwischen zwei Gebieten (A und B) werden nicht als eine Folge von Wegen gezeichnet, auf die in beiden Grenzrelationen verwiesen werden. Sondern beide Grenzen werden als eigenständige Folge von Wegen erfasst, was dazu führen kann, dass sich die Grenzen (und damit die Gebiete) überschneiden können oder dazwischen Lücken entstehen können.

Ob Grenzen in sich stimmig sind, können der OSM-Inspektor (z.B. Selbstüberschneidung) und KeepRight (nicht geschlossen) prüfen. Ein Prüfung, ob zwei Grenzen sich nicht überlagern respektive ohne Lücken sind, kenne ich dagegen nicht.

Edbert (EvanE)

In JOSM klappt die Darstellung von (gefilterten) Grenzverläufen ganz gut, inkl. Visualisierung von möglichen Fehlern/Doppelungen:

http://wiki.openstreetmap.org/wiki/MapCSS/Examples

Das klappt definitiv! Man kann sich die einfachen CSS-Regeln nach eigenen Bedürfnssen gut anpassen.

Ansonsten fällt mir nur http://openmapsurfer.uni-hd.de sowie http://ags.misterboo.de ein.

Die boundary-Layer von itoWorld wertet keine Relationen aus, und der von OSM-Inspector von der geofabrik.de hat keine Differenzierung bei adminlevel größer 4.

Stephan

Genau das meinte ich, Edbert. Ich hoffe, irgend jemand kann ein solches Tool entwickeln. Wäre hilfreich.

Hallo stephan75, danke für die Tipps, ich leite sien nach Lodz weiter, dort spielen die Jungs gerade mit dem Thema da die Reparatur / Neuordnung der adminlevel dort aussteht.

Viele Grüße,
Marek

Kurzer Nachtrag zu den Lücken und Überschneidungen:
In einigen deutschen Bundesländern gibt es auf der Ebene der Gemeinden in der Tat Lücken. Das nennt sich dann gemeindefreie Gebiete. Ob in anderen Ländern so etwas eventuell auch in höheren Gliederungen (Kreise, Regierungsbezirke, Bundesländer) existiert ist mir nicht bekannt.

Auch Überschneidungen könnten in seltenen Fällen vorkommen, wenn ein Gebiet von zwei Parteien jeweils für sich beansprucht wird.

Edbert (EvanE)

Deutschland ist ( fast) ein Musterland. Klar, Polen ist jetzt nach dem bot Disaster ein Trümmerfeld aber solche Fälle sollen öfter vorkommen wenn ich dem Team aus Lodz glauben soll der die OSM Daten darauf testet.

Daher wäre ein solches Tool eine weitere Bereicherung für die Community.

Hallo,

Ja, solche Prüfung (=Topologieprüfung) wäre wichtig, stelle ich mir aber im Fall OSM als… ich sags mal… interessant vor, da verschiedene flächige Informationen überlagert… erfasst sind und dargestellt werden. Ich selbst arbeite beruflich mit ArcGis… und hab viel mit Biotopkartierung zu tun. Da machen wir immer Topologie-Prüfungen: für Flächen wäre es dann die Prüfung z.B.: “Keine Überlappungen” und “Keine Lücken” dererlei gibt es noch mehr (als Info: http://www.esri-germany.de/downloads/papers/TopologyRules_themes.pdf Letztendlich sind das ja Prüfungen, ob Geobjekte mit der Information Fläche in ihren Stützpunktkoordinaten Lagegleich sind oder nicht… Das sollte für findige Datenbankprogrammierer sicherlich zu lösen sein…

Innerhalb bestimmter Ebenen ist das sicher lösbar: Grenzen, Landuse/natural… ect. pp.

Letztendlich ist das aber nur praktikabel, wenn diese Prüfung gleich bei der Erfassung/ Bearbeitung der Daten gemacht wird. Ein Bot kann dann aber die Problemstellen der Bestandsdaten aufzeigen.

Man käme dann aber auch zum Schluß daß die Information: “Was ist auf der Fläche?” geschlossen erfasst werden muß/sollte… Straßen als Linien würden z.B. auf den jew. Flächengrenzen liegen… Grenzen wiederum dürfen nicht mit Landnutzungsdaten, Straßen ect. kombiniert werden, sie stellen eine eigene Ebene dar. Grenzen basieren z.B. auf alten Gewässerläufen, die mittlerweile sein über 100 Jahren nicht mehr existieren.

Ich denke, es wären auch in begrenztem Maße Flächenfallen nötig, also, ab welcher Größe erfasse ich das Objekt als Fläche/Linie/Punkt…

…nur so als Anregung und Idee… Sven

Ich habe aus familiären Gründen dieses Jahr auf OSMF Kandidatur verzichtet, aber dies ist für mich einer der Gründe, wieso ich Geld für Softwareentwicklung für OSM sammeln möchte:

Flächeninformationen müssen natürlich sauber vorliegen und die Prüfung der Informationen die sich überlagern, sollte layerweise passieren. So werden administrative Einheiten unabhängig von der Information über Biotope, Flächennutzung etc geschehen. Auch gibt es des Öfteren so triviale Sachen wie sich überlappende, unsauber verschnittene Gebäudegrundriße.

Klar gehen Deine Vorschläge in die richtige Richtung: Gemeint - mehr Professionalität durch bessere Werkzeuge.

Richtig, und auch klare Regeln: z.B. daß in Städten laduse=residental lückenlos an Landuse=comercial zu Grenzen hat und die trennende Straße auf der Grenze zu liegen hat (mit dem entsprechendem Tagging) die Liste ließe sich fortführen, muß aber auch disskutiert werden, was an welcher Stelle und in welcher Situation richtig, wichtig und sinnvoll ist. Aber da hab ich hier ein gutes Gefühl, daß das auch geschieht…

Sven

Das dann aber als Multipolygon, also nur eine Linie die jeweils in den MP Commercial und Residential einen Outer bilden und selber die Tags der Straße an sich trägt. Weil 3 Linien übereinander schwer zu bearbeiten sind. Den Fehler habe ich mal gemacht und vermeide ihn nun.

Geht aber noch eleganter und kann nun dank Bing auch umgesetzt werden, wenn auch nicht ganz ausgereift, weil man die Linenform der Straße nur schwer flächig auftrennen kann. Hatte ich damals auch schonmal im Test und wieder verworfen, aber besser als nichts und aighes wird sich freuen. Für die Darstellung der groben versiegelten Verkehrsfläche reicht es ersteinmal aus.

Rundherum landuse=farmland, dazwischen landuse=grass und die Straße liegt innerhalb von area:highway=secondary, drinnen wieder grass. Alles in Multipolys sauber getrennt. Da liegt nichts aufeinander, überlappen durch Fehlklicke ausgeschlossen und man kann es sauber bearbeiten.

Hallo Sven

Jetzt schüttest das Kind mit dem Bade aus.
Eine Fordereung Landuse muss lückenlos an Landuse oder Natural oder … grenzen entspricht nicht der Realität. Erstens gibt es Bereiche, wofür wir kein Landuse-Tagg haben, zweitens gibt es Bereiche, für die kein Landuse existiert. Auf Katasterkarten mit der Erfassung aller Flurstücke mag diese Forderung angemessen sein, führt aber zu seltsamen Konstruktionen wie Unland.

Übrigens grenzen in Katasterkarten keineswegs landuse=xyz in der Straßenmitte an landuse=abc. Ganz im Gegenteil eine Straße mit all ihren Nebenteilen (Graben, Grünstreifen, Geh-/Radweg, …) ist selber eine Fläche, die zwischen diesen beiden Landuse liegt. Wenn man so will ein landuse=highway für die gesamte von der Straße und ihren Nebeneinrichtungen beanspruchte Fläche.

Aufgrund der Tatsache dass bei OSM Straßen zur Verallgemeinerung/-einfachung als Linien erfasst werden, zu fordern dass die Landuse bis an die Straßenmitte ausgedehnt werden, verfälscht die Fläche der beteiligten Landuse.

Edbert (EvanE)

Wenn administrative Grenzen wie in DE als MP gezeichnet sind, findet OSMI natürlich Lücken (open Polygon)
oder interne Überschneidungen. Wenn die Grenzen dagegen type=boundary sind, wird die mWn nicht geprüft.

Guten Morgen,

gut, etwas unklar ausgedrückt… da, wo zwei verschiedene Landuse-Tags oder Natural-Tags aneinander grenzen, sollten die Geometrien gegeneinander sauber sein.

jaja… das Unland in der ALK… ich frage mich sowieso, wie die Nutzungsarten im ALB ermittelt werden… Ich schaue mit ALB-Nutzungsarten in einem dienstlichen Zusammenhang immer wieder an und bin der festen Überzeugung daß es sehr wohl möglich wäre, jeder Fläche eine Nutzungsart zuzuweisen, die nicht “Unland” ist, der Schlüssel deckt alles ab. Ich glaube, man benutzt “Unland”, weil man keine Lust hat, die Fläche zu fragmentieren, wo es nicht nötig ist, oder wo man sich nicht sicher ist, was genau auf der Fläche ist. Mit Nutzungsarten im ALB ist das eh so eine Sache: die stimmen ganz gerne mal nicht: z.B. ALB sagt Grünland, Luftbild sagt Wasser und Schilf… Unland betrachte ich als ein Konstrukt, daß in der Hauptsache Grundsteuerrelevant st…

Das ist richtig. Jedes Flurstück hat seine Nutztungsart(oder -arten, es darf ja auch mehrere haben). Oder auch nicht, weil Nutzungsart Graben oder Weg im ALB nicht erfasst, im Luftbild aber ersichtlich sind.

Das ist auch richtig, führt aber zu solchen Dingen wie in Lübbenau (nicht von mir):
http://www.openstreetmap.org/?lat=51.868343&lon=13.951449&zoom=18&layers=M
unterschiedliche Straßenbreiten… und dann unregelmäßigen Streifen rechts und links… innerhalb städtischer Bereiche sehe ich es nicht als Problem an, die Landuses in der Straßenmitte enden zu lassen. Bei Kreisverkehren ist es interessant… siehe Beitrag #15.
Na uns die Fläche der beteiligten Landuse ist doch sekundär, es werden doch keine statistischen Auswertungen gemacht…

Sven

an diese Multipolygon-Geschichte muß ich mich bei JOSM noch herantasten. Da lerne ich noch… Ist aber sicher nicht schwierig, wenn man den Bogen raus hat…

Sven

Ich freu mich über die Diskussion. Eines im Vorab: Klar haben wir Bereiche wo wir NOCH kein Landuse Tag haben. Ich sehe es aber eher als eine interessante Herausforderung an uns solche Lücken zu schließen.
Des Weiteren ist es eine Interessante Aufgabe, Tools zu entwickeln, die die Topologieprüfung und automatisierte Verbesserung ermöglichen. Beispiel: Saubere Verschneidung der Seefläche und des Waldes rund herum. Eine Entsprechende Beschreibung habe ich falls jemand Interesse hat. Ich denke es sollte zweierlei sein:

  1. JOSM PlugIn
  2. Potlatch2 Funktion ( Wobei ich hier zu meinem Bedauern eher die Untätigkeit des Teams befürchte:( ).