Opened 14 years ago
Closed 14 years ago
#555 closed defect (fixed)
Ability to define a geometry column as Polyhedral surface
Reported by: | robe | Owned by: | colivier |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
Olivier,
I'm sure you are aware of these, but though I would itemize them as I come across so we don't forget.
CREATE TABLE pgis_garden (gid serial); SELECT AddGeometryColumn('pgis_garden','the_geom',ST_SRID(the_geom),GeometryType(the_geom),ST_CoordDim(the_geom)) FROM ((SELECT ST_GeomFromEWKT( 'SRID=0;PolyhedralSurface( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )') As the_geom) ) As foo limit 1;
gives error:
ERROR: Invalid type name - valid ones are:
SELECT GeometryType(the_geom), ST_GeometryType(the_geom) FROM ((SELECT ST_GeomFromEWKT( 'SRID=0;PolyhedralSurface( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )') As the_geom) ) As foo limit 1;
Gives 'Unknown' for GeometryType and ST_PolyhedralSurface for ST_GeometryType. You think we should allow GeometryType to return POLYHEDRALSURFACE ?
Change History (10)
comment:1 by , 14 years ago
Owner: | changed from | to
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Its already added. That's how I came across this problem.
ST_Area I see also returns an answer. Is that intentional or accidental. I'm not sure how to check if the answer is right.
What I was going to do next is to revise the subset.xsl so can isolate testing specific geometries like Polyhedral, so not so much noise in testing
comment:4 by , 14 years ago
For ST_Area it's a 'normal' behaviour as it care on sub geometry only. And PolyhedralSurface is a collection of connected polygons.
So ST_Area should return the sum area of each sub polygon inside.
So it should be OK for this one.
I guess i will also have to 'flag' each supported function in the documentation with a 'PS_support'
comment:5 by , 14 years ago
We'll also want to put a new in this release too. No need to worry about that though. I'll flag them as I come across them in my testing and confirm with you that they really are supposed to work. I'll aslo add another matrix column (though what to call that column) ?
Might be easier to just see which functions when subjected to polyhedral surfaces the garden tester arrives at an answer for which is the reason for enhancing the subtests to isolate certain kinds of geometries. Should be interesting.
comment:6 by , 14 years ago
Olivier,
Now I remember why I had my suspicions about ST_Area. I don't think our ST_Area supports 2.5D polygons and aren't all the faces of the polyhedral surface 2.5D polygons? In which case -- it probably needs some work.
But saying ST_Dump works with polyhedral surfaces I guess is safe to say.
comment:7 by , 14 years ago
Forgot to ask - does Oracle Locator support Polyhedral surfaces (or is it just the spatial version). Would be nice to have a system we can verify our answers as we did with geography.
comment:8 by , 14 years ago
Regina,
A PolyhedralSurface could be 2D, 2D5 or 3D !
2D if only X,Y,(M) defined (in this case it's really close to a multipolygon, except that we oblige all polygons to be connected)
2D5 if there's also Z defined
3D if in more each patch is connected to 2 others (and then produce a polyhedron, so a volume)
Area work on 2D (even if your geometry is not only 2D) On SQL/MM we are supposed to implement also in addition ST_3DArea to deal with such a thing.
And you're definiltly right current ST_Area don'deal with Z !
There's no statement (AFAIK) to indicate what to do if the geometry is 2D5/3D and the function is 2D only (i.e exit on error, or silently ignore Z dimension)
For Oracle i dunno, Only thing i've seen on papers is that they don't use the same way to describe a volume (so not the same WKT)
comment:9 by , 14 years ago
NOTA: My definition of Polyhedron is wrong. It's the boudary patch linestring itself who should 'share' exactly 2 patches.
comment:10 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Regina,
You're the world's first tester of this feature :)
My previous commits only care indeed about low level serialization, i fixed this issue on r5772.
It now works for me on your SQL provided (modulo changing SRID to -1)
Is it the first step to add this new type to garden test ?