GeoRSS to KML through Drupal

I was working at the end of last week on pulling GeoRSS-enabled feeds into Drupal and attaching the location information for each item to the nodes created from each item. Once it's within the flexible world of Drupal, all the benefits of having attached geodata then apply.

With the number of GeoRSS enabled feeds around the world slowly growing, the opportunity to make your own geospatial mashup machine (borrowing the name slightly from Zacker's Drupal Mashup Machine screencast) is now here.

Much of the functionality was already there in contributed modules - aggregator2 module to pull in feeds (not sure what's going to happen to this module in the future) and location module to store location data for nodes. Then my recently released KML module can feed all of this information back out in different ways (eg by tags assigned to the incoming feeds), GMap module can display them on top of Google Maps.

The only part that was missing was the bit to pull geodata from the incoming RSS feeds, based on the GeoRSS standards, of which Version 1 was released last week. To do this I created a little module (GeoRSS module) that tied aggregator2 module and the location API together.

The functionality here overlaps slightly with the location module in that it already inserted geographic information into RSS feeds being sent out by Drupal, but I prefer to use the module as an API to store the information and then extend it in other ways. In the future the GeoRSS module could be extended to deal with more complex geodata than simple points, being able to cope with lines and areas as well if that time comes along and people have that need.

Searching by location in Drupal

There have been great improvements to search in Drupal 4.7 including the ability to extend it to search content from different modules. What I'd like to do is incorporate location into the search (instead of being a separate tab as it presently is using the location.module), allowing people to type their search text, choose which node types they'd like to search and then type in the name of a place (eg a city) they'd like to search near to.

To simplify the input, the new AJAX autocomplete functionality could be used to suggest places based on the name you're typing in. The co-ordinates of this place could then be used to filter the nodes that were returned from the search and allow for the ordering of search results by distance if desired.

I'm conscious that a search screen should be as simple as possible, but think this would be a useful addition for people who wanted to search for things by location. Perhaps allowing people to type '[searchstring] near Stuttgart, Germany' would be a better way of allowing location based searching. The autocomplete could still be used for that as well, by autocompleting only the bits after a 'near' statement.

Any input from the community is welcome, including thoughts on the interface and on how the back end hooks in the search system may best be put into place.

Location-based functionality within Drupal

Having laid out last week some of the overall location-related functionality I'd like to see within Drupal, I wanted to start a proper list of areas around which I would like to see development within the Drupal community. I'll be putting effort into creating and improving many of these, and hopefully working with others who want to help as well.

I've broken down the functionality into three sections of the data flow - incoming data, internal processing and display, outgoing data and external systems. Please feel free to leave comments on which bits you'd like to see sooner rather than later, and any extra functionality that I've missed off the list.

  • Incoming data
  1. Ability to tag individual nodes in system with location information
  • by address (functionality already exists)
  • by clicking map
  • by coordinates
  • Ability to extract location information from EXIF tags in jpg images
  • Ability to automatically extract location of items from incoming feeds
    • from RSS feeds (using the geo namespace or GeoRSS implementation)
    • from KML feeds?
    • from GML feeds?
    • Internal processing and display
    1. Ability to search near location
    • by address (currently can search near zipcodes only)
    • by city/country
    • by clicking on map (or entering coordinates)
  • Listing of similaraly tagged nodes nearby
  • Mapping
    • Simple visualisation
    • Mapping nodes on top of imagery
      • Google Maps
      • Yahoo Maps
      • Maps from a GIS (eg MapServer)
    • GIS functionality
      • Point in polygon analysis (for example, to find which region a point lies in - useful for determining which country a pair of coordinates lies in, or which administrative district a point lies in)
    • Community map creation
    • Map of nodes with ability to filter by users, buddies, location, etc
    • Outgoing data
    1. Export any Drupal page as a feed (or layer) - e.g. search terms, tags, node types etc
    • RSS feeds with location imformation embedded
    • KML feeds
    • GML layers (using WFS from OGC to allow data output capabilities to be determined)
  • Ability to filter by geographic location, user, content type etc
  • Ability to export single points
    • links to maps (functionality already exists)
    • link to Google Earth placemark (complete)
    • External systems
    1. Creation of a geocoding system that can be accessed and queried by other systems (including Drupal) through a RESTful style XML interface - similar to Mikel Maron's geocoder

    updated 16th February 2006

    After the OSCMS summit

    The OSCMS summit is now over, but it's been a great week, packed full of information and activities. I've met a number of the other people interested in using Drupal for location-enabled activities, from simply tagging of content with a geographic location, to mapping those locations (and others) and actually implementing more GIS-like functionality.

    One of the things I really want to see happen (and will certainly be helping with) is making sure that we are complying to standards of geographic data sharing so that information from outside the Drupal framework can be pulled into Drupal, and information can similarly be pushed out and used by other systems - from Drupal sites (through GeoRSS feeds - or the other GeoRSS standard being proposed), to Google Earth (using KML) and also systems capable of reading in OGC-compliant feeds (probably implementing a WFS interface).

    Improving the usability and functionality of inputting geographic information is also high on my priority list, trying to get away from the largely US-centric input that is present at the moment. Of course, that's not easy when the availability of reliable and open geographic data is scarce outside of the USA.

    I'll be keeping track on here of the bits I'm working on - and others are working on - here in my blog over time.

    Every cloud has a silver lining

    I flew home last week for a Christmas break with family and friends. I had booked myself onto a low cost carrier (HLX) back to Manchester and then BA from Manchester back to the Isle of Man the following day. After queuing in the wrong line for about 15 minutes (Who'd have thought that 'All Flights' actually meant 'All Flights - except Manchester, which has a huge great big queue, the next aisle down'), then another 30 in the right line, I made it swiftly through to the departure area. The queue to go through passport control was short but soon grew as the guards started to become concerned that the guy in front's passport may be fake. It took them at least 20 minutes of inspection before they gave this guy his passport back. They were easier on me but still looked suspiciously at my rather worn passport under the glare of a UV light and magnifying glass.

    The flight was delayed a while, as it later turned out that the inbound flight had some technical difficulties. What that meant though was that the full plane-load of people actually got to travel in a much more spacious backup plane operated by the parent company, Hapag Fly.

    I watched with interest as the overhead screens (once they'd finished playing random Christmas music videos) started to show our location and proposed route into Manchester. This plane locator, it turned out, went miles beyond anything I'd seen on flights in the past. To start with it showed the standard plane, pointing in the direction of travel, on top of a satellite image of Europe. Part way into the flight it began to show something more interesting - virtual views out of the side windows and out of the cockpit, using detailed satellite imagery. I thought it was a great use of geographic data, especially on flights where you're going overland and where the view is obscured either by cloud or just by the fact that you're flying through the night.

    Subscribe to RSS - location