[Xastir] Help needed with proj library compatibility

[David Ranch]

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 <kg4wsv at gmail.com> 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 <russo at bogodyn.org> 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]