[OSM-dev] GSoC Ideas

[Milo van der Linden]

Paul Wicks wrote:
> Hello all,
>
> My name is Paul Wicks and I am a Computer Science major at the 
> University of Puget Sound and I am interested in taking part in the 
> Google of Summer of Code for the OSM project.
>
> The idea in the list that seemed to appeal to me most was the creation 
> of a Static Map API. I'd be very interested in implementing something 
> of this nature and have a bit of a basic plan sketched out (note that 
> some of this is mentioned in the ideas list and also discussed a bit 
> previously here).
>
>
> 1. Receive Latitude and Longitude coordinates, along with zoom level 
> information, and return a static image (probably start with something 
> really simple like ppm and go from there). Once this was achieved, 
> everything else can be built up. The rendering path for images would 
> have to be investigated (although from what looking I have done it 
> looks like maybe mapnik would be the way to go, although it was 
> suggested earlier that perhaps it would be better to grab the image 
> tiles from the OSM servers and stitch them together), as I am not too 
> familiar with the internals of OSM, having only used it for street 
> maps up until now.
Please read into the standard WMS protocol. Information can be found at:
Official documentation: http://www.opengeospatial.org/standards/wms
Mapnik's implementation of wms: http://mapnik.org/news/2006/apr/18/wms/


Mapnik could act as a wms server, but this would not be good for 
performance since all rendering would be done straight from the 
openstreetmap db on the fly. A better trick would be to implement a 
tile-layer in a wms image server, the image would then take the required 
tiles, sticht them together in the requested projection, cut the area 
that is requested and return that to the client.
>
> 2. Once the absolute basics were in place, work on making it more 
> useful. Maintaining a local cache of static maps would be important, 
> so that maps would only need to be rendered once (although maybe maps 
> should expire, since the canonical OSM map could itself change). Work 
> would need to be done to determine the best way/place to store this 
> data, especially considering that this project would most likely be 
> aimed at deployment on Google App Engine. The other important thing, 
> as I see it, would be to graft a key authentication mechanism on top 
> the api, to prevent abuse. This seems like something that someone 
> might have already written for django, so that would be good to look 
> into. If not, it shouldn't be too difficult to create something of the 
> sort.
Caching with WMS is something that, as far as I know is not common, If 
you can figure out a way of caching and write a proposal, please also 
offer it to the mentor group at www.osgeo.org, they would gladly help
>
> 3. Once the first 2 items were done, it would be more or less open 
> season on whatever features were thought to be most useful. Markers 
> (various types, colors, capacities), Paths/lines/boxes/shapes (again, 
> many of the same options), additional caching backends (might as well 
> increase the number of places that can run it as much as possible and 
> not get locked into app engine), more image formats (jpg, gif, png, 
> svg, pdf), different map themes (allow the api call to specify the 
> colors of various map features, would this be possible/desired? maybe 
> just have a dark theme and a light theme, that would probably 
> encompass most needs for this feature)
That is nothing new, it is merely a matter of adding layers in the wms 
request.
>
> Another important thing would be to build a basic test suite around 
> the api, both for benchmarking purposes and to help ensure it's 
> integrity as development progressed.
Stick to the open protocol and your testing will also be defined. You 
can use a lot of free wms clients around for testing:

uDig
qGIS
JOSM
Merkaartor
>
> In the ideas list, django was mentioned as a possible platform for 
> this and I would agree, for much the same reasons: it is written in a 
> popular language and platform, meaning more developers in the future; 
> deployment should be fairly easy, especially on something like app engine.

>
> Another wild thought I had was to create some sort of application that 
> uses/showcases OSM for the iPhone/Android/Pre. This seems to be a hot 
> new place for development these days and it would be cool to have an 
> app that showcases OSM on one of these new mobile platforms. Perhaps a 
> basic maps applicaion that uses OSM (although it looks like a 
> jailbreak iphone can use OSM in the official maps app 
> http://brainoff.com/weblog/2007/10/19/1271 ) or maybe something more 
> specific, something that shows the strength of the OSM project. I'll 
> have to think about this one some more.
>
> If this is not the place for this discussion or I've made any large 
> errors, please let me know.
>
> Thanks for your time.
>
> -Paul Wicks
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>