[Xastir] Help needed with proj library compatibility

[Tom Russo]

There is a simpler way for me to address this issue, but I need some input
from the Xastir user community.

The easiest possible way to address this is to remove GDAL and OGR support from
Xastir altogether.  That would remove the need to have a copy of 
GTIFProj4FromLatLong in map_tif at all (because that copy exists SOLELY to 
deconflict libgeotiff and libgdal's two versions of the same function), and I 
believe it would have minimal impact on any existing users.

GDAL and OGR support was added to Xastir back around 2005, with the intent of
using its vast capability to support many more map types than had previously
been supported in Xastir.  But this support never really reached its potential,
and almost no GDAL raster support ever got written.  Only OGR vector map 
support was developed, and it never reached the level of support that the 
completely separate shapelib code had --- that is, while the shapelib
driver allows you to control Xastir's rendering of shapefiles using DBFAWK, 
you can't control Xastir's rendering of OGR-supported vector files
except by hand-editing the map_ogr.c file and hacking in special purpose
code.

I do not believe *anybody* actually uses these obscure map types in Xastir,
and some of them are not even available anymore (such as the old topological
format TIGER/LINE data or the SDTS files from USGS).  The complete list of
data types that *could* be rendered wtih OGR in the existing code are:
   .ddf   USGS SDTS vector files
   .rt1   US Census Tiger/Line
   .s57   International Hydrographic Organization S-57 files
   .tab   ]
   .mid   ]  MapINFO files
   .mif   ]
   .dgn   Microstation DGN format

Many other map types *could* have been implemented, but only these were.

So the question is, is anyone actually using any of these map types in their
Xastir work, or is the GDAL/OGR code in fact just code bloat that is causing
problems now?

Removing the GDAL/OGR code and the handful of obsolete shapelib "contrib" 
programs that use proj.4 would completely solve the future incompatibility
with the proj library.

Note that the programs that come with gdal are still all very useful, but
are not directly used by Xastir.  If you have been using tools like gdalwarp
or ogr2ogr to convert map data into formats that Xastir understands natively,
that would remain the best approach and would not be impacted if I were to
remove all GDAL/OGR support from Xastir.

On Thu, Mar 14, 2019 at 08:25:40AM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
> 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]

-- 
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]