[Auscope-geosciml] GeologicUnit composition, geologicHistory in Geoserver

Stephen M Richard steve.richard at azgs.az.gov
Tue Sep 1 12:12:20 EDT 2009


Rob--are you saying that there is evidence that the 
<relationshipToParent><semanticElement> pattern parses more efficiently 
when there is only one <semanticElement> for each <relationship> 
element, even when there are many <semanticElements> that stand in the 
same relationshipToParent? e.g. <composition> is relationship to parent, 
there are 1 to many <compositionParts> that represent the semantic 
elements.
steve


Rob.Atkinson at csiro.au wrote:
> 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
>
>
> _______________________________________________
> Auscope-geosciml mailing list
> Auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>   

-- 
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone: 
Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov




More information about the GeoSciML mailing list