<div dir="ltr">In theory, it possibly could.  On the Python side (shapely / pygeos) we don't currently use userdata attached to geometries (nor get/set SRID for that matter).  But it should be easy to add those for specific cases like this, and that doesn't mean we need to add them into our public API.<div><br></div><div>There hasn't previously been a case where we pass in an opaque collection of geometries with attributes attached to individual geometries; instead the geometry operations are either 1:1 or 1:many (in case of splitting a collection into parts).</div><div><br></div><div>For cases where we need to track back to individual geometries (e.g., geometries added to STRtree) the item data we use when inserting to the tree is an address of the geometries within an array that we manage (since we had to store the array of geometries anyway), and we use pointer addresses to derive indexes into the original array.  Originally we were using a loop counter, but because that gets passed in as a void * and we are supposed to persist the actual thing on our end, we were getting segfaults sometimes.  Our API for STRtree heavily revolves around indexes into the geometries added to the tree.</div><div><br></div><div>For opaque collections / geometry arrays, I could see setting and getting userdata to the workflow:</div><div><br></div><div>array of polygons => set user data on each => make coverage (validate & clean) => ... coverage operations... => array of polygons => get user data and relate back to inputs</div><div><br></div><div>However, with userdata as a void*, that means we'd have to create something that owns those values in an array on our end before passing pointers to them (we'd likely store an array of indexes), which is a little bit of overhead (though minor in the grand scheme of things).  The benefit of that approach is that the polygons could be output from the coverage in any order and we'd still be able to relate them back.  </div><div><br></div><div>Likewise, internally within GEOS the elements of the coverage could store an integer with their original index into the input array, and that could be used to retrieve elements of the coverage to polygons like we do now with getting geometries from a geometry collection.  </div><div><br></div><div>So it would look something like:</div><div>array of polygons => make coverage => ... coverage operations... => getCoveragePolygon(coverage*, index) => polygon</div><div><br></div><div>or </div><div><br></div><div>array of polygons => make coverage => ... coverage operations... => sort on original index (internal) => array of polygons<br></div><div><br></div><div>Presumably any polygons in the coverage that are simplified out during processing would be emitted as empty polygons?  If so, the count of polygons input and count of polygons output should be the same.  In either case above, elements of the coverage could be reordered as needed internally, and just sorted back to the original order before outputting back to polygons.</div><div><br></div><div><br></div><div>In my limited worldview, index into the original array is all we'd need to relate back to other things.  I don't see wanting to store other custom data via user data (e.g., a struct or some other more complex value), but perhaps there are other users of the C API that would need that complexity.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 7, 2022 at 9:15 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</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>
<br>
> On Sep 7, 2022, at 9:12 AM, Brendan Ward <<a href="mailto:bcward@astutespruce.com" target="_blank">bcward@astutespruce.com</a>> wrote:<br>
> <br>
>  Having final outputs (e.g., coverage => polygons) relate 1:1 to the input polygons so we can re-attach associated data will be essential<br>
<br>
I wonder if having the userData survive the trip from polygon->coverage->polygon would be sufficient?<br>
<br>
P<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font size="4">Brendan C. Ward</font><div><font color="#666666">Owner | Lead Software Engineer</font><br><div>Astute Spruce, LLC</div></div><div><a href="https://astutespruce.com/" target="_blank">astutespruce.com</a><br></div><div>541-250-9544</div></div></div></div></div></div></div>