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

[pfeffer]

ok, ich habe noch etwas weiter getestet:
Der WMS von NRW liefert, wenn man eine Karte anfordert, dessen linke untere und rechte obere Ecke in unterschiedlichen Gauß-Krüger-Streifen liegen, offenbar immer die Karte in der Projektion, in der sich die rechte obere Ecke (oder die Mitte?) befindet und ignoriert die Angabe der geforderten Projektion. Dagegen liefert der Service korrekt kalibrierte (umprojizierte) Bilder, wenn man ein Bild innerhalb eines Streifens anfordert und zwar auch dann, wenn man eine Projektion aus dem Nachbarstreifen anfordert.

Gruß,
Pfeffer.

 

[Black-Jack-Team]

Dann wäre doch der einfachste Lösungsansatz für diesen Server nur Kacheln anzufordern, die nur bis zur Grenze gehen, oder?

 

[pfeffer]

wenn das mal so einfach wäre... dazu müssen die Kacheln ja kleiner als 1000x1000 werden und die Methode, die dafür zuständig ist, hat gegenwärtig nicht das recht, sich selbst auszusuchen, wie große das Bild werden soll - mal sehen, was ich da mache.

Gruß,
Pfeffer.

 

[Black-Jack-Team]

wenn das mal so einfach wäre... dazu müssen die Kacheln ja kleiner als 1000x1000 werden - mal sehen, was ich da mache.

Gruß,
Pfeffer.

Nein nicht nötig! Nur die Überlappung müsste für die Kachel links und die Kachel rechts der Grenze angepasst werden. Die Kachel darf schon 1000x1000 bleiben!
Diese beiden Kacheln dürfen sich dann wohl auch nicht überlappen.

 

[greiol]

mal sehen, was ich da mache.

nachsehen ob die neben einem wms server auch einen bugzilla haben? :-\

 

[pfeffer]

tjo, die Leute vom NRW-Vermessungsamt sind zwar nett - aber beheben tun sie die Fehler eh nicht, denn dazu müssten sie die beauftragte Firme erneut beauftragen oder zumindest denen Ärger machen... und dazu haben sie einfach keine Lust (da arbeiten wohl zuwenig Sadisten ;-ö ).

Ich habe mir den CacheWolf code jetzt nochmal genauer angeguckt:
Es wäre doch möglich, die Pixelgröße zu reduzieren alternativ den Ausschnitt zu verschieben theoretisch auch. Allerdings ist diese Sache doch recht aufwändig (zB muss man diese Grenze ja erstmal ermitteln).

Deswegen mein Vorschlag: Wenn ein Karte geladen werden soll, die Punkte aus 2 üblicherweise unterschiedlich projizierten Gebieten enthält, verweigert CacheWolf das Hernuterladen und gibt eine entsprechende Fehlermeldung aus. Das halt ich für besser als eine falsch kalibrierte Karte plötzlich darunter zu haben. Was meint Ihr?

Das Problem ist, dass wir nicht wissen, ob alle Server diesen Fehler haben. Vielleicht kannst Du da mal noch Stichpriben bei den anderen WMS machen?

Gruß,
Pfeffer.

 

[MiK]

Deswegen mein Vorschlag: Wenn ein Karte geladen werden soll, die Punkte aus 2 üblicherweise unterschiedlich projizierten Gebieten enthält, verweigert CacheWolf das Hernuterladen und gibt eine entsprechende Fehlermeldung aus. Das halt ich für besser als eine falsch kalibrierte Karte plötzlich darunter zu haben. Was meint Ihr?

Wenn man dann dummerweise an so einer Grenze wohnt, hat man Pech gehabt und bekommt keine Karten. Aber Du hast Recht: Den Kachelcode so zu ändern, dass er sich an diesen Grenzen ausrichtet, ist wohl etwas größerer Aufwand.

 

[Black-Jack-Team]

... Aber Du hast Recht: Den Kachelcode so zu ändern, dass er sich an diesen Grenzen ausrichtet, ist wohl etwas größerer Aufwand.

