"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Geoserver Meeting 04 June 2008

A Skype conference call between GeoSciML Testbed3 users and GeoServer developers.

Attending

Agenda

  1. Datasets/instances for Ben to complete use case 2 geoserver tests
  2. WFS query Function Specifications
    • Agree on the exact query and spec for what is returned
    • Agree on what geoserver needs to do to handle the results
    • Discuss what we as 'oracle' [and PostGIS! - AR] data servers need to implement oracle function side before Ben can implement and test use case 3 - and before other implementations of query function handling e.g. Paul can build that handler?
  3. Dale to explain Ollie's powerpoint 'blast'.
  4. Consistency of testbed instance documents e.g. mapped unit example - where we go from here

Minutes

1. Ben's needs to better test and finish testbed Usecase 2 support in Geoserver was discussed

It was agreed that Dale, GA and Alistair, GSV were to supply Ben with datasets in the form of SQLDDL to include creating the postgis/oracle tables for these datasets for usecases 2A, 2B, 2C and 2D (shear displacement?) and Marcus, BGS to provide the same for 2D (boreholes). In parallel final TB3_UC instance documents would be placed in the instance repository, including mapping comments, and Ben directed to them.

2. Consensus on the profile of each usecase instance return

With the very recent placing of example instance documents by BGS, GA, GSV, BRGM and GSC for all use cases in the repository John Laxton as actioned was about to propose, for testbed participant agreement, consensus profiles for each using instance documents and the profile .EAP file as documentation. These agreed profiles would form the basis for his 'How to map your data to GeosciML' cookbook which was to be published with GeoSciML v2.0 i.e. August 10th. The instance documents associated with the above SQLDDL datasets should be of this final agreed consensus form and ir was requested therfore that this consensus was reached very early next week. John Laxton/Marcus would be asked to action gaining this consensus from Friday 6th. Alistair's excel spreadsheet of instance differences and a recent discussion with Eric would aid this work.

3. Usecase 3 Filter 1.1 Query format and passed to back-end database Function functionality

Tim had requested this item on the agenda before Ollie's post-testbed powerpoint proposal on this came in, as Tim believed we needed consensus on the precise form of both the Filter 1.1 queries for usecase 3 and what was to be expected of the passed Function's (and therefore what was to be expected of middleware like Geoserver trying to deal with such functions so that Ben could plan for it). As it happened Eric had put up new visible implementations of such functions here: http://ngwd-bdnes.cits.rncan.gc.ca/service/geosciml/page/gsmltb3.html with documentation here: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/CocoonTB3Implementation and here: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/Testbed3FunctionImplementation. It was noted the BRGM registry had put up earlier examples of such queries and would be updating them very shortly see here: http://tellus.brgm.fr/GeoSciMLWeb/testbed/middleware.jsp - choose * open * top left then uc3 QUERY and WFS (as documented in the 6th May mailing to all testbed participants).

Nobody could find fault with Eric's query implementation and so it was accepted as the consensus. It was noted that the definition for the structure for returned results from the 'Function' queries was defined by the usecase 3 instance documents and the imminent consensus on that would determine that. Ben explained that when he moved onto implementing usecase 3 in Geoserver he would need more time to consider the specification of that implementation than actually to write the implementation as much 'work; would be done by the Functions within each surveys back-end database.

Olli'e powerpoint was discussed and the consensus was that Eric's response to it - backed up by Rob Atkinson's confirmation that Eric understoof the issue in pointing out that dealing with the hierarchical issue was a major part of why we needed Functions for now (and was apparently why we moved to this form of the filter query proposed at Orleans). The xpath issue was not mentioned in the 'preferred solution' slide although it somewhat confusingly still had a Function used within it's example. It was pointed out again that a testbed result to be reported at Uppsala may well be that we need to request OGC to improve the Filter 1.1. spec to handle more easily such queries to complex-feature schemas in the future.

4. Next Geoserver development iteration

This was noted to contain most of the previous iterations work still outstanding and no new version of Geoserver to handle use case 2 had yet been published, but Ben wished to emphasise that he had not been held up due to lack of correctly documented datasets and instances - he had had to work on getting his xmlservice tester working and this he had nearly completed. Further work would be held up unless we could get him the datasets and consensus instances quickly ( see item 2 above). The issue of getcapabilities not working in the latest complex feature geoserver version had in fact been very quickly fixed (it had been noted that it worked in previous versions). The outstanding issue of Describefeature also no longer working was agreed to only be tackled once usecases 2 and 3 were working. The registration of feature services in the testbed Registry provided by Jean-Jacques would negate the current need for describefeature to be working for testbed purposes.

The new rather fundamental issue of codespace population not working even in old Geoserver trunk versions was discussed at length and Ben stated that he had a plan for dealing with this agreed with Rob Atkinson see https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverIteration2008Jun1. It was noted that multi-tiered approach temporary solutions to this might be applicable before this solution is implemented. [BUT it was decided to fix this bug in the current development iteration (GeoserverIteration2008Jun1) -- AlistairRitchie - 06 Jun 2008]

5. Need for an email list to aid Geoserver development for testbed 3

Ben requested that, rather than relying on twiki responses which were varaible and not rapid (few had used the geoseerver feedback twiki page) and he needed to move fast and get feedback fast , could someone host an email list with an enlarged membership (people would be encouraged to remove themselves form the list if not interested)? Ben agreed to ask if could find an offer for hosting such a list and Alistair also (it was noted that GA and BGS were unlikely to be able to to).

-- TimDuffy - 05 Jun 2008
Topic revision: r7 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).