First install of Drupal 5.x

I installed what will be Drupal 5.x on my computer last night for the first time and was amazed at how easy it was to set up and get it working out of the box. Drupal 5.x is still in development but it's possible to download the current snapshot and try it out - and it seems like it's not too far from being ready for release.

After downloading the latest version of Drupal to my computer, accessing it through the web browser, it now gives a friendly screen telling you to give the correct permissions on the configuration file instead of giving SQL errors as 4.7 had done. Once I'd set those permissions, I was taken to a configuration screen that asks for database information (which I still had to set up by hand, though in the future this step may also be done for you) and that was it. Click the button and Drupal is ready to go. No more worrying about importing database tables and everything, it's all taken care of by the installer now.

I've not had a proper look around yet but the overhaul of the administration section seems to break things down into much more understandable areas (content, users, site configuration, etc) than the previous flat listing of everything. It may take me a while to find where some things have moved to, but it's a great step forwards in making Drupal more friendly to site administrators.

I'll be starting to upgrade my modules for 5.x soon, though I am planning to continue support for the 4.7 branch for some time still.

Licensing information in Drupal feeds

After releasing the Drupal GeoRSS module the other day, I sent a message to the GeoRSS mailing list. It created some positive responses and an interesting question back from Andrew Turner of the High Earth Orbit blog, who is interested in giving people the ability to create their own personal geospatial aggregators. He's done some work in this area already, in the form of Mapufacture, a geospatial aggregator that allows people to specify regions they would like to receive feeds for.

When you start to look at aggregating and redistributing information you should really be clear about the licensing of the information that is being brokered. How is it licensed, what are the restrictions, etc? Hence Andrew's question to me was whether Drupal has any way of specifying applicable licenses for its outgoing feeds. I hadn't heard of anything in the community, but whilst researching the area today I came across some Creative Commons syndication examples and also spoke to Boris Mann of Bryght - one of the biggest Drupal shops - about whether this had been implemented in Drupal already.

It turns out it has: the Creative Commons module allows Creative Commons license information to be added per feed or overridden on a per node basis. I need to do some more research into whether there are more general extensions that support other types of licenses than just Creative Commons, but it's a great start.

The next step would be to ensure license information is extracted from feeds being pulled into Drupal by the likes of aggregator2 module and its successor(s). It's becoming clearer from looking more and more into the flow of data into and out of Drupal that there are lots of use cases for ensuring standards compliant information can be pulled from feeds and applied to nodes in Drupal and then also included in outgoing feeds.

