[Xastir] Help needed with proj library compatibility

[David A Aitcheson]

Tom,

My vote is for removing the code bloat that is not used.

If I do need something involving these types of map files I would
probably open the map in its native software package and overlay the
Xastir data in a layer.

73
Dave
KB3EFS


On 3/15/19 11:03 AM, Tom Russo wrote:
> 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]