[OSGeo-Discuss] Documenting GIS Data Models (Again): Using DXF

Wed Sep 9 15:29:15 PDT 2009

Rupert Essinger designed a visual GIS workflow language in 1991.
http://www.ncgia.ucsb.edu/Publications/Tech_Reports/91/91-6.pdf  

Max Egenhofer designed an entire Direct manipulation UI around Map Algebra.
http://www.spatial.maine.edu/~max/MapAlgebraSurvey.pdf

Both might be inspiring to someone wishing to have a formal framework for
documenting GIS workflow in a simple and intuitive way.

I'm still unclear on what type of GIS data models the original poster wants
to document as Smallworld, ArcGIS, GRASS, and others all have quite
different approaches to modeling.

If it's OO data, etc then UML class diagrams work great and don't need to be
heavy.  In software dev there are many tools that keep the data models in
sync with the code, there is no reason why the same thing couldn't be
created for GIS data modeling.  The diagrams could be GIS independent, with
underlying drivers to read/write data models for particular GIS packages.

If it is a data model, then there are already tools for keeping an
Entity-Relationship Model (ERM) in sync with the data table.  Geometry is
just another data type in the Simple Features view of the world.

Craig

Geospatial Software Architect

Spatial Minds, LLC <http://spatialminds.com/> 

From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Brian Russo
Sent: Wednesday, September 09, 2009 2:49 PM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] Documenting GIS Data Models (Again): Using DXF

I think it's an interesting problem to solve (Sharing gis models/processes),
but...

* Way too heavyweight for us, I don't have time/interest to build & maintain
sheets of DXFs manually

* Of little practical use for us since our processes typically grow pretty
organically with small meetings and whiteboards/stickies, eventually we are
going to stop maintaining these 'heavy' model diagrams.

* Probably more useful for very large teams defining massive workflows with
well-defined requirements/outputs, but I don't really work on those types of
problems often (nor personally know many that really do anymore - and they'd
probably already have some dialect of UML or ERM)

* Can't easily convert those DXFs into GDB/DB schemas or into the processes
themselves, etc, so hence little use at the tech level

It might be more useful to define a simple standardized set of symbols that
handles 80% of what we do, and then for more complex processes just lets you
name it, treat them like blackboxes and just annotate them or something.

Personally I would just probably use simple data flow & entity-relationship
diagrams. If there was a simple system that modelled common spatial analysis
processes via symbols then I might be interested in that.

I'm skeptical on the real world utility of building/maintaining large sets
of diagrams that A) Don't fit into the business process generation/capture
processes and B) Don't easily convert into the actual code/schemas
underlying.

Perhaps figure out what the problem you're really trying to solve is. I.e.
What am I trying to achieve via sharing models?

- bri

On Wed, Sep 9, 2009 at 9:48 AM, Landon Blake <lblake at ksninc.com> wrote:

I posted a few weeks back I posted about possible ways to document and share
GIS data models. I decided to move forward with a graphical approach. 

I started building diagrams to document my GIS data model for the Public
Land Survey System in the United States. I am drawing these diagrams in a
CAD program. When I get things ironed out I hope to release the following
items to the GIS community:

-          My completed GIS data model in DXF format that can be used as an
example or template for other models.

-          A set of CAD "blocks" that can be used to build similar diagrams.

If I like how things come together with the diagrams, I might try converting
the diagrams to SVG. The diagrams would be much prettier in SVG, but I am
quicker with CAD than I am with Inkscape, and I want to get a prototype
completed quickly.

This will make a lot more sense when you get to see the example diagrams.

I welcome any collaboration on this effort. If there is interest, I could
move this discussion to the Standards mailing list. It would be great to get
input from interested parties now, while the diagrams are still taking
shape.

Landon

Warning:
Information provided via electronic media is not guaranteed against defects
including translation and transmission errors. If the reader is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this information in error, please notify the sender
immediately.

_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20090909/a508bec3/attachment-0002.html>