2.2-M1 released

The GeoAPI 2.2-M1 milestone release has been deployed to our maven repository.

This tag contains some interesting work:

  • Initial round of org.opengis.style interfaces based on the latest OGC and ISO portrayal specifications
  • Some feedback on our new feature model after several months testing
    • Feature now has a getIdentifier() method allowing access to the same FeatureId used by the org.opengis.filter package.
    • use of getDescriptor methods (rather than getAttribute methods) for ComplexAttribute

Thanks to everyone who helped out and provided feedback.

2.1-M9 has been released into our maven repository. This release includes the results of a review of our "General Feature Model". These interfaces are a compromise between GeoAPI 2.0 and ISO19109.

For GeoAPI 2.0 users:

  • We maintaining the PropertyDescriptor (rather than MemberType)
  • We have introduced a Name class (a scoped name to prevent conflicts)
  • We are no longer tied to attribute order; this change allows us to represent complex content
  • If your data is tied to attribute order the SimpleFeature interface as indexed based attribute lookup similar to GeoAPI 2.0

And now over to Justin:

Hi all,

Time for round2 with geoapi. Based on andreas initial feedback and the thread that resulted I have taken a crack at simplifying the model. Here is a summary of what I have done.


JavaDocs are now to the point, and no longer a brain dump from Jody. They should be much more approachable from the normal java programmer point of view, and less in terms of Rob A (sorry Rob (wink) ). Many of them
are complete with code examples, and anologies to the xml world (which helped andrea see the point of Attribute, and AttributeDescriptor).

Attribute methods pushed up to Property

All the "meat" is now on the Property interface. This makes it more much more possible to write code against Property directly, and not have to worry about if its actually an Attribute or an Association.

For this reason, there is not longer a real need for the "view" methods. When I say "view method" what i mean is:

  • Collection<Attribute> attributes();
  • Collection<Association> associations();

Added useful methods to ComplexFeature

Before, the only access to the properties of a ComplexFeautre were through:

  • Collection getProperties();
  • Collection getProperties( Name );
  • Collection getProperties( String );

This is a pain, because more often then not you know that you have only
a single property. And always having to deal with a collection is
pointless. So the following methods have been added:

Property getProperty( Name );
Proprety getProperty( String );

The javadocs on these methods clearly state that the first property
matching the name is returned... and if you are unsure what the
multiplicity is you should use getProperties(star).

CRS only available on GeometryType

Before a CRS was available from the following:

  • Feature.getCRS();
  • FeatureType.getCRS();
  • GEometryAttribute.getCRS();
  • GEometryType.getCRS();

That has been changed so that it is only available on GeometryType and FeatureType. The javadoc for FeatureType.getCRS() clearly states that the crs is derived from the default GeometryType. I found this useful to get out of writing code like this (like i have so many times):

Killed FeatureCollection

OK I did not kill it... but I killed it from the factories. Basically FeatureCollection in geoapi should be ignored.

Java Bean Conventions

All methods follow java bean naming conventions


Instead of rolling our own interface which looks like a half baked
map... I just added the following methods:

  • Map Property.getUserData();
  • Map PropertyDescriptor.getUserData();
  • Map PropertyType.getUserData();


I changed the following methods:

  • Object getValue(Name)
  • Object getValue(String)
  • Object getValue(int)


  • Object getAttribute(Name)
  • Object getAttribute(String)
  • Object getAttribute(int)

(and the corresponding setter methods).

Also changed:

  • Object getDefaultGeometryValue()


  • Object getDefaultGeometry();

Now things get a bit interesting here. Note that these methods return the attribute value, and not the attribute itself. This might be a bit confusing in terms of naming conventions, but it has a few key advantages:

  1. The SimpleFeature interface now looks pretty much exactly like the geotools Feature interface
  2. It is useful in terms of IDE auto completion in that all the methods that are most useful show up first in the list.

Talking with Jody on this one we are a bit torn. It would be great to have more feedback on this one.

And that is it. Let me know what you all think. Let the second round of review begin.


– Justin Deoliveira The Open Planning Project http://topp.openplans.org

2.1-M8 Released

