[auscope-geosciml] MappedFeature

Thu May 12 19:58:35 EDT 2011

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110513/c02ef36e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cropped_geological_legend_gsv.pdf
Type: application/octet-stream
Size: 96046 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110513/c02ef36e/attachment.obj>