Looks like Google have been sending out StreetView skiers at Whistler:
http://maps.google.co.uk/maps?hl=en&hq=http:%2F%2Fmaps.google.com%2Fintl%2Fen%2Fhelp%2Fmaps%2Fgames10%2Fsv-alpine-skiing-map.kml&q=Whistler+Creekside&ei=va1jS8jMHZGcjAPiz-G-Cg&sll=50.094972,-122.990841&sspn=0.014317,0.032015&ie=UTF8&view=map&geocode=FXxj_AIdB0-r-A&split=0&ved=0CBMQpQY&t=h&layer=c&cbll=50.079093,-122.952392&panoid=AIYiwpBxNQ7PAtX8H5zVcg&cbp=12,302.61,,0,0.03&ll=50.079176,-122.952504&spn=0,359.975839&z=15

I've been using AndNav2 on my Android phone for a while now, and despite a few crashes, I've been reasonably pleased with it - it does satnav and uses the OSM data. Until recently, that is. A few days ago, I needed to find a route whilst in the field, and so fired up AndNav2, only to be presented with a dialogue box telling me it had "expired" and had therefore been disabled, and that I would need to upgrade to the latest version. So I upgraded... and promptly found the latest version didn't work at all. Since the older versions are no longer available for download, and contain this moronic "expiry" thing which would render them useless, I'm now stuck without working satnav software. The author basically doesn't seem to care about the (fairly large number) of people who are now complaining that it is completely broken, even though the fix is trivial: remove the expiry check and allow people to download the version that works.

So now I'm looking for some satnav software for my Android phone that runs on top of the OSM maps - anyone got any bright ideas?

To recap, the following things the AndNav2 developer has done are *NOT COOL*:
1. Forcing all the users to upgrade in the field when they actually need the software, rather than letting them do the upgrade in their own time when they are safely at home.
2. Posting a *completely broken* "upgrade".
3. Preventing users from downgrading again to the working version.

Every time I start using closed source software, something like this happens and reminds me why I usually don't bother.

I've been playing with my new HTC Dream and trying to find a decent data collection app for OSM.

AndNav2 is a pretty nice satnav app, which uses the OSM data set. It also has built in support for OpenStreetBugs and recording GPX tracks. Unfortunately, it seems that when you switch away from the app (e.g. to take a photo), it shuts down the GPS and stops recording the GPX track. Also, it wants to zip the GPX files and frequently ends up breaking and producing a zero length zip, losing the track.

Then I came across CollectDroid, which is specifically designed for collecting OSM data. Unfortunately this seems to suffer a similar problem - when it isn't in the foreground it doesn't seem to record a GPX track (although it does leave the GPS running and a little icon in the status bar telling you it is recording.

Finally, the best app I've found so far is Google's own MyTracks. This does let you leave it going in the background and it keeps collecting. It takes a bit more prodding through menus to export to GPX format, but it does work.

However, all these apps suffer a bit of a problem when wandering: it takes several seconds for the camera app to fire up when you press the camera button, which is a bit annoying (although credit to Google - the camera app sticks geotags in the EXIF). What I want is an app that will show me the current OSM tiles as I'm walking along, together with my current track, let me quickly snap a photo or place a marker at my current location with some attached text. Bonus points if the app includes HDOP and orientation data (from the compass and accelermeters) in the photos and GPX file.

Last night I committed my osm2pgsql tile expiry code to Subversion. Various iterations of the code have been running on OpenPisteMap for the past couple of weeks and I think it is now fit for public consumption.

OpenPisteMap is now doing near-realtime map updates.

It pulls the latest changes from OpenStreetMap's database every minute and works out which map tiles are out of date. Zoom levels 14-17 are updated immediately, and lower zoom levels updated progressively less frequently.

How far the updates lag behind is dependent on how loaded the server is - expect anything from around 5 minutes up to a few hours, depending on the time of day.

After doing some performance tests, I discovered that there is a huge I/O latency overhead introduced by Xen, so I've been working to move the OpenPisteMap database into the Dom0 (OpenPisteMap is run from a Xen DomU virtual machine). The move is now complete and database queries are definitely running a lot faster. The system is now (easily) keeping up with the minutely planet deltas. For now it is only running 2 render threads, but I will experiment with that setting a bit.

On a slightly different note, my initial attempt at working out which tiles are dirty after each update so that they can be automatically re-rendered turned out to be rather too simplistic. I had decided to try drawing a bounding box around every object and dirtying all the tiles within that bounding box, but unfortunately some objects can end up being huge (especially relations), so this resulted in an unfeasible number of tiles being marked as dirty. Some more intelligence is needed here - I think my next attempt will be to calculate which tiles a LINESTRING actually intersects with. I'm not entirely sure what to do with POLYGONs though - it may be wise to introduce some size limits so that polygons under that size limit have all the tiles within them dirtied whilst polygons over the limit would be treated as LINESTRINGs (the theory being that we probably aren't going to shade the area inside huge polygons).

