1ec5 left a comment (openstreetmap/openstreetmap-website#6622)
> the result sometimes gives the impression there's a duplicate object on the
> map
This is exacerbated by the identical feature type prefixes, which we’re trying
to keep consistent with the presentation of Nominatim search results. This is
more of a problem with some relation types than others. After all, most
boundaries don’t have other boundaries as members, but a `type=waterway`
relation by definition has `waterway=*` ways as members. Even in plain
language, I’d struggle to succinctly explain the difference without falling
back to raw element types.
It looks like the Overpass API response for [this particular
query](https://github.com/openstreetmap/openstreetmap-website/blob/a30c8d037e23b2ee48e0aabb9a0e555f27ef8be3/app/assets/javascripts/index/query.js#L275)
includes the full list of members of each relation. That’s overkill for the
current display, but it does enable the hierarchical display you’re proposing.
If we do choose a hierarchical display, I’d suggest inverting it. That way,
multiple members of the same relation get collated under a single relation, in
case the user queries for features near multiple members:
* Stream: Houghton Brook
* Stream: Houghton Brook
* Stream: Houghton Brook
I think the sidebar currently only has the ability to display these items in a
flat list, so we’d need to style these items slightly differently.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/6622#issuecomment-3662211669
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/issues/6622/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
