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