Philip Sargent
Space Applications Institute,
European
Commission JRC,
Ispra, Italy.
21 November 1998
It has become possible to envisage that someone, somewhere, will build a single-user, 100% object oriented, simple GIS system using largely free, off the shelf components. It is not a matter of "if", more a matter of "when". This would be a modern day equivalent of GRASS, but developed to give GIS software training rather than to actually be a usable GIS system.
The quickest, cheapest way to do this would be to write it in Java and also specify methods in Java. The spatial API could use the Java variant of OGC Simple Features specification (which was placed in the public domain by cadcorp and Oracle). Only two things would require much programming, the spatial index and the event/ transaction reflex-method invocation system. A proof of concept version could omit a spatial index altogether, offer a tiny subset of events and provide no transactions - and a rudimentary user interface.
The GIS aspects would almost be the most straightforward. What is needed is a single-user object database, the fact that some values are "geometries" is not the tricky part. However we do need a transaction style of storage (as in ODMG), not a persistent-language style (as in PJama) I believe. The Quillion PETS architecture would be almost ideal (it does schema evolution nicely) but using Java for both implementation and methods has drawbacks as well as advantages, and the PETS architetcture may just not work without significant changes. Simple serialised collections may be entirely adequate, coupled with a set of conventions for typing, names and interfaces.
The basic structure could remain the same, but commercial components substituted for the simple, free ones as the users' needs expanded, e.g. a single user Object Store, O2 or Poet database instead of simple files of Java serialised objects, a plug-in of independently validated spatial reference system translators, or successively more capable spatial indexes which retained the same API.
Since JavaGIS is a full generation ahead of theme (layer) GIS, it is almost too far ahead for established commercial GIS companies to consider; but neither is it a research project. Academia likes to think that it is working one and a half to two generations ahead of commerce, so JavaGIS would be an engineering project, but one on which research projects could then be based.
A widely-used JavaGIS would compete most immediately with ESRI's Arc/View and similar simple desktop GIS commercial products. Arc/View has one of the biggest shares of this market, though this is a small fraction of the total as there are dozens if not hundreds of products from much smaller GIS companies. Microsoft and Mapinfo could, however, eventually dominate completely. It would not compete in terms of sales, but it would certainly compete as a platform on which research groups could build experimental plug-ins. It would then be both a jump-start for the research and a way of disseminating the resulting tools.
Arc/View's strong point is its "extension architecture" which allows research groups and very small companies to produce "extensions" to perform specific tasks. The "spatial analysis" extension (from ESRI itself) provides some topological query functions which are lacking in Arc/View itself. Small, specialist GIS companies have seen a commercial opportunity that does not require them to produce an entire GIS themselves. University research groups have not yet taken up the opportunity to use Arc/View as a research platform; due largely to its expense, but ESRI can be expected to provide cheap site-licenses to solve this. This need not cost ESRI much in terms of revenue: the basic Arc/View is extremely limited in its functions while still being able to host extensions, and ESRI could provide its most valuable capabilities as extensions which cost extra.
Arc/View could look as if it is about to achieve exponential take-off in large GIS users and universities were it not for the uncertainty concerning Microsoft's desktop GIS product. This bundles public-domain USA spatial data but is less attractive outside the USA. In the CAD market 10 years ago, AutoCAD achieved exponential take off due (perhaps) mostly to its customisability which allowed small companies to produce specialist add-ons; but it had no significant desktop competitors at the beginning.
Thus Arc/View's strongest feature, its extension architecture, is precisely the area at which JavaGIS projects could excel and do even better than Arc/View does. If a widely adopted JavaGIS architetcure did not exist (and it doesn't yet), Arc/View would provide a very useful capability for the GIS research community as a de facto standard for specialist GIS extensions. However, the people who now produce research tools based on Arc/View would be precisely the same people who could help make JavaGIS a reality. Thus Arc/View is both a help and a hinderance to GIS research. This conflict is not universal: many important research developments are too radical to be shoe-horned into Arc/View extensions; and no doubt there will be several generations of JavaGIS too, each of which is eventually seen as too limiting and is replaced in turn by a more general approach.
There is a very significant design poblem in decising where to partition the various class hierarchies that are required. However this may be best done as a series of throw-away prototypes. The schema of the application is distinct from that of the data except that some data really wants to modify the application rather than just be active data. We would need to be able to work with "dead" data imported from OO GIS's without feature methods and also "flat, dead" data imported from theme-based GISs. The internal core object model, display behaviour system and "reflex method" (the object life cycle event model) and user event model need designing. ODMG's ideas would be worth a close look as would the existing OO GIS product architectures of Laser-Scan, Smallworld and Ardent(O2).
This looks like the sort of thing we need: "In general, all Java Beans loaded from a single class loader can "see" other beans from the same loader and make direct method calls on those beans. However, these cross-bean calls are currently based on well-known interfaces or base classes. Beans use "introspection" to "learn" or "discover" information about peer beans at run time. In such a case, one bean can infer an API supported by another by detecting certain "design patterns" in the names of methods discovered through introspection. By contrast, the InfoBus interfaces form a tightly typed contract between cooperating beans. No inferring is required, and procedure calls are direct. "
"The InfoBus interfaces allow the application designer to create data flows between cooperating beans. In contrast to an event/response model, where the semantics of an interaction depend upon understanding a bean-specific event and then responding to that event with bean-specific callbacks to the event raiser, the InfoBus interfaces have very few events and have an invariant set of method calls for all components. " http://java.sun.com/beans/infobus/spec111/ib111spec.htm "
These are only a rough and incomplete selection of references. For more references to IETF, W3C and OGC work, see my full bookmarks lists. If you know of osmething important that I have missed, please email me. This list does not include print media references.
[This position statement derives from a privately-distributed note of 28 September 1998.]