[postgis-devel] Empty for Discussion

[Paul Ramsey]

> On Feb 10, 2023, at 6:23 PM, Regina Obe <lr at pcorp.us> wrote:
> 
> Oh something did change, I missed that Martin, was getting POINT EMPTY on 
> 
> ST_GeometryN(..,1) 
> 
> In PostGIS 3.1
> 
> Yes I see now on my PostGIS 3.1 -  SELECT ST_AsText(ST_GeometryN('GEOMETRYCOLLECTION(POINT EMPTY, POINT EMPTY)'::geometry, 1));
> 
> I do get a POINT EMPTY,
> 
> But in my latest dev compile, get NULL back.  It's possible this behavior change was to handle empty geom crashers.
> 
> I should add, I had changed here -- https://trac.osgeo.org/postgis/ticket/5240
> 
> All the dumps to just ignore empty geometries.  It was easier than trying to get them to output a geometry for empties.
> 
> So I'd rather standardize on 0 for an answer and that ST_GeometryN should just return NULL.
> 
> I think the only concern there, is what should one expect with:
> 
> SELECT ST_AsText(ST_GeometryN('GEOMETRYCOLLECTION(POINT EMPTY, POINT(1 2))'::geometry, 1));
> SELECT ST_AsText(ST_GeometryN('GEOMETRYCOLLECTION(POINT EMPTY, POINT(1 2))'::geometry, 2));
> SELECT ST_NumGeometries('GEOMETRYCOLLECTION(POINT EMPTY, POINT(1 2))'::geometry);
> 
> In both my 3.1 install and dev branch, I get back an answer of: 
> 
> Position 1: POINT EMPTY
> Position 2: POINT(1 2)
> NumGeometries:  2

Well, yeah, it's not consistent... in the case of empty components we fold the thing down to zero (notionally) but in other cases we let the component empty hand around and count it as real. I'm not sure being more consistent HELPS us or anyone at all, but I'm pretty sure that NumGeometries(GEOMETRYCOLLEcTION(POINT EMPTY, POINT EMPTY) is WRONG, at least to the angels dancing on the head of a pin.

P

> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Regina Obe [mailto:lr at pcorp.us]
>> Sent: Friday, February 10, 2023 7:39 PM
>> To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
>> Subject: RE: [postgis-devel] Empty for Discussion
>> 
>>>> Agree in the sense, that yes if number of geometries is 0, then I
>>>> expect
>>> ST_GeometryN of anything to give me NULL back.  It has also been like
>>> that for quite some time so all supported versions I assume agree (I didn’t
>> check 3.0).
>>>> 
>>> 
>>> Right, but we're talking about GEOMETRYCOLLECTION(POINT EMPTY, POINT
>>> EMPTY) here, which has... 2 geometries in the collection.
>> 
>> Yes the answer 2 is more right than 0 I suppose, but I don't think 0 is
>> necessarily wrong either.
>> 
>> If I collect all the candy bags from some kids and combine them and dump out
>> all of the candy?  How much candy do I dump out if no one went trick-o-
>> treating = 0.
>> 
>> As an accountant once send to me, as long as the answers all agree, that's the
>> most important thing.
>> ST_Dump, ST_DumpPoints, ST_GeometryN, ST_NumGeometries all agree, if
>> you ask for nothing, you don't get something back.
>> 
>> Should we change it, I say not worth the trouble unless there is a major issue
>> you are seeing that is resulting.
>> 
>> I'm more concerned about people relying on:
>> 
>> ST_NumGeometries(GEOMETRYCOLLECTION EMPTY ) =
>> ST_NumGeometries(GEOMETRYCOLLECTION(POINT EMPTY, POINT EMPTY)
>> Having the same number of elements
>> 
>> And that
>> 
>> ST_DumpPoints and ST_Dump of empty geometries result in nothing being
>> dumped.
>> 
>> Fixing this will break their workflow.
>> 
>> Thanks,
>> Regina
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel