[postgis-users] Table w/existing geometry column (withoutAddGeometryColumn), SRID?

[Paragon Corporation]

Stefan,

Let me try to address some of your questions/comments:

To summarize, I think there are some "best practices" to be changed as well
as some quick fixes and open issues regarding metadata and SRID.
Let's begin with metadata (public.geometry_columns table):

>  * Quick fix: Document probe_geometry_columns()
Kevin has done this for 1.3.4 - it was already done for 1.4.  Actually 1.4
is probably going to be a better documentation source than 1.3.4 since we
are putting all our efforts into that - particularly the new PostGIS
reference section.  For the most part all the functions in 1.3.4 are in 1.4
and 1.4 hasn't released any new functions yet to my knowledge that is not in
1.3.4.  Even if it did, we have tried to explicitly state the version a
function came into existence.
http://postgis.refractions.net/documentation/manual-svn/ch07.html


> * "Best practice" (to be discussed and probably changed): I think that the
usual/"best" way to define a geometry attribute is *not* >  through
AddGeometryColumn but to create it with all attributes and possibly (at
most) one attribute of type GEOMETRY).

> The current solution managing SRID information on two places is
> suboptimal: Why don't we define a view called 'geometry_columns' to be
compliant with OGC and e.g. MapServer? Stored procedures > could be
triggeres if needed.

AddGeometryColumn currently simply creates a geometry column and puts in
constraints on the table to ensure only goemetries of that type will be put
in that field and then logs it to geometry_columns table.  This is needed
beause there is no easy way with older versions of PostgreSQL to stuff in
more attribute info in the geometry type.  There are talks for in future to
do this taking advantage of 8.3+ feature to store additional info for custom
data types and then making a view st_geometry_columns against this
information.

Refere to the create tables smarter thread on postgis-dev
http://postgis.refractions.net/pipermail/postgis-devel/2008-June/thread.html
#3080



> If this is not possible, best practice should be to issue
'populate_geometry_columns' as a postprocessing step once after the table >
has been created.

> Quick fix: Integrate and document populate_geometry_columns().
I like this idea.


Regarding the management of SRIDs:

> * You wrote: "There aren't any functions in PostGIS that actually use the
values stored in the geometry_columns table. 
> This  includes coordinate transformation."
>  Does this mean, they use the table/attribute constraint values or just
some mandatory parameters?

No.  Each geometry actually has metadata that denotes its SRID and type so
it just looks at the raw geometry.  Conceivably you can have a table with a
mixed bag of geometry types.  I actually have that in one of my projects
(well I segregate them by having them in an inheritance hierarchy and I
think others do similar things.    


>  Decide whether to keep '-1' as default in PostGIS, or to change it to '0'
(or NULL?) as SQL/MM seems to propose.
Paul really really wants to change to 0. The question is how much code will
that break?

Hope that helps,
Regina