[Auscope-geosciml] GeologicUnit composition, geologicHistory in Geoserver

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Mon Aug 31 19:20:49 EDT 2009


The pattern can also be explained as 

<relationshipToParent><semanticElement>.

ie. the container specifies what role the element plays in the containing feature, the element is at least a re-usable (readily identifiable) data type, and often a reusable element that can be referenced from multiple places.

More work needs to be done here, but there is some evidence this pattern might  be parsed more efficiently - in this case comparing XML based on ad-hoc rules with an O&M based implementation with water observation data, the GML was larger, but parsed quicker.

Rob Atkinson
____________________________________
____
From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon Cox [simon.cox at jrc.ec.europa.eu]
Sent: Tuesday, 1 September 2009 3:37 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] GeologicUnit composition,       geologicHistory in Geoserver

This pattern - each property-element can only contain one Object-element - is a consequence of the UML-XMl encoding rule defined for GML Application schemas. You should not be tempted to manually tweak the XML schema - it is automaticaly generated using the rule. Occassionally that might make the XML more verbose than a hand-crafted schema, but in general we believe that the regularity more than outweighs this consideration.


--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre
Institute for Environment and Sustainability
Spatial Data Infrastructures Unit, TP 262
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox at jrc.ec.europa.eu
http://ies.jrc.ec.europa.eu/simon-cox

SDI Unit: http://sdi.jrc.ec.europa.eu/
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/

--------------------------------------------------------



________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Ryan Clark
Sent: Monday, 31 August 2009 19:01
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] GeologicUnit composition,geologicHistory in Geoserver

I'm still working with Geoserver to get a GeoSciML WFS set up. I've run into something that confuses me a bit in the GeologicUnit featuretype. From what I can understand looking at the schema, it looks like it would be valid for me to list multiple <composition>s under a <GeologicUnit>, each with a single <CompositionPart> element. Similarly, it looks like it would be valid to list multiple <geologicHistory>s, each with a single <GeologicEvent>. >From my understanding of the app-schema Geoserver extension, it is also easier to do it this way. I also see a few instance documents that put things together like this.

However it doesn't really make sense to me conceptually, and it seems like it would be more sensible to have just one <geologicHistory> containing multiple <GeologicEvent>s, or one <composition> with multiple <ComnpositionPart>s. Perhaps either way is valid?  I'm not sure if Geoserver is even capable of putting together a document following the latter option. Has anyone implemented this?

Thanks,
Ryan





More information about the GeoSciML mailing list