Org.OpenGIS.GeoAPI Revisited - Part I

Author: Sestic, Maksim

I've been thinking of starting this article by lamenting on current state of the available managed OGC's GeoAPI interface implementations, but I won't :-) If you're reading this - you have probably already hit their limitations. I'm talking about GeoAPI interface ports here (a la GeoAPI.NET), not concrete implementations (i.e. NetTopologySuite, SharpMap or Proj.NET).

Not having common managed interface library makes things a lot harder for GIS developers. Present one(s) won't help you much either - most of them got way out of synch when compared to their Java-based raw model maintaned by OGC. In the meantime, Microsoft's .NET Framework itself evolved a lot, etc. To cut the long story short, my idea was to start managed GeoAPI interfaces from scratch, based on present GeoAPI 2.1.1 interfaces specification - but not by simply jumping into it...

Naming Conventions

Lets start with something "obvious" - naming conventions used in Java and .NET. For example: org.opengis.geometry namespace becomes Org.OpenGIS.Geometry namespace in .NET. Both camel-case and abbreviation rules apply, starting letter always capitalized.

When it comes to interface names, since it's mostly about them, each Java class pertaining to an interface gets an "I" prefix. For example: Precision interface becomes IPrecision in .NET.

Naming and Type Conventions

Java Get/Set functions become Properties. That is - ReadOnly properties for explicit getter functions, or WriteOnly properties for explicit setter functions. Also, get/set prefix gets stripped from resulting property name, always starting with a capital letter. For example:

Function getLength() As Double

becomes:

ReadOnly Property Length() As Double

Also:

Function getLength() As Double
Sub setLength(d As Double)

method pair becomes:

Property Length() As Double

So, when Java function becomes .NET property, and when it simply remains a method - beyond getter/setter rules stated above? It depends on overall method semantics; what it actually means to hosting class/object. For example:

Function setLength(d As Double)

when alone in a class, becomes:

WriteOnly Property Length() As Double

Because Length is a class property. But:

Function ToArray() As Double()

remains a function, since it's a method to hosting class. Sticking to described semantic rules, even parametrized functions become properties. For example:

Function getBuffer(d As Double) As IGeometry

becomes:

ReadOnly Property Buffer(ByVal d As Double) As IGeometry

since buffer is a parametrized geometric property (one of many, of course).

Type Conventions And Enumerators

Enumerated types seem rather confusing to present managed GeoAPI ports. In fact, they're simple enumerators. A good example for this is org.opengis.geometry.PrecisionType which derives from (extends) generic Java CodeList type. In .NET it becomes:

Public Enum PrecisionType

with it's members slightly changed when it comes to naming: DOUBLE becomes Double, FIXED becomes Fixed, etc. If we had a Java member named PIECEWISE_BEZIER, then it would become PiecewiseBezier in .NET. BTW, proposed notation is way closer to original ISO identifier naming rules anyways.

Type Conventions And Generics

This is the most challening part of it all. That's also why IKVM.NET won't help you much with GeoAPI in first place. Yes, it's about .NET generics and how do we use them in GeoAPI - keeping in mind future implementations. IMHO, it's very important to introduce strongly typed collections to managed GeoAPI interfaces. Alas, without knowing the nature of each interface it's close to impossible to introduce their generic counterparts properly. In other words - one needs to consult UML definition and think ahead of possible implications on implementers' side.

Ongoing Activities

You can check the current development status of managed GeoAPI library based on present GeoAPI 2.1.1 interfaces specification here: Managed OpenGIS GeoAPI Interfaces (look under SVN trunk).