Table of Contents
- How to Evaulate
Geographic Information Systems have an interesting problem domain, much like with programming GIS Hacks are involved in modeling the real world.
- Programmers model with Software (and use abstractions like Object and Class).
- Geographers model with Maps (and use abstractions like Feature and FeatureType).
There is more then one way to do it, programers used to use procedures, geographers used to use a pen and paper. Lets get on with it.
Ack - try and stay awake. Nothing is as silly as trying to explain why creating a model is useful. Why create a model when you could solve a real problem?
Well for starters models are simpler and more flexable.
- A Geographer could model what it would be like to flood a river, this is much more pragmatic then driving around with sticks of dynamite and blowing up a few dikes (although perhaps not as much fun). Hacking models is easier then hacking reality.
- A programmer can model code (using UML diagrams and such), hacking the model is often a lot quicker then hacking the code.
One can also view "proper" Object-Oriented programming as constructing a model of a problem space in the real world - and then using it to solve actual problems. There is even a branch of practice called Model Driven Development & Domain Driven Design to try and steer us back in the direction of OO prinicples.
What to we want (aka what is our task) - Geographic Markup Language:
- GML3 - this is the "mandate" mentioned at an IRC meeting a couple of months ago.
- Programers would use UML2 these days (right?)
Here are some of the constructs in GML that we need to ensure we handle well:
- Feature - something that can be drawn on a map
- Programers would call these objects (or instances if that makes you happy)
- FeatureType - kind of thing on a map.
- Programmers would call these classes
- a bunch of features, can also be considered a "Feature" (Cause you can draw it on a map)
- Programers would consider this a data structure
- id - formally FID or "FeatureID"
- used to unqiuely identify the Feature, the real world object
These are informal working definitions, for a formal definition consult a specification.
The exact requiremetns are outlined here:
- complex type support
- subset of geometry types
There is some discussion of references and dealing multiple feature collections and feature references.
The XPath view of a document is limited to the following:
To support this model we do not need the full set of validation constructs requried for GML3 (such as choice, restrictions or even multiplicity).
Node breakdown of example:
- xml-stylesheet type="application/xml" href="sco.xsl"
- gml:boundedBy: Envelope
- sco:sitename: BALRANALD WEIR
- sco:determineand_description: 16/JAN/94
- sco:result: Turbidity
- sco:determineand_description: 24/JAN/94
- sco:result: Turbidity
- sco:location: Point( 22, 134.5399658, EPSG:4283 )
- sco:nearestSlimePit: Point( 22.1,143.53399658, EPSG:4283 )
- sco:sitename: RWWQ004
- gml:name: My Boreholes
Points of interest:
- Root node is not the same as the root element
- Root node contains the entire document including the xml-stylesheet (xmlns and xmlns:prefix are not covered though)
Similar to unix shell:
- Page 67 for Feature
- Page 68 & 528 for FeatureCollection
- Page 530 for "Annex E UML-to-GML Application Schema Encoding Rules"
GML3 includes a more complicated Geometry model then supported by JTS. Higher order geometries (like surface) are supported in addition to curves and topologies.
GML2 & GML3