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 supplement SOTM. Cheers Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
