[postgis-tickets] [PostGIS] #3338: postgis extension that returns not supported for all Raster functions if raster not available

Sun Oct 18 02:54:03 PDT 2015

#3338: postgis extension that returns not supported for all Raster functions if
raster not available
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 2.3.0
 Component:  postgis  |    Version:  2.0.x
Resolution:           |   Keywords:
----------------------+---------------------------

Old description:

> Was talking on IRC with astrodog and it seems they are having a hard time
> getting raster in the FreeBSD packages because of all the dependencies
> GDAL brings in which a user may not have.
>
> The easiest option which he proposed which I think we can swing is to
> still have a PostGIS extension that zeros out raster if not available.
> Just returns a not supported note similar to what we do with ST_GeoJSON
> and several GEOS functions if your GEOS is not new enough.
>
> Here is bit of IRC dialog for context
>
> {{{
> 23:39] <astrodog> We build gdal as another package, with pretty broad
> support for formats.
> [23:39] <astrodog> That way things just work for people.
> [23:39] <robe2> and disable everything except some key ones like sqlite,
> odbc, curl
> [23:40] <robe2> I even disable postgres
> [23:40] <astrodog> But PostGIS brings in GDAL, which brings in a pile of
> other things.
> [23:40] <astrodog> None of it is bad if you build from source... it's the
> binary packages that cause problems.
> [23:41] <robe2> one more reason not to have a shared liblwgeom :)
> [23:41] <robe2> astrodog: so you can't build an isolated gdal sits in
> postgres bin?
> [23:42] <robe2> on windows always searches in postgres bin first
> [23:42] <robe2> so I can override system dlls by replacing with my own
> version
> [23:42] <robe2> not sure how it works on unix/linux
> [23:43] <astrodog> robe: If you guys bundle it, I can. If you don't, I'm
> expected to use whatever the gdal port does, that way users can set
> whatever gdal options they want.
> [23:43] <robe2> so if we included gdal source as part of our dist
> package?
> [23:45] <robe2> pl/v8 (not sure if they still do have to check) included
> v8 source zip as part of theres
> [23:45] <astrodog> Sure. Then it's just some thing you guys included...
> and any issues it creates would be sent up to PostGIS trac. *grin*
> [23:45] <robe2> cause the v8 upstream was kinda flaky (I mean you hit a
> bad version and you are screwed)
> [23:48] <robe2> astrodog: so if you have gdal already is the issue
> because depending on user installing, they might have a different gdal
> with not all the dependencies available
> [23:49] <robe2> I got the impression from listening to devrimgunduz that
> was his pain
> [23:49] <robe2> and why EL 5, CentOS 5 he was very apologetic for
> [23:49] <astrodog> Yeah.
> [23:49] <astrodog> For us... we install GDAL with a huge pile of things,
> so that the various bits that depend on it can all use one version.
> [23:50] <astrodog> But it means requiring GDAL is a fairly large
> requirement.
> [23:50] <robe2> I wonder how hard it would be to get GDAL to do run-time
> load like they do with proj already
> [23:50] <robe2> that seems like the fundamental issue
> [23:51] <robe2> astrodog: do you built spatialite and rasterlite
> [23:51] <robe2> as I recall rasterlite relies on gdal I think
> [23:51] <robe2> so would have similar issue
> [23:52] <astrodog> Yeah, it does.
> [23:52] <robe2> so you have same issue with it?
> [23:53] <astrodog> Yeah, but with rasterlite, people know they're in for
> it.
> [23:53] <robe2> one thing I always wanted was for people to be able to
> swap out the gdal I have with a beefier one
> [23:53] <astrodog> The issue we run into with PostGIS is that the SQL
> method isn't as well documented... so we get PRs saying "Loading the
> extension doesn't work!"
> [23:54] <robe2> well we could document that better I guess
> [23:54] <robe2> I didn't like it cause it required too much explaining
> [23:54] <astrodog> It's not so much you guys, as every tutorial on the
> planet skips over that option. :P
> [23:54] <robe2> like find where your files are stored -- and I lost 90%
> of the audience at that point
> [23:54] <astrodog> Be nice if the extension had a way to tell if it had
> raster support or not, and act accordingly.
> [23:55] <robe2> and had to digress into if you are on this - its' here ,
> if you are on that it's here etc
> [23:55] <astrodog> *nod*
> [23:56] <robe2> yah but then it wouldn't be the same extension
> [23:56] <robe2> we could create a postgis_no_raster extension
> [23:56] <astrodog> Could the extension stub out the raster bits if they
> aren't there?
> [23:57] <astrodog> So the function exists, it just always returns not
> supported.
> [23:57] <astrodog> :P
> [23:57] <robe2> but the problem is the extension model doesn't have a way
> to say something like requires: postgis or postgis_no_raster;
> [23:57] <robe2> So you'd have issues with like you can't install
> postgis_sfcgal, pgrouting etc.
> [23:57] <robe2> astrodog: ah didn't think about that
> [23:57] <robe2> yah it could
> [23:57] <robe2> that's a great idea
> [23:58] <robe2> we do that already for some functons like json and geos
> if you are running a lower geos
> [23:58] <robe2> I'll ticket it
> }}}

