Posts Tagged FME
Live from FMEUC, it’s the Tim and Jason show!
Posted by Jason Birch in FME on August 11, 2009
OK, so better late than never. At the always-awesome FME User Conference, Tim Taylor and I did a short presentation on Nanaimo’s use of FME Server.
I think we did OK, but I definitely need to spend a bit more time polishing both my presentation and the slides next time.
Check out other great FME UC Videos on Safe’s user conference website. There is a lot of valuable videos, with case studies and technical presentations which will show you how your business processes could be improved by using FME.
As an aside, I count myself fortunate to live within driving distance to two of the best geospatial conferences in the world. In these times of tight budgets, I am incredibly grateful to be able to attend both the FME User Conference and GeoWeb.
-J
SQLite Spatial Files in FME 2009 through the Magic of FDO
Posted by Jason Birch in FDO, FME, Formats, Open Source, Tutorial on December 2, 2008
Writing the FDO/GDAL style of SQLite spatial files (see previous post for details) just got a LOT easier for those of us using Safe Software’s FME Desktop, even the affordable Base edition.
Over the past month, developers at Safe Software and the author of the FDO SQLite provider have put some time into ensuring that the SQLite provider will work properly with FME 2009. Reading worked fine out of the box, but writing required a bit of effort. FME needed datastore creation and schema writing added to their generic FDO writer, and the FDO SQLite provider needed to account for the way that FME writes to multiple schemas.
Here’s how you can take advantage of this provider in FME (and in other FDO 3.3 consumers, such as MapGuide Open Source 2.0):
- Download the unofficial binaries for the SQLite provider from my site
- Open this zipfile and copy the SQLiteProvider.dll file into your FDO directory (default c:\Program Files\FME\plugins\fdo\)
- Make a backup of the providers.xml file in that directory, and then edit the original, adding the contents of the sqlite_provider_entry.xml file in an appropriate location.
Once this installed, writing to SQLite from within FME is dead easy…
1. Add new FDO Destination Dataset:
2. Go to Settings and specify OSGeo.SQLite.3.3 as the provider name:
3: Specify the filename you want to write to:
4. Optionally, set a spatial reference system, and click on OK:
That’s it; now you can start adding tables to your SQLite file as you would any other destination dataset in FME!
As far as I know, Safe will not be distributing the SQLite provider directly with FME 2009 (it’s still in beta) primarily because the provider is not officially being released for FDO 3.3, and partially because the provider is still under heavy development. Fear not, though. I am building this provider against the 3.3 branch as often as necessary, and will post binaries as I do.
The relative ease with which this format was supported by FME can be attributed to Safe’s foresight in exposing FDO directly, rather than just using it behind-the-scenes in their SDF3 writer. They also allow FME to act as an FDO provider, which enables users of products that use FDO for their data layer (such as AutoCAD Map 3D) to access the full range of formats that FME supports.
-J
KML Goodness from the FME User Conference
Posted by Jason Birch in FME, Google Earth on March 13, 2008
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
A really Safe place to be…
Posted by Jason Birch in FME on March 3, 2008
I’ll be attending and co-presenting with my colleague Matthew Dunstan at the FME Worldwide Users Conference later this week.
I am really looking forward to this conference, and am confident that it will measure up to the outstanding event that Dale, Don, and their team put on in 2006. The technical quality and value for users of FME is truly outstanding, and sets this conference apart from many other industry events.
I’m getting into town on Wednesday night and staying at the conference hotel. Drop me a line if you’re going to be there and want to hang out.
-J
GeoRSS and Google Maps for Fire Response Notifications
Posted by Jason Birch in Formats, Google, Nanaimo on February 18, 2008
One of the developers in my section (Chris McLuckie) has been working on a replacement for our creaky old fire incident notification system, and launched the new City of Nanaimo Fire Daily Calls page last week. If you’re interested, you can read the official press release (pdf).
Basic improvements include:
- automatic pull from our FDM Computer Aided Dispatch (CAD… a popular acronym) database, removing requirement for dispatchers to manually update this list
- publication of the incidents in multiple formats (GeoRSS, HTML… KML planned for an intermediate update)
- integration with Google Maps
This is what the query interface for incidents looks like:
This is the embedded Google Map (using the GGeoXML class to hit the GeoRSS feed) showing incidents for the selected day:
This is the basic statistics interface allowing users to see incident activity for a date range (which also has a similar Google Map embedded):
And this is what the GeoRSS feed looks like in Google Maps
And now for the technical stuff…
Chris has put together a fairly strong process for extracting and displaying this information publicly, consisting of several components:
- A monthly FME process that reads the current 9-1-1 streets shape file and places it into a normalized database structure (one-to-many between lines and coordinates). This allows easy formatting of coordinates for different output formats (GeoRSS, KML, etc) in native ASP.Net.
- A SQL Server Integration Services job that pulls initial incident data from our CAD database, as well as updated information from the RMS (records management system), generalizes it to block ranges to reduce privacy concerns, and writes it our publicly accessible webserver.
- An ASP.Net web application that transforms an XML serialized data set into GeoRSS (and eventually other formats) using XSLT.
- An ASP.Net web application that provides the rudimentary user interface, including the incident query mechanism, incident statistics, and Google Maps integration.
The current applications are accessed via IFRAMEs because although our standard for web apps on our main site has changed from ASP to ASP.Net, our web site migration is still under way. Once the web site is redeveloped, these will be standard non-encapsulated web apps.
This is definitely just a starting point for us; the framework that has been used for this application was designed so that we can add other data sources that make sense for GeoRSS syndication, such as recent business licenses, building permits, etc. This aligns with our website redevelopment, where we are using RSS/Atom as an alternate access mechanism wherever possible.
As an initial project, there are certainly limitations with this implementation. For instance, we haven’t defined an API for pulling down specific categories or date ranges from the RSS feed. Also, because the GGeoMap class doesn’t expose properties of specific features, we were unable to link the incident rows with the map (pan and pop-up). There are third-party interfaces to Google Maps (GeoXML, EGeoXML) that work around this, and of course the option of just creating the lines ourselves, but we were trying to keep coding and dependencies to a minimum. There is a ticket in the Google Maps API issue tracker for this, so hopefully it will be addressed eventually…
Ideally we’d be using a spatially-enable database (such as PostGIS) as the underlying data store for this application, but we don’t have PostGIS in place on our public webserver yet.
-J
User Map
Recent Comments