EPSG:3068 in WGS84 umwandeln und Frage bezüglich WMS

selphiron wrote:

Ach und kann man mit Josm die Polygone einer Ebene zu soetwas wie GeoJSON oder was ähnliches ausgeben lassen?

Der WMS liefert ein Rasterbild, das kennt keine Polygone. Da kann man nur über Vektorisierung GeoJSON draus machen, also über manuelles oder automatisches Nachverfolgen von Linien.

Wenn dein Ziel GeoJSON ist, würde ich das mit QGis machen, denn soweit ich weiss kann der JOSM kein GeoJSON exportieren (obwohl JOSM und JSON so gleich klingen).

Alternativ kannst du den JOSM zum Digitalisieren verwenden, das OSM-XML lokal bei dir auf Platte speichern und dann mit (beispielsweise) ogr2ogr in ein geojson konvertieren, aber da weiss ich nicht, wie gut das Ergebnis ist.

...oder ich verstehe dich falsch und du willst ganz was anderes.

selphiron wrote:

Ich bin so verfahren wie beschrieben wurde und habe und es wird alles korrekt dargestellt. Allerdings habe ich das nicht ganz verstanden, was das jetzt zu bedeuten hat.

Und wenn das alles zu kompliziert/aufwändig wird würde ich mich über eine Methode freuen, wie man von EPSG:3068 zu EPSG:4326 bzw. WSG84 umwandeln kann.

Ich habe auch noch ein bisschen mit dem WMS gespielt. Auch wenn ich die URL nehme, die JOSM verwendet, kommt der Versatz, sobald der runtergeladene Ausschnitt größer wird. Vermutlich ist der auch bei der 500x500-Kachel von JOSM drin, nur da sieht man ihn nicht, weil er zu klein ist. Ich vermute, die Stadt hat eine Karte in EPSG:3068. Wenn man die in EPSG:4326 abfrägt, rechnet der WMS nur die Eckpunkte um und stanzt dann eine Kachel aus, statt sie neu zu rendern. Dabei passiert dann dieser Spalt zwischen Kacheln.

Falls diese Vermutung stimmt, könntest Du einfach kleinere Ausschnitte runterladen und die zusammensetzen. Nimm mal statt 100 Kachel z.B. 2000 Kacheln.

Umrechnen zwischen Soldner- und WGS84-Koordinaten geht mit cs2cs aus dem proj4-Paket.

Wo solls denn eigentlich hingehen?

Willst Du POIs aus OSM auf diese Karte plazieren? Dann bleib bei EPSG:3068 und rechne die Koordinaten der POIs um.

Oder willst Du die Arbeitslosenquote aus der Karte über eine OSM-Karte legen? Dann musst Du nicht umrechnen, sondern die Grafik pro­ji­zie­ren. Mapproxy kann sowas oder Mapserver (sagt man, gemacht hab ich das noch nie)

Grüße, Max

Danke für die Antworten

@gormo: Mein Ansatz die Polygone rauszunehmen geht über PNG Dateien und mit gdal_polygonizer. Dafür wäre mir am liebsten die gesamte Karte in einer hohen Auflösung als 1 Bild zu haben aber da spielt der Server nicht mit. Deshalb musste ich Kacheln erzeugen, die einerseits klein genug sind, andererseits aber die nötige Auflösung haben und es sollten der Effizienz wegen nicht all zu viele Kacheln sein (wobei das eine geringere Rolle spielt).
Deinem Vorschlag mit ogr2ogr werde ich nachgehen, wenn meine bisherige Vorgehensweise nicht klappt

@maxbe: "Wo solls denn eigentlich hingehen? "

Die Stadt Berlin gibt sehr viele Kartenmaterial über WMS frei (hier eine Liste der Datensätze)
Leider sind JPEGs und PNGs nicht sehr geeignet um damit zu Arbeiten. Ich möchte die zur Verfügung gestellten Daten in GeoJSON umwandeln um damit mehr erreichen zu können. Dies würde sehr viele Möglichkeiten eröffnen mit den Daten zu arbeiten.
Ich habe eine Möglichkeit gefunden die Polygone aus den Kacheln in GeoJSON zu übertragen. Allerdings brauche ich ja die Koordinaten der Eckpunkte für die Polygone. Zurzeit werden die Polygone so kodiert, als sei die obere linke Ecke der Kachel der Punkt (0,0).
Ich brauche also lediglich die Geokoordinaten der oberen linken Ecke jeder Kachel. Dann kann ich mir die Geokoordinaten der Eckpunkte der Polygone berechnen.
Die vielen erzeugten GeoJSONs kann ich dann ganz leicht zu einer ganzen vereinen und es dann z.B. wieder auf eine OSM-Map rauflegen. Ich versuche sowohl die Idee mit den 2000 Kacheln, als auch das cs2cs aus dem proj4-Paket. Ich hoffe es gibt eine nicht allzu komplizierte Möglichkeit da programmatisch ranzugehen, da ich vorhabe eine Art Tool dafür zu erstellen.

