Opened 8 years ago

Closed 8 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: trunk
Keywords: Cc:

Description

Description

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.

References

Helpful (hopefully) web links...

Attachments (2)

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

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by bnordgren

Attachment: libraries.png added

comment:1 Changed 8 years ago by pracine

Version: 1.5.Xtrunk

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

comment:2 Changed 8 years ago by bnordgren

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 Changed 8 years ago by pracine

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 Changed 8 years ago by bnordgren

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 Changed 8 years ago by bnordgren

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.

Changed 8 years ago by bnordgren

Attachment: libraries-option3.png added

comment:6 Changed 8 years ago by bnordgren

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 Changed 8 years ago by strk

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.