Klokan's starred items in Google Reader

OpenLayers: failure of map redraw on panning

2012-01-17T14:58:25Z

Just a quick heads up for those of you using OpenLayers. There seem to have been a lot of problems lately with OpenLayers refusing to redraw its layers when panning, where everything was working before. One possible solution turned up in this thread on OpenLayers Users. The credit for solving the problem is therefore not [...]

Students demonstrate innovative iPad book page flip

2012-01-24T13:00:00Z

One major complaint about reading an eBook is the experience; holding an iPad is just not the same as holding a book and thumbing through the pages. This complaint may lose some of its weight if the folks at the KAIST Institute of Information Technology Convergence can get their patented Smart E-Book Interface Prototype out of the lab and into the wild.

The interface uses the private Apple API for the page flip and turns it upside down and inside out. Not only do you get a beautiful page flip like the one in iBooks, you also get page flipping that lets you scan 20 or 30 pages at a time, multiple page flips that are controlled by the speed of your finger swipe, and a way to hold your thumb on one page and flip through the book with your fingers. You can see it in action in the video below to marvel at how the interface mimics the way most people flip the pages of a softcover book.

[Via Macgasm]

Students demonstrate innovative iPad book page flip originally appeared on TUAW - The Unofficial Apple Weblog on Tue, 24 Jan 2012 08:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Linked Ancient World Data Institute

2012-01-12T19:16:31Z

From the ISAW blog:

ISAW will host the Linked Ancient World Data Institute (LAWDI) from May 31st to June 2nd, 2012 in New York City. Applications are due 17 February 2012.

LAWDI, funded by the Office of Digital Humanities of the National Endowment for Humanities, will bring together an international faculty of practitioners working in the field of Linked Data with twenty attendees who are implementing or planning the creation of digital resources.

More information, including a list of faculty, and application instructions are available at the LAWDI page on the Digital Classicist wiki.

I'm excited to get to play a small part in this. I was on the faculty of the UVA Scholars' Lab's Institute for Enabling Geospatial Scholarship in 2009 and got to see first hand how an excellent institute is run. We'll try to live up to the high standards of #geoinst.

Dropbox-for-Google Insync leaves beta, goes free and opens doors for business

2011-12-30T15:00:00Z

Advertising itself as a cheaper Dropbox alternative with a better feature set, Insync has been in closed beta for the last 15 months. Now, they're finally ready to launch with a service that tightly integrates into Google Docs. It's "8x cheaper" than Dropbox, according to their marketing; in fact, the core service is now free, and customers who paid for the service during the beta period will be offered a refund or premium service credit. The only cost for basic membership is the cost of Google storage.

Insync brings a number of novel features to the table, differentiating it from Dropbox's current service. For example, you can share individual files with more granularity -- not just as public links, but specifying read-write or read-only permissions. You can also revoke a sharing link, which isn't possible on Dropbox unless you move or delete the shared file.

All your files live inside your Google Docs account, but that doesn't mean you're limited to the supported Google file types; any file can be synced over, as long as it's less than 10GB in size (assuming you have that much room in your storage allocation).

You can nest sharing privileges so people have access to just part of a folder structure. You can also set re-sharing permissions, specifying whether those you share with can re-share that material or not. Share recipients are not charged against their storage quota.

Insync supports multiple Google accounts and uses Google's storage system. Google starts with 1GB free storage, and then moves to 20GB for $5/year up to 16 TB for $4096/year. Dropbox's pricing rates includes 2GB free storage, and then jump to 50 GB paid storage at $10/month. Dropbox's 50 GB will cost you $120/year compared to Google's $20/year for 80 GB. That's $0.25 per GB per year for Google Docs versus $2 per GB per year for Dropbox.

To use Insync, you sign in with your Google credentials and permit it to gain access to Google Docs. You then download and install the client software on your computer. From there, you launch, link the Google account to your machine, and you're ready to go. On OS X, all your Google Docs appear in a Finder window.

