NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Max-- as for the range set, Andrew points to a CR that seems useful for us. I have to check the range issue, together with the other items, against the current status of discussion & existing CRs with GML as a next step.
- as for the file linking, there is a provision in gml:
<complexType name="RangeSetType">
<choice>
<element ref="gml:ValueArray"
maxOccurs="unbounded"/>
<element ref="gml:AbstractScalarValueList"
maxOccurs="unbounded"/>
<element ref="gml:DataBlock"/>
* <element ref="gml:File"/>
* </choice>
</complexType>
<complexType name="FileType">
<sequence>
<element ref="gml:rangeParameters"/>
<choice>
<element name="fileName" type="anyURI">
<annotation>
<appinfo>deprecated</appinfo>
</annotation>
</element>
* <element name="fileReference" type="anyURI"/>
* </choice>
<element name="fileStructure" type="gml:CodeType"/>
<element name="mimeType" type="anyURI"
minOccurs="0"/>
<element name="compression" type="anyURI"
minOccurs="0"/>
</sequence>
</complexType>
Andrew, with his proposal, wants to spice up ValueArray instead (see
http://portal.opengeospatial.org/files/?artifact_id=31487).
Unfortunately all the XML schema there is in screenshots so I don't want
to append here, and don't want to retype it either.
-Peter Woolf, Andrew (STFC,RAL,ESC) wrote:
Note the GML SWG is considering a CR (08-157) to add the ISO 19123 rangeType attribute to GML coverages, this gives a hook to be explicit about range semantics.*From:* Max Martinez [mailto:Max.Martinez@xxxxxxxxx] *Sent:* 20 August 2009 13:22 *To:* Woolf, Andrew (STFC,RAL,ESC); Peter Baumann*Cc:* Robin, Alexandre; Ben Domenico; Unidata Techies; Unidata GALEON; Carl Reed; wcs-2.0.swg *Subject:* RE: GML coverages / xlink (was: Re: [WCS-2.0.swg] CF-netCDF standards initiatives)Peter, et al.I think this is useful for what we are trying to do but there are still issues to resolve. As I point out here <https://portal.opengeospatial.org/twiki/bin/view/WCS2x0swg/ServiceUsingGmlCoverages>, if you are going to use gml:AbstractCoverage derivatives as your encoding for coverage information, then you want to be sure that as much metadata as possible is obtainable without following a link to the attribute values. Something needs to plug the gap between WCS’s range Fields and gml’s void on the subject (although rangeParameters seems to be where some people [GMLJP2?] think this gap is going to be at least partially filled).I was also unaware that there was a dispute about referencing a file of a specified format for pixel values. We have been talking about this for a while, at least with respect to the File RangeSetType. What specific mails from the thread are you referring to?Max------------------------------------------------------------------------ *From:* Woolf, Andrew (STFC,RAL,ESC) [mailto:andrew.woolf@xxxxxxxxxx] *Sent:* Thursday, August 20, 2009 7:29 AM *To:* Peter Baumann*Cc:* Robin, Alexandre; Max Martinez; Ben Domenico; Unidata Techies; Unidata GALEON; Carl Reed; wcs-2.0.swg *Subject:* RE: GML coverages / xlink (was: Re: [WCS-2.0.swg] CF-netCDF standards initiatives)<RectifiedGridCoverage id="tos_O1_2001-2002"> <domainSet> <RectifiedGrid dimension="3" id="tos_O1_2001-2002.domain"> <limits> <GridEnvelope> <low>0 0 0</low> <high>23 169 179</high> </GridEnvelope> </limits> <axisLabels>x y t</axisLabels> <origin><Point id="tos_O1_2001-2002.domain.origin" srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d"><pos>-79.5 1 1</pos> </Point> </origin><offsetVector srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">1 0 0</offsetVector> <offsetVector srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">0 1 0</offsetVector> <offsetVector srsName="urn:x-ogc:def:crs:badc:TimeLatLon:2001-01-01:1d">0 0 2</offsetVector></RectifiedGrid> </domainSet> <rangeSet> <ValueArray gml:id="tos_O1_2001-2002.range"> <valueComponentxlink:href="http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc#tos"; xlink:role="urn:mimetype:application/x-netcdf" xlink:arcrole="QuantityList"><QuantityList uom="K"/> </valueComponent> </ValueArray> </rangeSet> </RectifiedGridCoverage>(The referenced CRS is a composite using a TM_CoordinateSystem (gml:TimeCoordinateSystem) for time, with origin 2001-01-01 and interval ‘one day’.)Our current CR 07-112 will enable analogous use of CF-netCDF files using ‘auxiliary coordinate variables’ for a gml:ReferenceableGrid.Cheers, Andrew*From:* Peter Baumann [mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx] *Sent:* 20 August 2009 10:50 *To:* Woolf, Andrew (STFC,RAL,ESC)*Cc:* Robin, Alexandre; Max Martinez; Ben Domenico; Unidata Techies; Unidata GALEON; Carl Reed; wcs-2.0.swg *Subject:* GML coverages / xlink (was: Re: [WCS-2.0.swg] CF-netCDF standards initiatives)Andrew- I anyway wanted to contact you on the xlink question.Your approach as presented at the Boston TC meeting I consider the missing link for WCS: we consider coverages delivered as a manifest (XML) and one or more encoded files, referenced from the manifest. It seems like your approach allows to mimic this in GML. Is that correct?As we currently are seriously considering adopting GML for the WCS 2.0 coverage model such a facility is of high importance to us.-PeterPS: this might also resolve the dispute of this thread: GML coverages can well reference a netCDF file then, can't they?Woolf, Andrew (STFC,RAL,ESC) wrote:I’d say the same thing about GML – it’s already possible to use GML to provide a canonical encoding linked to an underlying conceptual model *AND xlink to netCDF for the actual content*.Andrew*From:* wcs-2.0.swg-bounces+andrew.woolf=stfc.ac.uk@xxxxxxxxxxxxxxxxxxxxxxxx <mailto:wcs-2.0.swg-bounces+andrew.woolf=stfc.ac.uk@xxxxxxxxxxxxxxxxxxxxxxxx> [mailto:wcs-2.0.swg-bounces+andrew.woolf=stfc.ac.uk@xxxxxxxxxxxxxxxxxxxxxxxx] *On Behalf Of *Robin, Alexandre*Sent:* 20 August 2009 09:16 *To:* Max Martinez; Ben Domenico; Peter Baumann *Cc:* Unidata Techies; Unidata GALEON; Carl Reed; wcs-2.0.swg *Subject:* Re: [WCS-2.0.swg] CF-netCDF standards initiativesFYI,SWE Common can serve to send very efficiently packaged datasets (binary, compressed binary) just like NetCDF does while providing robust metadata describing the datasets.These datasets can be N-D grid coverages, discrete coverages, or any other kind of sensor observations or model results.The point for us to build SWE Common rather than just reusing NetCDF was to support efficient random access in huge datasets and real time streaming data (which NetCDF is not designed for) with a single model.Both cases are supported and I am pretty sure we can generate a SWE Common encoded binary stream that is byte-to-byte compatible with the data section of a NetCDF file.Developing a module for the NetCDF API dealing with SWE Common would be quite trivial thanks to the harmonization work we have already done.Regards,------------------------------------------------- *Alexandre Robin* Spot Image, Web and E-Business Tel: +33 (0)5 62 19 43 62 Fax: +33 (0)5 62 19 43 43 http://www.spotimage.com Before printing, think about the environment------------------------------------------------------------------------ *De :* Robin, Alexandre *Envoyé :* jeudi 20 août 2009 10:01 *À :* 'Max Martinez'; Ben Domenico; Peter Baumann *Cc :* Unidata Techies; Unidata GALEON; wcs-2.0.swg; 'Carl Reed' *Objet :* RE: [WCS-2.0.swg] CF-netCDF standards initiativesBen,I hope we don’t have to define a NEW standard but rather work with you to see how we can treat your use cases with SWE Common (which already incorporates some NetCDF concepts and is VERY close to NcML).I already looked at the issue and writing a converter (even the ‘on the fly’ kind) between the two formats should be no problem at all.Bringing legacy formats (be them pseudo-defacto standards of a community) into OGC is NOT going to help interoperability across domains…Regards,------------------------------------------------- *Alexandre Robin* Spot Image, Web and E-Business Tel: +33 (0)5 62 19 43 62 Fax: +33 (0)5 62 19 43 43 http://www.spotimage.com Before printing, think about the environment------------------------------------------------------------------------*De :* wcs-2.0.swg-bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx <mailto:wcs-2.0.swg-bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx> [mailto:wcs-2.0.swg-bounces+alexandre.robin=spotimage.fr@xxxxxxxxxxxxxxxxxxxxxxxx] *De la part de* Max Martinez*Envoyé :* jeudi 20 août 2009 03:19 *À :* Ben Domenico; Peter Baumann *Cc :* Unidata Techies; Unidata GALEON; wcs-2.0.swg *Objet :* Re: [WCS-2.0.swg] CF-netCDF standards initiativesBen,What exactly is an “OGC binary encoding standard”? Is CF-netCDF attempting to be the first of its kind or are there other examples?Max------------------------------------------------------------------------*From:* wcs-2.0.swg-bounces+max.martinez=erdas.com@xxxxxxxxxxxxxxxxxxxxxxxx <mailto:wcs-2.0.swg-bounces+max.martinez=erdas.com@xxxxxxxxxxxxxxxxxxxxxxxx> [mailto:wcs-2.0.swg-bounces+max.martinez=erdas.com@xxxxxxxxxxxxxxxxxxxxxxxx] *On Behalf Of *Ben Domenico*Sent:* Wednesday, August 19, 2009 1:19 PM *To:* Peter Baumann *Cc:* Unidata Techies; Unidata GALEON; wcs-2.0.swg *Subject:* [WCS-2.0.swg] CF-netCDF standards initiativesHello,Some confusion has resulted from the fact that we are pursuing two parallel efforts at standardizing CF-netCDF within the OGC. The first initiative began a few years ago. The goal is to establish CF-netCDF as an extension standard for WCS encoding of data in binary form. Stefano Nativi just sent out an email announcing the latest revision of the proposed "discussion paper" on that topic. This will be discussed and hopefully voted on at the September/October TC meeting.At the same time, we have a new initiative to establish CF-netCDF as a separate OGC binary encoding standard. This approach will result in a binary encoding which can be used with different access protocols, e.g., WFS or SOS as well as WCS. Of course, in the long run, our objective is to tie the two approaches together, but we do not want to impede progress on either right now by making them formally interdependent. A very rough draft of the core standard for CF-netCDF is on the GALEON wiki at:http://sites.google.com/site/galeonteam/Home/cf-netcdf-candidate-standardAs you can see, the draft for the OGC core is based on the NASA Earth Science Data System standard (NASA ESDS-RFC-011v1.00). We hope to have this candidate standard in the proper OGC template form by the September/October TC and will have an ad-hoc session at which we plan to establish a SWG. Since there is already a large community of practice, endorsement by other standards groups (NASA and NOAA in the US), and solid reference implementations, we hope to move forward quickly with this standard.We would very much like to have as many liaisons as possible between the WCS and CF-netCDF working groups to ensure that they are kept in harmony.-- Ben-- Scanned by iCritical.-- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann> mail: p.baumann@xxxxxxxxxxxxxxxxxxxx <mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx> tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 147737) www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@xxxxxxxxxxxx <mailto:baumann@xxxxxxxxxxxx> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "A brilliant idea is a job halfdone."-- Scanned by iCritical.-- Scanned by iCritical.
-- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@xxxxxxxxxxxxxxxxxxxx tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 147737) www.rasdaman.com, mail: baumann@xxxxxxxxxxxx tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "A brilliant idea is a job halfdone."
galeon archives: