[geos-devel] Ownership of userData

Martin Davis mtnclimb at gmail.com
Tue Jan 29 17:06:06 PST 2019


FWIW I sympathize with the problem.  This actually felt like a bit of a
hack when I implemented it, but since it's not much of an issue in
Java-land I ploughed ahead.

Isn't there *always* going to be an ownship problem for anything returned?
The user knows they own any returned geometry, which is why that seems ok.
If they want extra information they are going to have to own that as well.
It's just that GEOS-created userData is a bit unexpected (only in this one
place AFAIK).

Maybe the coordinates could be kept in another list, and only handed off to
the user if they ask for them?  The fully geometric way of doing this would
be to return a MultiPoint with the points in the same order as the
polygons.  (SIgh... would be nice if MultiPoints had a more compact
structure).

On Tue, Jan 29, 2019 at 10:24 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> I am going through the various tickets and PRs and trying to clean
> them up. This one seemed straightforward at first, but the issue of
> ownership of userData is pretty ugly in GEOS land.
>
> https://github.com/libgeos/geos/pull/115#issuecomment-458649362
>
> Basically we seem to currently assume that whomever assigned userData
> will clean up said userData. But in the case of this ticket, the GEOS
> engine itself is assigning it. I think we just cannot do that. It's
> not userData any more, it's geosData, and users cannot be expected to
> clean it up.
>
> We could further enhance geometry to also have geosData, maybe
> something like a python dictionary of extra "stuff" that can be added
> to geometry optionally, but in the short term I'd rather just not
> follow the contract of including the cell coordinates in the returned
> voronoi polygons.
>
> P
> _______________________________________________
> 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/20190129/1dd3d654/attachment.html>


More information about the geos-devel mailing list