In its current incarnation, Insync feels a lot like Dropbox, including its menu bar widget and small status indicators next to files (both Egnyte and Box.com use similar UI conventions for their respective cloud sync tools). If you're used to Dropbox, then you already know how to use Insync.

Dropbox-for-Google Insync leaves beta, goes free and opens doors for business originally appeared on TUAW - The Unofficial Apple Weblog on Fri, 30 Dec 2011 10:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Google Translate for iOS adds iPad support

2012-01-06T03:00:00Z

The Google Translate app (free) has become a universal app, adding support for the iPad. Unfortunately, it appears that the only real change to the app was to scale up the user interface elements to fit the larger screen of the iPad, but based on prior experiences with the app on the iPhone it should be a very useful piece of software.

The app does quite an amazing job of translating text between 63 different languages, literally everything from Afrikaans to Yiddish. For 17 of those languages, you don't even have to type in the text -- you can speak it, and Google Translate makes quick work of converting your speech to text and then translating it. For 24 of the languages, the translations can be spoken aloud.

Favorite translations and your history can be set up for quick access when the iPad is offline, perfect for setting up a list of translated phrases for use while traveling in a foreign country. It's also possible to display translations on a full screen so other can easily read what you're saying or asking.

The universal update became available today.

Google Translate for iOS adds iPad support originally appeared on TUAW - The Unofficial Apple Weblog on Thu, 05 Jan 2012 22:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Daily Mac App and Friday Favorite: CodeRunner

2012-01-06T19:00:00Z

CodeRunner is a text editor for people who write code. It comes with built-in syntax highlighting for AppleScript, C, C++, Java, JavaScript (Node.js), Objective,C, Perl, PHP, Python, Ruby, or shell scripting.

I have been using it for a few months, mostly for writing shell scripts, and love it. The color coding makes it easy to immediately tell when I am missing a quote or some other basic syntax flaw, which means making fewer mistakes. It automatically applies templates (which are editable) to new files, so whenever I start a new shell script, it automatically includes the header lines and some other settings that I always use. In fact, it defaults to using the same template as the last kind of file you saved, so if you tend to write in one language, it will automatically pick that language and template. Otherwise you can choose manually.

One of my favorite aspects of it is a built-in terminal console, which lets you test the script without switching over to Terminal or iTerm. A recent update even made it possible to define arguments, compilations flags, or arguments before sending it to the built-in console. The console automatically appears when needed, and can be shown/hidden with a keyboard command.

CodeRunner offers "completions" (for example: automatically adding a closing bracket when you open one), but it also lets you turn that off if you don't like it. There are even themes to change the color combinations. I tend to prefer a simple black-on-white, but there are several dark background/light type options as well. In Lion, CodeRunner supports Autosaving, Versions and Fullscreen mode. It also supports "tabs" (multiple documents in one window) if you want to use them, but doesn't require them. Generally I don't like tabs in any apps except web browsers, but it is handy to have the option to keep related files together when working on separate projects.

CodeRunner isn't going to replace a complex program like BBEdit with integrated FTP and a multitude of configurable options, but it doesn't need to. I own, use, and love BBEdit, but I use CodeRunner exclusively for writing shell scripts now, and vastly prefer it for that purpose.

If you want a lightweight tool for writing scripts, you should definitely check it out on its home page or download it from the Mac App Store for $10. (Also: if you use regular expressions -- especially if you have trouble with them -- be sure to also checkout Patterns, an app by the same developer which makes it much easier to see how they expand. I'll probably review that more fully another day but it's currently on sale for $3 instead of $5, so you might want to check it out soon.)

Daily Mac App and Friday Favorite: CodeRunner originally appeared on TUAW - The Unofficial Apple Weblog on Fri, 06 Jan 2012 14:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

Google Body becomes Zygote Body; built on open source 3D viewer

2012-01-09T19:00:00Z

Google Body was built by Google engineers in their “20% time” and was retired along with Google Labs last year. Today we’re pleased to announce that the software underlying Google Body is now open source.