Tatsächlich?
Wie ist das denn programmiert?
Es muss doch nur die letzte Kachel (die erste, die die Grenze überschreitet) westlich der Grenze E 7° 30' , E 10° 30' usw. auf die Grenze nach links also Westen verschoben werden.
Der nächste Anfang dann auf der Grenze usw.

Liegt das Problem in der Bestimmung des Ostwertes westlich der Grenze um dann mit 1000 Pixeln möglichst nahe an die Grenze zu kommen ohne sie zu überschreiten?
Kann man das nicht ggf. iterativ lösen?

 

[pfeffer]

klar kann man das "iterativ" machen - ineffizienter geht es kaum - hmm... dafür müsste man aber immerhin nicht eine zusätzliche Schnittstelle auf der tieferen Ebene einbauen, und da es nur wenn man besonderes Pech hat, häufig vorkommt, könnte man es in Kauf nehmen... hmmm... trotzdem aufwändig: wie soll ich entscheiden, in welche Richtung ich es verschieben soll?
Ich würde sagen, in die Richtung, in der ohne Verschiebung schon mehr drauf ist. Aber, um das entscheiden zu können, muss ich die Grenze wissen -> also einmal nach Osten, einmal nach Westen schieben und dann dasjenige nehmen, bei dem die Verschiebung kleiner war? (Ineffizienz noch mal verdopplet)
Vielleicht ist eine zusätzliche Funktion im GKPoint doch nicht so aufwändig. Das Problem dabei: es geht nicht einfach x Grad als Grenze, weil CacheWolf intern normalerweise überall in WGS84 und nicht mit Bessel, Potsdam arbeitet...

Gruß,
Pfeffer.

 

[Black-Jack-Team]

Imho muss die fragliche grenzüberschreitende Kachel immer nur nach Westen verschoben werden, weil Cachewolf die Karten "zeilenweise in Leserichtung" also West>Ost dann Nord>Süd lädt.
Wenn die Kachel erfolgreich verschoben wurde, setzt die nächste Kachel ohne Überlappung östlich davon an der erkannten Grenze neu auf.

Oder habe ich da was flasch verstanden?

 

[pfeffer]

Ich hätte es jetzt so gemacht, dass es keine Rückkopplung der einmaligen Verschiebung der Kachel zu der Methode gibt, die sagt welche Kacheln heruntergeladen werden. Vielmehr würde die Kachellagemethode einfach nicht genau die Kachel laden, die ihr "befohlen" wurde, sondern eine verschobene.

EDIT: noch ein mögliches Problem bei der Verschieben-Methode: Was soll passieren, wenn der Maßstab so gewählt ist, dass es nicht möglich ist, durch Verschieben einen Ausschnitt zu bekommen, der nur 1 GK-Streifen enthält?

Gruß,
Pfeffer.

 

[MiK]

Ich hätte es jetzt so gemacht, dass es keine Rückkopplung der einmaligen Verschiebung der Kachel zu der Methode gibt, die sagt welche Kacheln heruntergeladen werden. Vielmehr würde die Kachellagemethode einfach nicht genau die Kachel laden, die ihr "befohlen" wurde, sondern eine verschobene.

An sowas habe ich jetzt auch gedacht. Allerdings sollten an dieser Stelle dann zwei anstatt einer verschobenen Karte geladen werden. Eine westlich und eine östlich der Grenze. Sonst fehlt ja der Teil zwischen der Grenze und der nächsten Kachel.

 

[Black-Jack-Team]

...noch ein mögliches Problem bei der Verschieben-Methode: Was soll passieren, wenn der Maßstab so gewählt ist, dass es nicht möglich ist, durch Verschieben einen Ausschnitt zu bekommen, der nur 1 GK-Streifen enthält?

Gruß,
Pfeffer.

Wenn der Maßstab so groß ist, dass 1000 Pixel 3° entsprechen, dann wird die minimale Verschiebung nicht merkbar sein.
oder meintest Du etwas anderes?

 

[pfeffer]

@MiK: 2 statt 1 Laden ist nicht so leicht, dafür ist die Abstraktion an der falschen Stelle

@Black-Jack-Team: ja ich meinte was anderes. Was soll passieren, wenn es nicht möglich ist, den Ausschnitt so zu verschieben, dass keine GK-Streifengrenze überschritten wird.

Gruß,
Pfeffer.

 

[MiK]

@MiK: 2 statt 1 Laden ist nicht so leicht, dafür ist die Abstraktion an der falschen Stelle

Wenn wir durch den Workaround nicht alles abdecken können, ergibt er auch keinen Sinn. Ob jetzt eine ganze oder eine halbe Kachel fehlt, macht für mich nicht den großen Unterschied. Die Frage ist, wie aufwendig es wäre, es so umzubauen, dass es geht. Wo ist denn die entscheidende Stelle?

 

[pfeffer]

solange der Server den Fehler macht, kann es nicht "ganz gehen". Zumindest muss auf jegliche Überlappung verzichtet werden.

Ich sehe keinen Sinn darin, jetzt an dieser Stelle viel Aufwand zu betreiben, denn, wenn tatsächlich die Umstellung auf viele kleine Kacheln gleichzeitig anzeigen in der MovingMap kommt, dann muss/sollten die Kacheln ohnehin nicht mehr so willkürlich wie jetzt, sondern an einem weltweiten Raster (oder am Raster der jeweiligen Projektion) ausgerichtet heruntergeladen werden.

Gruß,
Pfeffer.

 

[MiK]

Das keine Überlappung geht ist klar. Aber man hat zumindest für überall eine Karte.

Ich kann mir das auch nochmal anschauen. Aber wenn Du sagst, dass das größerer Aufwand ist, dann wird es schon stimmen.

Wie soll das mit dem weltweiten Raster dann bei 1 Karte pro Cache funktionieren?

 

[pfeffer]

Wie soll das mit dem weltweiten Raster dann bei 1 Karte pro Cache funktionieren?

1 Karte pro Cache macht bei 256x256 großen Kacheln kaum Sinn. Da müsste man schon einen Umkreis um jeden Cache laden.

Gruß,
Pfeffer.

 

[Black-Jack-Team]

...@Black-Jack-Team: ja ich meinte was anderes. Was soll passieren, wenn es nicht möglich ist, den Ausschnitt so zu verschieben, dass keine GK-Streifengrenze überschritten wird.

Wie soll das gehen? Dann wäre doch die unmittelbar vorherige Kachel bereits bis an die Grenze gegangen und nur die Überlappung würde westlich der Grenze liegen.
Dann würde ich nach Osten verschieben und unmittelbar rechts (östlich der Grenze) einlesen.
Eine wie auch immer geartete Überlappung darf es ja bei diesem Server wohl nicht geben.

 

[pfeffer]

hmmm... ich kann - anders als ich gestern dachte - doch nicht angeben, unter welchen Bedinungen der Fehler auftritt.

http://www.geoserver.nrw.de/GeoOgcWms1.3/servlet/TK25?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:31466&BBOX=2602682.61,5701612.97,2606843.04,5705445.85&WIDTH=1000&HEIGHT=1000&LAYERS=Raster%3ATK25%5FKMF%3AFarbkombination&STYLES=&FORMAT=image/png

liefert ein nicht korrekt kalibriertes Bild. Ich dachte der Fehler läge daran, dass es über die 7,5° Grenze hinweg geht. Deswegen habe ich aus dieser Anfrage eine gebeastelt, die nur die linken 100px liefert und damit vollständig links von 7,5° liegen dürfte:

http://www.geoserver.nrw.de/GeoOgcWms1.3/servlet/TK25?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:31466&BBOX=2602682.61,5701612.97,2603098.65,5705445.85&WIDTH=100&HEIGHT=1000&LAYERS=Raster%3ATK25%5FKMF%3AFarbkombination&STYLES=&FORMAT=image/png

wenn dieses Bild richtig kalibriert wäre, dann müsste es gegenüber dem erstgenannten verschoben sein. Ist es aber nicht :-(

Außerdem tritt der Fehler nicht grundsätzlich auf. bei der de.topo habe ich ihn nicht feststellen können.

Insgesamt: Solange wir nicht vorhersagen können, wann der Fehler genau auftritt, könne wir nichts dagegen tun :-(

Gruß,
Pfeffer.