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/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