Zygote Media Group, which provided the imagery for Google Body, has used this open source code to build Zygote Body (zygotebody.com). Zygote Body offers the same navigation, layering, and instant search as Google Body. Like Google Body, Zygote Body can be used in browsers that support WebGL, like Chrome and Firefox, without needing to install additional software.

To support the release of Zygote Body, the Google Body team built a new open source 3D viewer, now available at open-3d-viewer.googlecode.com. This viewer provides a standard way to create and view 3D models in a Web browser, with multiple layers and instant search. A sample model (by 3D artist Leo White) is included; Google Body users may recognize it as the Google Cow, first seen on April Fool's Day 2011.

By Roni Zeiger, Google Body 20% team

Understanding the South African Coordinate Reference System

2011-12-13T20:36:17Z

A nice article by Aslam Parker, Chief Directorate: National Geo-spatial Information, South Africa was published this month in our local GIS/Surveying magazine ‘Position IT‘ that describes the South African CRS. It probably would be of general interest to those trying to understand CRS concepts too. Direct link to the PDF here.

Seamless access to remote Global Multi-resolution Terrain Elevation Data 2010 with GDAL

2011-12-05T19:44:00Z

The USGS has recently released GMTED2010, a new dataset of elevation data, available in resolutions of 30, 15 and 7.5 arc-seconds. A look at the download page shows that the dataset is delivered as tiles whose dimensions are 30° of longitude x 20° of latitude.

There are also global grids available, but due to the fact they are contained in a .zip file, seeking to arbitrary offsets will undoubtedly be very slow. The content of the be75_grd.zip file can be obtained with the new gdal_ls.py sample script and a combination of /vsizip/ and /vsicurl/ virtual filesystem prefixes :

$ python swig/python/samples/gdal_ls.py -R /vsizip/vsicurl/http://igskmncngs506.cr.usgs.gov/gmted/Grid_ZipFiles/be75_grd.zip

Which shows that the .zip contains an Arc/Info Binary Grid :

