Archive for the Google Category
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
Related posts
You can now do some slightly fancier things with location queries in Google Base, including the good old bounding box.
I am actually a bit surprised to see this. Base has not had the kind of recognition/adoption that I figured would be required for it to get the development resources it needs (an anonymous Googler once said that the problem with Base was that I was the only one who had heard of it). They still have quite a way to go though… For instance, I need a way of uploading KML representations into a column, and of course Base needs to be swapped in as an open back end to MyMaps. 
-J
Related posts
Certainly not the fact that Google is estimating location from cell strength; that’s pretty low-tech and has been done in 911 call centres for quite some time.
What I think is cool is that they are using the 15% of Mobile Maps users who do have GPS to populate their database of cell tower locations.
Once more cell phones support wi-fi (will this EVER happen in North America?) they’ll be able to take advantage of the same infrastructure to build their wi-fi location database.
-J
Related posts
If you’re only looking at adoption by the players like MySpace, I think you’re missing the big picture.
Sure, buy-in by these sites is going to push adoption of the APIs, but for me the real value is that this extends social capabilities beyond the sphere of these "container" sites to the entire web. If you read the Google OpenSocial FAQs, nowhere do they say that its goal is to enhance sharing between portals. In fact, they explicitly say:
This is an effort which we hope will benefit the entire web community. [...] In the future, we are planning to open-source the components that are required to run OpenSocial on your own website.
The code hasn’t been released yet, but the docs make it clear that this vision has merit. OpenSocial uses gData, AtomPub, and a whole lot of REST goodness to allow any website to implement interactive social capabilities.
I see this taking off quickly in blogging (FriendBlogRoll,etc), but I also see huge potential for things like distributed social mapping. Take a look at what Google has done with its Put Yourself on the Map capabilities. That’s pretty cool on an individual mapping level, but imagine extending that out to community maps, implemented similar to the concept of “Groups” on Facebook. Encapsulate some GeoRSS in gData (via Sean) and how hard would it be to build an OpenSocial system where "friends" can all interact with the same map through their interface of choice? OpenSocial is already geo-aware to some extent; the People data includes a GeoRSS GML Point element to locate individuals!
OpenSocial has incredible value for traditional web sites as well. I’ve been considering several different applications for my hobby website (I built this Drink Recipes website in college, and it’s stuck with me since) such as "tell a friend", "friends favourite drinks", etc, etc. All of these could be built as plug-ins for OpenSocial-enabled sites (and of course as an additional plug-in for Facebook), but they can also be exposed on the main website, turning the whole web into one big social network.
One area that I don’t really understand is how OpenSocial deals with distributed authentication. It looks like you can either authenticate locally (through user/pass) or through Google Accounts using AuthSub. I don’t know a lot about this area, but I really think that this may need to be extended to authentication methods like OpenID.
-J
Related posts
OK, so I’m breaking a promise; guess I’m a certified fanboi.
Over at Google LatLong, they just announced increased limits for KML in Google Maps. The real news, though, is that they are now following network links based on zoom extent. This means that there are more applications where you can just publish a KML service rather than messing with the Maps API.
For example (careful, it can be pretty sluggish in certain browsers) here’s my city’s main KML file displayed in Google Maps:
As cool as this is, in many cases you still have to design your KML files differently than you would for Google Earth. The browser is very limited in the amount of data that it can display–so you have to send back less data–and certain visual elements are handled differently in Maps. To deal with these limitations, there are several things that immediately come to mind as potential performance gains:
- In your network links, check the bounding box extents before returning data that is too dense for the current zoom level. Basically you just take the max (or average) of width and height, and don’t return data unless it’s lower than a predetermined value. This was the original method for controlling content in Google Earth before Regions were introduced, and is quite effective in two dimensions.
- Stay away from fancy elements like multi-geometry for mouse-overs. They don’t work in Maps. If your information can be communicated using points, then stick with points.
- If you must use lines/polygons, simplify your data so that unimportant vertices are removed
- Keep the information in your descriptions to a reasonable level.
It may also be worth experimenting with Regions to see if they are supported and make a performance difference.
Check out the original post for more examples of KML in Maps.
-J
