Saturday, September 13, 2014

FOSS4G was awesome!

Well, that was fun!

Some highlights of FOSS4G, in no specific order. There'll be some things to re-evaluate, some to prioritize and try to integrate into the next year at work, some side projects after hours, ...

FOSS4G was close by! It's only in the USA every third year, and last time (2011) it was in Denver. But this time, it was conveniently located only 2 hours away. Too far to go home every night, but close enough to stay with a friend and not need a plane ticket.

Meeting up with colleagues is one of my favorite parts. Before I get caught up in the deluge of data and techniques, I should thank again the folks I met at the conference: old colleagues like Karsten and Stephen and Matt and Bob, and new colleagues such as Tanner and Jim. It's been a pleasure meeting you; please follow my profile links and get in touch.

My presentation on the RCS Viewer was something of a dud. It seems that the 10am timeslot the morning after the party, on the last day (short day) just gets poor attendance. That's too bad: the RCS Viewer combines some of the best features for advanced GIS analysis with a simple "GIS whiteboard" as well as PDF take-aways. If you're interested, click here to see the slideshow and be sure to read the notes on each slide for some additional annotations describing the spoken part.

On the other hand, my presentation on MobileMapStarter was a real hit. I felt like a nervous, babbling idiot up there, but feedback afterward said something very different. Several folks came up afterward with compliments, good questions, intentions to use MobileMapStarter, ... and questions about licensing, because they want a clearly-stated license so they can get started using it. Huzzah! Don't worry folks, an explicit license is coming right up this weekend. If you're interested, check out the slideshow and again be sure to read the notes on each slide for the spoken material and other side notes. (oh, Chapter 1 and 2, on setting up the Cordova build environment are back up; see July 5 or so!)

MapServer 7 sounds like a small update, though in fact it seems to have involved a 25% rewrite of MapServer. Why do we use MapServer? It's lightweight and fast, configuration is dead simple (sorry, I do not consider it a painful chore to write mapfiles), you can dump temporary mapfiles to disk and use them for a session, it does variable interpolation, ... MapServer 7 brings performance improvements, then the ProTips had some useful tips, some of which I didn't already know. And lastly, MapCache is yet another tile caching system but one perhaps more flexible than TileCache and TileStache (it can handle raw WMS requests that do not fit tile boxes).

CartoDB's presentation on performance and caching was moderately enlightening. Perhaps the biggest take-home here, was the nature of their caching: it's not a tile cache holding a zillion PNGs, as much as a Varnish cache for the vector tiles that are to be rendered. Making a DB update hits a trigger that issues a varnishctl command. In conversation that day I had guessed about 2/3 of this just mentating on how I would do it... good to know that I was on the same brainwave as the smart guys. :) But it gets me thinking about whether Varnish or even CloudFront could do us some good over at GreenInfo Network, for general caching of not only map tiles but static assets such as PNGs and CSS files. (you know, network contention when downloading the 30+ assets which form a page)

RasterIO (not Raster I/O, but Rrrrrrrrasterio!) is yet another Python-NumPy-GDAL wrapper. But, it's a step beyond all the prior ones such as agoodle and even rasterstats. a) It wraps both GDAL and OGR, so you can handle both shapefiles and GeoTIFFs (et cetera). b) It uses a "more Pythonic" programming interface, e.g. using .read() and .write() c) It may consume far less memory than agoodle by virtue of being able to do a read() on a specific window of the raster, rather than loading the whole thing into memory. For one specific application where we use agoodle, this could be a game-changer.

Then some breathtaking demos of 3D data, such as Cesium. Mostly it was sit-and-spin sort of deals: load 3D data (NED), render a mesh, drape the photo (NAIP) as a texture, and there's a spinny 3D mountain demo, super cool. This is the part I find most visually intriguing, though at the same time the most baffling as to what anybody would do with it, at least as far as my customers who find a "find nearest park" application to suit their needs. I would love to find a use case for some awesome 3D stuff.

And Galileo seems like a very practical phone app that I'll probably download later this weekend. It loads OSM extracts (e.g. states in the USA) and provides a slick little pan-zoom UI. Imagine Google's "Maps" app or Apple Maps, but... without Google and Apple. If I heard correctly, it's for iOS only, which would be too bad since I'm an Android man. But I'll get on the newsletter and keep listening.

Google Closure Compiler keeps coming up. We're already in the practice of minifying our JavaScript code, but Closure goes an extra step and optimizes the code for run time performance. I've gotta give a look to this, see what differences we can achieve in file size and also runtime, compared to our existing applications.

Whew! The above are just the highest highlights that I'll be investigating at work, not even the really experimental stuff for when I get a slow day. WHAT A WHIRLWIND!

THANK YOU SO MUCH, FOSS4G!

1 comment:

  1. Hey Greg (or Gregor?) I was reviewing my notes from FOSS4G and wanted to drop you a line--sorry for the delay! Hit me up at elrobis [at] hotmail [dot] com (I never check my gmail). I added your blog to my own blogroll (http://www.cartometric.com/blog/), you've got some good stuff here.

    I've been playing around with a socket-fed web mapping idea you might find interesting--I may have mentioned at FOSS4G I was looking for presentations based on this concept, but I was disappointed because I didn't find (m)any. It's an interesting concept, because instead of the normal request/response paradigm used in a typical web mapping application, it's more of a "conversational" paradigm; imagine the client/server exchange as being "instant message"-like, where the client says "hey server here's my new viewport, what do you got?", and then the server says "oh sure, let's see ..I have this ..and this ..and this," and then it PUSHES data right into the map canvas, feature by feature. In some browsers (I think Chrome and IE) this creates a cool "progress" effect, where the features seem to "spill" into map. In Firefox, oddly, they still draw all at once, or in big chunks---which was exactly the type of UX problem I was trying to solve, so I'm not sure why FF behaves differently.

    If you're curious and want to see it in action, check out a demo video of it running on my work PC. We're a county government so just about everything we do has to work in IE, hence the demo being in IE. :)

    http://www.elrobis.com/projects/mappysocket/demo.avi

    Anyway it was nice meeting you, and if you're interested in this project concept, hit me up. I could use a collaborator.

    ReplyDelete