So GitHub announced that you can now automatically view any GeoJSON files that may be in a repository inside an interactive map driven by MapBox technology. This simple enhancement to GitHub is probably one of the most significant developments in the geospatial industry in years. I’ll explain a little later in this post. It’s also important to view this new capability as a great, but limited, first step. I’ll discuss that a little later as well.

While it’s cool to click on a link and just see a map, it doesn’t take long to wonder about how you can use this capability beyond viewing data in GitHub. What follows are three ways to capitalize on GeoJSON in GitHub. Not all are directly related to the new mapping capability, and two have been possible for a long time. That said, the GitHub announcement may draw interest from users who have not previously considered either GitHub or GeoJSON, so I hope these approaches will be useful.

Embed the GitHub map.

If you click on a GeoJSON file and view the new map in GitHub, a quick view of the page source will show that this map is embedded in an IFRAME object. This approach can be used to embed the GitHub map in any page. It’s a great way to quickly publish a data set while also providing access to download the raw data.

A while back, I posted about my desire to see GeoJSON supported as an output format from ArcGIS Server. I found myself needing that capability so I recently completed, and posted to GitHub, a first cut at a server object extension (SOE) for ArcGIS Server 10.1 that enables output of GeoJSON via an HTTP GET.

Using the SOE is fairly straightforward. If you download the code and build it (ensuring you have installed the ArcObjects SDK for .Net), you can simply move the project outputs to your target machine and use the ArcGIS Server manager to install the SOE. Once you log into the manager application, click “Site” at the top of the page and then “Extensions” on the left. Click “Add Extension” and browse to the .soe file. You should end up seeing something like this:

Those are my words, not theirs.

It came to light today that OGC has decided to withdraw the GeoServices REST Specification, also known as the “ESRI REST API,” as a proposed standard. I will not take up the relative merits of the specification or the implications of OGC potentially adopting an industry-developed specification that has so much implied workflow embedded in it. With this decision, three facts remain unaltered:

1. The ESRI REST API will continue forward as a widely-used de facto standard in the form of ArcGIS Server installs and other emulations, such as that in Arc2Earth.
2. GeoJSON will continue forward as a widely-used de facto standard in the form of numerous open-source implementations.
3. OGC still has no JSON syntax.

Yes, twelve years after the birth of JSON, five years after the release of the ESRI REST API and its embedded JSON syntax, and five years after the release of GeoJSON 1.0, OGC is still has no entry in the JSON space. Between Esri and GeoJSON, the utility of JSON in web mapping applications has been roundly proven. In the ESRI arena, find me anyone who willingly uses the SOAP API these days while the adoption of support for GeoJSON across the open-source GIS world speaks volumes. The industry has voted with its feet and its code as to what it prefers.

There’s probably a lively discussion to be had about where JSON should fit into OGC’s priorities. What is clear, however, is that Javascript and JSON are driving the web at large and the web-mapping space in the geospatial market. With no official stance of any kind in this area, it becomes increasingly difficult to take OGC seriously in matters of the modern web.

Howard Butler had a great point a while back when discussing the potential adoption of the GeoServices REST Specification:

The irony here is that the withdrawal of the specification accomplishes the same thing. I won’t go so far as to say OGC has no clue or doesn’t care but, in the perception-is-reality department, they look pretty out-of-touch these days. Is this a problem with process? Maybe. Is it a problem with message? Definitely. The message I’ve gotten from this whole episode is that we can keep doing what we’ve been doing with our web mapping applications because OGC has nothing for us.

Thanks to LinkedIn, I saw that Dr. Art Lembo of Salisbury (Maryland) University is leading an “Open Source/Enterprise GIS Summer Bootcamp” at the university from June 3 - 7, 2013. All of the salient details, including contact information, can be found here (PDF).

Having seen Dr. Lembo and his team in action for an afternoon at TUGIS, I think this will be a good way for those who have been wanting to take the leap with open-source GIS tools to get some hands-on experience with core tools like QGIS and PostGIS. It’s also a great time of year to be on Maryland’s Eastern Shore. The LinkedIn discussion says there are still spaces available but the date is coming up soon so you’ll want to move quickly if you’re interested.

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.

