Technical Ramblings

JOSM is the ‘advanced’ OpenStreetMap editor, used by most technical users of OpenStreetMap. It is written in Java, but despite that 😉 it works reasonably well. Jokes about Java aside, JOSM is an excellent example of the type of ‘advanced’ editor that most GIS professionals would feel comfortable with* after some work understanding OSM: it has familiar interfaces for drawing lines, displaying and editing attributes, etc.

It works well on the eeepc: Java comes pre-installed, so it’s simple to get started; just download josm-latest.jar from the josm homepage and run (from a terminal) ‘java -jar josm-latest.jar’. You’ll be presented with a message that you can’t read, but it’s not really important. (The reason you can’t read it is that the message is apparently laid out with ‘fixed’ border sizes of ~350px… meaning the message only has about 100px across on the eee’s screen. “Oops.”)

First, we’ll set up the interface so it has more room for attribute values on the right hand side, by hiding the command history (Alt-O) and the selection list (Alt-E). You can bring these back at any time using the same shortcuts.

Next, we’ll download some data. The easiest way to download data for an area you’re interested in is to navigate one of the ‘slippy maps’ that OpenStreetMap has: my personal preference is to use Information Freeway, since it has a full page map. To see the area I’ve been mapping in, check out Grand Cayman; you can use this URL in JOSM by copying it, then selecting “File”, “Download From OSM”.

Navigating the map once you’ve downloaded it isn’t too difficult: by default, you’re in ‘zoom’ mode, which will do a ‘rubber band zoom’ (As we call it in OpenLayers) by default. You can switch modes using hte keyboard: simply hit ‘s’ (for select), ‘a’, for add, ‘d’, for delete, or ‘z’ to go back to the default ‘zoom’ mode. Moving the map can be done with Right click->Drag, and the arrow keys can also be used for navigation if you hold down ‘Control’. Zooming in and out can be done with the ‘scrollwheel’, which on the Eee is the right hand side of the trackpad.

In general, the editing experience of JOSM on the eee is actually significantly better than my mac. The reason for this is simple — the Mac doesn’t have a right click, which means that navigating by dragging the map doesn’t work. Additionally, one of the ways to get information about nodes near your cursor is the middle click. On the Eee, this is as simple as tapping two fingers on the trackpad.

That said, there are some significantly lacking aspects in using JOSM on such a small screen that don’t come up on the Mac:

• Toolbar is too tall — can’t select buttons towards the bottom of the list
• Preferences dialog is too small: can’t see the ‘okay’ button, so can’t enable plugins (one of the coolest aspects of JOSM)
• Inability to resize right hand side control panels: this means that the ‘layer switcher’ panel is as tall as the tags panel, which isn’t really neccesary for me. Similarly, ‘relations’ (Which are seldom used, at least at this point) share equal play time with tags/attributes, which is somewhat unneccesary

All in all, JOSM doesn’t work out too bad on the EeePC, but the lack of plugins due to the preferences panel being ‘too tall’ is somewhat annoying, and I haven’t yet figured out how to get around it. It’s possible that installing the plugins manually will work okay, but it’s been so long since I’ve installed them from within JOSM that I don’t even know how anymore!

* Of course, many GIS professionals working with OSM are going to have a steep learning curve, due to the nature of OSM’s data model: the majority of the vectorization software (at least, the stuff that I’ve seen) works with features, whereas OSM is topological, which makes interacting with the data a very different experience.

Got my EeePC. It’s so tiny! I love it already; I haven’t even pulled out the macbook tonight. (I’m sure this won’t keep up forever, since there are some things I really can’t do on a screen this small.) I did some playing with OpenStreetMap editing with Potlatch (painful, but not horribly so), figured out how to get a terminal up and running (ctrl-alt-t; handy), got subversion installed after setting up some extra repositories based on instructions in the eeeuser wiki, etc.

I will want to see if I can start building some tools targeted at the small screen resolution in OpenLayers or what have you, so that I can edit maps more effectively, and do other things like hook up GPS traces. I’m leaning more and more towards building myself some nice custom UIs for editing OSM, just to figure out how to do things that work well on my hacky platforms.

I have no plans (for the time being) to switch away from the ‘friendly’ interface, which seems (to me) to work just peachy keen. I am happy with my decision: even if I only use this thing intermittently from today forward, it’s a worthwhile and nifty toy to have, and I’m liking it a lot.

Just bought the Eeepc… should be here in a couple days. (It’s only coming from NYC via UPS Ground — since Boston is so close, maybe it’ll be here before the weekend…)

I’m going on a trip in a couple weeks, and wanted something I could do mobile mapping on without bringing my big, clunky laptop with me. I started looking at the EeePC, and bumped into the CloudBook — 30% longer battery life, 30GB hard drive instead of 4GB flash drive, same price point. It’s sold through Walmart, which is a major downside, but I might have been willing to accept the moral qualms that came with…