The skiing season is almost upon us, with The Lecht and Cairngorm having opened for last weekend. I was aware of some problems with contour rendering on OpenPisteMap, but now it seems it is affecting the rendering of the actual pistes too. Comparing 2 zoom levels of the same area:
http://openpistemap.org/?lat=46.09542&lon=7.24663&zoom=14&layers=B000
http://openpistemap.org/?lat=46.09542&lon=7.24663&zoom=15&layers=B000
Some of the pistes just aren't rendering in some zoom levels.

My only guesses are that either Mapnik or the PostGIS spatial index is broken. Unfortunately, if it is the latter I suspect I'll have to drop the whole database and start from scratch. :(

I got a bit carried away today - I had intended to map a short section of road in Pantlasau and then go up near Clydach to fill in some missing roads and names. But I ended up finding an interesting looking footpath and curiosity got the better of me; so I spent the afternoon investigating that path and some tracks leading off it.

In the end I found myself at the *enormous* 275KV Swansea North electricity substation. And it was pretty loud too - you can hear the 50Hz buzz from the transformers a good couple of kilometres away from it. On the way back home I discovered a rather useful footpath crossing some fields to the North of the housing estate, so I can make use of that when I *actually* go up to Clydach to fix up these roads. :)

It looks like there's something screwey with the tracks I'm recording while driving around. I have a computer in my car which runs Kismet. I plug my eTrex Venture GPS into it, letting Kismet record a track from the NMEA stream (via gpsd) and then process Kismet's GPS logs into GPX files. But I just compared one of the Kismet data sets with a track downloaded directly from the eTrex with gpsbabel and the tracks are consistently offset from each other by about 100 metres or so. So now I've got to work out where on earth the error is being introduced. The GPS is set to WGS84 and I presume Kismet is too dumb to try and do any kind of datum conversion on the coordinates so I'm a bit stumped.

I've now mapped almost all the roads in the patch I have been working on, having done a stack more roads around the Ynstawe area. My Sunday afternoon stroll around the estate became unexpectedly long when I discovered the very pleasant footpath along the Clydach river and followed it all the way up to the Cwm Clydach nature reserve.

There are still quite a few little footpaths to do, but I probably won't do those at the moment - I think mapping the roads is a more productive use of time for now. However, I must walk along the Swansea Canal tow path at some point and map it. I've noticed that Google Maps gets it *completely* wrong, showing the canal joining the Clydach river - in reality the canal crosses the river as an aquaduct and continues a for few hundred metres South, whilst the river joins the Tawe just on the South-East side of the aquaduct.

I haven't quite worked out the best way to tag aquaducts though - setting waterway=aquaduct seems a bit silly since it doesn't let you specify the sort of waterway being carried (i.e. canal), so for now I have settled on bridge=yes instead.

Summer has arrived (although still rather cold around here :) and it's time to get outdoors and do some rock climbing.

