Archive for March, 2015
Posted by smathermather on March 13, 2015
Posted by smathermather on March 7, 2015
NCGIS was an excellent conference, and this year was my first attending / presenting. Bravo to the organizers, who themed it Mobile and Global, but confessed that Mobile, Global, Open would have been more apropos.
To catch screen captures and audio for the presentations, see this temporary location:
which is organized by room numbers, so check out the schedule: http://ncgisconference.com/#schedule .
My favorite new ideas from the conference, aside from talks by Randale Hale, Howard Butler, and Paul Ramsey were local to NC State University, with Helena Mitasova from the Open Source Geospatial Research and Education Laboratory.
See especially their Tangible Landscape which ties a sandbox in to real-time GRASS DEM processing (flow accumulation, viewsheds, fire modeling, etc.):
Posted by smathermather on March 6, 2015
Thanks to some brilliant work by our Interpretive Technology Technician, we now have a little video for FOSS4GNA on OpenDroneMap. Come see my presentation next week in San Francisco, Weds. at 13:30 (1:30PM):
Posted by smathermather on March 1, 2015
So much documentation to catch up on for OpenDroneMap. Probably the most important missing element is documenting the ground control point file format. This will be a file name gcp_list.txt to be placed in the root of the image directory that you are processing.
The ground control point file associates locations in the input raw images with geographic positions, allowing for the output of an orthophoto and georeferenced mesh. It can augment or replace the need for geographic coordinates in the exif headers of the input images.
I mention this file briefly in a previous post, but let’s get into the weeds a bit on how to create one. The format is a simple text file. The header, or first line, is a descriptor of the coordinate system. This is not a formal thing, so don’t worry about format for this line.
The subsequent lines contain the x, y, and z of the ground control location in your local coordinate system, the pixel and line number of the location in the image, and the imagename itself. A minimum of 3 GCPs is necessary:
x y z pixelx pixely imagename
So, for example, if I mock up a version for the Langley dataset, I get something like this:
WGS84 UTM 10N 544256.7 5320919.9 5 3044 2622 IMG_0525.jpg 544157.7 5320899.2 5 4193 1552 IMG_0585.jpg 544033.4 5320876.0 5 1606 2763 IMG_0690.jpg
Note that my elevations are all the same. I was lazy, and assumed that there’s minimal topography and Langley, and that we are 5 meters above sea level. It is far better to put real values here, derived from an elevation dataset.
More on the how:
So, how to get these numbers? I loaded my raw unprocessed jpegs into QGIS. As I mouse over the image, it gives me coordinates, like “3044 -2622”. These are pixel values. I ignore the sign on the Y value.
For the X and Y values, I just used a Leaflet slippy map with a lat/lon pop-up: http://smathermather.github.io/leaflet-test/index.html. It would be better if I had GPS values from the field (preferably map grade) or survey values, but this quick and dirty adaptation of http://leafletjs.com/examples/quick-start.html will at least get my map in the correct part of the world. I plugged the lat/lon values I get into Montana State’s UTM converter, though this is a slow method if I am doing a lot of points.
Finally, I save my text file as gcp_list.txt, save it in the directory that contains my raw images, and run the run.pl script, and sit back and get some coffee. Output will be a subdirectory with a name similar to reconstruction-with-image-size-2400-results.
And now I’ve added this to the wiki: https://github.com/OpenDroneMap/OpenDroneMap/wiki/Running-OpenDroneMap