[Auscope-geosciml] [SEC=UNCLASSIFIED]

Wed Mar 3 21:08:01 EST 2010

looks like swe:vector is the way to go

On 3/1/2010 8:40 PM, Oliver.Raymond at ga.gov.au wrote:
>
> Many thanks Alex and Simon.  That has cleared things up nicely.  Now I 
> have to get my geophysicist to decide which option to take....
>
> Regards,
>
> Ollie
>
> /------------------------------------------------------------------------------------------------/
>
> /Ollie Raymond
> National Advice,  Maps and Standards Project/
>
> */Geoscience /**/Australia/*
>
> */ /*
>
> *Address:* GPO Box 378, Canberra, ACT, 2601, Australia *|* *ABN:* 80 
> 091 799 039
>
> *Ph:* (02) 62499575 *|* *Fax:* (02) 62499992 *|* *Email: 
> *Oliver.Raymond at ga.gov.au
>
> *Web:* 
> http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
>
> *Google Map 
> <http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1> 
> *
>
> -- This message was created with 100% recycled electrons --
>
> -----Original Message-----
> *From:* Simon Cox [mailto:simon.cox at jrc.ec.europa.eu]
> *Sent:* Friday, 26 February 2010 9:47 PM
> *To:* 'Robin, Alexandre'; Raymond Oliver
> *Cc:* auscope-geosciml at lists.arcs.org.au
> *Subject:* RE: [SEC=UNCLASSIFIED]
>
> Very nice explanation Alex.
>
> I would add just one point: if you expect that a CRS (whether geodetic 
> or not) will be re-used, then it is good practice to 'register' it 
> somewhere, and thus obtain an identifier that can be used to reference 
> it. This strategy generally assists interoperability since it allows
>
> (a) software developers to pre-configure applications to support 
> registered CRSs, and
>
> (b) data producers to refer to a pre-defined CRS using an identifier 
> rather than by description (the latter makes comparison laborious and 
> error prone).
>
> --------------------------------------------------------
> *Simon Cox
> *
> European Commission, Joint Research Centre
> Institute for Environment and Sustainability
> Spatial Data Infrastructures Unit, TP 262
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox at jrc.ec.europa.eu
> http://ies.jrc.ec.europa.eu/simon-cox
>
> SDI Unit: http://sdi.jrc.ec.europa.eu/
> IES Institute: http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
>
> --------------------------------------------------------
>
> Any opinions expressed are personal unless otherwise indicated.
>
>     ------------------------------------------------------------------------
>
>     *From:* Robin, Alexandre [mailto:Alexandre.Robin at spotimage.fr]
>     *Sent:* Friday, 26 February 2010 11:21
>     *To:* Oliver.Raymond at ga.gov.au; simon.cox at jrc.ec.europa.eu
>     *Cc:* auscope-geosciml at lists.arcs.org.au
>     *Subject:* RE: [SEC=UNCLASSIFIED]
>
>     Hello Oliver,
>
>     The main reason for the SWE Common vector is the management of CRS.
>
>     In GML, a vector is given as:
>
>     <gml:DirectionVector>
>
>     <gml:vector srsName="#myLocalMagneticCRS">0.0 2.3 4.5</gml:vector>
>
>     </gml:DirectionVector>
>
>     You can see that it relies on a CRS defined externally, and this
>     CRS must include the definition of units for each coordinate. This
>     is a model that works well for geodetic CRS that are shared by
>     many people but not necessarily for local CRS that are typically
>     redefined for each problem. In SWE we thought that it is too
>     constraining to force the definition of a new out-of-band CRS for
>     each case.
>
>     Your example is a very good one where the projected quantity is
>     not a distance and thus it is very unlikely that somebody else has
>     already defined the exact same combination of spatial axes and
>     magnetic field units.
>
>     For this reason, SWE does things slightly differently by relying
>     on an external CRS or datum to define only an origin and axes
>     directions in space (like it is usually done in physics) while
>     units are defined inline in the vector instance. This is shown below:
>
>     <swe:Vector referenceFrame="#myLocalCRS"
>     definition="urn:...:MagneticField">
>
>     <swe:coordinate name="x">
>
>     <swe:Quantity>
>
>     <swe:uom code="T"/>
>
>     <swe:value>0.0</swe:value>
>
>     </swe:Quantity>
>
>     </swe:coordinate>
>
>     <swe:coordinate name="y">
>
>     <swe:Quantity>
>
>     <swe:uom code="T"/>
>
>     <swe:value>2.3</swe:value>
>
>     </swe:Quantity>
>
>     </swe:coordinate>
>
>     <swe:coordinate name="z">
>
>     <swe:Quantity>
>
>     <swe:uom code="T"/>
>
>     <swe:value>4.5</swe:value>
>
>     </swe:Quantity>
>
>     </swe:coordinate>
>
>     </swe:Vector>
>
>     This obviously means that the same set of axes (usually Cartesian
>     but not necessarily) can be reused for many different types of
>     vectors. For instance a typical example in mechanics is to express
>     location but also velocity and acceleration in the same reference
>     frame. In GML this would mean defining a CRS for each of these,
>     with the risk that the connection between them is lost (unless the
>     same Datum is used perhaps), while in SWE Common the same frame is
>     reused and only the units of the coordinates and the definition of
>     the vector are adjusted.
>
>     Not that if efficient encoding is used, SWE Common also allows you
>     to group several magnetic vector of this kind in an efficient CSV
>     type block.
>
>     Hope this clarifies the matter...
>
>     Cheers,
>
>     -------------------------------------------------
>
>     **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 :* Oliver.Raymond at ga.gov.au [mailto:Oliver.Raymond at ga.gov.au]
>     *Envoyé :* vendredi 26 février 2010 05:22
>     *À :* simon.cox at jrc.ec.europa.eu; Robin, Alexandre
>     *Cc :* auscope-geosciml at lists.arcs.org.au
>     *Objet :* [SEC=UNCLASSIFIED]
>
>     Hi Alex, Simon,
>
>     Could you give some advice please on the use of 'Vector' in GML
>     and SensorML.  I am trying to model a measurement of remanent
>     magnetisation, which involves a directed (vector) measurement of
>     the magnetic field and need to know which one to use.
>
>     Was the SWE modelling team concerned that the GML Vector element
>     could not handle all types of vectors?  Does the SWE Vector class
>     supersede the GML Vector class, or is it designed for a different
>     purpose?
>
>     Regards,
>
>     Ollie
>
>     /------------------------------------------------------------------------------------------------/
>
>     /Ollie Raymond
>     National Advice,  Maps and Standards Project/
>
>     */Geoscience /**/Australia/*
>
>     */ /*
>
>     *Address:* GPO Box 378, Canberra, ACT, 2601, Australia *|* *ABN:*
>     80 091 799 039
>
>     *Ph:* (02) 62499575 *|* *Fax:* (02) 62499992 *|* *Email:
>     *Oliver.Raymond at ga.gov.au
>
>     *Web:*
>     http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
>
>     *Google Map
>     <http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>
>     *
>
>     -- This message was created with 100% recycled electrons --
>
>
> _______________________________________________
> Auscope-geosciml mailing list
> Auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100303/a833dbc4/attachment.htm>