$ gdalinfo /vsizip/vsicurl/http://igskmncngs506.cr.usgs.gov/gmted/Grid_ZipFiles/be75_grd.zip/be75_grd/hdr.adf -nofl -norat
Driver: AIG/Arc/Info Binary Grid
Files: /vsizip/vsicurl/http://igskmncngs506.cr.usgs.gov/gmted/Grid_ZipFiles/be75_grd.zip/be75_grd
Size is 172800, 67200
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]]
Origin = (-180.000138888888898,83.999861111111116)
Pixel Size = (0.002083333333333,-0.002083333333333)
Corner Coordinates:
Upper Left (-180.0001389, 83.9998611) (180d 0' 0.50"W, 83d59'59.50"N)
Lower Left (-180.0001389, -56.0001389) (180d 0' 0.50"W, 56d 0' 0.50"S)
Upper Right ( 179.9998611, 83.9998611) (179d59'59.50"E, 83d59'59.50"N)
Lower Right ( 179.9998611, -56.0001389) (179d59'59.50"E, 56d 0' 0.50"S)
Center ( -0.0001389, 13.9998611) ( 0d 0' 0.50"W, 13d59'59.50"N)
Band 1 Block=256x4 Type=Int16, ColorInterp=Undefined
Description = Band_1
Min=-606.000 Max=8746.000
NoData Value=-32768
Metadata:
LAYER_TYPE=athematic

With the build_gmted.py Python script leveraging on GDAL Python and utilities, we create a GDAL virtual dataset that merges all the tiles into global datasets, so that we can access them seamlessly. Of course, we also take advantage of the multi-resolution nature of the dataset to use the tiles of resolutions 30 and 15 arc-seconds as overviews that can speed-up sub-sampling processing. The script currently uses the breakline emphasis layer of the GMTED dataset, but can easily be customized to use other layers (minimum, maximum, mean, medium).

For best performance, the script and the following operations must be used with the latest GDAL development version (1.9.0dev, >= r23468) to benefit from new optimizations.

$ python build_gmted.py

After a few minutes, the script has created a gmted subdirectory that contains several VRT files : one for each tile at each resolution, and 3 global ones : gmted/all075.vrt, gmted/all150.vrt and gmted/all300.vrt.

Let's have a look at the content of gmted/all075.vrt with the gdalinfo utility :

$ gdalinfo gmted/all075.vrt -nofl
Driver: VRT/Virtual Raster
Files: gmted/all075.vrt
Size is 172800, 86400
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.000138888888898,89.999861111111116)
Pixel Size = (0.002083333333333,-0.002083333333333)
Corner Coordinates:
Upper Left (-180.0001389, 89.9998611) (180d 0' 0.50"W, 89d59'59.50"N)
Lower Left (-180.0001389, -90.0001389) (180d 0' 0.50"W, 90d 0' 0.50"S)
Upper Right ( 179.9998611, 89.9998611) (179d59'59.50"E, 89d59'59.50"N)
Lower Right ( 179.9998611, -90.0001389) (179d59'59.50"E, 90d 0' 0.50"S)
Center      ( -0.0001389, -0.0001389) ( 0d 0' 0.50"W, 0d 0' 0.50"S)
Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
Min=-606.000 Max=8746.000
NoData Value=-32768
Overviews: 86400x43200, 43200x21600

The global dataset covers 172 200 x 86 400 elevation points, i.e. 29.8 GB of data. all075.vrt also references all150.vrt and all300.vrt as overviews. And we can verify that it is consistent with the global grid provided by USGS (except that our VRT extends more towards the poles).

With gdallocationinfo, we can query the elevation at one point :

$ gdallocationinfo gmted/all075.vrt -geoloc 2 49
Report:
Location: (87360P,19679L)
Band 1:
    <LocationInfo><File>gmted/30N000E_20101117_gmted_bln075.vrt</File></LocationInfo>
    Value: 183

Let's build a small overview of 2048x1024 pixels of the global dataset. (Note: this may need several dozen minutes to complete)

$ gdal_translate gmted/all075.vrt gmted/global_2048x1024.tif -outsize 2048 1024 --config CPL_VSIL_CURL_ALLOWED_EXTENSIONS ".tif" --config GTIFF_DIRECT_IO YES --debug on

Screen-shot of the overview of 2048x1024 pixels

(The white strip between Patagonia and Antarctica is filled with no-data values)

2 options (new in GDAL 1.9.0dev) have been used to speed up access :

The CPL_VSIL_CURL_ALLOWED_EXTENSIONS option is set to ".tif" so that only TIF files are queried from the server, and no other auxiliary files (.aux.xml, .ovr, .msk, etc..)
The GTIFF_DIRECT_IO option is set to YES so that the minimum number of bytes are fetched from the remote files. Partial TIFF strips can be read. It also takes advantage of the ability of the HTTP server to return multi-range of data at once, minimizing client-server round-trips. On the downside, it makes no use of the GDAL block cache mechanism, hence it is not an appropriate default choice for general purpose I/O. It is also restricted to simple configurations of TIFF files : single-band, untiled, uncompressed.

We can now edit gmted/all075.vrt with our favorite editor to take advantage of the local overview that we have just generated. We just have to insert the following snippet before the </VRTRasterBand> element at the end of the file :

    <Overview>
      <SourceFilename relativeToVRT="1">global_2048x1024.tif</SourceFilename>
      <SourceBand>1</SourceBand>
    </Overview>

Let's open the global dataset with QGIS (linked against our development version of GDAL) with close to acceptable performances :

$ GTIFF_DIRECT_IO=YES CPL_VSIL_CURL_ALLOWED_EXTENSIONS=".tif" CPL_DEBUG=ON qgis gmted/all075.vrt

Depending on the zoom level, either the local 2048x1024 dataset, or the remote 300, 15 and 7.5 arc-seconds datasets will be used.

For example, let's zoom in on Reunion island. We can easily distinguish its 3 magnificent cirques (the 3 dark areas near the center/west) and the Piton de la Fournaise volcano (white circle at the east) :

Screen-shot of Reunion Island in QGIS

We can extract a low-resolution window covering mainland France :

$ GTIFF_DIRECT_IO=YES CPL_VSIL_CURL_ALLOWED_EXTENSIONS=".tif" gdal_translate gmted/all075.vrt france.tif -projwin -5 52 10 41 --debug on -outsize 10% 10%

Mainland France

On my PC, this command completes in about 20 seconds with GDAL 1.9.0dev, versus more than 3 minutes with GDAL 1.8.

If you don't want to do all the above steps, you can just use the following pre-generated set of .vrt files :

$ ln -s /vsicurl/http://even.rouault.free.fr/gmted/all075.vrt remote_all075.vrt
$ CPL_DEBUG=ON GTIFF_DIRECT_IO=YES CPL_VSIL_CURL_ALLOWED_EXTENSIONS=".tif,.vrt" qgis remote_all075.vrt

Did you realize that you are now using a remote virtual dataset made of virtual datasets pointing to remote GeoTIFF tiles ;-) ?

New data set: Global Multi-resolution Terrain Elevation Data 2010

2011-12-01T14:12:00Z

USGS has published a new nice data set called the "Global Multi-resolution Terrain Elevation Data 2010" (GMTED2010). It is offered at three different resolutions (approximately 1,000, 500, and 250 meters).

Example (MEA = mean dataset) Trento - Garda Lake - Verona area (Northern Italy):

The 250m product looks quite smooth -a nice new DEM product...

Data download: http://eros.usgs.gov/#/Find_Data/Products_and_Data_Available/GMTED2010

GRASS GIS processing steps: see here

Introducing Closure Stylesheets

2011-11-12T22:58:00Z

(CSS is for programming, not for pasting)

When the Closure Tools were first released a little over two years ago, they gave web developers the ability to organize and optimize their JavaScript and HTML in a new way. But there was something missing, namely, a tool to help manage CSS.

You see, the nature of CSS runs contrary to the DRY principle that is exhibited in good software engineering. For example, if there is a color that should be used for multiple classes in a stylesheet, a developer has no choice but to copy-and-paste it everywhere because CSS has no concept of variables. Similarly, if there is a value in a stylesheet that is derived from other values, there is no way to express that because CSS also lacks functions. Common patterns of style blocks are duplicated over and over because CSS has no macros. All of these properties of CSS conspire to make stylesheets extremely difficult to maintain.

To this end, we are excited to introduce the missing piece in the Closure Tools suite: Closure Stylesheets. Closure Stylesheets is an an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming. As the existing Closure Tools have done for JavaScript and HTML, Closure Stylesheets will help you write CSS in a maintainable way, while also empowering you to deliver optimized code to your users. We hope you enjoy it! Please let us know what you think in the discussion forum.

By Michael Bolin, Open Source Engineer

Cross posted from the Google Open Source Blog.

ESSHC History and Computing Network Adds Historical Computing and GIS

2009-04-18T00:51:11Z

News Flash from the ESSHC: “The European Social Science History Conference (ESSHC) has added Historical GIS to its History and Computing network to create a new network provisionally called ‘Historical Computing and GIS.’ It is hoped that…this new network will become a focus for Historical GIS research in Europe. This new network will be launched at the next ESSHC conference which will take place in Ghent, Belgium 13-16th April 2010.”

For conference particulars, see here.

– Kelly Searsmith

Thoughts on vector based mapping

2011-10-19T16:51:00Z

Traditional...wait, I have to put that in quotes..."Traditional" web mapping, as you see in pretty much any web mapping application, relies of raster tiles to convey the base map. The reason for this approach is pretty simple: You can convey a ton of information in a raster image simply by changing the colors of pixels. And it's highly performant. As many pixels in your image is as many points of information you can portray.

But there's been a lot of buzz for awhile about the possibility of vector based mapping. Vector mapping is essentially pushing the underlying data used to build a map to the client, instead of the fully assembled map. By pushing vectors to a client (browser or mobile application) you can push the assembly of the map into the client machine, saving quite a bit of work on the server side. But it also gives you a lot of capabilities that are absent from raster maps. For instance:

Reprojection and restyling on the fly: If you are assembling a map based on vectors, you're just providing the base map data and allowing the local app handle constructing the map. That allows you to do interesting things like reproject and restyle a map in the client and on the fly.
Graduated map drawing: You can draw the map while the user watches, instead of loading it tile by tile.
Perspective changes: You can tilt maps, create 2.5D or 3D maps, do all sorts of things based with the data.
Fluid transitions: Instead of jumping between zoom levels, you can have smoother transitions as you navigate a map.

This comes at a cost to the client of course, you have to have a device of sufficient power to assemble the map. Fortunately, a variety of new technologies in the browser are making that happen. Here's the basic approaches developers are taking:

Google Maps for Android: Google Maps for Android uses vectors to draw the maps. It uses a custom vector format and pushes it down to the application where it runs on the mobile device. If you have an Android phone, chances are you have vector mapping already on that device:

Scalable Vector Graphics (SVG): SVG has been around for awhile, and has even been used by Google for rendering overlays on Google Maps API maps. But it was always held back by the performance in the browser and lack of support by IE. IE9 finally gives support for SVG, and most modern browsers are now performant enough to use it. Polymaps, a JavaScript library, was the first major implementation of vector mapping for the web that I saw. It allows developers to draw maps using SVG and style them using CSS styling. I think SVG is still a little slow, but it is now widely supported and the CSS styling is a great way for developers to style maps.

Canvas: There's been a lot of hall-way talk at conferences like WhereCamps and FOSS4G about using HTML5 Canvas to render vectors, pushed down in a standard format. I haven't seen any great implementations, but Canvas is also widely supported in the browser and generally has good performance.

WebGL: WebGL gives the browser access to a machine's graphics card to do rendering, giving it some tremendous power. Browsers traditionally only had that kind of access through plugins like Flash. Google launched an experiment last week called MapsGL. It's pretty awesome. We've got buildings, smooth transitions, and nice animations of 45 degree imagery. The downside of WebGL is that it isn't widely supported yet in the browser. Currently only Chrome 14 and later versions of Firefox have good enough support for MapsGL. And currently Microsoft has no plans to support it. My hope is that WebGL will take off because of the power that graphics processor gives maps developers.

This isn't meant to be an exhaustive list, feel free to add other approaches you've seen or implemented. I'm really excited by vector mapping and want to see it succeed. I really feel like it's "The Future"

67M1TTLmJDnCN0B1lNNmxH

2011-10-07T18:01:00Z

New map 67M1TTLmJDnCN0B1lNNmxH added by klokan.

Come Develop with the Omeka Team!

2011-10-12T16:49:08Z

The Roy Rosenzweig Center for History and New Media is looking for a new contract developer to join our innovative, energetic, and hilarious team of developers. With guidance from our Lead Developer and Omeka Dev Team Manager, and in collaboration with other developers and members of CHNM, the new team member will work primarily on various aspects of our Omeka content management system. Duties may include helping to resolve issues, building new sites with Omeka, developing plugins and themes, and helping to design and implement future versions of the core Omeka codebase, as well as contributing to other ad-hoc projects within the CHNM ecosystem.

You can see the code at https://github.com/omeka/Omeka. Some other CHNM projects are at https://github.com/chnm.

Required

Proficiency in PHP and Javascript
Strong Object-Oriented programming skills
Familiarity with the MVC design pattern
Familiarity with Zend Framework
Excellent communication skills with others at all levels of programming skill, from “Hello World!” novice to seasoned guru
Ability to balance competing needs and priorities in designing code
Creativity in problem-solving, and openness to experimenting with unfamiliar approaches

Preferred

Experience working on open source software projects
Familiarity with HTML5, CSS3, and graphic design principles
Experience with Amazon Web Services and other cloud services
Experience with PHPUnit testing framework
Background or experience in the Humanities

CHNM is the leading producer of open source tools for humanists and of award-winning history content on the Web (for example: Zotero, Omeka, teachinghistory.org and the Bracero History Archive). Each year CHNM’s many project Web sites receive over 16 million visitors, and over a million people rely on its digital tools to teach, learn and conduct research.

Our preference is for a freelance developer who can join us onsite at George Mason University, which is located 15 miles from Washington DC, and is accessible by public transportation.

Please send a resume and cover letter to jobs@chnm.gmu.edu. We will begin reviewing materials immediately and will close the position on November 15.

Lars Rasmussen on the startup of Google Maps

2011-09-29T20:48:00Z

Here's some interesting background to where Google Maps came from. Must feel pretty good to have created a revolution (slippy maps) - and maybe to have just missed creating another one (Google Wave as an alternative to email).

22 Essential Tools for Testing Your Website’s Usability

2011-09-30T20:43:00Z

Here is an excellent article which covers the current best practices on website usability, along with the latest tools which support usability testing: 22 Essential Tools for Testing Your Website’s Usability. It covers the following topics:
1. User Task Analysis

Learnability:
Intuitiveness:
Efficiency:
Preciseness:
Fault Tolerance:
Memorability:
Affordance:

2. Readability

Ease of Comprehension:
Legibility:

3. Site Navigability

Information Architecture (IA):
Findability:
Efficiency of Navigation:

4. Accessibility

Cross-Browser/Cross-Platform Compatibility:
Color Choice:
Use of HTML Accessibility Features:

5. Website Speed

Webpage Response Time:
Webpage Size:
Code Quality:

6. User Experience

Fulfillment:
Usefulness:
Enjoyment:
Positive Emotions:

Image Source: http://9.mshcdn.com/wp-content/gallery/user-task-analysis-tools/intuitionhq.jpeg

Introducing Google JS Test

2011-09-29T17:45:00Z

Google JS Test is a JavaScript unit testing framework that runs on the V8 JavaScript Engine, the same open source project that is responsible for Google Chrome’s super-fast JS execution speed. Google JS Test is used internally by several Google projects, and we’re pleased to announce that it has been released as an open source project.

Features of Google JS Test include:

Extremely fast startup and execution time, without needing to run a browser.

Clean, readable output in the case of both passing and failing tests.

An optional browser-based test runner that can simply be refreshed whenever JS is changed.

Style and semantics that resemble Google Test for C++.

A built-in mocking framework that requires minimal boilerplate code (e.g. no $tearDown or $verifyAll calls), with style and semantics based on the Google C++ Mocking Framework.

A system of matchers allowing for expressive tests and easy to read failure output, with many built-in matchers and the ability for the user to add their own.

See the Google JS Test project home page for a quick introduction, and the getting started page for a tutorial that will teach you the basics in just a few minutes.

By Aaron Jacobs, Google Engineer

Selecting GDAL Drivers on the fly with QGIS

2011-09-13T10:09:57Z

There is quite an old ticket in the QGIS bug tracker relating to the need to be able to select which GDAL drivers to use. The issues is this: GDAL in some cases provides multiple drivers for the same image type. For example, JPEG2000 datasets can be opened using ECW's proprietary driver, KAKADU (gotta love that name!), OpenJPEG etc. The problem is that there isn't actually any way to choose which driver GDAL should use for a given image format - it works on a first come, first served bases. This is a bit of a problem sometimes when you actually want to be using a different driver. In some work I did recently for SANSA (the South African Space Agency), I built a custom version of QGIS for them. They are particularly keen on the JPEG2000 format since it is an open standard and provides good compression. However the custom build of QGIS I made for them includes the ECW JP2000 driver which unfortunately chokes and dies (no fault of GDAL, it happens down in the ECW code itself) when trying to open their JP2 imagery. Also we would prefer to use a FOSS driver for JP2 in keeping with the general ethos of being a FOSS project. So all this prompted me to implement the needed support to let you disable GDAL drivers at runtime in QGIS which is illustrated a little by the screenshots below.

By default GDAL want to use the ECW JPG2000 driver...(click to enlarge)

Using the options dialog, you can now disable a driver....(click to enlarge)

After the driver is disabled (and restarting QGIS), the alternate JP2 driver is available (click to enlarge)

Building GDAL under windows with all the bells & whistles

2011-09-18T19:18:23Z

Lately I have been delving deeper into the (aweful) world of Microsoft Windows - specifically looking to be able to better support Windows users trying to get to grips with running FOSSGIS on that platform. I have mentioned before on this blog how dependent I am on GDAL for my daily work. GDAL is also one of the pillars of any FOSSGIS stack (especially if you 'belong to the c-tribe'), so being able to build it yourself on a given platform os always useful. In my case I wanted to include openjpeg V2.0 support in my Windows builds of QGIS (and hence in my windows build of GDAL).

There are several options for building GDAL under windwos yourself (ranked from insane to mindless):

Build all the dependencies yourself from scratch and then download GDAL from SVN and build against those dependencies.
Download and install OSGEO4W including the developer packages it provides, and then build GDAL against that.
Download an SDK created by a very fine fellow by the name of Tamas Szekeres (thanks to the folks on #gdal IRC channel for putting me on to this).

Tamas' SDK is available in various forms - for different MSVC versions and different versions of GDAL. Also he provides two options:

GDAL and its dependencies provided as pre-built runtimes without.libs and headers (around 20mb) - this is most useful if you want up to date versions of the GDAL command line tools and don't need to compile and link against the GDAL library.
A complete build it yourself environment with GDAL and Mapserver source code and all the dependencies needed to build them (around 60mb).

The runtime packages are available as nightly builds so you can use bleeding edge versions of GDAL like that if you want to. The SDK is provided as a simple .zip file which you can unpack and then run the following command (you need to have MSVC installed) in order to build GDL:

nmake gdal

Simply wait a few minutes and you will have a fresh build of the stable GDAL created in the directory called release-1500 (if you are using MSVC2008). If you want to build GDAL Trunk, I could't find a download on Tamas' site that directly supports that so I switched the gdal checkout inside his SDK to use trunk:

cd gdal
svn switch https://svn.osgeo.org/gdal/trunk/gdal

If may take a few minutes or longer to do the switch if you are on a slow connection like I have. After that step is done, go back up a level in the directory tree and rebuld GDAL:

cd ..
nmake gdal

Once again, go have a cup of fine South African Rooibos Tea while you wait because it may take a few minutes....

When it is finished compiling you will have a shiney new gdal19dev.dll binary build under release-1500-bin and a gdal_i.lib under release-1500/lib. Next you can build QGIS against this binary. To do so, simply follow the standard QGIS INSTALL process for windows, but during the cmake-gui step substitute the following variables (I build GDAL using Tamas' SDK in c:\dev\cpp\gdal-sdk\):

Replace:

GDAL_INCLUDE_DIR   : C:/OSGeo4W/include/
 GDAL_LIBRARY      : C:/OSGeo4W/lib/gdal_i.lib

With

GDAL_INCLUDE_DIR   :  C:/dev/cpp/gdal-sdk/release-1500/include
GDAL_LIBRARY       :  C:/dev/cpp/gdal-sdk/release-1500/lib/gdal_i.lib

Then generate and configure and build QGIS as per the documentation. One last thing you need to remember : all the SDK binaries need to be copied into your QGIS runtime directory otherwise it will complain about missing GDAL.

Tamas' work to create a GDAL SDK for Windows takes away a lot of the pain of developing 'C-tribe' applications under Microsoft Windows and is well worth using if you are stuck in MS land. Thanks Tamas for your efforts!