I got a lovely surprise when I opened my emails on Friday – ESRI has finally gotten around to implementing a beta version of the grid theme in Survey123.
I know I’ve been quiet on the blog for a while, but that’s because I’ve been keeping my rants about GIS offline (mostly). In particular, my utter frustration at not being able to replicate a very critical paper-based form digitally because of the lack of a grid theme.
I even went as far as chucking Survey123 completely, setting up ODK Collect from scratch and trying out the grid theme there. I was not happy with the results at all, so I resigned myself to a compromise: replicating the forms in Excel and extracting the data automatically from the spreadsheets as the team uploads them to OneDrive in the field. Terrible, I know, but still better than paper.
Since ESRI is making this tentatively worded claim in the beta forum:
It’s now possible to design a digital smart form that closely resembles its paper form predecessor!
I will be putting it to the test today. It’s still not the holy grail though, which would be a proper table theme, but it at least takes us a step closer.
According to my notes, I first used the Make Query Table tool in my first week at Aurecon, back in March 2012. It was the first of many, many times, because often when receiving spatial data in a non-spatial format from a non-GIS user, the first thing that gets thrown out is any trace of the original spatial component.
At some point, I realised the tool’s expression parameter was a bit wonky. As I have come up against this problem every few months since (forgetting it happens each time because I only thought to write down a note about it now), I have decided to immortalise it in a gist below.
I needed to add a field to dozens of layers. Some of the layers contained the field already, some of them contained a similar field, and some of them did not have the field. I did not want to batch Add Field, because not only would it fail on the layers which already had the field, but it is super slow and I would then still have to transfer the existing values from the old field to the new field.
I wrote the tool in the ArcMap Python window, because I found it easier to load my layers into an mxd first as they were lying all over the place. The new field to be added is set up as a NumPy array, with the relevant dtype.
The script loops over all the layers in the document, adding the field via the Extend Table tool, and then transferring the values from the old field to the new field. Deleting the old field at the end would be an appropriate step to include, but I didn’t, purely because I’ve lost data that way before.
A colleague had a map document containing 9 data frames showing various climate scenarios. He asked me for a script to pan and zoom each data frame to the extent and scale of the data driven data frame. The data driven pages were set up beforehand and must be enabled manually.
In Line 21, the data frame containing the data driven pages index layer is stored, so that it can be excluded from the list of all the data frames in the document in Line 24. When looping over the data driven pages for export, the scale and extent of each data frame are set to match those of the main data frame before writing to jpeg.
I needed to create random points inside polygons for some testing I needed to do. Since I only had a Standard Licence available (and therefore no access to the Create Random Points tool that I used to POST random points as ESRI JSON to a REST endpoint), I decided it was as good a time as any to write a tool in Python.
After creating an
InsertCursor on the point feature class, I iterate over the polygon feature class using a
SearchCursor. In Line 25, a random number is chosen between 1 and 10 to determine the number of points that will be created for that feature. The extent of the current feature is stored in Line 26.
The actual points are created in Lines 30 – 34. For each point, a random floating point number within the polygon’s extent is chosen as the
y coordinates. A point feature is created using the coordinates to build the geometry, as well as the name of the polygon feature. The point feature is then inserted into the point feature class.
I’m sick today, so I decided to choose one of the simpler scripts for today’s post. This one automates a common task of the GIS professional: converting a spreadsheet of coordinates to GIS. The script assumes you’ve formatted each sheet appropriately.
For each sheet in the workbook, the script creates a file geodatabase table, and displays the coordinates as a layer in ArcMap using the WGS 1984 spatial reference. The script is very basic, and therefore will be easy to change to suit your own data.