OGC vs GeoRSS

Ok so the title is a bit dramatic but Howard Butler has written an excellent article over at hobu.biz to give his point of view over OGC‘s “smash and grab” on the developing GeoRSS standard.

Too many great quotes to agree with, but this one particularly hit a chord with myself,

The implementation of OGC specs for the large GIS vendors historically has been uneven at best, with bits and bytes dangling about — giving the hope and appearance of interoperability but ultimately failing to deliver on the promise. In fact, in many ways it has been the small vendors and open source implementations like MapServer and GeoServer that have carried the torch of true OGC interoperability.

I must admit i have been largely on the sidelines reading the eogeo lists but i am certainly intrigued by OGC’s interest in GeoRSS given its use would benefit largely individuals and web development products – certainly a far cry from OGC’s GIS-centric member list.

From Allan Doyle’s response:

I believe it’s in the best interests of keeping GeoRSS open and
available to everyone to for us to keep it under a Creative Commons
license.

If you read one thing in the GIS blogosphere this would be it. Come on hobu, open up comments!

10 thoughts on “OGC vs GeoRSS”

  1. Yikes! I think that Allan is on to something when (on his blog) he suggests that the Open Source Geospatial Foundation might be the organization to take over GeoRSS.

  2. Chris – I put in a trackback but it seems to not have worked, Thanks for the link back.

    I don’t know if OSGEO wants to do standards or even pseudo-standards. By conflicts do you mean internal or with other organizations?

    Let’s assume you mean internal, that there might be two groups working on roughly the same thing.

    I see no specific reason not to be working on more than one spec that covers the same topic, particularly if they are different enough in approach. I’d rather have two well thought out things to deal with than a hodge-podge. Also, the two camps might learn from each other and might realize they are not that far apart. Better to have that happen in an open environment than a closed one.

    Also, you have to assume that when the time is right for an idea, more than one person or group will start working on it. Again, better to have some open process so people can notice each other.

    Then let’s distinguish between development of the spec and ratifying the spec. I think people should get less hung up on premature ratification. It forces you do behave in silly ways. The IETF model was to only consider specs that had at least two independent implementations that are shown to interoperate. That means that the spec maturity was high enough to have gained some traction. I’m not sure if they do things exactly that way anymore, but it’s a good model.

    So forget about the “standardization”, let’s develop some specs. The good ones will bubble up and win out. If they don’t it’s more than likely due to personal ego issues or business reasons usually dreamed up by the marketing departments, not the techies.

  3. Pingback: Ogle Earth
  4. Pingback: 10 clomid online

Comments are closed.