On Sun, Nov 14, 2010 at 3:33 AM, Andrea Aime
<[email protected]>wrote:
> 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.
>
>
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
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
