Ne, genau so ist es gedacht. Da das Editing anonym ist, weiss ich eh nicht, wer da was gemacht hat. Aber eigentlich ist das egal - Hauptsache gefixt.
Schwitzende Grüsse
walter
Moin, hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/242-countries-compare-2015-07-04
Datenstand 00:18 heute früh.
Nicht viel passiert, genau genommen fast nix.
Gruss
walter
Moin,
hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/243-countries-compare-2015-07-05
Datenstand 00:34 heute früh.
Nicht viel passiert, genau genommen fast nix. Muss wohl an der Hitze liegen.
Gruss
walter
Soweit ich die frz. Wikipedia verstehe (Google Translate), gliedert sich Marokko nicht mehr in 16 Regionen sondern nurmehr in 12 Regionen: “En 2015, le Maroc se dote d’un nouveau découpage territorial, annoncé par le projet de régionalisation avancée de 2011. Il compte désormais 12 régions2, le nombre de provinces ou préfectures et communes étant resté inchangé.”
Danke, ich schau mal nach.
eventuell spreche ich auch den Mapper an, der zuletzt viel in Marokko gemacht hat.
Gruss
walter
Moin,
hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/244-countries-compare-2015-07-06
Datenstand 01:07 heute früh.
absoluter “Tiefpunkt”. Ein Missing und sonst nix.
Gruss
walter
Schiefgegangener Import von Distriktgrenzen in Uganda? (2014)
Bevor ich das auf der Imports-Mailingliste breittrete wollte ich erstmal hier Rücksprache halten.
Für mich sieht es danach aus, dass die hochgeladenen Distriktgrenzen einen Shift von bis zu 300 Meter nördlich und 400 Meter westlich aufweisen.
Fest mache ich das unter anderem an folgenden Stellen, wo der Versatz zu Straßen/Flüssen in Bing und auch LSIB5 extrem ist:
https://www.openstreetmap.org/#map=17/0.5575127435054442/34.128277440009654
https://www.openstreetmap.org/#map=18/-1.144355/30.308764
https://www.openstreetmap.org/#map=16/3.5775263062619813/32.06758168053731
Der Importeur hat mir geantwortet, er habe die importierte Datei mit folgender Projektion direkt in JOSM eingelesen: PROJCS[“WGS_1984_UTM_Zone_36N”,GEOGCS[“GCS_WGS_1984”,DATUM[“D_WGS_1984”,SPHEROID[“WGS_1984”,6378137.0,298.257223563]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER[“False_Easting”,500000.0],PARAMETER[“False_Northing”,200000.0],PARAMETER[“Central_Meridian”,33.0],PARAMETER[“Scale_Factor”,0.9996],PARAMETER[“Latitude_Of_Origin”,0.0],UNIT[“Meter”,1.0]]
Was bedeutet das? Ich kann leider nicht viel damit anfangen. Liegt hier der Fehler begraben?
Die Ausgangsdatei war laut Importseite im Wiki folgende: http://www.humanitarianresponse.info/operations/uganda/dataset/uganda-admin-level-3-boundaries
ich hätte fast gesagt ja… aber… die Parameter:
PARAMETER["False_Easting",500000.0]
PARAMETER["False_Northing",200000.0]
PARAMETER["Central_Meridian",33.0]
bewirken nur eine eine Verschiebung in x bzw. y-Richtung und das in ganzen Metern (
UNIT["Meter",1.0]
), das heißt eine Verschiebung um 500 km in x, bzw. 200km in y-Richung unter Annnahme eines anderen Zentral-Meridians. Aber das ist es nicht…
Wir bewegen uns immer in WGS84. Diese Verschiebungen benötigen aber keine fehleranfälligen Transformationen (wie z.B. von Gauss-Krüger nach WGS84)
Ich vermute, der Datensatz ist schon unter Nichtbeachtung einer Transformation aus irgendeinem Koordinatensystem nach WGS84 falsch konvertiert worden… Wen man das Ausgangskoordinatensystem kennen würde, ließe sich das rückgängig machen, ansonsten nicht…
Sven
Das ist die Information im .prj-File zum importierten Shapefile.
Die sollte stimmen, muss aber nicht, je nachdem wie die Shape-Directory erzeugt wurde. Wenn da im GIS eine falsche Projektion / falsches Datum eingestellt war, hat man einen Versatz. Wenn Oberhausen in der Ukraine liegt, fällt es gleich auf, bei einem halben Meter Versatz erst, wenn die Brückenbauhälften über den Rhein in der Mitte zusammentreffen.
In Uganda sind es ein paar hundert Meter. Der Versatz ist nicht konstant, es ist also nicht nur ein Offset-Fehler durch UTM.
Ohne die Original-Projektion (am besten in EPSG) ist das ein Stochern im Nebel.
Moin,
hier die aktuelle Missing Boundaries-Auswertung: http://osm.wno-edv-service.de/index.php/10-osm-reports/245-countries-compare-2015-07-07
Datenstand 00:22 heute früh.
In Uganda hat sich viel getan - hat wohl mit den Beiträgen vorher zu tun. Nur kann ich das noch nicht nachvollziehen.
Kampala fehlt:
Gruss
walter
EDIT: Ich nehme an, jemand hat den Mist rausgeschmissen. Der Import war mWn übrigens von den selben Experten, der vor ca 2-3 Monaten versucht hat, kritische Boundaries in Nepal zu importieren.
Ja, ich habe gestern etwas geändert und bin dadurch dann darauf aufmerksam geworden, dass mit den kompletten Grenzen inklusive Staatsgrenze bis runter zu AL6 etwas nicht stimmen kann, als mir der starke Versatz an der Staatsgrenze auffiel. Der Import wurde sogar auf imports@ angekündigt, wo offenbar auch niemandem der Projektionsfehler auffiel.
@seichter und streckenkundler: Danke für die Infos!
Ich würde jetzt aber nicht gleich das Kind mit dem Bade ausschütten.
Ich weiß nicht, wie die Grenzen vorher ausgesehen haben bzw. ob da überhaupt welche da waren.
Eigentlich ist eine Grenze mit einem Fehler von 300 m besser als eine mit dem Fehler 3 Km oder gar keine.
Die Grenzlinien selbst sind etwas generalisiert, die relative Ungenauigkeit (d.h. ohne Projektionsfehler) liegt aber in der Größenordnung von 10 m.
Problem ist nur, dass wenn das Grenzpolygon bereits existiert, immer wieder Wege, Gewässer, Hausecken etc. (meist ungewollt) an die Grenzknoten gepappt werden, was eine spätere Korrektur der Grenze sehr erschwert.
Beim Übernehmen der Shapes hätte aber spätestens an den Staatsgrenze auffallen müssen, dass da was nicht stimmt. Selbst wenn das vorher nur ein grober Linienzug mit etlichen km Ungenauigkeit war, gibt es genug Objekte wie Gewässer an Staatsgrenzen, mit denen man vergleichen kann.
In der Gegend gibt es genug GPS-Tracks in den Städten und größeren Straßen, mit denen man z.B. Bing überprüfen kann. HiRes-Bing ist danach in der Gegend bis auf wenige Meter genau, kann also als Referenz herhalten.
Hi, ich versuche eine Mail-Diskussion hier in das Forum zu ziehen, da es doch mehr als 2 Leute interessieren wird:
Ja, das ist ein altes Problem. Jedes Land kocht da in OSM bei der Einteilung der Admin-Level sein eigenes Süppchen und es passt wirklich nicht zueinander.
Das lag auch an der schwammigen WIKI-Beschreibung und dem Fehlen einer vernünftigen Datengrundlage. Hier halte ich den Ansatz, die ISO3166-2 konsequent als Vorlage zu nehmen, für äusserst interessant. Schliesslich hat da jedes Land seine Administrative Struktur verbindlich festgelegt.
Die Liste zeigt derzeit die Ebene2 der Länder unabhängig von sonstigen Daten an. Nur was genau auf Ebene 2 liegt, wird hier ausgegeben. Und wenn ein Land in OSM 3 Regionen hat, die es laut ISO nicht gibt, fehlen diese wohl auf Ebene 3 stehenden Daten hier. Das Ganze ist einzig und alleine aufgrund der Geometrien (st_contains()) in PostGIS berechnet worden.
So erklären sich die rund 1300 fehlenden Grenzen in der Liste. Sie werden einfach “verdeckt”.
Hier die aktuelle Liste:
https://osm.wno-edv-service.de/Dataserver/osm/files/iso2.txt
Es gibt noch Unstimmigkeiten wegen der Klein-/Grossschreibung, aber das gibt sich schon.
Gruss
walter
In einem Dokument bzgl. “GIS Data Interoperability in Uganda” heißt es auf Seite 13:
Die Grenzen sind von UBOS: http://www.humanitarianresponse.info/operations/uganda/dataset/uganda-admin-level-3-boundaries
Herrgott aller Gis-Datenbanken, was machen die denn da… 
Danke für den Link…
Die Grafik auf Seite 14 im dem PDF gibt Aufschluß… Anscheinend gibt es 4 Quelldatensätze mit unterschiedlichen Verschiebungen und Projektionsherkünften… das würde erklären, warum die Grenzen un einigen Ecken einigermaßen passen und in anderen nicht. Noch sehe ich aber nicht durch, welche der unterschiedlichen Datensätze eine 166m - Verschiebung haben, und welche eine 12,5m Verschiebung. Dann sind einige Daten bereits WGS84 und einige noch Clarke 1880 …
Sven
dto.
Aus dem Text geht hervor, dass die vier Transformationen von vier Regierungsstellen kommen, UBOS ist eine davon.
Die verwendeten als Sphäroid (Ellipsoid) Clarke 1880 mit Datum Arc 1960, das wären EPSG 21096 und 21036 (nördlich und südlich des Äquators) plus einem konstanten Shift von 200 und 500 km wegen des Äquators (der ist im .prj schon drin). Verwendet wurde wohl 21096 plus Shift, da sie wahrscheinlich keine zwei Projektionen für ihre Karten verwenden wollten, der Unterschied dürfte auch minimal sein.
Hi, wenn ihr mal mit Uganda durch sein solltet:
Kann mit jemand erklären, wieso in Tschechien 8 “Bundesländer” mit AL4 eingetragen sind, obwohl es die laut Wiki und ISO3166-2 überhaupt nicht gibt?
Die 14 “Kreise” sind mMn dagegen ok.
Bevor ich bei unseren Nachbarn durch eine “blöde” Frage Unmut erzeuge, würde mich eure Meinung dazu interessieren.
Ich vermute, dass es irgend ein Überbleibsel aus “alten Zeiten” ist.
Gruss
walter
Ja da ist was dran - aber das sind dann doch keine Administrativen Grenzen, sondern “irgend was anderes”.
Edit: Laut Wiki doch. ziemlich undurchsichtig.
Ich würde die NUTS2-Grenzen mit boundary=statistical taggen oder boundary=nuts. Es handelt sich ja um keine administrative Verwaltungseinheiten und die NUTS2-Regionen in Tschechien unterscheiden sich auch von den administrativen Regionen (*), sonst hätte ich gesagt man könnte den Code an die administrativen Grenzen “ranpappen”.
“NUTS Severovýchod je statistická oblast Eurostatu úrovně NUTS 2.”
https://cs.wikipedia.org/wiki/NUTS_Severov%C3%BDchod
Ich würde da nicht zu viel auf das OSM-Wiki geben.
OT: Sehe ich das richtig, dass wir die NUTS2-Regionen für Deutschland nicht in OSM haben? https://de.wikipedia.org/wiki/NUTS:DE
(*) https://commons.wikimedia.org/wiki/File:NUTS_CZ-Regio.png (NUTS-Regionen = farbige Fläche; weiße Grenze = administrative Grenze)
