Re: [GRASS-user] r3.in.xyz

[Moritz Lennert]

On 27/06/18 03:59, Francois Chartier wrote:

Hi,

I am working with a data set that consists of borehole logs with a Top 
of a layer (layer 1) and the top of the underlying layer (layer 2) 
(which is also the bottom of the overlying layer 1).  Everything in 
between the elevation of top of layer 1 and top of layer 2 correspond to 
a Layer 1 property.


The thickness of Layer 1 varies and this layer may not exist everywhere 
(pinches out).  Above the Layer the property is different; in other 
words the property only starts below the Top of layer 1 until the 
underlying Top of the next layer.
Not sure of the capabilities of the interpolation in Grass and working 
with a very large data set (i cannot link every top of layers together), 
my first approach was to create a each Layer property for every 
elevation slice along each Borehole axis, interpolating soil properties 
at every elevation between Boreholes.


I read on another forum that r3.in.xyz  can 
interpolate in 3D without a Property at every elevation slice,


  * while respecting the condition that above the Top of the layer 2,
the property corresponds to the Overlying top layer 1, and
  * that the property is continuous until the next underlying layer 3 -
can someone confirm this?

To provide a bit of background, borehole data bases, identify the top of 
layer as encountered when drilling downwards, and provide the elevation 
of the next layer (pick); in between the soil property is the same, 
however there is no data points.  When interpolating, while there is no 
data point in between the two geological picks, the property should 
still have weight in the interpolation process.




I don't think r3.in.xyz is what you need. This module aggregates 3D 
point data into voxels.


You probably want to use something like r.to.rast3. This would mean 
interpolating each layer separately into 2D elevation maps and then 
assemble them into 3D using r.to.rast3.


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r3.in.xyz

[Francois Chartier]

Hi,

I am working with a data set that consists of borehole logs with a Top of a
layer (layer 1) and the top of the underlying layer (layer 2) (which is
also the bottom of the overlying layer 1).  Everything in between the
elevation of top of layer 1 and top of layer 2 correspond to a Layer 1
property.

The thickness of Layer 1 varies and this layer may not exist everywhere
(pinches out).  Above the Layer the property is different; in other words
the property only starts below the Top of layer 1 until the underlying Top
of the next layer.
Not sure of the capabilities of the interpolation in Grass and working with
a very large data set (i cannot link every top of layers together), my
first approach was to create a each Layer property for every elevation
slice along each Borehole axis, interpolating soil properties at every
elevation between Boreholes.

I read on another forum that r3.in.xyz can interpolate in 3D without a
Property at every elevation slice,

   - while respecting the condition that above the Top of the layer 2, the
   property corresponds to the Overlying top layer 1, and
   - that the property is continuous until the next underlying layer 3 -
   can someone confirm this?

To provide a bit of background, borehole data bases, identify the top of
layer as encountered when drilling downwards, and provide the elevation of
the next layer (pick); in between the soil property is the same, however
there is no data points.  When interpolating, while there is no data point
in between the two geological picks, the property should still have weight
in the interpolation process.

Thank You
Francois
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] 7.5svn: issue with finding EPSG codes for new locations

[Rich Shepard]

  Trying to select an EPSG code for a new location (2838) in both
/usr/share/proj/epsg and /usr/share/proj/esri. Using the GUI, the default
'path to the EPSG-code file' is /usr/share/epsg. When I click the browse
button to select that an error box displays:

"Unable to read EPGS codes: invalid literal for int() with base 10:
'metadata'"

  And, entering the EPSG code, 2838, in that widget does nothing because no
button is active to accept it.

  What is the error message telling me about what to do?

Rich


___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Markus Metz]

On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris 
wrote:
>
> * Markus Metz  [2018-06-25 08:29:45 +0200]:
>
> [..]
>
>> The resolution is a bit wrong, it is 0.0083330 but should be
>> 0.008, i.e. exactly 30 arc-seconds. This can be solved with
the
>> -a flag of r.in.gdal, or after import with r.region -a.
>>
>> The message
>>
>>> 360 degree EW extent is exceeded by 0.999827 cells
>>
>>
>> will change to
>>
>>> 360 degree EW extent is exceeded by 1 cells
>>
>>
>> but will not go away, because 360 degree EW extent is exceeded in the
input
>> data, the first and last column cover the same geographical area. You can
>> change your current region to chop of e.g. the first column: set the
region
>> to the raster, then modify the current region with g.region w=179:59:45W
-p
>> and use this region for further processing.
>
>
> I guess this is worth being documented in the manual of the add-on.

This is a universal problem applying to various raster data in latlong. The
first issue, 30 sec represented as 0.0083330 instead of
0.008 is solved by r.in.gdal -a. The second problem, this extra
column responsible that 360 degree EW extent is exceeded by 1 cell can be
solved by setting the current region accordingly. This is also a universal
problem. Maybe the manual of r.in.gdal could include a hint about how to do
this. Generally, users are encouraged to inspect the output of r.info after
importing raster data to check if everything is as expected.

> Would
> it also make sense to let the module attempt to perform this "correction"?

If you refer to i.nightlights.intercalibration, I would say no, because it
is a more general issue not restricted to DMSP-OLS nightlight data. Even
more general, the current region as set by the user is used for raster
processing (with a very few exceptions).

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Nikos Alexandris]

* Markus Metz  [2018-06-25 08:29:45 +0200]:

[..]


The resolution is a bit wrong, it is 0.0083330 but should be
0.008, i.e. exactly 30 arc-seconds. This can be solved with the
-a flag of r.in.gdal, or after import with r.region -a.

The message


360 degree EW extent is exceeded by 0.999827 cells


will change to


360 degree EW extent is exceeded by 1 cells


but will not go away, because 360 degree EW extent is exceeded in the input
data, the first and last column cover the same geographical area. You can
change your current region to chop of e.g. the first column: set the region
to the raster, then modify the current region with g.region w=179:59:45W -p
and use this region for further processing.


I guess this is worth being documented in the manual of the add-on. Would
it also make sense to let the module attempt to perform this "correction"?

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user