GeoAPI 2.1-M8 has been deployed to the maven repositories for review. The significant change this release is the additional of a valueOf method to each code list implementation (to prevent applications calling the constructor).


  • GEO-65 - SurfaceBoundary.getInteriors() returns an array of Rings


  • GEO-124 - Add valueOf method to CodeList implementations

For more information please visit our issue tracker:

This release is the targeted for GeoTools 2.5-M0.

GeoAPI 2.1-M7 Released

GeoAPI 2.1-M7 has been deployed to the maven repositories for review. The significant change this release is the removal of Java 5 Generics from the org.opengis.feature package, the org.opengis.geometry package has also seen considerable feedback based on real world implementation.


  • [GEO-37] - createDirectPosition is in wrong factory interface
  • [GEO-90] - CoverageDescription.dimension has incorrect cardinality
  • [GEO-112] - Geometry getDistance() should be distance()


  • [GEO-66] - Citation.identifiers / identifierTypes are hard to use together
  • [GEO-68] - TemporalExtent.getExtent() need to returns a TM_Primitive
  • [GEO-113] - Create geometry.BoundingBox
  • [GEO-114] - Create AggregateFactory
  • [GEO-115] - Create ComplexFactory
  • [GEO-116] - Add Envelope getCoordinateReferenceSystem
  • [GEO-117] - Change Aggregate.getElements() to return Set<? extends Geometry>
  • [GEO-118] - Change return type of Complex.getElements
  • [GEO-119] - Define equals and hashcode for DirectPosition
  • [GEO-120] - Filter version 1.1 support
  • [GEO-121] - Extend the FilterFactory interface
  • [GEO-122] - Create BoundedSpatialOperator
  • [GEO-123] - Change Function.getParameters() return type from Array to List

For more information please visit our issue tracker:

This release is the targeted for GeoTools 2.4.x.

GeoAPI 2.1-M4 Released

A GeoAPI milestone release has been deployed to maven repositories for review.

Significant changes this release include:


  • GEO-108 - PointArray should extend List<Position>


  • GEO-107 - Add PrecisionModel to Geometry


  • GEO-4 - Publish the GeoAPI charter on the GeoAPI web site
  • GEO-21 - Update javadoc comment when new ISO 19111 revision will be public

We have collected some of the email conversation into a handy guide.


The source code examples have been placed into svn as well.

GeoAPI 2.1-M3 Released

A GeoAPI milestone release has been published out to maven for review.

Significant changes this release include:

  • GEO-93 a refresh of the the org.oprngis.metadata package (aligned with latest ISO19115 specification)
  • GEO-110 Repackaging of our ISO19107 interfaces into org.opengis.geometry.

For more details please check the above links or the full Release Notes.

The GeoAPI 2.1-M0 milestone release is being prepped, the various RnD experiments are being rolled out into svn branches.

Here is a discussion about the coverage API changes, and if we roll them off trunk into a branch for refinement (and revert trunk coverage code to geotools 2.0 tag).

