"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"

Teleconference on 6436 8994 (AndyDent taking minutes so apologies if any names missed or comments mis-attributed due to poor voice recognition by the organic unit)

Attendees: StuartGirvan, RobAtkinson, PeterBarrs, BrendonWard, GregoryJenkins, AndyDent, TerryHannant, StephenBandy, AndyDent, SimonCox

MarkJolly ??

Apologies: RobertWoodcock


New Issues and Current Status

  • GA - geoserver WFS is working but spatial queries still limited by Oracle problem
  • PIRSA - working
  • GSWA WFS queries running, final mapping tasks hopefully finished today
  • Stylesheets - minor work to reconfigure one column & use preferred uom parameter, waiting to test services
  • Units of Measure (UOM) - largely resolved with minor work coming from agreement to use GA uom table


Is there light at the end of the tunnel?

From RobAtkinson's point of view, he needs a list of here's the units people will use.

The stylesheet could portray using a common unit which is the one searched on, if the WFS aren't sending back the correct unit.

The stylesheet would be invoked with a preferred unit and would do conversion to that preferred unit.

StuartGirvan worried about converting units on the fly incoming, performance hit. Wants preferred units of measure per analyte.

The concern about passing in UOM in the query is that it is not clearly represented as an attribute in the WFS query object so people may not think the query is a scaled number but a value=1 AND uom='ppm' style of query.

ProjectScenarioImplementations contains list of units trimmed down.

Could we have two feature types, one normalised?

StuartGirvan - normalised would not be a problem

RobAtkinson - needs to be more user friendly with ability to specify uom, how about scale value is passed in the query? - analyte code, threshold value & uom multiplier - user sees human name of analyte & multiplier (eg: ppm) and textbox for value entry.

If we pass in a scaling number, SimonCox suggested could be concatenated into scientific notation. AndyDent pointed out this rules out user entry of a scientific notation figure.

SimonCox said units like Teslas can't be represented as scaling factors.

If using a text field to lookup scaling factors on server, which implementors are happy with, need to agree on uom labels - SimonCox pushing UCUM compatibility.

Decision - pass UOM using StuartGirvan's table for this implementation.


will change to Range representation as per discussion with SimonCox

AndyDent to liase with RobAtkinson to put stylesheets onto servers, PIRSA server now available to test.

StuartGirvan still wrestling with Oracle spatial, can put out two feature types - query by ID and Threshold but not spatial queries. Now working with Peter Barrs (?) to try to solve that.

BrendonWard has queries running, hopes to finish mapping to server today.

Lesley is in Perth on Monday so we hope to have something to show at that seminar

RobertWoodcock needs to write final AusIndustry report by end of next week so can submit by the 7th Dec.

Issue - can we see the PIRSA server from inside CSIRO? RobAtkinson had problems - tested ports 4662 & 4663.

RobertCheung will be relied on to solve this with the CSIRO IT guys. get back to Terry & RobAtkinson.

Server on 4662 not running now.

StuartGirvan has code to do query, will forward to others as requested.

By next meeting:
  • WFS's for all surveys will be active and producing desired XMML output (assuming GA oracle problem can be sorted out)
  • Web Map Composer will be hooked up with the stylesheets and survey WFS.
  • Stylesheets corrected to remove current Range column based on detection threshold and use the preferred uom, converting returned values.

Next Meeting: 2 Dec 2004 9:30 am (WST)
Topic revision: r2 - 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).