[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