[OSM-talk] Ideas for OSM enhancements

[Richard Fairhurst]

Nick Whitelegg wrote:

> One would be to do something similar to what I already do on   
> Freemap, namely clickable POIs: The user could click on a POI then   
> get a window containing a link to its Wikipedia article (if   
> applicable) and its description tag (if it has one).

Generally a great idea - it helps to showcase our rich data.

A minor point, but I'm very strongly opposed to favouring one website  
over another. If there are multiple URL-like tags for a POI (or way),  
we should display either all of them, or an impartial selection of  
them if space forbids (e.g. the first five alphabetically, with "click  
for more").

OSM has no special ties with Wikipedia: some OSMers are Wikipedians,  
some are decidedly Wikipedia-sceptics. In many cases, of course, the  
POI's "official" URL will be more informative than the Wikipedia  
content - you'll find a lot more about UK canals on Waterscape.com, a  
lot more about UK cycle routes on sustrans.co.uk, and so on.

> The second (and I think this is already on the "todo" page) would be  
>  to make a web interface for creating Garmin maps, where a user  
> could  select an area and then a Garmin .img map of that area would  
> be  generated. I can see two ways of doing this - implement in JSP,  
> grab  OSM data through the API and link to existing mkgmap code, or  
> (and  much more work) reimplement mkgmap in Ruby to link with the  
> rest of  the site.

Heh, I've been thinking about something similar over the past four  
days - something to do with getting a Legend HCx for Christmas. ;)

Again, let's not be too specific. There are lots of export formats  
that OSM users might want. Garmin users want .img; GIS people want  
.shp; people planning to go out walking with a nicely cropped paper  
map might want .pdf; cartographers want .ai; and so on. Yes, it's our  
old friend the export tab again.

The point about reimplementing mkgmap in Ruby not being fun is  
well-made. So how about something like this?

1. User requests file
2. If file is already cached, deliver it
3. Otherwise send request to some file-making service or other
4. Regularly refresh a "Please wait" every 5 seconds until the file is ready
5. Deliver file to user, and cache it for future use at step 2

You could even couple it with a distributed architecture and call it  
files at home. ;) It also means that our 8 zillion Perl scripts to  
convert OSM data to something-or-other don't have to be reimplemented.

cheers
Richard