Connecting the Dots - Garmin Watch to AGOL

For Christmas, my wife bought me a Garmin Forerunner 35 to assist with my training leading up to Grandma's Marathon in Duluth this summer. So far, I've really enjoyed everything the Forerunner 35 has to offer and I've been pleasantly surprised with how quickly it syncs to mobile devices.

Since I also now have a personal AGOL license, I wanted to play around with uploading some of my watch data and creating a web map to catalog my training routes.  The Garmin Connect App already does this (and much more), but I wanted an excuse to play around in AGOL.

After downloading a recent .gpx file from the Garmin Connect website, I was able to use the GPX to Features tool to bring these feature points into ArcMap.

GPX to Features Tool

Output points from the .gpx file

While the points are interesting visually, my primary goal was to save these routes as line features.  To accomplish this, the Points to Line tool enabled me to connect these points (which have a Date/Time field) chronologically to create a continuous route line.

Points to Line tool, with Date/Time as the sort field

Output line after running the Points to Line tool

So, there you have it, a relatively simple set of procedures to get .gpx data off of a running watch and into ArcMap!  I loaded the data into an AGOL test map, which can be found on the Running tab of this blog, for those interested in seeing the results! More routes to come!

Unnecessary Concern of the Day: Snapping Beyond a 1:1 Scale

An ongoing head-scratcher for me has been why my points/lines/polygons look "off" in ArcMap when zoomed in beyond a 1:1 scale. Today, I found the answer to my question! A question, it turns out, that I didn't need to worry about in the first place.

The explanation I found for this issue is summed up as follows:
"Viewing linework at a viewing scale of less than 1:1 will show apparent offsets that are not real - i.e. they are not really what is going on. The polygons could be totally coincident, but below 1:1 look off. So some visually-seen disconcerting gaps/overlaps are actually not issues."

Here's ESRI Supports explanation:
"As per our phone interaction, a map scale past 1:1 is a known limitation of our software because at a scale of 1:1, the screen display is equal to the actual distance of objects on the earth's surface (i.e. an inch on your screen is equal to an inch on the ground). When you go past that scale, it may appear that features are overlapping (when in reality) what you are seeing is the actual software resolution tolerance pushed past it's maximum threshold. In essence, the entire screen is only one point (at a map scale of 1:0), which is why your work flow is producing inaccurate results."

Original Thread Here: https://community.esri.com/thread/180322

In other words, don't be fooled by the illusion beyond a 1:1 scale! Everything is Fine.....probably. Maybe set up a few topology rules to ease your worries for good?

GIS Corps - Mapping Malakal, Nsanje District

Mapping of Malakal, Nsanje District (Partnered with Humanitarian OpenStreetMap Team)

From January 2014 - Novemeber 2014 I was involved with a project to remotely map areas of Malawi as a Volunteer Coordinator with the GIS Corps.  Below is a detailed description of this effort.

In September 2014, GIS Corps partnered with Severin Menard of the Humanitarian OpenStreetMap Team to begin mapping the Southern region of Malawi along the Lower Shire River.  The area along the Lower Shire (the Nsanje District) connects Lake Malawi and the Zambezi River in Mozambique and is prone to frequent flooding that can be devastating to local communities.

The national Department of Disaster Management Affairs in Malawi (DoDMA) and the Global Facility for Disaster Reduction and Recovery (GFDRR) agreed about the necessity to have detailed data of the region.  Through community mapping in the field, the collected data could be used to build hazard impact scenarios with tools like InaSafe to improve planning, preparedness and response activities.  Flood prone areas were identified through local experience and knowledge from DoDMA headquarters, DoDMA districts officers, village leaders, and local residents.

http://hot.openstreetmap.org/projects/osm_community_mapping_for_flood_preparedness_in_malawi

Since October 2014, GIS Corps volunteers have made significant progress toward mapping roads, buildings, footpaths, and waterways in an effort to add valuable spatial data to OpenStreetMap.  Areas of high priority were identified, and as of late January 2015 approximately 150 square miles have been mapped in these flood prone areas (see Figure 1, Figure 2, Figure 3).

The project used the iD and JOSM editors developed for OSM, and the Tasking Manager developed by HOT. GISCorps managed the project, provided online documentation of project methods, and created a Q&A document where volunteers could find answers to their questions. Skype, Google Chat, and Google Drive collaboration documents have been utilized for real-time communication between volunteers.

