In what can only be described as a noble act of self-sacrifice, ESRI have told us that as an educational charity we are no longer allowed to have an educational discount for using their software and, not only that, our license codes will cease to work at the end of this month.
This is why Open Source software is so important. So you think you have a stable relationship with your vendor? Maybe you think that you’ve come to a great licensing agreement that you’re happy with? Remember that so long as you’re working in an environment where someone else controls the tools you use, you’re not able to make your own rules.
Why does Open Source software matter? If you’re not using it, you’re handing over control of your use of your tools — possibly important ones — to people who aren’t under your control. In the end, that lack of control may end up hurting you far more than you’d expect.
KML has become the “HTML” of the Geographic Web. With limited semantic meaning, a combination of mostly-human understandable XML tags for the majority of the usages, widespread use and abuse for purposes far beyond the original thoughts and intentions of the designers, and more, KML fits well into the geographic version of the niche filled by HTML in more generalized content publishing.
Google Earth loads *content* over the web, rather than loading code like Google Maps mashups do. The difference is important: Google Earth ‘mashups’ generate content which is, to some extent reusable within other applications. Google Maps mashups don’t: they tend to use hidden databases without public APIs, and the HTML and code that you do see is executable code, not content.
The content that is generated is reasonably easy to follow: KML is reasonably close to human readable. There doesn’t tend to be a lot of extra XML that confuses users: similar to HTML, it can be edited, for the most part, in a text editor with limited difficulty. There’s a caveat to this, however: editing geographic information — the actual coordinates behind a ‘FlyTo’ — is something that humans don’t have an innate ability to do.
To this problem, Google Earth offers a solution: In addition to being a KML viewer, it’s also a KML *generator* — draw any type of feature you like, style it how you like, then just select the item and ‘copy’ the item, and paste it into a text editor: You immediately have a working KML file, with coordinates that you created. WYSIWYG editing, built right into the data browser. Google Earth acts as the ‘view source’ button for the geoweb.
To some extent, this is extremely handy: users now have the ability to trivially create styled content in Google Earth, export it, and mix and mash these items together to create their own customized feed of data. However, this democratization is exactly the reason that KML does fit the bill of the “HTML of the GeoWeb”, with its pitfall as well as its benefits.
One of the key aspects of the difference between “paleogeographers” and neogeographers is the difference in the importance of accuracy. (I use the terms lightly here, since I don’t tend to categorize users in that way, but it provides a spectrum which is useful to understand.) In general, GIS professionals — regardless of what toolset they’re using, be it Google Earth or ESRI ArcMap — have a need for an understanding of the quality of their data. It doesn’t have to be perfect for all cases, but knowing how good it is or isn’t is an important distinction when you’re going to make decisions based on it. Google Earth doesn’t make including information like this a part of the KML workflow, nor did KML accommodate this type of usage very well until relatively recently.
Information like attributes of a feature, source data — in fact, metadata at all — and so on, is largely left out of the realm of KML. Similar to HTML, it’s largely treated as a ‘presentation’ language by the majority of the users of it. (FeatureServer uses it in a different way, and OpenLayers mimicks that usage, but that’s the exception, not the rule.) Although HTML in an ideal world separates style from substance — using CSS, semantically correct tags, etc. — I think that most web developers have seen too many uses of <table> for layout to believe that that ideal world actually exists. Similarly, KML has support for many features that users will never use. Separation of content and style is possible, but not as widely used, and mixing presentation with content (in terms of application-style control) is the best practice behavior for KML.
I’ve seen continued belief by some users that KML is a geographic data interchange format. Although exchanging geographic data via KML is possible, it’s not an interchange format for data: it’ s primarily an interchange format for presentation. Tools like GDAL and other geodata libraries do their ‘best guess’ interpretation of this data as geographic data, but are not well suited for presentation, only data interchange.
OpenLayers, on the other hand, is in a position where presentation can be taken into account. The newest version of OpenLayers has support for a fair amount of KML styling: other than differing default styles, this KML file looks pretty similar in OpenLayers and Google Maps. However, even here you can see the comparative limitations: Since OpenLayers is primarily about rendering maps, the ‘extras’ around the outside are lost, a somewhat significant loss in cases where most of the information is provided via additional display.
In the end, Google Earth is currently the only reasonably complete KML browser (that I’m aware of). Google Maps and Virtual Earth are slowly improving, and OpenLayers is moving forward as well. I look forward to seeing continued development, and am hopeful that the open source geospatial community can build UIs around data like KML that allow the feature rich presentational options that are currently available via KML in Google Earth — even if we’re only in 2d space. Solving the problems of implementing a format as far-reaching as KML is quite a task, and I’m enjoying watching as users demonstrate their interest in a particular set of features by helping to implement them, and look forward to continuing to see the trend of high quality presentations of geographic material grow, both in KML and other arenas.
I’m leaving soon for an island vacation, to Grand Cayman. I won’t be back until Feb 24th.
In the meantime, I want to know what killer apps people have in mind for OpenLayers. What should someone build with it? Why? How would it help OpenLayers, and how would it help the world at large?
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.
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 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.
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:
(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.
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.