> In PostGIS, the AddGeometryColumn() function needs to be run separately > after the create table. It adds the geometry field to the table, adds > its definition (projection, geometry type, dimensions) to the > 'geometry_columns' table, creates a number of constraints, etc.
Thanks, Rob, for the excellent summary; below, I'll give a bit more detail. > GIS guys, any particular reasons for the approach you took? -- laziness? > economy? "it works, dammit!"? technical reason against the above? Malcolm, the fact that AddGeometryColumn() must be called _after_ the CREATE TABLE statement is not a choice of the GIS branch. As I stated before, geometry column creation with the AddGeometryColumn() stored procedure is part of the OpenGIS standard. [1] When figuring out where to place the check for the _post_create_sql() function, I did not randomly choose a function in management.py. My goals were to (1) accomplish geometry column creation in the aforementioned manner, (2) minimize patches outside of the contrib directory, and (3) use the existing API to the fullest extent possible. I believe this solution, a three-line patch to an existing post-initialization SQL function, satisfies these criteria. -Justin [1] See Open GIS Consortium, Inc., OpenGIS Simple Feature Specification For SQL Rev. 1.1, Document 99-049 (May 5, 1999), at 2-38 (s. 2.3.8, Geometry Values and Spatial Reference Systems, pg. 40), available at http://www.opengis.org/docs/99-049.pdf. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
