MAPS

[joni73]

hi,

I do have problems whit maps. I guess problem is at: EPSG:3067 , https://epsg.io/3067

Firstly dowloadble maps cooridantes are out of system limits ! http://kartat.kapsi.fi/files/taustakarttasarja_jhs180/taustakartta_10k ,.... at http://kartat.kapsi.fi/

Secondly I have not succeed to generate WMSSERVER server request that works:

WMSSERVER
URL https://tiles.kartat.kapsi.fi/taustakartta?service=wms&version=1.1.1&request=GetMap&SRS=EPSG:3067&FORMAT=image/png

I'am trying to use https://kartat.kapsi.fi/ as source of maps, these maps are from
Finish Land Survey material and free to use when origing is mentioned.

Also like to note that whole europe location informations are available due Inspire Act
https://inspire.ec.europa.eu/,...

joni@oh5bzr.rdw.fi

[tvrusso]

Sorry for having taken so long to respond.

Yes, Xastir does not know how to do transformations between geographic or projected coordinate systems itself. There is some limited ability to handle UTM coordinates in NAD27 and NAD83, but only for maps in GeoTIFF format, which doesn't help you. There is NO capability to transform WMS maps, which actually must be in EPSG:4326 (WGS84 geographic (lat/lon) coordinates) in order that Xastir understand how to pop them into its world coordinate system.

However, the server you provided can do that transformation just fine on the server side, and the following .geo file does work:

WMSSERVER
#
URL https://tiles.kartat.kapsi.fi/taustakartta?service=wms&version=1.1.1&request=GetMap&SRS=EPSG:4326&FORMAT=image/png

The important thing is to specify "SRS=EPSG:4326" in there, not EPSG:3067.

This "works" if you're zoomed in close enough to Finland, but as you note does produce

convert_from_xastir_coordinates:X out-of-range (too low):18446744073692789480
convert_from_xastir_coordinates:X out-of-range (too high):164376258

if you zoom out too far, and shows nothing. That's because if you go out too far, the transformation from EPSG:3067 to EPSG:4326 is actually invalid and the server chokes. But so long as you're inside the region where EPSG:3067 transforms cleanly into EPSG:4326, it'll work fine.

If you zoom in close enough, you can get a usable map, but it will be distorted because of the coordinate transformation needed. For example, if I naively zoom in to bits of Finland near Helsinki, with a typically American ignorance of what parts are actually interesting, I can see varying levels of detail, down to single buildings and streets:

I hope this is good enough of an answer for you.

[tvrusso]

I will note, though, that the actual placement of features correctly on the map is entirely dependent on the accuracy of the transformation/warp performed by the WMS server itself. I expect that in this day in age it is safe to trust that accuracy, but your mileage may vary.

[tvrusso]

And perhaps a location that might be more interesting to you:

Unfortunately, as I type this your last APRS positions sent to APRS-IS were about 10-20 minutes ago, and I only just updated my filter for my APRS-IS feed to include you, so I don't have any position reports from you to display on this view.

[godfreja]

@tvrusso - Is reprojection something we would want to consider adding as a potential future feature? (With the understanding that it may not happen.) I'm guessing we would use GDAL to do that, which I know was previously ripped from Xastir because we weren't really using it.

[tvrusso]

We would definitely want to do it via gdal (there is a whole gdal warp api that can do exactly that), but it's a computationally expensive operation and many full-featured GIS systems don't even do it on the fly. Trying to do it in Xastir (where users have typically complained loudly when map panning is slow) might not be the best approach.

In this particular case, the best thing really is to let the WMS server do the warping as it serves the image. It's smart enough to do it right.

GDAL use in Xastir was envisioned as a way to replace the hackish handling of various raster map sources, but it got started and abandoned almost in the same breath and only very, very tentative use of OGR (the vector part of GDAL) ever got worked on.

GDAL got removed from Xastir because linking to it started to conflict with other things (geotiff, according to #48).

A sufficiently motivated developer could replace our geotiff support with gdal support, including full blown coordinate system transformations, but that's real work. It could also replace the support for ".geo" insertion of random image files with no georeferencing information (other than the .geo file). map_tif.c and map_geo.c have sort of duplicated hacks that use either libgeotiff or image/graphicsmagick to turn the image file into something Xastir can display, and if one could simply use gdal to access the imagery directly then perhaps we could do away with Magick entirely. But again, that's real work.

I am not sure there's enough interest in on-the-fly coordinate system transformation to make it worth the effort.

One can always use gdalwarp to warp single images to an appropriate coordinate system, and then tell Xastir to load that. That's what we've been recommending for many years for geotiff/geopdf maps that are in anything other than UTM in NAD27/NAD84, and it's what I have always used for aviation sectional maps (which are usually in lambert conformal conic). Once that's done, Xastir just has to load the file without having to transform it every single time.

And it appears that at least some (maybe all) WMS servers actually can do coordinate transformation themselves, so we should leverage that when possible.

[tvrusso]

Oh, and I just confirmed that if one has Berkeley DB installed and linked into Xastir, Xastir properly caches WMS map images, so if one pans and zooms a bunch, the images are cached and saved for fast reload when previously downloaded maps are available for the current view. This is much better than either repeated pulling maps off of the server or transforming maps on the fly.

[tvrusso]

And now that you're up and about, here's a screenshot of Xastir using the .geo I posted earlier:

I switched back and forth between this map and Open Street Maps (OSM_tiled_mapnik.geo) and it looks like it's correctly georeferenced.