[openstreetmap/openstreetmap-website] Allow option to view child relations via parent (#2772)

[Minh Nguyễn]

1ec5 left a comment (openstreetmap/openstreetmap-website#2772)

> I think what may be happening is that the API response include the relation you asked for, and the ways and relations that are part of it (there is certainly more that one relation in the response) but not the ways which are members of the child relations and hence you effectively don't see the child relation.

The /full response for [this route superrelation](https://www.openstreetmap.org/relation/9973398) includes each member relation and its member relations (which happen to be ways). In turn, that relation belongs to [this route superduperrelation](https://www.openstreetmap.org/relation/11486089), whose /full response recurses three levels down to the ways. Neither response includes any way’s nodes. We’d need the nodes to reconstruct a geometry for display.

https://github.com/openstreetmap/openstreetmap-website/blob/3e447d802ccb269dc468340c54f6c5268f7d4ebf/app/controllers/api/relations_controller.rb#L41-L64

> I would discourage unconstrained relation resolution for the API, in particular for use cases like the one mentioned here. Looking at relation 60189 (Russia) with all its nested multi level subareas, this would quickly produce 584MB worth of data. That's a pretty good way to kill your browser.

Any fix for this issue would definitely need to exclude `subarea` members. Even if the API response includes them, the client-side conversion code would need to ignore them anyways, since the user wouldn’t be expecting the map to highlight subareas.

Even if we could eliminate the `subarea` tagging convention from OSM (pretty please), mappers have gone overboard with other elaborate relation structures, such as [all the numbered roads in South Korea](https://www.openstreetmap.org/relation/6818098). At the same time, there are definitely superrelations that would benefit greatly from a map visualization. (This is especially true in OpenHistoricalMap: OpenHistoricalMap/issues#601.) Unless we have a way to gauge the overall data size ahead of time, it should only be available on demand, after the user explicitly asks for it by clicking a button or something.

> If the route cannot be displayed, the interface **actually says so**; a list of the components of the superroute could for instance be stated as a list, which means the user at least gets some sense of what to do next.

I think this is the biggest pain point for both this issue and #3841. A disclaimer could appear on the map, noting that we’ve loaded the current element and some or all of its members are undownloaded ways.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/2772#issuecomment-3757114161
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/2772/3757114161 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260115/1d9f0608/attachment.htm>