[OSM-talk] Long Ways and API 0.6
frederik at remote.org
Sun Feb 8 21:56:47 GMT 2009
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.
> 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
> 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
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.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the talk