On Fri, Oct 09, 2009 at 09:43:41AM -0700, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > On Fri, 9 Oct 2009, Kevin Ratcliff wrote: > > > On Fri, Oct 9, 2009 at 12:08 PM, Tom Russo <[email protected]> wrote: > >> Hmmm. ?Well, then, recompiling proj.4 with correct datum shift grids would > >> be required regardless, then. > > > > I've been meaning to modify the Ubuntu 9.04 wiki instructions to > > address this, but haven't done so yet. I'll try to do it this weekend. > > Nick was hoping to use these maps off-road this weekend. Guess he's > out of luck unless he finds that other package Tom mentioned that > has it fixed.
*IF* the clipping is due to libgeotiff not being compiled against proj.4, and the problem that Nick is having is related to proj.4 not being compiled correctly. That has not been determined, it's just one possibility. You brought it up, because that would be one explanation. Lee almost certainly followed the wiki instructions for building Xastir in the VM. That would mean that libgeotiff was compiled after proj.4 was installed from the repositories, meaning that border clipping should still work. We do NOT use proj.4 to do datum shifting in map_tif.c. The only use of proj.4 in map_tif.c is to convert coordinates in the geotiff file from their native coordinate system (generally UTM) into lat/lon using GTIFProj4ToLatLong --- no datum shift is applied in this step, and the lat/lon produced is in the same datum as the original projected coordinate system. Datum shifting is applied by the code you wrote in datum.c instead. Since NAD27/NAD83 conversion is not an analytic transformation (it requires an interpolation grid to be done correctly) this is at best an approximate shift that would actually be more correctly done by proj.4 (if it is compiled properly with the interpolation grids), but that's another matter. The point is, even if proj.4 is compiled incorrectly, it has no impact on Xastir because Xastir doesn't use proj.4 for exactly the thing that is wrong in the Ubuntu compilation of proj.4. Even if it did, the error would show up as a few dozen pixels of incorrectly cropped or uncropped white border around the map. Most of the rest of the border would be cropped. Nick implied that no border was being trimmed, which would suggest something much more serious, such as Xastir not finding the FGD files or being unable to read them. I think it is much more likely that there is a problem with reading or processing the FGD file than that the issue is related to libgeotiff and proj.4. Nick should try running with debug level set to 16 and see if Xastir reports the various things that are printed out by the cropping code (such as "Upper left <XXXXXX> <YYYYY>," "Lower Right <xxxxxx> <yyyyyy>," "Tiepoints:," "Datum:", "***** Attempting Datum Conversions", "NW neat-line corner =" and so on and so forth, or errors such as "Failed GTIFProj4ToLatLong() call") And now that I look, if the issue were libgeotiff not being compiled with PROJ.4, there would also be error messages such as: draw_geotiff_image_map: Problem converting from lat/lon\n Did you follow the instructions for installing PROJ?\n Nick should definitely try running Xastir from the command line and tell us if he sees error messages such as these. Read permissions of FGD files would also be a good thing to check. Also, if the files are called ".FGD" instead of ".fgd", the function "read_fgd_file" will not find it. -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM In some cultures what I do would be considered normal. -- Ineffective daily affirmation _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
