[OSGeodata] geodata stylesheets

[Norman Barker]

Hi,

Comments in line below

-----Original Message-----
From: Kralidis,Tom [Burlington] [mailto:Tom.Kralidis at ec.gc.ca] 
Sent: Thursday, August 03, 2006 4:19 PM
To: geodata at geodata.osgeo.org
Subject: RE: [OSGeodata] geodata stylesheets

 

> -----Original Message-----
> From: Norman Barker [mailto:nbarker at ittvis.com] 
> Sent: 03 August, 2006 11:05 AM
> To: geodata at geodata.osgeo.org
> Subject: RE: [OSGeodata] geodata stylesheets
> 
> Thanks for the list, and the version numbers, if I get the 
> WCS retrieval fully working this way then the others will be 
> very similar.
> 

Check out the mapbuilder codebase.  They already have some XSLT's to
parse OGC:WMS and OGC:WFS, I believe.

<ncb>
Ok, MapBuilder has a LGPL license - this will be ok, I will check out
the source code.  I feel for this to work we can't be GPL, we need
industry to adopt this model as well if there is to be uptake.
</ncb>

> 
> The Sensor Observation Service would be interesting in terms 
> of generating GeoRSS, and there are a couple flying around at 
> the moment (MapServer has support).
> 

We're almost done deploying our OGC:SOS via MapServer of our national
water quality measurements.  As an asdie, we have to tweak the MapServer
code still for OGC:SOS, as, at this point, one station (sensor) is seen
as a LAYER object, which could be cumbersome for monitoring programs
with hundreds of stations (sorry, my gaffe on that one, this is how we
outlined the design when we funded OGC:SOS support in MapServer).
Anyways, better off discussed on mapserver-dev.

<ncb>
Ok, we recently funded the further development of mapscript so that you
could tweak the request and responses (so tweak the replies before they
reach the client) it is in CVS, and may be useful if you want to do any
tweaks. http://mapserver.gis.umn.edu/docs/howto/wxs_mapscript it doesn't
include sos on the docs, but I guess it will work as well.  As you say
lets take this bit on to the MapServer list.
</ncb>

I think, for a catalogue, we'll also want to have OGC:SensorML documents
supported.  Conceptually, a SensorML document can be a catalogue
resource, which can point to an OGC:SOS, which can provide O&M, or
GeoRSS, etc.

<ncb>
My current project is working with JPIP, and I am looking to have a
catalog backend (hence this work), integrating sensors would be very
useful (sensor -> ground -> catalog -> JPIP). 
</ncb>

> I have concerns about how much useful metadata you can 
> retrieve from a getcapabilities call, the time period is 
> important, and also since most getcapabilites are dynamic 
> should you just fetch every time - or say file size (as 
> determined by an http head request) is an indicator of 
> whether to fetch?
> 

I know the OGC:WMS 1.1.1 DTD has a root element attribute of
updateSequence (see section 7.1.3.4 of OGC:WMS 1.1.1 spec at:
http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&forma
t=pdf).  The problem is that this is an optional element, so some
instances may not have this info.

>From my experience, harvesting frequency has been ad hoc thus far (i.e.
somehow figuring out things have changed, then harvest).  We could do an
HTTP HEAD as a means of quick scanning, but what happens if the filesize
is the same but the content has changed?  Mind you, chances of this
would probably be small.  I wonder what others have done for their
catalog updates.

<ncb>
Thanks, that is very useful, if we agree a policy then I am fine with
that.  With a head request on a dynamic document you tend to get the
same result as a get request (all the data is returned as well), so it
isn't a network issue, just amount of time to ingest and the number of
concurrent ingests.
</ncb>


> I have copied the concerning bits from the stylesheet here 
> but they relate to populating the database schema
> 
>     <!-- boolean ok for classifying type? -->
>     <entry key="raster">1</entry>
>     <entry key="vector">0</entry>
>     <entry key="point">0</entry>

How are you figuring this out from GetCapabilities?  For OGC:WFS, we
know it's vector, OGC:WCS raster.  For OGC:WMS, are you checking the
(again optional) Layer/@opaque attribute?

<ncb>
Opps, I had forgotten about WMS feature portrayal.  This could be a
little unpleasant as it requires another url call and parse.
</ncb>

>     <!-- evaluate bbox, so not just to get -180,-90,180,90 from lazy
> admins-->
>     <xsl:call-template name="bbox">
>         <xsl:with-param name="list" select="//wcs:lonLatEnvelope"/>
>     </xsl:call-template>
>     
>     <!-- what value should we put in here? -->
>     <entry name="date"><xsl:value-of 
> select="date:date-time()"/></entry>
>     <!-- need to a describeCoverage here, but this could be 
> different for every coverage offering brief and we are only storing
> capabilities-->
>     <entry name="timePeriod"></entry>
>     <!-- CRS ref is forced to epsg:4326 -->
>     <entry name="projRef">EPSG:4326</entry>
>     <entry name="dataSource">WCS</entry>
> 

What is the underlying database schema you are populating to?

<ncb>
I am currently intending to populate Jo's PostGIS schema which is in
subversion, I am looking to map to EJB3 first since I would like the
system to include security and clustering and though there has been a
lot of work with JDO and spatial feature types - industry support is
pointing towards EJB3.  Also EJB3 is incredibly easy once you get over
the initial stumbling block of using meta tags to do things.

> 
> This is quite nice!
> 
> If we assume all of metadata will be encoded in XML, we 
> should probably
> list what XSLT's we need, a few off the top of my head:
> 
> OGC:WMS 1.1.1
> OGC:WFS 1.0.0
> OGC:WCS 1.0.0
> FGDC:CSDGM-1998
> ISO19115
> ISO19119
> OGC:OWSCommon
> GeoRSS
> 
> 
> Any others?
> 
> ..Tom
> 
> 
> > -----Original Message-----
> > From: Norman Barker [mailto:nbarker at ittvis.com] 
> > Sent: 03 August, 2006 10:44 AM
> > To: geodata at geodata.osgeo.org
> > Subject: [OSGeodata] geodata stylesheets
> > 
> > Hi,
> > 
> > Following on from our earlier discussions I wrote a 
> > stylesheet targeted towards extracting information from a 
> > getcapabilities response;
> > 
> > I have attached the test capabilities response (just a crude 
> > manufactured example), the stylesheet (you will need the 
> > exslt extensions for your language (java has them already, 
> > firefox will need the pure text versions), and the output (I 
> > have made this Java serializable specific - doesn't have to be).
> > 
> > I have put comments inline in <xsl:template 
> > match="wcs:Service"> in metadata_wcs_1.0.0.xsl, where I think 
> > we are missing info, or have questions.  From the 
> > capabilities we can't get time periods, and we struggle to 
> > get some meaningful data.
> > 
> > Please let me have your comments, I think I am going to go 
> > down the stylesheet route for extracting the data and then 
> > pulling it into Java and hence in the persistence model - if 
> > this isn't recommended please let me know.
> > 
> > Thanks,
> > 
> > Norman
> > 
>