In order to facilitate that, I wrote a very simple tile viewer using Node.js and Leaflet. It uses a config file to get everything it needs to operate so we just make our changes there. This application currently only works with Web Mercator tiles but I’m working on adding support for WGS84. It also doesn’t work with ‘compact’ tiles from ArcGIS Server. It obviously requires Node, and it also requires an NPM install of the ‘open’ module to facilitate opening the browser.

Anything else you need to know is in the readme. I hope you find it useful. It can be downloaded here.

When it’s really a desktop application.

Over the past few weeks, I have been reading with conflicted agreement the posts of Brian Timoney and Bill Morris about the nature of geo-portals and what they should or should not be and do. I say that I am in conflicted agreement not because I take any issue with anything they have said. Their posts represent what should be considered best practices in terms of building web mapping applications. In Brian’s posts, the counter-examples he highlights represent some of the worst practices to be avoided.

My conflict arises from the fact that, while I agree with the ideas that Brian and Bill put forward, I find myself working against them in my current work. In my hangout with James Fee a couple of weeks ago, I mentioned that I am working again (albeit temporarily) in the world of Silverlight. I am supporting a very large, complex Silverlight application that, as one of many functions, includes a mapping module that runs counter to almost every best practice espoused by Brian and Bill. And I am adding to it.

Over on Google+, Diego Guidi let me know that the SharpMap 1.0 Release Candidate has been released. There was a time when I worked with, and wrote about, SharpMap a lot. During that entire time, the stable version of SharpMap sat at some version number that started with “0.9”. The release of a 1.0 candidate is a signal that the project is moving forward.

This is important because there are still an awful lot of .Net developers out there, especially in government shops that made a big Microsoft push in terms of infrastructure and training years ago. Of course, many of those shops are also committed to Esri technologies but SharpMap, while being a fully-functioning mapping/GIS library, also provides easy access to data sources not natively supported by Esri. Additionally, it is very easy to extend to support new or custom data sources and strightforward to get SharpMap to play nicely in traditionally Esri-centric environments.

David Bitner sent out a reminder that Early Bird reagistration for the FOSS4G North America conference closes on 1 April 2013. After that, the price goes up by $50 US. You can register online at EventBrite.

The preliminary program (PDF) for this year’s event looks exceptional, building upon and potentially exceeding the outstanding quality of FOSS4G-NA 2012. I’ll be sorry to miss the conference this year but will be looking forward to its social media exhaust.

_{^{Image by s shepherd schizoform on flickr CC-BY-2.0, via Wikimedia Commons}}

Just a quick note to tidy up some loose ends related to recent posts…

First, regarding the post ”A #LazyWeb Compendium of Python Resources for Beginners,” the University of South Florida PyBulls Python interest group, as promised, compiled a list of Python resources and posted it on their GitHub page. Thanks to them for their quick response.

Second, following up on the post ”The Best Thing I Saw at TUGIS 2013,” the data and workbooks for Dr. Arthur Lembo’s introduction to open-source GIS have been made available. The data can be found on GitHub and the workbooks can be found on the Eastern Shore Regional GIS Cooperative web site. Many thanks for contributing these resources.

These items are embedded in the comments for their respective posts but I thought it would be useful to call them out more prominently.

I spent the day yesterday at Towson University attending the TUGIS 2013 conference. The new one-day format was a firehose that showcased the diversity of geospatial work occurring across the State of Maryland. The keynote by Learon Dalby was well-received and the content of the conference was generally substantive. While the day was a sprint, there was one workshop that really caught my attention more so than I would have thought from its title.

The photo below shows 40 participants of an “Introduction to Free and Open Source GIS Software” workshop getting hands-on experience with QGIS and PostGIS by working through prepared but realistic scenarios. These scenarios included doing multi-user editing and performing spatial analysis to assess the effects of a potential toxic release over a small town.

The workshop was put together by Dr. Arthur Lembo of Salisbury University and conducted by him and a team of his students, who not only led portions of the workshop but were also stationed around the room to provide guidance to participants. The scenarios were prepared in printed workbooks that the participants were free to take with them, along with information about how to download the tools. All-in-all, I thought the workshop was very well-designed and presented a thorough overview of the capabilities of these two tools.