* Richard Weait <rich...@weait.com> [2010-08-08 07:45 -0400]:
> Let's do a "shields" BoF at Atlanta next weekend. I have some ideas
> that make shields much easier and even solve shield concurrency.
I'm not going to SotM-US, so let me just mention what I've experimented
with (unsuccessfully).
What I'd like to see with shields is: If a road is a member of a US,
Interstate, state, or county route relation, render an
appropriately-sheped shield with the route number at zoom levels
appropriate to the road's highway= tag. Road ref= tags should only be
rendered if the road is not a member of any route relations. If a road is
a member of multiple route relations for different routes, it should have
all shields rendered, with reasonable spacing. If a road is a member of
multiple route relations for the same route (this happens with the
per-state relations and super-relations for Interstates and US highways),
rendering should be the same as if it were only a member of one relation.
(In other words, adding a super-relation shouldn't double the number of
shields rendered.)
I'm mostly focusing on rendering with Mapnik, since that's what most of
the web-based slippy maps use, including the main one.
Ignoring the roads' ref= tags completely and only rendering the shields
from the route relations is one approach, but it then leaves roads without
route relations (like a lot of state and couty roads) without shields, and
it loses the ability to decide when to render the shields based on the
roads' classifications; you would instead have to pick particular zoom
levels at which to start each type of shield.
On the other hand, if you render the shields from the route relations with
the road information, you run into two main problems. One is that roads
may be broken into almost arbitrarily-small pieces, which could result in
diplicate shields very close together. The other, more important one, is
that the information is now in two places in the PostGIS database, and I
have yet to find an SQL query that doesn't get really slow trying to JOIN
that information.
My best effort has been to generate a link table that contains the OSM IDs
of routes, the PostGIS IDs of those routes (just the OSM ID negated), and
the OSM IDs of their member roads (which are also the PostGIS IDs). Then
you do something like
SELECT road.highway, route.network, route.ref
FROM planet_osm_line road
JOIN route_members ON road.osm_id = route_members.road_id
JOIN planet_osm_line route ON route_members.postgis_id = route.osm_id
Unfortunately, in my experience, those JOINs get really slow. I've tried
working with the query planner to get speed improvements, but haven't
achieved much.
My next thought, for when I get back to working with shield rendering, is
to try making a denormalized table that contains the information from the
JOIN that I need. That approach will require some degree of modification
to osm2pgsql in order to maintain that table through database updates, but
it's the best way I can see forward.
Once you have a query that gives you highway= from the road and route= and
ref= from the relation, addressing almost everything from my "what I want"
paragraph becomes really simple. (I haven't figured out a way to suppress
shields from the super-relations yet.)
While most of my thought about the actual rendering are basically "make
separate images for each network shield for refs of one, two, and three
characters long", I've been pondering how to use the symbol= tag on the
route relations. Mapnik 1 simply can't, as far as I can tell; its shield
images need to be configured statically. I haven't played much with
Mapnik2, but apparently it has more dynamism in its renderings, so it
might be able to use them, if it can fetch images from URLs (preferably
only once; caching the downloads during a run).
--
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2
--- --
Don't have good ideas if you aren't willing to be responsible for them.
-- Alan Perlis
---- --- --
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
