[postgis-users] Issue with the geometry field in postgresql tables

[Paul Ramsey]

Sure, just drop the constraints and go crazy.  Mixed geometry types  
should not present any troubles at all, for either the functions or  
the indexes.  Mixed SRIDs will break all kinds of things unless you  
wrap everything in a transform() to force everything into a common  
plane at operation time.  Indexing in particular will not work on  
mixed SRIDs.

P

On 18-Dec-06, at 7:13 AM, Vincent J. Troisi wrote:

> We want to conduct searches on a table containing a variety of
> geometry types. The search returns records that satisfy the
> tests for intersection, containment, and overlap. Our DBA
> has discovered an issue with using the geometry field; the
> field can contain only one geometry definition.
>
> Does anyone have an approach that we can use to query a
> spatial field (e.g., geometry) in a table using the standard
> functions available in postgis? See below...
>
>
>>
>> Here is the write up for the issue I found out with postGIS  
>> yesterday.  The way postgresql handles the geometry column is that  
>> you have specify a spatial reference system ID everytime a  
>> geometry column is created.  It then uses the spatial reference ID  
>> to enforce the rule that every geometry entered into that column  
>> matches the spatial reference ID or it will give you an error.  It  
>> also allows postGIS to perform convertion on the projections.   
>> This causes the problem because we need to be able to assign  
>> different spatial reference ID to different datasets.  With a  
>> fixed spatial reference ID assigned to the column, it prevents us  
>> from using that the column for datasets that have different  
>> spatial reference IDs.
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users