Re: [GRASS-dev] r.stats.quantile: does the 50th percentile equal to the median?

[nik]

Thank you Markus!

---

On 2021-01-23 21:20, Markus Metz wrote:


On Fri, Jan 22, 2021 at 2:51 PM  wrote:


Hi devs,

does the default `percentiles=50` in `r.stats.quantile` equal to the
median?
Is the definition exclusive or inclusive?


The median is commonly defined as the 50% percentile, the "middle" item of a 
sorted dataset. See
https://en.wikipedia.org/wiki/Median

In GRASS, calculations of the median and the 50% percentile are identical. 

HTH, 

Markus M 




Thank you for any insight, Nikos
--

See also
- https://en.wikipedia.org/wiki/Percentile
- https://math.stackexchange.com/q/2048470/445399

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

[GRASS-dev] r.stats.quantile: does the 50th percentile equal to the median?

[nik]

Hi devs,

does the default `percentiles=50` in `r.stats.quantile` equal to the 
median?

Is the definition exclusive or inclusive?

Thank you for any insight, Nikos
--

See also
- https://en.wikipedia.org/wiki/Percentile
- https://math.stackexchange.com/q/2048470/445399

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

[GRASS-dev] Render related environment variables and vector maps

[nik]

Dear 'GRASS_RENDER'-experts,

I use custom functions to render several raster maps on the same output 
image file (always in the Terminology terminal):

```
# draw a raster map using `tyraster`
function tyraster {
# new frame, new file
unset GRASS_RENDER_FRAME
unset GRASS_RENDER_FILE_READ
export GRASS_RENDER_FILE="${GRASS_RENDER_PATH}/$1".png
# keep 'last' filename
export LAST_GRASS_RENDER_FILE="$GRASS_RENDER_FILE"
d.rast "$@"
echo "$GRASS_RENDER_FILE"
tycat -g 1000x1000 "$GRASS_RENDER_FILE"
# reset default filename, make it reusable
export 
GRASS_RENDER_FILE="${GRASS_RENDER_PATH}/${GRASS_RENDER_FILENAME}.${GRASS_RENDER_FORMAT}"

export GRASS_RENDER_FILE_READ=TRUE
}

# then, draw on top of the existing (output) image file with 
`tyraster.add`

function tyraster.add {
# use 'last' filename
export GRASS_RENDER_FILE="$LAST_GRASS_RENDER_FILE"
d.rast "$@"
echo "$GRASS_RENDER_FILE"
tycat -g 1000x1000 "$GRASS_RENDER_FILE"
# reset default filename
export 
GRASS_RENDER_FILE="${GRASS_RENDER_PATH}/${GRASS_RENDER_FILENAME}.${GRASS_RENDER_FORMAT}"

}
```

The same approach does not work for vector maps with PNG as an output 
file format (substitute in the above functions `d.rast` with `d.vect`).

It does work, however, with the BMP file format.

Would anyone have a clue why PNG is 'problematic' with vector maps?
Each time `d.vect` is called with GRASS_RENDER_FILE_READ=TRUE, there is 
no data rendered in the output image file.
Unsetting GRASS_RENDER_FILE_READ will draw data in the pre-defined 
output image file, however without drawing it on top of existing data -- 
which is the point of `tyraster.add` and a corresponding custom function 
`tyvector.add`.


I use the following setup (of which some variables are custom ones):
```
export GRASS_RENDER_PATH=/some/path/grassdb/render
export GRASS_RENDER_FILENAME=grass_render_file
export GRASS_RENDER_FORMAT=bmp
GRASS_RENDER_FILE="${GRASS_RENDER_PATH}/${GRASS_RENDER_FILENAME}.${GRASS_RENDER_FORMAT}"
export GRASS_RENDER_FILE

export GRASS_RENDER_FILE_READ=TRUE
export GRASS_RENDER_FILE_MAPPED=TRUE
export GRASS_RENDER_DRIVER=cairo
export GRASS_RENDER_ANTIALIAS=CAIRO_ANTIALIAS_SUBPIXEL
GRASS_RENDER_IMMEDIATE="${GRASS_RENDER_DRIVER}"
export GRASS_RENDER_IMMEDIATE

export GRASS_RENDER_TRUECOLOR=TRUE
export GRASS_RENDER_BACKGROUNDCOLOR=00
export GRASS_RENDER_TRANSPARENT=TRUE

export GRASS_RENDER_WIDTH=1500
export GRASS_RENDER_HEIGHT=1500
export GRASS_RENDER_LINE_WIDTH=1

export GRASS_FONT=DroidSans
export GRASS_RENDER_TEXT_SIZE=10
```

Thank you, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Read-access to data in a different location with same SRS

[nik]

Hi all. Greetings and have nice programming sessions.
(Not happy not being able to be an active member of the great team you 
have).


Regarding linking, this https://github.com/NikosAlexandris/r.internal 
might be of interest. Created to not duplicate tens of thousands of 
Landsat maps in the High Throughput cluster (in the JRC) while 
generating LST time series.


Cheers, Nikos

---


On 2020-11-19 21:38, Helmut Kudrnovsky wrote:

there and then other users including me symlink this mapset to their
locations in scratch spaces, so they can read from there and work on 
their

stuff. This has been working really well.



Yes, this is a typical workflow several of us use regularly. But 
again,
this is very easy in *nix environments, >but I'm not sure how portable 
it

is...

symlinks are available in ms windows (e.g. [1], [2], [3]), though I 
guess

it's not widely known and used.

[1]
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/
[2]
https://www.giga.de/downloads/windows-10/tipps/symlinks-in-windows-erstellen-mit-mklink-so-gehts/
[3]
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] Extract vector features from external PostGIS layer without building topology

[nik]

À Dimanche 6 août 2017, Martin Landa a écrit :
> Hi,
> 
> 2017-08-06 8:38 GMT+02:00 Nikos Alexandris :
> > I am looking for a confirmation that the following is _not_ possible:
> >
> > v.external -b input="PG:host=somehost user=someuser dbname=somepgdb"
> > layer=somemaplayer
> >
> > then
> > v.extract input=somemaplayer output=somemaplayer_extract where="some sql
> > query"
> 
> currently `v.extract` requires topology [1]. It would be possible to
> modify it in order to operate also on level 1 (no topology). At least
> for points it would make sense. For areas you always need topology
> built. Ma
> 
> [1] 
> https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.extract/main.c#L188
>

Than you Martin,
N
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Status of r.cva?

[nik]

Nikos Alexandris:
  ...(and r.viewshed [2]).

  [2] Module/manual exists only for G7
  http://grass.osgeo.org/grass70/manuals/r.viewshed.html, not for G64!

Markus Metz wrote: 
 r.viewshed is available as add-on for G6:
 http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.viewshed

Compiles and works :-)

Thnx, N
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.segment error: Ri is 0

[nik]

[..]

Markus Metz wrote:
 Not really. I created a sample dataset with a MASK leaving only a
 narrow diagonal strip and everything went fine. Did you get any other
 warnings while running i.segment? I assume you are using 64 bit Linux
 with more than 3072 GB RAM and lots of free disk space on the
 partition with your GRASS data.

Sorry for breaking the flow here :-/.

Besides the memory= parameter, could/would it be useful for i.segment to 
provide an option to make use of an external directory where to store 
temporary files?  Like in r.viewshed stream_dir=?

Thanks, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev