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 > [email protected] > http://lists.openstreetmap.org/listinfo/dev > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
