Geospatial Foreign Data Wrappers

[robe]

Now that PostgreSQL 9.1 has produced usable SQL/MED bindings and with raster we now have libgdal dependency. It seems to me we have all the ingredients to make some very slick geospatial data wrappers.

Here is an example from PgCon2011 talk leveraging these bindings:

​http://www.pgcon.org/2011/schedule/events/353.en.html

[pracine]

You mean that could be an easy way to implement full support for out-of-db rasters (and out-of-db vectors of course!)?

[pracine]

See also:

​http://www.pgcon.org/2009/schedule/events/142.en.html

[pracine]

and ​http://www.postgresql.org/docs/9.1/static/fdwhandler.html

[robe]

Yes that is what I was thinking.

[nicklas]

To add more possible fdw-implementations

If fdw can be used against twitter it ought to be possible to use it against a gps-stream.

A fdw catching the data from ​gpsd.

[robe]

This may need to require 9.2+ or higher. They've changed the API quite a bit in 9.2 for FDW to the point that trying to do a bunch of IFDEFs could become painful and most 9.1 FDWs are broken I believe. I got wind of this when I complained to Andrew I couldn't build my favortie FDW anymore on 9.2 and he fixed it but decided to have two parallel branches instead after that.

​https://github.com/adunstan/file_text_array_fdw/commit/9d173bc89fef92e280e8803ceca962d7393a7bc5

[strk]

Did anyone start on this ? I'm starting to work on a ogr2ogr FWD for both vectors and rasters, with 9.3 min dependency as a focus. Not sure it'd make sense for it to be immediately part of postgis, rather than a separate module (as most FWD are).

[robe]

not to my knowledge. I would like it to be part of postgis. Well as a separate extension similar to postgis_topology and postgis_tiger_geocoder that people can choose to or not to install. I figure the biggest group of users for it will already have postgis installed so why package separately

[robe]

Are you planning to have write support?

[strk]

No write support planned initially. The reason for a separate repository would mainly be to be able to have a faster release cycle.

[robe]

okay got it or slower release cycle so along the lines of point_cloud.

For first version makes sense. I guess we can always decide later to bring it back in.

[strk]

I found this project which may make implementation of an ogr2ogr (or generally GDAL) FDW easier: ​http://multicorn.org

It basically makes you do that in python…

[robe]

I saw that but couldn't get the darn thing to work on windows . Perhaps I didn't try hard enough.

[strk]

I tried a bit harder → ​https://github.com/Kozea/Multicorn/pull/69

[robe]

I knew someone would step up to the plate to do this. Thanks pramsey. I'll be screaming if this doesn't compile on windows

​https://github.com/pramsey/pgsql-ogr-fdw

[pramsey]

This really isn't a postgis concern, FDW's might work w/ postgis, but postgis doesn't have to do anything to make it happen.