[postgis-users] create tables smarter

[Chris Hermansen]

Hi Frank, folks;

This is the kind of thing that would be really great to see:

    * a way of creating geometry that relied on SQL and not on calling
      stored procedures
    * a way of deleting same
    * a system table that held ancilliary information

It bugs me that I can DROP a table and still have a row referring to
that table in geometry_columns.

I also find it kind of perverse that some desktop viewers require a
specific structure in a table containing geometry in order to view it.

Not to sound negative or anything!  Heaven forfend!  It's just that
PostGIS is so much better than having to use a programmatic access like
SDE when I want to use my geometry, that I find it hard to accept that
it hasn't gone that last few centimetres.

Frank Warmerdam wrote:
> Lee Hachadoorian wrote:
>> Andreas,
>>
>> AddGeometryColumn does two things: it adds a column of type geometry,
>> and it adds a row to table geometry_columns.  If I understand what it
>> is you want to do, you can do the SELECT and then add the row to
>> geometry_columns with an INSERT statement:
>
> Folks,
>
> I did a presentation at PGCon and the issue of AddGeometryColumn() being
> necessary to populate the geometry_columns table came up.  Some of the
> postgres techies suggested there has been work so that extension defined
> types could actually take extra arguments when used in the CREATE TABLE
> statement and that this might let us avoid the need to use
> AddGeometryColumn().
>
> ie.
>
> CREATE TABLE ROADS
>   (id   INT,
>    name VARCHAR(255),
>    geom GEOMETRY(<dimension>,<srid>,<type>) )
>
> Then the callback for the GEOMETRY type would take care of extending the
> geometry_columns table, presumably picking up the schema, table and
> column
> name from the context.
>
> In an ideal world, the dimension, srid and type would even show up when
> you describe the table, and would be automatically propagated to new
> tables
> created from a select.
>
> I don't know how hard this is, or if I overestimated how these custom
> type
> definition parsers work but I think it would be an appealing direction of
> development for postgis.
>
> Forgive me if I'm stating something already well understand in the
> postgis
> community.  I'm a bit of a diletante in this world. :-)
>
> Best regards,


-- 
Regards,

Chris Hermansen         mailto:chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue  · Vancouver BC · Canada · V5Z 1E5