On Sat, Nov 13, 2010 at 6:27 PM, Chris Holmes <[email protected]> wrote: > Looks quite good, though I worry about lack of interoperability between any > service with these goals. I've long wanted something like this in > GeoServer, but was planning to try to make interoperate with at least one > other protocol. Can you directly use a MapFish client with this service? > Like are all the improvements additive?
It's almost 100% compatible. The only change we suggested is "crs in the place of epsg to be consistent with the GeoJSON notation". The mapfish query protocol uses the "epsg" parameter, but the JSON notation uses "crs" everywhere, so we thought it would have been better to be consistent. It is actually something we can easily undo. > Are you planning to make it transactional? Or read only? Eventually we'd like to adopt also the write part of the Mapfish protocol, possibly, as is. But we haven't looked into it deeply, atm we need something we can use in a customer project, and rather quickly I'd say ;-) > One thing I would > like to see (though certainly not needed in early implementations) is to > also have html representations in addition to the json ones, so it's > browsable by humans. ESRI does a good job with that, including query pages, > like > http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/TaxParcel/ConsumerFocusedPublicAccessMap/MapServer/1/query This could be done, but it adds unrequired work, so it goes against the guiding principle of this work. As I said, the major driver for this is to be able to effortlessly cascade a random service that generates simple feature like objects into GeoServer. So the idea is to write a store in GeoServer to cascade the protocol down and get those random services expose the expected network interface real quick. I'm not saying having a HTML interface would be bad, on the contrary, it looks like a good idea, but I would not make it a requirement in the protocol. It seems to me one could/should be free to implement whatever GUI on top of the base protocol to make it more approachable to the casual user. > Did you consider at all trying to implement the ESRI version? Nope. > I think they > actually did quite a nice job with the rest api, and they released it as an > 'open' standard, > http://www.esri.com/industries/landing-pages/geoservices/geoservices.html I > met some ESRI folks at foss4g and they seem serious about trying to make it > a real open standard, starting an open list to discuss changes and move it > forward with consensus. But as of yet I've not seen that. The really nice > win of implementing it would be that we'd get real interoperability, with > esri flex, javascript, silverlight and iphone clients. And we could cascade > arcgis server. Looked briefly at the specification. 200 pages... Also looked briefly at the data querying setup and return documents: it fails the objectives of what we're trying to do squarely. What I see there is a protocol almost as powerful as WFS with some bits of WPS and some RestConfig stuff as well and location services and .... Even just limiting ourselves to the part looking like WFS we're facing a protocol that's more complicated than the Mapfish one for the implementor, ease and speed of server implementation are very important to us. One final bit (just joking here): would you really implement in GeoServer a protocol filled with tokens such as "esriSpatialRelIntersects"? :-) So much for being open, it has ESRI written all over it ;-) > The other two that jump to mind are http://featureserver.org/ and > http://www.jasonbirch.com/nodes/2009/01/31/269/mapguide-rest-extension-feedback-wanted/ By looking around it seems to me that did not evolve much past that blog? FeatureServer also seems to be dead in the water, latest release is 2 years and a half old: http://featureserver.org/doc/News.html Of the open implementations we've seen only MapFish still seems to be alive and kicking. > And yes, there's wfs basic as Ian points out, but I'm not sure that there's > any implementations of it? Maybe cubewerx? Not aware of any implementation in fact. > No matter what I think it'd be a great community module. We could > theoretically have several rest services in community modules. But to get > in to extension I'd like to see one that actually interoperates with several > clients and at least one other server. Perhaps once we flesh them out we > could suggest the changes to the mapfish protocol. Or ultimately see if we > could agree with ESRI and perhaps put the final results in to OGC > eventually. Aren't you jumping the gun a little here? Last time I checked in order for a module to get into extensions it required a stable maintainer, some test coverage and some users: http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules#GSIP22-CommunityModules-promoting You're adding extra promotion criterias there that are not part of what the PSC voted. Btw, I don't disagree with your general assessment, but I'd just change the word "extension" with "core". Anyways, we're just getting started, not sure if and when we'll create a GS plugin that implements that protocol. Generally speaking I already got quite some positive feedback via private mail (which is good but a bit disorienting, I guess many people like the idea but are weary of saying so publically). One thing that I'm missing is some detailed feedback about the protocol. Is there anything wrong, are we missing something, is there some way to make it better without changing its "quick and easy to implement on both sides" nature? Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