Recent Developments

In mid-January, devastating flooding in Southern Malawi and Mozambique left tens-of-thousands displaced from their homes, thus reaffirming this project’s importance and the necessity of GIS Corps’ involvement with the Humantarian OpenStreetMap Team(http://www.theguardian.com/global-development/2015/jan/14/malawi-flooding-torrential-rain-mozambique).  Heavy rains have damaged crops, washed away livestock, damaged infrastructure, and have left many stranded in low-lying areas.

GIS Corps volunteers have continued their hard work, mapping in designated “priority areas” where disaster planning efforts are most crucial.  The job aims primarily at adding building footprints and infrastructure data, which will serve to estimate the number of affected people for each settlement.  Since the mid-January flooding, Severin Menard (HOT Coordinator) has re-established areas of high priority and identified several other areas within Southern Malawi in which mapping efforts are needed.

Link to article on GIS Corps Website:

http://www.giscorps.org/index.php?option=com_content&task=view&id=162&Itemid=63

Link to related article:

http://hotosm.org/updates/2015-02-27_hot_called_upon_to_support_disaster_response_in_malawi_flooding

Figure 1 - Project Area, Nsanje District, Malawi

Figure 2 - HOT/OSM Project Overview Page, completed tiles

Figure 3 - Detailed view of mapping progress in OSM

Exporting Maps to PDF with Python

Recently, I had the need for a python script that would export a series of maps to PDF.

I wanted to set up a task using Python and Task Scheduler, that would access a workspace location and export every .mxd at that location to PDF at a specific time during the evening.

I began with a script I found here:  http://support.esri.com/en/technical-article/000012420

I ended up with a slightly modified script, as shown below:

_________________________________________________________
#Import modules here
import arcpy, os

print ('Hello, finding workspace now...')

#Set workspace location here
arcpy.env.workspace = ws = r"C:\Test"

print ('Finding .mxd files now...')

#Create list of .mxd files within the workspace.
mxd_list = arcpy.ListFiles("*.mxd")

print ('Exporting to PDF now...')

for mxd in mxd_list:
   
    current_mxd = arcpy.mapping.MapDocument(os.path.join(ws, mxd))
    pdf_name = mxd[:-4] + ".pdf"
    arcpy.mapping.ExportToPDF(current_mxd, pdf_name)

print ('Complete, thank you for using Map Exporter!')
__________________________________________________________


Next, I needed to set the script to run at a specific time. 

To accomplish this, I started by opening Task Scheduler from the Windows Start Menu.

Next, I ran through the following steps:

1. Create a Basic Task
2. Start Daily
3. Run time 10 p.m., recurring daily
4. Action = Start a program
5. Select location of script


Now, I have a nice, tidy, fairly simple map exporter that will run every night at 10 p.m. 

Additional information on utilizing the Task Scheduler is here:    https://blogs.esri.com/esri/arcgis/2013/07/30/scheduling-a-scrip/

Using ModelBuilder to Streamline Editing in ArcMap

Recently I was tasked with creating section lines (from township dimensions and attributes contained in legal descriptions) for several counties in Minnesota.

Existing data was deemed insufficient for our project's purposes, so the lines would need to be manually created, on a case by case basis, in order to accurately plot data.

Maintaining the integrity of the section line feature class was very important, and would dictate the accuracy of other steps in the process.  Thus, creating section lines that were both accurate and topologically sound became my primary concern.  Creating sections without overshoots, dangles, or extraneous points was the primary goal here, and I wanted to ensure I streamlined the process to remove human error during the editing process.  The section lines themselves didn't need to be perfect, but we needed to be consistent in our approach.

The first step in the process involved close examination of aerial imagery, and unfortunately could not be modeled.  The mapper would need to carefully draw a centerline along a road, fence, or other visible use-line in order to establish the boundary of each section.  Next, the Copy Parallel tool was utilized to offset each line by 1320 feet.  The result of this manual operation is a grid, as depicted in the image below.

Image 1 - Section lines before running custom tool

As you can see, the grid contains a number of errors including line overshoots, dangles, and extraneous vertices.

The tool below, is aimed at correcting these issues without manual edits.



Image 2 - "Finalize Section Lines" tool developed in ModelBuilder



Image 3 - "Finalize Section Lines" tool

The end result of the model, should look something like the image below.  Nice, clean lines, with 2 vertices per edge.

Image 4 - End Result