A physical point in a real world space can sometimes be designated (approximately) by marking the point in question with some kind of marker. You may have seen the bronze monuments for ground control points deployed by national or regional geological survey or mapping organizations. Such an approach is, of course, not possible for points that are in space, under the earth, or the ocean. In fact, in the majority of cases, we can only specify a point by constructing a coordinate reference system and then specifying the coordinates associated to the point through that coordinate reference system. Such a point specification is really only the specification of a point in a model point space that approximates a portion of the physical world.

Let us illustrate this with a simple example. We assume a point space model which is a vector space. Each point is specified by a vector from the origin to the point in question. We then select a basis for the vector space and this, in turn, defines the coordinates to be associated to the point.

The Point O is easily related to the vector OP (the frame F’ defines the point space of interest).  Now given the basis {e₁, e₂, e₃} we can write the vector OP as follows:

OP = a1.e₁ + a2.e₂ + a3.e₃

where (a1, a2, a3) are real numbers.

The numbers a1,a2,a3 are called coordinates and (a1, a2, a3) is called a coordinate tuple.  Note that the tuple is NOT the point P, even if we could estimate the coordinate values exactly (zero error).  The coordinate tuple can ONLY be associated to the point P through the coordinate system, in this case the Frame F.

To make this point even more strongly, consider a vector space which is spanned by the basis “vectors” {1, x, x², x³}.  This is the vector space of polynomials of degree 3.  Given a vector in this point space, i.e. a polynomial of degree <=3 , we can assign coordinate using the basis.  For example, the polynomial 2 + x-x² can be wriiten 2.1 + 1.x -1.x² + 0.x³, hence the coordinates are (2, 1, -1, 0).  Equally clearly, the coordinate tuple (2, 1, -1, 0) is NOT a polynomial.

So… bottom line…  Points are geometric entities that live in a point space (geometric space) that can model some aspect of the real world.  Coordinates (real or complex numbers in most cases) are assigned to a point through the use of a coordinate reference system.

The CBC News article “Vancouver mulls making itself an ‘open city’” provides some background on the motion.

The City of Vancouver published the text of the motion “Open Data, Open Standards and Open Source” on their website, and members of the public were invited to speak at the committee meeting, which was held on Thursday, May 21.

After the vote, which endorsed the principles stated in the motion, CBC News published a second article “City of Vancouver embraces open data, standards and source” to follow up, and the final copy of the motion was published by the City of Vancouver.

A great deal of discussion has taken place in the OGC and ISO TC/211, over the past several years, with respect to coordinate reference systems.  Much of this discussion has been confusing, and many of the ideas discussed are subtle and hard to express.  This has resulted in less generality than one might have liked for abstract specifications such as ISO 19111.  Attempts to apply encodings and models, which depending on these abstract specifications, have subsequently run into trouble as a result.

One of the most poorly understood concepts has been that of datum.  In common parlance, and in land surveying, a datum is a reference point or reference surface.  Sometimes this is also interpreted as the zero point for a measurement, such as the freezing point of water being a datum for a Celsius thermometer.  These definitions, while correct in themselves, provide a poor basis for generalization, and as a result progress on a general treatment for coordinates and coordinate reference systems in OGC and ISO has suffered.

We propose here a notion of datum which we believe provides the required degree of generality and allows the transportation, engineering, physics, and geodesy use cases to be integrated together.

What are coordinates?

The most general way to think of coordinates is to think of a Coordinate Vector Space.  This is set of n-tuples of real numbers (other fields could be used) in which addition of these tuples is defined by component wise addition, and in which multiplication by scalars is defined by component wise multiplication.  The identity element in such a set is (0, 0, … 0) and it is clear that any element (a1, a2, … an) has an additive inverse, namely (-a1, -a2, … -an).  Hence the set of n-tuples forms a vector space which we call the Coordinate Vector Space.  The numbers a1, a2, etc., appearing in these tuples, are coordinates.

Assigning coordinates to points

From the point of view of geometry, points are more primitive than coordinates, and one can talk about points in a geometric set without having any notion of coordinates.  In fact, a point could have multiple coordinate representations.  Under certain assumptions about the geometric set, it does make sense to talk of coordinates, and we can think of coordinate reference systems as enabling the assignment of coordinates to a point.  Note that the geometric set can be quite abstract and need not represent physical space; we could have a set of points where each point is a branch voltage or the concentration of a chemical species.

