[OSM-talk] Using Osmarender to hilight Relation/Routes?

[Andy Allan]

On Fri, May 16, 2008 at 7:51 AM, Thomas Wood <grand.edgemaster at gmail.com> wrote:
> The gravitystorm use a custom version of osm2pgsql and their own
> mapnik rendering rules afaik. The xsl of osmarender has nothing to do
> with their map, but osmarender did have a cycle stylesheet, but it
> wasn't well used (and was from api0.4 times).
> I guess Andy Allan may add his notes to this thread at some point.

Sure.

The way we handle route relations is to process them and add an
additional way for each member of the relation (simply by finding the
member way of the relation and duplicating its geometry). Then you
have stuff that's renderable. So at
http://www.gravitystorm.co.uk/osm/?zoom=16&lat=6702764.64156&lon=-16109.73934&layers=B00
we have a four polylines in the database, one for the cycleway and one
each for the three routes that cross the park. Mapnik collision
detection on the references show each side-by-side. The limitation of
this method is that the relations are processed after the import, so
only nodes and ways that have made it through the osm2pgsql process
(i.e. have useful tags on them) are available at that time.

The garmin cycle maps operates in a slightly different way, but still
involving pre-processing - instead of adding duplicate ways it adds
the references to the existing way - this is so that you can
"mouseover" a road and all the references appear. So the same example
has one polyline with one reference, just a concatenation of the three
refs with spaces.

So there's different approaches, but generally involves unwinding the
route relation back into ways (or nodes), and depending where in the
process you do so you do things differently. As for osmarender, that's
black magic to me, but I think the concept of trying to add tags to
ways or duplicating the ways with more tags will still hold - probably
the former due to the lack of text-placement collision detection.

Cheers,
Andy