[postgis] GEOMETRY_COLUMNS table

[Kurt Ackermann]

The following is my reply to the question posed by Paul and then his
response to it. (Not originally posted to list.)

Thanks Paul.

Kurt

--- Paul Ramsey <pramsey at refractions.net> wrote:

> I would be interested in people's opinions. Once you start down this
> road, the complexities never end. Prefered fill and outline colors,
> scale preferences, full descriptive names. Is the storage of this
> information necessarily a part of the backend data store, or should
> it
> be part of the rendering application solely? The only benefit to
> pushing
> it back into the database is that applications can then share
> rendering
> specifications: to make my roads blue on both desktop and web apps, I
> change it once in the database. 
> > My tendency is to think that rendering preferences should be stored
> in a
> manner specific to the rendering tool. If the rendering tool is
> specific
> to PostGIS, then fine, store the specs table in the postgresql
> database,
> but not as a part of GEOMETRY_COLUMNS. Other thoughts?


--- Kurt Ackermann wrote:

Although in general I agree with the basic idea behind your opinion
that rendering should be left to the application, I do feel there may
be instances when it would be, at the least, convenient to have the
information stored in the database.

In our company we use a variety of GIS applications (particularly
MapInfo, ArcView, and ArcInfo, but a few others also by times) and to
me the idea of having display and similar such information stored in
the database does have appeal. We often do work that has been
subcontracted to us by a large company with connections to government
ministries and agencies, etc. The basic standards covering the data may
be the same, but each company tends to have its own preferences with
regard to software, and we must often create data that is of the same
"type" but in different formats. Upon occasion this data may be
"recycled" but at the same time desired in a different format. In these
cases, having the display information contained within the database
would likely save a lot of the hassle involved in going through the
process of assigning colours/patterns/styles from inside an
application. This would be especially true in the case of datasets such
as complex vegetation layers, where a myriad of combinations may be
required (ie. stipulated). In my opinion, having these characteristics
stored in the database would not only ease porting to a different
application, but also allow the inclusion (in one package, so to speak)
of important secondary information when archiving.

Kurt Ackermann
Regional Science Institute
Sapporo, Japan

--- Paul Ramsey replied:

Your points are one side of the argument. My personal tendency is to
the other side: once we start putting display logic into the database
we run inevitably into a morass of unfixable details and conflicts. I
had not even thought about categorical theming as something one would
store, but the data model for that alone is non-trivial.
Now add in the possibility of data shifting underneath the theme (new
values are added which are not categorized), does that mean the
database should enforce referential integrity with the display theme?
Fundamentally, is this a place where effort in the spatial database
field should be placed? My feeling is no, that abstractions higher up
the value chain should deal with relating abstract data sources to
rendering preferences and styles. 

Paul



______________________________________________________________________ 
File your taxes online! http://taxes.yahoo.ca

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/