thoughts on spatial tools and practices
A while back, I posted about about the 2014 edition of JS.GEO. After that post, things got a little fluid, but I’m happy to finally be able to provide an update. According to JS.GEO Organizer Chris Helm, the event is “locked in solid.” The event has a web site, a location, and a date. Tickets … Read more
UPDATE (12 March 2014): The situation with JS.GEO 2014 seems to be a bit fluid and the information originally posted here is no longer accurate. As indicated by Steve Citron-Pousty, the current goal is to have the event occur with FOSS4G in Portland, though that does not appear to have been finalized. In short, don’t book travel yet.
@mappingmashups @smathermather @billdollins we are looking to try and combine with Foss4G @cwhelm
— (((TheSteve0))) (@TheSteve0) March 12, 2014
We do a lot of tiles for various customers at Zekiah. Tiling is as much art as science and sometimes things go wrong so we have a range of utilities that we use to perform various kids of QA. Because the caches can be large, we usually want to perform a visual QA on the static tiles before pushing them up to wherever they are going to live full-time.
Yesterday, I attended the JS.geo conference at the Colorado University Denver campus. It looked like about 100 or so came out for the event. I was able to catch up with Chris Helm and Brian Timoney the night before and they told me the event took off faster than they had originally expected. I think this speaks to two things: 1) the level of interest in Javascript as a solution for geospatial applications and 2) the fast pace of innovation in the Javascript community that has a lot of people looking for ways to stay abreast of the latest developments.
What follows is an overview based on some of the notes I took. I wasn’t always writing as I sometimes just stopped to listen and I’ll probably follow up with more details later.
I’m looking forward to next week’s JS.geo event in Denver. It is a small event, spearheaded by Chris Helm of Esri, that focuses on the use of Javascript in geospatial applications. Although I have been more vocal in my recent explorations with Python, I’ve probably done as much, if not more, work with Javascript over the past 18 months.
I’ve had a couple of people ask me recently about the geospatial tools I use. Year-over-year, that answer changes but here’s how I answer that right now:
As a Federal contractor, I spend a lot of time working with the Esri stack during my work day. A few years ago, I added a few open-source geospatial tools into my tool set and, since then, have also done a respectable amount to consulting work them as well. The balance between the two varies over time, depending on the requirements of individual customers and projects. Lately, commercial customers have seemed much more interested in open-source tools while my government customers are sticking with Esri. Since those observations are based on the the extremely heavy filter of my own recent experience, I’d be hesitant to draw any larger conclusions from them.
I’ve always believed that proficiency with a wide range of tools makes me a better consultant and integrator, so I am always exploring and trying new things. With those commercial customers, and in my own personal side projects, my recent workflows have gelled around a core set of tools, both commercial and open-source:
So I’ve been playing with Leaflet a lot lately. It’s become my lightweight mapping library of choice. There’s a lot it doesn’t do so I keep OpenLayers and others in the rotation as well but Leaflet is direct and to the point so I use it when I can.
A while back, I stumbled onto the Leaflet.markercluster project on GitHub, which adds a clustering layer type. I wanted to try it so I revisited my old GISP heat map demo (Silverlight) and decided to rework it. I was happy to finally get a chance to strip out the plug-in, anyway.
I’ve become a big fan of Leaflet for putting maps on the web. It gives me most of what I need without much of what I don’t and is fairly easily extended, as shown by the impressive work of Jason Sanford.
A while back, Dave Bouwman blogged about work he and the team at DTS Agile had done extending Leaflet to support ArcGIS Server layers. Given that there are a lot of ArcGIS Servers out there, this is a good thing to have. Thanks to section 4(f) of the Esri Web Services Terms of Use, it’s less useful for use with ArcGIS Online, but that’s probably the topic of another post.
One of the biggest sources of buzz at FOSS4G was CartoDB. It is a hosted solution from Vizzuality that uses PostGIS to allow you to store your spatial data online. I got a beta account a couple of weeks ago but life (i.e. paying work) kept getting in the way but I finally got to play with it recently.
One of the things that intrigued me is that, similar to Google Fusion Tables, CartoDB exposes a SQL interface through a RESTful API (I’m still not sure if the term “API” applies to REST but it’s a convenient shorthand). Essentially, CartoDB exposes PostgreSQL SQL and the spatial SQL extensions of PostGIS. Once your data is loaded, you can query it and return the results as either CartoDB’s JSON syntax, KML or GeoJSON.
With this information, I set out to build a simple application to query property data and display the results on a map in a browser. In addition to CartoDB, I elected to use the Leaflet Javascript library to accomplish the mapping (although I also experimented with OpenLayers). Displaying and styling GeoJSON in Leaflet is very straightforward and this task gave me and excuse to get a little more comfortable with it.
I had the distinct pleasure of attending my first FOSS4G conference in Denver last week. Having not attended one previously, I can only rely on the opinions of others that this has been the best FOSS4G yet. For me, this was best geospatial conference I have attended. I’ll probably blog in more detail about some of the things I saw but here are my high-level observations:
