Opened 12 years ago
Closed 11 years ago
#2262 closed defect (fixed)
autocast to box causing issues with removed functions
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.1.0 |
Component: | postgis | Version: | 2.0.x |
Keywords: | Cc: |
Description
Bruce Rindahl pointed out to me that he was in the habit of using the
area function and when he upgraded to 2.0, he could still use the area function, but it was now returning a different answer from ST_Area. I think the wrong answer. I did a test myself on a pure 2.0 install, and came up with the same disturbing answer. Seems our geometries are falling into the built in box type is my guess and enjoying te fruits of using box area functions.
Demonstration:
select st_area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As our_area, area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As our_geom_found_in_box, area(ST_Buffer(ST_MakeEnvelope(1,2,3,4),1)) As explicit_cast_box
All kinda disturbing:
our_area | our_geom_found_in_box | explicit_cast_box ------------------+-----------------------+------------------- 15.1214451522581 | 16 | 16
I suppose we could just bring back area and length to prevent this from happening. I suspect those might be the only two.
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 11 years ago
Milestone: | PostGIS 2.0.4 → PostGIS 2.1.0 |
---|
I forgot about the more obvious solution though I guess we can't do it until 2.1 since its an API change. Can simply change this cast from IMPLICIT to assignment?
So if we do this:
CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS IMPLICIT;
to
CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS ASSIGNMENT;
I experimented with dropping it and as far as I can tell the earth did not shatter (it let me drop without complaining it needed to drop anything)
It might break some people's code, but it was problem breaking people's code already in the worst possible way: LOGICAL.
Once I made that change on my db, then this:
SELECT area('POINT(1 2)'::geometry)
was no longer legal and gave the correct
ERROR: function area(geometry) does not exist LINE 1: SELECT area('POINT(1 2)'::geometry)
Of course this means putting in
ALTER EXTENSION postgis DROP CAST (geometry AS box); -- only needed for extension DROP CAST (geometry AS box); CREATE CAST (geometry AS box) WITH FUNCTION public.box(geometry) AS ASSIGNMENT;
comment:3 by , 11 years ago
I meant
CREATE CAST (geometry AS box) WITH FUNCTION box(geometry) AS ASSIGNMENT;
or we could get rid of it, though I am tempted to say NO for that just because in 2.1 now that we allow casting from PostgreSQL types it only seems fair to allow casting back.
comment:4 by , 11 years ago
okay I converted to assignment at: r11340
but haven't put in upgrade logic. I hate repeating the CAST twice and don't see any other way for upgrade since our upgrade perl script strips out CREATE CAST from postgis.sql.in
comment:5 by , 11 years ago
The ideal would be to just drop the CAST entirely but not sure it exists for a reason. As far as I can tell its not tied to anything. The I can just put the drop cast in our drop after section.
comment:6 by , 11 years ago
pramsey et. al,
thoughts on this or are we fine that its a non-issue for people doing a hard-upgrade or new upgrade, but minor upgrades will suffer the same old behavior.
I guess it's not a super big deal or we can push the issue to a micro release at another time.
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I am happy with changing away from using an implicit cast.
st_centroid vs center might also be confusing. st_centroid returns a geometry while center returns a PostgeSQL point type so that part is obvious but the x and y coordinates are different. Testing length but there seems to be multiple versions of the function in PostgreSQL