11:59 AM Alessio F... says: morning all
12:04 AM Jody Gar... says: (smile)
12:17 AM Jody Gar... says: I would like to fix geotool trunk, and started prepping a geoapi release based on trunk.
12:33 AM Jody Gar... says: I need to know if I need to rollback (to a branch) the coverage changes made ...
12:46 AM Jody Gar... says: (or if you guys want to fix things on geotools trunk)
13:12 AM simboss1... says: we already siwtched to trunk
13:22 AM Jody Gar... says: sorry for the rush, I am only going to have a few days this month to help, and I am not sure who else is set up to make a geoapi milestone release.
13:26 AM simboss1... says: there is no need to go and fix the old branch
13:29 AM Jody Gar... says: nope that is not what I ment simboss.
13:38 AM Alessio F... says: GeoServer is alredy using gt trunk
13:48 AM Jody Gar... says: let me send you guys a "new" geoapi jar made from geoapi "trunk"
13:56 AM simboss1... says: ok
14:12 AM Jody Gar... says: it has a different coverage interterface (a few methods deprecated and/or changed)
14:17 AM Jody Gar... says: and I need to know what you guys want to do ...
15:03 AM simboss1... says: can you provide a link to some javadocs?
15:05 AM simboss1... says: afaik
15:07 AM simboss1... says: coverage interafces
15:15 AM simboss1... says: should be unchanged
15:19 AM Jody Gar... says: jar is being sent now .... it is geoapi-2.1-M0
15:20 AM simboss1... says: desides the work
15:23 AM simboss1... says: on iso 19123
15:31 AM Jody Gar... says: (aka a milestone release rather then a dated timestamp thing that justin made from eclipse)
15:33 AM simboss1... says: which should be independent
16:02 AM Jody Gar... says: there are a couple changes, for javadocs you can visit the geoapi site ... let me find a link
16:31 AM Jody Gar... says: (I have an uncommited change to trunk, moving over to the jar I sent you - I would like to commit and fix the coverage implementations in one go ...)
16:36 AM Alessio F... says: hopefully the changes should not break our work ... maybe there are some deprecated methods we could remove
16:51 AM Jody Gar... says: (I am not sure if you understood that geotools trunk, was a right mess w/ respect to geoapi snapshot jar)
17:10 AM simboss1... says: I saw that when a played a bit with features and ordering
17:14 AM Jody Gar... says: the changes are not too bad, I did them on the FM branch (thought I sent email about this, even yesterday)
17:16 AM simboss1... says: remember?
17:32 AM Jody Gar... says: features and ordering?
17:41 AM Jody Gar... says: do you mean Filter 1.1 and sortBy ?
17:53 AM simboss1... says: yeah
17:59 AM Jody Gar... says: right, that is some of what we got.
18:23 AM Jody Gar... says: but there are also changes made to geoapi on coverage, something returing an Object or a Set etc...
18:34 AM Jody Gar... says: I sent out an email with some same error reports yesterday - shall we read it together?
19:00 AM simboss1... says: lemme see
19:04 AM Alessio F... says: I'm going to inspect the jar
19:06 AM * Jody Garnett added Andrea Aime to this chat
19:14 AM Jody Gar... says: going to find you the javadocs ...
19:25 AM simboss1... says: do you remember the subject of the email
19:32 AM simboss1... says: yesterady was out on consultancy
19:39 AM simboss1... says: maybe I missed it
19:47 AM simboss1... says: found it
19:50 AM Jody Gar... says: switching trunk to geoapi-nogenerics ... exerpiment
20:14 AM Jody Gar... says: evaulatingInverse - whatever that is....
20:24 AM simboss1... says: well
20:30 AM simboss1... says: basically
20:33 AM simboss1... says: if that is the problem
20:51 AM Jody Gar... says: http://geoapi.sourceforge.net/pending/javadoc/
20:52 AM simboss1... says: we can just provide a blank implementation
20:59 AM simboss1... says: cause I do not really think
21:09 AM simboss1... says: that inverse evaluation is something worth to block us
21:15 AM simboss1... says: at least for the time being
21:18 AM Jody Gar... says: Or we can check what I did on the FM branch, at least a couple things needed to call through to different methods in order to compile and pass tests.
21:20 AM simboss1... says: We might ask martin
21:27 AM Jody Gar... says: martin is away (sad)
21:32 AM simboss1... says: but he is away
21:42 AM Jody Gar... says: Note simboss I can also rollback this coverage interface change from geoapi trunk
21:43 AM simboss1... says: ((smile) )
21:47 AM Jody Gar... says: (and leave it on a branch only)
21:54 AM simboss1... says: I would rather do that
22:00 AM Jody Gar... says: but I wanted you guys to make this call ... cause you know/understand/care (wink)
22:10 AM simboss1... says: because otherwise
22:16 AM simboss1... says: we would have kind of a mix up
22:20 AM Jody Gar... says: http://geoapi.sourceforge.net/pending/javadoc/org/opengis/coverage/Coverage.html
22:32 AM simboss1... says: between GC IS from OGC and ISO 19123
22:44 AM simboss1... says: yeah
22:50 AM Jody Gar... says: um, okay ... see you understand
23:05 AM simboss1... says: In this release I would not put the new coverage interfaces
23:07 AM simboss1... says: or at most
23:12 AM Jody Gar... says: I will try and rollback, but if I fail I will need to ask us to stub the methods as per the FM branch.
23:16 AM simboss1... says: I would deprecate the old ones
23:57 AM Jody Gar... says: okay so if you can answer my email, with the request to rollback the coverage changes I will try it.
24:10 AM simboss1... says: does what I said make sens to you?
24:18 AM simboss1... says: the new interfaces you are referring to
24:31 AM simboss1... says: would be part of next cycle
24:33 AM Jody Gar... says: hopefully I can upload a geoapi-nogenerics-2.1.-M0 jar this morning and switch geotools trunk over to use it.
24:43 AM simboss1... says: the one we were talking about yesterday evening
24:44 AM Jody Gar... says: I understand ... and that cycle can work from a geoapi branch.
24:46 AM simboss1... says: at the geoserver meeting
24:53 AM simboss1... says: exactly
25:00 AM Jody Gar... says: the nD branch... I will try creating it now.
25:02 AM simboss1... says: We might change a bit these interfaces
25:04 AM Jody Gar... says: (on geoapi)
25:25 AM simboss1... says: so it might not be worth to spend time now on this
25:28 AM simboss1... says: just to create stubs
25:35 AM simboss1... says: that we will change for sure later on
25:39 AM simboss1... says: do you agree?
25:44 AM Jody Gar... says: I understand, my ability to hack geoapi is just limited - let me try the rollback.
25:48 AM Jody Gar... says: and if it works we will use it.
26:23 AM Jody Gar... says: do you mind if I copy this chat over to the geoapi site? It is nice to work in the open on stuff like this, I just did not have time this morning to wait for your email response.
26:33 AM Jody Gar... says: (so yes I agree, let me see if I can do it)
26:34 AM simboss1... says: I inspected the javadocs
30:23 AM simboss1... says: and I noticed that the old interfaces are stil there
30:31 AM simboss1... says: but with deprecations
30:32 AM simboss1... says: which is fine
31:14 AM simboss1... says: we should maybe give it a try
31:32 AM simboss1... says: and correct the few problems we have
31:55 AM simboss1... says: alesio just tried the jar you sent us
31:59 AM simboss1... says: and it builds just fine
32:51 AM simboss1... says: (the coverage package)
32:58 AM simboss1... says: going to try myself
34:12 AM Jody Gar... says: okay cool, I have no problem leaving it in (I did think the changes were small enough I did them on the FM branch)

