Changes between Initial Version and Version 1 of Ticket #3338


Ignore:
Timestamp:
10/18/15 02:54:03 (9 years ago)
Author:
strk
Comment:

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.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3338 – Description

    initial v1  
    1 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.
     1Was
     2 talking on IRC with astrodog and it seems they are having a hard time
     3getting raster in the FreeBSD packages because of all the dependencies
     4GDAL brings in which a user may not have.
    25
    3 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.
     6The easiest option which he proposed which I think we can swing is to
     7still have a PostGIS extension that zeros out raster if not available. 
     8Just returns a not supported note similar to what we do with ST_GeoJSON
     9and several GEOS functions if your GEOS is not new enough.
    410
    511Here is bit of IRC dialog for context
    612
    713{{{
    8 23:39] <astrodog> We build gdal as another package, with pretty broad support for formats.
     1423:39] <astrodog> We build gdal as another package, with pretty
     15broad support for formats.
    916[23:39] <astrodog> That way things just work for people.
    10 [23:39] <robe2> and disable everything except some key ones like sqlite, odbc, curl
     17[23:39] <robe2> and disable everything except some key ones like
     18sqlite, odbc, curl
    1119[23:40] <robe2> I even disable postgres
    12 [23:40] <astrodog> But PostGIS brings in GDAL, which brings in a pile of other things.
    13 [23:40] <astrodog> None of it is bad if you build from source... it's the binary packages that cause problems.
     20[23:40] <astrodog> But PostGIS brings in GDAL, which brings in a
     21pile of other things.
     22[23:40] <astrodog> None of it is bad if you build from source...
     23it's the binary packages that cause problems.
    1424[23:41] <robe2> one more reason not to have a shared liblwgeom :)
    15 [23:41] <robe2> astrodog: so you can't build an isolated gdal sits in postgres bin?
     25[23:41] <robe2> astrodog: so you can't build an isolated gdal sits
     26 in postgres bin?
    1627[23:42] <robe2> on windows always searches in postgres bin first
    17 [23:42] <robe2> so I can override system dlls by replacing with my own version
     28[23:42] <robe2> so I can override system dlls by replacing with my
     29 own version
    1830[23:42] <robe2> not sure how it works on unix/linux
    19 [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.
    20 [23:43] <robe2> so if we included gdal source as part of our dist package?
    21 [23:45] <robe2> pl/v8 (not sure if they still do have to check) included v8 source zip as part of theres
    22 [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 [23:45] <robe2> cause the v8 upstream was kinda flaky (I mean you hit a bad version and you are screwed)
    24 [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
    25 [23:49] <robe2> I got the impression from listening to devrimgunduz that was his pain
     31[23:43] <astrodog> robe: If you guys bundle it, I can. If you
     32don't, I'm expected to use whatever the gdal port does, that way users
     33can set whatever gdal options they want.
     34[23:43] <robe2> so if we included gdal source as part of our dist
     35package?
     36[23:45] <robe2> pl/v8 (not sure if they still do have to check)
     37included v8 source zip as part of theres
     38[23:45] <astrodog> Sure. Then it's just some thing you guys
     39included... and any issues it creates would be sent up to PostGIS trac.
     40*grin*
     41[23:45] <robe2> cause the v8 upstream was kinda flaky (I mean you
     42hit a bad version and you are screwed)
     43[23:48] <robe2> astrodog: so if you have gdal already is the issue
     44 because depending on user installing, they might have a different gdal
     45with not all the dependencies available
     46[23:49] <robe2> I got the impression from listening to
     47devrimgunduz that was his pain
    2648[23:49] <robe2> and why EL 5, CentOS 5 he was very apologetic for
    2749[23:49] <astrodog> Yeah.
    28 [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.
    29 [23:50] <astrodog> But it means requiring GDAL is a fairly large requirement.
    30 [23:50] <robe2> I wonder how hard it would be to get GDAL to do run-time load like they do with proj already
     50[23:49] <astrodog> For us... we install GDAL with a huge pile of
     51things, so that the various bits that depend on it can all use one
     52version.
     53[23:50] <astrodog> But it means requiring GDAL is a fairly large
     54requirement.
     55[23:50] <robe2> I wonder how hard it would be to get GDAL to do
     56run-time load like they do with proj already
    3157[23:50] <robe2> that seems like the fundamental issue
    3258[23:51] <robe2> astrodog: do you built spatialite and rasterlite
     
    3561[23:52] <astrodog> Yeah, it does.
    3662[23:52] <robe2> so you have same issue with it?
    37 [23:53] <astrodog> Yeah, but with rasterlite, people know they're in for it.
    38 [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
    39 [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!"
     63[23:53] <astrodog> Yeah, but with rasterlite, people know they're
     64in for it.
     65[23:53] <robe2> one thing I always wanted was for people to be
     66able to swap out the gdal I have with a beefier one
     67[23:53] <astrodog> The issue we run into with PostGIS is that the
     68SQL method isn't as well documented... so we get PRs saying "Loading the
     69 extension doesn't work!"
    4070[23:54] <robe2> well we could document that better I guess
    41 [23:54] <robe2> I didn't like it cause it required too much explaining
    42 [23:54] <astrodog> It's not so much you guys, as every tutorial on the planet skips over that option. :P
    43 [23:54] <robe2> like find where your files are stored -- and I lost 90% of the audience at that point
    44 [23:54] <astrodog> Be nice if the extension had a way to tell if it had raster support or not, and act accordingly.
    45 [23:55] <robe2> and had to digress into if you are on this - its' here , if you are on that it's here etc
     71[23:54] <robe2> I didn't like it cause it required too much
     72explaining
     73[23:54] <astrodog> It's not so much you guys, as every tutorial on
     74 the planet skips over that option. :P
     75[23:54] <robe2> like find where your files are stored -- and I
     76lost 90% of the audience at that point
     77[23:54] <astrodog> Be nice if the extension had a way to tell if
     78it had raster support or not, and act accordingly.
     79[23:55] <robe2> and had to digress into if you are on this - its'
     80here , if you are on that it's here etc
    4681[23:55] <astrodog> *nod*
    4782[23:56] <robe2> yah but then it wouldn't be the same extension
    4883[23:56] <robe2> we could create a postgis_no_raster extension
    49 [23:56] <astrodog> Could the extension stub out the raster bits if they aren't there?
    50 [23:57] <astrodog> So the function exists, it just always returns not supported.
     84[23:56] <astrodog> Could the extension stub out the raster bits if
     85 they aren't there?
     86[23:57] <astrodog> So the function exists, it just always returns
     87not supported.
    5188[23:57] <astrodog> :P
    52 [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;
    53 [23:57] <robe2> So you'd have issues with like you can't install postgis_sfcgal, pgrouting etc.
     89[23:57] <robe2> but the problem is the extension model doesn't
     90have a way to say something like requires: postgis or postgis_no_raster;
     91[23:57] <robe2> So you'd have issues with like you can't install
     92postgis_sfcgal, pgrouting etc.
    5493[23:57] <robe2> astrodog: ah didn't think about that
    5594[23:57] <robe2> yah it could
    5695[23:57] <robe2> that's a great idea
    57 [23:58] <robe2> we do that already for some functons like json and geos if you are running a lower geos
     96[23:58] <robe2> we do that already for some functons like json and
     97 geos if you are running a lower geos
    5898[23:58] <robe2> I'll ticket it
    5999}}}