Layers and Holism

This recent article (“Layered GeoInt“) describes how “layers” will be used to achieve “holism”. I really feel the concept of layers often stands in the way of holistic understanding. For example, say you’ve deployed something to Arcmap users and they see something in the real world they want to put onto the map. There’s a good chance what they see does not fit neatly into a single layer. So what do they do? Odds are they end up marking the map up with graphics (IElements). If you’ve been a supportive programmer for these users, maybe you’ve provided tools to let them hang attributes off these elements as xml strings (in IElementProperties.CustomProperty).

Lets suppose you developed a mechanism to share these elements with the rest of the enterprise. Now what we need is a framework for doing the following to these elements: spatial selection, identify (like the Identify tool), and select by attributes. Basically all the tools that work with FeatureLayers are also needed for these IElements.

I submit that the FeatureLayer concept is really joined at the hip with Codd’s relational model. There’s been a lot written about the shortcomings of the relational model, for example here. Usually the criticism is followed by some sort of proposal for an xml database. What is needed is an ILayer for xml.

In that spirit, I propose a new class, XmlLayer, that would maintain a collection of XmlFeatures. There would be NO rule saying all XmlFeatures in an XmlLayer have to have the same geometrytype, or the same field definitions. This would solve the “feature level metadata” requirement. XSLT would be leveraged for rendering, import, export, etc.

Some concepts, e.g. an electric circuit, are comprised by features that live in different featureclasses. Maybe things like the GeometricNetwork and database Topologies could be expressed to the map as an XMLLayer. That way all the features comprising the circuit would be in on layer.

Certainly there are scalability issues, but those issues exist for managing large collections of IElements too. Maybe some day I’ll give this a try.


4 comments so far

  1. […] The Memory Leak Thoughts on GIS programming yet to be forgotten. « Layers and Holism […]

  2. Dave on

    You could implement this via a custom feature, which had the ability to be any spatial type (ok, maybe just point/line/polygon). It would be an interesting project, but alas, I’m not a C++ guy, and that’s the only way to create a custom feature (that I know of!)



  3. Administrator on

    Hi Dave –

    I’m thinking that since I want to have a mixed bag of features in my layer (where different features would have different fields) then a custom featureclass would still be inappropriate. Even with a custom featureclass, all features would still be required to have the same fields, wouldn’t they?

    In the mean time I’ve looked at the OGC standard for “Feature Collections” … from what I can tell it does not require that all features in the collection have the same fields.

    I also found some research in this area, but got lost in all the greek letters.


  4. Bill Dollins on

    This sort of concept is the same thing that drew me to SDE years ago (version 3.something). With it, you could define a layer that could hold multiple geometry types (but not field definitions). Lo and behold, that did work but none of the client software was able to take advantage of this feature. In MapObjects, ArcView, etc. you had to specify what single geometry type you wanted from your ArcSDE layer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: