[auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Mon May 30 10:01:05 EDT 2011


Hi John,

I suppose my "intended purpose" for a stereotype means that it has some intended function in encoding the xml schema.  At the moment, "voidable" stereotype serves no function beyond a label on a UML diagram, because the tagged value "nillable" contains the schema encoding functionality.  Maybe I am putting too much responsibility on the UML model - but that is how we have designed the GeoSciML UML model - it is almost a one-to-one UML-to-schema model (with the notable exception of "estimatedProperty" which we hope one day will be adopted more widely), so the elements in the UML all have a clear presence in the schema.

If the "voidable" stereotype served exactly the same purpose as the "nillable" tagged value (ie, to generate a "nillable" xml schema tag), and it would also be visible in a UML diagram, then that would be fabulous.  But I think we need to achieve a wide modelling community agreement on the encoding rules for the "voidable" stereotype, preferably beyond it being an visible advertising note for an existing "nillable" tagged value.

I read Michael's email with interest, noting that INSPIRE and GeoSciML are of one mind about the use of xsi:nil and "voidable" - at least for the time being :)  I agree with INSPIRE's conclusions about the difference between
"minimum multiplicity of 0" and "mandatory, but nillable".

Michael's comment that "You can automatically apply default values of tagged values associated with a stereotype to UML elements carrying the stereotype in EA." is reassuring to me.  I note that the HollowWorld tools for EA provide certain class templates with built-in tags, but there is no unbreakable link between the stereotype and the tagged values - ie, a user can add/delete tagged values from the class once it is created.  I think there would need to be a very tight link between the stereotype and tagged value in this case to ensure that encoding of a "nillable" tag linked to a "voidable" stereotype occurs.  That is, of course, unless we all come to an agreement to change the encoding rules so that FullMoon would generate a nillable element based on its "voidable" stereotype rather than its "nillable" tag.

Cheers,
Ollie



________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Monday, 30 May 2011 8:02 PM
To: auscope-geosciml at lists.arcs.org.au
Cc: michael.lutz at jrc.ec.europa.eu
Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Hi Ollie,

From an INSPIRE point of view the use of <<voidable>> in GeoSciML would be useful for consistency with the rest of INSPIRE – Michael can comment on whether there is an intention to submit it to ISO for inclusion in the standard.

I don’t see your point about this not being the intended purpose of stereotypes though. This is a consistent extension of meaning of the UML which is what stereotypes are for isn’t it?

John

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: 26 May 2011 01:53
To: auscope-geosciml at lists.arcs.org.au
Cc: michael.lutz at jrc.ec.europa.eu
Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

“You can stereotype associations..”     How did I miss that?    :-(

Disregarding for the moment my inept interpretation of UML’s capabilities, I would rather use stereotypes for their intended purpose, rather than as a workaround to graphically display the nillable tag.

I would like to hear from Michael about the likelihood of “stereotype = voidable” becoming a standard.

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/InteroperabilityWG>
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+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 ---



________________________________
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: Thursday, 26 May 2011 10:20 AM
To: auscope-geosciml at lists.arcs.org.au
Cc:
Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

You can stereotype associations..

[cid:275023711 at 30052011-2430]

And EA allows some form of custom diagramming for certain stereotypes  - so it’s certainly possible.

Options include some sort of function that synchronises the nillable UML tag and a stereotype, or explores using the tagged value to control diagramming. Whatever, INSPIRE has done something that presumably they want to roll into the ISO conceptual schema language, so you need to understand this path IMHO. I’ve cc-ed Michael Lutz who will have some insight into this.

I’d personally like to see ISO CSL having an extension mechanism- a way of describing or registering extended profiles that add new tags etc.  So that an extended profile could be “ISO compliant” if necessary, rather than on some vague branch of development of future ISO models.

Rob

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: Thursday, 26 May 2011 9:31 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

I support Ollie's reasoning - maintaining a "voidable" stereotype doesn't really solve the problem and raises a number of other issues.

I'm not sure you can colour the nillable properties differently to the non-nillable properties (isn't it only the classes we can colour?).

If we cannot readily display the tags for each property/association then it only leaves us with the option to add a note to every class and association indicating which properties are nillable.
Although this is a pain, I think it is important as part of our 'documentation' process and encouraging take-up of the standard.

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:        <Oliver.Raymond at ga.gov.au>
To:        <auscope-geosciml at lists.arcs.org.au>
Date:        26/05/2011 09:00 AM
Subject:        Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au
________________________________



Hi all,

In summary:

1. The standard way of indicating "voidable" is to use the UML tagged value "nillable".  As of last month, this tag is processed for all element types by FullMoon.  (Thanks Pavel!)

2. We can add a "voidable" stereotype to attributes and EA will show that in UML diagrams.

3. Attributes can have more than one stereotype (eg, estimatedProperty and voidable).  These are displayed in a UML diagram as a comma separated list.

4. RobA voiced concern about modelling groups like us inventing their own non-standard stereotypes.  This makes it difficult (impossible?) to maintain support tools like FullMoon.

5.  The voidable stereotype offers no functionality over and above the "nillable=true" tag that is already present in the UML.  The voidable stereotype is cosmetic AFAICT and is effectively only so that you can display "this attribute has a nillable tagged value" in a UML diagram.

And finally, something that has not yet been raised, but was the clincher for me in deciding not to use the "voidable" stereotype...

6.  Adding a voidable stereotype to attributes does not solve the problem that many *association* links between classes are also nillable, and we can't stereotype an association with "voidable" as far as I am aware.  I can't see a way of displaying "voidable" for associations in UML diagrams.  Any ideas?

As the voidable stereotype appears to serve only a cosmetic function, why not just use UML notes to display which attributes and associations are voidable?

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 Létourneau, François
Sent: Thursday, 26 May 2011 3:17 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Steve,

I don't know if there is a mechanism in EA to symbolize the presence of a tagged value in the diagrams, but it would definitely be something usefull. I'll do a quick search on this.

François

-----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:57
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

François-- right, I should have known that. So what we need is either a way to have EA display some of the tagged values in the model drawing, or we need to add our own annotation to the model to indicate where the tagged value is present.  It would be less of a maintenance headache if EA did it, but putting in the annotation wouldn't be impossible; we could maybe color nillable properties green or something?
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
> Létourneau, François
> Sent: Wednesday, May 25, 2011 8:47 AM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]
>
> 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/Interopera
> > bi
> > 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/GeoSciMLv3Desi
> > gn
> > 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/Interopera
> > bi
> > 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??^???w
> > j)
> > ]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
> _______________________________________________
> 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

"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讙^jǧ؟ʘ^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf񎵿ϼSM����⪗(����҈{c幫‑r쉗y֞~ަ)඘zf񎵿ϼSM����⪛"ͭ㓝)󧮊

--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110531/b671197d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 9749 bytes
Desc: image001.gif
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110531/b671197d/attachment.gif>


More information about the GeoSciML mailing list