- OpenStreetMap dataset
- Map creation tips
- NASA Blue Marble possibles
- Australia positioning test
- GeoTIFF to gpsdrive tiles script
- GpsDrive 2.10svn built for Debian/Etch
OpenStreetMap's XML data to GRASS 6 vector import script and errors:
(requires GRASS 6.1 or newer)
image to the right (click to enlarge) shows OSM Segments as grey lines
and Routes (ways) as thick blue lines. My osm2grass.sh script is
intended for use with GRASS 6.1's v.net
vector network modules (road names, one ways, shortest path routing,
travelling salesman problem, etc.), so only valid routes are of use to
us. The segment road network can of course be connected with v.build.polylines and cleaned with v.clean for backdrop use or as the basis for an automated route labeling frontend.
You can generate the segment vector map from the above osm2grass.sh script. The route vector map is much smaller and takes a fair bit more processing to create, so I will provide a GRASS location* containg the "planet_rte" vector map and linked database. <download> (1mb). Google only lets me serve 10mb at a time, so a GRASS location containing the OSM segments built into poly-lines needs to be downloaded in two parts: <part 1> <part 2> (7mb ea.). Reconstitute with:
cat osm_rte_polyseg_* > openstreetmap_rte_polyseg_2006_05.tgz
[*] Map projection is Lat/Lon WGS84 (EPSG code 4326)
I have not included anything west of the Atlantic as the information
derived from the US Census Bureau TIGER dataset makes it way to huge.
My script is just a prototype and would need to be rewritten in a
compiling interpreter language (awk, perl, python, C, etc...) in order
to be fast enough to handle that. My main intention in writing the
script was to demonstrate the process. TIGER data can be imported
directly into GRASS via OGR using the v.in.ogr module.
Here's an earlier awk script for osm2shp by Alex Willmer.
To rank and display raw segments by length in GRASS 6.1 (or newer), create a new DB table for the "planet_seg" vector map (created from the osm2grass.sh script) with v.db.addtable and upload the lengths using v.to.db. You can then do statistical analyisis on them with v.univar or selectively display or extract the longer segments with a SQL query. e.g.:
d.vect planet_seg where="length > 1000" color=red
NASA Blue Marble GRASS import and gpsdrive backdrop creation instructions.
With the advent of WMS
servers, for city-wide map scales it is probably better to only fetch
the satellite data you need. There are two GRASS modules to do this, r.in.wms and r.in.onearth. You'll probabaly want to use r.in.onearth to fetch LANDSAT-7 "visible" data at 30m resolution and enhance the coloring with i.landsat.rgb before exporting with d.out.gpsdrive. Details here and here.
GRASS GIS d.out.gpsdrive backdrop creator help page.
(click to enlarge)
Here's a new GpsDrive backdrop image for the Tasman Sea:
top_TasmanSea.jpg -33.500000 160.875000 8867948
NZ and AU Airports as waypoints: way_tasman_airports.txt.gz
[derived from the Flightgear.org database, please read their disclaimer]
Screenshot of these airports with the top_Australia.png map.
Looks ok to me!
NOAA Nautical Chart 12326 "Approaches to NY Harbor" imported from a
BSB raster downloaded from NOAA's website, converted into GeoTIFF
using gdalwarp, and sliced into GpsDrive tiles using gdal_slice.sh.
Here's a script to convert a large GeoTIFF into registered gpsdrive
1280x1024 tiles, including a scaling file. It relies on the
gdal_translate utility from http://www.gdal.org. It may be worth investigating if gdal2tiles is a better solution. The same method can be used to slice up any of GDAL's many supported raster formats.
Here is the mailing list thread explaining the workflow for the BSB nautical chart example.
Correction to that post: do not use COMPRESS with gdalwarp. If you want to compress it use gdal_translate to write to another file with the compression instruction, then delete the uncompressed GeoTiff.
GpsDrive 2.10pre8.svn 2010-01-30 (r2527) build for Debian/Etch:
- No OpenStreetMap/Mapnik/GDA3/Speechd support; some dependent packages may be needed from backports.org and http://gpsdrive.sf.net (OSM icon sets for geonames.db)