2010/11/23 Michael von Glasow <mich...@vonglasow.com> > Hello list, > > For my efforts mapping public transportation routes in Milan, I have up to > now relied on Öpnvkarte to look at the data I entered and occasionally look > up the best way to get around town. > > In the meantime the situation has changed: Öpnvkarte hasn't been updated > since early September; a similar service at latlon.org has discontinued > coverage for Western Europe (they seem to have limited themselves to > Belorussia, Russia and maybe some of their neighbors) and the third player > in the field, OSM Transport, comes with disadvantages (slow to load, slow to > update, less "nice" to use and not open-source). > > > Couldn't we do something similar right on the OSM homepage, running on OSM > infrastructure? > > > The advantages would be: > - Easy switching between "normal" and "public transport" view (just a > matter of switching base layers) > - Only one URL to remember > - Uses most recent data (if directly connected to live OSM database) > - Standard OSM tools available (for instance, exporting the map as PDF) > - Could be a "killer app" for OSM (until now this information is available > only for single networks from their respective transport companies, if at > all; OSM would be the first to do this for the whole world) > > > Following the iterative approach with which OSM was and is being built, > here's how it could be implemented: > > Step 1: Add the new map view > > Create a new Mapnik style sheet with routes and numbers overlaid on it. I > would suggest the familiar Mapnik view but in black and white (at the most I > would color some landuses), possibly reducing the number of POIs if the map > gets too cluttered. All stop names would be shown; routes and their numbers > would be drawn in color on top of everything else. This would preserve all > information but make public transport data stand out. > > This should be fairly easy, it would take a second Mapnik style sheet and > possibly some post-processing to render the routes. The database is already > there; all rendering-related effort I would expect to roughly double as > every tile would get rendered twice (once per style). Not sure about the > effort to run Mapnik with two different styles. > > This woudn't cause mapnik to render double. I believe mapnik only renders when a tile is visited and changed, or after a longer period. As long as nobody visits the tile, it wouldn't be rendered for a long while. On the other hand, maybe mapnik could render both styles while the info needed is still in the RAM and not on the main disks, but I don't know what costs the most time: loading data from HDD to RAM or processing the data.
> Step 2: Add stop information > > Add a new overlay, which makes all stops clickable. Clicking on a stop > opens a bubble with information on it, such as name and lines stopping > there. > > This would require some extra coding, but most of the work has been done > already (e.g. OpenStreetBugs, which has an overlay for clickable bugs). Some > extra post-processing will probably be needed on the data in order to group > nearby stops belonging together (take Munich's central station, which > consists of one light railway stop, two subway stops, three tram stops and a > couple of bus stops): that way the user just needs to click the station and > gets a popup with all the light railway, subway, tram and bus lines. > Öpnvkarte already does this, so it's not impossible. > > Step 2a: Line sketches > > In the popup for each stop, clicking the line number opens a new window > with a sketch of the line. > > Probably easy play: Sketch Line from OSM Server Scripts [1] (example [2]) > already does an excellent job at this; just the choice of colors may need > some tweaking. The only problem is that the output is in SVG format, which > not all browsers out in the field handle well: we may need to convert that > into a bitmap on the fly. > I believe most power users don't use a ie browser. So if they are not power users, the extra clicks to download and view it are small. So converting it is not really needed. > > Step 3: Extensions > > Up to the imagination of the community: For example, if one day we add > routing to the OSM page, we could extend that to finding a public transport > connection. > > A project that could help in the future with routing: transiki<http://www.transiki.org/>it's still in alpha stadium, but if it gets of the ground, it might be wurth implementing it in OSM. (in both ways: transiki giving data to OSM for routing and OSM having a dialog to input data in Transiki.) > > Taking Milan as an example, step 2a would already put us ahead of what > Google has to offer today: Transit is not available for Milan yet, bus stops > are missing completely on the map, the location of subway stops is > approximate at best and the network data seems to be out of date. > > > Now here's the catch: While I am ready to contribute to such an effort, I > cannot do it alone - my knowledge of the OSM infrastructure is generic at > best. Is there anyone out there who: > - knows how to get started in order to get new items on the main OSM page, > in terms of both technology and who to talk to? > - is willing to participate in such an effort? > > Any input is greatly appreciated. > > Michael > > > [1] http://wiki.openstreetmap.org/wiki/OSM_Server_Side_Script > [2] http://78.46.81.38/api/sketch-line?network=SITAM&ref=19&style=padua > > _______________________________________________ > Talk-transit mailing list > Talk-transit@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-transit >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit