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

[Martin Davis]

Actually I have been developing using the pattern that the output list is
1:1 with the input list, with null representing outputs which are not
present for some reason.  Reasons for this are:

- works well with the "list of polygons" representation
- avoids any issues with creating/freeing userData objects
- makes it easy to associate results back to inputs

Not sure if this pattern will work if the Coverage datatype design is used
(especially through chained operations on coverages).  Perhaps Coverage
Faces will have to maintain the input polygon ID (index) through
operations, and then the 1:1 output array could be reconstituted as
required.

On Wed, Sep 7, 2022 at 9:18 AM Daniel Baston <dbaston at gmail.com> wrote:

> I think this is a good way to do it. In precision-reduction operation I
> can imagine that some input polygons would disappear; maintaining a 1:1
> correspondence would require including NULLs in the output, which seems
> unwieldy.
>
> Dan
>
> On Wed, Sep 7, 2022 at 12:15 PM 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
>>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220907/0465775a/attachment.htm>