Making Sense of Projections in Precision Agriculture
Shapfefiles? Coordinate Systems? Knowing your projections in Precision Agriculture is all about taking the time to understand the data behind the data!
May 2, 2016
Ok tell me if this has ever happened to you: You plug some acquired imagery or map data into your GIS, farm management software, or implement console only to see your relative location to the data being displayed off somewhere in Timbuktu. Sound familiar? then it’s likely you’ve fallen victim to a spatial coordinate system or “projection” mismatch. Whether they realize it or not, many ag professionals are also GIS professionals; which makes knowlege of projections in precision agriculture all the more important!
To be precise, the term “projection” is commonly used to describe a type of coordinate system. However it happens so often that a projection is applied to a coordinate system that there are a lot folks who refer to the entire locational what’s-what as “the projection” (even when it’s not projected). We have to use projections because our modern cartographic methods are steeped in tradition – and paper. Just like you can’t fit a square peg in a round hole, you can’t trace a location on the globe using a flat piece of paper or “plane”. To make it work, cartographers have [for centuries] been looking for ways to depict this inherent distortion on paper maps. Curt has this [rather large] infographic hanging above his desk, and I stop to stare at it often (hey don’t judge!). It illustrates the point I’m trying to make more eloquently than I could hope to hash out in another 30 minutes of rambling. Totally worth the download (oh, and here’s the html friendly version for the impatient).
This is why your stuff doesn’t always line up.
The way we use imagery and map layers today very much takes the time-honored representational methods into account because, well, we have to if we want to utilize all that historic survey and mapping data. For example, while it is true that a GPS receiver has the ability to give us true position on the globe, the land that you’re operating on at present was likely provisioned part and parcel by a survey. Just a guess here, but the original survey tied to the deed probably wasn’t done while a satellite constellation floated above ;). Those folks may have used a very specific representation of the earth on paper, or “projection” if you will, in concert with a chosen unit of linear measure to map it all out; however traditional methods have the need for survey markers, and the further one deviates from the survey marker, the more potential for error is introduced. The disparity between projection (or lack thereof) and accuracy in measurement methods is key to why why data foreign to your workflow often doesn’t line up maybe as nice as it could (and why straight lines are just so damn hard to delineate across the planet). Can data with the wrong coordinate system for your workflow be corrected? Heck yeah – This is why we have math! Modern GIS software tends to come with extensive libraries of coordinate systems; and it’s such that we are fortunate to be able to leave the transformations of spatial data to software pretty much exclusively.
Know Your Data; Know Your Metadata.
I’m In many cases, a reprojection or transformation of the data isn’t even necessary, as the data may just be poorly identified or come with no coordinate system identification whatsoever. Shapefiles are notorious for this, as the named coordinate system, housed in a “prj” file is NOT a required piece of the dataset. In these cases, the data was built to be used in a particular coordinate system; we just have no certain way of knowing what that is. You can certainly go and name the coordinate system for a shapefile, but one has to first know what that is. In my experience, it’s always been a given that you’re going to spend the better part of an afternoon playing “guess that projection” if a data set doesn’t come with some instructions. In the realm of geographic data or “geodata”, there exists a thing called “metadata”. Simply put, it’s data about the data. GIS jockeys get real excited when geodata comes with metadata, because it makes their work a whole lot easier. Metadata isn’t exclusive to geodata. Listen to mp3? It’s likely your music file has an id3 tag embedded within that carries info like track, artist, and album title. Likewise modern photographers would be absolutely lost without the EXIF data embedded into each image (that’s a topic for another day). If we have metadata, we know what coordinate system our data is utilizing. If that coordinate system doesn’t happen to match what we’re trying to line it up to, then math comes to the rescue with the instructions to transform or “reproject” the data from one coordinate system to another.
How well do different data reproject?
Generally speaking, vector-based data such as the points, lines, and polygons (found in data like the ubiquitous shapefile) are much easier to reproject from one coordinate system to another. Shapefiles store coordinate pairs and some instructions on how to connect those dots. However, where raster data like aerial imagery is concerned, a true reprojection can be a very resource-intensive operation from a computing standpoint. That said, the extent of current UAV acquired imagery is on the order of half and quarter sections; a very, very, small flattened surface to be superimposing over our big blue marble, making the wait on such transformations much more tolerable (at least until we start seeing long endurance drones taking to the sky).
So now that I’ve thoroughly put you to sleep, go grab your caffeinated beverage of choice, and then come back and feel free to share your experiences (or woes) with coordinate systems. Can’t sort your planar from your geodesic? Or maybe a map put you in the neighbor’s field when you weren’t minding the autosteer? Let’s have it!