[postgis-users] raster2pgsql binary in apt distros

[Nils Nolde]

Hi,

I had trouble accessing the raster2pgsql binary with different apt postgresql-x-postgis-x distros in the past. It’s not callable as executable and I can’t find it in the usual bin/ directories. I can only access it when installing ‘apt-get install postgis’ which leaves me with a postgresql v10 distro. Not a dealbreaker, but a bit annoying. So my questions are:

- how can I access raster2pgsql in a postgres specific postgis version from apt, e.g. postgresql-9.6-postgis-2.4?

- is there a way to compile the tool independent of a postgis installation, as to not have a full postgres installation for just using raster2pgsql? Context: sometimes I only need the tool in a docker container to update an external database.

Or does it need compilation against specific postgis versions? I guess GDAL is a dependency, but the produced .sql should be rather independent of postgis versions right?

Of course I could write my own sql statements for raster import, but it’s sooo convenient:)

Many thanks
Nils
_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users

[Regina Obe]

I don't think there is any way to get it via apt without getting PostgreSQL as I think it's only part of postgis package which contains just the loaders and dumpers (raster2pgsql, shp2pgsql, pgsql2shp)
and postgis was marked as depending on postgresql.

I'm guessing the reason for that is because pgsql2shp has a dependency on libpq. Though the others do not so would have a dependency on the postgresql client tools. Then again why that is sufficient to require postgresql seems a bit odd to me.

That said, assuming you had all the dependencies (GDAL generally being the biggest unless you compiled your own), then you in theory could

1) Download the postgis tar ball
2) Run configure (which you can't cause we require it to find pg_config which only comes with postgresql development)
3) CD into the raster/loader folder
4) run make && make install

It would seem to me though we could make this easier for folks. I too have on occasion only needed the commandline tools.
It would seem while we would "In theory" require libpq for the pgsql2shp, which having postgresql client would be sufficient.

Shp2pgsql and raster2pgsql just write out SQL so don't even need that.

Something to think about for our 3.0 release.

[Paul Ramsey]

Something to think about for our 3.0 release.

Might need to be ticketed and assigned to packagers? It's not a big ask, but it's easy to forget if they just copy'n'ship the old specs.

P

[Regina Obe]

I think we can make it a bit easier on them and also easier on people who just want the commandline tools

 

1)      Right now you can't compile the commandlines without having postgres installed unless you hack the make scripts

2)      It has come to my attention that raster2pgsql has a dependency on libpq.  I'm not sure why it should when I thought it just emits SQL similar to shp2pgsql (which has no libpq dependency).

So this sounds like a dependency that may be accidental.

[Michał Garnysz]

I noticed many of things you described and im i doubt there is any clean way to get it working. It looked like simple task get tar ball of postgres & postgis and make it work. (was even able to configure and make postgis but was installation dependant)
I made it run instance just overloading some param -L while executing initdb - on extracted binaries on clean ubuntu - not 100% all was working fine but where able to add extension and populate data.

It's sad that you can apt-get all of this in like 5steps, but there is no way to make it work form one binary (not installed) folder - there are ready to use docker container db with spatial but it's another dependency to project (and just for tests it's an overkill) 
Or maybe someone prove me wrong, anyone - please :)

[Mateusz Loskot]

Regina, 

I don't see how raster2pgsql depends on libpq. It does depend on liblwgeom, librtcore though. 

Mateusz Loskot, mat...@loskot.net
(Sent from mobile)

[Nils Nolde]

Thanks for thinking about an easier entrypoint for compiling and using
the command line binaries. I think it'd be a great addition.