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.
Convert Polygons to Polylines This macro can be used to convert Polygons into Polylines. In order to use the macro you must specify a spatial field (polygon) as an input.
After running the module all the polygons in the selected spatial field will be converted to polylines. This macro is very useful for when you are putting polygons on an ALTERYX base map and want their boundaries to appear on top of the base map roads. An example would be the mapping of census based Trade Areas. As census Geographies tend to follow roads, they are often obscured by the Alteryx base map. Before Example After Example
In its spatial tools, Alteryx includes an option to create a convex hull polygon from a series of points. However, depending on the type of analysis requested, it can be more ideal to create a concave hull instead. An example of this would be the need to group customer points into trade areas thematically based on store location. If the standard method of convex hull polygon creation were used, it would be possible to create polygons that overlap, which would not be the desired outcome. A demostration of this is shown below. Module attached. Example: To avoid this, one can first project non-overlapping trade areas from the points and spatially combine them to eliminate the overlap. To then remove the excess area projected, the object can be trimmed to the original convex hull boundaries. To further process and remove the resulting holes, spatial generalization can then be used.
The addition of a reference map can bring your report to another level of utility. This is a technique that is often used when a module is developed to produce a multitude of maps; each zoomed-in upon a small area. For users who may be unfamiliar with the area displayed in the primary map view, a reference map provides a rapid means of orientation. The key to creating a reference map is making use of the bounding rectangle sourced from your primary map. The bounding rectangle will be used as a display feature (layer) in the reference map.
Alteryx users who have purchased the TomTom Alteryx Maps data set have the ability to extract layers into various formats using the Alteryx Street Analytic App. Installs from TomTom 2011 Q3 Alteryx Maps forward, include the Street App within the install. The App replaces what was previously known as the StreetWare product. The Alteryx Street App is an extraction tool which allows the user to extract TomTom layers into various file formats such as .tab, .shp, .yxdb to name a few. The App is specific to the data install vintage of TomTom Alteryx Maps Data and is located in the, AlteryxDataProductsAlteryxMapTomTom_US_xxxx_Qx directory. To run the Street App (TomTom_US_yyyy_Qx.yxwz) you will need to browse to the location above and select it. Under the Geography Selection tab, select the Geographies you would like data for. You may select all, single or multiple Geographies as shown below:
Under the Layer Selection tab, you may select the individual layers you would like to install for the Geographies that you selected.
The Output Options tab allows you to select the file format you wish to create and the Destination directory you wish to install the data to. There is also an option to merge the geographies.
One feature of the wizard that was not present in the StreetWare product is the ability to create seamless .tab files. This feature allows the user the ability to bypass the 2 GB limitation that .tab files have. Please note .shp files also have a 2 GB file size limitation but do not offer the same seamless ability that is incorporate in the extraction of .tab files When .tab file format is selected a folder is created containing the referenced .tab tables, the seamless .tab files are visible below this folder. As Shown Below:
The seamless .tab files will be opened and viewed in MapInfo as normal. The individual .tab files that are referenced by the Seamless files can be found in the SeamlessTabFiles folder. We hope our users find that the Street App will be an easy-to-use utility to extract the desired map layers for use in their preferred applications.
Often, we get support requests asking if we can do a quick session on best practices for a particular tool or set of tools. The Spatial Match Tool is certainly no stranger to this request. Even though Alteryx is extremely fast and efficient with spatial processing, there are instances where a slight change in settings could speed up your total module runtime. For example, let us assume that we have 10,000 records that we are trying to perform a spatial match against. Upon looking at our data, we notice that the points were derived from the centroid of another polygon, but the previous polygon field was still in the data stream. Removing the unnecessary spatial field is one of the first steps in optimizing your data stream. Why? If you don't need the data, why are you pushing it all the way through your module? That extra data consumes memory, so removing it from your data stream reduces that consumption, increasing the available resources on your computer. Ultimately, this practice can be used in any aspect of your data, but it is especially relevant with spatial processing. For more tips and tricks regarding your spatial match process, download the included zip package. It contains information that can help you optimize your modules that utilize the Spatial Match tool. Special thanks to Paul Treece for helping out with the module! Until next time! - Chad Follow me on Twitter! @AlteryxChad
I have no doubts that many of you have attempted to geocode a set of records, only to find that your records show up in the middle of the ocean on the other side of the world. I certainly have, and the result is always that I accidentally reversed my non-descriptive latitude and longitude fields just before the Alteryx Create Points Tool. If I had taken a quick look at my data, I would have known that my field with a non-zero hundreds digit (100+) is my longitude field, and setting it properly would have saved me valuable processing time. While the above example is common, there are many others that are equally as common that can be fixed or avoided completely with a bit of additional knowledge. The main question of the article (How accurate does my data need to be?) all depends on your use case. For example, in many point-in-polygon cases you may only need 5 digits of precision rather than 6. Why? 5 decimal places are accurate at 1.1 meters, while 6 decimals are accurate to 0.11 meters. This may seem like a big difference, but when you are trying to search for entire buildings based on a trade area, 5 decimals should do the trick. If you are interested in learning more, please take a look at the StackExchange article How to Measure Accuracy of Latitude and Longitude. This breaks down the difference between accuracy and precision, and goes into detail about each decimal in a latitude and longitude point (with examples!). Big thanks goes out to our very own Paul Treece for his help with the article. Until next time! Chad Follow me on Twitter! @AlteryxChad