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 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
