Opensource Development funding

Howard Butler has just written an interesting article discussing the pro’s on funding development in open source GIS packages.

From my perspective looking in (and currently trying to get some Geoserver sponsorship), there are a few problems which i think would entice more sponsorship from the wider community,

  1. A simple WIKI/Document explaining to the company/corporation, ‘whats in it for me”?
  2. How does sponsorship work?
  3. Is there any attribution attached to the sponsored feature?
  4. How are the rates calculated?
  5. Will the feature remain in the products roadmap?

Hopefully, OSGEO will sort out some of these issues. The “whats in it for us” attitude is certainly the feeling i am getting at the moment

Google Earth’s Issue logging …

Where is it?
I have had many queries regarding their HTTPS support of network links and image overlays but these always seem to land on deaf ears or gets lost amongst the thousands of arguably useless posts on the community forum.

Makes you realise how refreshing it is when projects have public JIRA/Bugzilla interfaces available so you can at least give feedback
From the release notes of the latest BETA 4 (4.0.1657) via GEBlog, the offcial word,

Reporting Errors
----------------

To report an error, you should first consult the Google Earth Help Center and
the Google Earth Community. They are both excellent sources of information.

Well my issue isn’t resolved in any of these resources and I’m kinda resorting to the blogosphere in a last ditched effort so someone may see it,

Problem: GE does some very weird handling of any network link or image/screen/ground overlay that is being sourced over HTTPS (as distinct from HTTP). I would imagine most would not even notice this, but as a few of my WMS services exclusively use HTTPS i stumbled upon the following problems,
GE v3 (current stable): If a groundoverlay href containts a HTTPS link with a query string, Google Earth strips out the query string when making the request to the remote URL. In my WMS case, this would mean the HREF would contain

https://my.wms.server.com/wms?Service=wms&Version=1.1.1&Request=Getmap….

but then GE would actually only request

https://my.wms.server.com/wms

which results in no image being returned.

GE v4 (any beta vers): I was hoping v4 may have fixed the HTTPS problem but it appears they have made it even stranger. Now if i request a WMS groundoverlay via HTTPS, GE interprets the https:// path as a relative link to the KML host address so if i’m sourcing the network link from http://my.networklink.com/link.kml … the address requested by GE would actually be

http://my.networklink.com/https:/my.wms.server.com/wms ….

What the ~!?

Since GE uses the libcurl.dll libraries, HTTPS support should be a given. I’m sure its a very small configuration change that’s required but its extremely frustrating!

In other good news, i’m pretty eager to see when wmsbase.dll is linked into the binary. From what i can gleam from the code, it’s containing proper WMS 1.1.1 GetCapabilities parsing which is propably what James Macgill has been working on. I better get my skates on releasing my own similar code!

All this ArcGIS interoperability …

has revived a rant i had a couple of months ago regarding WFS support.

In a word, its terrible.

As has been discussed elsewhere, the fact ESRI expects its consumers to purchase *another* extension to read open standards that they “openly support” is questionable and laughable at best. Sure the cutdown FME is a great addition if you want to read 50+ formats, but when 8.3 had a free plugin with arguably better WFS support, you really gotta question ESRI’s motive about supporting the standard in the first place.

From where i’m sitting, they rant about their free WFS/WMS server connectors for other products such as ArcIMS but then when they don’t include the same functionality for their client’s to consume, whats the point?

WMS support is dime a dozen in all desktop GIS products nowadays so i couldn’t care less that this is out of the box with v9 … but ESRI has really fallen behind the eight-ball when competitors such as Mapinfo include OGC support out of the box, and Intergraph with two nicely configurable extensions.

In contrast with the ESRI / Interoperability approach, one size definately doesn’t fit all. Last time i looked (and please correct me if i’m wrong), the WFS connector through FME simply attempts to download the *entire* dataset from WFS, indexes it and you’re supposedly ready to go. Thats fine when the dataset is tiny and or relatively simple, but when its a complex cadastral dataset its just not going to work. There isnt any smarts built in to use the filters at all (no, not even bbox), use any intelligent caching or make it even configurable to setup what you would like FME to request. It’s just plain dumb.

Kudos must go out to Cadcorp, Carbontools, UDIG and Mapinfo for some excellent WFS support. Hopefully the big E can take note, although i’m not holding my breath
Uh oh, I’m starting to sound like the GISDirtbag‘s apprentice!