Cachewolf-Karten (*.wfl) nach Ozi (*.map) konvertieren?

[MiK]

Die MovingMap ist das einzige was mich noch stört am CW, bzw. der Punkt, indem der CW mMn wirklich gegenüber anderen Programmen auf dem PDA hinterher hinkt. Ein ähnlich flüssige Darstellung wie z.B. in Glopus wär ein Traum

Ein bisschen was ist bestimmt noch drin. Aber so schnell wie nativer Code werden wir mit EWE/EVE wohl nie werden.

Ich hatte vor längerem bereits einen Blick in den entsprechenden Code geworfen und das erste was mir auffiel war die Tatsache, daß die Map-Grafiken IMMER als RGBA geladen werden, also mit 32 Bit / Pixel, auch wenn ich z.B. Karten als PNGs mit 4 Bit Farbtiefe verwende.

Um etwas schnell anzeigen zu können, muss man die Daten normalerweise so vorhalten, wie es die Anzeigeroutinen dann haben wollen. Und das ist normalerweise eben die Farbtiefe des Displays.

 

[klausundelke]

Die MovingMap ist das einzige was mich noch stört am CW, bzw. der Punkt, indem der CW mMn wirklich gegenüber anderen Programmen auf dem PDA hinterher hinkt.

Sehe das ähnlich, ich finde für ein Programm, das nur auf freiwilliger Basis programmiert wird, ist hier schon ganz erstaunliches geleistet worden. Meine Hochachtung!

Ich hab keine Ahnung ob das mit ewe/eve überhaupt zu realisieren ist, aber schaut mal
beim GPSTuner. Die Möglichkeiten der Moving Map in diesem Programm finde ich
ideal. Auch die Darstellung wahlweise mit Titelleiste auf der auch eine (eingeschränkte) Anzeige zur Navigation eingeblendet werden kann ist super.

Gruss
Klaus

 

[Wortfetzen]

Ein bisschen was ist bestimmt noch drin. Aber so schnell wie nativer Code werden wir mit EWE/EVE wohl nie werden.

Ja das stimmt wohl leider ps:

Um etwas schnell anzeigen zu können, muss man die Daten normalerweise so vorhalten, wie es die Anzeigeroutinen dann haben wollen. Und das ist normalerweise eben die Farbtiefe des Displays.

Klar, aber deswegen kann ich z.B. auf dem PDA in der Karte überhaupt nicht zoomen. Jeglicher Versuch zu zoomen wird mit einem Speichererror quittiert.

Eine kurze Untersuchung mit jconsole ergab damals auch, daß beim ersten Anzeigen der Karte etwa 40 MB im Speicher alloziiert wurden (auf der Workstation) für ein PNG, welches - ungepackt - etwa 12 MB belegen sollte (4 Bit-Colormap).

Mein Vorschlag wäre, später mal zu untersuchen, ob es tatsächlich soviel langsamer ist die Map-Daten z.B. als TYPE_INDEXED_256 oder TYPE_INDEXED_4 zu verwenden statt TYPE_ARGB.

 

[Black-Jack-Team]

Sind die *.wfl-Dateien an Grenzen der Streifen der Merkator-Projektion eventuell nicht korrekt?

Ich stelle diese Frage deswegen, weil MapMerge die Karten bei Ost 7° 30' nicht korrekt zusammensetzen kann.
Kann es sein, dass hier eine falsche Kalibrierung der Kartenstücke vorliegt, die die Streifengrenze überschreiten?
Die Streifengrenzen liegen jeweils bei 1,5 ° östlich und westlich der Streifenmitte. Die Streifenmitten sind bei E 0° 3° 6° 9° usw.
Also müsste das Problem sich bei E 7° 30' E 10° 30' E 13° 30' usw. eigentlich wiederholen.
Wohlgemerkt, die Kartenkachel sieht korrekt aus (mit den üblichen Abweichungen wie andere Strichbreiten, andere Höhenlinienstückelung usw.).
Nur die 4-Punkt-Kalibrierung erscheint mir nicht ganz koscher.

 

[pfeffer]

werden Caches in CacheWolf nicht an der richtigen Stelle in der Karte angezeigt?

Manche WMS liefern die Karten nicht in einem Gauß-Krüger-Streifen, auch wenn das abgedeckte Gebiet darüber hinaus geht.

Aber dass sich Karten nicht schnittfrei an den Grenzen der Streifen zusammensetzen lassen, ist quasi das Prinzip der Gauß-Krüger-Projektion.

Ich vermute, alles ist korrekt.

Gruß,
Pfeffer.

 

[Black-Jack-Team]

Konkret ging es hier um die Topo25 NRW, bei der das Problem aufgetreten ist.

Wie gesagt, konnte MapMerge die Kartenkacheln, die die Grenze überschreiten, nicht korrekt untereinander oder mit anderen Karten zusammensetzen. Ein Streifen Nord-Süd von mehreren dieser fraglichen Kacheln an der Grenze 7° 30' konnte nicht korrekt verarbeitet werden. Es wurden quasi Schattenbilder eingefügt mit horizontalem Versatz, schwer zu beschreiben.
Ansonsten verursacht MapMerge eigentlich keine Fehler. Die zusammengesetzten Riesen-Karten (Topo25 mit ca. 27 Km Kantenlänge, Topo50 mit 80 Km Kantenlänge) sind korrekt und auch sehr gut kalibriert.
Vielleicht liegt es aber auch an greiols Tool, dass aus den *.wfl die *.map-Dateien macht.
Rätselhaft...

 

[pfeffer]

na, ich verstehe nicht, was Dir rästelhaft ist.
Karten aus unterschiedlichen Streifen können einfach nicht ohne Lücken/Weglassungen zusammengesetzt werden. Sonst bräuchte man ja nicht unterschiedliche Streifen.

Mach Dich mal über Kartenprojektionen schlau, dann verstehst Du es vielleicht.


Gruß,
Pfeffer.

 

[Black-Jack-Team]

Hallo pfeffer,
das ist mir sehr wohl klar. Nur warum liefert der wms-server passende stimmige(!) Kacheln mit 1000x1000-Pixeln über die Projektionsgrenzen aus?
Und warum habe ich (leider alte) Topo25- und Topo50-Karten für Ozi, die korrekt über die 3°-Streifengrenzen hinaus gehen? Man kann wie gesagt an zeichnerischen Deatails schon gut erkennen, wo die Streifengrenze ist, aber ein kontinuierliches Moving-Map geht auch damit. Warum auch nicht, es ist ja nur eine Projektion in die Ebene. Wenn das abgebildete Areal nicht allzu groß ist, halten sich die Verzerrungen ja auch in Grenzen. Unser Planet ist ja schließlich doch etwas größer als ein Golfball... []

Rechnet der wms-Server eventuell was spezielles an diesen Stellen?

P.S.: Für Mitleser: Interessante fundierte Infos zum Thema Projektionen gibt es hier:
http://www.kowoma.de/gps/geo/Projektionen.htm

 

[pfeffer]

manche WMS lieferen eben Karten an den Grenze der Streifen (oder sogar komplett) in beiden Streifen, je nach dem, welcher Streifen angefragt wurde. Sie projizieren das Kartenbild entsprechend um. Das macht aber weder CacheWolf noch MapMerge (offensichtlich). MapMerge hat ja auch gar nicht die dafür nötige Information (d.h. die genauen Parameter der Projektion).

Gruß,
Pfeffer.

 

[Black-Jack-Team]

Dann ist für mich die Lösung offensichtlich. Wir brauchen Kacheln, die genau an den Grenzen enden.
Bei der Serveranfrage müsste das entsprechend an diesen Stellen angegeben werden.

 

[pfeffer]

bislang wird er xport eben nicht unterstützt. Aber Du hast Recht: wenn es irgendwann unterstützt werden sollte, dann müsste darauf geachtet werden. Nur steht das zur Zeit bnicht an.

Gruß,
Pfeffer

 

[Black-Jack-Team]

Nicht nur für den Export.!
Mittlerweile bezweifle ich ernsthaft, dass die Cachewolf-Karte bzw. die Cachewolf-moving-map auf den besagten Kacheln korrekt arbeitet!
D.h. eventuell werden Caches und Wegpunkte an falschen Stellen angezeigt und das moven wird eventuell auch nicht auf den korrekten Stellen an der Karte angezeigt.
Das kann ich aber nicht so ohne weiteres verifizieren - ich wohne leider zu weit weg, um das mal eben auszuprobieren. []

Die betroffenen Kacheln sind übrigens 2,5x2,5 Kilometer groß (bei Topo25) bzw. 5x5 Kilometer bei Topo50. Also nicht so ganz nebensächlich.

 

[pfeffer]

Mittlerweile bezweifle ich ernsthaft...

Wie kommst Du auf die Idee - dafür hast Du keinerlei Anhaltspunkte genannt.

Zum Überprüfen kannst Du versuchen, die die Umgebung von Caches in CacheWolf mit denen in Google zu vergleichen. Allerdings beachte dabei, dass auch GoogleEarth manchmal Fehler bis zu 5-10m hat.
Wenn Du also eine _systematische_ Verzerrung zum Rand der Gauß-Krüger-Streifen findest, dann gibt es irgendwo im WMS (oder in CacheWolf) einen Fehler.
Würde mich freuen, wenn Du das mal verifizieren könntest.

Gruß,
Pfeffer.

 

[Black-Jack-Team]

Ja, ich konnte jetzt tatsächlich eine gehörige Abweichung feststellen!

Und zwar z.B. beim Cache GCYKXB
Dieser wird auf meiner Topo deutlich unterhalb der Stromleitung angezeigt.
Im Cachewolf aber deutlich darüber! Nur ganz grob geschätzt 50 Meter und mehr Abstand!

Der Aufruf vom Cachewolf an den Server war:

rot left direkt: 181,15937193121
rot right direkt: 181,188622435067

51.46100003,7.48165237
rot left direkt: 181,15937193121
rot right direkt: 181,188622435067
http://www.geoserver.nrw.de:80/GeoOgcWms1.3/servlet/TK25?SERVICE=WMS&VERSION=1.1
.1&REQUEST=GetMap&SRS=EPSG:31466&BBOX=2603014.55,5701580.48,2605614.81,5703976.0
3&WIDTH=1000&HEIGHT=1000&LAYERS=Raster%3ATK25%5FKMF%3AFarbkombination&STYLES=&FO
RMAT=image/png

 

[pfeffer]

und in google-earth?
wo ist genau "in meiner Topo"?

 

[Black-Jack-Team]

Auf der Yahoo-map auf der Cachebeschreibungsseite, auf Google-Maps und auf meiner Topo50 des Gebietes werden drei Caches jeweils weiter südlich angezeigt als im Cachewolf. Ostwert stimmt wohl.
Ergo zeigt Cachewolf an der Stelle eine verschobene Karte an.
Damit liege ich mit meiner Vermutung wohl richtig, denke ich.

Edit: ich habe mal gemessen - es sind ca. 160 Meter Verschiebung nach Norden!

 

[pfeffer]

beim Karten herunterladen in CacheWolf:
was hast Du als Zentrum gesetzt? (oder hast DU "pro Cache") herunter geladen?
welchen Maßstab hast Du angefordert?

 

[pfeffer]

verdammter Mist. Die von Dir angegebene Karte ist tatsächlich irgendwie falsch kalibriert (mit einem Fehler von mehr als 50m). Diese Scheiß-WMS, die nicht standard konform arbeiten!

Hat Du schon herausgefunden (oder kannst es bitte noch), ob das Problem nur auftritt, wenn 2 GK-Streifen auf 1 Bild sind?

Danke,
Pfeffer.

 

[Black-Jack-Team]

Zentrum war N 51° 48.360' E 7° 43.270'
40 KM Umkreis Topo25 NRW

Ja, ich weiß, gibt ziemlich viele Kacheln. Aber Ziel ist ja auch die Herstellung ziemlich großer Karten!

 

[Black-Jack-Team]

...
Hat Du schon herausgefunden (oder kannst es bitte noch), ob das Problem nur auftritt, wenn 2 GK-Streifen auf 1 Bild sind?
...

Ja, alle anderen angeforderten Kacheln sehen korrekt aus. (nur stichprobenartig überprüft)

Eine Serie von 9 großen Kacheln Topo25 mit 27 KM Kantenlänge und eine riesige Topo50 mit 80 KM Kantenlänge hier aus meinem Gebiet habe ich erfolgreich im Einsatz.
Die Kalibrierung könnte nicht besser sein! Die Tracks liegen auf den Wegen und Straßen. Die Caches da, wo sie wirklich sind.