Off the top of my head, we have the basic information itself - title, body, author, date, etc - and also additional information such as location, event data, license and enclosures of different types, as well as numerous others presumably. Each module should listen for new nodes being created by an aggregator module (using Drupal's extensive hook system) and handle any elements from the incoming feed as required - so the GeoRSS module would handle geodata, the event module would handle calendar dates, times, venues, etc, the Creative Commons module would deal with licensing information, and so on.

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.

Drupal KML module released

Tonight saw the release of the KML module I've been working on for the Drupal content management system. The main features of the module currently include the ability to:

  • add a KML link to the bottom of all spatially enabled nodes
  • view all spatially enabled nodes in Google Earth
  • view nodes tagged with a certain term
  • view nodes from within a group
  • view search results
  • determine order of nodes that are displayed in Google Earth, allowing for alphabetical or time-based flythroughs of nodes for example.

If you are interested in this module, please feel free to try it out. You can see parts of the module in action over at geodan.org/kml-module.

It's been developed on Drupal 4.7 and the source is available in the CVS repository or as a package. If you come across bugs or things that aren't working as expected, please add them (along with any suggestions or feature requests) to the issue tracker on drupal.org.

It took me a while to get to grips with using CVS and specifically MacCVSClient (to add to SVN which I also recently got to grips with) but finally I managed to import the module source to the Drupal CVS repository. I think I still need to tag it to make sure it's packaged properly from the module description page and therefor easier to download, but that can wait until the morning.

Design for geodan.org

Design for geodan.orgGeodan.org has a new theme, for the most part at least. I got the basics done on Monday night having begun with the basic bluemarine theme that Drupal ships with and has enabled by default. I had an idea in my head of what I wanted to acheive with the theme and it didn't take me too long to get it into a state that I was relatively happy with.

It's best viewed in Firefox or Safari at the moment as I can't get the opacity levels to have any effect in Internet Explorer. It's just no good if you can't see the earth through the body of the page (thanks go to NASA for that beautiful Blue Marble image of the earth).

Drupal geospatial testbed

It's been long enough that I've been working with Drupal and not had a site of my own that runs off it. I'd love to migrate dankarran.com to Drupal but it would take some time to migrate. So for now I will leave this site as it is and create a new site aimed at demonstrating Drupal as a Geospatial Content Management System.

geodan.org will be a testbed for geospatial functionality within Drupal. I'll be using existing modules such as the location module which gives a basis for handling geographic information about users and nodes in a site, gmap module which allows for Google Maps to be easily created, as well as a number of others. In addition to these I'll be adding the KML module I've been working on as part of my day job, and also the WFS Server module which still has a little way to go before it's ready.

Right now it's just a shell, but over time it will grow. And as it seems somebody over at the OGC recently picked up on my last post about Drupal as a WFS I should try and make that sooner rather than later...

Drupal as a WFS

Recently I have been looking into the specifications for the Open Geospatial Consortium (OGC) Web Feature Services (WFS) that provide a standard interface between geographic information systems (GIS) for the transfer of geodata.

I've been starting to think about it in terms of using the Drupal web framework as a geodata store that can be used by any standards compliant GIS. Drupal can already be considered a Geospatial Content Management System (GeoCMS) so this seems like a natural extension to allow other systems to talk to it.

In GIS, the term 'layer' is usually used to group together geographic information relating to the same kind of feature, e.g. forests, places or roads. These are often stored in different files or different tables in a database. In Drupal the equivalent concept is a little more flexible and fine-grained. All of the information is stored in one place (with the ability to extend a basic piece of information with extra attributes) and can be filtered by any number of 'tags' that may be assigned to different pieces of information.

Using a WFS server as an interface to data held in Drupal would mean that systems would have access to any number of geographic datasets simply by combining tags to retrieve the data that they need.

I'm looking forward to putting more work into building up a spec for a WFS Server module for Drupal, and hopefully one day geographic information systems will be able to query Drupal for dynamic geodata, and even create, update and delete it as well.

My first paid Drupal site

Over the past week I've been working on building, theming and tweaking a new Drupal site for a friend. It's my first paid (as in, with chocolate) Drupal-based website outside of the ones we maintain at work, and it was great to be able to put into practice some of the tips and tricks I've picked up over the past eight months or so.

I'm quite pleased with the amount of work that Drupal removes from creating a website (steep learning curve aside), and how flexible it is out of the box, without even beginning to look into the many modules that you can plug and play with the framework. I'd say the majority of the time spent working on the site has been walking my friend through, showing her how to add new content, link it all together and all that good stuff.

The site went live today but isn't quite polished, so I'll leave the link off for now. At least until I've had a chance to make all those last minute tweaks that inevitably don't show up until you leave the nice comfortable environment of Safari and Firefox and see the thing torn to pieces in Internet Explorer.

The importance of interoperability

When a colleague asked me today if I knew any way of converting XML to CSV, I was up for the challenge. It turned out that all she wanted to do was import event information into Google Calendar from Groove. Simple, right?

Google liking to follow standards, they allow you to import iCal feeds and even let you import CSV files from Outlook (because that's presumably the main userbase and Outlook doesn't export iCal). But try to import the XML export from Groove, and it tells you - rightly - that it's broken and it can't understand it. Admittedly it's not a format that Google says it can import, but from looking at the file, it does look very broken.

Why have an export facility in Groove that allows you to "export Calendar events for importing into another Calendar tool" when it exports in some propietary format that no other programs read? Just because it's XML doesn't necessarily mean it's interoperable. Groove doesn't even let you export as old-school CSV.

In the end it took the enabling of the "publish all events to Outlook" option, then going into Outlook to export the CSV, and only then is there a usable file that we can import into Google Calendar. It shouldn't be that difficult, should it?

I'm glad Drupal supports iCal - even if it doesn't allow for imports yet. With node_import, it at the very least allows imports of CSV calendar files.


Subscribe to RSS - Drupal