fg
Selphiron

selphiron wrote:

Ich brauche also lediglich die Geokoordinaten der oberen linken Ecke jeder Kachel. Dann kann ich mir die Geokoordinaten der Eckpunkte der Polygone berechnen.

Du solltest bei WGS84 bleiben und 3068 meiden, oder jedenfalls auf keinen Fall die Koordinatensysteme mischen. Das Koordinatengitter bei EPSG3068 steht ein bisschen schräg (Hier am nach links hängenden westlichen Rand deutlich zu sehen, die x=40000-Linie zeigt nach Norden, links davon ist alles leicht nach rechts gekippt). Eine quadratische Kachel in 3068 ist ein schräg liegendes Trapez in WGS84 und umgekehrt. Das müsstest Du immer berücksichtigen, wenn Du deine Polygone nach den Eckpunkten berechnest.

Hmm also was wäre dann dein Vorschlag? Lieber EPSG:4326 benutzen und irgendwie die Spalten wegkriegen? Ich habe mir folgendes überlegt: Wie wäre es wenn ich die Kacheln nicht vollständig benachbart mache sondern so, dass sie sich mit allen benachbarten (sagen wir so um 10%) überschneiden? Dann hätte ich manche Polygone mehrfach aber das ist ja egal, da die Koordinaten der Polygone gleich sind und diese sozusagen aufeinander liegen werden. Oder hast du einen besseren Vorschlag?

selphiron wrote:

Hmm also was wäre dann dein Vorschlag? Lieber EPSG:4326 benutzen und irgendwie die Spalten wegkriegen? Ich habe mir folgendes überlegt: Wie wäre es wenn ich die Kacheln nicht vollständig benachbart mache sondern so, dass sie sich mit allen benachbarten (sagen wir so um 10%) überschneiden? Dann hätte ich manche Polygone mehrfach aber das ist ja egal, da die Koordinaten der Polygone gleich sind und diese sozusagen aufeinander liegen werden. Oder hast du einen besseren Vorschlag?

Ich sehe zwei Möglichkeiten:

(1) Die Kacheln in EPSG:4326 holen, aber in kleinen Stücken von z.B. 300x300 Pixeln. In der Auswertung berücksichtigen, dass auch mal eine Kurve um 1 oder 2 Pixel an der Grenze springen kann.

(2) Alles in EPSG:3068 holen. Dann stur in EPSG:3068 weitermachen und auch die Polygone in EPSG:3068 ausrechnen. Ganz zum Schluss dann die einzelnen Eckpunkte dieser Polygone in EPSG:4326 umrechnen, damit man mit der Welt ausserhalb Berliner Ämter auch klar kommt.

Ich würde (2) wählen. EPSG:3068 ist ja eigentlich ein schönes System. Und man hat nicht den Ärger mit den Sprüngen an der Kachelgrenze.

Grüße, Max

Ja das klingt in der Tat gut. Vielen dank für die Hilfe. Ich melde mich dann wenn ich Probleme mit der Umwandlung habe 😄

Falls du Windows nutzt, schenkt dir die Stadt noch ein passendes Programm zum Umwandeln. Dann musst du zwar immer "Geoportal Berlin / Trans3win" dazuschreiben, dafür hast du die amtliche Umrechnung, die "Sprünge bis in den Dezimeterbereich" verspricht, was ich ziemlich genau finde.

hmm danke aber wenn ich das richtig verstanden habe muss man sich da durchklicken.

Ich brauche eher etwas was ich in mein Programm einbinden kann und das mehr über Befehle geht.

Hmm habe nun doch das Programm probiert und bin nach der Schritt-für-Schritt im Readme mit den Musterdaten vorgegangen aber es kommt ein Fehler (2001tr0\DEFAULT kann zum Lesen nicht geöffnet werden) und das obwohl ich alles so gemacht habe wie in den Screenshots und der Beschreibung dargestellt wurde. Gibt es was anderes? Du hattest mir ja im Thema für kleine Fragen eine andere Möglichkeit gezeigt. Könntest du bitte mehr darüber berichten?

selphiron wrote:

Du hattest mir ja im Thema für kleine Fragen eine andere Möglichkeit gezeigt. Könntest du bitte mehr darüber berichten?

Trans3win kann ich auch nicht ausprobieren, hab kein kompatibles Betriebssystem.

Ich würde irgendwas aus proj.4 nehmen. Das kann entweder Dateien umwandeln (mit cs2cs):

Ausgangsdaten ("soldner.txt" mit 2 Werten pro Zeile, erst Rechtswert, dann Hochwert)

