Q & As for the 8th 3D GeoInfo

Few questions surfaced before the upcoming 3D GeoInfo conference. Here they are answered:

What is the benefit of the GMO's in contrast to system "X"?

First must be stressed that the main differences derive from an unorthodox design behind the GMO concept. This difference is not a hype - it is a legitimate design that worth an attempt to study its potential. All is based on a strict principle that data and functionality are of the same status and quality for any GMO everywhere on the platform. One benefit becomes noticeable when systems are exposed to a change of a standard format/protocol, or are exposed to the limits of what a particular standard can address, or when a blend of standards would be optimal. Then, using a traditional approach (regardless of how advanced technology is used for the systems), we need some new implementation for those systems - otherwise they remain unable to cope with the desired cases, become outdated or even obsolete. New implementation often can only be made by the vendor of the software, which is expensive for individual cases, and in connection to other systems sometimes so expensive that it is practically impossible. In contrast, a GMO-based system needs a new GMO definition that addresses only the problematic case, it can be made by the content/information provider, typically without any intervention to the customer's system regardless of how complex is the rest of the system. More frequently this happens,the broader system-of-systems evolving over time is in question, the bigger is the benefit of GMO.

Are there some modeling similarities to Systems modeling or SysML?

GMO is not a modeling tool, it is a technology that allows us defining, instantiating, storing and exchanging data objects that represent any geospatial or geographically related feature or information. If necessary one can use SysML or similar tools to specify, analyse, design, and/or verify definitions of GMOs.

How is GMO fitting into the context of web processing, standardization and data exchange?

Neatly, in short. Any web processing or a web service may be utilized by a GMO definition, and it is also possible to define GMOs that provide specific web service by themselves. GMO has a strong focus on standardization, but the standardization takes place on a different level then usual. Traditional approach is to standardize structure and format of the data. GMO, however, standardize at the level of how to computationally interpret entire data model associated with particular data. Claiming a "different approach to standardization" is a major source of misunderstanding and suspicion about GMO. Perhaps because the standardazitaion of the entire model interpretation has vast implications, which get quickly overwhelming and therefore confusing. The exchange of GMO is a solved issue and requires the HotSpot VM at all ends.

How can we transform or map our current geographic feature into a GMO?

There are several options how to do that. One way to classify these options is based on semantics of data used in a GMO definition. If all data are carried by the GMO instance itself the transformation is a direct analogy to what we need to do when converting from, let's say, KML to a Shapefile. Less traditional option is when the resulting data or information can be generated from few parameters using procedures that are also part of GMO definition. Finally, GMO may represent a geographic feature by containing only some reference id and functionality for retrieving the actual data/parameters from the third party web service, DBMS or files.

How can we share information with others not using GMOs?

It depends on what the others are using. Imagine you have all your data in Shapefiles, CityGML, or other particular standard format and other party simply does not use that format. One solution is to convert (export/import) your data base into the format acceptable by the other party - the nature of this solution remains the same also for GMOs. Another solution is to implement the support for the format in the other party's system. It is relatively light, in terms of amount of code, to implement GMO support in comparison to most standard specifications used in GI systems today. Once implemented the GMO support remains valid for any future GMO definitions (understand data models and functionality), which multiplies GMO's effectiveness in terms of cost, design and maintenance.

Is there a vision for usage besides the sharing of GMOs within a specific JVM environment?

The bytecode of GMOs utilizes a certain standard format in a similar way as KML, CityGML or Shapefile do. Hence, it is theoretically possible to handle GMOs on the level of binary data - just to retrieve the data (not the functionality) of a GMO. The current development effort, however, does not go in that direction because it leaves the more powerful and less discovered part aside. There, in a sense, GMOs act more as system elements rather then being a mere data set in a rigid data structure.