[aprssig] Map Symbol Placement
Tom Russo russo at bogodyn.orgThu Apr 19 16:08:39 UTC 2007
- Previous message: [aprssig] Map Symbol Placement
- Next message: [aprssig] KPC3 power connector size
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [aprssig] Map Symbol Placement
- Next message: [aprssig] KPC3 power connector size
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
