This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Looks aren't everything... But the latest Community refresh looks darn good!
Learn Moreon 05-17-2019 07:02 AM - edited on 05-17-2019 07:02 AM by SydneyF
Gathering and using spatial data requires a way to record the location of whatever is being observed (e.g., buildings) that preserves the spatial properties of the data (e.g., the distance between points in a dataset). Spatial reference systems are used to record the spatial properties of data in a meaningful and translatable way.
Spatial reference systems are typically made up of two components, a 2-dimensional coordinate system, which defines the rules of how points are assigned to observations of spatial data, and a 3-dimensional datum, which defines the origin and scale of the coordinate system. These two components in combination allow spatial phenomena to be meaningfully translated and recorded as data.
Coordinate Systems
The coordinate system of a spatial reference system is used to define the location of a spatial object using a set of numbers.
Think about a simple cartesian coordinate system that you might have been exposed to in math class. Typically, an x-coordinate is used to represent the horizontal position of an object, and the y-coordinate is used to represent the vertical position. Combining these two coordinates describe the location of a point in the 2-dimensional plane.
Geographic coordinate systems work the same way, but for positions on the surface of the Earth.
For example, latitude and longitude are a coordinate system where latitude represents the north/south location of a point, and longitude describes the east/west.
Datum
For analyzing spatial data in a relatively small region of interest, geographic coordinate systems can be accurate while approximating the shape of the Earth as a sphere. For an analysis that covers a larger area, the approximation of an ellipsoid (it has two radii instead of one) is much more accurate (+-0.3%). However, the Earth’s true shape is not an ellipsoid either. To maximize the accuracy of analysis where spatial data spans a large area of the Earth, variation across the Earth’s surface need to be considered.
A geodetic datum (also called a datum for short) defines a reference frame for spatial coordinates, measurements, and calculations. It consists of a selected ellipsoid and a definition of the position of the ellipsoid relative to the center of the geoid (the smooth but irregular surface of the Earth). Some of the more well-known datums include WGS84, NAD83, OSGB36.
Projections
If you have worked with spatial data before, you made have heard of projections. Projections are a special type of coordinate system that specifically account for the distortion that occurs when translating a 3-d object (the Earth) to a 2-d representation (e.g., a map). Depending on the projection chosen distortion will occur in one or more aspects of shape, area, distance, and direction. It is important to note that each map projection will preserve only or two of the four spatial properties.
A common map projection is the Mercator projection, though it has limitations.
The Mercator Projection was designed as a navigational tool for sailors. It preserves the shape of coastlines, and direction (rhumb lines, useful for navigation) while distorting area. Moving away from the Equator to the poles, the size of landmasses appears much bigger than they really are. For instance, Greenland owing to its closeness to the North Pole will appear roughly the same size as Africa.
This shows how important the choice and understanding of the projection can be to get accurate results.
How does Alteryx Designer handle Spatial Data?
All spatial data read into Alteryx is automatically transformed to a WGS84 datum with a latitude and longitude coordinate system.
Spatial calculations in Designer are performed on a sphere with a radius between the polar and equatorial radii of the Earth. This does result in some distortion in calculations. Near the equator, distance calculations can be 0.2% smaller than their actual size, and near the poles, distance calculations can be 0.2% larger. Within the US and Europe, distance calculations are more accurate. Alteryx does not use any projected coordinates when performing spatial calculations.
Projections can be specified when writing out data spatial formats via the Edit projection dialog box. This feature is supported in the following spatial file formats: MID/MIF TAB, SHP, Oracle, and ESRI Personal Geo-Database.
All maps from the Report Map tool are drawn in Spherical Mercator projection.
Great overview of these spatial principles @MichaelAd. Could you elaborate on what Alteryx is doing when a spatial dataset in a projected coordinate system (e.g. NAD 1983 HARN StatePlane Oregon North FIPS 3601 Feet Intl) is inputted into a workflow? Is a transformation being applied, and if so, how does the user know which one? My colleagues and I are trained geographers and GIS analysts that use Esri products. The data we work with is almost always in a projected coordinate system, so when we output a spatial dataset from Alteryx we'd like it in its native projected coordinate system. My typical process is to export to an Esri personal geodatabase (Esri shapefile truncates fields names and has other limitations) using the custom projection option to define an Esri projection file (e.g. ESRI::X:\0 Software\Alteryx\Esri_coordinate_systems\NAD 1983 HARN StatePlane Oregon North FIPS 3601 (Intl Feet).prj) and then copy/paste into n Esri file geodatabase. Ideally, I'd like to move away from the Esri personal geodatabase, because it is becoming obsolete (not supported in ArcGIS Pro), but cannot at this point, because the export to file geodatabase option in Alteryx does not offer the same projection-setting ability. I've tried to re-project spatial datasets that have been outputted by Alteryx to a file geodatabase (in WGS84) to their native projected coordinate systems, but this has resulted in slight datum transformation shifts. Thanks for any input.
Hi @abrasch,
Thank you for your questions!
When a spatial data set is read-in to Alteryx, an implicit transformation takes place, converting the spatial data from it's native projection to WGS84. Depending on the type of file being brought into Alteryx, the Input tool will either prompt the user to specify which projection the input data is in, or if the projection is encoded as a part of the input file, and Alteryx will determine the projection from that. Some input files have an encoded projection Alteryx is able to read, while others do not.
I spoke to the Product Manager regarding the ability to reproject data when writing out to a File Geodatabase, and he advised that we're looking into our options as File Geodatabases are an ESRI proprietary format.
Are there any other questions I might be able to assist you with? Please let me know.
Sydney
Hi @SydneyF,
Thanks for the reply. The files I am importing into Alteryx do, indeed, have an encoded projection, so I am not being prompted to specify one upon read-in. Initially, I was specifically wondering if more details could be provided on the "implicit" transformation. I ask, because when changing coordinate systems in Esri products, the user is prompted to choose a geographic transformation, of which there are many options (see screenshot below). I am assuming most Esri users, and likely Alteryx, are using the "default" suggestion (e.g. in the case of WGS84 <> NAD83, use WGS_1984_(ITRF00)_To_NAD_1983). In most cases, I think the Esri options are overkill. Perhaps R users might chime in, since I believe transformations are also handled implicitly. For instance, using spTransform from NAD83 to WGS84 (see below).
Lastly, thanks for looking into options to either 1) export to file geodatabase in a projected coordination system, or 2) reproject into projected coordinate system after export to file geodatabase in WGS84. It's unfortunate that Esri is not more open to interoperability.
Hdata@proj4string
CRS arguments:
+proj=utm +zone=10 +ellps=GRS80 +datum=NAD83 +units=m +no_defs +towgs84=0,0,0
WGS84 <- ("+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +towgs84=0,0,0")
Hdata_WGS84 <- sp::spTransform(Hdata, sp::CRS(WGS84))
Hi @abrasch,
Alteryx uses GDAL (which in turn uses PROJ.4) to perform coordinate transformations. The target for the transformation is the WGS 84 datum with no projection. According to the PROJ.4 documentation, transformations are performed using either a Helmert transformation, datum shift grids, or a combination of both. Please see this resource to read more about Coordinate operations in PROJ.4.
The spTransform() function in the sp R package is executed by the rgdal R package, which is also based on GDAL (and PROJ.4). It is possible to specify a variety of geodetic transformations in R with PROJ.4 using the cs2cs framework specified in the PROJ.4 documentation. The transformations in R are expressed as two separate, explicit proj-strings, which map the source CRS system to the destination CRS, and are performed with a Helmert transformation, datum shift grids, or both.
Does this answer your question regarding the input? Please let me know.
Thanks,
Sydney
Hi @SydneyF,
Yes, your reply answers my question wonderfully! I really appreciate the level of detail you provided and the links to additional resources. It's great to move forward with my spatial data analysis with a better understanding of how Alteryx is handling projections and transformations.
Thanks again,
Alex