[postgis-devel] Re: [postgis-users] create tables smarter

[Stephen Frost]

* Tom Lane (tgl at sss.pgh.pa.us) wrote:
> "Paul Ramsey" <pramsey at cleverelephant.ca> writes:
> > Could make support for srid values tricky, to say the least...
> > currently it looks like we can do it, but it would requires some
> > constraining of spatial_ref_sys.

Right, I brought up that issue when the feature was being discussed on
hackers.  At around the same time I asked what the max SRID allowed was
on the PostGIS lists, but I don't recall getting an answer.  (also, it
was me at PGCon, hi Frank!)

> The argument that carried the day for implementing it like that was
> that the stored typmod could just be an index into a table, lookup
> key in a catalog, etc.  So in principle you can associate as much
> data as you want with any column.

This is true, but having a seperate table to handle it, where the values
stored in the system catalog are essentially meaningless across
installs, is kind of ugly.  I'm much more in favor of encoding the data
into the integer.  For some reason, I had thought it was a 2-byte
integer but the documentation appears to claim it's 'integer', which is
a full 4-bytes.

My suggestion, assuming 4 bytes, would be:

Negative: 1 bit
COORD_DIMENSION: 2 bits
TYPE: 6 bits
SRID: 23 bits

That allows for 4 coordinate dimensions (only 3 currently exist), 64
types (only 15? or so now), and over 8M SRIDs.  If we think that SRIDs
won't go over 1M, we could give it only 20 bits and keep the other 3
bits for 'future expansion'.

I don't see this as being particularly difficult to implement...  If
there's agreement on this approach then I'd be happy to write the C code
necessary.  Is there a preference on the structure of the typmod values,
or is Frank's suggestion of:

GEOMETRY(<dimension>,<srid>,<type>)

acceptable?  The other question that crops up in my mind is, what do we
want to do about the current situation where data will be dumped out
with just 'geometry' as the column?

	Thanks!

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080604/ec2bc188/attachment.sig>