When I arrived in Vientiane in August 2009 the OpenStreetMap was quite empty, there were only some unconnected roads traced from Yahoo imagery and a few points of interest. It was my second or third weekend when I took my GPS, a pencil and a sketchbook and started mapping the downtown.
Friday, September 30, 2011
Wednesday, September 21, 2011
Find your way with openstreetmap.la
I'm really happy to announce the latest update on openstreetmap.la: Routing has been integrated to the main page.
As illustrated in a previous post I evaluated the capabilities of the Open Source Routing Machine amongst other routing engines. The speed and the web-oriented architecture of the Open Source Routing Machine convinced me to use it as a backend to implement routing on openstreetmap.la.
As illustrated in a previous post I evaluated the capabilities of the Open Source Routing Machine amongst other routing engines. The speed and the web-oriented architecture of the Open Source Routing Machine convinced me to use it as a backend to implement routing on openstreetmap.la.
Monday, September 12, 2011
Rivers and lakes downloads available on openstreetmap.la
During my two-week trip through Laos I collected some tracks and points of interest, of course ;). Last week I started to add them to OpenStreetMap when I realized that there are still a lot of rivers missing. I traced (rather randomly) some parts of rivers from Landsat or where available Bing imagery.
Sunday, September 4, 2011
Google Fusion Tables in QGIS
Since version 1.9 (currently still in trunk) OGR supports Google Fusion Tables. There are instructions online available that show how to upload Shapefiles to Google Fusion Tables using OGR e.g. a video from the Google I/O conference (starting at 26:30 with an introduction to GDAL/OGR).
Thursday, August 18, 2011
Garmin maps with contour lines
Some days ago I read in the OpenStreetMap wiki about maps for Garmin devices featuring contour lines. Interested in topographic Garmin maps for openstreetmap.la, I started to create maps with contour lines for Laos. As often happens it took me longer than I expected to figure out a suitable work flow, mainly because I ran in several memory issues.
I started with the generation of contour lines from the SRTM (and CGIAR improved) terrain model using gdal_contour. After about two hours calculating on a more capable work station (than my laptop), I got a 900MB heavy Shapefile. Based on this GDAL output, my plan was to convert the lines to the OSM format to use finally mkgmap.
To be able to deal reasonably with this amount of data I put the lines with shp2pgsql into a PostGIS database. Storing data in a PostGIS database facilitates faster spatial and attribute queries.
My first idea was to convert each contour level with ogr2osm to the OSM format. ogr2osm is a very flexible Python script I like to use, but in this case it refused to work for unknown reason. I had to use the two step approach with ogr2ogr and gpsbabel. For each contour level between 0 and 3000 I scripted the following steps and subdivided the levels in minor, medium and major contours according to the Garmin features land-contour-thin, land-contour-medium and land-contour-thick.
Query the database and write the result as tracks to a GPX file.
Use gpsbabel to convert the GPX file to an OSM file and add corresponding tags.
Since it is not possible to add an elevation to a GPX track (only to points), I wrote the elevation to the name attribute. Now I had to replace the name tags with ele.
The versatile osmosis program, I wanted to use to compress the data to PBF format, still didn't accept the file since it did not comply with the API v0.6. I had to add a version and timestamp attribute to each node and way and replace the negative identifiers with positive ones.
Applying mkgmap to this file, mkgmap ran inevitable out of memory. It was necessary to split first the data (with splitter) to tiles manageable by mkgmap. I used the following tiles with dynamically generated map names for each tile and contour level:
Using this approach I finally managed to create map tiles in the Garmin IMG format.
Last step was to merge all contour lines maps with the OpenStreetMap data, but this could easily be done by mkgmap.
The result looks as follows:
The map is can be downloaded as gmapsupp.img from openstreetmap.la or directly from here. There are detailed instructions on the OpenStreetMap wiki how to store a gmapsupp.img file in your Garmin device.
Update 9.9.2011: Due to problems with the routing, I've removed again the contours. To be continued ...
I started with the generation of contour lines from the SRTM (and CGIAR improved) terrain model using gdal_contour. After about two hours calculating on a more capable work station (than my laptop), I got a 900MB heavy Shapefile. Based on this GDAL output, my plan was to convert the lines to the OSM format to use finally mkgmap.
To be able to deal reasonably with this amount of data I put the lines with shp2pgsql into a PostGIS database. Storing data in a PostGIS database facilitates faster spatial and attribute queries.
My first idea was to convert each contour level with ogr2osm to the OSM format. ogr2osm is a very flexible Python script I like to use, but in this case it refused to work for unknown reason. I had to use the two step approach with ogr2ogr and gpsbabel. For each contour level between 0 and 3000 I scripted the following steps and subdivided the levels in minor, medium and major contours according to the Garmin features land-contour-thin, land-contour-medium and land-contour-thick.
Query the database and write the result as tracks to a GPX file.
# ${level} means the currently processed contour level
ogr2ogr -f GPX -lco FORCE_GPX_TRACK=YES -sql "SELECT wkb_geometry, name FROM srtm_contours WHERE name=${level} AND ST_INTERSECTS(wkb_geometry, ST_SetSRID( ST_MakeBox2D( ST_POINT(100.1, 13.9),ST_POINT(107.7, 22.5)), 4326))" -nlt MULTILINESTRING ${outdir}/${prefix}_${level}.gpx PG:"dbname=openstreet user=openstreet"
Use gpsbabel to convert the GPX file to an OSM file and add corresponding tags.
gpsbabel -i gpx -f ${outdir}/${prefix}_${level}.gpx -o osm,tag="contour:elevation;contour_ext:${contour_ext}",created_by= -F ${outdir}/${prefix}_${level}_tmp.osm
Since it is not possible to add an elevation to a GPX track (only to points), I wrote the elevation to the name attribute. Now I had to replace the name tags with ele.
sed 's/name/ele/g'
The versatile osmosis program, I wanted to use to compress the data to PBF format, still didn't accept the file since it did not comply with the API v0.6. I had to add a version and timestamp attribute to each node and way and replace the negative identifiers with positive ones.
cat ${outdir}/${prefix}_${level}.osm | sed "s/node\ /node\ version='1'\ timestamp='2010-08-01T12:00:00+02:00' /g" | sed "s/way\ /way\ version='1'\ timestamp='2010-08-01T12:00:00+02:00' /g" | sed "s/'-/'/g" | osmosis --read-xml file=- --write-pbf omitmetadata=true ${outdir}/${prefix}_${level}.osm.pbf
Applying mkgmap to this file, mkgmap ran inevitable out of memory. It was necessary to split first the data (with splitter) to tiles manageable by mkgmap. I used the following tiles with dynamically generated map names for each tile and contour level:
 |
