[ gpsdrive ] gpsdrive and NOAA charts

Hamish hamish_b at yahoo.com
Tue May 13 06:00:09 AKDT 2008

> chris123 at s103:~> gdalinfo --version
> GDAL 1.5.0, released 2007/12/18
> same syntax
> and a smashing success..!!!
> gdal converted the same test file to tif without issues.


> running gdalslice.sh on the file and it completed
> successfully however did 
> give me the following errors towards the end repeatedly:
> Processing chunk [8640 0] ...
> Input file size is 9619, 12838
> -srcwin 8640 0 1280 1024 falls outside raster size of
> 9619x12838
> or is otherwise illegal.
> Quietly moving on ...
> Processing chunk [8640 768] ...
> Input file size is 9619, 12838
> -srcwin 8640 768 1280 1024 falls outside raster size of
> 9619x12838
> or is otherwise illegal.
> Quietly moving on ...

That's ok. Some tiles partially fall off the edge of the map and are discarded. "Quietly moving on ..." as there is no bad error to worry about.
Edge tiles are created in another pass, so nothing is lost.

> So all I can conclude from this exercise is that there must
> be a difference between the kubuntu and opensuse package other
> then the version number

GDAL 1.4.4 failed, 1.5.0 worked: I'd be happy to consider it a bugfix between those and not spend too much more time wondering about it.

> but I really dont trust package numbers from different vendors.
> The latest suse package is identified as gdal-1.5.1-5.1.i586.rpm 
> Yet the gdal site seems to favor a 1.4 release level. Who knows. ..:)

www.gdal.org and gdal.osgeo.org both say 1.5.1 is the latest at the top by NEWS.  Yes I see what you mean, the binaries downloads page is out of date, but the source code downloads page is in order. 1.4.4 was only a couple of months ago, so no so awful.

> potentially important alternative usage of gpsdrive.

my primary usage :)

> A change request if I may Hamish.
> The gdal slice script seems to work just fine, however
> would it be possible to augment this script to allow it
> run in batch mode without the need of identifying the
> input and output files as these are basically standardized
> for noaa charts. 

see attached.
> For example a nice feature would be for the script to walk
> through a directory of noaa_xxx.tif files and create the
> necessary tiles in discrete folders with the base name of
> noaa_xxx and with a base output file of noaa_xxx as is
> currently defined by the script anyway. 
> In this manner a directory containing several hundred
> noaa_xxx.tif files, could be processed in batch mode.


for MAP in noaa_*.tif ; do
  if [ -d "`basename $MAP .tif`" ] ; then
     # skip if already processed

  gdal_slice_auto.sh "$MAP"  

> Once done it would not be that difficult to 
> load the data into say a UMN mapserver and make them
> available to everyone.

(disclaimer, I know nothing about mapserver's needs)
if UMN mapserver uses GDAL to read maps, then it can read the .tif files directly, no need for tiles?  (I expect it will need the warping step)

if it does need tiles, newer versions of gdal come with a tiling script, 
gdal2tiles.py  (see also gdaltindex, gdal_retile.py)

mine is specifically made for gpsdrive, gdal2tiles.py probably works better with MapServer... but maybe it's ok.

> Just a thought. Sorry I don't code nor script unfortunately.

one reason for not making gdal_slice automatic is that I want to encourage people to open the script and look at it :)

> Currently learning the rudimentary steps of mapserver.

one thing you probably could do is use the GeoTiff tiles that gdal_slice.sh makes and use them in mapserver without any more effort. ie use PNG tiles for gpsdrive and .tif tiles for mapserver.
it would be neat to see! A WMS server too!

> Someday I'll tackle grass but thats a different beast altogether.

FWIW, it has gotten a lot easier.

> Thanks again Hamish and others.  

no worries.


ps- I think the gdalwarp method may be more accurate than explicit reprojection from Mercator using the NOAA info. If the results do not line up well* you could try using -tps instead of "-order 2". The internal math is a lot trickier but the splines twist oh so very nicely.

[*] tip: turn on grid lines in gpsdrive, see how well they overlap. alternatively make a grid of waypoints (way_grid.txt?) on the coords that the raster map's grid lines cross. that will give you confidence in your result. I have found that errors are less problematic in 1:50,000 scale maps and finer. More coarse maps seemed to wander more. I'd be curious to know how your match up.

For me NOAA chart 12200 lines up very nicely!! (pos. mode then zooming in on grid crosses and checking coord on the status bar matches the nice round number)

pps- I remember about 15-20 years ago the headaches and disclaimers flying out from NOAA all of a sudden when people first started putting GPSs in their boats and discovering that the NOAA charts were not as perfect as they had thought. Since then, most of the charts have been made very good- to the point of people carefully measuring and entering the lat/lon coords of bells and nuns as waypoints, switching on the autopilot, and then a few hours later they arrive at the buoy with an almighty "thunk" as the chart, GPS, and autopilot all did their job flawlessly.  :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdal_slice_auto.sh
Type: application/x-shellscript
Size: 5297 bytes
Desc: not available
Url : http://lists.gpsdrivers.org/pipermail/gpsdrive/attachments/20080513/411f9f74/attachment.bin 

More information about the GPSdrive mailing list