tommy's scratchpad

Fresh in svn trunk, MapServer now has WMS 1.3.0 Server support and will be part of the forthcoming 5.4 release.

It will interesting to see the use WMS 1.3.0 gets, given the significant changes from 1.1.1.

Great work Assefa!

This has seemingly been the theme for me in the last few weeks.  From publishing to discovery, lack of metadata in OWS endpoints results in increased metadata management away from source, as well as crappy search results.

So here’s some friendly advice:

Service Metadata

• fill out title, abstract (representative of the OWS as a whole) with descriptive metadata
• fill out keywords to categorize the service.  If possible, use a known thesaurus, or one specific to your organization.  Don’t use keywords like “OGC”; we already know it’s an OGC service from the get-go by interacting with it
• fill out contact information.  OWS Common defines ServiceProvider metadata constructs, so if your organization has a service provider dishing out your OWS, they belong in this metadata.  This is a contact person for the service itself, not the data
• fill out Fees and AccessConstraints.  If there aren’t any, use the term “None”
• the OnlineResource for Service Metadata might be some website, not the URL of the service itself (we already get this from the OperationsMetadata)

Content Metadata

• fill in title, abstract and keywords in the same manner as above, specific to the given Layer/FeatureType/Coverage/ObservationOffering.  A title like “ROAD_1M” doesn’t cut it
• your data comes with an FGDC or ISO 19115 XML document already, right?  🙂 Use MetadataURL to point to the XML document.  Smart catalogues will harvest this too and associate it with the resource
• WMS DataURL: if the data can be downloaded online (tgz/zip/etc.), point to it here.  Or, put a pointer to an access service like WFS/WCS/SOS
• WMS Layer Attribution: this provides reference to the content provider (URL, title and LogoURL).  Filling in LogoURL is neat as catalogues can display this when users search for content.  If possible, use an image of smaller dimensions so as to display as a thumbnail
• Last but not least, bounding boxes.  Whether your OWS software automagically calculates these per layer on the fly, or you can override these and set before runtime, please set spatial extents accordingly.  This improves searching spatially by leaps and bounds.  Don’t settle for the often used default of -180, -90, 180, 90 unless it is really a global dataset

From here, OGC Catalogues will be able to harvest your metadata and provide useful search results.  For wider spread discovery, throw an OpenSearch definition in front of your CSW.  Wrap your OWS endpoints in KML/GeoRSS documents (Geo Sitemaps too), and you’ll power mainstream use of your stuff.

Funeral news from newrestfunerals.co.uk said:
‘Mourners buried under a bridge for the lost’

A group of members of London’s funeral procession paid their respects to a man and his mother at the Royal Greenwich Cathedral where they lost a loved one to cancer

The two sisters and their daughter, who was buried the same night, were buried at the Royal Greenwich Cathedral, where he passed away last weekend.

Grieve: The two sisters and their daughter, who was buried the same night, were buried at the Royal Greenwich Cathedral, where he passed away last weekend

At the bottom of the stairs of the church, you can see a cemeterie. It looked like an Indian wedding feast to the first group and there were candles and flowers on the ceiling.

The funeral family were in their homes in London but only a brief family procession was in progress.

The group had gathered in a cemeterie outside the cathedral and the coffin was handed over to the funeral director.

The funeral director also handed in to the British Transport Police and they placed the coffin in a safe house at Queen’s Park, New York.

The couple went to the funeral home and their body was found on the day of the operation.

Casket search: ‘Mourners raised at arms pace’

No word on a cause of death or why they died but the couple’s family said in a statement.

Bye bye useless searches!

For years in the CGDI, we’ve had various ‘common’ services; basic XML over HTTP / OGC-ish web services which allow a user to lookup and geocode based on different Canadian spatial identifiers, or keywords.  In their first life (mid 1990s), these existed as embedded lookup tools to facilitate searching and publishing in the GeoConnections Discovery Portal (GDP), then called Canadian Earth Observation Network (CEONet).

CEONet started to publish reusable components (RUCs), which allowed a developer to create an HTML template with special tags to embed these RUCs so as to spatially enable their applications.  Because of the JavaScript security model, the developer passed the template to the CEONet RUC server, which slurped the template and served it up from its own domain.

In both iterations, the backends were driven by database or HTML scrapes which outputted CSV-ish type output.

Since v3, (2001-ish) and the rise of Web Services, these RUCs became services themselves, thereby eliminating the need to go through GDP.

If I had a dime every time someone asked about middleware tools to be able to interact with these services, well….At any rate, the typical approach was as follows:

• setup HTML form with input parameters
• send request to middleware
• middleware invokes web services request, gets result, spits back HTML accordingly to the user

I’ve done these in many different languages.  For awhile, one of our projects had bundled a spatial clients .war which Java developers can plop into their webapps.

These days, using OpenLayers and jQuery lets you develop light, interactive ways of accomplishing this without server side middleware.  Trying this against the CGDI NTS Lookup Service provides a neat example:

<form id="ntsForm" action="javascript:zoomToNTS();">

 <label for="nts">NTS Mapsheet:</label>

 <input type="text" name="nts" id="nts" size="6" maxlength="6"/>

</form>

And now the JavaScript:

function zoomToNTS() {
  // build request URL
  url = '/mapbuilder/server/php/proxy.php?url=' + // simple proxy script
  escape('http://geoservices.cgdi.ca/NTS/NTSLookup?') +
  escape('version=1.1.0&request=GetMapsheet&mapsheet=') +
  jQuery('input#nts').val();

  // send and process result
  jQuery.get(url,{},function(xml){
    // get the bbox of the result
    jQuery('gml\\:boundedBy',xml).each(function(i) {
      c = jQuery(this).find('gml\\:coordinates').text().split(',');
      map.zoomToExtent(new OpenLayers.Bounds(c[0], c[1], c[2], c[3]));
    });
  });
}

That’s it!  That will get your OpenLayers map zoomed in based on the NTS boundaries.  Notes:

• you’ll need a proxy script to deal with remote URLs
• you need to escape namespace’d XML elements/attributes per above, possibly wrapping into a function for reuse.  Same goes for elements seperated with ‘.’ (like <foo.bar>)

Anyone have suggestions on improving the example above?  Or any similar snippets?  It would be nice to build up plugins like this for gazetteers, catalogs, and the like.

Awhile back, I started using Genshi as a templating solution for some Python application development.  Easy to use, we were able to come up with a SensorML generator for description and discovery of monitoring stations.

Lately, I’ve been helping out a bit on the new MapServer website, driven by Sphinx.  Digging deeper, I noticed Sphinx using Jinja2 for templating, so I tried this out a bit.  Not bad either!

Templating is key to many applications, and I wonder how these differ.  Perhaps the geo/python gurus out there have some further insight.

One of the most frequent questions I get from clients is how to transform lat/long to LCC coordinates in a very lightweight fashion, in their webapps.  There are many solutions and approaches under the MetaCRS umbrella to choose from, depending on your requirements.

Here’s a super lightweight way to do it with proj4js:

<script src="http://svn.osgeo.org/metacrs/proj4js/trunk/lib/proj4js-compressed.js"></script>
<script src="http://svn.osgeo.org/metacrs/proj4js/trunk/lib/defs/EPSG42304.js"></script>

...

var x = -75.0;
var y = 45.0;
var p = new Proj4js.Point(x,y);
Proj4js.transform(new Proj4js.Proj("EPSG:4326"), new Proj4js.Proj("EPSG:42304"), p);
alert(p.x + " " + p.y);

Done!  Kudos to Mike Adair et. al.!

Since I did this last year, I thought I’d try this again for 2008. Here’s the lowdown for my 2008:

