Opened 13 years ago

Closed 12 years ago

#1133 closed task (fixed)

Figure out and approve library dependency strategy.

Reported by: bnordgren Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc:



Currently, the "postgis" and "raster" libraries are in parallel, having no dependency relationship between them. Both libraries depend on liblwgeom for common code, but liblwgeom does not contain any postgresql-aware code (e.g., memory context, etc.) There is no place, therefore, for common code which needs to be postgresql aware.

Lack of such a mechanism is blocking #1053 and #1058, which attempt to implement the dependency represented by the dashed line in the following figure:

As I see it, there are four candidate solutions:

  1. Duplicate the common code in postgis/ and raster/ (ick)
  2. Figure out how to correctly make one shared library depend on another, when the linking happens before the first shared library is installed. (e.g., shared library is moved after something links against it.)
  3. Create a new static library which contains common code that is postgresql-aware.
  4. Make libpostgis and libraster be static, and create one merged shared library containing both of them.


Helpful (hopefully) web links…

Attachments (2)

libraries.png (5.6 KB ) - added by bnordgren 13 years ago.
libraries-option3.png (9.0 KB ) - added by bnordgren 13 years ago.

Download all attachments as: .zip

Change History (9)

by bnordgren, 13 years ago

Attachment: libraries.png added

comment:1 by pracine, 13 years ago

Version: 1.5.Xtrunk

Could you describe why you need such a dependency? Which functionality do you need from libpostgis?

comment:2 by bnordgren, 13 years ago

The immediate need is described at length on #1058, even though it applies more directly to #1053.

In essence, I want access to the cache of projections. The code uses postgresql memory context stuff and queries the spatial_ref_sys table. Hence, it cannot go into liblwgeom, as that is not supposed to be tied to postgresql.

comment:3 by pracine, 13 years ago

Is it because you want to reproject some geometry or raster on the fly to the srid of another geometry or raster in order to do some operation implying both?

comment:4 by bnordgren, 13 years ago

Essentially. But without actually resampling. GDAL has an "image to image" transformer, which calculates the (i,j) index of one image using the (i,j) index of a second image. This needs the projections (SRS) of the two images.

However, once a strategy is figured out, it has much wider applicability than this first application. Raster suddenly has access to all Postgis functionality at the C level.

comment:5 by bnordgren, 13 years ago

Tentatively adopting strategy three, above. See the patch on #1053 for the creation of a libcommon static library which can be used by code in both raster and postgis.

by bnordgren, 13 years ago

Attachment: libraries-option3.png added

comment:6 by bnordgren, 13 years ago

Dependencies suggested by option 3 are illustrated by

Note liblwgeom is the only library which does not depend on one of the others.

comment:7 by strk, 12 years ago

Resolution: fixed
Status: newclosed

I think we're pretty much settled about libs dependencies for the time being.

Note: See TracTickets for help on using tickets.