Opened 14 years ago

Closed 13 years ago

#724 closed defect (fixed)

ST_AsEWKT outputs invalid EWKT (mixed dimensionality in collection)

Reported by: robe Owned by: strk
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: history Cc:

Description

This one is from regression testing against PostGIS 1.5.2: I'm not really sure if this is just something you are not done with In PostGIS 2.0

SELECT ST_AsEWKT(ST_Collect(ST_GeomFromEWKT('SRID=4326;MULTIPOLYGONM(((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2)))'),
ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1))') )) ;

— yields the below which is the same answer as 1.5 —

SRID=4326;GEOMETRYCOLLECTIONM(MULTIPOLYGON(((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))

Didn't we plan those to be all Ms in there?

— this works

SELECT geography(ST_Collect(ST_GeomFromEWKT('SRID=4326;MULTIPOLYGONM(((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2)))'),
ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1))') )) ;

—This doesn't work but used to in 1.5 so I have this problem — that I can't convert what I used to input.. Maybe we don't care.

SELECT ST_GeogFromText(ST_AsEWKT(ST_Collect(ST_GeomFromEWKT('SRID=4326;MULTIPOLYGONM(((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2)))'),
ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1))') ))) ;

— this

SELECT ST_AsText(geography(ST_Collect(ST_GeomFromEWKT('SRID=4326;MULTIPOLYGONM(((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2)))'),
ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1))') )) );

— gives the below which was kind of what I was expecting ST_AsEWKT to return except with the additional SRID info

GEOMETRYCOLLECTION M (MULTIPOLYGON M (((-71.0821 42.3036 2,-71.0822 42.3036 3,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON M ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 2,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))

I'm not sure if we consider this a bug or not — or is this the same issues as #718 and its just because you haven't set ST_AsEWKT to behave like the new ST_AsText of geography?

Change History (5)

comment:1 by strk, 13 years ago

I confirm there's an inconsistency. According to doc/ZMgeoms.txt we do want the M replicated in subgeoms. But our EWKT format doesn't add them. Instead, AsText, but only for geography, adds the M in all subgeoms.

comment:2 by strk, 13 years ago

Owner: changed from pramsey to strk
Status: newassigned
Summary: ST_AsEWKT , ST_GeogFromText regress failureST_AsEWKT outputs invalid EWKT (mixed dimensionality in collection)

Ok, I think the core of this bug is that the parser can't read what the writer emits:

SELECT ST_AsEwkt(geometry(ST_Collect('MULTIPOINTM((1 1 1))', 'POINTM(5 5 5)')) )::geometry;
ERROR:  can not mix dimensionality in a geometry

Note that dropping the ::geometry part you get no error, so the error is at parse time, and the error is correct. So the bug is in ST_AsEwkt. I'm on it.

comment:3 by strk, 13 years ago

NOTE: 1.5.4 is also bogus. The difference there is that the parser only dumps a NOTICE rather than an ERROR.

comment:4 by strk, 13 years ago

It's incredible how many tests in the regression suite expect the bogus EWKT..

comment:5 by strk, 13 years ago

Keywords: history added
Resolution: fixed
Status: assignedclosed

Fixed in trunk by r8741. Not sure it is safe to backport.

Note: See TracTickets for help on using tickets.