-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Luftbilder für NRW und Karten von beliebigen WebMapService
- Ersteller pfeffer
- Erstellt am
MiK
Geoguru
Das sieht schon recht gut aus. Bei mir funktioniert folgendes:Romanese schrieb:
Code:
Name: Hessen TK25
MainUrl: http://lika.hessen.de/cgi-bin/lika-services/de-viewer/access/ogc-free-maps.plx?
LayersName:
ServiceTypeUrlPart: SERVICE=WMS
VersionUrlPart: VERSION=1.1.1
CoordinateReferenceSystemCacheWolf: 31467
CoordinateReferenceSystemUrlPart: SRS=EPSG:31467
RequestUrlPart: REQUEST=GetMap
LayersUrlPart: LAYERS=ATKPG25-N1
StylesUrlPart: STYLES=
ImageFormatUrlPart: FORMAT=image/png
BoundingBoxTopLeftWGS84: N 51.6697 E 7.69911
BoundingBoxButtomRightWGS84: N 49.3455 E 11.3986
MinScale: 1.49671
MaxScale: 49.8903
RecommendedScale: 2.5
ImageFileExtension: .pngIch habe obiges, sowie Hessen TK50 und Bayern TK50 auch schon mal ins SVN eingecheckt. Die restlichen von Bayern und Hessen mache ich, wenn das Format endgültig ist.
Mit den hessischen Karten gibt es aber ein ärgerliches Problem. Obwohl ich sie in 2.5 bzw 5.0 anfordere (das sollte das 1:1-Format sein) erscheinen dabei komische Skalierungsartefakte.
@Pfeffer: Gibt es eine Möglichkeit direkt den unskalierten Maßstab anzufordern?
OP
pfeffer
Geowizard
nein, leider nicht. Sie werden auch nicht nur umskaliert, sondern auch bei Bedarf auch umprojeziert... Man fordert es vom Server so an, wie man es haben möchte, aber der Server sagt nicht, wie die Daten im Original sind.
Ich habe übrigens mit der Vertragsabteilung vom Landesvermessungsamt NRW gesprochen: Die sind mit der Nutzung in CacheWolf einverstanden. Nur, wenn wir die unveränderten Originaldaten haben wollten, dafür wollten sie Geld sehen...
Ich habe irgendwie Kalibrierungsprobleme. Insbesondere bei der TK 25 und der DTK 10 von NRW zeigt CacheWolf die Caches irgendwie recht weit vom wirklichen Ort an :-( [checke ich gleich beides ins SVN ein]
Daran bastele ich heute schon den ganzen Tag, es scheint alles korrekt zu sein und sehe nicht, wo der Fehler liegt. Aber auch das Luftbild macht Probleme.
Ich habe den Eindruck, dass die Caches um einen bestimmten Pixelwert verschoben werden, unabhängig vom Maßstab, den die Karte hat.
Ist das in Bayern / Hessen auch so?
Besonders auffällig wird es, wenn man einen hohen meter pro Pixel wert wählt.
Wenn irgendjemand das nachvollziehen kann und mir noch mehr Hinweise geben kann, wäre ich sehr dankbar. tritt
Schöne Grüße,
Pfeffer.
OP
pfeffer
Geowizard
so, habe die Abweichungen genauer untersucht.
Das Ergebnis: Ich habe keinen Fehler gemacht, aber die Gauß-Krüger-Projektion lässt sich nicht mit den bisher genutzten Parametern und der affinen Abbildung korrekt nachbilden. Die Ecken sind korrekt, aber je weiter man sich von der Diagonalen entfernt, desto größer wird die Abweichung. Ich habe bei einem 4x4km großen Luftbild Abweichungen bis zu gut 30m gegenüber GoogleEarth gemessen. Das bedeutet einen Fehler von etwa 1%.
Ich finde, das ist zu viel Abweichung. Als Sofortmaßnahme schlage ich vor, dass ich die Scalierung so begrenze, das die maximale Abweichung kleiner als 5m ist. Das würde bedeuten, dass die maximale scale 0,5 wäre bei 1000x1000 Pixeln.
Längerfristig muss das .wfl-Format geändert werden.
@Bilbowolf: kannst Du mir noch mal den Anhang schicken zur Berechnung der affinen Transformation aus den Geo-Kontrollpoints, was vor einiger Zeit nicht geklappt hatte?!
Du hast Dich da ja sicher schon eingelesen gehabt, was schlägst Du vor, wie wir das .wfl-Format ändern sollten? Hast Du vielleicht schon etwas im Kopf?
Gruß,
Pfeffer.
Das Ergebnis: Ich habe keinen Fehler gemacht, aber die Gauß-Krüger-Projektion lässt sich nicht mit den bisher genutzten Parametern und der affinen Abbildung korrekt nachbilden. Die Ecken sind korrekt, aber je weiter man sich von der Diagonalen entfernt, desto größer wird die Abweichung. Ich habe bei einem 4x4km großen Luftbild Abweichungen bis zu gut 30m gegenüber GoogleEarth gemessen. Das bedeutet einen Fehler von etwa 1%.
Ich finde, das ist zu viel Abweichung. Als Sofortmaßnahme schlage ich vor, dass ich die Scalierung so begrenze, das die maximale Abweichung kleiner als 5m ist. Das würde bedeuten, dass die maximale scale 0,5 wäre bei 1000x1000 Pixeln.
Längerfristig muss das .wfl-Format geändert werden.
@Bilbowolf: kannst Du mir noch mal den Anhang schicken zur Berechnung der affinen Transformation aus den Geo-Kontrollpoints, was vor einiger Zeit nicht geklappt hatte?!
Du hast Dich da ja sicher schon eingelesen gehabt, was schlägst Du vor, wie wir das .wfl-Format ändern sollten? Hast Du vielleicht schon etwas im Kopf?
Gruß,
Pfeffer.
MiK
Geoguru
Wenn die Abweichung prozentual ist, dann ist das Problem bei 1:1-Darstellung doch immer gleich. Also entweder ganz deaktivieren oder lassen.pfeffer schrieb:
Was ich mich noch frage: Die Karten sind ja die gleichen, wie man sie mit NHTop50Trans aus dem Geogrid-Viewer bekommt. Dort herrscht dann im Cachewolf der gleiche Fehler, oder?
Wenn Du jetzt deswegen das Format ändern willst: Könnten wir dann nicht einfach das .map-Format übernehmen? Oder kann das auch nicht mit diesem Fehler umgehen?
OP
pfeffer
Geowizard
also, der Fehler ist ungefähr proportional zur Größe der Karte in km. Das heißt, je kleiner der abgebildete Abschnitt, desto kleiner der Fehler in metern. Auf der anderen Seite bleibt dadurch der Fehler in Pixeln gemessen gleich, das stimmt.
Naja, ist halt unfertig, schade, dachte, es wäre fertig :-(
.map gucke ich mir an.
Ich vermute, dass bei bei NHTopTrans der gleiche Fehler, die gleichen Abweichungen auftreten. Mich würde das sehr interessieren. Könntest Du es mal mit GoogleEarth vergleichen?
Danke,
Pfeffer.
Naja, ist halt unfertig, schade, dachte, es wäre fertig :-(
.map gucke ich mir an.
Ich vermute, dass bei bei NHTopTrans der gleiche Fehler, die gleichen Abweichungen auftreten. Mich würde das sehr interessieren. Könntest Du es mal mit GoogleEarth vergleichen?
Danke,
Pfeffer.
MiK
Geoguru
Keine Ahnung, ob das besser ist. Kam nur drauf, weil wir es sowieso schon beim Import verwenden.pfeffer schrieb:
Wenn ich das richtig verstehe, müsste ich dann in der Mitte der Seiten der Karte die größte Abweichung haben. Und eine Top50 mit 5m/Pixel müsste dann bei einer 1000x1000 Karte dort eine Abweichung von 50m haben. Ist das so richtig?pfeffer schrieb:
Ich versuche mir das morgen mal anzuschauen. Falle jetzt erst mal ins Bett.
OP
pfeffer
Geowizard
nein, in beiden Diagonalen sind auch alle Punkte richtig. Die größten Fehler finden sich dann in der Mitte der Kanten.
Ich steige da noch nicht genug durch, es könnte auch sein, dass durch die Verwendung von mehr Kalibrierungspunkten (ich verwende bei WMS 4 Punkte) es genauer möglich wird.
Vielleicht kann man es auch genauer machen, in dem man die Kalibrierungspunkte nicht an die Ecken, sondern ins Karteninnere verlegt.
Auf den ersten Blick könnte es schon sein, dass .map alles nötige liefern könnte. Allerdings gefällt mir das Format nicht. Außerdem habe ich noch keine vollständige Beschreibung des Formats gefunden. Es speichert jedenfalls nur die Daten, die zur Kalibrierung notwendig sind. Das heißt, wir müssten die Kalibrierung vom Import/Download verschieben auf das Karten suchen / Laden - was die Performance in der MovingMap verschlechtern würde.
Gruß,
Pfeffer.
Ich steige da noch nicht genug durch, es könnte auch sein, dass durch die Verwendung von mehr Kalibrierungspunkten (ich verwende bei WMS 4 Punkte) es genauer möglich wird.
Vielleicht kann man es auch genauer machen, in dem man die Kalibrierungspunkte nicht an die Ecken, sondern ins Karteninnere verlegt.
Auf den ersten Blick könnte es schon sein, dass .map alles nötige liefern könnte. Allerdings gefällt mir das Format nicht. Außerdem habe ich noch keine vollständige Beschreibung des Formats gefunden. Es speichert jedenfalls nur die Daten, die zur Kalibrierung notwendig sind. Das heißt, wir müssten die Kalibrierung vom Import/Download verschieben auf das Karten suchen / Laden - was die Performance in der MovingMap verschlechtern würde.
Gruß,
Pfeffer.
MiK
Geoguru
Ich dachte das hätte ich geschrieben. Nur dass ich "Seiten" anstatt "Kanten" benutzt habe.pfeffer schrieb:
Ich stelle mir das so vor: Wenn man eine quadratische Karte auf eine Kugel legt und dazu die Ecken fixiert, werden die Diagonalen anliegen. Die Mitten der Kanten werden aber abstehen. Und genau dort beobachtest du ja den Fehler.pfeffer schrieb:
Vielleicht sollten wir die Karte je nach Größe in Teilrechtecke zerlegen und für die Eckpunkte Kalibrierungsinformationen hinterlegen. Für kleinere Karten, bei denen der der Fehler vernachlässigbar ist, ändert sich dann nichts. Größere würden dann in 4 Rechtecke zerlegt und fünf weitere Kalibrierungspunkte im .wfl hinterlegt. Vielleicht sind manchmal auch noch mehr Zerlegungen nötig.
Noch mal zum Verständnis: Bei 1000x1000er Karte und 1:1 Darstellung, ist der maximale Fehler immer 10 Pixel. Unabhängig vom Maßstab der Karte. Richtig?
OP
pfeffer
Geowizard
ja, ich glaube schon.MiK schrieb:
Tja, Bild zerlegen..hmm... damit man die dann noch sinnvoll nutzen kann, müsste die MM mehrere Kacheln gleichzeitig anzeigen können...
Alternativ könnte man auch anstatt das Bild wirklich in mehrere Teile zu zerlegen, nur für mehrere Teile des Bildes in der .wfl jeweils die Kalibrierungsinformationen hinterlegen.
Aber eigentlich wäre es da schon besser, solche Kalibrierungsinformationen zu hinterlegen, die dann eben die Veränderung der Kalibrierungsinformationen über das Bildhinweg kontinuierlich angeben. Dazu muss man sich aber erstmal näher mit der Materie beschäftigen... Ich hoffe auf die Mail von Bilbowolf dazu.
Schöne Grüße,
Pfeffer.
blackeye501
Geocacher
Das Problem ist wohl die Gauß-Krüger-Projektion der Karten. Wenn ich das ganze richtig verstanden habe, sind nur die Meridiane Längengrad 0° 3° 6° 9° 12°... gerade. Alle anderen sind entsprechend gebogen. Der Breitengrad verläuft immer gerade durch die Karte.
vergleiche:
http://www.kowoma.de/gps/geo/Grids.htm
Ich vermute, dass in der Moving-map linear zwischen den Kalibrierungsinformationen interpoliert wird. Das könnte zu einem Fehler im Längengrad führen. Nicht jedoch im Breitengrad. Zudem müßte der Fehler größer werden, je weiter man sich von den Mittelmeridianen entfernt. Maximal also bei 4° 30', 7° 30', 10° 30', 13° 30'...
Diese Biegung müßte man rechnerisch kompensieren können. Nur ob dafür die Rechenleistung eines PDA noch ausreicht ????
Und eigentlich müßte der selbe Fehler auch mit NHTop50Trans auftreten, da ja das selbe ausgangsmaterial an Karten verwendet wird (mit der selben Kartenprojektion)
vergleiche:
http://www.kowoma.de/gps/geo/Grids.htm
Ich vermute, dass in der Moving-map linear zwischen den Kalibrierungsinformationen interpoliert wird. Das könnte zu einem Fehler im Längengrad führen. Nicht jedoch im Breitengrad. Zudem müßte der Fehler größer werden, je weiter man sich von den Mittelmeridianen entfernt. Maximal also bei 4° 30', 7° 30', 10° 30', 13° 30'...
Diese Biegung müßte man rechnerisch kompensieren können. Nur ob dafür die Rechenleistung eines PDA noch ausreicht ????
Und eigentlich müßte der selbe Fehler auch mit NHTop50Trans auftreten, da ja das selbe ausgangsmaterial an Karten verwendet wird (mit der selben Kartenprojektion)