[OSM-talk] Long Ways and API 0.6

Frederik Ramm 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.

> 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.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the talk mailing list