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 [EMAIL PROTECTED] ;) 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
