[auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Mon May 16 07:39:40 EDT 2011


> GeoSciML has introduced estimatedProperty (does anyone else use this?) etc

The last time I asked, it was supposed to be considered in GML 4.0

See relevant CR :  06-001r1 and 07-069
 
In 07-069 has specific examples on how to handle <<estimatedProperty>> :


-----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 Rob.Atkinson at csiro.au
Envoyé : 15 mai 2011 19:39
À : auscope-geosciml at lists.arcs.org.au
Cc : A.Woolf at bom.gov.au
Objet : 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/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 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/GeoSciMLv3DesignProposals#16_gsml_Map, and https://www.seegrid.csiro.au/wiki/CGIModel/Quebec2009ModelDesignTaskGroupAgenda).  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/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 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)]zWz+_????'('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



More information about the GeoSciML mailing list