20000␣20000
30000␣20000
30010␣20000
40000␣10000

Umwandlung mit vermutlich passenden Parametern liefert die Längen- und Breitengrade (und eine Höhe als dritte Spalte, kannst aber in diesem Fall vergessen):

cs2cs␣+proj=cass␣+lat_0=52.41864827777778␣+lon_0=13.62720366666667␣+x_0=40000␣+y_0=10000␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+ellps=bessel␣-f␣"%5f"␣soldner.txt
13.332606␣␣␣␣␣␣␣52.508158␣0.000000
13.479904␣␣␣␣␣␣␣52.508433␣0.000000
13.480051␣␣␣␣␣␣␣52.508434␣0.000000
13.627204␣␣␣␣␣␣␣52.418648␣0.000000

(Die "vermutlich passenden Parameter" bei "towgs84" sind Gegenstand eifriger Spekulationen)

Proj.4 wird auch von den gdal-Tools verwendet (ogr2ogr z.B.) und man kann das auch als Bibliothek in eigene Programme einbinden. Da hab ich aber keine Erfahrung, ausser mit der JavaScript-Version (das ist die, die dir hier unten rechts die Koordinaten des Mauszeigers umrechnet).

Grüße, Max

danke hat soweit funktioniert aber es ist viel zu ungenau. Es verschätzt sich um ein paar KILOmeter. Für die Koordinaten
24120 18520 spuckt er mir 13.393363 52.494992 aus aber laut dieser Seite müsste es 13.30885 52.54375 sein. Sollte ich andere towgs werte ausprobieren, die in dem von dir verlinkten Thema aufgelistet sind?
Ach und noch ein paar Fragen: Warum ausgerechnet diese Parameter? (+lat_0=52.41864827777778 +lon_0=13.62720366666667 +x_0=40000 +y_0=10000)
Und wie kann ich das Ergebnis in eine Textdatei schreiben?

FG Selphiron

selphiron wrote:

danke hat soweit funktioniert aber es ist viel zu ungenau. Es verschätzt sich um ein paar KILOmeter. Für die Koordinaten
24120 18520 spuckt er mir 13.393363 52.494992 aus aber laut dieser Seite müsste es 13.30885 52.54375 sein. Sollte ich andere towgs werte ausprobieren, die in dem von dir verlinkten Thema aufgelistet sind?

Die Frage der richtigen Parameter für towgs ist eine Frage von 1-5 Metern, nicht Kilometern. Da muss irgendwas anderes schief gelaufen sein. Ich bekomme (13.393363, 52.494992) raus.

Kann es sein, dass Du Rechts- und Hochwert verwechselst? Das ist ein bisschen verwirrend, weil in diesem EPSG:3068-Koordinatensystem "X" nach oben zeigt und "Y" nach rechts. cs2cs verwendet "x" für "Rechts" und "y" für "Oben". Deshalb vermeide ich auch "x/y" und versuche immer von "Rechts" und "Hoch" zu reden....

Ach und noch ein paar Fragen: Warum ausgerechnet diese Parameter? (+lat_0=52.41864827777778 +lon_0=13.62720366666667 +x_0=40000 +y_0=10000)

proj=cass: Die Arte der Projektion, Benannt nach irgendeinem Cassini, ich glaube, César François.

lat_0,lon_0: "52.418 Nord 3.627 Ost" ist der "Nullpunkt" des Systems. Früher stand da mal ein Turm, heute ein verfallenes Restaurant. Der heutige Turm steht verwirrenderweise wohl nicht auf dem Platz des alten, sondern ein Stück daneben.

x_0=40000 y_0=10000: Damit man keine negativen Koordinaten bekommt, hat man willkürlich diesen "Nullpunkt" nicht auf (0,0) sondern auf die Koordinate Hochwert=10km, Rechtswert=40km gesetzt.

+ellps=bessel: Das verwendete Ellipsoid. Die Umrechnung der Ellipsoide ist ein bisschen knifflig, dazu braucht man die "towgs"-Parameter (die geben so ungefähr an, wie das Ellipsoid für WGS84 relativ zum Bessel liegt).

Und wie kann ich das Ergebnis in eine Textdatei schreiben?

ich würde "cs2cs +proj=cass ... soldner.txt > meinekoordinaten.txt" tippen.

Grüße, Max

meinekoordinaten.txt hat funktioniert danke. Und als ich die Koordinaten getausch habe wurde es wesentlich besser (190 meter). Ist das denn genau? 🙂

selphiron wrote:

Ist das denn genau?

Nicht wirklich... Das liegt daran, dass sowohl diese Seite mit dem Gitter falsch umgerechnet hat (das Gitter stimmt, aber die Mausposition nicht. Das ist mir peinlich und jetzt gibt sie auch keine Mausposition mehr aus...), als auch wir mit cs2cs (was schlimmer ist...).

Diese 190 Meter kommen zustande, weil cs2cs aus irgendeinem Grund die Ellipsoiden nicht umgerechnet hat. Vielleicht kann uns ein Kundiger erhellen, was an dem Aufruf falsch ist...

Abhilfe: Du musst irgendwo eine Datei rumliegen haben, wo die Parameter für EPSG drinstehen. Bei Unixen ist das oft "/usr/share/proj/epsg", bei Windows könnte das "C:\PROJ\epsg" oder so sein. Da stehen alle EPSG-Codes drin, die proj.4 schon kennt. Solltest Du dort 3068 nicht finden, schreibe eine Zeile dazu, ansonsten ersetze die vorhandene:

<3068>␣+proj=cass␣+lat_0=52.41864827777778␣+lon_0=13.62720366666667␣+x_0=40000␣+y_0=10000␣+ellps=bessel␣+units=m␣towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+no_defs

Dafür musst Du danach nie wieder so lange Zeilen tippen, sondern:

cs2cs␣+init=epsg:3068␣+to␣+init=epsg:4326␣-f␣"%2f"␣soldner.txt

Zum Testen: Die Koordinate (40000 10000) liegt bei WGS84 nicht bei (13.6272,...), also bei lon_0. Vielmehr liegt sie bei 13.6254, was dem transformieren Längengrad entspricht.

Grüße, Max

Ich habs...

cs2cs␣+proj=cass␣+lat_0=52.41864827777778␣+lon_0=13.62720366666667␣+x_0=40000␣+y_0=10000␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+ellps=bessel␣+to␣+proj=latlong␣+datum=WGS84␣␣-f␣"%5f"␣soldner.txt

Wenn man nicht explizit das gewünschte Ausgabedatum dazuschreibt ("+to +proj=latlong +datum=WGS84"), hat cs2cs keine Lust, die Ellipsoiden umzurechnen. Mit der Angabe haut es hin.

Ah jetzt sind es nichtmal 4 Meter 🙂 Sehr gut vielen dank. Ist wahrscheinlich nicht wichtig aber ist die 3. Spalte immernoch die Höhe?

selphiron wrote:

Ah jetzt sind es nichtmal 4 Meter 🙂 Sehr gut vielen dank. Ist wahrscheinlich nicht wichtig aber ist die 3. Spalte immernoch die Höhe?

Fein. Jetzt könntest noch die passenden Werte für towgs aus dem verlinkten Thema nehmen und ändern. Vielleicht schaffst auch 2 Meter. Was aber bei sozialen Strukturdaten auch wieder nicht so wichtig ist 😉

Die dritte Spalte ist der Höhenunterschied der beiden Ellipsen, nicht die Höhe über einem Meer oder so, also eher unbrauchbar.

Ja also mit den Werten aus dem verlinkten Thema wird es nicht wesentlich besser (mal besser mal schlechter) aber die paar Meter stören mich nicht. Ach meinst du es gibt eine Möglichkeit, wie ich dem cs2cs sagen kann, dass er eine GeoJSON-Datei bekommt und alle Werte darin umwandelt? Sonst würde ich das selber schreiben.

selphiron wrote:

Ach meinst du es gibt eine Möglichkeit, wie ich dem cs2cs sagen kann, dass er eine GeoJSON-Datei bekommt und alle Werte darin umwandelt?

cs2cs kanns nicht, glaube ich.

Bei diesem gdal-Zeug ist ein Programm namens "ogr2ogr" dabei. Das kenne ich nur zum Umwandeln von Shapefiles, aber es soll auch geojson können. Ich weiss aber nicht, ob es alle Versionen und Elemente von geojson erkennt. Kannst ja mal diese Datei in WGS84 und diese in EPSG3086 ausprobieren. Die erste sind ein paar Parks in Berlin, die mir Overpass Turbo geliefert hat, die zweite die umgewandelte Version.

Erzeugt wurde die WGS84-geojson mit

ogr2ogr␣-f␣"GeoJSON"␣parks_wgs84.geojson␣parks_soldner.geojson␣-s_srs␣EPSG:3068␣-t_srs␣EPSG:4326

(s_srs ist für "source", t_srs für target. Diese Schreibweise setzt voraus, dass Du 3068 in diese in #16 erwähnte Datei /usr/share/proj/epsg einträgst. Solltest sowieso machen, dann tippst du nicht immer so viel)

Grüße, Max

Hmm also wenn ich das mache wird statt diesen Koordinaten 13.399628, 52.517800 diese angezeigt: 13.39962482791635, 52.517798852231934 Danke, ich glaube die Abweichung kann man vertragen oder? 🙂