New description:

 Was
  talking on IRC with astrodog and it seems they are having a hard time
 getting raster in the FreeBSD packages because of all the dependencies
 GDAL brings in which a user may not have.

 The easiest option which he proposed which I think we can swing is to
 still have a PostGIS extension that zeros out raster if not available.
 Just returns a not supported note similar to what we do with ST_GeoJSON
 and several GEOS functions if your GEOS is not new enough.

 Here is bit of IRC dialog for context

 {{{
 23:39] <astrodog> We build gdal as another package, with pretty
 broad support for formats.
 [23:39] <astrodog> That way things just work for people.
 [23:39] <robe2> and disable everything except some key ones like
 sqlite, odbc, curl
 [23:40] <robe2> I even disable postgres
 [23:40] <astrodog> But PostGIS brings in GDAL, which brings in a
 pile of other things.
 [23:40] <astrodog> None of it is bad if you build from source...
 it's the binary packages that cause problems.
 [23:41] <robe2> one more reason not to have a shared liblwgeom :)
 [23:41] <robe2> astrodog: so you can't build an isolated gdal sits
  in postgres bin?
 [23:42] <robe2> on windows always searches in postgres bin first
 [23:42] <robe2> so I can override system dlls by replacing with my
  own version
 [23:42] <robe2> not sure how it works on unix/linux
 [23:43] <astrodog> robe: If you guys bundle it, I can. If you
 don't, I'm expected to use whatever the gdal port does, that way users
 can set whatever gdal options they want.
 [23:43] <robe2> so if we included gdal source as part of our dist
 package?
 [23:45] <robe2> pl/v8 (not sure if they still do have to check)
 included v8 source zip as part of theres
 [23:45] <astrodog> Sure. Then it's just some thing you guys
 included... and any issues it creates would be sent up to PostGIS trac.
 *grin*
 [23:45] <robe2> cause the v8 upstream was kinda flaky (I mean you
 hit a bad version and you are screwed)
 [23:48] <robe2> astrodog: so if you have gdal already is the issue
  because depending on user installing, they might have a different gdal
 with not all the dependencies available
 [23:49] <robe2> I got the impression from listening to
 devrimgunduz that was his pain
 [23:49] <robe2> and why EL 5, CentOS 5 he was very apologetic for
 [23:49] <astrodog> Yeah.
 [23:49] <astrodog> For us... we install GDAL with a huge pile of
 things, so that the various bits that depend on it can all use one
 version.
 [23:50] <astrodog> But it means requiring GDAL is a fairly large
 requirement.
 [23:50] <robe2> I wonder how hard it would be to get GDAL to do
 run-time load like they do with proj already
 [23:50] <robe2> that seems like the fundamental issue
 [23:51] <robe2> astrodog: do you built spatialite and rasterlite
 [23:51] <robe2> as I recall rasterlite relies on gdal I think
 [23:51] <robe2> so would have similar issue
 [23:52] <astrodog> Yeah, it does.
 [23:52] <robe2> so you have same issue with it?
 [23:53] <astrodog> Yeah, but with rasterlite, people know they're
 in for it.
 [23:53] <robe2> one thing I always wanted was for people to be
 able to swap out the gdal I have with a beefier one
 [23:53] <astrodog> The issue we run into with PostGIS is that the
 SQL method isn't as well documented... so we get PRs saying "Loading the
  extension doesn't work!"
 [23:54] <robe2> well we could document that better I guess
 [23:54] <robe2> I didn't like it cause it required too much
 explaining
 [23:54] <astrodog> It's not so much you guys, as every tutorial on
  the planet skips over that option. :P
 [23:54] <robe2> like find where your files are stored -- and I
 lost 90% of the audience at that point
 [23:54] <astrodog> Be nice if the extension had a way to tell if
 it had raster support or not, and act accordingly.
 [23:55] <robe2> and had to digress into if you are on this - its'
 here , if you are on that it's here etc
 [23:55] <astrodog> *nod*
 [23:56] <robe2> yah but then it wouldn't be the same extension
 [23:56] <robe2> we could create a postgis_no_raster extension
 [23:56] <astrodog> Could the extension stub out the raster bits if
  they aren't there?
 [23:57] <astrodog> So the function exists, it just always returns
 not supported.
 [23:57] <astrodog> :P
 [23:57] <robe2> but the problem is the extension model doesn't
 have a way to say something like requires: postgis or postgis_no_raster;
 [23:57] <robe2> So you'd have issues with like you can't install
 postgis_sfcgal, pgrouting etc.
 [23:57] <robe2> astrodog: ah didn't think about that
 [23:57] <robe2> yah it could
 [23:57] <robe2> that's a great idea
 [23:58] <robe2> we do that already for some functons like json and
  geos if you are running a lower geos
 [23:58] <robe2> I'll ticket it
 }}}

--

Comment (by strk):

 I thought we had a ticket for this but could not find one.
 My idea was that we should have these extensions:

  - postgis_core
  - postgis_raster depends on postgis_core
  - postgis_topology depends on postgis_core
  - postgis_sfcgal depends on postgis_core
  - (postgis depends on postgis_core and postgis_raster) for backward
 compatibility

 How to get there is still to be found out, especially when it comes to
 upgrading an existing system.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3338#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.