Until I found out that the trackpad is the little rectangle in the upper right corner of this picture on Flickr.

I want to do mapping with whatever I buy, and that little thing is simply not going to cut it. EeePC it is, if anything…

I’ve asked $Coworker to bring his in today to see if it’s really the right size for me: I’ve seen his before, but only for a brief bit, and want to get another feel for the size before I go with it. I’m hopeful that if I do this purchase, I can make the Eee something I can take with me everywhere *instead* of the Macbook — so vacations, etc. aren’t besotted by me pulling out a gigantic Apple laptop, but instead a little thing that is designed more for the ‘on the go’ case — and especially something that I won’t be trying to do work on, so that I’m not working during vaccations so much. 🙂

I really like the Leaf of Trust diagram, and from there I was able to wander out to a lot of different sites. For example, I was able to see that if you remove the most recent signature I obtained, from a Ari Pollak (on NYE, while drinking Tequila… eerily reminiscent of the xkcd comic posted earlier that day), the web of people who trust me is about one third the size under the default trust model: without Ari, With Ari. As far as I understand it, the default is to go 5 levels deep: this means that without Ari, I get to 2953 people, but with his sig, I get to 10272 people. Not a bad jump.

Things like this always make me want to go out and expand the web of trust. The fact that there only appear to be ~38,000 keys is almost an embarrassment. There are a number of reasons for this — the gnupg documentation, for example, practically screams “If you’re not an expert, don’t use this toolset”, which is hardly the right attitude for building the web of trust. More poignant to me, though, is the fact that it’s a somewhat difficult social barrier to break to move from exchanging business cards — which I do with ease — to exchanging IDs and GPG fingerprints. I’m hopeful that I’ll be able to overcome this, because I’d really like to stop seeing the “Signature is not trusted” warnings in my mail client. But also because I think building a stronger web of trust is important in general. Currently, the web is something where you can trust who is saying something. I’m hopeful that that can be changed.

That said, I don’t think that GPG-style public key web of trust stuff is likely to be the solution in the long term. It seems like karma-based systems — where determining who someone really is is less important than determining that what they say makes sense — are the ‘wave of the future’. However, I’ve always lived in the past as far as noticing that technology is changing — and I’m not about to change that now.

So, if anyone meets me, and wants to exchange fingerprints, please feel free to ask! I’ve started carrying copies of my gpg fingerprint in my wallet, so I can exchange keys with confidence — and even if I can’t sign your key, you can sign mine. If you’re running Debian (or Ubuntu), ‘caff’, a utility provided by the ‘signing-party’ package, is super-useful for this: Simply type ‘caff C90820BA’, and it will show you the fingerprint and ask you if you want to sign. You compare the fingerprint to the piece of paper you have with the correct ‘print written on it, hit yes, and it then sends it off to the email in the key. I have no problem breaking the social barrier that prevents pulling out ID to prove who you are — I just have a problem doing it first.

I took the last week of the year off from work, and I spent most of the time doing a push to get some of the software that I help develop into Debian.

Debian is a Linux distribution that is built and maintained almost entirely by volunteers: it is the basis of the very popular Ubuntu operating system used on desktops, and is also used heavily for both desktops and servers at MetaCarta. Getting a package into Debian’s main repository is an indication that it meets the projects (relatively stringent) guidelines for inclusion into the repository.

The first package that I did this for was TileCache. TileCache is a relatively simple to install utility, but it has significant benefits from being installed directly on the system — such as the ability to place the configuration file into the main configuration files locations, etc. In addition, TileCache is a relatively widely used piece of software — meaning it could have benefits for a number of users.

New packages are typically packaged by a user, then a ‘sponsor’ is searched for. A sponsor is a Debian Developer — someone with the rights to upload packages to Debian — who will take on the review of the packaging materials to ensure that the meet Debian’s guidelines.

Thanks to a thorough and patient review by Paul Wise, from the DebianGIS list, TileCache was able to be put into Debian in less than a week’s time, and is now available to users of Debian “Sid”/unstable. Barring any problems with TileCache showing up, in 10 days, TileCache will be migrated to “Lenny”/testing. Additionally, I believe that this means that TileCache may be included in the next Ubuntu release. (I’m not sure on that — I don’t know the exact way that Ubuntu pulls its packages in.) You can see information on the TileCache package on the TileCache Debian package info page.

As a result of this, I’ve also packed the python-memcache library, maintained by tummy.com, ltd, which will make it easier for TileCache users to use the Memcached cache class.

All in all, my initial experiences with Debian have been very positive, and I’m looking forward to continuing to work on building more of the software I build into Debian packages for wider distribution. Indeed, cleaning up things for Debian has resulted in a lot of other improvements to the code as well: meeting guidelines for documentation, packaging, etc. has resulted in adding documentation that didn’t otherwise exist, and cleaning up what did exist.

