Thursday, December 1, 2011
Getting started with eCogniton webinar recording
A recording of the AmericaView sponsored webinar, Getting Started with eCognition, that I gave today is now available for viewing via this link. You may also be interested in another video, Segmentation Algorithms in eCognition. The segmentation video uses the same data and contains a link to download the data from the eCognition Community site.
Saturday, November 5, 2011
Leveraging Geospatial Knowledge to solve Geographic Secrets
This post on leveraging geospatial knowledge to solve geographic secrets comes from one of our interped GIS techs, Dan Koopman.
--
Urban Exploration is a hobby that has skyrocketed in popularity over the past 20 years in the United States. It is loosely defined as the discovery, infiltration, and exploration of areas traditionally deemed "off limits."
It is probably no mistake that the increase in popularity of Urban Exploration parallels the public's access to new and ever-improving geospatial data in the form of free services such as Google Maps. What started as a technical tool aimed at getting people from Point A to Point B, has raised awareness within the public of what comes between - in other words, the value of public geospatial data beyond driving directions. The discovery and exploration of abandoned places is, at its heart, a geospatial question that begs to be answered and addressed by datasets ranging from high-resolution imagery to census information.
These leaps in awareness and usership, however, have come at a price to Urban Exploration. Increased access to information about delicate abandoned buildings and the resulting traffic in and out has led to many negative consequences in the hobby. These consequences range from increases in security aimed at keeping explorers out of sites, to outright abuse and degradation of sacred historic buildings by vandals. To counteract this abuse, two unspoken rules obeyed by the community for sites not yet heavily trafficked have been established:
a) The exact location of the site must never be revealed
b) However, Clues leading serious and respectful explorers to the site can be given upon request, so long as some amount of work must be undertaken in order to find the site.
This being said, I hope that whoever chooses to read this article takes from it not a free shot at a really cool place, but an example of how using geographic knowledge in conjunction with free geospatial technology can help you find a virtual needle in a haystack. I also feel comfortable in sharing this since the location discussed is so remote that the effort it would take to reach would not be worthwhile for your average vandal.
Jake Reinig is a talented young photographer and explorer from San Diego, California. I was visiting his website when I came across some beautiful pictures of some double-decker passenger train cars left abandoned in a desert. Reinig, being a responsible explorer, spared only two descriptions in his explanation of the site: in the "Desert east of San Diego." I became so interested in the idea of several large passenger train cars being stranded in the middle of the desert that I decided to try and find them using Google Earth.
I encourage the reader to check out Jake's post that contains the images used to find the trains:
http://www.jakereinig.com/blog/?p=1901
In an initially naïve move, I figured that I could just "fly around" in Google Earth in the desert east of San Diego, and find the cars in the imagery. I soon realized however that this was a ridiculous and ineffective method.
In the last of the pictures on Reinig's post, there is a very distinct conical mountain in the background behind the railroad tracks. I opened up the Google Earth preferences and set the vertical exaggeration to 2/3 - this allowed me to try and match the feature that I was seeing with the digital elevation model that is loaded in Google Earth. Unfortunately, as I found out, there are many conical mountains in the desert east of San Diego. It only took about an hour of fruitless navigation to figure that out...
After the realization that trying to find a train car in 2500 mi2 of desert was literally like trying to find a needle in a haystack, I started to assemble more contextual clues and leverage geospatial information.
I started working under these assumptions:
Specified in Description
* Desert
* East of San Diego
Implied
* It's a railroad
Visually Interpreted Clues
* The trains are on a spur
* The spur likely ends after the train cars
* There is a smallish trestle over a river
It occurred to me that there may not be too many railroad lines running through the desert in that part of the world, so I googled "California Railroads." I cherry picked a very simple map of the all historical railroads in California courtesy of www.djcooley.com and zoomed in on Southern California:
The map reveals that there is only one railroad line that connects San Diego to the desert, and it cuts across the mountains east of San Diego and across the southern part of the Anza-Borrego Desert eastward to El Centro. I went on the assumption that the trains had to be located on a spur off of this railroad line, narrowing down the potential targets.
At that point, I began to interpret the pictures on Reinig's site a little more thoroughly.
Perhaps the single most important photograph to solving the secret is the second to last one, for two reasons:
a) It shows the fact that the trains are on a spur
b) More importantly, it reveals that the "main line" of tracks runs in a SE to NW fashion. I arrived at this crucial relationship when I noticed that the sun in that photograph is setting. Because the sun always sets in the West, and the main line is closer in the left of the frame than the right, it must have been constructed on a SE to NW trajectory.
Drawing this relationship out on paper gave me a map to compare with the imagery for the area, greatly improving the likelihood of finding the trains. But that's not all - the first picture clearly shows the spur ending after the trains. It also shows a bit of topography to the East of the trains as well as to the North.
Another crucial piece of evidence is revealed in the final picture, which shows the conical mountain. Because of the newfound contextual knowledge that the railroad tracks run SE to NW, it can be assumed that there is a considerably unique conical mountain to the South and East of the trains.
I added these new geographic clues to my list:
Geographic Clues
* Because the sun sets in the West, and this is clearly a sunset, the main rail line must run from the SE to the NW, with the spur roughly N/NE
* There is a very distinct conical mountain to the South of the Spur
* There is a small railroad trestle going over a stream
* One of the photos reveals that there is a hill to the SE of the trains as the photo is looking down on the trains
* There is a distinctive conical mountain to the SE of the site
I also began to look at Geologic clues. In the second-to-last picture, there is considerable vegetation - sagebrush and low-lying desert bushes. The density of cover is relatively high. The first picture shows there to be large sandstone outcroppings and boulders, uncharacteristic of a low desert. I also added these clues to my list:
Geologic Clues
* There are large smoothed sandstone outcrops in close proximity to the trains
* There is sand that has been blown over the tracks
* There is considerable vegetation and brush
* The end of the spur has a large rock outcrop
These new clues brought me back to El Centro. I suspect that it is called El Centro for a reason... To the east there is nothing but sandy flat areas without any distinct topography... This description definitely does not fit in with the land cover seen in the pictures, and is missing that crucial conical mountain feature to the southeast of the trains.
With these clues compiled, a significantly reduced search area began to take shape:
a) EAST of San Diego, in (or near) the desert
b) WEST of El Centro
c) NORTH of the Mexican Border (it's assumed to be in the United States)
d) SOUTH OF or DIRECTLY ON the only railroad that connects San Diego to El Centro.
This graphic shows the only possible places the site could be. The red line represents the railroad line drawn in from the California Railroads Map. The black box shows the West, South and East borders.
I also drew out the trajectory of the main line and spur that I figured out from the sunset picture:
Armed with the Hand Drawn Map showing the clues, I began following the railroad line west out of El Centro. The drawn map was invaluable as you could eliminate any section that didn't fit the 2 dimensional vectors of the SE-NW line. That is to say, there are an awful lot of sections that don't meet those criteria. Still, I was hung up on the location being on the Eastern edge of the mountain range...
I had isolated an area that met the description well - the tracks were SE-NW, there was a conical mountain in the SE, there was sand over the tracks, a small trestle over a stream and even an abandoned water tank - unfortunately there was no spur. I turned on the "Historical Imagery" toolbar and turned on previously acquired imagery but there was no evidence of a spur.
After that failure, I turned on the "Photos" layer in Google Earth and was surprised by how many images came up. Basically, users upload and "tag" the locations of their pictures to Google Earth's servers. These images are then added to a central database and made available through the "Photos" layer. In the area that I was focusing on, I found one tagged as "Carrizo Gorge Railway."
Without divulging any more information, within several minutes I was tracking the railroad line further west, hand drawn map in hand. When I finally found the site, I must admit that it was not as far from civilization as I had expected. It is actually the quiet neighbor to an, er, interesting type of ranch...
Also unexpected was the degree to which my hand drawn map matched the geometry of the railroad spur when I held it up to my computer screen - it was uncanny how accurate it was.
It only took three hours of intensive research, but through some historical mapping, geologic identification, geographic knowledge, and contextual interpretation it was possible to gather enough clues to resolve a train in the middle of a large desert. Of course, none of the individual parts can lead you there alone; it takes a common platform to make sense of all the data. In this case, all that it took was leveraging a free geospatial platform to find five train cars in a roughly 2500 mi2 area - a pretty decent feat considering that GIS was just a twinkle in someone's eye when the cars were placed there.
--
Urban Exploration is a hobby that has skyrocketed in popularity over the past 20 years in the United States. It is loosely defined as the discovery, infiltration, and exploration of areas traditionally deemed "off limits."
It is probably no mistake that the increase in popularity of Urban Exploration parallels the public's access to new and ever-improving geospatial data in the form of free services such as Google Maps. What started as a technical tool aimed at getting people from Point A to Point B, has raised awareness within the public of what comes between - in other words, the value of public geospatial data beyond driving directions. The discovery and exploration of abandoned places is, at its heart, a geospatial question that begs to be answered and addressed by datasets ranging from high-resolution imagery to census information.
These leaps in awareness and usership, however, have come at a price to Urban Exploration. Increased access to information about delicate abandoned buildings and the resulting traffic in and out has led to many negative consequences in the hobby. These consequences range from increases in security aimed at keeping explorers out of sites, to outright abuse and degradation of sacred historic buildings by vandals. To counteract this abuse, two unspoken rules obeyed by the community for sites not yet heavily trafficked have been established:
a) The exact location of the site must never be revealed
b) However, Clues leading serious and respectful explorers to the site can be given upon request, so long as some amount of work must be undertaken in order to find the site.
This being said, I hope that whoever chooses to read this article takes from it not a free shot at a really cool place, but an example of how using geographic knowledge in conjunction with free geospatial technology can help you find a virtual needle in a haystack. I also feel comfortable in sharing this since the location discussed is so remote that the effort it would take to reach would not be worthwhile for your average vandal.
Jake Reinig is a talented young photographer and explorer from San Diego, California. I was visiting his website when I came across some beautiful pictures of some double-decker passenger train cars left abandoned in a desert. Reinig, being a responsible explorer, spared only two descriptions in his explanation of the site: in the "Desert east of San Diego." I became so interested in the idea of several large passenger train cars being stranded in the middle of the desert that I decided to try and find them using Google Earth.
I encourage the reader to check out Jake's post that contains the images used to find the trains:
http://www.jakereinig.com/blog/?p=1901
In an initially naïve move, I figured that I could just "fly around" in Google Earth in the desert east of San Diego, and find the cars in the imagery. I soon realized however that this was a ridiculous and ineffective method.
In the last of the pictures on Reinig's post, there is a very distinct conical mountain in the background behind the railroad tracks. I opened up the Google Earth preferences and set the vertical exaggeration to 2/3 - this allowed me to try and match the feature that I was seeing with the digital elevation model that is loaded in Google Earth. Unfortunately, as I found out, there are many conical mountains in the desert east of San Diego. It only took about an hour of fruitless navigation to figure that out...
After the realization that trying to find a train car in 2500 mi2 of desert was literally like trying to find a needle in a haystack, I started to assemble more contextual clues and leverage geospatial information.
I started working under these assumptions:
Specified in Description
* Desert
* East of San Diego
Implied
* It's a railroad
Visually Interpreted Clues
* The trains are on a spur
* The spur likely ends after the train cars
* There is a smallish trestle over a river
It occurred to me that there may not be too many railroad lines running through the desert in that part of the world, so I googled "California Railroads." I cherry picked a very simple map of the all historical railroads in California courtesy of www.djcooley.com and zoomed in on Southern California:
The map reveals that there is only one railroad line that connects San Diego to the desert, and it cuts across the mountains east of San Diego and across the southern part of the Anza-Borrego Desert eastward to El Centro. I went on the assumption that the trains had to be located on a spur off of this railroad line, narrowing down the potential targets.
At that point, I began to interpret the pictures on Reinig's site a little more thoroughly.
Perhaps the single most important photograph to solving the secret is the second to last one, for two reasons:
a) It shows the fact that the trains are on a spur
b) More importantly, it reveals that the "main line" of tracks runs in a SE to NW fashion. I arrived at this crucial relationship when I noticed that the sun in that photograph is setting. Because the sun always sets in the West, and the main line is closer in the left of the frame than the right, it must have been constructed on a SE to NW trajectory.
Drawing this relationship out on paper gave me a map to compare with the imagery for the area, greatly improving the likelihood of finding the trains. But that's not all - the first picture clearly shows the spur ending after the trains. It also shows a bit of topography to the East of the trains as well as to the North.
Another crucial piece of evidence is revealed in the final picture, which shows the conical mountain. Because of the newfound contextual knowledge that the railroad tracks run SE to NW, it can be assumed that there is a considerably unique conical mountain to the South and East of the trains.
I added these new geographic clues to my list:
Geographic Clues
* Because the sun sets in the West, and this is clearly a sunset, the main rail line must run from the SE to the NW, with the spur roughly N/NE
* There is a very distinct conical mountain to the South of the Spur
* There is a small railroad trestle going over a stream
* One of the photos reveals that there is a hill to the SE of the trains as the photo is looking down on the trains
* There is a distinctive conical mountain to the SE of the site
I also began to look at Geologic clues. In the second-to-last picture, there is considerable vegetation - sagebrush and low-lying desert bushes. The density of cover is relatively high. The first picture shows there to be large sandstone outcroppings and boulders, uncharacteristic of a low desert. I also added these clues to my list:
Geologic Clues
* There are large smoothed sandstone outcrops in close proximity to the trains
* There is sand that has been blown over the tracks
* There is considerable vegetation and brush
* The end of the spur has a large rock outcrop
These new clues brought me back to El Centro. I suspect that it is called El Centro for a reason... To the east there is nothing but sandy flat areas without any distinct topography... This description definitely does not fit in with the land cover seen in the pictures, and is missing that crucial conical mountain feature to the southeast of the trains.
With these clues compiled, a significantly reduced search area began to take shape:
a) EAST of San Diego, in (or near) the desert
b) WEST of El Centro
c) NORTH of the Mexican Border (it's assumed to be in the United States)
d) SOUTH OF or DIRECTLY ON the only railroad that connects San Diego to El Centro.
This graphic shows the only possible places the site could be. The red line represents the railroad line drawn in from the California Railroads Map. The black box shows the West, South and East borders.
I also drew out the trajectory of the main line and spur that I figured out from the sunset picture:
Armed with the Hand Drawn Map showing the clues, I began following the railroad line west out of El Centro. The drawn map was invaluable as you could eliminate any section that didn't fit the 2 dimensional vectors of the SE-NW line. That is to say, there are an awful lot of sections that don't meet those criteria. Still, I was hung up on the location being on the Eastern edge of the mountain range...
I had isolated an area that met the description well - the tracks were SE-NW, there was a conical mountain in the SE, there was sand over the tracks, a small trestle over a stream and even an abandoned water tank - unfortunately there was no spur. I turned on the "Historical Imagery" toolbar and turned on previously acquired imagery but there was no evidence of a spur.
After that failure, I turned on the "Photos" layer in Google Earth and was surprised by how many images came up. Basically, users upload and "tag" the locations of their pictures to Google Earth's servers. These images are then added to a central database and made available through the "Photos" layer. In the area that I was focusing on, I found one tagged as "Carrizo Gorge Railway."
Without divulging any more information, within several minutes I was tracking the railroad line further west, hand drawn map in hand. When I finally found the site, I must admit that it was not as far from civilization as I had expected. It is actually the quiet neighbor to an, er, interesting type of ranch...
Also unexpected was the degree to which my hand drawn map matched the geometry of the railroad spur when I held it up to my computer screen - it was uncanny how accurate it was.
It only took three hours of intensive research, but through some historical mapping, geologic identification, geographic knowledge, and contextual interpretation it was possible to gather enough clues to resolve a train in the middle of a large desert. Of course, none of the individual parts can lead you there alone; it takes a common platform to make sense of all the data. In this case, all that it took was leveraging a free geospatial platform to find five train cars in a roughly 2500 mi2 area - a pretty decent feat considering that GIS was just a twinkle in someone's eye when the cars were placed there.
Sunday, August 28, 2011
Storm surge maps - is bad data worse than no data?
Due to Hurricane Irene, my esteemed university cancelled the first day of classes on Monday, thus postponing the first session of the course I am teaching, the GIS Practicum, until Wednesday. I thought I would use the time to generate a few slides showing the power of GIS during a crisis situation. I have quite a few family and friends in NYC and thus I was interested to see if they would be affected by the storm surge. What I found, after browsing three sources of storm surge data, were some massive inconsistencies. In one case in particular I felt the presence of poor storm surge data on the map was worse than having no data at all.
Let's start with Esri's US Tropical Storm Map. I like it, because it includes precipitation data with the storm map and it worked fairly well on my Xoom. The storm surge data, however, just doesn't pass the snuff test. A single grid cell covers many square kilometers leading one to believe that their area, nearly 20km inland, could be subjected to a 9ft storm surge. From the Esri map you can basically tell that areas near the ocean are subject to storm surge. Not in the least bit helpful.
Compare this to the work Steven Romalewski and his OASIS team put up. Clearly Steve and his team had access to localized, more authoritative data through the NY State Emergency Management Office. Unlike the data Esri is displaying, the surge models actually makes sense when you compare them to topographic and hydrographic data sets. I could zoom into areas where my friends and family live and find out if they were likely to be affected. Would I trust the Esri map for that? No way!
Finally, the National Hurricane Center has their map. The Google Crisis Response Center map using the same underlying data (the graphic below is from Google). The data appear to be more detailed that what Esri is serving up, but the coarseness of the grid once gain results in some unrealistic patterns in which small section of the shoreline are excluded.
First, all of these organizations should be commended for taking the time to make this data available, but I do wonder, if in this case, Esri in particular is undermining their credibility by serving up data that is at its best, uninformative and confusing, and at its worst, wrong. I would be grateful to hear your thoughts on this matter, particularly if you happen to be a storm surge modeling guru.
Let's start with Esri's US Tropical Storm Map. I like it, because it includes precipitation data with the storm map and it worked fairly well on my Xoom. The storm surge data, however, just doesn't pass the snuff test. A single grid cell covers many square kilometers leading one to believe that their area, nearly 20km inland, could be subjected to a 9ft storm surge. From the Esri map you can basically tell that areas near the ocean are subject to storm surge. Not in the least bit helpful.
First, all of these organizations should be commended for taking the time to make this data available, but I do wonder, if in this case, Esri in particular is undermining their credibility by serving up data that is at its best, uninformative and confusing, and at its worst, wrong. I would be grateful to hear your thoughts on this matter, particularly if you happen to be a storm surge modeling guru.
Sunday, July 24, 2011
Unmanned glider imaging - GoForce One
Below is a write-up from one of our recently graduated students, Bobby Sudekum. Bobby has worked for us in the Spatial Analysis Lab for over a year, doing everything from heads-up digitizing to LiDAR processing, to project management. With GoForce One Bobby combined his geopspatial expertise with his passions for planes, skiing, and photography. His work on GoForce One ended up winning him this year's ASPRS Central New York region student award. You can find out more about Bobby on his web site. He will likely be moving on from the SAL in the fall so if you are looking to hire a highly talented and motivated individual for your organization, Bobby might be the perfect fit.
--
Go Force One
Bobby Sudekum
When I was younger, I was always interested in aviation. I loved flying the wind up rubber band-powered balsa wood planes. I dreamt about owning an r/c plane but for some reason, but Santa never came though. Fast-forward 15 years to my introductory Remote Sensing class. Little did I know that when I signed up for this class, I would be participating in a service learning project centered around flying r/c planes equipped with cameras to learn more about Remote Sensing. I was ecstatic.
Fast-forward again to the fall of 2011. I am sitting in Economics of Public Policy, day dreaming about a mountain bike film in which they use a camera mounted on a zip line to achieve some stunning angles of mountain bikers. I began to wonder “How can I achieve the same effect with a skier, but with out the zip line?” I’m thinking, scratching my head, tapping my pencil...and then it dawns on me. Airplanes. I remember back to my Remote Sensing class. The planes we used were by no means powerful nor big, and the cameras also fared on the heavier side of things. After class, I immediately called my roommate who was an engineer. “Mike, think about this. Glider plus a GoPro (a small hd video camera) plus deep powder plus a skier.” There was a long pause followed by, “Bob, it’s a great idea but I don’t think it will fly, its just too heavy.” I was not convinced.
I began to look around the Internet for the largest foam glider I could find. I found one with a 54” wingspan for $9.95. I jumped on it, and bought two. The planes arrived and both of my engineering roommates shook their heads. I didn’t care. I knew, from the experience I had in my Remote Sensing class that it was possible. I chopped the nose off one of the planes and put a piece of Velcro on the camera and the nose. On a cold January morning, I threw the glider-camera combo off the balcony of a friend’s house. Not only did it fly, it flew better than anyone thought it would.
My roommates and I thought I had come up with a million dollar idea. We had this idea that we could capitalize on this new technology. For the next couple of months, we tested Go Force One (GoPro + Air Force One) in secrecy. Some of the footage we recovered from the plane was unbelievable, some of it was less than optimal. Halfway through the ski season, I sought for a mechanism to share my work with others. So I made a video with some of the footage and a little information about how it works. I thought that if people could build off of my idea, my plane could end up soaring longer and higher. Open source if you will. I have since then received a lot of good feedback from the video, and my eyes have been opened to many new ideas. I am glad I shared my idea with people.
Through trial and error we found what best worked for our UAV. We learned that it is designed to break, so we bought a decent amount of epoxy to glue it back together. We learned that you must throw it a lot to get the results we were looking for, because it flies where it wants to fly. Many people have asked me why I have not tried putting a motor and some controls on it. My answer is simple. It is a simple machine. It is something I can bring to the top of the mountain, through behind a skier, and not worry about it crashing into a tree. For now it is a simple machine, but in the near future I plan to move to more technical devises more specifically r/c planes.
This past semester, I enrolled in a special topics class, the focus of which was to apply object-based image analysis (OBIA) techniques to tackle real-world issues identified by non-governmental organizations through the Planet Action network. For my project I generated a 6 class land cover data set for the Sierra de las Cruces mountain range to the west of Mexico City, Mexico using Trimble’s eCognition Developer. The data will be used to monitor the depletion of forest cover over time.
At the end of the semester it occurred to me that OBIA techniques might be applicable to the images captured via Go Force One. Using a single frame from one of the flights as a test case I set out to see if it would be possible to classify the image like I did for my project in Mexico. Figure 1 shows the original frame used to classify the image.
The process began through the application of a multiresolution segmentation algorithm to aggregate pixels into image objects as seen in Figure 2.
Using a combination of spectral and spatial properties, the objects were then classified as either sky, tree, or snow. The results, which are rather impressive, can be seen in Figure 3.
The implications of this simple experiment are in my opinion outstanding and exciting. It is exciting because I think that small UAV like Go Force One, represent the future. Technology such as Go Force One, combined with OBIA techniques offers an end-to-end solution that is robust, transferable, and most importantly, affordable. Although we already have high-resolution spatial imagery of much of the earth, much of it is outdated and it is sometimes it is difficult to stay up to date. With a UAV, imagery could be gathered for a small city more often, or perhaps imagery could be gathered moments after a natural disaster to monitor damages.
Looking to future, I plan to continue to fly Go Force One, refine its design, and also move onto other aerial imagery projects. My next project is Go Force 2.0. Go Force 2.0 will be an r/c plane with a stronger camera capable of capturing sub-meter spatial imagery. I hope to team up with a seasoned pilot; he or she will fly it, I’ll do the camera and analysis work. My biggest plans though are to one day fly a UAV over a small town, gather imagery, and apply OBIA techniques to map land cover change over much more rapid time intervals than is typically possible. To find out more about Go Force One, and to see some of the shots, please go www.vimeo.com/bobbys/goforceone.
--
Go Force One
Bobby Sudekum
When I was younger, I was always interested in aviation. I loved flying the wind up rubber band-powered balsa wood planes. I dreamt about owning an r/c plane but for some reason, but Santa never came though. Fast-forward 15 years to my introductory Remote Sensing class. Little did I know that when I signed up for this class, I would be participating in a service learning project centered around flying r/c planes equipped with cameras to learn more about Remote Sensing. I was ecstatic.
Fast-forward again to the fall of 2011. I am sitting in Economics of Public Policy, day dreaming about a mountain bike film in which they use a camera mounted on a zip line to achieve some stunning angles of mountain bikers. I began to wonder “How can I achieve the same effect with a skier, but with out the zip line?” I’m thinking, scratching my head, tapping my pencil...and then it dawns on me. Airplanes. I remember back to my Remote Sensing class. The planes we used were by no means powerful nor big, and the cameras also fared on the heavier side of things. After class, I immediately called my roommate who was an engineer. “Mike, think about this. Glider plus a GoPro (a small hd video camera) plus deep powder plus a skier.” There was a long pause followed by, “Bob, it’s a great idea but I don’t think it will fly, its just too heavy.” I was not convinced.
I began to look around the Internet for the largest foam glider I could find. I found one with a 54” wingspan for $9.95. I jumped on it, and bought two. The planes arrived and both of my engineering roommates shook their heads. I didn’t care. I knew, from the experience I had in my Remote Sensing class that it was possible. I chopped the nose off one of the planes and put a piece of Velcro on the camera and the nose. On a cold January morning, I threw the glider-camera combo off the balcony of a friend’s house. Not only did it fly, it flew better than anyone thought it would.
My roommates and I thought I had come up with a million dollar idea. We had this idea that we could capitalize on this new technology. For the next couple of months, we tested Go Force One (GoPro + Air Force One) in secrecy. Some of the footage we recovered from the plane was unbelievable, some of it was less than optimal. Halfway through the ski season, I sought for a mechanism to share my work with others. So I made a video with some of the footage and a little information about how it works. I thought that if people could build off of my idea, my plane could end up soaring longer and higher. Open source if you will. I have since then received a lot of good feedback from the video, and my eyes have been opened to many new ideas. I am glad I shared my idea with people.
Through trial and error we found what best worked for our UAV. We learned that it is designed to break, so we bought a decent amount of epoxy to glue it back together. We learned that you must throw it a lot to get the results we were looking for, because it flies where it wants to fly. Many people have asked me why I have not tried putting a motor and some controls on it. My answer is simple. It is a simple machine. It is something I can bring to the top of the mountain, through behind a skier, and not worry about it crashing into a tree. For now it is a simple machine, but in the near future I plan to move to more technical devises more specifically r/c planes.
This past semester, I enrolled in a special topics class, the focus of which was to apply object-based image analysis (OBIA) techniques to tackle real-world issues identified by non-governmental organizations through the Planet Action network. For my project I generated a 6 class land cover data set for the Sierra de las Cruces mountain range to the west of Mexico City, Mexico using Trimble’s eCognition Developer. The data will be used to monitor the depletion of forest cover over time.
At the end of the semester it occurred to me that OBIA techniques might be applicable to the images captured via Go Force One. Using a single frame from one of the flights as a test case I set out to see if it would be possible to classify the image like I did for my project in Mexico. Figure 1 shows the original frame used to classify the image.
The process began through the application of a multiresolution segmentation algorithm to aggregate pixels into image objects as seen in Figure 2.
Using a combination of spectral and spatial properties, the objects were then classified as either sky, tree, or snow. The results, which are rather impressive, can be seen in Figure 3.
The implications of this simple experiment are in my opinion outstanding and exciting. It is exciting because I think that small UAV like Go Force One, represent the future. Technology such as Go Force One, combined with OBIA techniques offers an end-to-end solution that is robust, transferable, and most importantly, affordable. Although we already have high-resolution spatial imagery of much of the earth, much of it is outdated and it is sometimes it is difficult to stay up to date. With a UAV, imagery could be gathered for a small city more often, or perhaps imagery could be gathered moments after a natural disaster to monitor damages.
Looking to future, I plan to continue to fly Go Force One, refine its design, and also move onto other aerial imagery projects. My next project is Go Force 2.0. Go Force 2.0 will be an r/c plane with a stronger camera capable of capturing sub-meter spatial imagery. I hope to team up with a seasoned pilot; he or she will fly it, I’ll do the camera and analysis work. My biggest plans though are to one day fly a UAV over a small town, gather imagery, and apply OBIA techniques to map land cover change over much more rapid time intervals than is typically possible. To find out more about Go Force One, and to see some of the shots, please go www.vimeo.com/bobbys/goforceone.
Thursday, May 19, 2011
Digitizing the Wacom Way
A key component of our land cover mapping is manual quality control. We accomplish this though the application of "heads-up" digitizing techniques within ArcGIS. A single project can often require tens of thousands of manual corrections made for a given project. With so many edits even a minor improvement in per-polygon digitizing speed can yield huge gains.
We were intrigued by the possibility of using a pen-driven interactive display to perform manual corrections because most people have extensive experience drawing with pens, and are familiar and precise with their control. This allows the end user to draw their edits in a natural fashion directly on a digital map. We contacted the folks at Wacom who were kind enough to ship us their DTU-2231 to test in our production environment.
The DTU-2231 has 22” screen, which is bright and crisp. There is a power button that switches the display on and off, and a display menu similar to what you would see on a standard monitor (brightness, contrast, screen position, etc.). Also included is a stylus pen that can be stored behind the monitor in a recessed holster when not in use. The stylus is the size of a standard pen, and has three buttons: two buttons near the point and one button on the end. The end button is similar to an eraser on a pencil. The display ships with software that allows for customization of the buttons, sensitivity of the screen, and different profiles for different software installed on the computer.
In terms of the Wacom Tablet’s application in GIS Editing, several key advantages surfaced:
For our needs at the SAL, the Wacom Tablet represents a time effective tool for editing single data type vector datasets (i.e. editing a vector layer solely composed of polygons representing tree canopy). The editing process is fast, precise and natural. We ended up purchasing the DTU-2231 and will likely purchase another one this summer.
We were intrigued by the possibility of using a pen-driven interactive display to perform manual corrections because most people have extensive experience drawing with pens, and are familiar and precise with their control. This allows the end user to draw their edits in a natural fashion directly on a digital map. We contacted the folks at Wacom who were kind enough to ship us their DTU-2231 to test in our production environment.
In terms of the Wacom Tablet’s application in GIS Editing, several key advantages surfaced:
- The tablet allows for a standard mouse to be connected, allowing the user to switch between the fast pen for editing and more “computer friendly” mouse for doing other things.
- The software allows the user to enter custom “keystrokes” for the buttons. In the “customize mode” window of ArcGIS, the user is able to enter “shortcuts” for the editing tools. In our case, we have assigned “e” to switch to the feature selector tool, “c” to switch to the pan tool, and “{alt} + s” to save edits. After assigning these shortcuts in ArcGIS, we assigned the stylus buttons to match: The “eraser” button is assigned to “save edits,” the primary button is assigned to “feature select,” and the secondary button is assigned to “pan.” In assigning these shortcuts to the different buttons on the pen, we can easily create a feature, select a feature (to delete or reshape), pan the map and save our edits without ever having to move the mouse around the screen – all of these functions take place right on the stylus.
- Edits are fast and precise
- When editing attribute changes need to be made, the pen can actually slow things down. A mouse is the most effective way to change a feature’s attributes since there is inevitably a lot of clicking that goes on.
- The editing templates in ArcGIS 10 can “confuse” the pen and the custom buttons will no longer work. In ArcGIS 10’s editing templates, the user “preselects” the attributes for the polygon before going to create it. This creates a problem as the user must constantly be predefining the attributes before drawing. This problem can be fixed however by turning off the “create features using templates” in the “ArcMap Advanced Settings Utility.”
- Another potential problem that we ran into occurs when individual users change the customized settings for their own purposes each session. Deciding on customized buttons is something that should be done as a group, as having to redefine the buttons every session can take 15 minutes to complete. That is of course a human resource problem as opposed to a Wacom problem.
For our needs at the SAL, the Wacom Tablet represents a time effective tool for editing single data type vector datasets (i.e. editing a vector layer solely composed of polygons representing tree canopy). The editing process is fast, precise and natural. We ended up purchasing the DTU-2231 and will likely purchase another one this summer.
Sunday, May 8, 2011
GeoNet - Channel Extraction from LiDAR
This post is a summary of one of our graduate students, Terry Barrett, who did some excellent work getting GeoNet to run on a sizable (billions of points) LiDAR dataset.
---
GeoNet is an open-source Matlab code for stream-channel extraction of high resolution digital elevation data, developed by Passalacqua et al. at the National Center for Earth-Surface Dynamics at the University of Minnesota. With the release of version 1.0.1 last September, the code has matured enough to be capable of adaptation to production use. One of our projects had need of stream-channel extraction for its one billion point, one meter resolution LiDAR DEM, and I was assigned the task of scaling up GeoNet and producing the stream-channel network for the study watershed.
GeoNet is designed to extract the channel network for a single watershed of maximum extent of about 2000x2000 elevation points, which it can do in a reasonable time (a few minutes) if the code is compiled. When I began using GeoNet v.1.0.1, there were no compiled versions offered for Windows operating systems, but I was able to compile it for both 32 and 64-bit using the C++ compiler included in Visual Studio 2010.
Development of the production code was done using a 3.75x3.75km subset of the watershed DEM, which produced a code that can: tile a geotiff raster into buffered tiles, sized for GeoNet; process those tiles through GeoNet to determine the channel network; trim the resulting channel-network shapefile tiles to the original tile dimensions; and connect the tiled-channel shapefiles with channels that conform to stream-flow logic.
Here is the output on the subset DEM (runtime on a 32-bit machine was about two hours; the blue dots are the connecting channel locations):
Here are some representative channel connection locations from that run that show the robustness of the connection logic (green lines are trimmed-tile channels, red dots are identified channel ends, and blue lines are the channels added to provide logical connections; tile boundaries are shown as dashed lines):
The logic correctly connected the nearest independent channel ends for all locations except one, and the code was fast enough for the available time on the production machine, and so it was then used to run the entire watershed DEM.
Here is the output for the entire watershed (run in two halves, in parallel, on a 64-bit machine; runtime ~ 36 hours):
---
GeoNet is an open-source Matlab code for stream-channel extraction of high resolution digital elevation data, developed by Passalacqua et al. at the National Center for Earth-Surface Dynamics at the University of Minnesota. With the release of version 1.0.1 last September, the code has matured enough to be capable of adaptation to production use. One of our projects had need of stream-channel extraction for its one billion point, one meter resolution LiDAR DEM, and I was assigned the task of scaling up GeoNet and producing the stream-channel network for the study watershed.
GeoNet is designed to extract the channel network for a single watershed of maximum extent of about 2000x2000 elevation points, which it can do in a reasonable time (a few minutes) if the code is compiled. When I began using GeoNet v.1.0.1, there were no compiled versions offered for Windows operating systems, but I was able to compile it for both 32 and 64-bit using the C++ compiler included in Visual Studio 2010.
Development of the production code was done using a 3.75x3.75km subset of the watershed DEM, which produced a code that can: tile a geotiff raster into buffered tiles, sized for GeoNet; process those tiles through GeoNet to determine the channel network; trim the resulting channel-network shapefile tiles to the original tile dimensions; and connect the tiled-channel shapefiles with channels that conform to stream-flow logic.
Here is the output on the subset DEM (runtime on a 32-bit machine was about two hours; the blue dots are the connecting channel locations):
Here is the output for the entire watershed (run in two halves, in parallel, on a 64-bit machine; runtime ~ 36 hours):
The connector channels:
There are three reasons why the channel network has a few holes and doesn’t go to the edge of the DEM:
1) GeoNet’s curvature calculation fails on tiles with more than about 20% missing data, which affected both the edge of the DEM and some interior areas with missing data.
2) A few tiles crashed the Dinf mexfile (which calculates contributing area); I examined the tiles, and could find no significant differences between them and nearby tiles that did not crash.
3) A few channel shapefile tiles (all lowland areas, possibly covered by water) crashed the connecting code; they were about 3X the size of the next largest files, and so generated overly-large connection matrices.
The project was successful, insofar as it produced an automatically generated shapefile network over most of the watershed, but there are areas for further improvement and development:
The project was successful, insofar as it produced an automatically generated shapefile network over most of the watershed, but there are areas for further improvement and development:
1) Prevent holes in the network – by debugging/improving the areas of code mentioned above; using a watershed DEM with a larger buffer (perhaps 2km instead of the 10m that the watershed DEM currently has); and/or performing the tiling with another program, such as ERDAS IMAGINE (I modified some share-code, geotiffwrite, to write the geotiff tiles; may still have some bugs).
2) Validate and calibrate the channel network through comparison to networks generated by other methods (manual and automatic) and to ortho-photos of the watershed. Both GeoNet and my production code have a number of input parameters (all kept at default settings in the above analysis), and my preliminary investigations into the sensitivity of the channel network to changes in these parameters suggest that there is a lot of room for optimization.
3) Further improve the connecting-channel logic – the subset DEM used for development still had one location where the logic produced an unnecessary connection channel (this location has overlapping independent channels on the stitching boundary), and there are areas where unnatural stream loops are created.
4) The final step required to create a channel network most useful for further geoprocessing requires that the connection channels and the tile channels be merged into a single network of poly lines that properly conforms to sub-watershed regions. This may require “smart” tiling, with considerably more overlap (and processing time) than used by the current production method.
Thursday, May 5, 2011
ASPRS 2011 Roundup
If there was one theme from this year's ASRPS 2011 conference it was death by PowerPoint. I'm no Steve Jobs when it comes to presentations, but I know enough to not make it miserable for the audience. The graduate students in my GIS Practicum class deliver far superior presentations than many of the seasoned faculty at ASPRS 2011. Slides with endless bullet points, more formulas on a single slide than a person could read in 20 minutes, tiny graphics, the list goes on. This would be bad enough, but for a geospatial society you would think members would realize the value of a good picture. Compared to the quality of the presentations at the urban forestry conferences I have been going to, the ASPRS sessions were, for the most part, a massive disappointment.
That being said there were a number of top-notch presentations. I particularly enjoyed the session I moderated on "using multiple data sources." Tommy Jordan and his team at CRMS are doing fantastic work training the next generation of geospatial professionals by integrating undergraduate students into the production workflow for a recent LiDAR and imagery collect. Although the sensors and techniques we used are wildly different, I learned a lot from Ken Stumpf's work on land cover mapping in Alaska. Ken is with Geographic Resource Solutions. I am glad I stuck around for the final LiDAR session as two grad students, Colin Gleason from SUNY ESF, and David Kelbe from RIT, gave presentations that were filled with useful information and fantastic graphics. I attended the AmericaView session, and although I had seen much of the work before it was still inspiring.
Paul Ramsey gave a brilliant opening keynote on open source software. He did not pull any punches in going after Esri et al. I think all of us left his presentation questioning why we ever purchased commercial software. The problem with open source - they don't have the money to sponsor conferences like ASPRS.
Episode 4 of the Geospatial Revolution project premiered on day 1. Impressive is an understatement. It left me proud to be part of this profession and yet humbled by the great things others are doing. The theme of the conference was "Ride of the Geospatial Revolution," but I cannot help if ASPRS might soon find itself drowning in the location-based geospatial tidal wave. The largest booth in the exhibitor was Microsoft. That's right, the same people that sell Office were showing off their remote sensing capabilities. Who would have predicted that five years ago? I can't help but wonder what will happen to all of these companies whose business model is to sell imagery. Why, in these difficult economic times would an organization pay vast sums of money when Microsoft or Google will provide them with the data for free or at a much lower cost. No doubt there will always be the need for mapping companies, but the Bing Maps Global Ortho Project is going to change the remote sensing landscape.
Although the presentations were largely a let down I thoroughly enjoyed the Hot Topics session on the challenges involved in breaking the 85% accuracy barrier. Joe Knight from UMN was an amazing moderator. Chuck Olson, a man whose work on the elements of image interpretation serves as the basis for everything we do was in attendance. He offers a fantastic perspective from decades of experience, but it was disappointing to hear him say that all automated techniques rely solely on spectral information. WRONG, WRONG, WRONG. More than a few folks, us included, are using object-based approaches to incorporate spectral and spatial information into an automated process. Just check out Infoterra's work for proof.
Although Paul Ramsey's talk made me want to check out PostGIS, the proprietary vendors are doing some awesome work. I got a preview of the enhancements coming in the next release of eCognition. Amazing! The transition to Trimble has not slowed things down one bit and eCognition continues to redefine what is possible in terms of image analysis. Had some great conversations with teams from MDA, Trimble Geospatial, and ERDAS.
Keith Pelletier and I ran an Object-Based Image Analysis workshop on Monday. Over 30 people attended, and it was a lot of fun. I learned a lot from their questions and I hope they learned a lot too. Thanks to all of you who attended. I hope you will stay in touch.
You can check out all of the Tweets from ASPRS 2011 at #asprs11a. A lot of the tweets are me complaining about the presentation, sorry, but someone has to speak up.
Will I go next year - maybe. ASPRS really needs to post some guidelines to the presenters or better yet, make them all watch Death by PowerPoint the night before. Scientific presentations can be enjoyable.
That being said there were a number of top-notch presentations. I particularly enjoyed the session I moderated on "using multiple data sources." Tommy Jordan and his team at CRMS are doing fantastic work training the next generation of geospatial professionals by integrating undergraduate students into the production workflow for a recent LiDAR and imagery collect. Although the sensors and techniques we used are wildly different, I learned a lot from Ken Stumpf's work on land cover mapping in Alaska. Ken is with Geographic Resource Solutions. I am glad I stuck around for the final LiDAR session as two grad students, Colin Gleason from SUNY ESF, and David Kelbe from RIT, gave presentations that were filled with useful information and fantastic graphics. I attended the AmericaView session, and although I had seen much of the work before it was still inspiring.
Paul Ramsey gave a brilliant opening keynote on open source software. He did not pull any punches in going after Esri et al. I think all of us left his presentation questioning why we ever purchased commercial software. The problem with open source - they don't have the money to sponsor conferences like ASPRS.
Episode 4 of the Geospatial Revolution project premiered on day 1. Impressive is an understatement. It left me proud to be part of this profession and yet humbled by the great things others are doing. The theme of the conference was "Ride of the Geospatial Revolution," but I cannot help if ASPRS might soon find itself drowning in the location-based geospatial tidal wave. The largest booth in the exhibitor was Microsoft. That's right, the same people that sell Office were showing off their remote sensing capabilities. Who would have predicted that five years ago? I can't help but wonder what will happen to all of these companies whose business model is to sell imagery. Why, in these difficult economic times would an organization pay vast sums of money when Microsoft or Google will provide them with the data for free or at a much lower cost. No doubt there will always be the need for mapping companies, but the Bing Maps Global Ortho Project is going to change the remote sensing landscape.
Although the presentations were largely a let down I thoroughly enjoyed the Hot Topics session on the challenges involved in breaking the 85% accuracy barrier. Joe Knight from UMN was an amazing moderator. Chuck Olson, a man whose work on the elements of image interpretation serves as the basis for everything we do was in attendance. He offers a fantastic perspective from decades of experience, but it was disappointing to hear him say that all automated techniques rely solely on spectral information. WRONG, WRONG, WRONG. More than a few folks, us included, are using object-based approaches to incorporate spectral and spatial information into an automated process. Just check out Infoterra's work for proof.
Although Paul Ramsey's talk made me want to check out PostGIS, the proprietary vendors are doing some awesome work. I got a preview of the enhancements coming in the next release of eCognition. Amazing! The transition to Trimble has not slowed things down one bit and eCognition continues to redefine what is possible in terms of image analysis. Had some great conversations with teams from MDA, Trimble Geospatial, and ERDAS.
Keith Pelletier and I ran an Object-Based Image Analysis workshop on Monday. Over 30 people attended, and it was a lot of fun. I learned a lot from their questions and I hope they learned a lot too. Thanks to all of you who attended. I hope you will stay in touch.
You can check out all of the Tweets from ASPRS 2011 at #asprs11a. A lot of the tweets are me complaining about the presentation, sorry, but someone has to speak up.
Will I go next year - maybe. ASPRS really needs to post some guidelines to the presenters or better yet, make them all watch Death by PowerPoint the night before. Scientific presentations can be enjoyable.
Subscribe to:
Posts (Atom)