Modify

Opened 9 years ago

Last modified 2 months ago

#4142 new defect

JOSM does not query API for referring relations when downloading primitives

Reported by: Nakor Owned by: team
Priority: critical Milestone:
Component: Core Version: latest
Keywords: Cc:

Description (last modified by simon04)

Download data using the following bounding box: http://www.openstreetmap.org/?lat=42.65924&lon=-83.3199&zoom=17

Download all members from the relation

Search for way 43418202. It is shown only as a member of relation 308,352 but if it is also member of another relation (see http://www.openstreetmap.org/browse/way/43418202).

This would cause inconsistencies if the way is split.

Attachments (0)

Change History (13)

comment:1 Changed 9 years ago by mjulius

Summary: Incomplete data when downloading all memebers of a relationJOSM does not query API for referring relations when downloading primitives

When downloading primitives from the API (with multi get) the API does not return relations the primitive is member of. There is a special API call for that:

GET /api/0.6/[node|way|relation]/#id/relations

(see http://wiki.openstreetmap.org/wiki/API_v0.6#Relations_for_Element:_GET_.2Fapi.2F0.6.2F.5Bnode.7Cway.7Crelation.5D.2F.23id.2Frelations)

JOSM needs to iterate over all downloaded primitives and check whether they are members of any relation.

Better would be if the API provided a call like

GET /api/0.6/[nodes|ways|relations]/#ids/complete

that returns the same kind of data like the map call.

comment:2 Changed 8 years ago by bastiK

Ticket #4405 has been marked as a duplicate of this ticket.

comment:4 Changed 8 years ago by Nakor

Ticket #4734 has been marked as a duplicate of this ticket.

comment:5 Changed 8 years ago by stoecker

Ticket #5086 has been marked as a duplicate of this ticket.

comment:6 Changed 8 years ago by stoecker

Priority: majorcritical

comment:7 Changed 6 years ago by simon04

Description: modified (diff)

Any update on this critically prioritized ticket?

comment:8 Changed 6 years ago by skyper

Maybe a warning with an option to download parents before splitting could help as these ways are outside of the download area.

comment:9 Changed 4 years ago by verdy_p

Learn CTRL+ALT+D before splitting or merging nodes !
Or place the icon for the "Download referers" tool just beside the two icons on the toolbar for merging or splitting ways (use the preferences panel to add it to your toolbar).
This "Download referers" tool should be on the status bar by default !

comment:10 Changed 4 years ago by verdy_p

Note: not just referers of ways, but also referers of nodes should be downloaded to avoid conflicts.

But more critically, referers of relations can also include other relations, and this could recurse at deep levels;

  • However siblings found as members of referer relations do not need to be downloaded: only the fact that they are members of a known relation is enough. These members will also be known with a role in the referer relation, though the role is not strictly needed, we just need the member ID and type (node/way/relation).
  • Recursion will only occur if the referer relation is not alread loaded (at least partially). There should be an API that can recurse over parent relations but loading them with only their IDs (we know theu can only be relations). These relations would be loaded in "incomplete" state, without any of its tags and with partial lists of members with unknown roles (and in the partial list of members, not all of them would be loaded).

This would speed up the download, and would also save memory... provided that JOSM can accept such object state for relations. That "incomplete" relation is NOT locally modifiable (not even just to set new tags) as long as it has not been correctly loaded with its tags and the fll ist of members (but not necessarily their roles). We would continue to use "donwload incomplete" to completely load tags of the relation, compeltely load roles of existing members (with current "<unknown>" role, and get the full list of members as references (but not necessarily their own data, i.e. their own tags or geometry or submembers).

comment:11 Changed 17 months ago by verdyp@…

Note that frequently, the server cannot return all dependencies for some objects, notably when selecting ways that are part of several/many large relations:

The query fails (visible on the console with an HTTP error status), even when retrying it. Apparently the server has limited ressources for doing it.

It is probably not a bug of JOSM, but of the server trying to perform too costly requests (trying to build some costly temporary index for joining results: incorrect execution plan, or existing index estimated to be insufficiently selective). But...

Workaround: select a node one that way, zoom on it to view a very small area around it (to avoid loading too many unnecessary surrounding objects), and then load the tiny area around this node : it works instantly !

For doing the same thing on relations, you need to recurse down to get at least one node (this may require loading members if the relation is incomplete), and then use that node to perform the download by area.

Suggestion: possibly, JOSM could detect that failure and retry by downloading automatically with a query by area, using such tiny rectangle (it can be as small as a few centimeters around that node).

comment:12 Changed 2 months ago by anonymous

This or a variant of it (such as for when an Overpass API query only downloads certain objects and not all objects in an area, but it should to avoid editing conflicts when that object is later uploaded) may now be possible as of Overpass API 0.7.55:

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#The_block_statement_complete

It should probably be used both when downloading objects in a bounding box (by default), and at least be allowed as a user-selectable option when downloading objects through Overpass API (e.g. '[x] Also download object dependencies', enabled by default (See https://wiki.openstreetmap.org/wiki/Overpass_API/Sparse_Editing for the use case of that).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to Nakor
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.