Opened 13 years ago
Closed 13 years ago
#1635 closed defect (fixed)
[raster] Operator does not exist: raster ~ geometry
Reported by: | nicklas | Owned by: | pracine |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | raster | Version: | master |
Keywords: | Cc: |
Description
qgis can't show raster layer with latest trunk.
r9240 works
The issue isn't in the C part since I can change to latest binaries so something must have happened with the ~definition on the sql-side
the error is: operator does not exist: raster ~ geometry
Attachments (1)
Change History (35)
comment:1 by , 13 years ago
Summary: | operator does not exist: raster ~ geometry → [raster] Operator does not exist: raster ~ geometry |
---|
comment:3 by , 13 years ago
I guess it would not be wise to reverse the decision to make the cast explicit. So I guess the QGIS plugin will have to adapt... Bborie, Regina?
comment:4 by , 13 years ago
or you could explicitly create an operator for this. That might be wiser since I think this might be a common one and will affect mapserver as well or we could add to legacy install script file.
comment:5 by , 13 years ago
I concur with robe. Creating the operators is the best solution and possibly the easiest for the long term.
comment:7 by , 13 years ago
Now that I've looked at the operator code in rtpostgis.sql.in.c, I take back my prior comments. If we're going to add two more operators for ~ (raster ~ geometry and geometry ~ raster), do we need to add operators for all the other raster/geometry operators?
Maybe it is best to have the applications catch up and provide the appropriate IMPLICIT CASTs in legacy.sql
comment:8 by , 13 years ago
I think there's no problem with QGIS catching up, is just a matter of notifying the thing to the appropriate tracker. I never used postgis rasters with qgis so I'm not the best person to look at it.
comment:9 by , 13 years ago
I'd take the chance to notice that if all bounding box operators were defined on an Envelope type all of this would be a non-issue in that all types would implicitly cast to Envelope...
follow-ups: 11 12 comment:10 by , 13 years ago
Is there an envelope type?
I forget the name of the QGIS PostGIS Raster plugin developer. Pierre, if you remember, can you contact them?
comment:11 by , 13 years ago
Replying to dustymugs:
Is there an envelope type?
No, but we've given that a lot of thoughts. Stuff for 2.1 (maybe)
comment:12 by , 13 years ago
Replying to dustymugs:
I forget the name of the QGIS PostGIS Raster plugin developer. Pierre, if you remember, can you contact them?
Done. I set it to the new 'third party' component.
comment:13 by , 13 years ago
Component: | postgis → third party |
---|---|
Owner: | changed from | to
comment:14 by , 13 years ago
Component: | third party → raster |
---|---|
Milestone: | PostGIS 2.0.0 → PostGIS 2.0.1 |
comment:15 by , 13 years ago
Bear in mind that changing SQL function/operator definitions in a patch release violates our release policy. If you do need these extra operators, then they need go into either 2.0 or 2.1, not 2.0.1.
comment:16 by , 13 years ago
So Borie shall we make those operators in 2.0 or never? I vote never and add to legacy.
comment:17 by , 13 years ago
Milestone: | PostGIS 2.0.1 → PostGIS 2.1.0 |
---|
Question: is "the bounding box of a raster" open to different interpretations ? I mean, why is it that we don't want to provide an implicit path from RASTER to "bounding box" ? Because that's what we are after when dealing with all operators.
comment:18 by , 13 years ago
All we need is a set of
CREATE OPERATOR ~ ( LEFTARG = raster, RIGHTARG = geometry, PROCEDURE = raster_contain, COMMUTATOR = '@', RESTRICT = contsel, JOIN = contjoinsel );
and
CREATE OR REPLACE FUNCTION raster_contain(raster, geometry) RETURNS bool AS 'select $1::geometry ~ $2' LANGUAGE 'SQL' IMMUTABLE STRICT;
right?
comment:19 by , 13 years ago
yeah, it sounds about right. Lots of noise, isnt' it ? If you go there I recommend putting in a separate, but included, SQL file. I really hope we'll be able to replace all this noise with a single set of operators defined for a new Envelope type to which all our spatial types implicitly cast.
comment:20 by , 13 years ago
Bborie, Regina, if your ok with that I can do it.
So we need the two permutations of (geometry, raster) for all the 12 gist operators, right? 24 new operators and 24 new functions. Good calculation?
comment:21 by , 13 years ago
Correct. I do like strk's idea of putting those operators in a separate file to keep the noise down.
comment:22 by , 13 years ago
Pierre,
I wouldn't bother for all. Really I think ~ and && are the ones most people use and that will fix the third party issues we have. Lets not over clutter because it is much harder to take things out than put them in.
comment:23 by , 13 years ago
So then just 2 operators time 2 permutations = 4 operators and 4 functions. I'll keep everything in the same file.
comment:26 by , 13 years ago
Yes. Do I have to make regress for them? They are just SQL variants of existing functions and operators after all...
comment:27 by , 13 years ago
You probably should create regression tests for them. I think we have them for all the other operators.
comment:28 by , 13 years ago
Fixed at r9372. Nicklas, can you try QGIS to see if that fix the problem?
follow-up: 33 comment:29 by , 13 years ago
Milestone: | PostGIS 2.1.0 → PostGIS 2.0.0 |
---|
Don't forget to update utils/postgis_restore.pl to have the new signatures in the final list! (granted, not an easy task).
Easy way: create and spatially-enable database temp; pg_dump -Fc temp > temp.dump; postgis_restore.pl -v temp.dump 2> log > /dev/null; grep KEEP log | grep raster
Then copy & paste the output by the end of postgis_restore.pl dropping the "KEEP: " prefix, and sort.
comment:30 by , 13 years ago
Status: | new → assigned |
---|
comment:31 by , 13 years ago
Now it works like a charm :-)
Thanks!
see screenshoot
I leave it open because of strks last comment.
comment:33 by , 13 years ago
Replying to strk:
Don't forget to update utils/postgis_restore.pl to have the new signatures in the final list! (granted, not an easy task).
Easy way: create and spatially-enable database temp; pg_dump -Fc temp > temp.dump; postgis_restore.pl -v temp.dump 2> log > /dev/null; grep KEEP log | grep raster
Then copy & paste the output by the end of postgis_restore.pl dropping the "KEEP: " prefix, and sort.
ok. I did the whole process. I get:
$ grep ^KEEP log | grep raster KEEP: FUNCTION geometry_raster_contain(geometry, raster) KEEP: FUNCTION geometry_raster_overlap(geometry, raster) KEEP: FUNCTION postgis_raster_scripts_installed() KEEP: FUNCTION raster_geometry_contain(raster, geometry) KEEP: FUNCTION raster_geometry_overlap(raster, geometry) KEEP: FUNCTION st_clip(raster, geometry, double precision[], boolean) KEEP: FUNCTION st_clip(raster, integer, geometry, double precision[], boolean) KEEP: FUNCTION st_geotransform(raster) KEEP: FUNCTION st_intersection(raster, raster, double precision[]) KEEP: FUNCTION st_intersection(raster, raster, double precision) KEEP: FUNCTION st_intersection(raster, raster, text, double precision[]) KEEP: FUNCTION st_intersection(raster, raster, text, double precision) KEEP: FUNCTION st_intersection(raster, integer, raster, integer, double precision[]) KEEP: FUNCTION st_intersection(raster, integer, raster, integer, double precision) KEEP: FUNCTION st_intersection(raster, integer, raster, integer, text, double precision[]) KEEP: FUNCTION st_intersection(raster, integer, raster, integer, text, double precision) KEEP: FUNCTION st_setgeotransform(raster, double precision, double precision, double precision, double precision, double precision, double precision)
If I understand well I should have seen only me new functions. so there seem to be missing more entries in postgis_restore.pl. Right?
Also I saw many lines starting with FUNCION instead of FUNCTION. Looks like a typo.
I add just the one I added...
Must be since casts became explicit...
Is raster::geometry ~ geometry working?