[geos-devel] GEOS C API for Polygonal Coverage operations?

[Brendan Ward]

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.

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).

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.

For opaque collections / geometry arrays, I could see setting and getting
userdata to the workflow:

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

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.

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.

So it would look something like:
array of polygons => make coverage => ... coverage operations... =>
getCoveragePolygon(coverage*, index) => polygon

or

array of polygons => make coverage => ... coverage operations... => sort on
original index (internal) => array of polygons

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.


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.


On Wed, Sep 7, 2022 at 9:15 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
>
> > On Sep 7, 2022, at 9:12 AM, Brendan Ward <bcward at astutespruce.com>
> wrote:
> >
> >  Having final outputs (e.g., coverage => polygons) relate 1:1 to the
> input polygons so we can re-attach associated data will be essential
>
> I wonder if having the userData survive the trip from
> polygon->coverage->polygon would be sufficient?
>
> P
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>


-- 
Brendan C. Ward
Owner | Lead Software Engineer
Astute Spruce, LLC
astutespruce.com
541-250-9544
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220907/1a43d06d/attachment-0001.htm>