Just a quick note asking you to VOTE for the solutions you think are best in the current GeoWorld Geospatial Leadership Awards.
Some interesting entries have been nominated. In particular, FDO and Fusion (both open source applications) are competing alongside other prominent applications in the Innovator Award category.
Full disclosure: My work on earth.nanaimo.ca (built with MapGuide Open Source technology) is nominated for the Public Enterprise category. Please only vote for it if you think it’s the most deserving solution in this category.
-J
Related posts
James’ recent post about the GIS Interchange File reminded me that I’ve been meaning to discuss some recent activity on the SQLite front in both FDO and OGR.
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
Related posts
I have been happily hosted at pair Networks for about twelve years now. A few days ago, one of the users on their private newsgroups asked if anyone had compiled MapServer there. I had never compiled MapServer before, so I figured that I was incredibly qualified to help 
Normally MapServer appears to be fairly simple to install, but there were a couple annoying complications in my scenario. The first was that pair Networks runs exclusively on FreeBSD. The second was that it is an entirely managed service: no root access allowed, no ability to run ldconfig, no changes to php.ini. The net result was that all of the dependencies had to be compiled in static mode, and that a custom PHP CGI had to be used so that the extension_dir could be overridden.
The notes that I took during installation are available if anyone is interested. These are not guaranteed to be accurate, but are pretty close. If you are on pair Networks and trust me (are you crazy?) you can see if the binaries (5 MB) work for you. They are mostly static, so there shouldn’t be any dependencies other than the standard pair libraries, but you never know until you try…
As long as I had it compiled I felt the need to play around. I grabbed some test data from the awesome OSGeo4W project (which allows Windows users to run a large part of the OSGeo stack without hassles) and put them up on my site:
I did run into some problems that I didn’t take the time to solve. I couldn’t get GEOS to link into MapServer properly, and there were some issues with some of the image formats in GDAL. I’m sure that these could have been overcome in time, but it’s the end of the weekend and I have to get back to real life
-J
Related posts
Looks like the east coast of Vancouver Island got a huge resolution increase in Google Earth. Previously, a large proportion of this area was low-resolution satellite imagery. Now much of the island appears in what looks like half-metre (18 inch) resolution. The copyright on this data reads IMTCAN, which I assume is Integrated Mapping Technologies. In general, this is a great upgrade and these photos really show off some of the recently improved terrain.
I feel sorry for the folks in Port Alberni though… Not only did they miss out on the new imagery for most of the city, but they also have a huge imagery glitch in the middle of their community:
There are a couple other places where the imagery was not very well edge-matched (some white triangles in the middle of the Strait of Georgia) and there are some really odd colours in the water, but I think that most people will be happy to trade consistancy for clarity.
-J
Related posts
The FME User Conference is always great value. You get to see interesting presentations, learn about new technologies, and talk to bright people from all across the industry. This last point is probably the most important to me. Mixed in with other great conversations, I got to chat at length with Ed Katibah about SQL Server Spatial, and Don Cooke told me I dressed too well to be a neogeographer
It is also the best place to corner an FME developer. I managed to grab Tom Weir, Safe’s KML guru, and go over some of the changes in KML support with FME 2008. During a presentation on the first day of the conference I had included an “easter egg” where I spoke about how to enable active mouse-overs in KML using FME. To my chagrin, after a couple minutes with Tom I realized that my advice was not exactly best practice, and with FME2008 becomes downright ridiculous.
Here’s the before shot from my slide deck (zipped workspace):
And the after shot once I applied what Tom showed me (zipped workspace):
Obviously, the FME 2008 press release should read: “KML Support in FME: Now with 50% less fat!”
KML FME has been generating multi-geometry for information points for quite some time, so that cuts most of the data wrangling out to generate the info point and merge the features into multi-geometry. And FME 2008 will automatically generate StyleMap elements for you if you follow a couple sneaky tricks.
First, when you create each KMLStyler, set its name to the style ID you want it to receive:
And second, on your geometry set the kml_target_style_normal and kml_target_style_highlight attributes to the IDs that you created in the KMLStylers:
That gets my embarrassment out of the way, but doesn’t even begin to touch on the extent of KML 2.2 support in FME 2008. Another issue that I have written about is extended data or schema support, and I am happy to say that FME deals with this. Attributes are stored in your output KML as extended data by default, and it is easy to generate a BalloonStyle template. Here’s my first take on this support, which does a great job of separating data from presentation (zipped workspace):
And a quick look at the new basic editor which is included in FME and used for modifying BalloonStyle templates:
Which gives us this KML output (source).
There is a going to be a lot more to the KML 2.2 support in FME 2008, including generation of image pyramids for PhotoOverlays, but I’ll leave it to you to explore those on your own.
-J
