Andrea Aime asked: >>> Last time I checked application-schema datastore was read only? >> >> Yes it is, but we should discuss this as part of the next steps strategy >> work.
>This is sure interesting. Do you have a longer term plan about this? I'll catch this one since I'm responsible for much of the strategy and associated funding that Ben and Rini are using to implement app-schema. With respect to WFS-T support, it is on the list of "could-have" requirements. In Australia there is legislation that requires Industry to report some spatial information (mostly minerals exploration related) back to Government agencies. It has been suggested a number of times that this could be facilitated using WFS-T with GML application schemas like GeosciML. The trouble is, even if the feature was implemented, there are still cultural barriers that prevent this from happening. We won't be moving to add app-schema WFS-T support until we start to see the culture for the current publishing phase establishing. There are also a couple of other features higher up on the list of requests. The immediate future (between now and June this year) is to complete app-schema read-only and have it deployed at a number of Australian geological surveys and research organisations (like my own) against production databases publishing GeosciML and similar GML application schemas. We're expecting this deployment will lead to a number of requests for improvement around configuration, performance and bugs we didn't catch in the tests. We're currently funded until June 2011 (2 more years) and will continue to support this activity during that time. All improvements, fixes etc will be returned to the Geoserver community as per current activities (and we've been delighted at the response of the geoserver community to our contributions). We will also continue to watch the geoserver mailing lists and where we can (which I expect will be quite a lot) we'll look at issues coming in from the broader community as well. Whilst we aren't currently active on the WFS-T app-schema support, if someone wanted to work on this then we would be happy to collaborate on it to aid the process. Its also entirely possible if things go well with our other priorities, we will get to it in the next couple of years just because it would nice to have the full read-write feature completed and we will eventually need it. Regards, Rob Dr Robert Woodcock Auscope Grid - Director, Senior Research Scientist CSIRO Exploration and Mining ARRC (Australian Resources Research Centre) 26 Dick Perry Avenue, Kensington WA 6151, Australia PO Box 1130, Bentley WA 6102, Australia Ph: 08 6436.8780 | E: [email protected] | W: www.csiro.au -----Original Message----- From: Andrea Aime [mailto:[email protected]] Sent: Friday, 20 March 2009 4:36 PM To: Rob Atkinson Cc: Geoserver-devel; Justin Deoliveira Subject: Re: [Geoserver-devel] Layer names, resource aliases Rob Atkinson ha scritto: >> Last time I checked application-schema datastore was read only? > > Yes it is, but we should discuss this as part of the next steps strategy work. This is sure interesting. Do you have a longer term plan about this? >> And GeoServer must do WFS-T. What I really want is something that >> allows me to rename attributes and map types on simple features >> without: >> 1) getting a significant drop in performance >> 2) loosing the ability to write > > This is perfectly reasonable set of objective criteria - its always > reasonable to put in optimisations for common special cases, but best > to do this against a design capable of handling all cases that will > matter. In an ideal world, yes, but practice does not always agree with that. The "general" case architecture usually has to do a lot more work in order to deal with its generality, sometimes you can just add a few checks in core places and you get the best bang for the buck... and sometimes its clear that performance was not considered during design and it's simply impossible, or too hard, to retrofit it later. >> If the application schema datastore can evolve to this point, >> excellent, otherwise I'll roll out something simpler that handles >> efficiently and effectively the common and simple case. >> > > Its obviously expected that you will need to do this - the questions are: > 1) can this be removed easily enough if a general solution emerges? The current RW type renamer is just a wrapper around datastores and feature collections. It could conceivably be evolved into something that does simple renaming and type mapping keeping a decent performance profile and without loosing RW capabilities. As for easy of removal, it's currently hooked up into the FeatureSource building chain by something like 15 lines of code in a single method of ResourcePool. Cannot get any easier to remove than this. > 2) does rolling this out involve adding unsafe or unnecessarily > restrictive assumptions into parts of the code base? Hmmm... I would not think so. If we ended up doing this the harder to switch out part would be the mapping configuration. But for sure I would make it so that it follows the current design principle: _nothing_ outside of the classes that build up the FeatureSource for the rest of GeoServer would know about it. The rest would just play ball as usual, not knowing that the FS it's playing against is actually a dynamic feature mapper. And I want this kind of design for application schema as well. Granted code modifications are needed to support complex features, but I really do hope we won't have to make changes in services to support application-schema mapping (besides the WFS references to external, non GS generated schemas). Cheers Andrea Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