Repository Juggling

As per email announcement I would like to proceed with the Repository Organization discussed via email. Will post another news item when the work is complete

Feature Model Revison

The change over to a revised Feature Model (see Feature Model is starting up in earnest.
To assist you will find that a source download has been attached to the above page for interested parties, we willl try and arange more formal releases of the pending directory as the projects move forward.

The changes include:

  • revision to Filter and Expression to allow opperation against Objects
  • FeatureCollection extended to support Filter 1.1 SortBy opperation, resulting in a FeatureList
  • FilterFactory2 (does not have to be supported) offering a non-explicit bridge for SFSQL based spatial filters

Interested Parties include: - GeoServer - driving this development (thanks!), GeoTools, uDig. It sounds like the support for ComplexAttribute and ComplexType would simplify some of Bryce's coverage work as well.

More details as they become available.

Stephane Fellah offered a document that describes briefly the coverage model for the reference WCS he implemented in March 2005. This document applies to the interfaces in the com.owsx packages in the pending directory. The document is available for download (PDF format) in the GridCoverage page.


I have added a new page to this space - Pending. This can be used to record documentation and ideas on working taking place in the CVS pending directory.

I have started the page off with:

  • a rough procedure for submitting changes to GeoAPI
  • Feature Model discussing intergration of geotools complex type research with the existing GeoAPI model
Web Site Gearing up

We are trying to figure out how to change over from the sourceforge website. In the mean time we are starting to clean up the user interface of this website, adding favicons and such.

On a related note - GeoAPI icons are now available as attachments on the home page:

The icon used as a favicon is also available:

Release 1.1 or 2.0

From Martin Desruisseaux email:

Given the following:

  • Release 1.0 was one year ago.
  • Release 1.0 had 246 files/interfaces. Upcomming release have 474 files/interfaces, which is a 93% growth.
  • There is incompatible changes since 1.0 release. We tried to document them here
  • Upcomming release is the first one approved by OGC through the vote on the GO-1 document.
    Should we call the upcomming release "2.0" instead of "1.1"? It would be compatible with the policy that dot release introduce new features without compatibility break.

In addition issue tracker has this to say: