[ gpsdrive ] WMS and registering maps by bounding box

[Hamish]

[gpsfetchmap.pl with NASA's OnEarth WMS]

Hamish:
> > one thing I am trying to understand -- how to ensure that the given
> > bounding box in the URL will create an image with equal north-south
> > and east-west resolution?

Guenther:
> the values are calculated. 

ah, in gpsfetchmap.pl  landsat_url(), based on center coord and scale
factor.

> I don't know who did this formulas and factors...

Based on the commented bbox=, maybe someone from Sweeden?
It is a shame that the CVS/SVN history was not loaded into SF, and that
so few "constants" and factors are commented as to their heritage.

At least with the OnEarth server we know the map projection [srs=], so we
can verify the math.

Starting with the paranoid assumption that all scale factors in GpsDrive
are fudged until they seem to work (instead of calculated) on a quick
look I fear that the landsat code in gpsfetchmap.pl is author-centric:
    my $deltalat = 0.0005;
    my $deltalon = 0.001;   # Gives ratio 1.2 in meter

I do not understand the comment. ratio 1:2 ?? or 120cm?

assuming the author is in Sweeden, at 58.4N, the lat/lon ratio should
be cos(lat) = 0.524. which is close to the mysterious 1/2 delta ratio.
If true, the calculation would not be valid for very low or high latitudes. 
The /1000 *1000 stuff seems a small waste of time.
And where does "6.4" in the scale table come from?
And what about compensating for 1024x1280 (=0.8) height/width?

I will step through by hand and see what I can discover...


> > Upon closer look, the code to register maps by bounding box coords
> > appears only partially written, and center lat/lon and scale are still
> > needed there.
>
> the code takes given center coords and scale, and calculates the bbox
> needed to get an 1280x1024 image in the projection used by gpsdrive.
> I guess, this is not really the best way to go, but it
> seems to work.

sorry, I changed topics there without saying so.
I meant the code that reads 8 terms from map_koord.txt in map_handler.c.
Once (maps+i)->maxlat etc are set, they are never used.

 
> I had a short look at gdal; is the following scenario possible?
> gpsdrive uses internally only one exactly defined projection. gdal ist
> used to get th maps from different sources

there are two ways- like above, or keep maps native and reproject the
gpsdrive map box and GPS cursor to match that. FWIW, keeping the image
file in its native projection and just cropping 1280x1024 cells takes
many fewer cpu cycles.

To be honest, I don't know the correct answer to which is the best way.
I am not fully confident that google/OSM have done the right thing, so
I would not blindly follow their lead for one moment. IMO even most
professional GIS software gets this wrong in some manner. (usually
WRT map datum support)  ... it's not easy.

But until we have something "real", the _top vs. _way can still be useful.

Getting one of the GDAL programmers interested in this project might be
a good idea...... hmmmm


> (it seeme, it can access map servers directly?),

since version 1.5.0, http://www.gdal.org/frmt_wms.html


> and changes them into the gpsdrive format (maybe tile based).

gdalwarp will reproject the maps to the desired SRS.
gdal_translate will crop to 1280x1024 (or whatever).
both will read and write any known --format.
Probably the common working format would be GeoTiff.


Hamish

ps- latest SVN commit is broken. Partial rename of download_map.* to
map_download.* ?