PostGIS plugin: avoid need for geometry_columns if 'geometry_field' and 'srid' is supplied #376

Closed
artemp opened this Issue Oct 11, 2011 · 5 comments

Projects

None yet

1 participant

@artemp
Mapnik member

No description provided.

@artemp
Mapnik member

[springmeyer] Currently the postgis driver queries the geometry_columns to obtain the geometry field name, the srid, and the geometry type (Only the geometry field and srid are currently used). In various cases it is advantageous to be able to skip this need for querying the geometry_columns, e.g.:

  • Views or other tables which do not have a geometry_columns record.
  • Complex sub queries or joins where the geometry data's representation changes.

Doing this requires that the user supply the 'geometry_field', which is already an option but is only currently used to differentiate between two geometry_column records. Instead this value can be assumed to be the geometry field for all subsequent queries, such as the queries done by the driver to collect attributes or calculate the extent.

Also required is the 'srid' which could be manually supplied or fetched via the EWKT of the geometry field (for geometry types in PostGIS that are EWKT).

@artemp
Mapnik member

[springmeyer] Notably this patch changes the internal usage and meaning of the 'geometry_field' parameter. I'm not sure this is the best/optimal route but it gets closer to the potential features I have in mind. This patch should be looked at in relation to #260.

@artemp
Mapnik member

[rcoup] My revised patch:

  • eliminates some repetition of code
  • finds the first non-null geometry to extract srid from if we're querying the actual data table
  • uses the table schema where appropriate
  • allows SRID=-1 to ignore all the projection info and not do any transforms
@artemp
Mapnik member

[springmeyer] Excellent - thanks!. I removed my previous usage of 'boost::algorithm::to_lower_copy' because we should preserve case in the original query.

applied in r1300

@artemp
Mapnik member

[springmeyer] note: this may address issues related to #260, #296, and #426

@artemp artemp closed this Oct 11, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment