This session is open to all, so if you’re going to be at GeoWeb, or are in the area and want to hang out and eat pizza with some Cool GeoGeeks (oxymoron?) RSVP on the wiki!

We’re also looking for some presentation ideas; if you’ve got a burning desire, then please propose a topic on the wiki.

-J

Jackie Ng has a better description of this than I could write.

Apart from the improved scalability and stability of this release, I’m most excited about the WiX-based open source MSI installer that I got to work on alongside Jackie and Kenneth. Huge learning curve, but not having to count on Autodesk resources to build new installers should allow us to push new releases as needed. It also means that someone who understands the installer can easily create custom deployments for internal use.

Anyway, please give this beta a try. If you notice anything it’s not doing right, please let us know.

-J

In the following dialog, either leave the default of all checked, or choose to only pre-render certain zoom levels of your data, the choice is yours (probably best to start with the smallest scale – in this case 100,000):

Then click "Build tiles now" and sit back and watch the tiles cook:

Of course, this isn’t practical for a production environment where you would want to batch this operation.  That’s where the second option comes in; clicking on "Save as script" generates a Windows batch file similar to the following that you can script to your heart’s desire:

"C:Program FilesOSGeoMapGuide MaestroMgCookerCommandline.exe" batch
   --mapdefinitions="Library://Samples/Sheboygan/MapsTiled/Sheboygan.MapDefinition"
   --basegroups="Base Layer Group"
   --scaleindex=7
   --mapagent="http://localhost:8008/mapguide/mapagent/mapagent.fcgi"

I have no idea if the MgCookerCommandLine.exe works under Mono, but given that the rest of Maestro seems to work fairly well there I would not be surprised.

Great job Kenneth; this is something we have been sorely missing since MapGuide 1.2, and it’s great to see it as part of Maestro!

-J

By linking to open source components such as MapGuide, FDO, POCO, CTemplate, and libkml, the MapGuide REST framework is very simple and powerful.  With absolutely no programming, a site administrator can build out customised HTML and KML representations of their data, and enable access to default GeoJSON and FDO-based XML representations.  Pair these representations with static HTML pages that expose "service metadata", and you have data that is easily crawlable by search engine spiders, and easily understood by anyone wanting to access the data for other applications.  Enough talk; let’s go over some examples from the City of Nanaimo’s live web site.

Data URI:  http://maps.nanaimo.ca/data/ 

This is where all of the City’s RESTful GeoData will be exposed.  Currently, there is a single resource type exposed for Property information, but more is on the way and will be interlinked when it makes sense.  The index page for this directory is a static HTML page pointing to various features of the Property resource type.

Property Resources:  http://maps.nanaimo.ca/data/property/ 

This currently displays a page that allows users to search by one of three attributes by HTML forms, and contains links to OpenSearch (with draft Geo) documents that define some of the other search and representation capabilities.

OpenSearch link:

<link
  rel="search"
  type="application/opensearchdescription+xml"
  title="Properties by Street"
  href="/data/property/search_by_street.xml"
>

As well, there is a link to a Street Index which acts as a form of sitemap, providing web crawlers with an equal-length trip to every property in the City.

Example Property HTML Representation:  http://maps.nanaimo.ca/data/property/123170.html

As much as this looks like a regular web page, it is cram-packed with features that make it distinguishable as a geospatial resource.  Most visibly, it displays an image of the property’s shape in context, and provides a link to the KML representation of that property.  Digging a little bit deeper, the page header contains links to alternate representations:

<link
  rel="alternate"
  type="application/vnd.google-earth.kml+xml"
  title="KML representation of 2143 AARON WAY"
  href="http://maps.nanaimo.ca/data/property/123170.kml" >
<link
  rel="alternate"
  type="application/json"
  title="GeoJSON representation of 2143 AARON WAY"
  href="http://maps.nanaimo.ca/data/property/123170.json" >
<link
  rel="alternate"
  type="text/xml"
  title="XML representation of 2143 AARON WAY"
  href="http://maps.nanaimo.ca/data/property/123170.xml" >

and some simple geotags:

<meta name="ICBM" content="49.18882, -123.9785">
<meta name="geo.region" content="CA-BC">
<meta name="geo.placename" content="Nanaimo">
<meta name="geo.position" content="49.18882;-123.9785"> 

Finally, within the page content itself, you will find both adr and geo microformats.

<div class="adr">
  <span class="extended-address"></span>
  <span class="street-address">2143 AARON WAY</span>,
  <span class="locality">NANAIMO</span>,
  <span class="region">BC</span>
  <span class="country-name" style="display:none;">CANADA</span>
</div>

<div class="geo">
  <span class="latitude">49.18882</span>,
  <span class="longitude">-123.9785</span>
</div>

Example Property KML Representation:  http://maps.nanaimo.ca/data/property/123170.kml

The KML representation uses Atom Author and Link elements to define the publisher of the data, and to store the KML’s URI and that of its alternate HTML representation.  It also uses a combination of ExtendedData and BalloonStyle entities to separate data from presentation, though I have also included a link to the HTML representation in the Description entity for earlier clients.  Finally, it uses external Style and Schema definitions to reduce the size of the file and to maintain consistency across the site.  I’d encourage you to view the source of the KML file to see how these elements work together.

Example JSON Representation:  http://maps.nanaimo.ca/data/property/123170.json

Example XML Representation:  http://maps.nanaimo.ca/data/property/123170.xml

Example PNG Representation:  http://maps.nanaimo.ca/data/property/123170.png

The native GeoJSON and FDO XML representations are provided by the extension.  No customization is possible, which ensures a consistent implementation from site to site.  The PNG representation is also native (not template), but allows you to specify a MapGuide map definition and a layer for selection.

"Endpoints" (because I’m not sure what to call them):

http://maps.nanaimo.ca/data/property/index.kml

This is a static file that allows KML clients to interact with the property information dynamically through View Based Refresh.  Basically, this file tells Google Earth to request the .kmz endpoint below using a BBOX element that will be used to return only features in view, or a warning if the viewport is too large.

http://maps.nanaimo.ca/data/property/.html

http://maps.nanaimo.ca/data/property/.kmz

http://maps.nanaimo.ca/data/property/.json

http://maps.nanaimo.ca/data/property/.xml

These allow users to perform queries on the data.  There are quite a few variations possible, but they basically support standard FDO filters, bbox, count, and start GET parameters.  There are also some funky parameter patterns that allow for easy searching from HTML forms, in the format: filter_[0-9]_(and|or)_(equal|like|likeleft|likeright|lt|gt)_attributename

http://maps.nanaimo.ca/data/property/.schema

This is a special "endpoint" that allows a smart client to determine the data schema for the XML representations of the feature.

Applications

Now, providing read-only representations of these features is pretty cool on its own, and that is all that the City of Nanaimo is prepared to do at this point.  However, the extension can be configured to allow full RESTful data access:  GET, POST, PUT, DELETE.  Combined with a yet-to-be-released FDO REST provider, users of applications that implement FDO (such as AutoCAD Map 3D, Safe Software‘s FME, 1Spatial‘s MapRelate and Radius Studio, and MapGuide) will be able to read, write, update, and delete data from this extension the same way as they would from local data stores.  I was experimenting with this against an internal server using Map 3D, and it was pretty cool to be able to edit data directly from a web site.

Applications that implement GeoJSON, such as Safe Software’s FME can also take advantage of this format to read and (untested) write to the exposed data.

The GeoJSON representation has a considerable upside for light-weight mobile data editing, for instance in an OpenLayers application running inside Google Chrome (or another Gears-enabled browser) and for minimal-packet data access from mobile phone applications.

All of these are really cool applications from a geospatial professional standpoint, but they don’t really address the primary goal of the original requirement:  enabling easier access to spatial information by residents.  That’s OK though, just by making these representations available and well-linked, the search engines will pick them up and do this part of the work for me. 

This site has been active for less than two weeks, and Google is already ranking some of the property reports first in the results for generic searches within British Columbia and specific searches elsewhere.  For instance, when I search from home for "881 Hunter St" (one of the properties Google has indexed) it comes up as number 1.  When Haris searches from Slovenia, that isn’t the case, but if he searches for "881 Hunter St, Nanaimo, BC" then it does.  Most municipalities have high authority for their location name, and this is a great way of taking advantage of that authority to provide a higher level of service to our residents.

Weaknesses

The current implementation has a few issues.  Unfortunately these will require a substantial refactoring to resolve, so we’re looking at another month or so before we have a public-ready build of the code. Some of these problems are as follows:

• HTTP status codes are often not correct.  For instance, a search that returns a single feature should redirect to that representation rather than displaying the single feature under the search representation.
• Fine control over methods is required, such as enabling/disabling specific methods, requiring SSL, requiring certain group access, etc.
• Existing configuration system grew in odd ways as the code was modified, and needs to be de-Frankenstein-ed
• More control over URI patterns needs to be extended to users, for instance to allow the creation of -edit representations that return pre-populated HTML forms.
• Need revision numbering or data checksum to reduce chance of overlapping writes.
• Need parameter/http header overrides for method (to deal with firewalls) and format (to allow selection from HTML forms)
• Other miscellaneous issues.

Updates

Based on feedback, Haris has enabled JSONP for the .json representations. Just add the argument _callback to the URI, with the name of your desired function as the value. e.g.: http://maps.nanaimo.ca/data/property/.json?filter_1_and_equal_street=ROSSTOWN+ROAD&_callback=rosstown

Call for Feedback

If you have a chance to look at the current implementation and see any areas where it could be improved, we’re really interested in making changes required to meet REST best practices.  We’ve been trying to pay attention to current guidance, but without a real implementation it has been hard to truly understand what is needed.

Thanks!

-J

If you’re using MapGuide Open Source 2.0 (2.0.2 recommended) and are not happy with the default blue selection colour, you can easily change it on a per-install basis by modifying the mapviewerajax template file. This is located at:

(INSTALLDIR)\WebServerExtensions\www\viewerfiles\ajaxmappane.templ

You will need to find the function called RequestMapImage, which includes a line that looks like this:


url = webAgent +
"?OPERATION=GETDYNAMICMAPOVERLAYIMAGE&FORMAT=PNG&VERSION=1.0.0&SESSION="
+ sessionId + "&MAPNAME=" + encodeComponent(mapName)
+ "&SEQ=" + Math.random();


You will need to modify this to change the VERSION to 2.0.0, and add the BEHAVIOR and SELECTIONCOLOR parameters:


url = webAgent +
"?OPERATION=GETDYNAMICMAPOVERLAYIMAGE&FORMAT=PNG&VERSION=2.0.0&SESSION="
+ sessionId + "&MAPNAME=" + encodeComponent(mapName)
+ "&SEQ=" + Math.random() + "&BEHAVIOR=7&SELECTIONCOLOR=FF5300FF";


Before:

After:

The BEHAVIOR parameter is a bitmask that controls what is rendered, and is described in RFC 38. The SELECTIONCOLOR parameter is a hex string in RGBA format, or its integer equivalent. Note for geeks: the A (opacity) portion of the string is ignored; the server code masks this out of the passed value, and then adds 200 (C8) as the line opacity and 160 (A0) as the fill opacity.

Note, the mapagent call allows you the flexibility to add more complicated behaviour to your viewer, such as changing the selection colour dynamically based on the map name, but I’ll leave that as an exercise for the reader (mostly because I’m lazy and use Fusion anyway and wouldn’t benefit from the work).

-J

In this submission, a fix for the patch we add to the SQL engine. One character is the difference between working code and epic fail…

This submission switches the provider to compile against SQLite 3.6.2. Apart from making universe collapse imminent, this comes with a nice performance boost of up to 2x for feature reads.

;)

-J

Well, this evening a new RFC was presented to the MapGuide project steering committee to replace PROJ.4 with CS-Map. Guess I was wrong about the beating part… but am still very happy about the joining :)

I’d imagine that this took a bit of work, but Autodesk MapGuide Enterprise has always used CS-Map, so most of the code was probably already sitting there waiting to go. I’m a little sad to see PROJ.4 replaced, and have some questions about compatibility with existing installs, but this has always been one of our pain points integrating MapGuide Open Source with other corporate applications (FME, Autodesk Map, etc) that used CS-Map. It will be great to see this problem go away.

-J

Why is this significant? Basically, because coordinate system identification and transformation is critical to almost every geospatial application. The bus factor on CS projects is generally extremely low, and they require a high degree of specialized knowledge to deliver accurate results. Having multiple projects out there means that differences in coordinate system handling and metadata can create a barrier to data sharing and interoperability. Making CS-Map open source allows open collaboration between CS-Map, PROJ.4, and other open source coordinate libraries. This was recognized in the community quite quickly, and the MetaCRS project was set up in January to allow open communication and collaboration between these projects.

