On Sun, Nov 14, 2010 at 3:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Sat, Nov 13, 2010 at 6:27 PM, Chris Holmes <cholmes@anonymised.com> 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.
Awesome. Hopefully the client implementation could handle both? Are you planning on just getting the georest geotools datastore up to snuff? Or making a new one just focused on this protocol? Would be really great to to eventually be able to cascade most any geo rest services.
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 
Cool.
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.
That makes sense, and I definitely don’t want to add unrequired work, am just thinking about the future. I would put an html interface as a bit different than ‘whatever gui’, as a good html interface for a rest protocol can make things much more self documenting. Potential implementors can click through the interfaces, and use forms to try out parameters, instead of having to drop down to curl. It makes sense as an addition on top of the base, but if we were to try to turn this in to more of a standard I would push for thinking through that base html interface (and then others could put more advanced html or guis on top).
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.
Cool, I was just curious of your thoughts on it - implementing it is definitely a different goal than what you’re going for.
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
OPesriEN
Yeah, I noticed that too as I was perusing this before sending this. Maybe Satish will have some insight, and if they’re open to changing that.
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.
Yeah, wasn’t suggesting to implement them, just noting other prior art. Though interestingly in my (albeit limited) experience, I see more feature servers in the wild than mapfish servers. The one that jumps to mind is http://www.geoplatform.gov/gulfresponse/
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.
Sorry, I meant core, not extension.
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).
Though many people likely won’t read this far - everyone who sent private emails, please send them public! It helps the core developers hugely to have the opinions of real users on this list, even if it’s just a ‘that would be useful to me’. And I’d say if you bothered to read this far in this email I’m quite sure we appreciate your opinion, since you care about these fairly obscure details enough to read.
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?
I looked it over. I mean, there’s not a ton there, so not a ton to comment on. But that’s the point, no? Keep it simple and clean? I think it accomplishes the goal, I like the design of just extending MapFish and aiming for compatibility with it. And for that reason it’s not worth really digging in to ways the mapfish protocol could be done different.
The one thing that would be nice, though certainly doesn’t affect the protocol, would be a reference like in http://docs.geoserver.org/2.0.x/en/user/extensions/rest/rest-config-api.html Something that maps out all the return codes, http operations and expected returns. The protocol pdf you sent has lots of references and implied functionality, which is certainly sufficient for a dev with good geo experience, but doesn’t seem quite sufficient for a naive implementor. But all should come later, as you evolve it when implementing.
If we do implement it in GeoServer it’d be cool to have ECQL filter option, so you could do like we do in other services and say cql_filter=XXX. But the mapfish protocol seems a good bit easier to implement, so no reason to have it in there.
Good luck with it, will be a great thing to have in the geoserver ecosystem.
C
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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel