On Mon, Jun 24, 2013 at 10:25 AM, Tim Bailey <[email protected]> wrote:
> Hi Pierre, and Hamish > It is nice to hear about the onset of Winter in New Zealand. Here in > California we are looking at the beginning of a severe season of drought. > > Hi Tim, nice to see another person from CA on the grass-dev list! > Clearly the problem of geographic representation of soil properties are > quite challenging. The US NRCS distributes soil datasets most often as > ArcSDE tables. Not to pander but from my perspective the state of the art > tie in with the nrcs data comes from the recent paper Algorithms for > quantitative pedology: A toolkit for soil scientists Computers & > Geosciences 52 (2013) 258–268. I now realize that you Pierre are a > coauthor of the article. Nice work by the way. In particular the > SoilProfileCollection object specifications are spot on in my opinion. To > paraphrase, the minimal horizon description of unique id, top depth, bottom > depth, linked to attribute any vertical interval attribute data. > > Totally agree, the NRCS has not done a good job of releasing data in open formats. I am working on changing that, but it might take a while. Efforts like this SoC project are one more way in which soils/geologic data can be opened to a larger audience. Glad to hear you liked the Comp & and GeoSci. article, please do comment/critique as issues arise. > I am just a novice with R but it occurs to me that the soilDB and AQP R > modules might be the best way to generate input point vectors. One > capability that I think is particularly useful is the slicing and > resampling of the vertical profile. For my current purposes, any attributes > of interest from these databases needs to be linked to a point vector as an > intermediary step towards being rendered by voxels. In the specific case > of categorical data, I am working with the data assumption that the > attributes will be assigned to a point vector located at the bottom of the > interval. > > Historically soil inventory profiles have usually been a bit sloppy with > locating elevation absolutely. All of the depth measurements were recorded > in relative terms to the surface. Would it be possible to deal with high > resolution z coordinates in a manner that was relational in the same way > that soil profiles are collected. The reason I ask is that I worry about > the amount of data required to tile voxels has the potential to grow > inordinately. 10 cm is a pretty rough vertical resolution for soils > purposes, but if you have to populate voxels for a field area that has 100 > meters of elevation it could get overwhelming. The other route I am > seeing is to create a mask from a digital elevation model to constrain the > region to voxels near the surface elevation. All of the workspaces I am > developing as examples for this project are areas where I have lidar > coverage to pin the depth intervals to a high resolution elevation datum. > > I have often wondered about the scale issue you bring up. 1cm precision in the vertical vs. 10m precision in the horizontal is often a good compromise for soils/landscapes in the western US. This would result in some pretty funny looking voxels-- more like waffles. A decent mask and tools for rapid development of a mask would be essential. > Away from soils field I have found some interesting issues in the data > practices. In the geotechnical boreholes the sampling intervals are not > always continuous, and they are specific. Also the reason why I have put in > a line vector in my process is that the vertical assumptions will not > always be met by the data. It occurs to me that a future iteration of this > module is going to want to use dynamic segmentation in order to render data > from boreholes that are not vertical and are only as straight as the the > borehole that is drilled. Also I hear that horizontal drilling is becoming > a very big deal in the energy sector and I can only imagine that > groundwater prospecting is going to follow. > > Also during the project review period Hamish mentioned an interest in > Seismic line interpolation. At the time I worried that a digression into > applied geophysics might be a dangerous distraction but I have subsequently > worked up a workflow for the processing of p-wave first arrivals. I am > suppressing any thought of any signal that is not a first arrival, but I > think that I can make it work within a day. I am going to the library this > afternoon to look into this some more. > > Tim > > Again, glad to see someone working on this issue and always happy to offer insight from the soils/NRCS perspective. Cheers, Dylan PS: I have cc-ed my "work" email address, as I don't always check my gmail account. > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
