One day to go before Christmas, and the UK government have made an astounding contribution to the OpenStreetMap project. It will shortly be announced that through collaboration with the Department for Transport, Traveline, and OpenStreetMap, most of the NaPTAN and NPTG datasets will be offered to OpenStreetMap as a one off bulk import, with the possibility of updates in the future.
This means the import of up to 350,000 geocoded public transport access points, such as bus stops, ferry terminals, trains stations, etc, along with the import of up to 50,000 geocoded place names in a hierarchical format.
Once again, a big thank you to the DfT and Traveline for this massive contribution, and to the OSM Foundation for making it all possible.
A year ago Matthew Dillon went into some detail about the new HAMMER filesystem. It’s now reaching stability, and will hopefully be sent forth in the upcoming v2.0 release of DragonflyBSD. All the interesting bits can be discovered here and here. A few features to note, though, are…
1 Exabyte of storage
Online data migration, replication and evacuation – multi-master disk replication across WANs anyone?
Logical data retention policies – ie you can have block level replication to a remote site with large slow disks, but with a lengthy data retention policy
Inbuilt volume level and file level versioning and snapshotting – just mount up or request a version number, and you get a snapshot from that time. A bit like MS VSS.
Inbuilt reblocker for defragging, expansion and contraction.
PF linked connection state recovery – keep those TCP links alive throughout a router reboot.
These are just a few of the features, read the documentation to find out the rest. It may turn out to be a ZFS killer, but anything with replication like this sounds good to me. Now we just need to wait for it to be ported to Linux, assuming Zumastor and Tux3 don’t rule the roost by then 🙂 For what it’s worth, there’s some info on Tux3 and HAMMER features and ideas at http://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3
It’s probably already been covered, but my 30 seconds of Google-Fu hasn’t turned anything up so bear with me…
Take one OpenMoko phone,Â a geolocation service like Fire Eagle, an online celltower database such as CellDB, and some code to use those lovely d-bus bindings, and you could have a location reporting service that’s easy on the battery and mostly precise in urban areas. If your area isn’t covered by CellDB, then run around with the OpenMoko GPS reciever online for a while to report celltower locations, and you’re sorted.
Use all of the above to create services like Socialight, location based Twittering, rough geotagging for photos (courtesy of Flickr and FireEagle [both Yahoo companies]) , pre-emptive OSM tile downloads, Asterisk routing – you could even implement ex-girlfriend logic to it all, if she were to have a similar device 🙂
Well, I’m sure someone has thought of this already, but I thought I would commit ideas to storage just in case. Once my FreeRunner arrives, I know what I’ll be working on