[auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Wed May 25 11:47:18 EDT 2011

Hi Stephen,

The latest version Fullmoon takes into account the nillable property of an attribute. It is specified in a specific tagged value.

François

François Létourneau
Professionnel de recherche - géomatique / TI
Institut national de la recherche scientifique
Centre Eau Terre Environnement - Centre Géoscientifique de Québec
490, de la Couronne, bureau 3344
Québec (Québec) G1K 9A9 

-----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 Stephen Richard
Envoyé : 25 mai 2011 11:38
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

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/Interoperabi
> lity
> 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/GeoSciMLv3Design
> Pro
> posals#16_gsml_Map, and
> https://www.seegrid.csiro.au/wiki/CGIModel/Quebec2009ModelDesignTaskGr
> o 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/Interoperabi
> lity
> 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

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml