Archive for June, 2012
Professional Philosophy: Don’t be Enemies with the End User
Posted by Gretchen in Cartography Profession, Uncategorized on June 25, 2012
When listening to water-cooler chat we often hear a tone of animosity toward the very people for whom we are working. No, I’m not referring to the boss (though that’s certainly typical as well), I’m referring to the end users of whatever it is you are creating.
Software developers complain about the idiocy of those who will be using their system, GIS analysts complain about wolves not living in the areas cited as most suitable in their GIS models*, cartography teachers worry about the incompetent design skills of those they teach, and so on.
What are you prone to complaining about and how can you turn that around so as to design a better product for your end users?
When we are excited about creating something that will eventually be used to make a difference, our work performance increases. Think about what those things are that make the product useful and keep those things at the forefront of your mind throughout the project for the ultimate motivated mindset.
All too often–especially in the cartography teaching field–we tend to be, okay, I’m going to say it…SNOBS…about how much we know and about how much the “others” don’t know. In the case of teaching cartography, our end users are the students who are learning. A much better approach is to evaluate their current skills, respect the variety of strengths they bring (both vocally and in terms of our attitude), and teach with compassion. This brings about a much more satisfactory result than the “snob-method”, which only serves to scare students off.
I still remember a very old professor of horticulture whom I took a class from back in college. The course was basically one of memorization. You had to memorize the names of trees, how to identify them in both winter and summer foliage, where they grew, and so on. This professor had had a stroke a few years prior to my class. He said that after his stroke he had to re-memorize everything that he was teaching, because the stroke had caused him to forget it all. Because re-learning it was still fresh in his mind, he told us he was much easier on us than he had been to students before his stroke, because he realized how difficult it is to learn everything from scratch. His experience gave him extra empathy for his end users–the students. We still learned quite a bit, and probably fared better than his previous classes, due to a new emphasis on collaborative learning that he had put into place to facilitate retention of the difficult material.
So that brings us to the following warning: being enemies with the end user is not only unproductive, it may even lead to your demise.
*Only partially a joke, it’s probably happened. 
US Cartography Employment Outlook 2010-2020
Posted by Gretchen in Cartography Profession on June 23, 2012
According to the ArcNews Summer 2012 issue, the occupation listed as “cartographers and photogrammetrists” has a 2010 estimated employment of 14,000 in the US with a projected growth between 2010 and 2012 2020 of 6,100, for a predicted growth rate of 20%-28%.
This growth rate is the highest reported for the 10 GIS related occupations listed in the ArcNews article, tying with “geodetic surveyors” and “surveyors”. Numerically, however, it is still a relatively small portion of GIS work, considering the categories of “geospatial information scientists and technologists” and “geographic information systems technicians” each have a 2010 estimated employment of 210,000.
ArcNews sites the US Bureau of Labor Statistics as the source.
Rectangular In-line Maps
Posted by Gretchen in Best Practices on June 22, 2012
If you do a lot of analysis and subsequent reporting, like I do, you’ll understand how awkward a report looks with maps sprinkled throughout it. It’s best to keep the report maps no bigger than 1/3 of the page for visual balance, as I’ve stated before. But here’s a new recommendation: make the maps rectangular, rather than square. This keeps the look and feel of the report consistent, since the text also runs in a rectangular fashion.
Here’s a report page with square-shaped map examples:
And here’s a report page with rectangular-shaped map examples:
I could have even made those rectangular maps the exact width of the text for bonus points.
Making of High Park Fire Map
Snapshot of the map:
View the interactive map here.
The Colorado High Park Fire, which started on Saturday June 9, has burned over 56,000 acres so far, and continues to burn. On Sunday June 10, my husband, Kris, and I decided to get a map of the fire out to the public, since none existed at that time. Kris is the owner of Mapbiquity, which happens to be a service that is already built to allow rapid deployment of web maps, so it was natural that we should give it a spin with the fire data. Another reason we jumped on this was because the fire is very close to home. In fact, here’s a picture I took from our window on June 11, when the fire was 5.5 miles away as the crow flies:
You can see a couple of red spots–fire–on the foothills in the picture. Kris and I took Monday off work to continue to fine-tune the map, which was getting so many hits that it was running very slowly. I spent quite a lot of time interpreting Larimer County’s text on evacuation issues and lifts in order to digitize them.
To date, our map is the only one that has the evacuation areas digitized. I do have to caveat that there is at least one evacuation area that is not on our map. This is due to my inability to interpret the Larimer County text in sufficient detail to create even a semi-accurate boundary.
BIG THANKS to Nick Armstrong, a small business Colorado-based marketing expert, who read our tweets about the fire map and subsequently purchased a dedicated domain/host for us to put the map on: www.cohighparkfiremap.org. Prior to this we had been using a mapbiquity domain.
The map has had 50,000 hits. To deal with the traffic, we enacted the following measures:
1) Moved it to a larger server with more processing power
2) Disabled most of the log files
3) Moved the JavaScript file into the main html page, which creates some sloppy-looking code, but reduces the amount of calls back and forth to the server
4) Began caching, though this means some users need to refresh and reload the page before they see the updates, unfortunately
The benefits / design considerations of the high park fire map that we put together are as follows:
1) It is interactive, people can zoom in to see where their home is or where their relative’s home is, while also viewing the latest fire perimeter, to determine how concerned they need to be.
2) You can measure distances on the map with an easy tool. People have been using this to tell their family and friends “the fire is 6.5 miles away” for example.
3) Each layer has an “i” button with more information on the layer. For the evacuation areas, clicking the “i” button displays the official evacuation wording (though we had to fix many typos in the official wording. For example, they did not spell Hewlett Gulch correctly in one instance.)
4) Having a disclaimer noting that the map is not “to the scale of individual houses” was the best way to inform the public that the evacuation areas are not very high-resolution. They have to visit the text or call an official number (provided) to make individual house determinations.
5) Twitter was used as the main form of communication to let people know when map updates were/are posted.
The map is featured in the Coloradoan. We thank them for making it known to a wider audience.
Colorado High Park Fire Map
There haven’t been any new blog posts recently, because a small team including myself has been volunteering most of our time to the Colorado High Park Fire interactive map. The fire was close to home, literally.
The map is updated as continuously as we can with the latest evacuation information (both issues and lifts), shelter locations and status, and the latest infrared layers–which tend to be flown daily. I’ll write a longer post about the making of the map and some lessons learned once things settle down. In the meantime, it is time to catch up on existing client work and…sleep
Calculating Variable Width Buffers on a Stream Segment Based on Elevation
GOAL: variable width buffer based on elevation
RESULT: What we’ve got is mostly correct, but with the following issue.
METHODS
In the example below, the stream line is shown in blue and some retention ponds are visible in the aerial photo near that stream:
Next, we take that stream segment and make it into a grid with the same extent as our elevation grid. It looks like this, where each cell has a slightly different elevation value (streams generally go downhill!):
Then we create a Euclidean allocation grid from those stream elevations. It just assigns the elevation of the nearest source stream pixel to all of the other cells. For example, the yellow area is all assigned pixel values of 148817 (meters X 100, since I have also multiplied the elevation grid by 100 to make it into an integer). That stream pixel value that the yellow is emanating out from has a value of 148817.
The next step is to subtract the Euclidean grid from the true elevation grid so that, for each pixel, we determine how much higher that pixel is than the elevation of the closest stream pixel. Ideally, this would produce a variable width buffer once you set a threshold for how high you want to go. For example, if I set the threshold at 1/2′ (which is 15 units in my data, remember it is meters and multiplied by 100), then the resulting “buffer” looks like this, in green:
The area shaded in green is a model of where the locations around the stream are within a half-foot elevation rise of the stream. Areas that are not in green are higher than half a foot of the stream. Note that I’ve left out some of the details which involve subtracting the Euc grid from the elevation grid, then testing (with a con statement in ArcMap in this case) whether or not the result is above 15 or lower than 15, where it is lower than 15, we assign the pixel a 1 and where it is above 15 we assign a NoData value.
THE ISSUE
The model works pretty well in many areas. As can be expected, it looks even better when we use less fine increments. So if we calculate the 7′ elevation rise, for example, the resulting buffer does not have a lot of strange “jogs” out from the stream line. I’ve chosen this particular example location to illustrate the problem that these retention ponds make very clear. One would expect that the entire retention pond, which has a completely even elevation surface, would be in the buffer if part of it is. However, in this case, the anomaly lies with the Euclidean distance raster. Since it is allocating the closest stream elevation to each pixel, if a stream changes in elevation enough from one neighboring pixel to another to cause the subtraction of the grids to cause one part of the pond to be “in” the buffer and one “out” of the buffer, then this will happen.
STEP BY STEP EXAMPLE
In this case, the pink part of the Euclidean distance calculation, in the upper left quadrant, comes from a source pixel having elevation equal to 148,987.
The purple area of the Euclidean grid just below that pink area has an elevation value equal to 148,801.
The retention pond has an elevation of 148,990 throughout its area (well, at least until you get to the slight rise at its edges).
For the pink part then, 148,990 – 148,987 = 3. Clearly, 3 is within out threshold of half-foot (which is 15 units)
For the purple part, 148,990 – 148,801 = 189. Clearly, 189 is not in our half-foot threshold. Thus, it doesn’t show up, even though the retention pond has an even elevation throughout!
At this stage in the analysis we must quantify the effect of this anomaly on the overall model’s accuracy.
(I noted at the end of How To Create an Inside Buffer Based on Elevation, that a cost distance raster could be used to do what I describe above. However, cost distance works only for local areas where the stream elevation remains constant–in this case, the stream elevations change from mountain elevations on down to plains elevations)
-
You are currently browsing the archives for June, 2012
The Books
Recent Comments