On Sun, Nov 14, 2010 at 7:48 PM, Chris Holmes <[email protected]> wrote: > > > 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.
Not sure how a pure georest protocol can actually work with geotools data stores: Difficulties: - being able to list the layers. Mapfish has no such entry point. In theory we could have a store where the entry points are manually configured. I find that lame, but don't see a way out - know the structure of a feature type. One can resort to a dirty trick like getting the first feature and pray and hope, but in the end it won't work unless you're lucky: an attribute could be missing from the first feature, or there may be no feature at all at that specific point in time. It's just not reliable. >> > 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). Works for me, as long as the GUI is optional. >> 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. Yeah, I guess so. At the end of the blog I listed a few things that I'm still mulling over. But yeah, in the end I'd like something that can be specified in its full form, examples included, in, say, 20 pages or less. > 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. Right, that should be done. > 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. Yeah, if there is one thing that I would have really liked to have was ECQL. However supporting it server wide is a burden. For this specific protocol and particular customer use case we actually foresee just one client (GeoServer itself) and many servers (the other services doing computations and needing to push vector data into GeoServer which will fan them out in many different services and formats). So the easier to implement the server, the better. To be honest, if one really needs complete and powerful there's WFS already, this one is aimed at a different niche, simple to understand and quick to implement. Should be something like WMS, that became popular quickly exactly because it was simple (and because it was a recognized standard, too). 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
