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
