Thanks Brent,
I will be cautious in my approach. The public schema is the place that I
wanted to use to store the geometry attributes, so from your points,
that sounds like the best place. The other schemas contain controlled
(security) information in proprietary data structures so I that was my
reluctance to modify those tables with the necessary geometry functions,
types etc.
Regards
John
Brent Wood wrote:
> On Tue, 13 Jun 2006, John Tregea wrote:
>
>
>> Hi Brent,
>>
>> I will look at postGIS today. I will try and keep the whole GIS
>> functionality as a separate schema to avoid confusing myself, so a
>> postGIS may be exactly what I am looking for.
>>
>>
>
> Ummm... one caution:
>
> The lovely side effect, apart from all the SQL functions to query &
> analyse spatial data in Postgres, is that any table with a
> properly created geometry attribute is automatically available as a GIS
> layer in a GIS map window, using GIS applications like QGIS, mezoGIS, JUMP
> & uDIG (even ArcInfo via the PostGIS SDE), or to a less well integrated
> extent, GRASS. It can also be a layer in a web map server application
> using something like UMN mapserver.
>
> However, not all of these support the concept of schema's, so only tables
> in the public schema may be able to be plotted/mapped.
>
> Also, from a data modelling perspective, a geometry attribute is not
> inherently different to a numeric, int, varchar or text attribute, so
> unless there is some other reason to divide entities with geometries into
> a separate schema frpom those without, I'm not sure it is good practice.
>
>
> Cheers,
>
> Brent
>
>
>
