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