<div dir="ltr">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<br><div></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div><div>This could <i>almost</i> 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 <i>there's no way to know where relation members are, spatially, within the relation</i>.  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.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 22, 2020 at 1:44 PM Simon Poole <<a href="mailto:simon@poole.ch">simon@poole.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:<br>
> ..<br>
><br>
> I like the idea of an api limit, though we would need a strategy to <br>
> deal with existing large objects.<br>
> ..<br>
<br>
This is, "surprise", not a new topic. There are certain issues with the <br>
semantics of relations which make this slightly more involved as the <br>
maximum node limit on ways.<br>
<br>
See<br>
<br>
- <a href="https://github.com/openstreetmap/openstreetmap-website/issues/1711" rel="noreferrer" target="_blank">https://github.com/openstreetmap/openstreetmap-website/issues/1711</a><br>
<br>
- <a href="https://github.com/zerebubuth/openstreetmap-cgimap/pull/174" rel="noreferrer" target="_blank">https://github.com/zerebubuth/openstreetmap-cgimap/pull/174</a><br>
<br>
With the later giving some insights in to why simply declaring a limit <br>
is not a good idea. But putting a bound in place and expecting all tools <br>
to be handle relations up to that size (just as we currently do with <br>
ways) would be a good thing to improve robustness of the whole system.<br>
<br>
Simon<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>