Re: [OSM-talk] Long Ways and API 0.6 - multirelations
On Mon, 09 Feb 2009 08:54:52 +0100, Frederik Ramm frede...@remote.org wrote: I don't think Dave was thinking of anything more than two different relations (partly) using the same ways. That would not warrant any special kind of relation. For situations in which you want relations contained in relations - e.g. in a situation where a nationwide cycle route comprises 5.000 ways and thus cannot be expressed in one single relation -, what I suggest is creating a number of sub relations that are members of a super relation with the same tags as the sub relation. (The super relation might have a different name tag from the sub relations, in case you want to name your sub-relations blah cycleway, southern section or so). The sub relations will not receive any extra tags saying that they are sub relations. Some hint that a super-relation exists would be helpfull here. Else it will happen that the sub-relation AND the super-relation are processed (in my case: rendered if they are tagged as type=street). I could of cause internally add such a hint automatically with a tag in a special namespace that is removed before exporting/uploading that part of the map again (so it never ends up in the main-map or an editor). Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6 - multirelations
2009/2/9 Frederik Ramm frede...@remote.org: Hi, marcus.wolsc...@googlemail.com wrote: You need the route relation so you can represent easily both a local and international route over the same ways, but it's no big deal if you have to split the 420km international route into three sections. Do you have a wiki-page that defines how these multi-relations are to look like and what the exact semantics are? My software works well with some relations but has no support for such multi-relations yet. I don't think Dave was thinking of anything more than two different relations (partly) using the same ways. That would not warrant any special kind of relation. For situations in which you want relations contained in relations - e.g. in a situation where a nationwide cycle route comprises 5.000 ways and thus cannot be expressed in one single relation -, what I suggest is creating a number of sub relations that are members of a super relation with the same tags as the sub relation. (The super relation might have a different name tag from the sub relations, in case you want to name your sub-relations blah cycleway, southern section or so). The sub relations will not receive any extra tags saying that they are sub relations. The super relation will not receive any extra tags saying that is is a super relation. The main problem there is that you lose the super relation if it's just made of sub relations. The map call won't return it, so you have to know it exists and what its ID is before you can edit it. It's not a problem for renderers or other planet processors as it'll be in there. It might be a problem for people parsing country osms depending on how your (and other) splitting tools handle it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6 - multirelations
Frederik Ramm schrieb: I don't think Dave was thinking of anything more than two different relations (partly) using the same ways. That would not warrant any special kind of relation. For situations in which you want relations contained in relations - e.g. in a situation where a nationwide cycle route comprises 5.000 ways and thus cannot be expressed in one single relation -, what I suggest is creating a number of sub relations that are members of a super relation with the same tags as the sub relation. (The super relation might have a different name tag from the sub relations, in case you want to name your sub-relations blah cycleway, southern section or so). I would solve this in a sort-of linked-list relation group. i.e. every section gets it's own relation, with the ways as members, plus the relations of the adjacent bits as additional members. (role=adjacent, perhaps) -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6 - multirelations
Hi, Dave Stubbs wrote: The main problem there is that you lose the super relation if it's just made of sub relations. You can use the relation/id/relations request to find out about the relations containing another relation, so they are not lost... It might be a problem for people parsing country osms depending on how your (and other) splitting tools handle it. ... but that's true, yes; the splitting tools would need to do a good job there. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Frederik Ramm frede...@remote.org writes: There being multiple relations for the same walking route is something that happens every day, not because of the size limit but because someone working on a local bit of the route might not be aware of someone else working on another local bit until they meet. It is actually *easier* to then combine the parts in a super relation than to move all the members from one part-relation to the other. I'm pretty sure we'll soon have good tools to work with that kind of thing. And anyway, if the super-relation is ignored and someone just sees the smaller parts of the walking route, that's not a big loss is it? What I don't like here is that this leads to duplication of data. Super-relations are fine, but IMHO tags should be moved to the super-relation. And then it would be a big loss if a renderer doesn't know how to deal with it. What is an application actually supposed to do when the tagging of of a relation contradicts the tagging of its members? For example: a super-relation with ref=E50 with a member-relation with ref=E52 which has a way tagged with ref=E58 Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, Matthias Julius wrote: What I don't like here is that this leads to duplication of data. Super-relations are fine, but IMHO tags should be moved to the super-relation. They should, but I would postpone that until later. The same is true with today's superways - tags should really be moved from the way into the relation but we can wait with that until everyone knows how to handle a superway. What is an application actually supposed to do when the tagging of of a relation contradicts the tagging of its members? For example: a super-relation with ref=E50 with a member-relation with ref=E52 which has a way tagged with ref=E58 I guess in practice this will depend on the type of relation one is talking about. With superway-type relations, the leaf objects have precedence. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Frederik Ramm frede...@remote.org writes: Hi, Matthias Julius wrote: What I don't like here is that this leads to duplication of data. Super-relations are fine, but IMHO tags should be moved to the super-relation. They should, but I would postpone that until later. Yes. I just like to bring this up once in a while to nudge people into thinking in that direction. ;-) The same is true with today's superways - tags should really be moved from the way into the relation but we can wait with that until everyone knows how to handle a superway. I'm just afraid you can wait forever here. I am not saying that people are too stupid to grasp the concept. It is more a matter of motivation to deal with the issue. I think a prerequisite is support in the main renderers. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Long Ways and API 0.6
in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm btw: now i'll try the planet :-) cheers gary68 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On Sunday 08 February 2009, Gary68 wrote: in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm Does this suggest that there will be a 1950 node limit in the 0.6 API? If yes, where's all this documented? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On Sun, Feb 8, 2009 at 1:31 PM, Gary68 g...@gary68.de wrote: in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm I did one for a big forest using a multipolygon relation. I can break the outer way to several smaller ones. Do you know if current renderes will support it or the forest will disappear in the next rendering ? Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
http://lists.openstreetmap.org/pipermail/dev/2009-February/013847.html On Sun, 2009-02-08 at 13:31 +0100, Gary68 wrote: in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm btw: now i'll try the planet :-) cheers gary68 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On 8 Feb 2009, at 12:44, Ben Laenen wrote: On Sunday 08 February 2009, Gary68 wrote: in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm Does this suggest that there will be a 1950 node limit in the 0.6 API? If yes, where's all this documented? It will be a 2000 node limit. It is now quickly documented at http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits See also the link to the dev mailing list that has been posted. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On Sunday 08 February 2009, Shaun McDonald wrote: It will be a 2000 node limit. It is now quickly documented at http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limit s OK, as long as there's no limit on the number of relation members, I'm happy :-) Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Shaun McDonald wrote: On 8 Feb 2009, at 12:44, Ben Laenen wrote: On Sunday 08 February 2009, Gary68 wrote: in europe there are 202 ways with more than 1950 nodes. complete lists can be found here: http://wiki.openstreetmap.org/wiki/SomeChecks or the europe file directly: http://www.gary68.de/osm/qa/some/len_europe.htm Does this suggest that there will be a 1950 node limit in the 0.6 API? If yes, where's all this documented? It will be a 2000 node limit. It is now quickly documented at http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits Is this a limit posed on ways only or also on relations? Because I got a note of a fellow mapper warning me that some relations have more than 2000 members. Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
In Czech republic there are many forests that does not fit into the new limit. Splitting them is not exactly easy, as most of them are multipolygons and you have to manually move inner parts between multipolygon relations in JOSM (2000+ nodes forest usually have about 20-100 inner parts). Sometimes splitting them will create and artificial boundary, though usually they can be split intelligently (like along roads or rivers...) Since the API will be set up in more than a month, maybe the long ways will get fixed, but if not, perhaps for some short time we could have the limit enforced only on new ways and on old ways we cold have temporarily a higher limit till the remaining ways get fixed. Are those few long ways a big performance problem, or could the limit be raised? Raising to at least 2500 will mean much less ways that needs fixing, as many are only slighty over the limit :) Limit on number of nodes in a way can be bypassed by splitting the polygon or way in multiple parts, but for relations it could be worse, as if there is route which is heavily fragmented due to many tunnels and bridges, thus consisting of many ways, it can exceed the limit and there is no easy workaround like splitting polygon/ways into multiple parts. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, MP wrote: In Czech republic there are many forests that does not fit into the new limit. Then you have even today created something that is very difficult for mappers to handle. The thought of downloading the history of one of these ways... shudder! Splitting them is not exactly easy, as most of them are multipolygons and you have to manually move inner parts between multipolygon relations in JOSM (2000+ nodes forest usually have about 20-100 inner parts). The advanced usage of the multipolygon relation allows you to have as many outer members as you want (see wiki page), so you can just split up your outer way and that's it. It probably isn't perfect in the renderers yet but I'm confident it will soon be. Since the API will be set up in more than a month, maybe the long ways will get fixed, but if not, perhaps for some short time we could have the limit enforced only on new ways and on old ways we cold have temporarily a higher limit till the remaining ways get fixed. The existing ways will not be touched, but you will be unable to make even the tiniest change to a way (you will not be able to change tags or add/remove nodes) if the new version of the way would have more than 2000 nodes. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On Sunday 08 February 2009, Frederik Ramm wrote: Hi, Ben Laenen wrote: OK, as long as there's no limit on the number of relation members, I'm happy :-) I'm pretty sure there will be, it is not implemented yet but I believe we said it would be 1.000. Relations with more members become very hard to work with. And why is that? We cannot just split relations. I thought it was the whole purpose of relations to have everything together. So I guess you then propose something like a super-relation. But that's not exactly user friendly: suppose I started tagging a 200 km long walking route from two opposite sides and work toward each other. So they now suddenly realize that you reached 1000 ways and haven't closed the gap in between. So now you'd have to add a new relation between those two parts to be able to finish the route? And too bad if you've reached 1000 ways in one relation and need to split a way up into two. I don't think there are any tools normal users can work with to completely reorganize relations. Furthermore, relations into relations are usually completely unsupported at all (renderers or editors). If the API really cannot work well with big relations, improve the API then. That's the whole point of having a new API, right? But adding such a limit just because the API doesn't really like it sounds like when I drive backwards with my car, the engine makes funny noises, so I fixed it by not allowing the gear handle to be put into reverse, thus eliminating all the funny noises problems. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Frederik Ramm wrote: Ben Laenen wrote: OK, as long as there's no limit on the number of relation members, I'm happy :-) I'm pretty sure there will be, it is not implemented yet but I believe we said it would be 1.000. Relations with more members become very hard to work with. So, we're going to have to make relations to group relations? Isn't that a bit... daft? I thought relations were there to make the editors able to work on ways and not have to download all ways in the relation. How would a big relation then be hard to work with? Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
In Czech republic there are many forests that does not fit into the new limit. Then you have even today created something that is very difficult for mappers to handle. The thought of downloading the history of one of these ways... shudder! Those forest were imported approximately August 2008 and it was not me who imported them. They lived in the database hapily since them, though I splitted few of them cause they were too big to comfortably handle. Splitting them is not exactly easy, as most of them are multipolygons and you have to manually move inner parts between multipolygon relations in JOSM (2000+ nodes forest usually have about 20-100 inner parts). The advanced usage of the multipolygon relation allows you to have as many outer members as you want (see wiki page), so you can just split up your outer way and that's it. It probably isn't perfect in the renderers yet but I'm confident it will soon be. Automatic multipolygon splitting, where inner parts will _automatically_ move to correct half would make this relatively easy problem to solve. Without that is is quite tedious and error-prone work (it is easy to forget about one of the many inner parts when splitting, creating sort of invalid multipolygon.). Any skilled coder nearby? The existing ways will not be touched, but you will be unable to make even the tiniest change to a way (you will not be able to change tags or add/remove nodes) if the new version of the way would have more than 2000 nodes. There is some risk they'll stay there in that state for quite long time if you won't be able to touch them. Especially those ways that are difficult to split. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
2009/2/8 Maarten Deen md...@xs4all.nl: Frederik Ramm wrote: Ben Laenen wrote: OK, as long as there's no limit on the number of relation members, I'm happy :-) I'm pretty sure there will be, it is not implemented yet but I believe we said it would be 1.000. Relations with more members become very hard to work with. So, we're going to have to make relations to group relations? Isn't that a bit... daft? I thought relations were there to make the editors able to work on ways and not have to download all ways in the relation. How would a big relation then be hard to work with? Because the API works on whole objects only. When you make a change to an object you have to upload the entire new object. When you download an object you have to download the whole object. A relation with over 1000 members is a large object which will take large amounts of bandwidth and database power to download/upload even if you're not having to download every single member as well. Hence the limit. Also every editor needs to then cope with an object with that many members -- they all do, it's just the performance and memory usage that suffers. There's very very few relation usages where we'll need groups of relations. The large area multipolygons are about the only ones I can think of. Routes can happily be split -- the primary point of relations here is to allow more than one route following the same way. It's not like we're trying to build categories or similar -- we don't need to because we can always match tags. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
And why is that? We cannot just split relations. I thought it was the whole purpose of relations to have everything together. So I guess you then propose something like a super-relation. But that's not exactly user friendly: suppose I started tagging a 200 km long walking route from two opposite sides and work toward each other. So they now suddenly realize that you reached 1000 ways and haven't closed the gap in between. So now you'd have to add a new relation between those two parts to be able to finish the route? And too bad if you've reached 1000 ways in one relation and need to split a way up into two. I don't think there are any tools normal users can work with to completely reorganize relations. Since relation can have other relation as members, maybe it can be fixed that way. In the route relation we can have next and prev members, pointing to next and previous up to 1000 ways segment of that route. Possibly most problems could be solved by that relation chaining, but I think such things should be at least proposed on wiki or perhaps pushed into map features before people start handling oversized relations by themselves, everyone in their own way. Furthermore, relations into relations are usually completely unsupported at all (renderers or editors). DTD for relations allows having another relation as a member. JOSM seems to support that, though I have not tested it thoroughly. And the relation editor in JOSM is currently very user-unfriendly. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, Ben Laenen wrote: I'm pretty sure there will be, it is not implemented yet but I believe we said it would be 1.000. Relations with more members become very hard to work with. And why is that? Because every time you make a change to an object, even if it is the tiniest change, you have to upload the whole object, and the whole object has to be copied for the history. The larger the object becomes, the more resources are used. A relation of, say, 2000 members with 5 tags uses 2006 rows in the database to store it, and the XML has 2007 lines. Every time you add or remove a member or just change the name tag marginally, you have to upload 2007 lines to the server, and another 2006 rows are used in the database. That is just something we do not want to encourage. We cannot just split relations. Sure we can. So I guess you then propose something like a super-relation. Right. Being used already for some routes in Germany although, as someone pointed out the other day, some details are still unclear. But that's not exactly user friendly: suppose I started tagging a 200 km long walking route from two opposite sides and work toward each other. So they now suddenly realize that you reached 1000 ways and haven't closed the gap in between. I'm sure Potlatch will be able to show how many members a relation already has. So now you'd have to add a new relation between those two parts to be able to finish the route? And too bad if you've reached 1000 ways in one relation and need to split a way up into two. I don't think there are any tools normal users can work with to completely reorganize relations. There being multiple relations for the same walking route is something that happens every day, not because of the size limit but because someone working on a local bit of the route might not be aware of someone else working on another local bit until they meet. It is actually *easier* to then combine the parts in a super relation than to move all the members from one part-relation to the other. I'm pretty sure we'll soon have good tools to work with that kind of thing. And anyway, if the super-relation is ignored and someone just sees the smaller parts of the walking route, that's not a big loss is it? Furthermore, relations into relations are usually completely unsupported at all (renderers or editors). No problem with JOSM, JOSM handles all kinds of relations equally bad but it is no more complicated to add a relation as a member than it is to add a away. If the API really cannot work well with big relations, improve the API then. There are people who have asked for the ability to partially edit things. We would need API calls that edit a relation without downloading or uploading the whole thing. We may get something like that in 0.7 or 0.8. Until then, we definitely must limit the number of members a relation may have or things *will* break. Even now, we have relations where the history *cannot* be downloaded because it is too large and/or takes too long to be collected, and even if it could be downloaded, it is would be an XML file of several hundred MB. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, MP wrote: The advanced usage of the multipolygon relation allows you to have as many outer members as you want (see wiki page), so you can just split up your outer way and that's it. It probably isn't perfect in the renderers yet but I'm confident it will soon be. Automatic multipolygon splitting, where inner parts will _automatically_ move to correct half would make this relatively easy problem to solve. You misread me. You simply take the existing outer way, split it into 5 little bits, make sure they are all member of the relation, and that's it. No need to move inner polygons to the correct half because there is no half. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, Dave Stubbs wrote: A relation with over 1000 members is a large object which will take large amounts of bandwidth and database power to download/upload even if you're not having to download every single member as well. Hence the limit. D'oh, should have read that before writing the same ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
On 8 Feb 2009, at 20:08, MP wrote: Routes can happily be split -- the primary point of relations here is to allow more than one route following the same way. It's not like we're trying to build categories or similar -- we don't need to because we can always match tags. Not always - there can be more routes on one road for example one international route plus perhaps a bicycle route, marked trail or route of some bus line. There is for example international bicycle route from Prague to Vienna (about 420km), most of it is on local routes of even some forest trails, often switching roads and therefore having lot of relation members. Many parts of it will be shared with another bicycle routes so you can't just forget relation and match tags. 1000 relation members will be enough for most uses but what about the few that are larger? This is a great example of where you can have multiple relations, each of which have the same tags, with the possibility of having a relation to link all these relations together. I know RichardF isn't going to agree. If the editors had a way to search for similar relations, then it would make it easier. Data users need to do the same, as is currently done for road names and refs in the rendering. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
2009/2/8 MP singular...@gmail.com: Routes can happily be split -- the primary point of relations here is to allow more than one route following the same way. It's not like we're trying to build categories or similar -- we don't need to because we can always match tags. Not always - there can be more routes on one road for example one international route plus perhaps a bicycle route, marked trail or route of some bus line. There is for example international bicycle route from Prague to Vienna (about 420km), most of it is on local routes of even some forest trails, often switching roads and therefore having lot of relation members. Many parts of it will be shared with another bicycle routes so you can't just forget relation and match tags. Umm.. yes. You've managed to get the complete wrong end of the stick :-) I was saying that's what relations are there for. You need the route relation so you can represent easily both a local and international route over the same ways, but it's no big deal if you have to split the 420km international route into three sections. Dave Dave 1000 relation members will be enough for most uses but what about the few that are larger? Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
2009/2/9 Frederik Ramm frede...@remote.org Hi, MP wrote: The advanced usage of the multipolygon relation allows you to have as many outer members as you want (see wiki page), so you can just split up your outer way and that's it. It probably isn't perfect in the renderers yet but I'm confident it will soon be. Automatic multipolygon splitting, where inner parts will _automatically_ move to correct half would make this relatively easy problem to solve. You misread me. You simply take the existing outer way, split it into 5 little bits, make sure they are all member of the relation, and that's it. No need to move inner polygons to the correct half because there is no half. IIRC, just splitting the ways in JOSM would result in the smaller ways all being members of the relation as the same object type as the original larger way by default... So, split the outer into two in JOSM and you automagically have two outer ways in the same relation... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6
Hi, D Tucny wrote: IIRC, just splitting the ways in JOSM would result in the smaller ways all being members of the relation as the same object type as the original larger way by default... So, split the outer into two in JOSM and you automagically have two outer ways in the same relation... Exactly that is the desired outcome: http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Advanced_multipolygons Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6 - multirelations
On Sun, 8 Feb 2009 22:24:47 +, Dave Stubbs osm.l...@randomjunk.co.uk wrote: Umm.. yes. You've managed to get the complete wrong end of the stick :-) I was saying that's what relations are there for. You need the route relation so you can represent easily both a local and international route over the same ways, but it's no big deal if you have to split the 420km international route into three sections. Do you have a wiki-page that defines how these multi-relations are to look like and what the exact semantics are? My software works well with some relations but has no support for such multi-relations yet. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Long Ways and API 0.6 - multirelations
Hi, marcus.wolsc...@googlemail.com wrote: You need the route relation so you can represent easily both a local and international route over the same ways, but it's no big deal if you have to split the 420km international route into three sections. Do you have a wiki-page that defines how these multi-relations are to look like and what the exact semantics are? My software works well with some relations but has no support for such multi-relations yet. I don't think Dave was thinking of anything more than two different relations (partly) using the same ways. That would not warrant any special kind of relation. For situations in which you want relations contained in relations - e.g. in a situation where a nationwide cycle route comprises 5.000 ways and thus cannot be expressed in one single relation -, what I suggest is creating a number of sub relations that are members of a super relation with the same tags as the sub relation. (The super relation might have a different name tag from the sub relations, in case you want to name your sub-relations blah cycleway, southern section or so). The sub relations will not receive any extra tags saying that they are sub relations. The super relation will not receive any extra tags saying that is is a super relation. At some point in the future we might think about removing tags from the sub relations and assuming some kind of tag inheritance but I'd not like to over-specify that today. For processing, I suggest that wherever a relation contains another relation and there is no special-case coding, the system should act as if all members of the sub relation were actually direct members of the super relation. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
