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 and GeoRSS.
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 <[EMAIL PROTECTED]> wrote: > >> Eric, >> 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 > custom. > > 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 > complex. > > 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. > > Thanks, > > -- > Eric > > -- Cameron Shorter 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 http://www.lisasoft.com/LISAsoft/SupportedProducts.html _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
