[auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Stephen Richard steve.richard at azgs.az.gov
Wed May 25 11:38:17 EDT 2011


How does fullMoon know what is nillable? Are we manually going into the
generated schema and setting that property on xml elements? If so, it makes
sense to have a known stereotype in the model to flag  nillable elements.
Since we are generating the 'base' xml schema for GeoSciML, from which
profiles would be derived, it does seem like a model level assertion.
Profiles may choose to modify the nillability in a manner consistent with
the base schema.
steve

Stephen M. Richard
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701   USA
phone: 520 209-4127
AZGS Main: (520) 770-3500.  FAX: (520) 770-3505
email: steve.richard at azgs.az.gov

> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> Sent: Sunday, May 15, 2011 5:06 PM
> To: auscope-geosciml at lists.arcs.org.au
> Cc: A.Woolf at bom.gov.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> Hi Rob,
> 
> As far as I can tell, the only reason for inventing a "voidable"
stereotype is to
> make a way of displaying in a UML diagram: "This element has a tagged
value of
> <nillable = true>".  (I'm happy to be told otherwise if I have missed
something.)
> So for me, the "voidable" stereotype is just decoration on a "nillable"
tagged
> value and I have similar reservations to you about inventing a stereotype
for this
> purpose.
> 
> Cheers,
> Ollie
> 
> 
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Rob.Atkinson at csiro.au
> Sent: Monday, 16 May 2011 9:39 AM
> To: auscope-geosciml at lists.arcs.org.au
> Cc: A.Woolf at bom.gov.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> Personally I am getting very uneasy about the proliferation of stereotypes
- it's
> starting to have significant interoperability impact on our (collective)
ability to
> model consistently and provide tooling, and ultimately be able to reuse
concepts
> across domain boundaries.
> 
> INSPIRE has done this, ISO 19156 O&M is implementing a proposed change,
> GeoSciML has introduced estimatedProperty (does anyone else use this?) etc
> 
> There are obviously good reasons, and issue with 19103 and/or 19109 - and
> perhaps we'll get some utopian view where these standards are updated to
> encompass all the proposals and usages. Alternatively we need a mechanism
for
> handling unknown and multiple stereotypes. Ignoring ones you don’t
understand
> seems sensible, but maybe we also need a register of these an extension
point
> within the ISO framework to avoid re-inventing the wheel?
> 
> Is the stereotype really a meta-class (voidable) - or this an
implementation hint,
> or is this an aspect of the model that simply needs a home within the UML?
The
> former smells bad and leads to problems as seen - but has been used by
INSPIRE,
> so are we stuck with it?
> 
> On a side note, Simon and I found the need to extend the meta-model with
the
> ownedBy tagged value (arguably this is a hint for certain types of
> implementation which maintain scoped attribute names and inheritance
> patterns). Nevertheless profiling patterns need some special attention. Is
> voidability really an implementation profile issue? Should it thus be a
decoration
> of some type, not an inherited meta-class?
> 
> Rob
> 
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> Sent: Monday, 16 May 2011 8:51 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> The issue that I was trying to describe is that we have attributes that
already
> have a stereotype (estimatedProperty [I mistakenly called it
estimatedValue
> earlier]). To stereotype these attributes as "voidable" we would have to
either a)
> discontinue the use of the "estimatedProperty" stereotype so we can use
> "voidable" where required, or b) create a new stereotype called
> "voidableEstimatedProperty" for those attributes which are both voidable
> (nillable) and estimated.
> 
> Comments?
> 
> 
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Friday, 13 May 2011 11:02 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> Not really -
> (i) if the encoding rule says 'ignore any stereotype you don't recognise'
we're
> just fine
> (ii) anyway, this stereotype is being considered in the revision of ISO
> 19103/19109
> 
> Simon Cox
> Research Scientist
> CSIRO Earth Science & Resource Engineering
> 
> Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672
> simon.cox at csiro.au | www.csiro.au
> Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia
> ________________________________________
> From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> [Oliver.Raymond at ga.gov.au]
> Sent: Friday, 13 May 2011 3:42 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> Thanks Simon, I’ll look into it.  I think we may run into trouble where we
have
> already used the non-standard stereotype “estimatedValue” on some
attributes.
> 
> _________________________________________________________________
> ______
> 
> Ollie Raymond
> 
> Project Leader
> National Geological Maps and Data Standards
>
Project<http://www.ga.gov.au/minerals/projects/current-projects/geological-
> maps-standards.html>
> Geoscience Australia
> 
> Interoperability Working
> Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/Interoperability
> WG>
> IUGS Commission for the Management and Application of Geoscience
> Information
> 
> Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
> Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email:
> oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>  |  Google
> Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+austra
> lia&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 ---
> 
> ________________________________
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Friday, 13 May 2011 5:38 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> P.S. INSPIRE uses the stereotype <<voidable>> to accomplish the same
effect.
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
> Sent: Friday, 13 May 2011 11:20 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: [ExternalEmail] Re: [auscope-geosciml] MappedFeature
> [SEC=UNCLASSIFIED]
> 
> Ollie – AFAIK you can’t display tagged values assigned to class attributes
in a
> UML diagram.
> What you might consider is *also* assigning a _stereotype_ <<nillable>>,
which
> you can display in UML.
> I think unrecognized stereotypes are ignored by FullMoon, so this provides
a way
> to make it show up.
> 
> (We could also argue whether ‘nillable’ is a conceptual or implementation
issue,
> which is the usual boundary for use of stereotype or tagged value UML
> extension points.)
> 
> Simon
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
> Sent: Friday, 13 May 2011 11:03 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
> 
> Hi John
> 
> Apologies for my late reply on this one.
> 
> 
>  1.  All attributes of MappedFeature are mandatory-but-nillable in
GeoSciML v3.
> 
> (SIDEBAR: Is there a way of displaying the “nillable” tag on a UML
diagram?  I
> have had to explain many times to users that although an element is shown
as
> mandatory on a GeoSciML v3 UML diagram, it may be nillable and it doesn’t
> necessarily mean that you have to deliver content for that element.)  2.
The xml
> for observationMethod, resolutionScale and PositionalAccuracy entails
between
> 16 lines (with full data content) and 3 lines (if nilled) of xml per
feature.  If you
> were hand-coding the xml for each feature, then that would be a pain.  But
> you’re not – a computer is.  Is the issue that having an extra 16 lines of
xml per
> feature is too bulky for a WFS service?
>  3.  I have two Australian national datasets that are good examples of
datasets
> with variable feature-level metadata:
> 
> The Australian 1:1M scale national geology dataset (our prime national
geology
> map which we deliver to the OneGeology portal) is compiled from many
source
> maps of different scales and vintages, and so has different
positionalAccuracies
> for features in different parts of the map.
> 
> We also have a national dataset which captures the outlines of geological
> provinces (eg, basins, cratons, etc).  Segments of these outlines are
compiled
> from different sources (like outcrop mapping, magnetic interpretation,
seismic
> interpretation, drilling) and so have different observationMethods for
these
> features within the dataset.
>  4.  Steve proposed a gsml:Map element back in 2008 which appears to cover
> what you require with delivering scale, accuracy, etc for a whole set of
mapped
> features.
> (https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciMLv3DesignPro
> posals#16_gsml_Map, and
> https://www.seegrid.csiro.au/wiki/CGIModel/Quebec2009ModelDesignTaskGro
> upAgenda).  But we never followed through with it after Quebec.  As
indicated
> by Eric and others, I think that there needs to be much more discussion,
before
> we add gsml:Map to GeoSciML, on how a client would know how to resolve
> metadata for different WFS datasets that could potentially deliver their
> metadata at either a) feature level or b) map level.
>  5.  I am more than happy to accommodate INSPIRE’s requirements in
GeoSciML
> if they also have general application outside the INSPIRE use cases (eg,
we have
> adopted some of the borehole attributes suggested by INSPIRE).  If INSPIRE
has
> more complicated requirements of GeoSciML, like this one appears to be, I
> would love to see UML examples from INSPIRE of how INSPIRE’s needs could
be
> accommodated by extending or changing GeoSciML while still maintaining the
> more general application of GeoSciML to the wider geological community.
> I really appreciate the role you are playing in “running point” for
GeoSciML
> within the INSPIRE network.
> 
> Cheers,
> Ollie
> 
> _________________________________________________________________
> ______
> 
> Ollie Raymond
> 
> Project Leader
> National Geological Maps and Data Standards
>
Project<http://www.ga.gov.au/minerals/projects/current-projects/geological-
> maps-standards.html>
> Geoscience Australia
> 
> Interoperability Working
> Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/Interoperability
> WG>
> IUGS Commission for the Management and Application of Geoscience
> Information
> 
> Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
> Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email:
> oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>  |  Google
> Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+austra
> lia&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 ---
> 
> ________________________________
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Bruce.Simons at dpi.vic.gov.au
> Sent: Friday, 13 May 2011 9:59 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature
> 
> Hi John,
> Attached is a snapshot of the Symbol Legend from a GSV geological map from
> 2003 (done in ArcInfo pre our database rebuild based on GeoSciML).
> 
> Note that the symbol legend (contact and fault line types) has a variety
of line
> types based on perceived accuracy and interpreted method.(A snapshot of
the
> legend is below).  These have been mapped to various
gsml:positionalAccuracy
> values for our GeoSciML WFS.
> 
> Cheers
> 
> 
> 
> 
> ----------------------------------------------------
> Bruce Simons
> Senior Information Geoscientist
> IUGS-Commission for Geoscience Information Oceania Councillor GeoScience
> Victoria/Australian Spatial Research Data Commons Level 9, 55 Collins St
PO Box
> 4440 Melbourne, Victoria, 3001 Australia
> 
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
> 
> 
> 
> From:        "Laxton, John L." <jll at bgs.ac.uk>
> To:        "auscope-geosciml at lists.arcs.org.au" <auscope-
> geosciml at lists.arcs.org.au>
> Date:        12/05/2011 06:41 PM
> Subject:        Re: [auscope-geosciml] MappedFeature
> Sent by:        auscope-geosciml-bounces at lists.arcs.org.au
> ________________________________
> 
> 
> 
> Hi Bruce,
> 
> It is definitely perceived as a problem within the INSPIRE group, to the
extent
> that there is pressure to depart from GeoSciML which I strongly want to
avoid. I
> think the problem is that in practice nobody can actually think of a set
of
> MappedFeatures from a particular source (map or model) where these
> properties would vary between MappedFeatures (or at least that that
> information would be available) other than possibly for field maps (which
aren’t
> central to INSPIRE). Do your maps record this information? In OneGeology-
> Europe we found that in practice every service simply set a standard value
for
> these properties – which might differ between services but didn’t within a
> service. I am not suggesting these properties be dropped, simply that the
> cardinality be changed so they don’t have to be populated. Ideally we
would
> have an alternative method, such as metadata, to provide a single value
for this
> information for a complete data set, but from an INSPIRE point of view we
> could probably live without that as long as it isn’t essential we populate
these
> values for every MappedFeature. We could always handle the metadata
> separately in INSPIRE if GeoSciML doesn’t wish to adopt some standard
> approach for this.
> 
> On your second point cannot a single gml:FeatureCollection contain several
> GSML collections, each with its own metadata, where a response includes
data
> from different sources?
> 
> John
> 
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Bruce.Simons at dpi.vic.gov.au
> Sent: 12 May 2011 00:58
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature
> 
> There are two aspects I think need to be considered prior to heading too
far
> down the solution path:
> 
> 1. Is this really a problem?
> The reason the properties are on the MappedFeature is that they may vary,
even
> on the same map.  If this is not the case then they should be (only) on
the
> Metadata.  The fact that for a lot of maps these properties don't vary
doesn't
> mean they shouldn't be provided for each MappedFeature.
> 
> 2. If they should be on the Metadata then there needs to be a way of
identifying
> a "collection that is used to generate a specific map".
> Steve has raised this at previous meetings, but I'm not sure how it has
> progressed. This could possibly provide a method of indicating common
> metadata.
> 
> ----------------------------------------------------
> Bruce Simons
> Senior Information Geoscientist
> IUGS-Commission for Geoscience Information Oceania Councillor GeoScience
> Victoria/Australian Spatial Research Data Commons Level 9, 55 Collins St
PO Box
> 4440 Melbourne, Victoria, 3001 Australia
> 
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
> 
> 
> 
> From:        "Boisvert, Eric" <Eric.Boisvert at RNCan-NRCan.gc.ca>
> To:        <auscope-geosciml at lists.arcs.org.au>
> Date:        11/05/2011 09:51 PM
> Subject:        Re: [auscope-geosciml] MappedFeature
> Sent by:        auscope-geosciml-bounces at lists.arcs.org.au
> 
> ________________________________
> 
> 
> 
> 
> Still the same issue.  Can't tell if void == "don't know / don't care"
versus "it's in
> the metadata".  Unless this becomes the default pattern (get missing
values
> from metadata).
> But now, we run into the issue of binding a specific GeoSciML properties
to the
> values of a specific properties in the ISO-19115.  Some are obvious, some
aren't.
> 
> Actually, the problem has two sides:
> 
> 1- how can we define local "default" values
> 2- how can we link that default values to a value in iso-19115.
> positionalAccuracy is actually a swe Quantity.  The metadata property must
be
> one of this DQ_Element.  Should it be some way to tell the client app or
is it a
> "Moses shows up with stone tablets" kind of rule.
> 
> Eric
> 
> -----Message d'origine-----
> De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] De la part de Laxton, John L.
> Envoyé : 11 mai 2011 06:44
> À : auscope-geosciml at lists.arcs.org.au
> Objet : Re: [auscope-geosciml] MappedFeature
> 
> Maybe what we have here is a hierarchy of collections. The overall
collection
> delivered is a gml:FeatureCollection but within that we can have distinct
GSML
> collections for features from different sources, each of which could have
its
> own metadata. Having distinct source metadata would be useful anyway,
apart
> from the positionalAccuracy and resolutionScale problem.
> 
> John
> 
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: 11 May 2011 11:18
> To: auscope-geosciml at lists.arcs.org.au; auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] RE : MappedFeature
> 
> >Cannot the metadata do this - as I recall there are 19115 properties for
> positional accuracy and spatial resolution?
> 
> it can. But how do we tell the client application that it should seek this
> information in the metadata ? (metadata of what actually ? metadata of the
> collection or the source dataset ? - there might be several sources in a
single
> collection).  If we use some pointer un positionalAccuracy to point to
metadata
> fragment, we are back to square one (this info is repeated for every
instance).
> 
> What you are looking for is a way to define "default" values or references
to
> subsitute to voided or missing properties and it should be valid for a
given
> dataset (not at the schema level).  Maybe generate one instance of
> MappedFeature at the top of the collection that has a role of "template"
(similar
> to GeologicFeature that can either be normative or instances) where all
the
> values are defined explicitly and when a property is missing/voided in any
> subsequent feature, the value must be drawn from the template instance
> assuming it's the same feature type.
> 
> too crazy ?
> 
> 
> ________________________________
> 
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Laxton, John
L.
> Date: mer. 2011-05-11 05:53
> À: auscope-geosciml at lists.arcs.org.au
> Objet : Re: [auscope-geosciml] MappedFeature
> 
> 
> 
> You could indeed represent the same GeologicFeature with different
> MappedFeatures (eg for maps at different scales) which would have
different
> values for positionalAccuracy and spatialResolution. But all the
MappedFeatures
> on either of those maps would almost certainly have the same value for
> positionalAccuracy and spatialResolution. As Eric says we want an easy way
to
> say these are the values for all MappedFeatures on this map, without
having to
> repeat the information on every single individual MappedFeature. Cannot
the
> metadata do this - as I recall there are 19115  properties for positional
accuracy
> and spatial resolution? We could then give the MappedFeature
> positionalAccuracy and spatialResolution properties a cardinality of
(0..1) and
> they would usually only be populated for field maps as these are the only
type of
> map where this information might either vary between or be known for
> individual MappedFeatures.
> 
> John
> 
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Dale.Percival at ga.gov.au
> Sent: 11 May 2011 10:40
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature
> 
> Isn't the concept to allow for different spatial representations to be
defined for
> a single feature? Or have I stated something obvious?
> 
> ....caffeine deprevation....
> 
> Dale Percival | Division Architect
> ________________________________
> 
> Information Development and Analysis Services Petroleum and Marine
Division
> Tel +61 2 6249 9265 | Mobile 0448 674 582 -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-
> bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
> Sent: Wednesday, 11 May 2011 7:34 PM
> To: auscope-geosciml at lists.arcs.org.au; Raymond Oliver
> Cc: auscope-geosciml at lists.arcs.org.au
> Subject: [auscope-geosciml] RE : MappedFeature
> 
> if voided, wouldn't it mean that the positionalAccuracy is "not known /
not
> available" as opposed to "known but always the same" ?
> 
> What would be neat is to have some way at the beginning of a feature
> collection to declare default values for voided (or missing) properties.
> 
> Eric.
> (cafeine kicking in)..
> 
> 
> 
> ________________________________
> 
> De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Laxton, John
L.
> Date: mer. 2011-05-11 05:19
> À: Oliver Raymond
> Cc: auscope-geosciml at lists.arcs.org.au
> Objet : [auscope-geosciml] MappedFeature
> 
> 
> Hi Ollie,
> 
> In the INSPIRE group there is some concern over the implications of the
> positionalAccuracy and resolutionScale properties of MappedFeature. At
present
> as I understand it these are not voidable so require to be provided for
every
> MappedFeature - which is potentially quite an overhead. In
OneGeology-Europe
> we just hard-coded in values for particular services (so all
MappedFeatures for a
> particular map service were given the same values), but clearly that is
really just
> duplicating information that could be in the metadata. Could these
properties be
> made voidable or have a (0..1) cardinality? In reality, at least where
maps other
> than field maps are concerned, the positionalAccuracy and resolutionScale
will
> always be the same for all MappedFeatures on a particular map.
> 
> John
> 
> 
> John Laxton
> British Geological Survey
> Murchison House
> West Mains Rd
> Edinburgh, EH9 3LA
> United Kingdom
> 
> Tel: +44 (0)131 667 1000
> Fax: +44 (0)131 668 1535
> email: jll at bgs.ac.uk
> Web site: www.bgs.ac.uk <http://www.bgs.ac.uk/> Internet Shop:
> www.thebgs.co.uk <http://www.thebgs.co.uk/>
> 
> 
> 
> 
> --
> This message (and any attachments) is for the recipient only. NERC is
subject to
> the Freedom of Information Act 2000 and the contents of this email and any
> reply you make may be disclosed by NERC unless it is exempt from release
under
> the Act. Any material supplied to NERC may be stored in an electronic
records
> management system.
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> 
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> Notice:
> This email and any attachments may contain information that is personal,
> confidential, legally privileged and/or copyright. No part of it should be
> reproduced, adapted or communicated without the prior written consent of
the
> copyright owner.
> 
> It is the responsibility of the recipient to check for and remove viruses.
> 
> If you have received this email in error, please notify the sender by
return email,
> delete it from your system and destroy any copies. You are not authorised
to
> use, communicate or rely on the information contained in this email.
> 
> Please consider the environment before printing this email.
> 
> 
> 
> 
> 
>  _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> 
> "D?#9?M4­Ÿ?8?7?-[1]8b?Vu??r?k'(?)?*'??jW(z{bjPQ?\+--
> u??mSLSM?????h??.???y?j^v?i'???-[1]*+¸?{-?m
> ???Ÿ?<??"?8?i|&"?z??X???*bz{m?rG???????Ÿ?<????l7!zz+???Xz?^jg??^???wj)]z
> Wz+_????'('b??m?xj???~??y?zf???SM?????(?????{c?-
> r?y?~?)?zf???SM?????"??)??
> 
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml




More information about the GeoSciML mailing list