cameron.shorter at gmail.com
Tue Oct 30 18:20:27 EDT 2007
Re Open Specs:
Assuming specifications are of similar complexity to alternatives, a
developer should pick specs as they offer an element of future proofing
to an application. Unfortunately some of the OGC specs don't fall into
the "similar complexity" category, as evidenced by the level of uptake
things like the WFS spec.
Encouragingly the OGC has shown signs of recognizing this with their
recent "Mass Market" focus. So you are likely to find OGC receptive to
suggestions to simple specs, as evidenced by OGC move toward Simple GML
If you are looking into routing, I suggest you start by looking at the
OGC's OpenLS spec. I am not familiar enough with it to make a call on
whether a simpler protocol would be more appropriate.
Eric Lemoine wrote:
> On 10/30/07, Cameron Shorter <cameron.shorter at gmail.com> wrote:
>> Looks very interesting.
> Hi Cameron
>> Quick questions.
>> I couldn't find a reference to a license on the home page. What will you
>> be using?
> Already answered.
>> My first thoughts when I look between server and client is "Should
>> standard protocols be used". Do you see use of OGC Standards to be
>> appropriate here?
> On the client-side there are components, such as the layer widget,
> that don't rely on any service. Some others, such as geostat, do rely
> on services that serve features using GeoJSON. The services support
> filtering, and we're trying to conform to the parameters specified in
> OpenSearch Geo. The application developer can also add his own
> app-specific filter parameters, but the protocol becomes totally
> As you've probably noted we could have used WFS and Filter Encoding
> for this. But our goal being to provide an extensible framework on the
> server side, where the application developer can provide his own code
> to respond to query of any complexity. I feel that achieving this same
> level of functionality with WFS and Filter Encoding would much more
> I'm very interested to hear from you regarding all this.
>> Or are some of your interfaces appropriate to put forward as a standard?
> We'll be interested in pushing REST-based interfaces in the realm of
> feature services and filtering. I often read Sean Gillies' blog (CC:ed
> to this email) and he also seems to be interested in that area.
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254
Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Software
More information about the Dev