[OSM-dev] OSM renderer -- which way now?

[Nick Whitelegg]

With a good deal of discussion on how to speed up the database queries, I'd 
like to raise the issue of what the future is for the OSM renderer. I'm 
particularly interested in this regarding Freemap; what I'd kind of like to 
do with Freemap is to use the default OSM renderer, but configured so that 
the maps are drawn in a "Freemap" style.

One option would be to keep a live renderer as now. If the bottleneck is with 
SQL queries and caching, and SQL queries and caching can be optimised (as 
extensively discussed on another thread) this would seem viable.

Another option would be to develop something else which runs off planet.osm, 
or a read-only version of the database. My gut feeling and personal 
preference w.r.t Freemap (warning - not backed up by research) would be to 
develop something custom rather than use Mapserver; it seems to me that 
something designed from the ground up using OSM's data model (e.g with Map 
Features as a core feature of any configuration) would be more easily 
configurable by OSM users, and you wouldn't be battling against another data 
model. This could be configured by a MapFeatures.xml file (as suggested by 
Joerg) or an osmarender rules file. If we did this there could again be a 
number of options:
     - use existing Ruby code. Pros: less maintenance overhead, performance 
issues could be lessened by good caching. Cons: performance.
     - use the fastest possible language, i.e. C. Pros: performance; other 
systems like mapserver use C. Cons: more maintenance.

Part of this code could involve exporting to other formats such as shapefiles, 
for interoperability with other applications.

If people agree that a configurable renderer, a custom OSM solution would be a 
good thing (from the point of view of freemap, I would certainly say so) I 
will prioritise this in my list of coding tasks, and get going on it. But if 
people *don't* see this as good, again let me know as I don't want to waste 
time coding something which will not be used :-)

Nick