[postgis-devel] Registering geometry columns

Kevin Neufeld kneufeld at refractions.net
Fri May 29 10:50:10 PDT 2009


Yes, this definitely gets back to the typmod discussion which would be *very* nice to have ... if it would work as 
advertised.

Ok. then maybe for now I'll just extend Populate_Geometry_Columns to work on an individual geometry column (it currently 
works over the entire database or individual table/view).

What about renaming it to RegisterGeometryColumns?

-- Kevin

Chris Hodgson wrote:
> 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
> 
> _______________________________________________
> 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