Folks,
I've been lazy. I remember I had promised to report from the SOTM
relations workshop but haven't done so yet.
There was a lot of interest (about 20 people in the room I guess). Some
didn't even know what a relation was, others dared to point out my own
mistakes ;-)
Unfortunately we didn't get to talk a lot about where we want to go -
what relations we want to use more and for what and how - but at least
we slayed a few beasts.
I started with a small overview of relation types we currently have and
how many there are in the planet. At the time, we had 14k relations
altogether; the most used relation types are multipolygons (5k) and
routes (4k). The next most used was a "street" relation type (1.5k, used
in a superway sense), plus 1k type-less relations stemming from some
kind of import. Then roughly 500 restrictions, 500 dual carriageways,
and 300 boundaries.
Multipolygons
-
Multipolygons have a special role because they don't conceptually belong
on the same layer as other relations; they are used as a workaround for
not having a basic area data type. It is not unlikely that they will,
one day, be replaced by a basic area data type but until then we use
multipolygon relations to model areas with holes.
(Areas without holes can be modeled by one single closed way.)
There were some misconceptions about how multipolygon relations should
be used. Multipolygon relations have one "outer" way and 1-n "inner"
ways. We noted down and agreed on the following:
* tags describing the area (e.g. natural=forest) should go on the outer
way or on the relation itself.
* the inner ways should *not* be tagged...
* ...unless they represent something themselves (e.g. a lake in the
forest) in which case they're tagged as whatever they are (natural=water)
* areas should not be segmented (i.e. if you have a big forest, don't
split it into parts that share a common boundary)
* the direction of the outer/inner ways does *not* matter
* if you have a hole in a forest or something else, don't put a
"landuse=land, layer=1" area on top of it ;-)
The "no segmentation" rule is important because there are renderers
already which use different colours for an area boundary than for the
area itself, and such segments will then show up on the maps.
Unsolved problem: How can we create really large areas without having to
have a 10,000 node "outer" way. Should be possible with relations - e.g.
multipolygon with >1 "outer" members that connect - but unsure.
Routes
--
Routes are most prominently used for cycle routes which are rendered on
Andy Allan's cyclemap. Generally ways which are part of a route don't
have a role, they're just part of it. But sometimes you have ways in the
roles "forward" and "backward", and I had thought that these refer to
different routings used by, say, a bus at it goes in one direction and
back again. Turns out that the "forward" and "backward" are only meant
clarify how the route goes by saying "you have to turn this way around
to match up with the direction of the others", and can often be ignored.
There's a lot of unclear points about questions like how to model a bus
stop that is part of a route. People currently put a node into the
relation and often give it a role like "forward_stop_5" to say that this
is the 5th stop going forward. This is a bit ugly but currently
necessary because the API does not guarantee ordering of relation
members, i.e. if you stuff in a number of nodes there's no guarantee
that they come back in the same sequence.
It is not currently possible to model a route that uses the same way
twice because relations may not contain the same object multiple times;
this might have to be changed some time in the future.
Peter Miller suggested we study the "transmodel" structure for bus
routes etc. and might copy a few good ideas from them regarding public
transport.
It was widely agreed that we have a problem because the Wiki has a lot
of information pre-dating the introduction of relations, and also some
that is post-relations but also completely outdated. Grant Slater
volunteered (I think ;-) to at least help remove API 0.4 stuff from the
Wiki, but it will probably remain a problem that the Wiki is largely
maintained (with best intentions and a lot of effort!) by people who
don't actually work with the data and who, because of that lack of
exposure, sometimes are not bold enough in throwing out the irrelevant
stuff.
I think there is a lot of work to be done until we can use the full
potential of relations. Not in the API or data model, but in editors,
renderers, and most importantly in agreeing how to best do certain
things. I believe that, had we had two days instead of two hours, we
could have produced significant advances. I hope that there will be a
chance to continue this work in some way, either by forming some kind of
informal "relation working group" or by having a proper developer
meeting to