A good test for OGC and OSGeo collaboration

One thing we ran into when going through GeoServer incubation (with OSGeo) was the interesting case of how to handle test data (from the CITE project) and application schemas (from every second standard the OGC produces).

The solution for GeoServer was was to point to the software notice. Here is an example from the cite wfs 1.1 README:

The CITE team engine does not offer a specific license for re-distribution, as such it falls under the general guidance provided by the OGC legal page (http://www.opengeospatial.org/legal/) and the following license:

• http://www.opengeospatial.org/ogc/software 

OSGeo incubation is not especially strict. Since OSGeo and the OGC have an "Memorandum of Understanding" so we figured we could talk through any confusion.

It looks like pycsw has found just such a confusion! The pycsw is a catalog implementation written in Python that is super close to finishing OSGeo incubation.

The project has been rejected from debian distribution ... because the OGC Schemas are not clearly open source. Here is the formal response from November 17th:

Dear Maintainer,

unfortunately I have to reject your package.

One result of the discussion about tinyows was that OGC schemas don't fall  under the Software Notice but the Document Notice. This makes them non free  (no modification) and tinyows had to move to non-free.

I am afraid that pycsw has to do this as well.

  Thorsten

Sounds like a great opportunity to leverage OGC and OSGeo collaboration. I am not quite sure what the answer is (schemas are open to modification, but doing so does render them incompatible with others). I guess we have the same question when distribution the EPSG dataset used for interoperability.

If you are interested in this sort of thing check out http://lists.osgeo.org/listinfo/standards .

If you are an open source developer and would like to avoid these questions consider OSGeo Incubation.

Update

From email Discussion: OGC XML schemas and FOSS4G software distribution

• Jody: Reference to OGC FAQ
• Carl: Scheduling for discussion at Barcelona TC meeting 
• Sebastiaan: Clarification conflict with Debian Free Software Guidelines
• Scott: OGC will contact Debian FTP Masters

There is now a wiki page to brain storm suggestions for Carl to take to the Technical Committee meeting. Deadline is  March 9th 2015 if you are in position to contribute.

Based on the above conversation it sounds like OGC is going to reach out to FTP Masters and resolve this issue.

A big +1 to OGC - thanks for keeping it real.

OGC and lowering the bar of implementation

I have a couple blog posts up on the LISAsoft website of an OGC nature:

• OWS 9 and WMS 1.3.0 Adoption: OWS9 is now complete (with an impressive $2.65 million from sponsors answered with $5 million in-kind from industry). For my part I was able to look at Daniel Morissette's excellent advise not to upgrade to WMS 1.3.0 and start attacking the source of the problem - restoring trust in WMS clients.
• OGC Struggling to Reach out to Implementors: Last week saw a great example of tough love for the GeoPackage standard. Carl Reed is doing the right thing and taking work like OWS Context to the standards@osgeo.org list for review. I had a look and while I am impressed with the level of "reuse" shown, I am concerned with the amount of work (and risk of mistakes) being fostered on client authors.

The common theme here is that OGC takes care of services pretty darn well (this makes sense as it is often what sponsors of events such as OWS9 are willing to pay for). In reaching for a larger audience of client applications the standards body really needs to step up its game and work hard on communication, simplification and lowering the bar of implementation.

I am heading to the AusNZ OGC meeting this week to discuss OWS10 - it will be interesting to see where the priorities are.

What is the deal with GeoAPI

One of the great thing about working on an open source project is the wide range of expertise you suddenly have access to. For me the expertise often takes the form of well documented Java interfaces provided by the GeoAPI project; and it is the GeoAPI mailing list I turn to for help when "I just don't get it".

This weeks question comes from Tim Swanson of Tyler Technologies (welcome Tim and keep the questions coming).

Tim asks (with respect to status of the relationship between GeoAPI and GeoTools)

The first is whether or not this relationship is spelled out somewhere in the documentation, and whether this documentation is up to date. (I gather that this relationship is still constantly evolving.)

Second, which version of the GeoAPI should I be using.

The answer this week comes from Martin Desruisseux; who provided a history of how these projects have interacted.

And yes the answer is in the documentation; and I have updated the page to include Martin's notes on the history.
- http://docs.codehaus.org/display/GEOTDOC/02+GeoAPI

My take on the matter is that the status is strained; but it is a healthy strain beneficial to both projects.

• GeoAPI keeps the GeoTools project honest about being correct (if you are wrong who cares if you made it run?)
• GeoTools keeps the GeoAPI project honest by actually making sure the ideas can be coded (who cares if the idea can be represented if it does not run?)

As for what version of GeoAPI to use: If you downloaded the GeoTools library you will find a geoapi jar included in the mix; if you are using Maven the pom.xml file will make sure you download the correct jar.