[Auscope-geosciml] GeologicUnit composition, geologicHistory in Geoserver

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Tue Sep 1 18:29:28 EDT 2009


To be honest I haven't looked deeply enough into it - it was a curious side effect of another test (geoserver stress testing!) that we noted.

Optimising XML data exchange is not my current focus, but it would be interesting to have some further experimentation in this area.


Rob Atkinson
Team Leader, Interoperable Systems
CSIRO Land & Water
Ph (mobile) +61 419 202 973

-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M Richard
Sent: Wednesday, 2 September 2009 2:12 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] GeologicUnit composition, geologicHistory in Geoserver

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

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml



More information about the GeoSciML mailing list