[auscope-geosciml] MappedFeature [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Fri May 13 03:42:06 EDT 2011


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讙^jǧ؟ʘ^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf񎵿ϼSM����⪗(����҈{c幫‑r쉗y֞~ަ)඘zf񎵿ϼSM����⪛"ͭ㓝)󧮊
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110513/898d1ab4/attachment.htm>


More information about the GeoSciML mailing list