MI SDTS format - Dragon Slayers Wanted (fwd)

[Rich Shepard]

On Thu, 16 Dec 1999, Michel Wurtz - ENGEES/CEREG wrote:

> ... this kind of data exchange format must take in account every little
> trick of every proprietary format, so it becomes a huge and unimplementable
> mess that is of course not widely used (high price and complexity of
> available implementations). 

Michel,

  I followed the development of SDTS for the first few years, then gave up
the effort. However, I believe the problem with it is less trying to
accommodate every proprietary data format, and more trying to be a "one size
fits all" data store.

  The fundamental idea of SDTS was (is?) that it should hold every different
type of spatial data produced or used by US government agencies. Not just
natural world data, but engineered/built data, too. So, here's a data
structure which will hold geographic objects, their locatations and their
attributes for airports, dams, highways, office buildings, census data about
people and soils, vegetation, rivers and species distributions. That's like
having one suit of clothes for every occasion; it just can't be easily done.

  Then, just to make the situation more obtuse, pick a complex, binary
format for everything with multiple headers for each datum type, a complex
API, and poorly written instructions. Finally, change things every now and
then. Then release it as the only format for all spatial data. Ugh!

> Besides, I think the real problem with Grass vector format is the lack of
> a good database interface for storing and managing attributes data.

  That's the problem for raster data, too. For example, cells could have
attributes for soil, depth-to-bedrock, slope, vegetation, aspect,
erodability, and so on. In my opinion, a GIS cannot do meaningful analyses
or modeling without a solid, relational database in which to store
attributes. Mapping, yes; spatial analyses/modeling, no.
 
> My only problem is "how to have a better attribute support than to spread
> all of them in a lot of cat files ?".  Gdabse, MySQL or Postgress : what
> is the best for Grass community ? Is there an "official" answer from
> Baylor people ?

  Let me go out on a limb, here: PostgreSQL. It has native, graphic data
types (and the 8K per tuple limit will be greatly increased in version 7),
had a working interface to GRASS in earler versions of both, and has a team
in Italy working on upgrading that interface.

  Without provoking a flame war on which dbms is "best", I am strongly
supportive of "officially" supporting postgres. There are a number of
reasons, but that's not relevant here and now. For what it's worth, I need
that GRASS/postgres interface before I can move my projects to GRASS. It's
critical for the work we want to do.
 
  I'm still available to work on that interface.

Rich
  
Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)         
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com