[Gdal-dev] GPSDrive Success! (Partial, labor-intensive...)
ed at topozone.com
Sun Sep 12 15:27:18 EDT 2004
Good job! I've got a few brief notes/comments:
1A) As I indicated before, if you're using TerraServer images, they are
stored a 1 meter/pixel, 2 meters/pixel, 4 meters/pixel, etc. You
control which resolution you get by the parameters of your image
request, so you shouldn't have to deduce it afterwards - you get what
you asked for.
1B) The UTM coordinates of the upper-left corner can also be calculated
from the TerraServer querystring request parameter - you don't need to
use PROJ at all, and you'll get a slighly more accurate result.
I think you will find everything you need at
2) Informally, think of lat/long as a special case of equirectangular.
In an equirectangular projection, each one-degree-square block forms a
rectangle, and they're all of the same size (hence, equirectangular).
In lat/long, those rectangles are squares. The lat/long projection
minimizes distortion along the Equator, but it is VERY bad at middle
latitudes. The equirectangular lets you choose two standard parallels
(usually an equal distance north and south of the Equator) to have true
scale - so you can have true scale at 40N and 40S, with things getting
moderately bad at the Equator and moderately bad at high latitudes.
Slightly more technically, think of lat/long as being projected onto a
cylinder that touches the Earth at the Equator only (ball stuck in a
tube) while equirectangular is projected onto a slightly narrower
cylinder that passes THROUGH the Earth, intersecting it at the two
standard parallels (tube shoved through the ball).
2) (also) Your UTM zone calculation is off by one - -180 to -174 degrees
is zone 1, note zone 0.
From: gdal-dev-bounces at xserve.flids.com
[mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of S Clark
Sent: Sunday, September 12, 2004 3:00 PM
To: gdal-dev at xserve.flids.com
Subject: [Gdal-dev] GPSDrive Success! (Partial, labor-intensive...)
Quick recap: I'm attempting to learn to convert various map images,
starting with UTM map images, to one of the two projections supported by
GPSDrive. At present, the image sources I am using give me only the
following pieces of information:
1)Latitude and Longitude of the center point of the image 2)A "scale",
which appears to related to meters/pixel 3)A known image size, required
to be 1280x1024 pixels 4)The projection of the source image (currently
I was able to SUCCESSFULLY convert the previously mentioned Terraserver
image of the "King's Bowl" crater (crater itself is at 42.94944
-113.21637, if anyone wants to look up a picture of it) such that it is
scaled and positioned correctly in GPSDrive. I've still got a ways to
go to learn what I need, as there is still a great deal of manual
intervention required at the last step, but here's what I've got so far:
1)Create a "world file" to go with the source image, using the small
amount of information available for the image:
A)Calculate the meters/pixel of the image - conversion from the "map
of GPSDrive, according to the GPSDrive source code gives the formula
this as "map scale/2817.947378". This gives 1.956033687155673
for the "scale 5512" original image.
B)use the 'proj' command (from the proj.4 project) to calculate the
"easting" and "northing":
proj +proj=utm +lon_0=(lon of image center) +ellps=WGS84 -r << EOF
> 42.94584 -113.2167
C)Create the world file (in this case, named
2)use gdalwarp to convert the image
(NOTE: GPSDrive "top_*" images should be "latlong". "map_*" images MAY
be Orthographic [unconfirmed])
(QUESTION: What's the difference between "eqc" (Equirectangular) and
A)calculate the UTM zone
B)gdalwarp to a .bmp (imagemagick appears to have trouble with
/usr/bin/gdalwarp -s_srs '+proj=utm +zone=12 +datum=NAD83
-t_srs '+proj=latlong +datum=WGS84' -of bmp
Creating output file is that 1432P x 851L.
ERROR 6: Dataset does not support the SetProjection() method.
:0...10...20...30...40...50...60...70...80...90...100 - done.
(PROBLEM: gdalwarp couldn't convert to ortho: "too many pixels failed to
transform (441 of 441)")
C)convert the image to 1280x1024 without changing the center or
or warping the map
i)for undersized height or width, add equal-sized blank borders to
both sides of the undersized dimension
ii)for oversized height/width, cut out an appropriately-sized
mogrify -border 0x87 -crop 1280x1024+76+0 top_kings_bowl.bmp
3)Add the image to GPSDrive
A)Copy image to ~/.gpsdrive or wherever GPSDrive looks for images
B)Add the image to map_koord.txt
top_kings_bowl.bmp 42.94584 -113.2167 5512
C)(The worst part right now) - fiddle with the "scale" until the map
actually works right. By trial and error (and examining how the
track file lined up with the road in the aerial photo) I was able to
determine that the new image appeared to be about 1:7000 instead of
Change the map_koord.txt line accordingly.
top_kings_bowl.bmp 42.94584 -113.2167 7000
(QUESTION: has the image actually been "rescaled" by the gdalwarp
process from GPSDrive's perspective, or has the "scale" of 5512 been
wrong all along?
The 5512 "scale" looks as correct as can be expected when left as UTM
and displayed as a "map_" file in GPSDrive...)
And now the track showing our travel correctly follows the road we took
into the feature. Screenshots:
Since the real goal here for me is to be able to automate the entire
fetch/convert/add-to-GPSDrive process, I still need to figure out what
the problem is with the "scale", but otherwise this seems to be working.
It would also be nice to figure out why I can't get gdalwarp to convert
the image to an Orthographic projection as well (since the information
from Ed McNierney [thanks!] seems to imply there's a good chance that's
the "map_*" projection that GPSDrive uses), but being able to get
working Geographic (latlong) projection images is good enough for my
purposes right now.
Thanks again - suggestions welcome!
Gdal-dev mailing list
Gdal-dev at xserve.flids.com
More information about the Gdal-dev