[Tagging] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

As time goes on, we will encounter increasingly accurate and resolute
mechanisms for surveying things like coastlines and land cover.  For
example, there are discussions about whether to use things like AI and
machine learning to produce such data.  The demand for ways to deal with
larger objects will only grow in the future

Therefore, a holistic solution is needed for large objects.  Setting an api
limit is good because it gives consumers a guarantee about the worst-case
object they might have to handle.  However, it must also be combined with a
replacement mechanism for representing large objects.  The 2,000 node limit
for a way is fine because longer ways can be combined via relations.  If
the relation member limit were capped, you create a class of objects that
cannot be represented in the data set.

What I think is missing is a way to store huge multipolygons in such a way
that they can be worked with in a piecemeal way.  The answer that
immediately comes to mind is a scheme where large objects are represented
as relations of relations, where portions of a huge multipolygon are
chopped up into fragments and stored in subordinate multipolygon
relations.  This hierarchy could perhaps nest several levels if needed.
Now a 40,000 member relation could be composed of 200 relations of 200
members each, with each subordinate relation member being a valid
multipolygon with disjoint or adjacent portions of the overall geometry.

Then, an editor could say "here is a large relation, I've drawn bounding
boxes for the 200 sub-relations, if you select one, I'll load its data and
you can edit just that sub-relation".

This could *almost* work under the current relation scheme (provided new
relation types are invented to cover these types of data structures, and
consumers roger up to supporting such hierarchical relations).  The thing
that makes this fail for interactive data consumers (such as an editor or a
display) is that *there's no way to know where relation members are,
spatially, within the relation*.  The api does not have a way to say "what
is the bounding box of this object?"  A consumer would need to traverse
down through the hierarchy to compute the inner bounding boxes, which
defeats the purpose of subdividing it in the first place.


On Sun, Nov 22, 2020 at 1:44 PM Simon Poole <simon at poole.ch> wrote:

>
> Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:
> > ..
> >
> > I like the idea of an api limit, though we would need a strategy to
> > deal with existing large objects.
> > ..
>
> This is, "surprise", not a new topic. There are certain issues with the
> semantics of relations which make this slightly more involved as the
> maximum node limit on ways.
>
> See
>
> - https://github.com/openstreetmap/openstreetmap-website/issues/1711
>
> - https://github.com/zerebubuth/openstreetmap-cgimap/pull/174
>
> With the later giving some insights in to why simply declaring a limit
> is not a good idea. But putting a bound in place and expecting all tools
> to be handle relations up to that size (just as we currently do with
> ways) would be a good thing to improve robustness of the whole system.
>
> Simon
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201122/c8f13610/attachment-0001.htm>