Re: [GRASS-user] Raster null values unchanged by r.null

2021-10-20 Thread Ken Mankoff
I think r.null does not work on external (r.external) files. Make sure this
is not the issue.

Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.

On Wed, Oct 20, 2021, 07:02 Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:

> I'm encountering some strange behaviour from r.null  - when I use the
> setnull parameter to assign a particular value to be null in a raster, the
> raster areas just set to null are still visible and coloured according to
> their previous values when I refresh the display in the gui map window.
> Querying these values shows they haven't been set to null.
>
> Using version 7.8.5 on Linux Mint. Can anyone confirm?
>
> --
> Eric
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Raster null values unchanged by r.null

2021-10-20 Thread Eric Patton via grass-user
Thanks for checking, Micha.

I have had weird behaviour from the wxgui in the last several months. Nothing I 
can pin down exactly. Perhaps a missing dependency?

I'll try Grass 7.8.6 and see if that fixes the issue. I think I installed my 
version 7.8.5 via git, so what would be the safest way to completely uninstall 
it?

--
Eric

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, October 20th, 2021 at 12:10, Micha Silver  
wrote:

> Hi
>
> On 10/20/21 4:52 PM, Eric Patton via grass-user wrote:
>
>> I'm encountering some strange behaviour from r.null - when I use the setnull 
>> parameter to assign a particular value to be null in a raster, the raster 
>> areas just set to null are still visible and coloured according to their 
>> previous values when I refresh the display in the gui map window. Querying 
>> these values shows they haven't been set to null.
>>
>> Using version 7.8.5 on Linux Mint. Can anyone confirm?
>
> No problem here, 7.8.5 on Debian. Also checked on grass 8.0.
>
>> --
>> Eric
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>>
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] PostGIS import and primary keys

2021-10-20 Thread Juan Pedro Pérez Alcántara
Hello,

I've been testing PostGIS to GRASS imports / exports and there are some
things I'm not sure I understand correctly. They are related to keeping
primary keys coming from PostGIS.

My table of origin at PostGIS has a primary key called gid_building
(integer). When using:

grass $GRASS_DB/PERMANENT --exec \
v.in.ogr --verbose --overwrite \
input="PG:host=$HOST dbname=cell_raw_data user=$USER port=$PORT password=
$PASS" \
layer=cat2020.building output=building \
snap=0.01 \
where="gid_building between 2633000 and 2633100"

and then exporting with:

grass $GRASS_DB/PERMANENT --exec \
v.out.ogr --overwrite \
input=building \
type=area \
output="PG:host=$HOST dbname=cell_raw_data user=$USER port=$PORT password=
$PASS" \
output_layer=cat2020_topo_clean.building_dump \
format=PostgreSQL \
lco=FID=gid_building_dump \
lco=GEOMETRY_NAME=geom

I found the following schema back in PostGIS:

gid_building_dump (integer, with a nextval sequence)
cat (integer)
...

But no trace of the original primary key in the PostGIS origin table
gid_building.
My guesses:

v.in.ogr just don't use the primary key of the original table,
gid_building. In
fact, if I drop the primary key from this column, it is imported normally.

GRASS add its cat field to store category.

v.out.ogr adds its own primary key with the nextval sequence.

I'm happy with GDAL / GRASS adding their own internal primary keys to the
data,
in fact, I understand this is the sensible thing to do given the disparity
in
data models. My only question is: is there any way in v.in.ogr to keep the
primary key as a normal field?

Thanks a lot,

---

Juan Pedro Pérez Alcántara

jp.perez.alcant...@gmail.com
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Raster null values unchanged by r.null

2021-10-20 Thread Micha Silver

  
  
Hi

On 10/20/21 4:52 PM, Eric Patton via
  grass-user wrote:


  
  I'm encountering some strange behaviour from r.null  - when I
use the setnull parameter to assign a particular value to be
null in a raster, the raster areas just set to null are still
visible and coloured according to their previous values when I
refresh the display in the gui map window. Querying these values
shows they haven't been set to null.
  
  
  
  Using version 7.8.5 on Linux Mint. Can anyone confirm?
  



No problem here, 7.8.5 on Debian. Also checked on grass 8.0.



  
  
  

  --
  
  Eric 
  

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


-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

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


[GRASS-user] Raster null values unchanged by r.null

2021-10-20 Thread Eric Patton via grass-user
I'm encountering some strange behaviour from r.null - when I use the setnull 
parameter to assign a particular value to be null in a raster, the raster areas 
just set to null are still visible and coloured according to their previous 
values when I refresh the display in the gui map window. Querying these values 
shows they haven't been set to null.

Using version 7.8.5 on Linux Mint. Can anyone confirm?

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