Hallo,
warum wird Russland zweigeteilt angezeigt?
Kann man das ändern?
Ich benötige Russland zusammenhängend.
vielen Dank
Da liegt daran, dass der 180. Längengrad durch Russland geht. Am 180. Längengrad teilt OSM die Welt auf.
Kann das von mir irgendwie geändert werden?
Ist die Frage wie Du darstellen willst?
Wenn Du alles selbst machst, Daten von Russland reinziehen, alle Lats minus 10 Grad und schon ist Russland gesamt in der östlichen Hemisphäre.
ok,
ich danke dir.
komm gut in den mai.
Mapnik kommt nicht mit Geometrien klar, die über den 180. Längengrad hinwegreichen. Anders ausgedrückt: Bei einem Liniensegment von x1,y1 nach x2,y2 prüft Mapnik nicht, ob x2-x1 größer als die Hälfte des Erdumfangs ist.
Nich direkt.
Grenzen und auch andere Flächen werden bei OSM und auch in allen mir bekannten GIS-Systemen an der Datumsgrenze geteilt.
Meine Versuche, das beim Export aus der Boundaries Map zu verbessern, sind für Russland bisher gescheitert, da PostGIS für diesen Bereich keine “vernünftige” Projektion anbietet.
Gruss
walter
Es hat zwei Polygone für Russland. Der senkrechte Strich hier ist keine Provinzgrenze zu Ostsibiren, sondern die “Staatsgrenze” an der Klebestelle.
Die Relation 3237101 zeigt auch schön, was passiert, wenn ein Land ungünstig an der Datumsgrenze liegt.
Achso: Die einfachste Lösung, wenns nur um die Anzeige geht ist natürlich, die Grenzen wegzulassen und nur die Fläche zu zeichnen. Die Flächen passen schon zusammen, nur der Trennstrich ist lästig.
Ist das die OSM-Version der Tschuktschen-Witze? 
Zur Info - vor allem auch weil einige Kommentare andeuten, dass dies ein grundsätzliches technisches Problem wäre (in allen mir bekannten GIS-Systemen) - Russlands Grenzen in ein einheitliches Polygon zusammenzusetzen ist eigentlich ganz einfach und geht mit so gut wie allen Vektordaten-Verarbeitungssystemen. Hier die ogr2ogr-Variante auf Grundlage von wambachers shapefiles:
ogr2ogr -t_srs EPSG:3995 ru_3995.shp Russian_Federation_AL2.shp
ogr2ogr -f SQLite -dialect SQLite -sql "SELECT ST_Union(GEOMETRY) FROM ru" -nln ru -nlt MULTIPOLYGON ru_3995.db ru_3995.shp -dsco SPATIALITE=yes
EPSG:3995 steht hier nur exemplarisch für ein beliebiges Koordinatensystem, welches die gesamte Ausdehnung Russlands kontinuierlich auf eine Ebene abbildet. Das Problem ist eigentlich nur, dass dies bei vielen gängigen Koordinatensystemen halt nicht der Fall ist. Und PostGIS kann das Ganze natürlich genauso.
Es gibt in PostGIS die interne Funktion _ST_bestSRID(geom), die - angeblich - für jedes Polygon die beste SRID liefert.
select _ST_bestSRID((select way from planet_osm_polygon where osm_id=-60189));
_st_bestsrid
--------------
999061
Für Russland liefert die Funktion 999061. (*) Leider kann ich das in Qgis (noch) nicht darstellen, da diese Projektion dort nicht vorhanden ist.
Spasseshalber hab ich mal IAU2000:99918 genommen, da die für die Gegenden um den Nordpol gedacht ist.
Sieht doch für den Anfang ganz gut aus:
Mal sehen, ob ich die 999061 hinbekomme.
Gruss
walter
Vor ca 3 Monaten gab es hier noch Geometry Exceptions wegen der Arktischen Region. Entweder hat wer an der Grenze im Norden rumgedreht oder der letzte PostGIS-Update hat das Problem beseitigt.
Also,
in den PostGIS-Sourcen ( https://github.com/bnordgren/postgis/blob/master/libpgcommon/lwgeom_transform.h ) steht
/** Lambert Azimuthal Equal Area North Pole, equivalent to EPSG:3574 */
#define SRID_NORTH_LAMBERT 999061
Danke, 3574 probier ich gleich mal aus.
Gruss
walter
done: sieht auch nicht schlecht aus.
Muss man “nur noch” die Datumsgrenze wegbekommen und dann noch drehen.
Pedanterie
Es geht nicht um die Datumsgrenze, sondern um den 180. Längengrad. Die Datumsgrenze geht da oben nicht durch Russland durch.
Siehe https://de.wikipedia.org/wiki/Datumsgrenze
imagico hat ja schon beschrieben, wie man die Trennung an 180° wegkriegt mit PostGIS oder ogr.
/Pedanterie
Was mich interessieren würde ist wieso PostGIS sich da ein 999061 ausdenkt, das aber 3574 ist. Hat da jemand eine Idee?
Jo, hattu Recht. Im Pazifik stimmt das oft, aber da oben halt nicht.
Hab ne Anfrage zu dem Thema bei Qgis-user laufen. Mal sehen, was da kommt.
Sein Beispiel läuft mit SQLite - das ist nicht PostGis ;)Gruss
walter
PostGIS “verweigert” den Merge übrigens - was mMn logisch ist, da in dem einen Teil der Breitengrad auf 180° und bei dem anderen Teil
auf -180° liegt.
create table ru_test as select st_union(way) as way from planet_osm_polygon where osm_id=-60189;
Gruss
walter
ich hab aber schon eine Ahnung, wie ich das dennoch hinkriege.
Ein Schritt nach dem anderen:
wie?
select ST_Union(ST_Buffer(ST_ShiftLongitude(way),0.0001)) as way from planet_osm_polygon where osm_id=-60189;
von innen nach aussen:
- ST_ShiftLongitude(geom) konvertiert den Bereich -180° … 180° in 0° … 360°
- ST_Buffer(geom,0.0001) macht die Flächen um 0.0001° größer. Dadurch wird Überlappung erreicht.
- ST_Union(geom) vereinigt die Flächen
Puh.
Gruss
walter
ps: das Ganze geht nur mit Daten in “gradischen” Projektionen. Merkaator geht z.B. nicht.
Ja cool, danke!