TerraGo Publisher for ArcGIS version 6.8 has been released along with its sibling products Composer and Toolbar. 6.8 represents a considerable and exciting step forward for Publisher with its introduction of what we’re calling PubPy: ArcPy-compatible Python extensions which can be used to automate Publisher workflows and create custom Publisher-powered geoprocessing toolboxes.

ArcPy is the noble extension framework implemented in the Python programming language which supplanted the venerable AML, or Arc Macro Language. In the 21st century, there’s no excuse to implement an extension language that doesn’t live within a general purpose programming language, lessons that AutoCAD and Emacs got right decades ago. Ah, PostScript, that lovely language. But I digress… ArcGIS certainly has this right today with Python, and that’s what matters. What’s particularly fun about this set of capabilities is that it has generated excitement inside TerraGo in places you don’t expect to find unabashed enthusiasm about a new feature: the quality assurance team! One QA expert was positively beaming when he reported at a daily stand-up meeting that he’d automated a wide variety of testing tasks and they were running as he spoke. The benefit to QA notwithstanding, one of the promises we’re very much looking forward to is simpler integration into ArcGIS for Server applications. One of the things that is often easy to miss is that Pub comes in two flavors: Desktop and Server. In the past, developing Pub-powered geoprocessing toolboxes for use with ArcGIS for Server apps, while possible, was more tedious and fragile than you might hope it to be, due to how ArcObjects COM interfaces work (won’t bore you with that here). Making our Publisher interfaces available through Python and accessible to ArcPy scripts remove the tedium and fragility, and if QA is to be believed, makes working with Publisher even more fun and productive. PubPy is a significant new capability, one we’re looking to continue to refine and enhance as we continue to move Publisher forward both on the Desktop as well in ArcGIS for Server environments. It’s one made possible by Esri’s excellent decision to extend ArcGIS with an industrial strength programming language in Python.

An overused, over-abused word we have today is “data”. Often people say they “just want to see the data”, but that is almost never what they mean. What they really mean, is “show me the data in a picture arranged just so that I don’t have to read anything to understand it”. That may sound cynical, and I don’t mean it cynically, but that is my experience. Every now and again you’ll get a scientist or someone with a truly scientific bent who really does want to see the data, but they’re not common, and certainly not as might be implied by all of the Church of Data blog posts and manifestos might have you believe. Now, with GIS and geo-writ-large, the connection to data is explicit and apparent, and some are prone to obsess over data, its forms and formats, interfaces for access and frobbing, to the point of distraction. For some, data is the end, it’s their product. But if it really is data, then that’s only a point, or narrow band, on a wide spectrum spanning from data to information to knowledge to wherever that knowledge might take you: insight, action, wisdom, understanding. That’s the point. While the generation of data might put bread on some analyst’s table, it only does so because that data is part of a larger whole. Yes, carefully designed and developed, high-quality, accurate data sets are valuable, but only for what you can do with them. To that end, it’s very important to make it accessible – the lower the barriers to access data enhance the possibilities for its use. If things are locked up in proprietary systems and locked away behind proprietary interfaces, it’s harder to make use of the data and necessarily limiting its utility and value.

(more…)

If TerraGo’s tag line is “Share Anywhere”, then I would have to say that “do more with what you already have” is its mantra, though that is certainly implicit. I talk a bunch about doing more with your investments in ArcGIS, but should focus on exploring doing more with your people and yourself. An employee’s value to a company is measured by more than just performance against a job description. They can provide feedback and observations that have no places on forms or tables in the company’s database which can be extremely valuable.  An aspect of a workforce to consider is its potential for distributed intelligence collection. By “intelligence”, I don’t necessarily imply anything covert or clandestine, but rather collecting information that is relevant to the efficient operation of the company. TerraGo provides tools and capabilities that facilitate the collection, recording, and sharing of observations and information, both ad hoc and structured. There are, of course, many systems for collecting data, but they tend to be closed loop, working within certain systems and paradigms for bespoke purposes.  TerraGo, historically, extended systems already in place to meet wider audiences and provision those audience with powerful location-enabled tools to let them do more with what they got from those systems. Use Publisher in ArcMap to make a GeoPDF map that can be shared , interacted with, and marked up in Toolbar in Reader, transforming what would be an otherwise static document into a data collection tool.

(more…)

Geographic Information Systems (or one of the other subtle variants of the acronym) will never disappear completely, but they should be more invisible than they are. It’s remarkable how long the apparent (and mostly false) dichotomy between that’s what’s spatial and that’s what not spatial has persisted. Having spent a good part of my career letting people integrate place into their workflows and systems, however, I can understand why it’s there, however. There are thousands of different coordinate systems with their different purposes, etc., and one person’s place exactly where they think it should be is not where another might expect it to be. Further complicating things are units like rods and chains and feet (really, feet are still used, in some places. And there is more than one foot to choose from!). A grad for good measure (pi/200 of a radian, in case you were wondering). Making that all go away for people for whom that’s a raft of irrelevant implementation details is actually pretty hard work, and I have the source code to prove it.

The reason that it’s important to hide as much of this kind of stuff when it’s not relevant is that the complexity of normal GIS workflows, worldview, and thinking prevent the adoption of location based capabilities in workflows in non-GIS contexts, which actually makes it harder for GIS and its champions to deliver value in proportion to the investments made in them or to their potential. In fact, I’d go farther to assert that it throws up barriers to adoption even in GIS contexts, because I see it all the time. It’s just a little too much of a pain to do this, that, or the other, so I’ll just jot it down on this paper form here…

(more…)