This week on the OSM lists…

So we are back again with another round up of the fabulous OSM mailing lists. First up, the redesign of the OSM front page, was kicked of by OJW with this entry. Top marks for including one of the only photos of a girl taking part in OSM data collection. Richard Fairhurst’s design included some sleek rounded borders – a challenge to replicate using only CSS. You can follow, or better yet, participate in improving the interface design of OSM here.

Next up, a question was raised about how you can find out about edits that are happening in your area. Because of OSM’s privacy policy, its not possible to query the API to find out who inserted or edited a node/segment etc. The ever wise and helpful Andy Robinson, pointed out that it is possible to subscribe to an RSS feed centred on a speceific location or of a specific user – more details here.

One of the longest threads recently has discussed entering street name details into OSM. It turns out that the situation is not as simple as tagging a node or way with a postcode or address, several issues complicate the situation. First off, as Andy R points out, tagging map data with address details will lead to a large increase in file size complexity. So TM and others suggest using address nodes that are tagged with a post code and address. The main problem with this approach is that it doesn’t take into account streets that have an irregular numbering system (what will we do when OSM expands to Japan where buildings are numbered based on the date they were built?). Postcodes largely remove the need for a geo-database to even bother with house numbers – but then a lot of countries either don’t have postcodes or have systems that are not as accurate as the UK system. Tom Chance hits the nail on the head when he points out that recording every single address as a tagged POI is totally impractical. What this all boils down to is the very worthy goal of using OSM for navigation – the defining factor must be whether people think that having addresses coded to house number level is worth it?

Tireless database warrior Nick Hill has been running tests on the DB, as well as upgrading to MySQL 5.1. As a result of Nick’s tests, the DB now stores lat and lon and integer values, sacrificing millimetre accuracy, but leading to substantially improved query times. The main bottleneck now exists within the rendering system – perhaps time to consider client side SVG rendering, Nick suggests.

Finally, there has been some discussion about representing areas. Chris Morley’s Chester map uses areas to colour parks – this is achieved by creating a way that is a closed loop and tagging it leisure=park, giving a green area. Or alternatively, tag natural=water to get – you guessed it – a blue area.

That’s all from the list this week. Keep on mapping and hacking…

Nickb