This collaboration is already bearing fruit. Between Oracle 9 and Oracle 10, coordinate system handling changed considerably. Seeing this, GDAL / OGR developers working on an Oracle driver posted to the MetaCRS mailing list asking for feedback. As a result of this conversation, OGR will be calling out to CS-Map to handle Oracle coordinate systems, joining (or maybe even beating) MapGuide as an early adopter of open source CS-Map. It is clear that MetaCRS provides great value as a key initiative in open source geospatial, and I wholeheartedly support its imminent application to enter OSGeo’s incubation process.

For those of you who care, the source code for CS-Map is available on the OSGeo infrastructure. You can access it through either raw SVN, or in a more human-friendly Trac interface.

Congratulations to Autodesk and Norm Olsen for taking this important step, and to the MetaCRS community for joining together to take advantage of it!

-J

Right now, the agenda is pretty basic: a couple technical presentations, brief chapter business, and pizza all at the Sierra Systems offices a few blocks from the GeoWeb conference.

If you’re interested in coming, or possibly presenting, sign up for our mailing list and let us know so that we can handle the vast numbers :)

-J

Traian Stanev recently proposed the creation of an SQLite provider for FDO. He was quickly arm-wrestled into supporting something close to OGC’s Simple Features for SQL specification, and working with Frank Warmerdam hammered out a GIS spec for SQLite that would work for both OGR and FDO. The beauty is that it’s a single file and can be read by any of the existing SQLite tools.

Traian completed initial development of the SQLite provider a couple weeks ago and Frank expanded OGR’s SQLite support to understand this common specification (this work is in the GDAL/OGR trunk for inclusion in the 1.6 release). These implementations have different strengths. The FDO provider was written to be blazing fast, features an in-memory spatial index, and writes to the FDO binary format. The OGR driver was written for maximum portability and allows writing WKT and WKB. Both implementations will read all three geometry formats and understand the dimension and projection information stored in the OGC-derived metadata tables.

You can download a totally unofficial build of the FDO provider from my website if you want to try it out with MapGuide 2.0 or maybe even Autodesk Map 3D 2009. I have successfully tested it in MapGuide with WKT, WKB, and FGF data. Adding this provider to MapGuide is easy:

• Drop the three files in the zipfile into your Server/bin/fdo directory
• Edit your main providers.xml file to include the SQLite provider using the included XML snippet
• Restart MapGuide

You will need some data. Testing can be done with SQLite files from the OGR sample data directory, but you will eventually want to use your own. It’s fairly simple to convert SDF and SHP. Open up a command window in your Server/bin/fdo directory and type something like:

SQLiteConverter.exe c:\src.sdf c:\dest.db

When creating a new data connection to this file, the provider only takes one configuration parameter: the full path to the file. If you run into any bugs, please post them on the FDO Trac instance.

OGR users that are tracking the trunk build can also try this out. With some amazement, I recently found that the enhancements to this driver had already been documented… obviously OGR places a premium on timely docs. ogr2ogr allows you to do a similar import operation, probably something like (untested):

ogr2ogr -f "SQLite" -dsco FORMAT=WKB dest.db src.shp


You can use additional ogr2ogr arguments to ensure that destination spatial reference and geometry type are written to the metadata tables.

Interestingly enough, a common SQLite GIS specification has been kicked around for quite some time. Last year it was discussed on the OSGeo Discuss mailing list, and more recently further discussion was held on the PostGIS mailing list and a wiki page was set up to collaborate on this idea. Obviously, there is considerable interest within the community. My personal hope is that this specification helps the idea of SQLite as a GIS data store take off.

One area where it could be improved is some kind of integration with Alessandro Furieri’s SpatiaLite extension for SQLite that allows common RDBMS GIS functionality in a native SQLite interface. Unfortunately, neither Frank nor Traian had the cycles to integrate this extension’s data format into the specification or the code at this point. Maybe we’ll get lucky and Alessandro will decide to somehow support this spec, but if not I hope there will be some convergence in the long run.

I know that there was more that I wanted to say, but it’s getting late and I don’t even have time to cut the extra gunk out of this post. Happy SQLiting!

-J