But I discovered that there seems to be no way to tag crags, routes, etc (well, there's the sport=climbing tag, but how to use it is rather ambiguous). So I've started putting together a set of tags:
http://wiki.openstreetmap.org/index.php/Proposed_features/Climbing

Representing vertical features is quite a difficult problem - at the moment I have opted to just mark the start of each route with a single node. However, I'm not sure how to show the difference between a path leading to the start of the route and one leading to the end - maybe the solution is to allow the use of ways to show the route, even though the start and end will often be practically on top of each other.

I've been spending some time fixing up bits of the Gower coastline by tracing the (rather fuzzy) yahoo photos. For the most part, leaving the existing natural=coastline way where it is (which should be roughly the high tide line... ish) and filling in each beach as two areas - one inside the coastline and one outside the coastline with a water=tidal tag. I've been using surface=sand/rocky/etc. to describe the type of ground.

At the moment they are also tagged with natural=beach but I favour deprecating this tag since it is rather ambiguous and the surface tag should give enough information about how to render it.

I've drawn the tidal bits of beach down to the water line shown in the yahoo photos, which seems to be a lowish tide for most of the area. But Swansea Bay seems to be photographed at high tide, so this will be harder (I'm not wading through that knee-deep mud at low tide with a GPS! :)

After some digging, it seems there is no documented way of tagging lifeboat stations and lifeboats. Tagwatch also didn't turn up anything especially obvious, so I've created a tagging proposal:

http://wiki.openstreetmap.org/index.php/Proposed_features/Lifeboat

I've tagged the Horton lifeboat station in accordance with this proposal. I may contact the RNLI to see if they will provide a copyright-free list of lifeboat stations and their locations (although I suspect they won't have the lat/lon for them all :( ).

I've created a wiki page for Swansea:
http://wiki.openstreetmap.org/index.php/Swansea

Hopefully this might generate a bit more interest in mapping the area, as well as allowing the mappers to jot notes on their progress and which areas they are mapping.

I noticed amillar's diary entry about hiding your home on GPS tracks so thought I'd mention a script I wrote to process GPX files:

http://public.subversion.nexusuk.org/projects/kismet-tools/trunk/gpx_trim.py

This lets you specify bounding boxes - any track segments starting or ending in the bounding boxes will be trimmed to remove the bits contained in the box. If the track just goes through the bounding box instead of starting/ending in it, it is left as-is.

Yesterday's planet.osm has now been imported into OpenPisteMap - things will be a bit slow since the tile cache has been purged.

It looks like quite a lot of new piste map data is in there, some of the resorts are looking fairly complete.

I've now got contours rendering on http://openpistemap.org thanks to the very helpful Contours wiki page created by Gravitystorm (of cycle map fame) (http://wiki.openstreetmap.org/index.php/Contours).

I've taken a slightly different approach, which I think is a bit neater - instead of leaving the contours data as shapefiles I have imported it into PostGIS. I've updated the Contours wiki page with this alternative method.

The piste map is now rendering the whole planet data set rather than just one resort (but it won't update regularly yet), and it will render contours for most of the European ski resorts. I need to work out which bits of other continents I should be including contour data for (let me know if there's anywhere I've missed).

I've got http://openpistemap.org in a vaguely working state, but it still needs a *lot* of work. At the moment it is only rendering data in the Verbier - Zermatt region and won't automatically render new data.

I've had a go at setting up a contour map on it as well, but so far haven't had much success... generate_tiles.py chucks up lots of "proj_init_error:failed to initialize projection with:+proj=latlong" after working through most of
http://wiki.openstreetmap.org/index.php/Contours_on_the_Cycle_Map, so that's something to continue fiddling with tomorrow.

So anyway, I've got Mapnik working and I'm starting to play with setting up contour data (and wow, that needs serious amounts of disk space!)

One thing that's bugging me though, is how to get OpenLayers to use degrees for the permalink? OSM itself seems to do it, but my code (and the OSM cycle map) don't... I tried swiping the "new OpenLayers.Map()" usage from OSM but it's still not happening...

I've been trying to set up Mapnik, but I've hit a problem...

Trying to import the coastlines with shp2pgsql gives me errors:

INSERT INTO "shoreline_a" ("error","tile_x","tile_y",way) VALUES ('0','17','286','SRID=900913;0106000000010000000103000000010000000200000000000060307C71C1522159370A6F604100000060307C71C1522159370A6F6041');
ERROR: geometry requires more points

Followed by lots of:

ERROR: current transaction is aborted, commands ignored until end of transaction block

This is running under CentOS 5.1 with postgis-1.3.2-1.el5.rf - can't see any useful references to this error in Google though. :(