| KML split-file for splitter on Google Earth |
Last step was to merge all contour lines maps with the OpenStreetMap data, but this could easily be done by mkgmap.
The result looks as follows:
 |
| Highest mountain in Laos |
 |
| Cave near Vang Vieng |
The map is can be downloaded as gmapsupp.img from openstreetmap.la or directly from here. There are detailed instructions on the OpenStreetMap wiki how to store a gmapsupp.img file in your Garmin device.
Update 9.9.2011: Due to problems with the routing, I've removed again the contours. To be continued ...
Saturday, August 13, 2011
Search bar on openstreetmap.la
I'm pleased to announce a new feature on openstreetmap.la: a search bar to find places and points of interests like hotels, hospitals, restaurants or convenience shops.
To facilitate the search, the search bar implements auto-completion: Start typing the name of any place or point of interest, and a drop-down menu suggests available places or points containing this name. A small icon in front of the name indicates if it's a village, restaurant, hotel etc. The icons corresponds in most (!) cases to the map symbols. Villages, towns and cities are the exception, since places have a label but no icon on the map. The icons for places used in the drop-down menu look as follows:
See the following screenshots:
A map marker highlights the found place:
As always: feedback is highly appreciated!
To facilitate the search, the search bar implements auto-completion: Start typing the name of any place or point of interest, and a drop-down menu suggests available places or points containing this name. A small icon in front of the name indicates if it's a village, restaurant, hotel etc. The icons corresponds in most (!) cases to the map symbols. Villages, towns and cities are the exception, since places have a label but no icon on the map. The icons for places used in the drop-down menu look as follows:
|
|
|
See the following screenshots:
 |
| Search bar with autocompletion |
 |
| Works also in Lao |
A map marker highlights the found place:
 |
| Map marker |
As always: feedback is highly appreciated!
Sunday, August 7, 2011
Open Source Routing Machine: Yet another routing engine
Initially I only wanted to some routing on OpenStreetMap data with GRASS GIS. Then I also tried pgRouting and later SpatiaLite. Using pgRouting as backend, I set up a simple web application following the well explained pgRouting workshop. But I wasn't really satisfied since the routing starts only at the closest node, that's basically less a problem in the city than on the countryside with less junctions (and thus less nodes).
Finally I turned away from GIS to specialized routing software for OpenStreetMap, namely to Routino and to the Open Source Routing Machine, short OSRM. I was that impressed by the speed of OSRM, that I decided to have a deeper look at this engine:
I adapted the simple web frontend I developed for pgRouting to work with OSRM as backend and put everything online. I'm pleased to present the current proof-of-concept prototype:
http://www.openstreetmap.la/dev/routing/
As soon as time allows I'll integrate the routing on the openstreetmap.la main page.
Finally I turned away from GIS to specialized routing software for OpenStreetMap, namely to Routino and to the Open Source Routing Machine, short OSRM. I was that impressed by the speed of OSRM, that I decided to have a deeper look at this engine:
Pros
- Speed! OSRM is about speed and it claims to be capable to handle continental sized networks using memory efficient third party libraries like google-sparsehash. It was a matter of seconds to preprocess the 6.2 MB Laos PBF file.
- Web-oriented: includes a server that runs on a configurable port and thus it is very easy to integrate in any web application.
- Since it's developed for OpenStreetMap, it considers out of the box OpenStreetMap tags like oneways etc.
Cons
- Configuration is not trivial, since speed and highway categories are hard-coded.
- Installation with Scons was very laborious on the server, since I had some dependencies in my home directory and it was necessary to fiddle the SConstruct file.
- Missing GeoJSON support. But since it needs anyway a proxy script to use OSRM in Ajax requests, it was a quick hack to reformat the homebrew JSON output to proper GeoJSON.
I adapted the simple web frontend I developed for pgRouting to work with OSRM as backend and put everything online. I'm pleased to present the current proof-of-concept prototype:
http://www.openstreetmap.la/dev/routing/
As soon as time allows I'll integrate the routing on the openstreetmap.la main page.
Subscribe to:
Posts (Atom)