"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"


Stylesheets

Design

Modular development

Initial experiments with stylesheets to convert GML into SVG raise significant issues regarding the role of common elements and structures in enabling the use of style libraries to allow browser caching of much of the SVG generated. Given XMML has many common patterns and significant reuse of information models it seems sensible to build a modular stylesheet library optimised for GML/XMML. This should allow reusable "styelsheet parts" to create a similar look and feel for common patterns when rendered in SVG, HTML, etc.

CSIRO has just a little experience here - see the stylesheets developed for of geochemistry data delivered in highly normalised form, but presented in tabular, de-normalised form. Some use of modularisation for recurrent patterns and components - see AdxExamples.

Implementation

HTML Reports

Suggested Report Format

Supplied by PIRSA (GregoryJenkins) 10 Sep 2004. The images are shown 75% of scanned size. Download them to view full resolution image.

The word RANGE in field names refers to the PIRSA value range field ie. <, >, or null.

It is proposed that this functionality be implemented through an XML Schema "substitution group": the generic Measurement and the derived GeochemMeasurement has an abstractResultMeasure property to carry the result; in an instance this is replaced by one of resultMeasureExact, resultMeasureLessThan, resultMeasureGreaterThan, resultMeasureInterval; the first of these is nillable="true", so may appear in an instance with the attribute xsi:nil="true" to manage the "null" case. -- SimonCox - 16 Sep 2004

  • Geochemistry Scenario 1 form and Report:
ALL GEOCHEM appears to imply use of the sample view which denormalises all analyte results as properties of a single sample. However ...
GeochemScenario1Report.png

In the SCREEN view, the results are presented one-row-per-measurement, which corresponds with the measurement view. The level of detail shown (method, lab information) for each measurement requires too many links to be followed and too much logic using the sample view. In the REPORT/EXPORT view, is this just the same data given in the SCREEN view, but formatted in a single table instead of multiple boxes? In which case the reader is responsible for matching up rows with the same sampleID in order to see "ALL GEOCHEM" for a location, right? (I would not call this "fully denormalised")

  • Geochemistry Scenario 2 form:
    GeochemScenario2Report.png

The main table on the left of the screen is equivalent to a discrete Point-Set Coverage - values of a single property at given locations. However, the annotations indicate that it is necessary to support interactions in which selecting a row (location) triggers display of all of the details of a single measurement in the secondary block. This requires the normalised measurement-oriented data to be available. If the interaction is to take place with minimal latency, the normalised data must be available on the client side, and interactions use (e.g.) javascript

Tentative conclusion: we must transfer "normalised" data to the client, and the client must then generate denormalised views on-the-fly.

Portrayal Stylesheet

Examples are now attached of output from a stylesheet which can cope with inline format samples. -- AndyDent - 15 Nov 2004

Additional requirements (PirSA)

Sample header information to be exposed by PIRSA (implementation and formatting: Mark Jolly) consists of:

  • PIRSA sample_no: to be implemented as
        xmml:GeochemSpecimen gml:id 
        
    (as at present)

External id's should be put in a gml:name element. Note that gml:name may be repeated (though I realise there are Geoserver difficulties in this). The gml:id may use one of these, but it is bad practice to assume any particular significance for the gml:id, which is a "database identifier" in the context of the GML document/WFS implementation. -- SimonCox - 17 Nov 2004

  • Sample source code, sample source description: to be implemented as
        <xmml:material>
        
    with the code and description separated by a single space (e.g. CALC Calcrete).

While it may be schema-valid and convenient, this looks repetitive. Better to use either code or description, not both repeated in same field. -- SimonCox - 17 Nov 2004

  • Sample depth from, sample depth to (populated for drillhole samples, null for surface samples)

This is specimen location information. It really implies that the geometry of the specimen is a LineString defined by two end points. The end points to be given in 3-D (which is supported by GML). However, the current Specimen feature may only have a point location. We may need to revisit this - perhaps we need to add an optional shape property in addition to the standard position property ... -- SimonCox - 17 Nov 2004

  • PIRSA drillhole_no

  • Drillhole name

Drillhole name, PIRSA drillhole no and Sample depth from, sample depth to are all to be implemented as
    <gml:LocationString>
    
with the format:
     Drillhole_name (DHNO: pirsa_drillhole_no), sample_from_depth-sample_to_depth m
    

I suggest that this is a misuse of the LocationString element which should be used strictly for a textual geographic identifier. Use the standard relatedFeature element to link to a Borehole feature - see BoreHole (note that logs are optional). -- SimonCox - 17 Nov 2004

  • Collector's sample ID

Use another (codeSpace scoped) gml:name -- SimonCox - 17 Nov 2004

  • Collector's name
  • Date of sample collection

These are allowed for within the description of the xmml:processingStep/xmml:ProcedureEvent that describes the sampling event. -- SimonCox - 17 Nov 2004

Collectors sample ID, collectors name and date of sample collected are all to be implemented as
    <gml:name>
    
