[GRASS-dev] GSOC wk1 checkin
Pierre Roudier
pierre.roudier at gmail.com
Sun Jun 23 03:15:26 PDT 2013
Hi Tim, Hamish et al.,
Just jumping in the discussion, FYI: I am following the project with
much attention, in particular because I am working with soil data,
both at the national scale in NZ, but also on international project
that aim at storing important amounts of data [www.globalsoilmap.net].
The soil science community has recognised the difficulty to deal with
the storage of soil horizon data, and a specific working group has
been formed under the auspices of the International Union of Soil
Sciences [www.soilinformationstandards.org/content/about].
We've already been developing data models for storing soil data, I'd
be happy to point you towards these if that is of interest for your
project.
Tim, all the best for your summer project,
Hamish, hang on tight for this cold winter blast!
Talk soon,
Pierre
2013/6/23 Hamish <hamish_b at yahoo.com>:
> Hi Tim, glad to see you're underway.
>
> is it possible to post some data samples on your project's blog? (a description + figure would be great) It would help to get a better idea of what the import options would be for those three datasets. What form is the Natural Resources Conservation Service survey data in?
> If you like/need I can poke around here for some more datasets.
>
>> My work product next week is going to focus on the interpolation
>> module. The abstract workflow for the module as whole is as follows
>>
>> Process for generation of r3 voxel grid from a population of xy
>> located 1 dimensional horizon descriptions
>> 1. Import of database horizon descriptions
>> 2. Generation of line vector representing the path of the horizon
>> description in xyz
>
> note that GRASS vector lines can not store per-vertex attribute data,
> only per-line attribute data. Anything else must be stored as points;
> see the v.in.gps module. one idea is to trick the vector engine into storing depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the results at the last step when you need real earth-coord x,y,z.
> ?
>
>> 3. Segmentation of the line vector into n number xyz points
>
> so binning by depth segment?
>
>> 4. query of attribute values to points from attribute database
>> 5. Generation of r3 region
>> 6. Interpolation of point attribute values through geostatistical
>> and/or logical operators onto voxel grid locations
>
> wrt to single x,y location well log, it seems to me like the r3.in.xyz
> module already gives you most of that, bypassing the vector line stage
> completely. binning 3D data into voxels using univariate statistics is precisely what it does.
>
> are you looking to interpolate/aggregate vertically first, then
> horizontally? would you interpolate at each depth band separately
> then combine those together?
>
> how well does that work with dipping angles? perhaps v.vol.rst could help too, to interpolate everything at once in a more 3D-influenced model?
>
>> One point that Ben articulated was that the interpolation assignment
>> needs to be capable of operating on integer data so that it can work
>> on
>
> that got cut off, but I guess you mean categorical value, so nearest
> neighbour is needed, and not linear, cubic, or spline.
>
>> Best wishes on this first day of summer.
>
> Up to my knees in snow yesterday, but good mountain boots and funner than the rain and sleet that was falling down in the valley. :)
>
>
> regards,
> Hamish
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Scientist
Landcare Research, New Zealand
More information about the grass-dev
mailing list