You can track some of what I’m now maintaining or working to get into Debian via my maintainer page, as well.

First commit in 2008:
* FeatureServer: r412
* TileCache: r242
* OpenLayers: r5614

All just updates to copyright dates, but hey, they make me fee special.

TileCache 2.0 has been released. From the announcement:

TileCache 2.0 is a major change in that way that the code works internally: rather than one large module each for layers, services, and caches, these are now split up into individual files.

The benefit that this offers is large: it allows for much easier customization of TileCache layer classes, with support for dropping your own custom modules into your TileCache config for either Layers or Caches. Additionally, it makes support for new services simpler.

One of the new layer types is an ArcXML layer, and one of the new Service types is support for MGMaps, a mobile mapping client available on many different mobile phones. One of the things that’s *not* mentioned in the relase is that TileCache now has limited support for KML SuperOverlays, allowing you to use browse your worldwide dataset in Google Earth. (A handy thing to have, if you ask me.)

Second announcement: TileCache in SVN now has support for storing tiles in Amazon Web Services S3 — simply tweak your tilecache.cfg, and enter:

[cache]
type=AWSS3
access_key=your_access_key
secret_access_key=your_secret_access_key

save the file, and you’ll be caching in S3.

(Also, in development, I have accrued a total of 4 cents of cost — but all of those are rounded up numbers, I’m nowhere near actually having to pay any ‘real’ money yet on any of their four metrics.)

Included as part of the Cache layer is a handy set of management tools for your S3 cache:

Usage: AWSS3.py [options] action    
    action is one of: 
      list_locks
      count_tiles
      show_tiles
      delete <object_key> or <list>,<of>,<keys>
      delete_tiles

Options:
  -h, --help  show this help message and exit
  -z ZOOM     zoom level for count_tiles (requires layer name)
  -l LAYER    layer name for count_tiles
  -k KEY      access key for S3
  -s SECRET   secret access key for S3

There’s probably a lot more that should be done with regard to the S3 cache layer, but for users for whom outsourcing data management is an acceptable cost, you now have the ability to use S3 more easily.

Enjoy!

OpenLayers has the ability to read and write geographic data in several different formats: KML, GML, GeoRSS (Simple and GML), GeoJSON, WKT. One of the things that hasn’t thus far been exploited as a result of this is the use of OpenLayers as a format conversion tool… until today.

OpenLayers Data Conversion is a new service that allows easy conversion from any of the formats that OpenLayers supports to any of the formats that OpenLayers supports. Simply paste your data, choose your format, and hit convert. Additionally, this tool supports reprojection to and from Spherical Mercator, the internal coordinate system used in Google Maps.

This code isn’t quite in trunk of OpenLayers yet, but in the meantime, you can grab the example from an svn sandbox, including the prebuilt lightweight OpenLayers build for format conversion.

From the mailing list:

Tomorrow Ordnance Survey (Britain’s national mapping agency) is letting a group of developers preview a new mapping API named OS OpenSpace. We aim to launch this to the public in January. We have used OpenLayers as a base for the API and have really enjoyed the opportunity to work with such a comprehensive library.

The email goes on to say that they’ve added a number of features to OpenLayers… but offers no indication that there is likely to be any likelihood of sharing the changes back with the OpenLayers community.

Of course, this doesn’t really come as surprising: a number of aspects of the effort are somewhat misguided. Very low request limits, “we own all your derivative work”, etc. However, there is one thing that is interesting, brought up on the OpenStreetMap Mailing List:

4.4 In the event that you or any User creates Derived Data, such Derived Data shall be owned by us, save that if any Derived Data is created which is a severable improvement (as defined by Commission Regulation (EC) No 772/2004, known as the Technology Transfer Block Exemption) of the Ordnance Survey Data then such Derived Data shall be owned by the person or entity creating the same.

The interesting bit is the “severable improvements” bit, which Richard Fairhurst (a member of the OSM Foundation) delves into a little deeper:

In practice, then, I read that to mean that if you use the Sustrans webmapping to find out where the routes go, this information is solely copyright Sustrans (who might be more willing to give permission) and not OS, even though it’s delivered through the medium of a derived work. So, if you had the wiggly lines already (whether mapped by GPS or NPE), you could tag them as NCN routes if Sustrans were ok with that.

Certainly brings an interesting development into the world of ‘derived works’ based on OS Mapping for the free data crowd.

Regardless, I must admit some level of frustration with users who bother to email and say “Thank you”, but not to contribute any effort into further development of the software they’re using. I suppose it’s better than ignoring the project entirely, but some of the things mentioned in the email are things I would love to have in the trunk — and there wasn’t even a consideration given to the mailing list as to whether we were working on some of these things.

I wonder if the OpenLayers community is scary in some way. We really do try to be open and welcoming. Maybe I’m just too much of an ass to people on the mailing list, but I try not to do that to people who actually want to help…