with the format:
     collectors_sample_id (Coll. by collectors_name, date: dd-mon-yyyy)
    
There was some discussion about use of Z value to specify sample position within a drillhole. This could only be used in the ideal situation. In practice it is unworkable due to (1) the lack of accurate information about collar elevation in the vast majority of cases, and (2) the fact that not all drillholes are vertical. The only practical solution is addition of distinct fields containing distance along drill stem from the individual drill collar.

There was also mention of not publishing collector's name and collection date in the demonstrator. PIRSA intends to expose those fields whether or not they are displayed, as we consider that they contain metadata essential for meaningful use (resolved above).

-- GregoryJenkins - 16 Nov 2004

In general, the following "informal" fields are provided where you can put additional unstructured information: either gml:description or xmml:comment -- SimonCox - 17 Nov 2004

Without checking the PIRSA WFS output I can't be certain of this but...

This looks as though these are extensions to the community schema which will break the clients.

Do these extensions validate?

In which case there is a definite need to tighten up the validation process or we will eventually break clients and never achieve the interoperabiltiy objectives.

Note that it isn't an objective of this project to deal with proprietry (industry) extension points but to achieve interoperability across organisational boundaries for the community schema. As such we are all obliged to conform to the community schema and to collaborate and achieve consensus on the community schema. As such the appropriate response under this project is to note the extensions that are being requested and to feed them into the community schema development process for incorporation into the next version of the schemas (the current versions on this project were frozen a little while ago).

-- RobertWoodcock - 17 Nov 2004

SVG

Simple demonstrator Stylesheet API

A map layer may have a SVG stylesheet specified. This is used to render the layer. The stylesheet must conform to a few interface rules to support geolocation.

The basic parameters we pass in to geolocate the stylesheet output are:


<!-- this param used if you want to externally specify a single style to apply -->
<xsl:param name="style">fill:none;stroke:rgb(0,0,0);stroke-width:0.1%;</xsl:param>
<!-- these params must be supported by all stylesheets -->
<xsl:param name="width"/>
<xsl:param name="height"/>
<xsl:param name="minx"/>
<xsl:param name="miny"/>
<xsl:param name="maxx"/>
<xsl:param name="maxy"/>

<!-- write svg element and attributes -->
<xsl:element name="svg">
  <xsl:attribute name="width">
<xsl:value-of select="$width"/>
</xsl:attribute>
  <xsl:attribute name="height">
<xsl:value-of select="$height"/>
</xsl:attribute>
  <xsl:attribute name="viewBox">
      <xsl:value-of select="$minx"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="-$maxy"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="$maxx - $minx"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="$maxy - $miny"/>
</xsl:attribute>

.... your SVG styling here...

<!-- close SVG element -->
</xsl:element>

Can we please have more detail as to what data ranges are represented by minX, maxX above and how these ranges affect the processing of the gml:position x, y & z -- AndyDent - 15 Nov 2004

You dont need to process gml:position if your map projection can be accurately (enough) scaled into the target projection. In practice, we will want the WFS to deliver data in the same projection as the viewing client wants to portray, though for small areas there is little difference as long as the direction of North is pretty close.

To truly reproject to fit a different map projection is more costly operation. In WebMap Composer we will do this at runtime for point geometries only - which we dont need SVG to then render. The whole issue is one for debate.

The benefit of the simple approach we have taken is that you have it easy - simply dump the native coordinates and the client can control the map size and scale. We are assuming that the data is being delivered in lat/long and we can get away with displaying crude "Plate Carree" projections at all scales. More work needs to be done looking at the best way of doing this.

Better ideas welcome!

-- RobAtkinson - 15 Nov 2004

From discussion with RobAtkinson, the stylesheet uses the gml:position as latlong and just uses those as raw coordinates.

-- AndyDent - 16 Nov 2004

Examples are now attached of output from a stylesheet which can cope with inline format samples. This first cut doesn't do much in the way of feature representation, we need more discussion on that. -- AndyDent - 16 Nov 2004
Topic attachments
I Attachment Action Size Date Who Comment
GA_Inline_AnalytePortrayal2.htmlhtml GA_Inline_AnalytePortrayal2.html manage 0.2 K 16 Nov 2004 - 18:15 AndyDent HTML to invoke the matching SVG
GA_Inline_AnalytePortrayal2.svgsvg GA_Inline_AnalytePortrayal2.svg manage 0.4 K 16 Nov 2004 - 18:15 AndyDent Sample output from AnalytePortrayal2
GA_Inline_AnalytePotrayal1.htmlhtml GA_Inline_AnalytePotrayal1.html manage 1.6 K 15 Nov 2004 - 14:11 AndyDent Sample output from AnalytePortrayal1
WA_Inline_AnalytePotrayal1.htmlhtml WA_Inline_AnalytePotrayal1.html manage 2.1 K 15 Nov 2004 - 14:12 AndyDent Sample output from AnalytePortrayal1?
Topic revision: r16 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).