#3541 closed enhancement (invalid)
Automatically convert Polygon to CurvePolygon when required
Reported by: | mkuhn | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Fund Me |
Component: | postgis | Version: | 2.2.x |
Keywords: | curve, curvepolygon, conversion | Cc: |
Description
When trying to insert a regular Polygon into a table with CurvePolygon type the operation fails with an error
ERROR: Geometry type (Polygon) does not match column type (CurvePolygon)
As far as I understand, the conversion from Polygon to CurvePolygon is lossless. Could this conversion be done implicitly? I cannot imagine a case where a user will take another action than adding an explicit conversion step from Polygon to CurvePolygon after seeing this message, so it might as well just happen implicitly.
The fact that at the moment there is no way to convert from Polygon to CurvePolygon apart from going through WKT (see #1291) makes this issue even more painful.
The same applies to LineString > CircularString and conceptually also to MultiCurve (untested).
> SELECT ST_GeomFromText('LINESTRING(75.15 29.53,77 29,77.6 29.5)')::geometry('CircularString'); ERROR: Geometry type (LineString) does not match column type (CircularString)
Change History (9)
comment:1 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 8 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
I meant to write COMPOUNDCURVE which can be converted from LINESTRING in a lossless way. Sorry for bringing in CIRCULARLINESTRING which raises an exception for good reasons.
I.e.
SELECT ST_GeomFromText('LineString(75.15 29.53,77 29,77.6 29.5)')::geometry('CompoundCurve');
can easily be upcasted to
SELECT ST_GeomFromText('CompoundCurve((75.15 29.53,77 29,77.6 29.5))')
The same holds true for CurvePolygon (which is in the title).
SELECT ST_GeomFromText('Polygon((0 0,1 1,1 0,0 0))')::geometry('CurvePolygon');
has exactly the same representation as
SELECT ST_GeomFromText('CurvePolygon((0 0,1 1,1 0,0 0))');
The current situation is similar to not being able to cast an integer to a float. Just because float allows more precision than integer.
select 1::float;
Please note, that this issue only concerns upcasting, downcasting from curve to non-curve types can be forbidden by definition even though possible in some scenarios.
comment:3 by , 8 years ago
Basically the requirement is to have some kind of method to take an existing linestring / polygon column and upgrade it to a compoundcurve / curvepolygon column.
Casting would IMHO be nice, but a function would also work.
At the moment I am not aware of any possibility to do this except for ST_AsText -> String Manipulation -> ST_GeomFromText. Or am I mistaken here?
comment:4 by , 8 years ago
I think this is similar to the work done by ST_Force3DZ, ST_ForceCollection, ST_ForceMulti. How about ST_ForceCurve ?
comment:6 by , 8 years ago
Apparently ST_ForceCurve is already there since 2.2 and works perfectly fine http://postgis.net/docs/ST_ForceCurve.html
Sorry for the noise
comment:7 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
LINESTRING with 3 points would result in a circularlinestring implicitly only if you assume that you want the middle to be a control point. This is a big jump in assumption to me. As I would expect a LINESTRING that forms into a curve to be a curve.
So I don't feel this warrants blind conversion option.
Even if it did, I don't think its possible the way we have PostGIS constructed to morph from one subtype geometry to another. Note we only have casts from geometry, geography, box, box2d, box3d, raster but those are all separate types, not subtypes of the same type.
pramsey or strk can correct me if my assumptions are wrong here.