Print This Post

Why we need features

While the rise of neo-geography, and in particular Google Earth, has had numerous benefits, it has also undermined many people’s understanding of feature types and why we need them. Having spent some time recently wrestling with DGN files, I was reminded rather strongly of how important features are, and just why we need them.

Just so that there is no confusion, let me start with an obvious definition. A feature (or feature type) is a model of some entity in the real world. It can be quite abstract or quite concrete. It usually has an associated list of properties, which are defined by the feature type or feature schema. A feature type implies a controlled vocabulary, meaning an agreed to list of terms, with specific meanings, and usually with a specific list of properties. Often, features have a geometric location or extent, in which case we would refer to them as geospatial features.

A KML Placemark, regardless of whether it has Point, LineString, or Polygon geometry, is in general NOT a feature. It is a piece of geometry – a polygon, for example – to which may be attached a label, and possibly other attributes. It has no defined type, as such, and asking “find me all of the roads within 50 km of a selected road” is not a well-defined question.

A ShapeFile can imply a feature through the .dbf Entity Type, although this is much abused, and cannot generally be relied upon.

DGN files, as we have already noted, are without features, and simply provide geometric elements with annotation (labels) and possibly additional attributes. It is important to understand that the presence of annotation does not a feature type make, since it simply attaches text to the geometry instance.

So… if so many popular encodings don’t use features, why do we need them?

If you are only doing map or drawing visualization, you very often do NOT need them, or you only need a much weaker version, what one might call a map, drawing, or image feature, meaning “something I can see on this map”. Placemarks are a perfect example of this notion of a “map feature”. This is not, however, what is meant by “feature” in this article. Placemarks are location centric, not feature or object centric.

Without features, almost any kind of computation on geometric objects (whether designed or natural) is somewhere between extremely difficult and impossible. Think about how you would compute (without features) such things as:

  1. The distance that something is from a road.
  2. The distance from something to the nearest runway.
  3. The area of a user-specified polygon that is within an airport zoning surface.

The computational software simply cannot “locate” the object in question if it does not know what it is. Computations that depend on the properties of the object (feature) are, of course, equally impossible.

Without features, lots of “vanilla” queries are completely impossible. “Find all houses within 10 meters of a given road” as just one trivial example.

Without features, any kind of geo-demographic analysis is also completely impossible. Imagine trying to compute the best location for a store or a bank branch (or your next house) without being able to refer to kinds of things, and kinds of value distributions?  All of this requires features.

Without features, how could one perform any type of simulation?  How would you simulate things like traffic flows? building heat loss? urban heat islands?

Not only are features (feature types) essential, but it does not take too much introspection to see that standard feature types are also required. Since none of us live “on an island” – well, actually, many of us do! – we need to share information with one another. The rapid transit line goes to an airport. Power for the transit line comes from a hydroelectric company. Water for the airport comes from the local community water supply. Everything is connected. To analyse and engineer any of these systems, we need to, indeed we must, share information – and that is impossible without features and, increasingly, without standard feature models.

The route to standard feature models (e.g. agreement on a classification scheme for feature types, and possibly attributes associated with each type) often starts with a standard means of encoding feature types and feature instances. One key standard in this respect is GML (Geography Markup Language), which uses XML Schema to define application-specific vocabularies, vocabularies that can then be used to test instances of these vocabularies for conformance (“Is this really a road?”).

GML has given rise to a number of languages which define standard feature types for particular domains, and we can anticipate more of the same in the future. These languages include things like CityGML, IndoorML, GeoSciML, and AIXM, to name only a few.

I believe we have just scratched the surface in the area of standard features and feature sharing.