api call to get the relations for a list of elements

[openstreetmap-trac]

Reporter: sebastiank
[Submitted to the original trac issue database at 9.29pm, Friday, 22nd January 2010]

In JOSM we always need to know all relations an object is in. (1)

For a normal map?bbox= request, this is fulfilled. However for a relation, we don't get all members (which is a good thing). So the incomplete members need to be downloaded separately, if the user requests it. For this we use the API calls relation/#id/full (to download all members) and ways?ways= (similar for nodes, relations; to download only the missing members).

Then the precondition fails and some of these objects might be in a relation, but the editor doesn't know that.

In principle one could request

[node|way|relation]/#id/relations

for each primitive that was retrieved by the ways or full call. But usually one deals with hundreds or even thousands of objects (that may be all member of large relations), so this produces way too much traffic.

It would be nice to have an API call to

• download all members of a relation as well as all relations, these members are in;

• download a list of nodes/ways/relations as well as all relations, these objects are in.

A little difficulty here: It should return only a list of the relation ids or otherwise it would produce a lot of unnecessary traffic, again.

(1) Some example: A boundary way can be in multiple boundary relations. When splitting the way, all parts need to be added as members of these relations. When editing boundaries, it is often necessary to download missing members, so it is easy to run into this trap.

[openstreetmap-trac]

Author: sebastiank
[Added to the original trac issue at 5.00pm, Monday, 25th January 2010]

There is a very similar problems for nodes: You never know if it is used by another way unless it is within a downloaded bounding box. However, when editing large objects (e.g. boundaries) in dense regions, you cannot download the entire area. Even opening a planet extract in JOSM can fail because the file is too large.

So it would help if the editor could keep track of all parent ways for a node. To download everything recursively is of course stupid as it would download the road network of the entire continent.

So the way out could be to have the 'id' of the parent way, but not the full way data. Then JOSM could show a warning, if the user tries to delete that node.

To sum it up: Always having the parent way/relation ids of each object would ease advanced editing in JOSM and avoid annoying errors. This would require new or extended API calls.