Tag: scripting

  • Automation or Scripting

    When I think back to my first exposure to GIS, it is through ARC/INFO. Just me and a command line. Everything was written in AML which made everything I created a script or even an app if you take the parlance that seems popular these days. I’ve beaten the drum about scripting and GIS so much on this blog that I feel like I don’t need to rehash it except to say that if you ain’t scripting you ain’t living.

    But is scripting as important as it once was? I scripted AMLs because that was the only way short of typing in commands one at a time to build anything, and you sure as heck couldn’t visualize anything without AML (well you could, but not in anyway that you’d share). Do we script as much anymore? I was looking at my automations in my life last night and there is so much that I use Zapier for that there really isn’t anything in my house that happens without a trigger. I think today we use works like “automate your workflows” rather than scripting but that is just the low-code ontology that permuted into our vocabulary.

    Regardless, the future of GIS is not scripting. That is writing Python or JavaScript and then running that file to see a result. It will be taking triggers and attaching them to actions to see results. The best part of this is that it isn’t hard coded to anything, they just wait for something to happen and then do something.

    A Rube Goldberg contraption.
    You just take an trigger and attach an action.

    GIS really is set up for this, almost everything you do is an action. The trigger is your mouse button but do you really want to be clicking your index finger all your life? But don’t be sad, this future doesn’t devalue your experience, it enables you to bring it to where it is needed. Output of GIS is more likely to be Salesforce or a BI tool than a PDF moving forward. That’s the biggest win for everyone.

  • SpatialTau v2.1 – Scripting

    SpatialTau is my weekly newsletter that goes out every Wednesday. The archive shows up in my blog a month after the newsletter is published. If you’d like to subscribe, please do so here.


    GIS and scripting go hand in hand.  With its roots in command line mainframe tools in the 70s and 80s, GIS required scripting to perform any analysis/cartography.  The hardest thing was that each GIS package required a different scripting language; AML, SML, Avenue, MapBasic, Magik, LISP, VB-Script, JavaScript, Python, Perl, TCL, etc.  In the past 5 years though, everyone from Autodesk and Esri to open source uses Python.  It’s at the point that you write Python scripts to perform GIS analysis (well unless you’re a wizard-based GIS professional or what I like to call “button pusher GIS”).

    I could spend hours writing about how Python has changed GIS analysis but I think we’ve talked about that enough.  No one needs to sell Python to GIS professionals, it is just assumed as a requirement.  I doubt I’d hire any GIS person who couldn’t write Python scripts to perform analysis.  We all use it to the point where we don’t even think about using it.  That said, I think JavaScript could be more important for the future.

    When I think GIS and Python, I think classic GIS Analysts doing their thing with large multi-monitor displays and huge loud desktops.  I hate to stereotype people but generally Python is old school GIS analysis.  The world has moved to a JavaScript focused environment and we’re starting to see some amazing things being done with JavaScript (D3).  I don’t think one can replace Python with JavaScript just yet but the tempo of innovation is clearly with JavaScript.  If you’re in an Esri centric universe, Python is still the weapon of choice, but outside of that silo, JavaScript is where people are doing amazing things.  I used to say, “Just learn Python” but I think that needs to read, “Learn JavaScript and Python”.

    That doesn’t mean there isn’t some really cool stuff going on with Esri.  Just 2 months ago, Esri said they were supporting the SciPy Library for spatial analysis.  This is a huge shift and one that I think everyone should be excited about.  SciPy is a great analysis tool that you can use anywhere, just not Esri.  You don’t need to worry about an Esri license being available for ArcPy, just use it wherever you wish.  Now short term this is probably just a niche thing as only the bleeding edge ArcGIS Pro supports it, but the plans are to back port it to the classic ArcGIS Desktop enabling you to work with your existing projects.  I can’t stress enough that people should learn how to use SciPy with Esri if only to broaden their marketability.

    So all this cool cutting edge Python/JavaScript means we’ll be standardizing on one or two scripting languages?  Possibly, but I was just looking at my text editor to see what scripts I’ve used/written in the past few months.  For me I see mostly .pl and .rb as extensions.  That’s right, I seem to write mostly Perl and Ruby scripts.  But does that mean I’m not following my own recommendation above?  Possibly, I hold on to Perl out of habit as I’ve been using it since the early 90s.  But I don’t use it for GIS analysis, I can clearly see that Python is the choice for that.  Same with Ruby, but I blame that on my stint at WeoGeo which was a Ruby/Rails shop.  But what is my point here?

    I think it is that workflows we use daily have tools that best help get them done.  I write this newsletter in Markdown and then use Gruber’s canonical Perl library to convert it to HTML.  I also use Perl to slurp data off websites that don’t allow downloads.  I use Perl to manage files on my computer and push to Amazon S3.  Here is the kicker, I could do all of this with Python but I haven’t.  I think the key is always to use the best scripting language to get the job done.  That still means Python and JavaScript with GIS.  Ruby and Perl are best left to where it makes sense and for most people I can simply say it doesn’t make any sense to use it.

    Now let me go ahead and run the Perl script to convert this newsletter into HTML and send it off.  I wish everyone a super 2015 and be ready for some amazing new spatial tools coming out in the next few months!