Discussion: output projection

[der-stefan]

The default output of Splat maps is in EPSG:4326 projection. Nowadays, most online maps (typical OpenStreetMap maps or Google Maps) are in EPSG:3857. Up to now Splat users had to transform the output on their own, for example with gdalwarp, after georeferencing the output png as a geotif:
gdal_translate -of Gtiff -a_ullr $x1 $y1 $x2 $y2 -a_srs EPSG:4326 map.png map_4326.tif (not necessary any more when using -tif output)
gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3857 map_4326.tif map_3857.tif
Should Splat produce EPSG:3857 projected maps as default?

[hoche]

Yes, please!

We should probably keep the capability to output EPSG:4326 around as an option though.

[dBitech]

I think the default should remain as 4326, and document the gdal_translate process, or better yet, link against libgdal, and support any output projection (and format) that is supported by the library.

[der-stefan]

That's still an ongoing discussion: Must splat2 be fully backward compatible, or can we change some aspects for good? There is no need for instant decision though.

[dBitech]

in my toolchain, I take the original ESPG:4326, and convert to vector and make available in a number of formats, one of which is geojson which is directly overlayed on a number of web mapping applications. I also import the data into a PostGIS enabled PostgreSQL database which drives a number of other analyses and display engines.

While I can easily change what I'm importing from, to match any specific ESPG, I think the path of least surprise is still valid for a Version 2. A flag such as -web which sets the output to ESPG:3857 and produces the HTML files, etc as discussed in #11 to me woudl be a good middle ground

[hoche]

I don't really have a firm opinion on this one way or another. My main reason for wanting to keep some backwards compatibility is so that we can check its results against what 1.4.2 generated. I don't want to break people's toolchains by removing functionality, but I'm also not particularly averse to changing the command line switches around a bit.

The way the command line switches are handled right now is one of the most difficult things about splat, both from understanding how they all interact with each other to maintaining the code in main() that untangles them. But that's another topic...

[davidsrsb]

Two points:
Many of us are using the SRTM3 DTED, which is WGS84 datum ie ESPG:4326

QGIS still defaults to ESPG:4326
This link has some information on ESPG:3857 and the misalignment caused
https://epsg.io/3857

[der-stefan]

Today I added a GeoTiff output by using the GDAL library and pushed it into the "json" branch. There are still some issues that need to be solved. If you want to try, just add "-tif" to the command line.

[der-stefan]

The warping with GDAL in C++ is pain. So it will take some days for me to include the functionality in SPLAT. However, the program "gdalwarp" is very easy to use in the meantime.

[dBitech]

maybe a better longer-term scalable solution is to have an -of (or such) that can take any of the supported gdal raster write drivers

[NRaf]

Hey guys, just commenting as someone who's very new to this. Been using your 2.0 branch and it's been a lifesaver.

My use case is letting users click on a map in a web app, generating Splat output for the selected location on the image, and then returning the image and rendering it over the map, parsing the KML output to figure out the bounding box for image.

I was using the default PNG output, but noticed the PNG was slightly offset from the actual location when adding it as a layer in Leaflet. Tried loading the GeoTIFF in QGIS and it was loading correctly, same for loading the KML in Google Earth.

Eventually realized there was a discrepancy in the CRS being used (again, new to all this...), and after spinning my wheels for a few hours trying a bunch of things, ending up running across this thread.

Ended up fixing it by running the following commands against the outputted GeoTIFF:

gdalwarp -s_srs epsg:4326 -t_srs epsg:3857 in.tif out.tif
gdal_translate -b 1 -b 2 -b 3 -mask "none" -of PNG out.tif out.png

Looking at the code, I noticed there's a -proj parameter inside of main.cpp, but when I supplied -proj epsg:3857, it didn't seem to make any difference to the output.

[der-stefan]

Hi @NRaf, thanks for your comment. See this explanation of the difference between EPSG 4326 and 3857: https://gis.stackexchange.com/a/380296
By the way: Although I have been involved with geospatial data for a decade in the context of the development of the OpenTopoMap, I still don't have a clear view over all those various types of projections. So it's always a good idea to use resp. libraries (GDAL etc.) to take care of them...

The parameter -proj isn't used yet, but we are going to implement that functionality. Apparently, hoche, watkipet, dBitech and me got sidetracked once more, so development stalled again...