On Thu, Mar 14, 2019 at 08:01:14PM -0700, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > > Hello Tom, > > So it seems like TIFF-based maps need gdal. Is that correct? You > mentioned that USGS topo maps might be impacted. Any other specific maps?
No. Nothing in Xastir actually *needs* gdal, except the handful of really obscure vector maps that are handled by the very incomplete map_ogr code and that the vast majority of Xastir users have no use for. OGR is the vector part of the GDAL package. GDAL raster support was never really added to Xastir, only a few stubs. This is why I generally tell people not to bother building in GDAL support unless they already have GDAL installed and they need GDAL tools for some other purpose. But if one *DOES* build GDAL support into Xastir, and also builds libgeotiff support in, then there is a potential conflict between a function that exists in both libraries. And the only place where that conflict would ever show up would be in the TIFF support code in map_tif.c. Any TIFF map that uses UTM as its projected coordinate system would show the issue, if it still exists. USGS topo quads in TIFF format are the most common sort of file of that type (and were the only ones that Curt had in mind when he wrote TIFF support into Xastir). The GeoTIFF format supports many other projected coordinate systems other than UTM, but Xastir's code is pretty much depending on UTM, so files that use anything other than UTM won't really georeference properly in Xastir. > On 03/14/2019 05:14 PM, Tom Russo wrote: > > On Thu, Mar 14, 2019 at 09:57:22AM -0500, we recorded a bogon-computron > > collision of the <[email protected]> flavor, containing: > >> If I didn't have a clue if I were using these or not, is there some debug > >> level and message that would tell me? > > If you've got gdal installed, it's using the hacked version of > > GTIFProj4toLatLong. To test out whether the hack is needed, you'd have to > > change the ifdef in map_tif.c so the "else" is never used: > > > > Comment this out at the top: > > > > // Needed for GTIFProj4FromLatLong() replacement below > > #ifdef HAVE_LIBGDAL > > # include "proj_api.h" > > #endif // HAVE_LIBGDAL > > > > and then later: > > #ifndef HAVE_LIBGDAL > > # define my_GTIFProj4FromLatLong GTIFProj4FromLatLong > > #else > > > > > > just change the "ifndef HAVE_GDAL" to "if 1". > > > > If TIFF maps in UTM (e.g. USGS topos) display properly after that change, > > you > > wouldn't have a problem with removing the hack. > > > >> e.g.: > >> $ xastir -v X >xastir.log 2>&1 > >> [poke around until i display all my maps in xastir] > >> $ grep "something" xastir.log > > Nothing here would tell you anything useful. This is entirely an issue of > > TIFF maps not properly being georeferenced, because this > > "GTIFProj4ToLatLong" > > is used to translate the coordinates stored in the TIFF file into > > coordinates > > Xastir can work with. > > > >> On Thu, Mar 14, 2019 at 9:25 AM Tom Russo <[email protected]> wrote: > >> > >>> We got a bug report on github that Xastir is using a deprecated API for > >>> the > >>> proj.4 library. A new API (in "proj.h") has been created in proj.5, the > >>> old > >>> is deprecated in proj.6, and will be removed in proj.7. In keeping with > >>> the > >>> new normal of racing through major versions every 6 months or so, proj.7 > >>> is due out in 2020. > >>> > >>> I've looked into it, and it turns out that the only uses of proj.4's API > >>> directly in Xastir source are the result of a hack that was put > >>> in place to deal with a GDAL/libgeotiff issue, and another place where > >>> we're including a "contrib" program for shapelib that the main shapelib > >>> distribution has dropped altogether because it's not very useful. > >>> > >>> I could use a hand figuring out the best path forward here. > >>> > >>> In map_tif.c there is code that conditionally compiles in a substitute > >>> function for GTIFProj4FromLatLong, because some 14 years ago there was > >>> apparently sometimes a problem with this function if one compiled both > >>> gdal > >>> and libgeotiff into Xastir. The reason for this is that both libraries > >>> define > >>> that function, and it was probably possible to compile them in > >>> inconsistent > >>> ways. The question is whether the hack is still necessary, and > >>> if the presence of both libraries still causes problems in the > >>> map_tif.c code if the hack were removed. This will require a lot of > >>> testing using TIFF maps, and probably on multiple systems to make sure > >>> it's safe to remove. I will need a lot of help with that, as I have > >>> hardly > >>> any time available to test things like this out myself. > >>> > >>> If this hack is no longer necessary, the easiest path forward to > >>> addressing > >>> the future incompatibility with Proj.6 and Proj.7 will be to remove it > >>> altogether. If it is still necessary, then the best path forward might be > >>> to use the GTIFProj4FromLatLong from the upcoming libgeotiff 1.5.0 instead > >>> of the one we have, as the upcoming version has been modified to work with > >>> the new proj.5 API. > >>> > >>> I also propose removing "shpproj" from our ancient "internal" shapelib > >>> library's > >>> contrib directory, because it is mostly useless and there are better tools > >>> to get the job done (e.g. ogr2ogr, from the GDAL/OGR library). Is anybody > >>> depending on this program who would object to it disappearing? > >>> > >>> -- > >>> Tom Russo KM5VY > >>> Tijeras, NM > >>> > >>> echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] > >>> [n-z][a-m] > > _______________________________________________ > Xastir mailing list > [email protected] > http://xastir.org/mailman/listinfo/xastir -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir mailing list [email protected] http://xastir.org/mailman/listinfo/xastir
