[Xastir] Help needed with proj library compatibility

[Jason KG4WSV]

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?

e.g.:
$ xastir -v X >xastir.log 2>&1
[poke around until i display all my maps in xastir]
$ grep "something" xastir.log


-j


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]
>
> _______________________________________________
> Xastir mailing list
> Xastir at lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir
>


-- 
-Jason
kg4wsv