Changes between Version 2 and Version 3 of DevWikiSpatialCollectionTutorial


Ignore:
Timestamp:
Sep 16, 2011 9:07:38 PM (8 years ago)
Author:
bnordgren
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DevWikiSpatialCollectionTutorial

    v2 v3  
    165165The salient point here is that `sc_sampling_engine` does not care how the values for each pixel are generated, nor does it care what those values are. It merely asks "What is the value at point '''P'''?" for every grid cell. It doesn't even care what algorithm was used to determine the size, shape, resolution or rotation of the raster.
    166166
     167== Projecting ==
     168
     169Not included in this example is the following implementation of the spatial collection interface:
     170
     171{{{
     172#!C
     173SPATIAL_COLLECTION *
     174sc_create_projection_wrapper(SPATIAL_COLLECTION *wrapped,
     175                                     int32_t desired_srid,
     176                                     projPJ wrapped_proj, projPJ desired_proj );
     177void sc_destroy_projection_wrapper(SPATIAL_COLLECTION *dead);
     178}}}
     179
     180Note again that we write and maintain only ''one'' version of the projection code. Because it is the query point which is projected (and not the base data from which the collection is derived), we need not be concerned with the nature of the base data. Wrap your spatial object with a collection, project the collection, then move on.
     181
     182The constructor shown requires that you pass in a `projPJ` object because it is included in the `liblwgeom` library which does not have access to the `spatial_ref_sys` table in the database. It would be possible (and desirable) to put another constructor in the `libpgcommon` library which could generate a `projPJ` object based on the srid.
     183
    167184== Potential directions ==
    168185