| |
ZL3AI > APRDIG 01.05.07 01:01l 88 Lines 4671 Bytes #999 (0) @ WW
BID : 10082-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 34 #18, 2/2
Path: DB0FHN<DB0FOR<DB0MRW<DK0WUE<F4BWT<VE2PKT<ZL2BAU
Sent: 070430/2249Z @:ZL2BAU.#79.NZL.OC #:45464 [Waimate] $:10082-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 8
Date: Thu, 19 Apr 2007 10:08:39 -0600
From: Tom Russo <russo_at_bogodyn.org>
Subject: Re: [aprssig] Map Symbol Placement
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
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 34, Issue 18
Read previous mail | Read next mail
| |