If we are to talk about assigning coordinates to points, we first have to be clear what set of points we are talking about.  This means making a model of the real world “region” of interest, and then using mathematics to construct coordinates from that model.

If we model our physical “region” as a vector space, meaning the points of the “process” are vectors, then we can assign coordinates to these points simply by choosing a basis {e_1, e_2, … e_n,} for the vector space, as we know, any vector v can be uniquely expressed as  v = a₁.e₁ + a₂.e₂ + … + a_n.e_n, hence the coordinates of the point P (corresponding to the endpoint of the vector v = OP) are (a_1, a_2, … a_n).

We can’t model everything as a vector space

It should be clear that not everything of interest can be modeled as a vector space.  Consider, for example, the set of possible orientations of a rigid body.  Each orientation of the body can be seen as the result of a rotation, so we can assign rotations to orientations.  Think of a partly symmetric body like a fixed wing aircraft.  If we perform two rotations in succession (e.g. 1^st about the longitudinal axis of symmetry and the 2^nd about a normal to this axis) we can easily see that the result of these two rotations can be different (http://farside.ph.utexas.edu/teaching/301/lectures/node100.html).  If the two rotations were then thought of as quantities a and b then this says that a+b is not the same as b+a.  This means that the set of rotations (orientations) does NOT form a vector space, and rotations are NOT vectors, even though such a quantity can be expressed in terms of a well defined magnitude and direction.

If we think about points on the surface of the Earth (which is more or less a ball), we can come to a similar conclusion.  Consider any such point and multiply it by a scale factor other than 1.  One can readily see that the new point will NOT be on the surface of the Earth. Vector spaces require that the set of vectors be closed under multiplication by scalars and clearly this is not the case.

What to do?  What about locally?

Without getting too technical, in many cases it is possible to model a “region” locally as a vector space.  This is the case for orientations of a rigid body, and for positions on the Earth.  When we say that the Earth is not “flat” - and that one cannot flatten the earth without tearing it (you may remember this from grade school) - what we are saying is that a model of the Earth is fundamentally different, as a surface, than a plane (which can be modeled as a vector space).  To address this difference, we use projections to locally map the Earth (model) to a plane.  For example, we may model the Earth as a sphere, put that sphere inside a cylinder, and project points on the sphere to points on the cylinder (e.g. draw rays from the center of the sphere through a point on the Earth to intersect a point on the cylinder).  When we unroll the cylinder, we get a flat representation of the Earth.  It is clear, however, that this model does not include: (1) the poles (these are mapped to the bounding lines), and (2) the points on the line where we broke the cylinder.  The target of the projection is a 2D plane, which CAN be modeled as a vector space and thus allow us to use our scheme above to construct coordinates, but we need more than ONE of these projections to cover the entire Earth - it CANNOT be done with ONE only.  It does, however, mean that the Earth (model) can be modeled locally as a vector space and that, locally, we can assign coordinates (given a projection), and that these coordinates are relative to a choice of basis - e.g.  latitude and longitude.  So in general we must think of coordinates in terms of vector spaces in ALL cases.

So what is a datum?

At the outset of this discussion, we said that a datum in common parlance was a reference surface or zero point.  Now we will introduce a different idea, namely, that the datum is the “space” of points in our model of the real world process.  It is the “space” of points to which we then assign coordinates through the selection of a coordinate reference system.

If you think of the reference surface viewpoint on datums for a moment you can see that it is not really inconsistent with the view presented here.  If we state that a datum for temperature measurement is the freezing point of water, implicit in this statement is the assumption that other temperature values can be represented as points on a line, in effect mapping temperature values into the Real number line which is, of course, a 1D vector space.

Considered in this way, a datum is the “surface” model for the application “region” to which we assign coordinates through the selection of a coordinate reference system.

We can then see that a datum for the positions and orientations of a rigid body is specified by a product of a geometric (affine) space of positions and a space of 3-frames attached at every point of this affine space.  A point in this space consists then of a position point P, and a frame F_P attached at P.

The Geodetic datum case also falls under the same concept.  A geodetic datum is, in effect, an earth model which has been “fit” to the earth by the selection of a model surface (e.g. ellipsoid), and the specification of the model surface parameters (e.g. sphere radius), and sufficient parameters (usually selection of real world points) to enable the 1:1 identification of points on the earth with points in the model.  This “fitted model” is a 2-dimensional manifold, and using this manifold and suitable “projections” we can construct a variety of coordinate systems.

The notion of datum as the point space for our models of the physical world thus serves to unify the treatment of coordinates and coordinate reference systems over a multiplicity of domains.

Read Ron Lake’s article discussing the interconnectedness of global resources, and whether and how geography might impact the economic and political success of nation states.

The full article is available in GeoWorld’s Building the GeoWeb column for April 2009.

Ron Lake talks with VerySpatial - May 2009

All well and good, but why are we doing this at all?  Why were the police districts not defined relative to the actual road segments (not as a drawn overlay), and why is there not an information infrastructure in place that automatically provides the police with the latest road information, thus automatically updating the police districts in the process?  It is the lack of such infrastructures that makes geospatial data integration such a difficult and tedious process.

Of course, you will argue that if the police and the road supplier use the same GIS software, all is good.  Well, of course, this is not really practical since the police may be a national organization, while the road supplier is only a local one.  Furthermore, and for much the same reason, the police and the road supplier have different road models, so the problem exists even if the same vendor software is used.  This is simply not a viable general solution.

Another argument is related to getting started.  How does the police force migrate to this automated infrastructure solution?  To begin with, the police force needs to define the police districts in terms of road and street segments (and possibly other features), and not just as a visual overlay.  This favours having a copy of the road geometry data and an identity management mechanism that enables the district features to be defined by referencing them to the road/street segments.  Most GIS and spatial databases support such mechanisms.  The only missing point, then, is to have the police subscribe to the road segments from a suitable road supplier, which may also require data transformation (e.g. coordinate conversion and schema-based transformation).  These are the functions of the supporting information infrastructure.  Once this is set up, the police agency has no more work to do and automatically remains in synch with the road provider.

If we see data access as really a process of business process integration, then many of the problems associated with ad hoc file transfer or ETL (extract-transform-load), especially those related to data integration, can be eliminated.  Moreover, capture of metadata is much easier to automate since the data is inherently acquired in context.  All of this helps ensure that the data subscriber has the most current, and most accurate, data available for their business processes.

Sometimes things move more slowly than we might hope but, slowly and surely, this view of data integration is taking hold.

Joe Francica, Editor-in-Chief and Vice Publisher of Directions Magazine, recently wrote about his experience in attending the Map World Forum (MWF) in Hyderabad, India. In the article, he quotes from Ron Lake’s talk where Mr. Lake suggested that SDI initiatives should begin at the city level where most of the work of building a spatial data infrastructure resides.

Read the full article at:  http://www.directionsmag.com/article.php?article_id=3042

Download the PDF file to read the full article:
ess_printers_nrcan_gc_ca_20090408_125207 [PDF - 1591 KB]

The essence of the talk went something like this…  Rather than focusing first on national datasets and services, SDI should focus at the urban level, especially on medium to large cities.  The rationale for this approach is simple enough:  cities are where most of us live. Cities consume most of the planet’s energy, and generate most of the pollution and green house gases.  Cities are where we need to deal with questions of overcrowding and water pollution.  Security is, of course, a national, or even international, concern – but when a security event takes place, such as the ones that occurred in Mumbai, Madrid, and London, we must deal with them in a city.  If there are environmental security threats, whether storms or bird flu, we will confront these threats in cities.  Smart energy management is touted as part of the solution to both climate change and energy security, no argument there, but to realize these saving, it is within cities that we will have to act.

Problems such as security, energy management, pollution control, and crime prevention can be partly alleviated through better city design, information re-use, and support for collaboration amongst all of the agencies that interact in city development.  Imagine a world where the mere act of everyone (architects, engineers, contractors, developers, lawyers, citizens) just doing their job led to the ongoing creation and maintenance of a complete “as built” model of the entire city.  Such a model would then be used by architects to plan new buildings, by police and fire departments to enhance public safety, and by ordinary citizens to look at the potential impact of new proposed developments.

In effect, the development of SDI can be likened to the development of other types of information technology including the Internet, databases, and GIS.  If we consider any vertical application (say in the urban context) such as a system for emergency response or urban planning, and thought about how we would develop it say 20 years ago, we would have found that a great deal of the money would have gone into the development of software just to provide a basic network, and messaging and persistence functionality.  Since that time, the IT industry has extracted these components (e.g. databases) out of general software development, and any such solution for these problems would undoubtedly build on things like DBMS, GIS, and IP networks.  Not to do so would, today, be a non starter.  We believe that this also true for the emergence of SDI technology.

If one looks at the various types of vertical applications for urban environments (e.g. crisis management, urban planning, e-Government, homeland security, and so on) it is pretty clear that all of these deal with geographic information (e.g. where are the roads, where are the vehicles, etc.), and almost all involve the integration of data and services across multiple agencies in the government and in the private sector.  Many of these require data to be delivered in real time (i.e. fast enough to contribute to the solution of the problem at hand), need to be event driven, and benefit from varied types of visual presentation including maps, charts, and 3D models.
SDI technology can be seen as providing part of a solution infrastructure not provided by GIS, databases, and the Internet, and their associated client tools.  SDI deals with the secure movement of information (geospatial or otherwise), discovery and access to data processing services (geospatial or otherwise), and collaboration between organizations and individuals.

The choice for implementers is to try and build the SDI part of the solution themselves or to leverage existing SDI frameworks that can provide:

• Unobtrusive connectivity to data sources and services (e.g. databases and applications).
• Data transformations for source/target data differences such as differences in schemas, units of measure, and coordinate systems.
• Secure real time delivery of access to services and data.
• Fine grained delivery of data on a change-only basis.
• Publication/Subscription for both data and services.

You will see that these capabilities deal with a great number of the key requirements for vertical solutions such as urban planning, collaboration, crisis management, and emergency response, and many others.  You will also note that, by refocusing SDI on urban environments, we lose nothing in terms of its application to national level problems of data discovery and data access.

Now, I am sure that someone will raise the objection that, while data and technology are easy to deal with, the real problem is people and organizations.  To a significant degree, this view is correct. As in any IT problem (or any problem at all) the most important and difficult problems to deal with are people problems.  I could not disagree.  Therefore, given that organizational and people issues are paramount, how should this influence the design and selection of SDI technology?

To begin with, we believe that this requires SDI technology to be unobtrusive, meaning that it can be inserted into existing applications and databases with little or no changes to their existing database schemas, user-application interactions, or security.  SDI should simply allow the application or database to benefit from secure delivery of data or data processing services.  The more invisible the SDI, the better it is.

A further implication of the importance of people and organizations is the need to see SDI as supporting business process integration.  One of the difficulties experienced by SDI implementations thus far has been the inability to populate and maintain metadata catalogues.  This is because few people like filling out forms of any kind, and they like it even less if they are not directly connected to the result.  I fill out my taxes because I have to and, in some years, I might even get a refund.

In the business integration approach, a large part of the metadata is a consequence of the business process itself, and thus can be obtained automatically, within the business process itself, and with little or no human interaction.  This minimizes unnecessary and unexplainable actions on the parts of the user, and makes the SDI that much easier to accept.  They basically use the SDI without knowing about it.  Again, the more invisible the SDI, the better it is.

Finally, we would argue that being cognizant of people issues means providing data directly to the user’s application or database, but only the data that they want, and only when they want it (typically when something significant happens).  This means that SDI should function not only on a user query basis (“e.g. find the data and request it”) but also on a publication/subscription basis.  Providers should make known what they have to publish, and subscribers should be able to discover and subscribe to it on a change-only basis. Once an “advertisement” has been posted by the provider, they should be out of the loop.  Once a subscriber creates or modifies their subscription, they should not have to worry about how the data gets to them or what remote service is invoked.  You don’t chart the delivery of your magazine subscription each month do you?

One might think that the adoption of technology and, by extension, technology standards, would be governed by pure rationality, or at least pure rationality moderated to some degree by enlightened commercial interest.  I will argue that, while such considerations do play a role, that role is relatively small compared to the role played by social and cultural factors - the social dynamics.  The technology that we get is not so much the right technology as it is the technology which, at a given point in time, is the most socially acceptable.

Contemporary development of information technology is very much a group process, whether we are talking about open standards such as the OGC or ISO TC/211, open source projects (e.g. OSGEO), or trying to gain the adoption for closed source proprietary technology.  In all cases, group perceptions dictate the final outcome, and this often has only a small amount to do with technical feasibility or capability and a huge amount to do with social and group dynamics.

In the OGC, for example, decisions are to be obtained by consensus.  This generally argues against radical ideas or ideas which substantially change the status quo.  It also argues in favour of ideas that are presented by likeable personalities or by those perceived as having authority, or ideas that are most readily understood.

Consider the Capabilities document interface (GetCapabilities) developed at the OGC.  From a rational IT perspective today, it does not make a great deal of sense.  No tools exist to parse and process capabilities documents, and no “theory” exists that describes how to construct a capabilities document for a new web service, other than to imitate ones that already exist.  When the OGC web services were just getting started, this was a reasonable idea.  The service construct was a new one, and the idea that a service could advertise what it could do was a perfectly sensible one.  At that point in time there were few, if any, web services (I don’t think the term was even used in the OGC) and ideas in the broader web world around Web Interface Description Language (WIDL), an evolution from CORBA IDL, were just getting underway.

The situation today is somewhat different.  Whatever the problems in the evolution of the Web Services Description Language (WSDL) specification (the W3C is captive to the same principles of evolution as the OGC), we now have a situation where WSDL (version 1.1) is supported in a variety of tools, and the creation of usable stubs is generally possible.  At the same time, the OGC capabilities documents have become even more complex, and the gap between OGC web service descriptions and those of the wider IT world has further widened.

Consider, for example, the now venerable Web Map Service (WMS).  To determine the list of map layers advertised by a WMS, one issues the GetCapabilities call and is returned a capabilities document.  One then parses this document to obtain the list of supported map layers.  Would it not make more sense simply to introduce a new operation into the service interface, something like “GetMapLayerList” which, as the name suggests, would return a list of map layers?  This would then appear in the WSDL description of the interface, and hence be usable by general web service tools.

The same situation applies to the Web Feature Service (WFS).  To obtain the schema description for a given feature type requires that one issue first a GetCapabilities request, then parse out the list of feature type names supported, then issue a DescribeFeatureType request for the selected feature type name or names.  It is strange that the first part (the list of feature type names) is part of the capabilities, while the request for the schema information is a separate operation.  This makes perfect sense when you realize that the WFS was developed after the WMS and used the latter as its point of departure.  Of course it would be entirely more sensible if the WFS (like the WMS) had provided a GetFeatureTypeNameList operation instead of burying this in the capabilities document.

At this point in time, such things are difficult to change.  Vested interests in the status quo will argue to keep things as they are or, even worse, do things like enabling parameterized requests for part of the capabilities document, thus completely missing the point about alignment with tools in the broader IT world.

The importance of social and group dynamics is even greater in the world of so called “neo-geography”, with some adherents of this completely undefined “discipline” labeling their non-adherents as “paleo-geographers” - whatever that might mean.  It harkens back to the days of believers and heretics, and I expect that much of the same social dynamic is at work.  It is no accident that the IT world labels certain types of debates as “religious”.  What is “neo-geography”?  At best, it amounts to looking at geo-processing from a new perspective and championing things like user-created data (although, to some degree, data is always user-created).  At worst, it adopts the notion that whatever idea is most widely held is likely to be correct - even if it is factually, and even mathematically, incorrect.  I have had innumerable discussions where neo-geographers want to wish away coordinate systems (”we don’t need polar projection”), or think that one coordinate system can suffice for the entire earth, or that polygons don’t need holes, and so on.  None of these considerations are based on reasoned argument, but rather on an appeal to “what the common man may understand”.  Similar arguments are raised to attempt to eliminate any level of complexity, in spite of the fact that the common man does not understand the operation of his watch or his telephone or his automobile.  Confusing internal complexity with external ease-of-use is a common outgrowth of these viewpoints.

None of this is to argue that groups cannot create useful advances in technology and in technology standards.  It is, rather, to try and make each of us aware of the foundation for the arguments that we are making.  Perhaps, had others done so in the past, Galileo would not have been declared to be guilty of heresy!