Order Tray | Contact Us | Home | SIG Lists

[aprssig] Map Symbol Placement

Tom Russo russo at bogodyn.org
Thu Apr 19 16:08:39 UTC 2007


On Thu, Apr 19, 2007 at 08:41:08AM -0700, we recorded a bogon-computron collision of the <scott at opentrac.org> flavor, containing:
> > Of course the fact that both lat and long can use negative numbers
> > complicates things slightly.  For the Xastir project we translate
> > everything to our own coordinate system that uses only positive
> > numbers which makes this part easier.
> 
> How does Xastir handle different map projections?  I seem to remember that
> it had a projection library linked in.  And it seems to work properly when I
> load in California maps in Albers equal-area conic projection.  Does it
> reproject the map to match the screen coordinates?

Xastir doesn't actually do map projections in a strictly correct way either, 
and the only code that's even approximately right is the geotiff code.  It 
uses an approximation that is pretty good for maps of the size of a USGS 7.5' 
topo quadrangle in UTM projection.  It uses the geotiff library's projection 
code (which is just a layer above the PROJ.4 cartographic projection library) 
to get the projected and geographic coordinates of the map corners, and then
works out an approximate linear scaling and rotation for each scan line.  To 
do it strictly correctly on the fly would be very much more expensive than the 
current approximation (it would require each pixel's corner coordinates to be 
transformed correctly, and a quadrilateral drawn, as opposed to the current 
method of transforming the pixel center coordinate approximately and then 
drawing a rectangle).

If it appears to work for your Albers equal-area conic maps then they
are probably small enough that this approximation might be OK -- the a
approximation amounts to assuming that a horizontal line in the image
transforms to a straight line (albeit rotated) in the geographic coordinates.  
This approximation is not valid on large scales or even in small scales in
some projections.  If you try out the geotiff code on much larger maps (such 
as USGS 1:100000 or 1:250000 scale maps) you'll see that the approximation 
breaks down.  Try it with an unmodified FAA sectional chart in Lambert 
conformal conic, and you'll see the approximation breaks down quite badly --- 
xastir will *try* to display it, but the internal features will be 
significantly misplaced because horizontal lines in the image are supposed
to map to *curves* in geographic coordinates.

The only maps that the geotiff code does *strictly* correctly are those that
are "unprojected" (geographic coordinates, "Plate Carre" or "Equidistant
cylindrical projection").  One can unproject map images using gdalwarp, but 
this usually adds opaque border junk that can interfere with tiling in xastir.  
An example of how to do that is described in README.MAPS when discussing
FAA sectionals.  Newer versions of gdalwarp can tile multiple images *and* 
repropect *and* chop up the result.

The .geo code (the stuff that uses imagemagick to read .png, .gif, and .jpg
files along with a "georeferencing" .geo file) only works for unprojected maps 
where the linear relationship between pixel coordinates and geographic
coordinates is valid.  It does *no* rotation at all, and does not use any
cartographic projection library.  If one uses, say, terraserver maps or on-line
TIGER (that are also done via the .geo code) and overlays accurate street-level 
vector layers, one can watch the inaccuracy of the .geo code in action --- 
simply pan around and watch how the registration between vector layer and 
underlying raster changes as intersections are moved to different parts of the 
screen.  The problem is that the tiles downloaded from terraserver are in
UTM projection but are not properly transformed, and the images downloaded
from TIGER are not only in sinusoidal projection without being transformed 
properly, but also the TIGER server does not always return an image with 
exactly the corner coordinates you request, so the georeferencing is always
at best an approximation.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick




More information about the aprssig mailing list