ST_AsGML and ST_AsKML crashes on POLYGON EMPTY or acts really bizarre

[robe]

Crash

SELECT ST_AsGML(ST_GeomFromText('POLYGON EMPTY',4326)) As result

-- though this works okay --

{{{SELECT ST_AsGML(ST_GeomFromText('GEOMETRYCOLLECTION EMPTY',4326)) As result; }}}

yields which is same answer as 1.5: <gml:MultiGeometry srsName="EPSG:4326"></gml:MultiGeometry>

-- and this works okay --

SELECT ST_AsGML(ST_GeomFromText('POINT EMPTY',4326)) As result;

yields below which is not the same answer as 1.5, but I assume that is a planned change. <gml:MultiPoint srsName="EPSG:4326"></gml:MultiPoint>

[robe]

Add to list same issue with ST_AsKML

[robe]

Add to list ST_Buffer, though seems to handle other permutations of Emptiness (but I don't have in my test to check MULTI emptiness or MULTI M etc. though spot check seems fine on those. I'll add later these)

-- crash

SELECT ST_Buffer(ST_GeomFromText('POLYGON EMPTY',4326), 0.5) As result

[pramsey]

Regina, could you open separate tickets for separate functions?

[pramsey]

I have fixed the crash for GML2 Polygon at r6300, but every other new empty variant now also needs to be done. I'm reassigning this to Olivier since he known GML better (and maybe he'll feel like updating that GML / KML output to a stringbuffer now?)

[robe]

I was wrong your most recent change does fix the ST_AsKML issue. However a small little problem still exists.

SELECT ST_AsKML(ST_GeomFromText('POLYGON EMPTY'))

Gives the message:

ERROR: Input geometry has unknown (-1) SRID

I thought our new UNKNOWN is 0 no or has this constant not been flipped yet?

[pramsey]

In order to move in the new parsers I needed an unknown srid and there are -1 values all over the place still, so I set the SRID_UNKNOWN macro to -1 for now and am cleaning the hardcode values as I find them. When I feel like hurting myself a little I'll flip SRID_UNKNOWN to 0 and see what breaks.

[pramsey]

The problem still exists in AsGML. I only re-wrote AsKML.

SELECT ST_AsGML(ST_GeomFromText('POLYGON EMPTY',4326)) As result;

[robe]

Well I'm looking at a day old build at the moment and its not crashing for ST_AsGML,and you note above states you fixed for gml and not kml. but I'm seeing dirty output.

SELECT ST_AsGML(ST_GeomFromText('POLYGON EMPTY',4326)) As result;

First call: <gml:Polygon srsName="EPSG:4326"></gml:Polygon>

Second call: <gml:Polygon srsName="EPSG:4326"¯@

Third call: <gml:Polygon srsName="EPSG:4326"`¹@

So the outputs each time are giving me a different answer subsequent ones have junk.

I'm also wondering why we are having so many problems with POLYGON EMPTY, the other empty variants I've been spot checking with the crashing functions don't crash.

For example:

SELECT ST_AsGML(ST_GeomFromText('MULTIPOLYGON EMPTY',4326)) As result;

Consisently returns: <gml:MultiPolygon srsName="EPSG:4326"></gml:MultiPolygon>

SELECT ST_AsKML(ST_GeomFromText('MULTIPOLYGON EMPTY',4326)) As result; consistently returns: <MultiGeometry></MultiGeometry>

[robe]

Okay -- now you have managed to make ST_AsKML on geography crash:

This crashes:

SELECT ST_AsKML(geography(ST_GeomFromText('POLYGON EMPTY',4326))) ;

This returns NULL is that intentional?

SELECT ST_AsKML(ST_GeomFromText('POLYGON EMPTY',4326)) ;

ST_AsGML is still returning mysterious goo when inflicted with POLYGON EMPTY.

SELECT ST_AsGML(geography(ST_GeomFromText('POLYGON EMPTY',4326))) ;

The geography ST_AsGML on first call returns

lwgeom_free called with unknown type (111) Invalid type

and on subsequent calls returns mysterious goo.

I feel like my database is haunted :).

Though interestingly enough MULTIPOLYGON EMPTY is fine. What's so special about POLYGON EMPTY?

[robe]

to add to this - ST_AsKML geography variant appears to crash for ALL variants of EMPTY. Including our beloved GEOMETRYCOLLECTION EMPTY.

SELECT ST_AsKML(geography(ST_GeomFromText('GEOMETRYCOLLECTION EMPTY',4326)));

and the geometry empty variants is returning NULL:

SELECT ST_AsKML(foo1.the_geom) is null
FROM ((SELECT ST_GeomFromText('POINT EMPTY',4326) As the_geom
	UNION ALL SELECT ST_GeomFromText('MULTIPOINT EMPTY',4326) As the_geom
	UNION ALL SELECT ST_GeomFromText('MULTIPOLYGON EMPTY',4326) As the_geom
	UNION ALL SELECT ST_GeomFromText('LINESTRING EMPTY',4326) As the_geom
	UNION ALL SELECT ST_GeomFromText('MULTILINESTRING EMPTY',4326) As the_geom ) ) As foo1 ;

[pramsey]

I have made no fixes to AsGML, I fully expect it to do all kinds of nasty things when fed EMPTY.

For AsKML, I have checked in a fix to the crashing at r6402. Right now I return NULL on empty. The 1.5 behavior was that the empty got coerced to geometrycollection empty, which then failed the "no geometry collections allowed" test and failed with an error. I can change to error out on empty if that is preferred. There seems to be no representation for empty in KML, although we could invent one (<polygon></polygon>) I'm not sure what Google Earth would do with it. Research project?

[strk]

I'm fixing and regress-stress-test it for empty, for the GML case.

[strk]

r8412 fixes the GML case and tweaks the output to use empty tags (<Point/>). Should we use the same for KML ?

[strk]

Anyway, the crashers are gone so please file another ticket if you have complaints about the returned representations.