[postgis-devel] Registering geometry columns

Chris Hodgson chodgson at refractions.net
Fri May 29 10:21:30 PDT 2009


This kinda gets back to the typmod and "geometry_columns as a view" model...

I think those functions would be great, however to be as "automatic" as 
you are suggesting (just tell it the table and optionally the column) it 
would have to go through your entire table and check SRIDs, geometry 
types, and dimensionality. If your table is empty it would have to 
default to something - perhaps the most friendly, srid=0; type=geometry; 
dims=3... even with the smart scanning you end up with questions like, 
hmm, this columns has lines and multi-lines, should it be specified as a 
multi-line or a geometry column? And just because it only has points now 
doesn't mean it isn't meant to hold other stuff later. AND it could take 
a LONG time.

I guess what I'm saying is, you probably need  functions that let you 
specify any/all of the possible parameters, at which point you might as 
well just insert the row into geometry columns yourself. Any details 
that are hidden or "automagic" in the simpler interfaces could 
potentially come back to bite the user; they should probably be made 
aware of them.

Perhaps the simplest thing would just be to set reasonable defaults on 
the geometry_columns table - the ones I suggested above maybe... then 
inserting into that table could possibly be a bit easier. I'm not 
against adding the functions though, I just think that if you add them, 
you probably need to add all variations, allowing the user to provide 
whichever set of parameters they want to set and letting the others be 
defaulted or automagic (maybe even a switch to specify which of those 
two methods). That just turns out to be a lot of functions.

Chris

Kevin Neufeld wrote:
> Thinking about the recent question on users, I think Piotr was just 
> confused about the functionality of AddGeometryColumn.  I think he was 
> looking for something that would simply register (or add) his view 
> with geometry_columns ... which got me thinking that there really 
> isn't a clear way for users to register/deregister their tables 
> tables/views with PostGIS.
>
> Sure we have DropGeometryColumn and friends, but these will actually 
> drop the geometry column or table ... not just remove a row or two 
> from the geometry_columns table.
>
> If a user wants to register a view with PostGIS, do they really need 
> to know the internal make up of geometry_columns and manually insert 
> and delete rows from the PostGIS metadata?
>
> Populate_Geometry_Columns(oid) that I wrote a while ago does abstract 
> the registering bit for either tables or views, but there is nothing 
> available to deregister a table or view.
>
>
> Would it make sense to add a few new management functions to PostGIS?
> RegisterRelation(oid)
> RegisterColumn(rel oid, column oid)
> DeRegisterRelation(oid)     or UnRegisterRelation
> DeRegisterColumn(rel oid, column oid)
>
>
> Well, those could be the implementation functions that we can wrap 
> with any number of possible APIs...
> RegisterTable(tablename text)
> RegisterTable(schema text, tablename text)
> RegisterView(tablename text)
> RegisterView(schema text, tablename text)
> RegisterGeometryColumn(relname text, columnname text)
> RegisterGeometryColumn(schemaname text, relname text, columnname text)
> DeRegister...
>
>
> Am I thinking too ESRI-ish?  PostGIS is supposed to be easy to use.  
> Does this make thing more clear or does it muddy the waters?
>
> -- Kevin
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel




More information about the postgis-devel mailing list