[OSM-dev] Getting admin_level=* from relations to render properly

John Smith deltafoxtrot256 at gmail.com
Wed Apr 28 08:27:39 BST 2010


On 28 April 2010 17:00, Lennard <ldp at xs4all.nl> wrote:
> How did this occur to you? Tagging the ways is even explicitly
> documented on the wiki.

That makes no sense when rendering can derive it from relations to
pick the most important (lowest admin_level value) without people
needing to know which way is part of which relation.

> If the relation forms a closed loop, and is tagged as a boundary, it
> should currently render.

Ok, here's the way and here's the relation and here's the rendering,
please explain why it's not rendering the relation how ways nearby
render:

http://www.openstreetmap.org/browse/way/32295414
http://www.openstreetmap.org/browse/relation/80372
http://osm.org/go/uTRwIeeW-

> Should work currently. The major drawback to also drawing boundary
> relations is that they can stack (in osm2pgsql+mapnik). Where a tagged
> boundary way is part of n boundary relations, you will see n+1
> overlapping lines in the render. IMO this is ugly, and you get no sense
> of the actual admin levels involved.

That may be what's happening, in which case that's pointing out where
we need to look, we should structure the SQL query to return only one
way, with the highest admin_level.

> Rendering just the boundary way makes for a clean border render, with a
> predictable appearance. To this end, the wiki documentation describes
> tagging the way with the highest order (lowest value) of admin_level. As
> far as I'm aware, Tiles at Home already take this approach, and does not
> render boundary relations.

So you admit the logic can be problematic with the rendering, doesn't
that mean we're tagging incorrectly for renderers?

> I trust people will now bring the "don't tag for the renderer" mantra

How'd ya guess? :)

> into play, but in my mind, a boundary relation(*) describes the polygon,
> so the administrative *area*, and the ways describe the demarcation
> between administrative areas. Thus, it's the ways that should appear on
> the rendered map, not the area.

Ok so you admit there is a problem with rendering, but instead of
fixing broken rendering software you suggest we do a lot of manual
work to over come the short falls in the software, this imho is the
wrong way to go, so my original question still stands, but you have
pointed out where I should be looking to fix the problem properly.




More information about the dev mailing list