[auscope-geosciml] MappedFeature

Laxton, John L. jll at bgs.ac.uk
Thu May 12 04:40:33 EDT 2011


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.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110512/816e1bd4/attachment.htm>


More information about the GeoSciML mailing list