tommy's scratchpad

http://n2.nabble.com/FW%3A-MapServer-enhancements-refactoring-project-td2571268.html

I’m beyond words at this point.

Written from home:

We have some existing C modules which do a bunch of data processing, and wanted the ability to spit out shapefiles on demand.  Shapelib is a C library which allows for reading and writing shapefiles and dbf files.  Thanks to the API docs, here’s a pared down version of how to write a new point shapefile (with, in this case, one record):

#include <stdio.h>
#include <stdlib.h>
#include <libshp/shapefil.h>

/*
 build with: gcc -O -Wall -ansi -pedantic -g -L/usr/local/lib -lshp foo.c
*/

int main() {
    int i = 0;
    double *x;
    double *y;

    SHPHandle  hSHP;
    SHPObject *oSHP;
    DBFHandle  hDBF;

    x = malloc(sizeof(*x));
    y = malloc(sizeof(*y));

    /* create shapefile and dbf */
    hSHP = SHPCreate("bar", SHPT_POINT);
    hDBF = DBFCreate("bar");

    DBFAddField(hDBF, "stationid", FTString, 25, 0);

    /* add record */
    x[0] = -75;
    y[0] = 45;
    oSHP = SHPCreateSimpleObject(SHPT_POINT, 1, x, y, NULL);
    SHPWriteObject(hSHP, -1, oSHP);
    DBFWriteStringAttribute(hDBF, 0, 0, "abcdef");

    /* destroy */
    SHPDestroyObject(oSHP);

    /* close shapefile and dbf */
    SHPClose(hSHP);
    DBFClose(hDBF);
    free(x);
    free(y);

    return 0;
}

Done!

Written from home:

A benefit of open source.

< 4 hours.  That’s how long it took to address a MapServer bug in WMS 1.3.0.  Having been on the other side of these many times, it’s gratifying to bang out quick fixes as well.

Committing often

Written from home:

MapServer action from the Toronto Code Sprint 2009:

• repository changes
• all trac activity

Paul has full details on his blog (day 1, day 2, day 3, day 4, post-mortem).  More details from Chris (day 1, day 2, day 3, day 4).  Also check out some pictures from the event.

Personally, I was happy to bang out fixes for:

• optionally disabling SLD for WMS (#1395)
• support for resultType=hits for WFS (#2907)
• working code for WFS spatial filters against the new GEOS thread safe C API (#2929)
• WFS 1.1.0 supporting OWS Common 1.0.0 instead of 1.1.0 (#2925)
• The beginnings of support for correct axis ordering for WFS 1.1.0 (#2899)

Good times!

UPDATE 12 March 2009: here’s a Camptocamp report of the event.

Written from home:

The code sprint starts Saturday, and there’s a good turnout of folks from the various OSGeo projects.

If you’d like to participate, you can join us on IRC at #tosprint and be there in spirit.

Written from home:

Check it out.  A few RFCs addressed, among them OGC WMS 1.3.0 server support.

Written from home:

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!

Written from home:

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.

Written from home:

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.

Written from home:

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.!

Written from home: