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?
--David
KI6ZHD
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