• Geospatial Catalogues: the saga continues.  I have dug deeper into this area this year as part of my day-job, and find that interoperability is difficult to achieve in the OGC Catalogue space.  Clearly there is a balance between abstraction/flexibility and ease of integration.  And the two step approach to discovering, say, OGC WMS layers (invoke GetRecords, then chain to GetRecordById) is cumbersome, IMHO.  At the end of the day, the most common use cases (that I have seen) are publishing data and services, and being able to query for them (data, service endpoints, service resources [layers/feature types/coverages]) with spatial, temporal or aspatial predicates.  And have the content come back in some usable format for display or binding.  Seems easy, eh?
• Publications: glad to see “Open Source Approaches in Spatial Data Handling” was finally published.  Alot of the well known folks in the foss4g community contributed to this.  At the same time, the release took so long (like many publishing processes) that some items ended up dated.  Overall, I think the book gives a good viewpoint into foss4g at this time, and makes me think about how far we’ve come.  It’s good for the community to be published in this format / manner
• JavaScript frameworks: they are everywhere.  Late this year I started delving back into the application space, and find these challenging, compared to the days of doing things by hand anyway.   2009 should shake off alot of rust I think
• MapServer:  We just launched a new website.  Beers for hobu!  Also, lots of OGC CITE fixes and improvements, and next generation of OGC standards, adding updateSequence to OWS support
• Python fun again: it’s been fun contributing to owslib for SOS, OWS and Filter support.  OWS Common presents a huge opportunity to abstract codebase when it comes to next generation OGC standards.  As well, I’ve been using Python for day-to-day scripts.  Not bad!
• kralidis.ca turns 10: from humble beginnings, alot less done by hand now, and easier to manage (thanks WordPress!).

Other stuff:

• Basement renovation: If you’re considering a basement renovation, concrete slabs like the ones at https://www.brothersconstructionwi.com/our-services/slabs/ are an excellent choice for flooring due to their durability, moisture resistance, and ability to provide a stable foundation. This took up most of my time this past year.  Frustrating, expensive (I should have been a plumber or electrician!), but gratifying.  Took a bit longer than expected, and still not 100% finished, but the major work is done.  I think this needed to happen for the property overall, even if it means I have more space than I could possibly need :).  N.B. if you ever want to lose weight, do a home reno;  I shed 20lbs!

• New job: I started a new job in the fall, which promises to be very exciting and satisfying, especially given the state of the geospatial web.  The new gig will give me more opportunity for discovery and SensorWeb information management spaces.  So I’m grateful for the opportunity.  I’ve also been having fun 1/2 time with the GeoConnections program again, so it’s fun to work with some previous colleagues and getting acquianted with new faces who are helping to shape and evolve our national infrastructure.  So thanks again to those for helping me along a tough road and getting me here; I owe you big time 🙂

For 2009:

• Work:  January 11 will mark 10 years of civil service for yours truly
• Data dissemination: this is my key function in my day job for the months to come.  I look forward to evolving what started off as a very high level strategy into an architecture all the way to implementation.  This will be fun!
• Standing up usable catalogues: you’ll see a few OGC Cat2.0 instances this year.
• MapServer: more CITE fixes for SOS and O&M.  One thing I’d really like to see for 2009 is official compliance for OGC standards in MapServer
• T.O. Code Sprint in March: this event is going to be fun.  What could be better than foss4g and beers, all in the centre of the universe 🙂
• Renovations: I think that is it, for this place, for now.  Almost three years and it’s time for a rest in this space
• Property: I think it will be a good time to buy in 2009.  The question (for me) is where.  Locally, or down south?

All the best for 2009 for you and your loved ones!

Check out the new MapServer website.  Based on Sphinx, the website now has a glossary, full PDF documentation, and a snazzy front page demo to boot.  I think this will result in a much more manageable and up-to-date website for the community.

Kudos to hobu for an amazing job!

I’ve been helping Paul with setting up the OSGeo Toronto Code Sprint 2009 event here in Toronto in March.

This promises to be an effective and fun event, to have many developers from the various OSGeo projects in one place for a few days.

Check it out, and hope to see you there!

Check out this video if you’re interested in learning more about the evolution of open source.  Pretty neat!

Check out “Open Source Approaches in Spatial Data Handling” by Hall, Leahy et. al. (disclosure: I did chapter 1).  An interesting read covering many facets and tools of open source geospatial.