I fully agree losing GDAL would be a HUGE step backwards. Let's not forget that GDAL has lots of rich vector support in it that we may want to leverage especially in 3.0. The only reason I propose this is for the few folks having problems compiling with GDAL or those who compile their own PostGIS and don't want to be forced to use scripts.
I should reiterate I am against splitting raster from postgis, I am just proposing a solution for folks who can't build with GDAL so they can use CREATE EXTENSION .. Nothing more and that is the least invasive change I can think of for everybody. Vincent, > I personally would appreciate to have CREATE EXTENSION postgis; (or > postgis_core) and CREATE EXTENSION postgis_raster; As said, it is then > clear from an application point of view which dependencies you have, > avoid to rely on GDAL if not needed - which can be a pain with all its > dependencies - and avoid to clutter the function lists, memory and > all. AS I mentioned I'm not interested in this. It's already fully clear when you do SELECT postgis_full_version(); Whether you have raster or not. Regarding the function list our function list is so huge with postgis alone that I don't see having postgis raster functions not in there being that much better to warrant the pain that would be caused by splitting And as I stated already there is no memory gain whatsoever. So if people are really against my approach for solving this, I think I'm going to have to leave this as a wontfix and just continue with business as usual. Thanks, Regina -----Original Message----- From: postgis-devel [mailto:postgis-devel-boun...@lists.osgeo.org] On Behalf Of Paul Ramsey Sent: Wednesday, October 28, 2015 10:06 AM To: vincent...@oslandia.com; PostGIS Development Discussion <postgis-de...@lists.osgeo.org> Cc: PostGIS Users Discussion <postgis-users@lists.osgeo.org> Subject: Re: [postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please Losing GDAL would be a step backwards, IMO, but I suppose we've gotten this far. I've just been hoping to make the SRS handling more magic by leaning on the OGR SRS stuff a bit, and that's not possible with GDAL out of the picture. However I guess that's the #1 reason for splitting raster out. I worry alot about this proposal impossibly complicating upgrades. PostGIS 3.0? P. On Wed, Oct 28, 2015 at 2:58 AM, Vincent Picavet (ml) <vincent...@oslandia.com> wrote: > Hello Regina, > > We do have cases where we do not need raster at all (>90% of our > users), and must compile everything from scratch (~10% of our users). > We would be pleased to not having to compile GDAL in this case. > And it would be great to still use the CREATE EXTENSION mechanism to > install Postgis, just to be consistent from a user point of view, with > what can be found in most documentation. > But I think we could live with a specific SQL loading method for the 10%. > > I personally would appreciate to have CREATE EXTENSION postgis; (or > postgis_core) and CREATE EXTENSION postgis_raster; As said, it is then > clear from an application point of view which dependencies you have, > avoid to rely on GDAL if not needed - which can be a pain with all its > dependencies - and avoid to clutter the function lists, memory and > all. > > But then it is a matter of how much work is required for that from the > developers, and is there funding to make it work this way. > > Vincent > > On 27/10/2015 23:49, Paragon Corporation wrote: >> How many folks are unable to compile postgis with raster or have a >> package that has no raster support and who REALLY REALLY want to be >> able to install postgis with: >> >> CREATE EXTENSION postgis; >> >> This is a repost of a conversation I started in PostGIS -develop >> which I probably should have cc'd PostGIS users on. It seems not too >> many people on dev have issue compiling with GDAL support. >> >> The issue discussed is that since postgis raster is part of the >> postgis extension, if people choose to compile without raster support >> because they can't get GDAL to work (despite being discouraged), they >> can not do >> >> CREATE EXTENSION postgis; >> >> They have to resort to the old way of using postgis contrib scripts >> to install. >> >> My proposition https://trac.osgeo.org/postgis/ticket/3338 >> >> >> was still have a postgis that has raster support (as breaking it out >> at this point would be headache particularly for the person who has >> to deal with the upgrade ramifications) and a big headache for people >> who use raster heavily as now they'd have two extensions to bother >> with. >> >> That said the proposition in a nutshell is this >> >> 1) Still have raster as default and you still need to explicitly ask >> for --without-raster 2) If you ask for --without-raster, you'll get >> an extension called "postgis" with no raster functions in it, but >> with an extension version number that reads 2.3.0-no-raster >> >> So a query like this if you compiled without raster: >> >> SELECT * FROM pg_available_extensions() WHERE name = 'postgis'; >> >> Would read: >> >> name | default_version | comment >> ---------+-----------------+----------------------------------------- >> ---------+-----------------+---------------------------- >> >> > postgis | 2.3.0-no-raster | PostGIS geometry and geography spatial > types and functions >> (1 row) >> >> Instead of: >> >> name | default_version | comment >> ---------+-----------------+----------------------------------------- >> ---------+-----------------+---------------------------- >> >> > postgis | 2.3.0 | PostGIS geometry, geography, and raster > spatial types and functions >> (1 row) >> >> >> Which means people who have postgis without raster support can follow >> the world renowned instructions: >> >> CREATE EXTENSION postgis; >> >> Like everyone else and all the other postgis extensions >> postgis_topology, postgis_tiger_geocoder will be built as well. >> >> The main downside to this is 1) you have a postgresql postgis >> extension that may not have any raster functions and one that goes by >> same extension name postgis with raster support. Though I claim this >> is clear from the version number and description :) 2) It does mean >> it s a bit easier for packager maintainers to package a postgis >> without raster support which is both good and bad -- good for older >> systems where an old antiquated gdal is not readily available so they >> can still package a newer postgis for it. -- bad for users who rely >> on package maintainers and really want raster support as their >> package maintainer might just decide not to bother with raster. >> >> If there is enough interest, I will reopen the ticket I closed and >> create and RFC as Paul Ramsey suggested to flesh out the complete >> details of this and how upgrading would work For folks coming from a >> postgis without raster non-extension version to a postgis without >> raster extension version. >> >> Thanks, Regina http://www.postgis.us http://postgis.net >> >> >> >> >> -----Original Message----- From: postgis-devel >> [mailto:postgis-devel-boun...@lists.osgeo.org] On Behalf Of Sandro >> Santilli Sent: Tuesday, October 27, 2015 5:28 PM To: PostGIS >> Development Discussion <postgis-de...@lists.osgeo.org> Subject: Re: >> [postgis-devel] postgis extension sans raster (only for folks who >> can't compile with raster support) - PSC Vote and developer/packager >> comments please >> >> On Tue, Oct 27, 2015 at 03:39:29PM -0400, Paragon Corporation wrote: >>> I've retracted. Seems not enough interest for this and could lead >>> to confusion. >>> >>> Or maybe I should have asked on postgis-users :) >> >> That's a good idea. Ask on postgis-users if there's any interest >> about being able to install postgis with no raster support. >> >> --strk; _______________________________________________ postgis-devel >> mailing list postgis-de...@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/postgis-devel >> >> >> _______________________________________________ postgis-devel mailing >> list postgis-de...@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/postgis-devel >> > > _______________________________________________ > postgis-devel mailing list > postgis-de...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/postgis-devel _______________________________________________ postgis-devel mailing list postgis-de...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/postgis-devel _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/postgis-users