Re: [GRASS-user] PostGIS import and primary keys

2021-10-26 Thread Moritz Lennert


Le 20 octobre 2021 17:56:04 GMT+02:00, "Juan Pedro Pérez Alcántara" 
 a écrit :
>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.

Have you checked whether the 'cat' column values correspond to the primary key 
values ? Maybe an existing primary key is automatically imported as the 'cat' 
column ?

Otherwise, this might actually be an OGR issue. What happens to the column when 
you do an ogr2ogr to transform to geopackage or shapefile ?

Also you might try feeding the PGSQL_OGR_FID option to v.in.ogr's gdal_config 
parameter. See [1] for more info about the OGR PostgreSQL driver.

If GRASS GIS really loses data during import, I would consider this a serious 
bug.

>
>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?

Actually, using the 'key' parameter you should be able to declare your 
PostgreSQKL primary key as the column to use by GRASS GIS as its internal 
primary key (aka category column).


Moritz

[1] https://gdal.org/drivers/vector/pg.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] grass gis equivalent of st_subdivide

2021-10-13 Thread Moritz Lennert
Hi HB,

Le 13 octobre 2021 22:57:21 GMT+01:00, B H  a écrit :
>Hi,
>How do I divide an area into smaller areas ( I am looking for functionality
>of st_subdivide in postgis).
>I need to  split some big areas into smaller ones (and all smaller ones
>should have the same attributes).
>I understand that it means that underlying topology would change( It would
>add more boundaries).
>
>When v.in.ogr imports a shapefile in Grass GIS, it automatically splits the
>overlapping areas to make them topologically correct, so I am hoping that
>there is already some way to just split a topologically valid area as
>well...


I don't think that there is any readymade module for this. You could just 
create a fixed grid with v.mkgrid and v.overlay it with something like this:

v.overlay ain=orig bin=grid out=subdivided operator=and olayer=0,1,0

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


Re: [GRASS-user] GUI vector import column format issue

2021-10-02 Thread Moritz Lennert

On 1/10/21 17:29, Rich Shepard wrote:
Using the wxGUI when GRASS was invoked I tried to import an ASCII point 
file

looking like this:
lon,lat,depth
7719886.85,702082.80,21
7719910.22,702014.88,21
7719927.67,701945.79,24
7719930.64,701875.40,19
7719933.85,701804.44,37
7719942.24,701734.58,40
7719949.17,701664.16,41
7719958.36,701594.64,38
7719965.04,701524.66,38

The processing window fails to import the file:
(Fri Oct  1 08:19:22 2021) v.in.ascii -r 
input=/home/rshepard/projects/washington/project/data/bathymetry/coe/CL_34_WSHX_20210720_CS.xyz 
output=wash_sounding_pts separator=comma

Scanning input for column types...
Skipping 452 of 1211 rows falling outside of current region
Number of columns: 3
Number of data rows: 1211
ERROR: 'x' column is not of number type, encountered: 'lon'
(Fri Oct  1 08:19:22 2021) Command finished (0 sec)

Yesterday, using the text interface when invoking GRASS there were no 
issues

using v.in.ascii on the adjacent file which begins like this:
lon,lat,depth
7709581.42,697951.64,24
7705545.87,698624.07,16
7709732.27,699488.73,27
7712090.79,699428.24,62
7716863.99,701238.89,32
7701540.85,698790.50,31
7713676.33,699192.82,58
7705283.41,697549.00,31
7705037.10,698489.22,16

Why might the GUI see the first column, longitude, differently than the
command line version of v.in.ascii?
I cannot reproduce that in grass 7.8.5: both the GUI and the command 
line version fail on your file, unless you add skip=1 in order to skip 
the header row. Maybe you inadvertently set skip=1 in the GUI without 
noticing it ? You can check that by looking at the command history in 
the console.


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


Re: [GRASS-user] Elevation/bathymetry raster maps

2021-09-30 Thread Moritz Lennert

Am 30.09.2021 14:40 schrieb Rich Shepard:

On Thu, 30 Sep 2021, Maris Nartiss wrote:


One option always is to set colours manually.


Māris,

That occurred to me: use r.mapcalc to define ranges of depth/elevation 
then

assign a color to each.


No need for r.mapcalc if what you are looking for is coloring. Just 
define a color table definition file and feed it to r.colors.


This color table file can be quite flexible, e.g. to get more 
differentiated coloring between -5000 and -3000, you can use something 
like this:


-5000 0:0:0
- 4000 50:50:50
- 3000 100:100:100
0 175:175:175
100% 255:255:255

Check the r.colors man page for more details.

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


Re: [GRASS-user] Create location fails in docker

2021-09-30 Thread Moritz Lennert

Hi Madi,

Am 30.09.2021 09:46 schrieb Margherita Di Leo:

Hi again,

I try to reformulate my question:

On Wed, Sep 29, 2021 at 9:32 PM Margherita Di Leo 
wrote:


grass --text -c EPSG:4326 $GRASSDATA/france -e

The error message:

Traceback (most recent call last):
File "/usr/bin/grass", line 390, in get_grass_config_dir
os.mkdir(directory)
PermissionError: [Errno 13] Permission denied: '/.grass7'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/grass", line 2218, in 
main()
File "/usr/bin/grass", line 2001, in main
grass_config_dir = get_grass_config_dir()
File "/usr/bin/grass", line 395, in get_grass_config_dir
_("Failed to create configuration directory '%s' with error:
%s")
NameError: name '_' is not defined
Traceback (most recent call last):
File "/usr/bin/grass", line 390, in get_grass_config_dir
os.mkdir(directory)
PermissionError: [Errno 13] Permission denied: '/.grass7'


What does this error message mean? Why is it trying to write in the
/.grass7 folder ?


Whenever you launch GRASS GIS with the grass startup script, it writes 
the chosen Gisdbase/Location/Mapset info into .grass7/rc. If you launch 
GRASS GIS for the first time, it first creates the directory .grass7 
which is the part that fails with a permission error.


I'm no Docker expert at all, but I think you have to explicitly run the 
container with parameters indicating the devices one can access from 
within.



And what does the name '_' refer to?


This seems to be linked to the translation handling:


File "/usr/bin/grass", line 395, in get_grass_config_dir
_("Failed to create configuration directory '%s' with error:
%s")


Note the '_' in front of the string which marks it as a translatable 
string.


There was a bug related to this a while ago, but it was fixed 
(https://trac.osgeo.org/grass/ticket/3875). Maybe a locale issue ?


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


Re: [GRASS-user] Starting GRASS

2021-09-26 Thread Moritz Lennert
Rich,

As mentioned in an earlier mail: you have to include the mapset directory in 
the path.

Moritz


Le 26 septembre 2021 16:28:59 GMT+02:00, Rich Shepard 
 a écrit :
>I don't know why I'm suddenly having problems starting GRASS when it's never
>before been an issue. I should be able to be in any directory when GRASS is
>started because ~/.grass80/rc lists the GISDBASE as /data/grassdata. I
>assume that the location in that file can be replaced by specifying the
>location onthe command line.
>
>But, this is not working.
>
>[rshepard@salmo ~]$ grass /data/grassdata/columbia_river_dtms 
>Starting GRASS GIS...
>ERROR:  is not a valid GRASS Location because PERMANENT 
>Mapset is missing
>Maybe you meant a different directory.
>Exiting...
>
>/data/grassdata is the GISDBASE, not a location. I get the same error if the
>PWD is /data/grassdata or if I specify the fully-qualified path on the
>command line. I'm out of ideas why I'm now having these issues and a clue
>stick will be very helpful.
>
>TIA,
>
>Rich
>___
>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] imported .tif maps lose all data

2021-09-26 Thread Moritz Lennert
If you set your region correctly before importing all the files, you could also 
use the -r flag of r.in.gdal, no ?

Might possibly be slower, though, then determining which files to import before 
running r.in.gdal as Micha suggests

Moritz

Le 26 septembre 2021 14:44:46 GMT+02:00, Rich Shepard 
 a écrit :
>On Sun, 26 Sep 2021, Micha Silver wrote:
>
>> If that's the case, perhaps a quick `gdalinfo` loop over all 77 topography
>> maps in advance will help to find the relevant ones. You get the corner
>> coordinates in the gdalinfo output, so you'll be able to find those that
>> overlap the project region before importing to GRASS.
>
>Micha,
>
>That's an excellent idea. I was going to use r.info or r.report on all maps
>and build a text table of the corners, then find the minimum and maximum of
>each corner and build the region using those values.
>
>I have the lon-lat of the project area and can reproject that to State Plane
>then find the one or two maps that enclose that area.
>
>It's common for many of us who are closely focused on an issue to not see
>other possibilities. Outsiders see things we don't.
>
>Toda,
>
>Rich
>
>___
>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] imported .tif maps lose all data

2021-09-25 Thread Moritz Lennert


Le 26 septembre 2021 00:50:13 GMT+02:00, Rich Shepard 
 a écrit :
>On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:
>
>> try the same steps as I've done (with adjusted paths) and _post the
>> command and the command output_ here.
>> - g.region -p
>> - r.in.gdal input=columbia_2010_e_dtm_35.tif output=columbia_2010_e_dtm_35
>> - g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35
>> - r.stats -l input=columbia_2010_e_dtm_35
>> - r.report map=columbia_2010_e_dtm_35
>
>Helmut,
>
>Results in attached 574 line file. There are some cells with data, but most
>without data (82%).
>
>I can display the data with cells; for this one map they appear to cover
>only the river and not the terrain north of it. But, this is only one of 77
>files.
>
>Since this test worked I need to figure out why it didn't work when I
>imported all 77 .tif files using the bash script. Ah! Thought: when
>r.in.gdal imports all 77 files where does GRASS get the values for setting
>g.region -p?

You feed the information to g.region with the 'raster' parameter.

-p just means pretty print the region settings, it doesn't set the region.


>
>If g.region -p displays the region of last map imported then the other 76
>maps will be outside that region. Is there a module that uses all maps in
>that mapset to set the region, or is that supposed to be done by default?

If you want to set the region to the extension covered by multiple raster maps, 
just feed all the maps' names to the 'raster' parameter.

But in your case, while still testing, you should set the region to one map, 
then test with r.report, then set the region to the next map, test, etc.

Another hint: if you just want to quickly test if the imported map has any 
values, use r.info which is region independent. With the -r flage you get the 
min-max range.

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


Re: [GRASS-user] imported .tif maps lose all data

2021-09-25 Thread Moritz Lennert


Le 25 septembre 2021 22:09:57 GMT+02:00, Rich Shepard 
 a écrit :
>On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:
>
>> try the same steps as I've done (with adjusted paths) and _post the command 
>> and the command output_ here.
>>
>> - grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
>> - enter into the location just created
>
>Helmut,
>
>Problem at this step:
>
>$ grass -e -c columbia_2010_e_dtm_35.tif ./rastertest
>Starting GRASS GIS...
>Creating new GRASS GIS location ...
>Cleaning up temporary files...
>Cleaning up temporary files...
>
># PROBLEM (PWD is /data/grassdata/):
>$ grass rastertest 
>Starting GRASS GIS...
>ERROR:  is not a valid GRASS Location because PERMANENT 
>Mapset is missing
>Maybe you meant a different directory.
>Exiting...
>
>$ grass /data/grassdata/rastertest/
>Starting GRASS GIS...
>ERROR:  is not a valid GRASS Location because PERMANENT 
>Mapset is missing
>Maybe you meant a different directory.
>Exiting...
>
># The rastertest location exists with the PERMANENT mapset:
>ls rastertest/PERMANENT/
>DEFAULT_WIND  MYNAME  PROJ_INFO  PROJ_UNITS  PROJ_WKT  VAR  WIND  sqlite/
>
>So, grass here is seeing the GISDBASE as a location, even when the location
>is specified on the command line with either that mapset name or the full
>path?
>
>I've been having this issue the past few weeks.
>

The startup script expects you to provide the full path to a mapset, so when 
you give it 'data/grassdata/rastertest' it assumes that 'rastertest' is the 
mapset, so 'grassdata' must be the location. It then checks for a PERMANENT 
mapset in that location but cannot find it.

After creating your location it only contains one single mapset: 'PERMANENT', 
so to start GRASS GIS, you have to use

grass /data/grassdata/rastertest/PERMANENT

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


Re: [GRASS-user] Start grass, create new mapset

2021-09-22 Thread Moritz Lennert


Le 22 septembre 2021 14:40:45 GMT+02:00, Rich Shepard 
 a écrit :

On Wed, 22 Sep 2021, Moritz Lennert wrote:

IIUC, you do not want to create a new location, but just a new mapset 
?


Moritz,

That's correct.


If that is the case, just try with the -c flag to create it:
grass -c /data/grassdata/lon_lat/
Then import your data.


Thank you. I wondered if the -c (create) option would work for only a 
mapset

since all examples create a new location.

Should I add that example to the startup manual page for 8.0 dev?


That would be great !

I also see that the description of the -c flag itself only speaks about 
locations, not mapsets. This should also be changed. Something in the 
direction of:


"-c
Creates new GRASS unprojected location in specified GISDBASE"
[no idea why it says 'unprojected' must be long-term legacy]

should become

"-c
Creates new GRASS location or mapset respectively in specified GISDBASE 
or location"

[if this is not too long]

Moritz




Regards,

Rich
___
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] Start grass, create new mapset

2021-09-22 Thread Moritz Lennert
Hi Rich,

Le 21 septembre 2021 17:30:48 GMT+02:00, Rich Shepard 
 a écrit :
>I have an existing location, lon_lat, into which I import new data in that
>format.
>
>From the command line I want to start grass in text mode using that location
>while creating a new mapset there. On the grass startup manual page I see
>examples that create new locations or use shapefiles or tiff files for the
>mapsets. What do I use if the input data is ascii text points?
>
>I've tried grass /data/grassdata/lon_lat/ and am told that the
>mapset doesn't exist or have a WIND file.
>

IIUC, you do not want to create a new location, but just a new mapset ?

If that is the case, just try with the -c flag to create it:

grass -c /data/grassdata/lon_lat/

Then import your data.

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


Re: [GRASS-user] What color style for bathymetric raster map?

2021-09-20 Thread Moritz Lennert
Hi Rich,

Le 20 septembre 2021 17:51:42 GMT+02:00, Rich Shepard 
 a écrit :
>I've a raster bathymetric map (attached) to which I've applied r.color =
>'elevation' because I didn't see another style more appropriate for aquatic
>environments. I'm sure there is at least one in various shades of blue and
>I'd like suggestions for what to use or do to create one.


I'd try 'water' or 'etopo2'.

>
>Also, is there a way to get narrower depth slices since the riverbed is
>comparatively shallow and flat in this data set.

Your data looks continuous, so what do you mean by "slices" ? A continuous 
color table doesn't have slices.

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


Re: [GRASS-user] v.in.ogr ESRI fileGDB

2021-09-17 Thread Moritz Lennert
Hi Rich,

I saw that you found a different solution, but just for the record: are you 
sure the fgdb actually contains vector data ? AFAIR, fgdb's can also contain 
raster data, but there is no gdal driver for that.

Moritz

Le 17 septembre 2021 19:29:37 GMT+02:00, Rich Shepard 
 a écrit :
>On Fri, 17 Sep 2021, Maris Nartiss wrote:
>
>> I was testing on the main branch compiled at the end of August running
>> with GDAL 3.0.4.
>
>Maris,
>
>gdal-3.2.2 is installed here. The problem is not that.
>
>> Rich, you should see in the output of ogrinfo -ro -so a list of layers
>> in the FGDB. If you do not see them, then you will not be able to
>> import as GRASS is using OGR for reading FGDB.
>
>That's what I expected. But, From the directory in which Tile_E.gdb/ is
>located:
>$ ogrinfo -ro -so ./Tile_E.gdb/
>INFO: Open of `./Tile_E.gdb/'
>   using driver `OpenFileGDB' successful.
>
>That's it.
>
>Of course GRASS could not import it since ogrinfo didn't see any content in
>the open file.
>
>I'll download it from the source again.
>
>Thanks,
>
>Rich
>___
>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


[GRASS-user] GRASS GIS moves to Open Collective for collecting donations and thanks its many financial contributors

2021-09-07 Thread Moritz Lennert

Dear all,

In order to make money donations easier, the GRASS GIS project has 
decided to use the Open Collective platform with the Open Source 
Geospatial (OSGeo) Foundation as its fiscal host:  
https://opencollective.com/grass. You can donate money via credit card, 
PayPal, or bank transfer (US account - for EU account please contact 
us). This new platform replaces our old PayPal Money Pool.


Although most of the work on GRASS GIS happens on a voluntary basis (or 
donated by organizations and companies in the form of working time of 
their staff), money donations are very important for the development of 
GRASS GIS as they allow us to organize face-to-face coding sessions 
(sprints), finance infrastucture needs (web site, etc) and sometimes pay 
developers to work on important but tedious bug fixes or high community 
value enhancements. The new platform allows both individuals and 
companies or organizations to contribute to the GRASS GIS budget.


We would also like to take the opportunity to thank those who have 
already contributed money in the last years. You can see a complete list 
of sponsors on https://grasswiki.osgeo.org/wiki/Sponsors. Whatever the 
amount your help is deeply appreciated !


We particularly encourage companies and organizations that use GRASS GIS 
in their daily work to consider contributing. As an example of such 
company support we wish to highlight the very generous donation recently 
received from Bohannan Huston, Inc. (https://bhinc.com/). We asked 
Robert S. Dzur, Vice President Spatial Data, to explain their motivation 
behind supporting the project. Here is what he has to say:


"Our use of GRASS GIS is primarily related to areas of data inventory, 
visualization, quality assessment and analysis.  As data producers, we 
are regularly confronted with production challenges related to ingesting 
and visualizing high data volumes of imagery, elevation / point cloud 
and feature data.  GRASS GIS gives us the ability to quickly handle 
large datasets at any point in the production stage.  For example, we 
use r.in.lidar and its capacity to read large multi-billion point 
datasets from a text list and create derivative elevation data products 
often to support both quality assurance tasks as well as base maps for 
vector feature data development.  GRASS GIS's multiplatform (Windows, 
Mac, Linux) support and integration with GDAL/OGR is also a plus for us. 
 GRASS GIS gives us direct control, access, and the ability to interact 
with our data at very granular levels.  My colleague, Dennis Sandin also 
reminded me that one of the greatest benefits of GRASS GIS is that its 
environments gives us a plethora of options for manipulating data and 
testing/designing our automation/workflow processes. We also appreciate 
the GRASS GIS legacy and its long history of development dating back to 
its genesis with the US Army Corps of Engineers and the continued 
scientific foundations of its applications.


Over the past few years, we have been making a concerted effort on two 
fronts to 1) support the geospatial open-source community and 2) reduce 
our dependence on commercial software.  Typically, our support had been 
through sponsoring the broader community through code sprint events.  
Last year, however, with code sprints on-hold we decided to contribute 
to the QGIS crowdfunding campaign for point cloud functionality.  At the 
same time, we attempted to make a corresponding reduction in our 
commercial licensing contracts.  This year we have also been trying to 
reach out to some of our key clients and teach team how to use GRASS GIS 
on their own computing infrastructure.  Specifically, we engaged with 
one client to teach them how to use r.in.pdal to develop elevation range 
maps from LiDAR point cloud data as a complementary data element in 
their NDVI analysis to identify vegetation canopy.  Another client was 
interested in merging DEM data of differing source lineage and quality 
and we conducted a basic how to session on GRASS GIS with them and 
shared details about r.patch and r.patch.smooth.  Given those recent 
technical exchange efforts locally with some of our clients, our 
experience with GRASS GIS, and our objective to support a specific 
open-source project, this year we decided to contribute to the GRASS GIS 
project.


If there are companies or organizations like us who are not already 
using GRASS GIS to improve their workflows, they should be."


Convinced you want to support GRASS GIS financially ? Go to 
https://opencollective.com/grass !


The GRASS GIS development team
~
___
grass-psc mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

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


Re: [GRASS-user] Error import from grass.pygrass.vector library

2021-08-26 Thread Moritz Lennert

Am 24.08.2021 11:35 schrieb Manuele Pesenti:

 Attivato mar, 24 ago 2021 11:04:44 +0200 STEFAN BLUMENTRATH
 ha scritto 


What version of grass_sessions do you use?

I run grass_session 0.4 on Ubuntu 18.04 with GRASS 7.8 and your
script works fine…


Thanks Stefan! It solves my problem... I opened an issue [1] to the
github repo of grass_session.



AFAUI, 0.5 introduced, among others, the fact that libs are not loaded 
by default unless explicitly requested:


https://github.com/zarch/grass-session/commit/b1d4c0fa574bdbd86716fb504ce05e8b449a9dfc#diff-6f5e014607121aae5fa1a45459276b57eceb9194cc53dd65413d973faf59dd87

I'm not 100% sure I understand how it works, but IIUC, you should be 
able to something like this (untested):


Session(gisdb="/tmp", location="location", create_opts="EPSG:4326", 
loadlibs=True)


Don't know what the rationale behind this change is, though.

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


Re: [GRASS-user] v.external, postgis materialized views and projection

2021-08-17 Thread Moritz Lennert

Am 17.08.2021 09:38 schrieb Stefan Blumentrath:

Hi Donovan,

Did you try the suggestion from the error message to use the -o flag?

That overwrites the projection check and should link the data assuming
the projection of your GRASS mapset.


That is a useful workaround, but I would still consider Donovan's 
observation as a bug, so please post an issue about it.
Make sure to indicate which version of GRASS GIS you are working with, 
including the GDAL and PROJ versions as there has been quite a lot of 
change in that domain across the latest releases.


Moritz



Cheers

Stefan

FROM: grass-user  ON BEHALF OF
Donovan Cameron
 SENT: tirsdag 17. august 2021 07:06
 TO: grass-user@lists.osgeo.org
 SUBJECT: Re: [GRASS-user] v.external, postgis materialized views and
projection

On 2021-08-16 12:18 p.m., Phillip Allen wrote:


I am not sure about GRASS's quirks in respect to this problem but I
do see in QGIS that in my views I often have to specifically CAST my
geometries so QGIS can see the Z & M values:

example: SELECT b. sample_id, b. au_ppm, b. as_ppm, b. cu_ppm,
ST_TRANSFORM(b.geom, 32718 )::geometry(LineStringZM,32718) FROM
bore_hole b;


Tested on a new set of polygons and casted but it didn't make a
difference. GRASS doesn't like ST_Transform on materialized views it
looks like.

All the views are opening in QGIS fine and with their correct
projection and geometry type (with and without casting to a specific
type).


On Mon, Aug 16, 2021 at 1:10 PM Saulteau Don 
wrote:

When I use v.external to load a postgis materialized view it says
the projection mismatches the Location but they are actually the
same.

% v.external input="PG:host=localhost dbname=database" layer=table_1
output=t

ERROR: Projection of dataset does not appear to match current
location.

Location PROJ_INFO is:
name: NAD83 / UTM zone 10N
datum: nad83
ellps: grs80
proj: utm
zone: 10
no_defs: defined

init: EPSG:26910

Dataset PROJ_INFO is:
name: NAD83 / BC Albers
datum: nad83
ellps: grs80
proj: aea
lat_0: 45
lon_0: -126
lat_1: 50
lat_2: 58.5
x_0: 100
y_0: 0

no_defs: defined

Difference in: proj

In case of no significant differences in the projection
definitions,
use the -o flag to ignore them and use current location definition.

Consider generating a new location from the input dataset using the

'location' parameter.

It looks like GRASS sees the projection from the source table used
for the materialized view instead of the materialized views
projection that was set in postgis using ST_Transform().

Is this normal for grass to see materialized views like this?

Donovan

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



Links:
--
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-userdata=04%7C01%7C%7C542dd240835b472f88ae08d9613cb730%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637647736003704409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xICdQBainNrRKS0F3Efppf67CgX%2FugCL9uSsgKIIph8%3Dreserved=0

___
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] v.extract fails for long strings in sql where or cat

2021-08-11 Thread Moritz Lennert


Le 11 août 2021 11:06:35 GMT+02:00, Mira Kattwinkel 
 a écrit :
>Dear list,
>
>is there a max length in the where statement for v.extract?
>
>I want to extract many line features depending on the value of an id 
>field and get:
>
>"[Errno 7] Argument list too long: 'v.extract'" when I run v.extract 
>with a long sql statement.
>
>It works if I use id < 7, hence the number of extracted items is not 
>the problem. However, this does not help because I need a selection like 
>"id in (1,5,7,...,7)". Similarly, cat = 1-7 works but cat = 
>1,2,3,,7 does not.
>
>I found an old posting about this 
>(https://lists.osgeo.org/pipermail/grass-user/2010-January/054361.html) 
>and wonder if anything has changed since then and if there is any work 
>around if not.

If what you have is a long list of cat values, try the 'file' option of 
v.extract.

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


Re: [GRASS-user] Advice on importing V5 data sets?

2021-06-25 Thread Moritz Lennert


Le 24 juin 2021 10:06:27 GMT+02:00, brendon wolff-piggott  
a écrit :
>Sorry, thought I had answered yesterday. It is both vector and raster.
>Created in GRASS 5.1 (not sure of .x number).
>
>I would like to import the data into PostGIS, so I can access it in GRASS
>or QGIS.
>

If all you want is to get the data out of a GRASS GIS database, another option 
would be to simply install GRASS 5 and then export the data: 
https://grass.osgeo.org/about/history/releases/ (see 2004 for 5.x source code).

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


Re: [GRASS-user] Missing ps.map example

2021-06-15 Thread Moritz Lennert

Hi Robert,

Unfortunately I was not able to locate them in some archives I have here 
at home. I can check with some colleagues at the university when I see 
them next, but am not too hopeful. I was pretty sure that I had saved 
them somewhere, but just haven't been able to find them, so they must 
have gotten lost in the process.


I've sent a mail to the university IT department to see if they still 
have archives somewhere.


Best wishes,
Moritz

Am 09.06.2021 03:19 schrieb Robert Dzur:

Hi Moritz

 I was curious if you might have located your ps map example from this
thread. I note that the links are no longer available. If you could
share your map / script, I would appreciate it.

 Thank you.

 Best

 Rob

-

FROM: grass-user  on behalf of
Moritz Lennert 
 SENT: Tuesday, January 5, 2021, 10:22 AM
 TO: n...@nikosalexandris.net; grass-user @lists.osgeo.org
 SUBJECT: Re: [GRASS-user] Missing ps.map example

[This message came from an External person]

 On 5/01/21 10:34, n...@nikosalexandris.net wrote:
 > In http://homepages.ulb.ac.be/~mlennert/grass/psmap/index.html [1]
there is
 > this nice example
 > http://homepages.ulb.ac.be/~mlennert/grass/psmap/ages.png [2]. The
source
 > code for it is missing. Any chance to get hands on it?

 There is a chance but since I've left the unversity, I will have to
dig
 into some archives. I'll make it available ASAP.

 Moritz

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



Links:
--
[1] http://homepages.ulb.ac.be/~mlennert/grass/psmap/index.html
[2] http://homepages.ulb.ac.be/~mlennert/grass/psmap/ages.png
[3] 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] v.select incredibly slow

2021-03-29 Thread Moritz Lennert

Hi Uwe,

On 29/03/21 15:59, Uwe Fischer wrote:

Hi Moritz,

for the question about lines and polys: I believe that confusion may come up 
when one looks at a GRASS dataset in the QGIS browser panel (please see 
attachment): there are lines and polygons in one map! And I can load them 
exactly that way in QGIS. That is: when I load the lines in QGIS, I only get 
lines!


GRASS GIS' vector format supports mixing all types of features in one 
single map, so you can have points, lines and areas (boundary lines + 
centroids) in one single map. The shapefile format does not support 
this. AFAIK, QGIS follows the shapefile logic and does not allow 
different geometry types in one single layer. Any area map in GRASS GIS 
can actually be represented in three ways:


1) As what we generally would call polygons
2) The lines that constitute the contours of these polygons (called 
boundaries in GRASS GIS)
3) Points that lie within the polygon (and are called centroids in GRASS 
GIS, although they are not necessarily actual centroids in the 
geometrical sense)


QGIS only provides 1 & 2.

You can see the effect of this format by playing around with 'type' 
option in d.vect, directly in GRASS GIS.




And they ARE lines. That means: when I select a linear feature that separates 
two areas with the mouse, I select only one feature! (attachment)
Were they boundaries, the mouse would grab two features, one for the left and 
one for the right area??


Again, in GRASS GIS boundaries are lines, not polygons. And in QGIS they 
are displayed as simple lines.


Because of its topological data format GRASS GIS does not have the 
notion of polygons as such. It has the notion of areas which are the 
combination of a boundary line with a centroid. Boundary lines without 
centroids are not considered areas aka polygons.


AFAIK, QGIS does not support topological formats as such and so the 
topological vector format of GRASS GIS (with points, centroids, lines, 
boundaries, (virtual) areas) is mapped into simple features in QGIS: 
points, lines, polygons. If you want to make use of the GRASS GIS' 
topological format directly, you will have to use GRASS GIS.




Maybe it has to do with the way the dataset was imported: it came via v.in.ogr 
using CAD data made up of lines and points using type='centroid,boundary'.

On the other hand, GRASS v.info for that same map gives me:

v.info -t map=forst_f_035980@lwk_work
nodes=86
points=0
lines=0
boundaries=109
centroids=42
areas=43
islands=20
primitives=151
map3d=0

No line features at all !

>
> So is the QGIS representation misleading? How can QGIS see lines 
while GRASS does not?

>

Boundaries are lines which have a special status. But geometrically they 
are lines, not polygones.




On the other hand, I learned from your example that v.select can use boundaries 
as linear features. I checked the same for v.buffer and found that it works: 
for type=boundary, v.buffer will put out tubular buffers around linear features 
(it will not buffer the areas as a whole!) I did not expect that, because I 
thougt that buffering boundarys gives me area buffers, since the boundaries are 
the area borders.


Creating buffers around "areas" will give you area buffers, creating 
buffers around boundaries will give you exactly that: buffers around the 
lines that are defined as boundary lines.


Have you had the opportunity to read through 
https://grass.osgeo.org/grass78/manuals/vectorintro.html#vector-model-and-topology 
?




And for the data conversion tasks: such tasks come up in my projects from time 
to time.
You are right, there are only lines or only polygons in a shapefile.
But I sometimes need to perform typical polygon tasks first (like selecting by 
attributes or dissolving or buffering) and then line tasks on the same dataset 
(like retrieving the clean lines, broken up and without duplicates or other 
errors for exporting and further processing in CAD). The second part cannot be 
done with boundaries, right? That is why i was looking for a good way to deal 
with both.


Most GRASS GIS vector commands allow you to choose which aspect of the 
vector map you want to work with, generally through a 'type' parameter. 
This allows to do what I showed you with v.select, but also with 
v.buffer, v.clean, etc. When you change boundaries, however, you have to 
be aware that you might change them in a way that you break topology. So 
some additional care might be necessary.



Moritz




-Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Gesendet: Montag, 29. März 2021 12:01
An: Uwe Fischer ; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.select incredibly slow

Hi Uwe,

On 29/03/21 09:53, Uwe Fischer wrote:

But it led me again to some kind of misunderstanding that I cannot figure out:

My data are imported from polygon shapefiles.

First question: using v.in.ogr, what does the "type=" parameter mean exactly? In the 
man

Re: [GRASS-user] v.select incredibly slow

2021-03-28 Thread Moritz Lennert
Hi Uwe,

Am 27. März 2021 14:58:01 MEZ schrieb Uwe Fischer :
>Hello list,
>
>I have trouble selecting line features using their location compared to a
>polygon layer using v.select. The line features I want to select from are
>parcel borders, and the polygon layer is made up of tubular-shaped buffers
>around municipal borders. I need to find the parcel borders which are inside
>this buffer.
>
>The command line in a Python script I use is:
>
>grass.run_command('v.select', ainput='temp5', atype='line', binput='buff',
>blayer=1, btype='area', output='grenz', operator='within', overwrite=True)
>
>The process starts, but it runs incredibly slow (> 15 min) and it brings not
>the desired result (but trash data). When I start it in the GRASS ui, it
>also works very very slow.
>
>I have only about 2000 parcel borders, so it cannot be a problem of too much
>features. Furthermore, the exact same selection task is processed in QGIS 3
>in a second with perfect results.
>
>I used v.build on both maps before v.select, but it does not help.
>
>I would like to perform it in GRASS because it is part of a bigger data
>preparation script which makes my work a lot easier. So I need to integrate
>it here rather than selecting in QGIS manually.


First of all: which version of GRASS GIS are you using ?

I filed a bug about this same issue a few years ago [1] and Markus Metz 
reorganized the code at the time to speed things up. I don't remember which 
version was the first to include the fixes (7.6 ?). However, even though it was 
slow, results were ok which doesn't seem to be the case for you, so that is a 
bit worrying.

Can you reproduce the same issue with the example given in that bug report ? If 
not can you provide a reproducible example, including relevant data ? Ideally 
as a GitHub issue ?

As a workaround you could try either the alternative provided in the bug 
report, or you  could try to reduce the number of line candidates first using 
v.select operator=overlap and using operator=within only on those selected in 
the first call.

Moritz

[1] https://trac.osgeo.org/grass/ticket/3361
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Building grass version grass-7.8.5

2021-03-27 Thread Moritz Lennert
Actually, the trailing comma after **kwargs is a feature introduced in recent 
Python 3 versions. It was recently introduced into our code through Black [1].

So, make sure you have Python 3.6+ installed on your system and that this is 
the Python version called during compilation.

Moritz

[1] https://github.com/OSGeo/grass/pull/1382

Am 27. März 2021 11:07:02 MEZ schrieb Moritz Lennert 
:
>
>
>Am 26. März 2021 23:13:18 MEZ schrieb Stephen Kirby :
>>Thanks Veronica for that good information.  I've made some progress by
>>ensuring I had the libs it needs ready (GDAL, etc.).  Now it is giving me a
>>Python error :
>>
>> File
>>"/home/me/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
>>line 305,
>>**options,
>>SyntaxError: invalid syntax
>>
>>I am not a Python user so this is throwing me.  I assume I need to install
>>a Python (Python3?) module, via "pip install ..." I suppose.  Can someone
>>tell me which module can fix this?
>>
>>For reference, the whole Python block of code containing the offending
>>line, from core.py is:
>>def make_command(
>> prog,
>> flags="",
>> overwrite=False,
>> quiet=False,
>> verbose=False,
>> superquiet=False,
>> errors=None,
>> **options,
>>);
>
>
>AFAICT there should not be a comma after **options. This would explain the 
>syntax error.
>
>Moritz
>___
>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] Building grass version grass-7.8.5

2021-03-27 Thread Moritz Lennert


Am 26. März 2021 23:13:18 MEZ schrieb Stephen Kirby :
>Thanks Veronica for that good information.  I've made some progress by
>ensuring I had the libs it needs ready (GDAL, etc.).  Now it is giving me a
>Python error :
>
> File
>"/home/me/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
>line 305,
>**options,
>SyntaxError: invalid syntax
>
>I am not a Python user so this is throwing me.  I assume I need to install
>a Python (Python3?) module, via "pip install ..." I suppose.  Can someone
>tell me which module can fix this?
>
>For reference, the whole Python block of code containing the offending
>line, from core.py is:
>def make_command(
> prog,
> flags="",
> overwrite=False,
> quiet=False,
> verbose=False,
> superquiet=False,
> errors=None,
> **options,
>);


AFAICT there should not be a comma after **options. This would explain the 
syntax error.

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


Re: [GRASS-user] Creating a png file with multiple vector maps

2021-03-12 Thread Moritz Lennert
Hi Chris,

In your previous message the settings you used had a lot of MS Windows paths in 
them, that's why I thought you used that. If you're not on Windows then these 
settings are wrong and this might explain your problem. Here's what you sent:

GRASS 7.8.4> env | grep GRASS
MANPATH=C:\OSGEO4~1\apps\grass\grass78\docs\man;C:\Users\Chris\AppData\Roaming\GRASS7\addons\docs\man
GRASS_PYTHON=C:\OSGEO4~1\bin\python3.exe
GRASS_RENDER_TRANSPARENCY=true
GRASS_PAGER=more
GRASS_GNUPLOT=gnuplot -persist
GRASS_RENDER_PNG_COMPRESSION=0
GRASS_RENDER_FILE_COMPRESSION=0
GRASSBIN=C:\OSGEO4~1\apps\grass\grass78\bin
GRASS_RENDER_FILE=test.png
GRASS_SH=C:\OSGEO4~1\apps\msys\bin\sh.exe
GRASS_RENDER_HEIGHT=480
PATH=/c/OSGEO4~1/apps/grass/grass78/lib:/c/OSGEO4~1/apps/grass/grass78/bin:/c/Users/Chris/AppData/Roaming/GRASS7/addons/bin:/c/OSGEO4~1/apps/Python37:/c/OSGEO4~1/apps/Python37/Scripts:/c/OSGEO4~1/apps/Python27/Scripts:/c/OSGEO4~1/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBem:/usr/bin:/c/Program
 
Files/RStudio/bin:/c/OSGEO4~1/apps/grass/grass78/bin:/c/OSGEO4~1/apps/grass/grass78/scripts:/c/OSGEO4~1/apps/grass/grass78/lib:.:/c/OSGEO4~1/apps/Python37/lib/site-packages/pywin32_system32
GRASS_MESSAGE_FORMAT=plain
GRASS_PROJSHARE=C:\OSGEO4~1\share\proj
PS1=GRASS 7.8.4>
GRASS_VERSION=7.8.4
GRASS_HTML_BROWSER=start
GRASS_RENDER_WIDTH=640
GRASS_RENDER_TRUECOLOR=true
GRASS_RENDER_IMMEDIATE=png
GRASS_ADDON_BASE=C:\Users\Chris\AppData\Roaming\GRASS7\addons
GRASS_RENDER_FILE_READ=true


All the C:\ paths indicate Windows.

Moritz

Am 11. März 2021 21:37:01 MEZ schrieb Chris Bartolomei :
> Helmut ... thank you for your example however I think there is a 
> misunderstanding of what I am trying to do.  I am using GRASS on Linux (on a 
> cluster) and the issue I am experiencing is overlaying two polygon maps 
> (layers in Arc-speak). Points and lines on top of ONE set of polygons works 
> fine as you have shown, however using two or more polygon maps (layers) does 
> not seem to work. I attached an example of what i am trying to achieve: Take 
> for instance a polygon representing Italy and you wanted it colored dark 
> gray, then you want to overlay on top of that an administrative map showing 
> only the areas of Lazio and Liguria colored in blue but no other 
> administrative areas. The result would look like the Italy_sample.png file i 
> attached (I made is using ArcPro as i am not in the office with access to our 
> cluster).  This is what is not working using the d.mon=png, d.vect tools. 
> Could you please try something similar and see if it works for you (on 
> linux)?v/rChris
> 
>
>On Tuesday, March 2, 2021, 2:38:45 PM EST, Helmut Kudrnovsky 
>  wrote:  
> 
> >I don't see anything immediately wrong. Maybe it is a specific MS
>>Windows issue I cannot reproduce here in GNU/Linux.
>>
>>@Helmut any ideas ?
>
>tested here in the following way in OSGeo4W-winGRASS 7.8.5
>
>(1) changing the working directory via GUI > change working directory
> 
> cd "D:\temp\testgrassrender"                                                  
>  
>Working directory changed to:                                                  
>"D:\temp\testgrassrender"
>
>(2) in OSgeo4W-winGRASS-windows console (no msys needed!), also change here to 
>the new wd:
>
>C:\>cd D:\temp\testgrassrender
>C:\>d:
>
>(3) put the variables and d.-commands into a bat-file into the working 
>directory (D:\temp\testgrassrender\mytest.bat):
>
>REM start of the batch file
>
>set GRASS_RENDER_IMMEDIATE=png
>set GRASS_RENDER_WIDTH=640
>set GRASS_RENDER_HEIGHT=480
>set GRASS_RENDER_TRANSPARENT=true
>set GRASS_RENDER_TRUECOLOR=true
>set GRASS_RENDER_FILE_COMPRESSION=0
>set GRASS_MESSAGE_FORMAT=plain
>set GRASS_RENDER_FILE_READ=TRUE
>
>g.region vect=census_wake2000
>d.vect map=census_wake2000 fill_color=none
>d.vect map=roadsmajor color=255:0:0:255
>d.vect map=schools_wake fill_color=0:128:0:255 icon=basic/circle size=10
>
>REM end of the batch file
>
>=> see here: in order to set a variable in the windows world, use e.g. set 
>GRASS_RENDER_IMMEDIATE=png instead if export GRASS_RENDER_IMMEDIATE=png in the 
>*nix world
>
>(4) start your batch file in the windows command line:
>
>D:\temp\testgrassrender>mytest.bat
>
>D:\temp\testgrassrender>set GRASS_RENDER_IMMEDIATE=png
>D:\temp\testgrassrender>set GRASS_RENDER_WIDTH=640
>D:\temp\testgrassrender>set GRASS_RENDER_HEIGHT=480
>D:\temp\testgrassrender>set GRASS_RENDER_TRANSPARENT=true
>D:\temp\testgrassrender>set GRASS_RENDER_TRUECOLOR=true
>D:\temp\testgrassrender>set GRASS_RENDER_FILE_COMPRESSION=0
>D:\temp\testgrassrender>set GRASS_MESSAGE_FORMAT=plain
>D:\temp\testgrassrender>set GRASS_RENDER_FILE_READ=TRUE
>D:\temp\testgrassrender>g.region vect=census_wake2000
>D:\temp\testgrassrender>d.vect map=census_wake2000 fill_color=none
>d.vect komplett.
>
>D:\temp\testgrassrender>d.vect map=roadsmajor color=255:0:0:255
>d.vect komplett.
>
>D:\temp\testgrassrender>d.vect map=schools_wake fill_color=0:128:0:255 

Re: [GRASS-user] Creating a png file with multiple vector maps

2021-03-02 Thread Moritz Lennert

Sorry, Chris, I lost this out of my sight.

I don't see anything immediately wrong. Maybe it is a specific MS 
Windows issue I cannot reproduce here in GNU/Linux.


@Helmut any ideas ?

Moritz

On 17/02/21 19:17, Chris Bartolomei wrote:

Good afternoon Moritz - thank you for the feedback :)
I've been able to get GRASS 7.8 running with msys on my pc so I can send 
images etc. now... I tried repeating what I had done at work and I have 
the same results ... I also downloaded the Spearfish dataset as you 
suggested and brought in the boundary_county vector. I can go into 
Properties and fill color orange and outline gray, but I go to the 
console and do the d.vect map=boundary_county color=red 
fill_color=orange and all I get is the red boundaries.I attached an 
image of everything ... the Layer Manager, the Display window, the msys 
console window with my commands run and all my exported GRASS variables, 
and the resultant png image.
I've tried this with several other polygon vector files and I get the 
same darn thing.  Can you see anything wrong with my variable settings ?


GRASS 7.8.4> v.info -t boundary_county@WarningPoints #from the Spearfish 
dataset

nodes=1114
points=0
lines=0
boundaries=1910
centroids=926
areas=926
islands=130
primitives=2836
map3d=0

GRASS 7.8.4> env | grep GRASS
MANPATH=C:\OSGEO4~1\apps\grass\grass78\docs\man;C:\Users\Chris\AppData\Roaming\GRASS7\addons\docs\man
GRASS_PYTHON=C:\OSGEO4~1\bin\python3.exe
GRASS_RENDER_TRANSPARENCY=true
GRASS_PAGER=more
GRASS_GNUPLOT=gnuplot -persist
GRASS_RENDER_PNG_COMPRESSION=0
GRASS_RENDER_FILE_COMPRESSION=0
GRASSBIN=C:\OSGEO4~1\apps\grass\grass78\bin
GRASS_RENDER_FILE=test.png
GRASS_SH=C:\OSGEO4~1\apps\msys\bin\sh.exe
GRASS_RENDER_HEIGHT=480
PATH=/c/OSGEO4~1/apps/grass/grass78/lib:/c/OSGEO4~1/apps/grass/grass78/bin:/c/Users/Chris/AppData/Roaming/GRASS7/addons/bin:/c/OSGEO4~1/apps/Python37:/c/OSGEO4~1/apps/Python37/Scripts:/c/OSGEO4~1/apps/Python27/Scripts:/c/OSGEO4~1/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBem:/usr/bin:/c/Program 
Files/RStudio/bin:/c/OSGEO4~1/apps/grass/grass78/bin:/c/OSGEO4~1/apps/grass/grass78/scripts:/c/OSGEO4~1/apps/grass/grass78/lib:.:/c/OSGEO4~1/apps/Python37/lib/site-packages/pywin32_system32

GRASS_MESSAGE_FORMAT=plain
GRASS_PROJSHARE=C:\OSGEO4~1\share\proj
PS1=GRASS 7.8.4>
GRASS_VERSION=7.8.4
GRASS_HTML_BROWSER=start
GRASS_RENDER_WIDTH=640
GRASS_RENDER_TRUECOLOR=true
GRASS_RENDER_IMMEDIATE=png
GRASS_ADDON_BASE=C:\Users\Chris\AppData\Roaming\GRASS7\addons
GRASS_RENDER_FILE_READ=true

GRASS 7.8.4> d.vect map=boundary_county@WarningPoints color=red 
fill_color=orange

d.vect complete.
GRASS 7.8.4>

Thanks again ... and sorry to bother you so much!
:)
Chris


On Wednesday, February 17, 2021, 7:57:08 AM EST, Moritz Lennert 
 wrote:



Hi Chris,

On 17/02/21 02:30, Chris Bartolomei wrote:
 > Oh !! Sooo close ! I can get the two vector maps to overlay and
 > display but no matter what I do I cannot get them to do a color fill ...
 > ugh ... fill_color does nothing. I can use "d.vect map=admin_area
 > color=red" and the boundaries change to red, but "d.vect map=admin_area
 > color=black fill_color=red" and i do not get any filled color. So
 > frustrating. I thought maybe my shapefile imported as just a boundary
 > but when I do a "v.category input=admin_area option=report" I get:
 > Layer/table 1/admin_area
 > type count    min    max
 > point    0    0 0
 > line      0    0 0
 > boundary    0    0 0
 > centroid 59       1        25
 > area             0    0 0
 > face             0    0 0
 > kernel      0    0 0
 > all           59    1    25
 >
 > Should I have areas in there too ??

I'm not really sure what 'area' in the output of v.category actually
refers to, as areas cannot have categories in GRASS GIS.

In order to see if you have areas in your file, check with v.info:

 > I wonder if the import went wonky what is strange is that the ps.map
 > tool fills the polygons just fine.
 > Moritz - could please I ask you to do a v.category on one of your vector
 > maps (v.category input=censuslbk_wwake@PERMANENT 
<mailto:censuslbk_wwake@PERMANENT> option=report) and see

 > if it has areas in it or just centroids like I have?

GRASS 7.8.5 (nc_spm_08_grass7):~ > v.info -t boundary_county
nodes=1114
points=0
lines=0
boundaries=1910
centroids=926
areas=926
islands=130
primitives=2836
map3d=0

but

 >v.category boundary_county op=report
Layer/table: 1/boundary_county
type      count        min        max
point          0          0          0
line          0          0          0
boundary      0          0          0
centroid    926          1        926
area          0          0          0
face

Re: [GRASS-user] Code sprint is now (OGC-OSGeo-ASF 2021)

2021-02-17 Thread Moritz Lennert



Am 17. Februar 2021 17:40:03 MEZ schrieb Luca Delucchi :
>Hi all,
>
>On Wed, 17 Feb 2021 at 17:29, Vaclav Petras  wrote:
>>
>> Code sprint is now!
>>
>
>I'm trying to connect sometime, specially during Italian evening time
>
>>
>> Post you plan here:
>>
>> https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/issues/2
>>
>
>could make sense to start a v.in.ogc.features to import features from
>OGC API Feature service using owslib library?

+1

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


Re: [GRASS-user] Creating a png file with multiple vector maps

2021-02-17 Thread Moritz Lennert

Hi Chris,

On 17/02/21 02:30, Chris Bartolomei wrote:
Oh !! Sooo close ! I can get the two vector maps to overlay and 
display but no matter what I do I cannot get them to do a color fill ... 
ugh ... fill_color does nothing. I can use "d.vect map=admin_area 
color=red" and the boundaries change to red, but "d.vect map=admin_area 
color=black fill_color=red" and i do not get any filled color. So 
frustrating. I thought maybe my shapefile imported as just a boundary 
but when I do a "v.category input=admin_area option=report" I get:

Layer/table 1/admin_area
type count    min    max
point    0    0 0
line      0    0 0
boundary    0    0 0
centroid 59       1        25
area             0    0 0
face             0    0 0
kernel      0    0 0
all           59    1    25

Should I have areas in there too ??


I'm not really sure what 'area' in the output of v.category actually 
refers to, as areas cannot have categories in GRASS GIS.


In order to see if you have areas in your file, check with v.info:

I wonder if the import went wonky what is strange is that the ps.map 
tool fills the polygons just fine.
Moritz - could please I ask you to do a v.category on one of your vector 
maps (v.category input=censuslbk_wwake@PERMANENT option=report) and see 
if it has areas in it or just centroids like I have?


GRASS 7.8.5 (nc_spm_08_grass7):~ > v.info -t boundary_county
nodes=1114
points=0
lines=0
boundaries=1910
centroids=926
areas=926
islands=130
primitives=2836
map3d=0

but

>v.category boundary_county op=report
Layer/table: 1/boundary_county
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid 926  1926
area   0  0  0
face   0  0  0
kernel 0  0  0
all  926  1926


In order to find out if the issue comes from your data or from your 
installation of GRASS GIS, you can also download the NC demo data set 
from https://grass.osgeo.org/download/data/#NorthCarolinaDataset and try 
to reproduce what I did in order to see if it works.


Moritz

On Tuesday, February 16, 2021, 11:20:31 AM EST, Chris Bartolomei 
 wrote:



Well - that does indeed work for you.  I'll try your settings when I get 
into the office - we're running GRASS on a RHEL 7 cluster - and see what 
I can come up with.

It would be sooo much better if it worked like yours did!
Thank you so much for taking the time and testing this out
:)
v/r
Chris

On Tuesday, February 16, 2021, 11:07:10 AM EST, Moritz Lennert 
 wrote:



On 16/02/21 15:54, Chris Bartolomei wrote:
 > Mortiz - are those vector layers areas ? I'm guessing the census is an
 > area, the roads are lines and the schools are points, yes?  I'm having
 > an issue overlaying two area maps (polygons). i can only get one to show
 > ... I have tried your method with all the export GRASS_RENDER* variables
 > but I have a country polygon map as the bottom later and a selection of
 > a few administrative areas (provinces/states) as the top map and I can
 > only get one or the other to show up. It almost seems as if the
 > transparency doesn't work and what should be transparent in the admin
 > map is actually the background color and blocks the country from 
being seen.

 > Could you please try your method with a couple area (polygon) vector
 > maps overlaying each other?

export GRASS_RENDER_IMMEDIATE=png
export GRASS_RENDER_WIDTH=640
export GRASS_RENDER_HEIGHT=480
export GRASS_RENDER_TRUECOLOR=true
export GRASS_RENDER_FILE_COMPRESSION=0
export GRASS_MESSAGE_FORMAT=plain
export GRASS_RENDER_FILE_READ=TRUE
export GRASS_RENDER_FILE=$HOME/test.png

g.region vect=census_wake2000
d.vect map=census_wake2000@PERMANENT <mailto:census_wake2000@PERMANENT> 
fill_color=grey
d.vect map=censusblk_swwake@PERMANENT 
<mailto:censusblk_swwake@PERMANENT> fill_color=red


I've tried with

export GRASS_RENDER_TRANSPARENT=TRUE
and
export GRASS_RENDER_TRANSPARENT=FALSE

As you can see in the attached images, the overlay seems to work without
any issues (or I don't understand what you are looking for exactly) and
setting GRASS_RENDER_TRANSPARENT decides on whether the background
should be transparent or not.

A second test in the same data set, but with different layers:

export GRASS_RENDER_TRANSPARENT=TRUE
export GRASS_RENDER_FILE=$HOME/test_NC_TRUE.png
g.region vect=boundary_county
d.vect map=boundary_county@PERMANENT <mailto:boundary_county@PERMANENT>
d.vect map=boundary_municp@PERMANENT <mailto:boundary_municp@PERMANENT> 
fill_color=255:255:0:255


export GRASS_RENDER_TRANSPARENT=FALSE
export GRASS_RENDER_FI

Re: [GRASS-user] Creating a png file with multiple vector maps

2021-02-16 Thread Moritz Lennert

Hi Chris,

For me, the following works with the current stable GRASS GIS (7.8.5) 
and using maps from the NC demo data set:


export GRASS_RENDER_IMMEDIATE=png
export GRASS_RENDER_WIDTH=640
export GRASS_RENDER_HEIGHT=480
export GRASS_RENDER_TRANSPARENT=true
export GRASS_RENDER_TRUECOLOR=true
export GRASS_RENDER_FILE_COMPRESSION=0
export GRASS_MESSAGE_FORMAT=plain
export GRASS_RENDER_FILE_READ=TRUE

g.region vect=census_wake2000
d.vect map=census_wake2000@PERMANENT fill_color=none
d.vect map=roadsmajor@PERMANENT color=255:0:0:255
d.vect map=schools_wake@PERMANENT fill_color=0:128:0:255 
icon=basic/circle size=10


I attach a small thumbnail of the resulting PNG file.

Moritz


On 11/02/21 18:54, Chris Bartolomei via grass-user wrote:

Good morning Anna,
It took quite a while of trial and error but I worked out a method that 
kindof works:
First off - unless someone says otherwise, you can't use the PNG driver 
(d.mon) method to overlay more than one polygon vector. Sorry - it just 
doesn't work. You CAN use the ps.map method - that works really well 
generating the image however it by default assumes you are printing on 
an A4 piece of paper so there's all sorts of white space.  The image is 
centered at the top of this fictional piece of paper. In your postscript 
rules file you can use the "maploc" command to position the image 
elsewhere on the page. This is necessary because the next trick changes 
the paper dimensions but it assumes the origin is the lower left corner 
and therefore clips anything that is above the new dimensions. Back to 
postscript commands in the rules file first though ... the ps.map maploc 
command uses inches (why?? it should be points) so an A4 page is 8.27" x 
11.69" points are 1/72 of an inch thus 595p x 842p - it also has a 
default 36p margin (0.5 inch). You'll need those numbers later. maploc 
also lets you set the size of your image box:  maploc {x offset from 
left edge} {y offset from top} {width of box} {height of box} Note: this 
is all done via a BASH script with GRASS 7.4 on Linux (RHEL 7), not 
python. This is my postscript rules file:


maploc 0.1 6.815 6.5 4.875 #468p x 351p map box moved down towards the 
bottom of the page
# note that if you push it too far down to where the box would run off 
the bottom, the image is
# resized to fit on the page so do some testing to come up with the 
correct values
# also I found the computational region controls the aspect ratio so 
although I say

# 6.5 x 4.875 with the above maploc command, I got a 6.5 x 3.8 inch box.
border y # add a border to the map frame (box)
   color 81:81:81 # shade of gray
   end # end the border controls
vareas admin_area # top vector layer to display
   layer 1 # attribute table to use
   rgbcolumn area_color # name of column holding R:G:B values to fill 
the polygons

   color 153:153:153 #boundary color
   end # end the admin_area controls
vareas Country # this is the bottom vectors to display
   color 210:210:210 #boundary color
   fcolor 153:153:153 #fill color for all polygons
   end # end the Country controls

Here's the command to run to generate the postscript file:

ps.map input=$HOME/ps_rules.txt out=$HOME/color_admin.ps --overwrite

To convert the postscript to PNG I had to use ghostscript - there are 
other tools you can use though.


gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r300 -dTextAlphaBits=4 
-dGraphicsAlphaBits=4 -dDEVICEWIDTHPOINTS=473 -dDEVICEHEIGHTPOINTS=276 
-dFIXEDMEDIA -dPSFitPage -sOutputFile=$HOME/color_admin.png -c 
"<> setpagedevice" -f $HOME/color_admin.ps


So the above line needs some explaining 
(http://www.ghostscript.com/doc/9.27/Use.htm) but in a nutshell, the 
parameters to play with are first the Pageoffset [x y] values. They are 
in points not inches ... 1/72 inch = 1 point ... remember the 1/2" 
margins? the -34 gives me 2 points of white space to the left edge of 
the map frame, the 78 I had to play with to push the map frame down to 
the right spot.
Next is the DEVICEWIDTHPOINTS and DEVICEHEIGHTPOINTS ... again in points 
... this "trims" the paper to height and width ... set something then 
run it and view the results. Adjust and run again until you get it correct.


It's a royal pain but it seems to work this way. It would sure be nice 
to create a GRASS workspace file and just say "convert this workspace to 
an image" with everything all laid out nicely - like Arc does exporting 
their mxd map files...


I hope this helps someone !
:)
Chris


On Wednesday, February 10, 2021, 11:08:00 PM EST, Anna Petrášová 
 wrote:





On Tue, Feb 9, 2021 at 4:41 PM Chris Bartolomei > wrote:


Hi Anna - thank you for the suggestion - I tried it but alas, still
it only outputs a single vector map (layer). I can get either the
Country vector or the admin_areas vector, but not both overlaid.
:(
Chris


I realized you are using both environmental variables and d.mon, that 
might cause some issues, you use one or the 

[GRASS-user] Elections results and new GRASS GIS PSC

2021-02-09 Thread Moritz Lennert
[Online version of this announcement: 
https://grass.osgeo.org/news/2021_02_05_new_grass_psc/ 
<https://grass.osgeo.org/news/2021_02_05_new_grass_psc/>]



 New GRASS GIS Project Steering Committee

By the end of last year, the GRASS GIS project called for PSC members 
election. A total of/13 GRASS GIS contributors/were nominated by the 
community to cover the nine PSC positions.


After the election itself, the new GRASS GIS PSC is composed of the 
following nine members ranked by number of votes:


 * Markus Neteler (95)
 * Anna Petrášová (88)
 * Helena Mitášová (86)
 * Martin Landa (83)
 * Verónica Andreo (76)
 * Moritz Lennert (74)
 * Václav Petráš (68)
 * Michael Barton (58)
 * Huidae Cho (56)

For completeness, all relevant candidacy communications, as well as 
details about the voting process, have been published 
at:https://trac.osgeo.org/grass/wiki/PSC/Election2020 
<https://trac.osgeo.org/grass/wiki/PSC/Election2020>


On behalf of the GRASS GIS project, we would like to thank/Hernán De 
Angelis/who agreed to serve as Chief Returning Officer (CRO) and all 
community members for their participation. Furthermore, we want to 
acknowledge the contributions of former PSC members and all nominees. 
The development of GRASS GIS is a collective effort and we are all part 
of it regardless of our role. So,*CONGRATS to everyone!*



 New PSC chair person

There’s yet one more change to report. GRASS GIS PSC has a new chair 
person:*Veronica Andreo* <https://veroandreo.gitlab.io/>. She works as a 
researcher in Argentina focusing on environmental drivers of 
vector-borne disease outbreaks and works primarily with satellite 
imagery and GIS-based time series analysis. For years, Vero has been 
very active in the GRASS GIS project, especially with documenting 
complex topics in a user friendly way, testing, development of the new 
website, coding of addons, outreach, social media and more. She 
regularly introduces GRASS GIS to new users and teaches introductory and 
advanced courses and workshops. We thank Vero for accepting this challenge!


We want to acknowledge and thank*Markus Neteler* 
<https://www.mundialis.de/neteler/>for his enormous efforts and 
passionate work on pushing the GRASS GIS development for more than 20 
years. While Markus was re-elected as PSC member, he preferred to pass 
on the position of chairperson to a new PSC member. Markus is one of the 
long runners in the project, as he already started to discover the 
software in 1993 as a student. In 1998, he set up a “European GRASS 
site” at the University of Hannover, which evolved into an international 
development team. From manual source code management, he was part of the 
journey to a modern, GitHub-based development system including code 
quality testing. Markus is known to be active in conferences, code 
sprints, bug fixing, user support, infrastructure management, project 
and release management, etc. He will continue to do so!



 PSC roles & tasks

In addition to the chair role, in the firstPSC 
<https://trac.osgeo.org/grass/wiki/PSC>meeting, we have defined some 
basic areas/tasks and PSC members responsible for them:


 * Treasurer - Moritz
 * Release manager - Markus, Martin
 * Infrastructure manager - Markus
 * Translation manager - Huidae
 * Website & Marketing manager - Michael, Vero
 * Github manager - Vaclav

Of course, *everyone is invited to join and contribute*in these and 
other areas:https://trac.osgeo.org/grass/wiki/PSC/Roles 
<https://trac.osgeo.org/grass/wiki/PSC/Roles>.


/The GRASS Development Team, Feb 2021/

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


Re: [GRASS-user] Grass gis surface roughness

2021-02-06 Thread Moritz Lennert
Dear Aylin,

Please post such questions to the grass-user mailing list [1], or on the 
relevant stack exchange forum, not privately to developers.

You can look at 
https://grass.osgeo.org/grass78/manuals/addons/r.roughness.vector.html to see 
if this corresponds to what you want. Otherwise you could probably roll your 
own formula with r.mapcalc, possibly combined with r.neighbors.

Moritz

Am 6. Februar 2021 19:03:29 MEZ schrieb "aylin çiftci" 
:
>
>
>Hi from Turkey,,
>İ am geologist, study morphotectonic and paleoseismology,
>İ research grass gis for moprhotectonic analysis,
>İ need surface roughness analysis on grass gis, do you help me for this 
>analysis,, a video or your researchs
>
>Thanks for publications
>
>Best regards
>Aylin
>
>
>
>
>iPhone’umdan gönderildi
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Support GRASS GIS financially !

2021-02-05 Thread Moritz Lennert
Dear all,

We just received our very first sponsorship contribution of 2021 (thank 
you !) and we want to take this occasion to thank all those who sponsored us 
last year and remind you that the GRASS 
GIS project needs financial support in order to:

- organize very valuable face-to-face meetings and sprints gathering 
developers and the wider community for a few days to concentrate on 
improving GRASS GIS

- fund specific fixes or enhancements (this year the use of 
micro-budgets for such fixes is planned)

- maintain our website

- produce marketing material to spread the word

You can see the list of past individual and corporate sponsors here:

https://grasswiki.osgeo.org/wiki/Sponsors

As you can see, no amount is too small: if all GRASS GIS users give just 
a small amount regularly, we will already have a sizeable budget to work 
with ! And I challenge you to find software that does all that GRASS GIS 
does for 5€/$ or 10 €/$ a year ;-)

So, just go to https://grass.osgeo.org/contribute/sponsoring/ and help 
us make GRASS GIS better.

If you want to see more details about how we use the money, note that 
the project budgets are public. For 2021 see 
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Budget_2021.

The GRASS GIS Project Steering Committee
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] increase efficiency of analysis with r.grow.distance aka Euclidean allocation

2021-01-29 Thread Moritz Lennert



Am 29. Januar 2021 01:30:03 GMT+00:00 schrieb karsten :
>Hi All,
> 
>I am working on a project that requires to find the middle boundary between
>raster regions (of the same value) using a maximum buffer distance. The
>raster input I am using is quite large like 5m resolution and 10 by
>10 cells. One approach I took was to fill all cells in areas outside the
>raster regions in question which I will need to buffer to NULL 
>and then using the r.grow.distance in GRASS (similar to the Tool Euclidean
>allocation in ArcGIS). 
>
>This works with smaller files but with a big input like the one above
>calculation time is very long or might crash even on a fast PC. The only
>remedy I found (apart from throwing larger RAM or hardware at the task) 
>so far was cutting up the raster file in tiles and running the analysis on
>each tile and putting the results back afterwards to get to final result
>layer.
> 
>Would anyone have hints if there are other approaches that I could increase
>the efficiency of this analysis in GRASS or have any knowledge of other tool
>sets such as R or python scripts that are already available for something
>like this ?


Working tile by tile allows you to parallelize the processes, and so treat 
several tiles at once. Obviously tiling does raise the issue of the border 
regions, so sufficient overlap will be necessary.

Moritz

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


Re: [GRASS-user] [GRASS-dev] [GRASS GIS Elections 2020] Voting phase closed, presentation of results

2021-01-26 Thread Moritz Lennert
Dear all !

Thank you very much for the honor of being part of the new PSC !

Looking forward to working with everyone, whether elected or not, on bringing 
this great project forward.

Special kudos to Hernán for the great job !

Moritz

Am 25. Januar 2021 12:30:46 GMT+00:00 schrieb "Chief Return Officer (CRO) - 
GRASS GIS election 2020" :
>Dear members of the GRASS GIS community,
>
>The voting phase of the GRASS GIS Election 2020 is now finished. Out of 
>245 registered voters, 98 completed the survey. The results are shown 
>below and are now available in the Trac Wiki.
>
>
>Voting result (ranking, name, number of votes):
>
>  1. Markus Neteler 95
>  2. Anna Petrášová 88
>  3. Helena Mitasova  86
>  4. Martin Landa   83
>  5. Verónica Andreo76
>  6. Moritz Lennert 74
>  7. Vaclav Petras  68
>  8. Michael Barton 58
>  9. Huidae Cho 56
>10. Helmut Kudrnovsky   55
>11. Peter Löwe  52
>12. Māris Nartišs   47
>13. Stefan Blumentrath  44
>
>
>
>The new PSC is then composed of the following 9 members:
>
>  1. Markus Neteler 95
>  2. Anna Petrášová 88
>  3. Helena Mitasova      86
>  4. Martin Landa   83
>  5. Verónica Andreo76
>  6. Moritz Lennert 74
>  7. Vaclav Petras  68
>  8. Michael Barton 58
>  9. Huidae Cho 56
>
>
>
>Regards,
>
>
>Hernán
>
>Chief Return Officer (CRO)
>
>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How would I make this odd choropleth in GRASS?

2021-01-18 Thread Moritz Lennert
Hi,

Am 19. Januar 2021 06:28:37 MEZ schrieb Dheeraj Chand 
:
>I have a shapefile of US counties in Texas. A map that I am trying to conceive 
>would 1) separate the polygons to add some distance / whitespace between the 
>constituting polygons 2) preserve their relative positioning 3) color the 
>polygons on a graduation of average income and 4) while preserving shapes, 
>increase or decrease size based on population . 
>
>Am I crazy, is there such a map ? What would it be called or described as? 

This generally called a cartogram or a chorogram: 
https://en.wikipedia.org/wiki/Cartogram?wprov=sfla1

Today the most used method, AFAIK, is this one: 
https://www.pnas.org/content/101/20/7499

>How could I make this in GRASS?

You can't make this in GRASS GIS.

You can find code from one of the authors of above paper here: 
http://www-personal.umich.edu/~mejn/cart/.

QGIS used to have plugin for this: https://plugins.qgis.org/plugins/cartogram/
Don't know if that is still active.

Then there is scapetoad:
http://chorogram.choros.ch/scapetoad/chorogram.php

In R you can use Rcartogram: 
https://cran.r-project.org/web/packages/cartogram/index.html

Geoda and others also offer this functionality.

Moritz

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


[GRASS-user] Statement Moritz Lennert

2021-01-14 Thread Moritz Lennert

Dear all,

I thank those who nominated me for putting my name up once again. Most 
of you will have seen me around as I'm one of the old ones, active in 
the GRASS GIS community for over 20 years now.


In the past I've have worked on many different parts of GRASS: 
documentation, the first attempts of a native MS Windows port, a series 
of modules, with, in the last years, a specific focus on remote sensing 
and particularly the entire tool chain for object-based image assessment.


I have been in the GRASS PSC since 2012, and have been active as GSoc 
mentor, "volunteered" as financial / bank manager of the project, 
contributor of presentations at different FOSS4G conferences, 
participated in several sprints, etc Having spent over 20 years in 
academia, I have also taught with GRASS GIS at university for quite a 
long time. I'm also one of the co-founders of the Belgian chapter of the 
OSGeo foundation and co-organiser of the Belgian foss4g.be conferences.


Recently, I have left university, however, and am now employed by a 
private company, https://bluesquarehub.com, that develops technologies 
for the health sector in developing countries. I was hired to develop 
the geospatial data aspect of their work (they do use GRASS GIS in a 
model of health facility accessibility we developed for them when I was 
still at university). As this is still quite new I don't know, yet, how 
much time I will have for actively contributing to GRASS GIS, nor for 
even just following all of the exiting continuous developments and 
discussions on the lists and in github. If elected, my presence will 
probably be more subdued, but I do promise to actively play the role of 
"old wise guy" and upholder of some of the historical traditions and 
values of GRASS GIS development.


At the same time, I would be more than happy to see new faces in the PSC 
and to leave my place to them if the community so desires. I promise 
that I will continue to hang around whatever the results of the 
elections and to manage our bank account and paypal money pool :-).


I'm proud to be part of such a wonderfully friendly and innovative 
community !


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


Re: [GRASS-user] Missing ps.map example

2021-01-05 Thread Moritz Lennert

On 5/01/21 10:34, n...@nikosalexandris.net wrote:
In http://homepages.ulb.ac.be/~mlennert/grass/psmap/index.html there is 
this nice example 
http://homepages.ulb.ac.be/~mlennert/grass/psmap/ages.png. The source 
code for it is missing. Any chance to get hands on it?


There is a chance but since I've left the unversity, I will have to dig 
into some archives. I'll make it available ASAP.


Moritz

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


Re: [GRASS-user] Can GRASS create color table in16 bit?

2021-01-02 Thread Moritz Lennert
AFAIK, GRASS only supports 8 bit color definitions, i.e. 0-255 for each of R, 
G, and B. This allows for 16 million different color tones which is generally 
enough.

Moritz

Am 2. Januar 2021 08:13:07 MEZ schrieb mega saputra :
>Dear all,
>
>I try to create color table in 16 bit. That is in attachment. But, when I
>set color table interactively, then I input that file (in attachment), then
>I click Load. There is a message : "Invalid color table format". Do I
>missing something?
>
>Thank you.
>
>Regards,
>mega
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] [GRASS-dev] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

2020-12-11 Thread Moritz Lennert
Dear all,

Many thanks to Hernán De Angelis who has agreed to serve as CRO !

We will put things in place with him to launch the entire process as soon as 
possible.

Moritz

Am 10. Dezember 2020 09:14:55 MEZ schrieb Moritz Lennert 
:
>Dear all,
>
>As part of the effort to guarantee a solid and sustainable governance of 
>GRASS GIS development, and in accordance with OSGeo guidelines, we have 
>a Project Steering Committee (PSC) [1]. Although most decisions are 
>taken by consensus via the mailing lists or via discussions in github 
>issues, some decisions go through this committee: annual budget, 
>admission of new developers into the core development team, and some 
>fundamental decisions (recent example: phasing out of a 32-bit version 
>for MS Windows).
>
>The last election for this committee was in 2016 and at the time we 
>decided that the PSC should be renewed approximately every 3 years. We 
>are already beyond this time frame and so a new election should happen, 
>soon. The general outline of the procedure has been drafted [2].
>
>The first step in that procedure is the nomination of one (or several) 
>Chief Return Officer(s) (CRO) who will oversee the election process and 
>who should not be a member of the current PSC, nor aim at becoming a 
>member of the new PSC.
>
>Is anyone willing to play this role ? You can just respond directly here 
>on the list to display your interest.
>
>In a second step, we will be looking for candidates for the new PSC. For 
>an overview of the (fairly low-noise) activity of the PSC, you can 
>browse through the archives of its public mailing list [3]. You will see 
>that it is not a job that requires a lot of work, but it is an essential 
>job nevertheless. Also: no need to be a developer to be part of the PSC, 
>users should also be represented.
>
>On behalf of the current PSC,
>Moritz
>
>[1] https://trac.osgeo.org/grass/wiki/PSC 
><https://trac.osgeo.org/grass/wiki/PSC>
>
>[2] https://trac.osgeo.org/grass/wiki/PSC/Election2020
>
>[3] https://lists.osgeo.org/pipermail/grass-psc/
>___
>grass-dev mailing list
>grass-...@lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

2020-12-10 Thread Moritz Lennert

On 10/12/20 14:43, Rich Shepard wrote:

On Thu, 10 Dec 2020, Moritz Lennert wrote:


The first step in that procedure is the nomination of one (or several)
Chief Return Officer(s) (CRO) who will oversee the election process and
who should not be a member of the current PSC, nor aim at becoming a
member of the new PSC.


Moritz,

What does the position involve and require?


Basically the tasks are:

- Announce elections and election procedures
- Receive nominations and confirmation from candidates that they accept 
to be nominated

- Fill out the list of nominees on the wiki page [1]
- Collect some info from the candidates and put it on the wiki page (see 
at the very end of the page the suggestion, i.e. ask each candidate to 
respond to the question  "What should the community expect from your PSC 
membership?")
- organize the election (configure vote on 
https://vote.heliosvoting.org/, launch vote, launch reminder, tally votes)

- announce results
 - deal with any complaints (I doubt that there will be any)

Moritz

[1] https://trac.osgeo.org/grass/wiki/PSC/Election2020
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

2020-12-10 Thread Moritz Lennert

Dear all,

As part of the effort to guarantee a solid and sustainable governance of 
GRASS GIS development, and in accordance with OSGeo guidelines, we have 
a Project Steering Committee (PSC) [1]. Although most decisions are 
taken by consensus via the mailing lists or via discussions in github 
issues, some decisions go through this committee: annual budget, 
admission of new developers into the core development team, and some 
fundamental decisions (recent example: phasing out of a 32-bit version 
for MS Windows).


The last election for this committee was in 2016 and at the time we 
decided that the PSC should be renewed approximately every 3 years. We 
are already beyond this time frame and so a new election should happen, 
soon. The general outline of the procedure has been drafted [2].


The first step in that procedure is the nomination of one (or several) 
Chief Return Officer(s) (CRO) who will oversee the election process and 
who should not be a member of the current PSC, nor aim at becoming a 
member of the new PSC.


Is anyone willing to play this role ? You can just respond directly here 
on the list to display your interest.


In a second step, we will be looking for candidates for the new PSC. For 
an overview of the (fairly low-noise) activity of the PSC, you can 
browse through the archives of its public mailing list [3]. You will see 
that it is not a job that requires a lot of work, but it is an essential 
job nevertheless. Also: no need to be a developer to be part of the PSC, 
users should also be represented.


On behalf of the current PSC,
Moritz

[1] https://trac.osgeo.org/grass/wiki/PSC 



[2] https://trac.osgeo.org/grass/wiki/PSC/Election2020

[3] https://lists.osgeo.org/pipermail/grass-psc/
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Reprojecting to x,y grid

2020-11-19 Thread Moritz Lennert

On 18/11/20 15:01, Ken Mankoff wrote:

Hello,

On 2020-11-17 at 10:06 -08, Ken Mankoff  wrote...

I've successfully worked in rotated pole coordinates (e.g., [1]) but
because I don't know what (x,y) coord contains the pole, I haven't
figured out how to adapt this to the rotated pole situation as in [1].
Anyway, this isn't a rotated pole...


I was incorrect - this is a rotated pole coordinate system.

When I run the following code on GRASS 7.4, I get the attached graphic. The key 
part here is that the rotated pole is at (lon,lat) = (-200,18).



grass -c EPSG:4326 Gnorm

# Import something into the normal location
v.import input=~/data/Zwally_2012/sectors output=Z

cat << EOF > ./Gnorm/PERMANENT/PROJ_INFO
name: General Oblique Transformation
datum: wgs84
towgs84: 0.000,0.000,0.000
proj: ob_tran
o_proj: latlon
ellps: wgs84
a: 6378137.00
es: 0.0066943800
f: 298.2572235630
lat_0: 0.00
lon_0: 180.00
o_lat_p: 18.0
o_lon_p: -200.0
EOF

# rotated_pole:grid_north_pole_latitude = 18. ;
# rotated_pole:grid_north_pole_longitude = -200.

cat << EOF > ./Gnorm/PERMANENT/PROJ_UNITS
unit: degree
units: degrees
meters: .0174532925
EOF

grass -e -c EPSG:4326 Grot
grass ./Grot/PERMANENT

v.proj location=Gnorm input=Z
g.region vector=Z

d.mon start=wx0
d.vect Z
d.grid 1:0:0


The above code run in GRASS 7.4.0 on a clean Ubuntu 18.04 VM produces the 
attached graphic. However, when I run the exact same code in GRASS 7.8.4 it 
does not work. The reproject/rotate does not occur, and Greenland remains at 
62-82 N, and 22-72 W.

The contents of the "Gnorm" folders is appears identical. The md5sum of 
DEFAULT_WIND, MYNAME, PROJ_EPSG, PROJ_INFO, and PROJ_UNITS are all the same.

I can do the work in GRASS 7.4 in a VM but I'd prefer to do it on the main 
development machine in the latest GRASS. Does anyone have any idea why this 
feature stopped working?


Maybe because of changes linked to proj6 support ? Markus Metz will know.

Moritz



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

Re: [GRASS-user] Recommendations for v.surf.rst parameters for huge region

2020-10-21 Thread Moritz Lennert
Just to add my 2¢ on one aspect: IMHO, unless you have some aesthetic or other 
reasons to do otherwise, smooth should reflect the error in your data. As it 
determines how far the interpolated surface can be from the observed values, 
the margin of error that you think your data has should be an adequate value.

I therefore wouldn't really tune on smooth, but just set it to one reasonable 
value.

Moritz

Am 21. Oktober 2020 04:12:53 MESZ schrieb "Anna Petrášová" 
:
>Hi,
>
>I don't have an answer but couple notes I can now think of:
>
>- Variable density of points may be a problem, I sometimes had that issue
>with gaps in lidar when it creates visible segments. In that case you need
>to increase npmin, but that substantially increases processing time. The
>default npmin is 300, but that is typically unnecessary, npmin 150 is
>usually ok and runs faster. The segments can be mitigated as well by higher
>tension. I usually use tension between 20-40. I haven't used smooth value
>larger than 5 I think. But again, your data are probably quite different.
>
>- v.surf.rst is parallelized, you need to compile GRASS with openMP to take
>advantage of that
>
>- Have you looked at r.fill.stats? I used it for lidar, first r.in.lidar
>and then fill the rest with r.fill.stats, possibly multiple passes to fill
>larger holes. It uses IDW, and it will be *significantly* faster, although
>v.surf.rst would probably give you better results in the end.
>
>Best,
>Anna
>
>On Fri, Oct 16, 2020 at 3:05 PM Eric Patton 
>wrote:
>
>> Hello list,
>>
>> I am trying to interpolate raster values for a single massive dataset that
>> represents dozens of multibeam bathymetry surveys over a few decades.
>>
>> The region is pretty big: all of Eastern Canada; at 100m resolution there
>> are
>> ~ 464M cells.
>>
>> The raster data has a wide range of completeness; in some areas, there is
>> near 100% coverage - these areas were surveyed with modern sonars and 100%
>> overlap between survey lines. In other areas, the data is very sparse, with
>> ~1km or more between tracklines. These areas would represent surveys from
>> the
>> 70's to 90's using singlebeam echosounders.
>>
>> Firstly, would v.surf.rst be the best module for a massive interpolation
>> job
>> like this?  If not, could you recommend what would be the optimal method?
>>
>> If v.surf.rst is the right module to use, I was wondering if anyone could
>> help
>> with what parameters to use for an area this size, at least as a starting
>> point. I have read the manual several times, but I still don't have a good
>> intuition for how parameters like npmin, segmax, dmin, dmax, smooth all
>> work
>> together.
>>
>> At the moment, I have a script written that accepts a user-supplied number
>> of
>> random positions all over the input raster. For each random point, I obtain
>> the east and north coordinates with v.to.db, feed these to g.region, and
>> grow
>> the region around the point in all four cardinal directions by some value
>> like
>> 10,000m to create an analysis window around each point. I create a polygon
>> vector of this region with v.in.region, and use this polygon to clip my
>> vectorized raster bathymetry with v.clip, and then do v.surf.rst on this
>> clipped vector.
>>
>> I have no other way of knowing what v.surf.rst parameters to use other than
>> trial and error, so I have a 4-level nested 'for' loop written to basically
>> traverse through all permutations of the parameters within the ranges I
>> chosen. So for example, I am exploring all combinations of parameters
>> within
>> these ranges:
>>
>> Tension: 10, 20, 40, 80, 160
>> npmin: 100, 200, 400, 800, 1000
>> smooth: 1, 2, 4, 8, 16, 32
>>
>> With 7 random points selected around the full region, this script will
>> produce
>> a few hundred maps per point, and quite a long time to run. And even more
>> time
>> to look at the results.  I know this isn't the best approach.
>>
>> I am looking for help to find some workable set of parameters to use for
>> the
>> entire dataset from other users who have more experience using this module.
>>
>> Thanks,
>>
>> --
>> Eric Patton
>> Marine Geoscience Technologist
>> Geological Survey of Canada (Atlantic)
>> Natural Resources Canada
>> Bedford Institute of Oceanography
>> 1 Challenger Drive, Dartmouth NS, Canada
>>
>> ___
>> 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] r.in.gdal problem

2020-10-13 Thread Moritz Lennert

On 12/10/20 20:42, chadli Kadri wrote:

Hi;

I am working on grass-gis 7.8 under windows 10 (python 3.7),

when I run my python script on grass-shell this error message appears:

*Unable to open datasource*

**


This is the actual error. Are you sure that this file exists in the 
directory you are running this script in ? It might be better to provide 
the complete path to the file.


Moritz



*Traceback (most recent call last):*

*File "E: \ chadli_docs \ Chadli_DISKDUR \ Desertification \ Data \ 
SRTM_PROJTED \ Sebal70.py", line 45, in *


*g.parse_command ('r.in.gdal', input = files [i], output = 
os.path.splitext (files [i]) [0], overwrite = True)*


**

*grass.exceptions.CalledModuleError: Module run None r.in.gdal --o input 
= LC08_L1TP_197037_20190620_20190704_01_T1_B1.TIF output = 
LC08_L1TP_197037_20190620_20190704_01_T1_B1 ended with error*


*Process ended with non-zero return code 1. See errors in the (error) 
output.*


is there anyone seeing this kind of problem



___
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] remove holes from polygon

2020-10-09 Thread Moritz Lennert

On 8/10/20 18:11, Robert Nuske wrote:

Hi GRASS list,

I am kind of lost and hope someone can point me in the right direction.

Is there a way to automatically (not by manually editing the dataset)
remove all holes in all areas of a vector dataset (I guess that are
polygons without a category within polygons with a category).


What do you mean by remove ? Fill them as separate polygons ? Make them 
part of the containing polygon ?


If the latter and if the holes are all smaller than existing polygons, 
one possible path I see is making them into actual areas using 
v.centroids and then merge them with the outside polygon using v.clean 
with the tool=rmarea.


Moritz

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

Re: [GRASS-user] tiled version for r.neighbors

2020-10-07 Thread Moritz Lennert

On 7/10/20 12:37, Bernardo Santos wrote:

Dear community,

I have recently found that some functions such as r.mapcalc and 
r.textile have their "tiled" versions, whichi is perfect for processing 
things in large extents and fine scale resolution.
I need to perform a moving window analysis, such as using r.neighbors, 
over large areas. Is there already any implementation of a 
"r.neighbors.tiled" or something like that?

(If not, that would definitely be very useful!)


AFAIK, there is no r.neighbors.tiled. Actually, the two others you cite 
were quick hacks from me which I decided to make available in case they 
could be useful.


Several tests by others using r.mapcalc.tiled have not shown significant 
speed increase, and so there is currently a discussion about how to 
solve this (the current idea is to try with r.patch instead of the 
internal python-based patching routine). Unfortunately, I don't have 
much time for GRASS GIS these days, so will not be able to do anything 
about this.


You could have a look at the existing *.tiled modules (see link to the 
code at the bottom of the online man page) to see how they work (not 
very complicated) and try to cook your own for r.neighbors. :-)


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

Re: [GRASS-user] R: exwcuting grass python script from php web page

2020-09-29 Thread Moritz Lennert

Hi Roberta,

I'm really no expert in this domain, so just doing some educated guessing.

On 28/09/20 18:37, roberta fagandini wrote:


On 28/09/20 17:51, roberta fagandini wrote:

Sorry, maybe I didn't explain myself well because actually, I don't get
any error from the php web page, simply the code related to grass is not 
executed.For instance gsetup.init(gisbase, gisdb, location, mapset) does 
not create any file in my /tmp/ folder and the print(gscript.gisenv()) 
is not printed.
I checked the import of the grass libraries (print(sys.modules)) and 
they seem to be correctly imported.


Have you checked your webservers error logs ?

I have already checked and this is the error in the webserver log file

File "importgrass.py", line 82, in 
     main()
   File "importgrass.py", line 71, in main
     rcfile = gsetup.init(gisbase, gisdb, location, mapset)
   File "/usr/lib/grass74/etc/python/grass/script/setup.py", line 170, 
in init

     config_dir = os.path.join(os.getenv('HOME'), config_dirname)
   File "/usr/lib/python3.6/posixpath.py", line 80, in join
     a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType


First of all, the importgrass.py you sent only has 72 lines, so I don't 
know what the line 82 reference in your above error points to.


But most importantly, I would really recommend that you upgrade to a 
newer version of GRASS GIS. Current stable is 7.8. There's been a lot of 
improvement in terms of python3 compatibility and maybe this is an issue 
that has already been resolved.


It sounds like an issue with a variable containing a path. Apparently it 
is of type NoneType...





How do you call the python script from PhP?

I tried  both with:


and



and

        $myfile = fopen("./tmp/script.sh", "w") or die("Unable to open 
file!");

        fwrite($myfile, $intestazione);
        fwrite($myfile, $command);
        fclose($myfile);
        echo exec("/bin/sh ./tmp/script.sh", $output, $return);
        print_r($output);
?>



What happens when you replace '/usr/bin/python3 importgrass.py ' by, for 
example '/usr/bin/grass --version', just to check if other executables 
work ?


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

Re: [GRASS-user] R: exwcuting grass python script from php web page

2020-09-28 Thread Moritz Lennert

On 28/09/20 17:51, roberta fagandini wrote:
Sorry, maybe I didn't explain myself well because actually, I don't get 
any error from the php web page, simply the code related to grass is not 
executed.For instance gsetup.init(gisbase, gisdb, location, mapset) does 
not create any file in my /tmp/ folder and the print(gscript.gisenv()) 
is not printed.
I checked the import of the grass libraries (print(sys.modules)) and 
they seem to be correctly imported.


Have you checked your webservers error logs ?

How do you call the python script from PhP ?

Are you sure that your web server has sufficient permissions to access 
the relevant directories ?


Moritz



*Da:* Moritz Lennert 
*Inviato:* lunedì 28 settembre 2020 17:29
*A:* roberta fagandini ; 
grass-user@lists.osgeo.org 

*Oggetto:* Re: [GRASS-user] exwcuting grass python script from php web page
On 28/09/20 12:10, roberta fagandini wrote:

Hi all!
I wrote a python script with grass to be run from a php web page.
The python script works perfectly if I run it from the terminal but when 
I try to run it from the php web page, the grass related part seems to 
be ignored and the grass session is not launched. I set the grass gis 
environment following this link [0].
  From the php side, I try to launch the python script using both exec(), 
system() and also a bash script to run the python script but I always 
got the same error.


Maybe you could tell us what error you get ?

Moritz


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

Re: [GRASS-user] exwcuting grass python script from php web page

2020-09-28 Thread Moritz Lennert

On 28/09/20 12:10, roberta fagandini wrote:

Hi all!
I wrote a python script with grass to be run from a php web page.
The python script works perfectly if I run it from the terminal but when 
I try to run it from the php web page, the grass related part seems to 
be ignored and the grass session is not launched. I set the grass gis 
environment following this link [0].
 From the php side, I try to launch the python script using both exec(), 
system() and also a bash script to run the python script but I always 
got the same error.


Maybe you could tell us what error you get ?

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

Re: [GRASS-user] How to generate a random DEM Model of given size & resolution

2020-09-28 Thread Moritz Lennert

Hi,

On 28/09/20 13:52, BHARATH RAM wrote:

Hello,

I want to generate a set of random DEMs ( epsg code known to me). I am 
aware that I need to use r.surf.fractal and specify fractal dimension.


But how do I specify other parameters of the raster map (like length & 
breadth, resolution?)


You just set the computational region using g.region. Any map you create 
will respect that setting.




Also, can you guide me towards how generate a set of many such maps 
using scripting?


The answer here really depends on your level of existing knowledge. Most 
people nowadays prefer using Python for scripting, although you can also 
create simple shell scripts. I would suggest that you read through 
https://grasswiki.osgeo.org/wiki/GRASS_GIS_APIs first and come back to 
us if you have more specific questions.




Also, are there any tips for me to follow so as to make this (DEM raster 
map) dataset generation as fast as possible?


Speed will depend on the size of the maps you create.

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

Re: [GRASS-user] Distance surface 3D

2020-09-16 Thread Moritz Lennert


Am 16. September 2020 15:45:31 MESZ schrieb Edward Guevara :
>Muy buenos días para todos, tengo una consulta: ¿Sabe alguien cómo puedo
>medir la distancia de un vector tipo polyline en una superficie 3d, en mi
>caso un DEM?, estoy buscando alguna opción en grass pero no la encuentro.
>La función en ArcMap se llama "Add Surface Information". ¿Alguna
>alternativa de código abierto que pueda ejecutar desde script o línea de
>comando?
>Gracias.
>
>Good morning everyone, I have a question: Does anyone know how I can
>measure the distance of a polyline-type vector on a 3d surface, in my case
>a DEM? I'm looking for an option in grass but I can't find one. The
>function in ArcMap is called "Add Surface Information". Any open source
>alternative that I can run from script or command line?

As far as I know, as long as your line is a real 3D line, v.to.db with 
option=length measures that length in 3D.

You can use v.drape to transform a 2D line into 3D with the help of your DEM.

Moritz

>Thank you.
>
>*Edward Guevara E-mail  edara...@gmail.com *
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Classify basins as "narrow"

2020-09-03 Thread Moritz Lennert

On 3/09/20 08:54, Stefan Blumentrath wrote:

In order to get the skeleton of the basin you could use r.neighbors as well:
r.neighbors input=basin_boundary_distance method=maximum 
output=basin_boundary_distance_max
r.mapcalc expression="skeletons=if(basin_boundary_distance < 
basin_boundary_distance_max, null(), 1)"
This should approximate the center lines...


There is also v.voronoi with the -s flag for extraction of skeletons 
from vector polygons.


Moritz

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

Re: [GRASS-user] Sqlite error when calling GRASS GIS outside of GRASS

2020-08-07 Thread Moritz Lennert
Hi Ellen,

Am 6. August 2020 22:03:24 MESZ schrieb "DAmico, Ellen" :
>Good Afternoon,
>I have been going around in circles with this error.
>When I run this piece of code:
>g.run_command(r'C:\OSGeo4W64\apps\grass\grass78\bin\g.proj.exe',
>georef=geotiff, location = locationGeonet)
>I am getting this error:
>Process ended with non-zero return code 3221225785. See errors in the
>(error)
>
>When I run that g.proj.exe directly I get the dynamic link error.
>
>I think this is a conflict with the sqlite3.dll as is suggested the
>below wiki but the solutions there have not worked for me.
>https://grasswiki.osgeo.org/wiki/WinGRASS_errors
>
>I am wondering if it might have something to do with not having
>administrative rights to my machine.  I can access my path variables
>through Spyder/ Anaconda but not directly through the usual channels. 
>I am on a windows machine.
>

First of all, there are a series of variables you have to define before you can 
call a module without starting GRASS GIS explicitly. See [1] or use the exec 
parameter of the grass command.

Second, when using the functions in the grass scripting library (e.g. 
run_command), you should not provide a path, but just the module name, i.e.

g.run_command('g.proj', georef=geotiff, location = locationGeonet)

Moritz

[1] 
https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in v.distance when running from R (in a container)

2020-07-22 Thread Moritz Lennert

On 20/07/20 21:41, Markus Neteler wrote:

Hi,

On Mon, Jul 20, 2020 at 9:22 PM Veronica Andreo  wrote:


Hi Mehrdad,

I have the same problem (running just GRASS dev - without calling it from R).
Why can't v.distance update the current table


Because it was changed to "upload is required" in:

https://github.com/OSGeo/grass/commit/2c614dd3225294a1f9e094b06d24a0905a239333

Maybe Moritz can tell us more why this was needed?



The issue wasn't the upload is required (v.distance always needs a 
variable to upload), but a change to G_required in which I added the new 
functionalities, but at the same time forgot the column upload option. 
Should be fixed in master, now.


Sorry...

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

Re: [GRASS-user] Question about v.cluster DBSCAN

2020-07-18 Thread Moritz Lennert

Hi Zac,

On 18/07/20 11:34, Zac45 wrote:

Hi,

I am kinda new to GRASS and now dealing with a group of point data, but I
failed to get output from the DBSCAN in v.cluster. It is kind of strange to
me because I input the correct vector data but the output seems unchanged.
Here are the command output:

Creating search index ...
Estimating maximum distance ...
Distance to the 1 nearest neighbor:
Min: 4.53982, max: 32826.2
Mean: 2192.14
Standard deviation: 4348.38
Estimated maximum distance: 13392.8
Building clusters ...
Generating renumbering scheme...
Write out cluster ids ...
Building topology for vector map ...
Registering primitives...
7 clusters found
2 outliers found

But the output in display area shows the same data as the input.

Could you please help me with it?


By default, cluster ids are stored as category values of the points in 
layer 2.


If you just want to visualise them, you can use random coloring 
according to cat value (as in the examples in the man page):


d.vect -c map=sites_clustered layer=2 icon=basic/point size=10

or you can create an attribute table for layer 2 using:

v.db.addtable sites_clustered layer=2

and then visualise the cluster ids in this table.

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

Re: [GRASS-user] Storing raster maps

2020-07-02 Thread Moritz Lennert



On 1/07/20 23:55, Rich Shepard wrote:

On Wed, 1 Jul 2020, Markus Neteler wrote:


I see two options:
- export the DEMs, still in GRASS GIS format, with r.pack (in a loop)
- or simply package the mapset(s) containing the DEMs.


Markus,

With changes to GRASS over the years I was no sure whether making a tarball
of the mapset would retain all information.


There might be future changes to GRASS which would make this difficult 
with the current version of GRASS (e.g. plans to change the raster 
format / storage organisation). However, you will always have access to 
older versions of GRASS GIS and so should at least always be able to 
open old mapsets in those and then update if necessary.


Otherwise, I think that well-compressed tiff files will remain readable 
for quite a long time.


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

Re: [GRASS-user] r.in.lidar and v.in.lidar not available in GRASS 7.8.3 fc31 from copr

2020-06-22 Thread Moritz Lennert

On 22/06/20 09:51, Markus Neteler wrote:

Hi Richard,
(re-adding the user list)

[topic: r.in.lidar/v.in.lidar support on Fedora]

So, the liblas package on Fedora is lacking "liblas-config" which
makes it unusable for GRASS GIS. Tthe maintainer of liblas in Fedora
told me that we would need to support /usr/lib64/pkgconfig/liblas.pc
but I have no time to tweak it. And, liblas is deprecated anyway and
PDAL is the way to go.

I made some efforts in the last weeks to make PDAL an official Fedora
and EPEL package (it is now available) and could activate that for
GRASS GIS.
We have v.in.pdal in the core system and r.in.pdal in addons.

And a new version of r.in.pdal awaits testing:
https://github.com/OSGeo/grass/pull/61

What do you think? Shall I switch to PDAL (see also
https://bugzilla.redhat.com/show_bug.cgi?id=1672170)?



+1

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

Re: [GRASS-user] i.segment vs. i.segment.gsoc

2020-06-11 Thread Moritz Lennert

On 11/06/20 13:36, mbrauch...@posteo.de wrote:
Thank you for the explanation! I assumed gsoc version is build upon 
i.segment.
Is there any way to include the shape parameters in i.segment? I am very 
fond of the gsoc version as it helps surpress segments growing to very 
complex geometries (shadows through the forest patches for example).


There was some reasons why the shape parameters were not integrated in 
i.segment, but I can't remember why. Some code is actually there, but 
currently it is not used.


MarkusM, do you remember ? And how complicated would it be to integrate 
them ?


Moritz




Kind regards,
Melanie

On Jun 11, 2020 12:52 PM, Moritz Lennert  
wrote:


i.segment.gsoc is the original version developed during GSoC.
i.segment is ann optimized version that was originally based on the
GSoC work, but has known different developments since, including in
the way the threshold parameter is applied.

I would recommend using i.segment.

Moritz

Am 10. Juni 2020 13:13:33 MESZ schrieb mbrauch...@posteo.de:
 >Hello list,
 >I am working on segmentation of aerial imagery in forest areas and
have
 >
 >used both modules (i.segment and i.segment.gsoc) for some
experiments.
 >When running i.segment and i.segment.gsoc with radioweight = 1 on the
 >same dataset with a threshold of 0.3, I assumed the output should be
 >similar, but it isn't.
 >In the manual of i.segment.gsoc it is stated that the threshold
will be
 >
 >multiplied by the number of rasters in the image group, so I tried a
 >threshold of 0.1 in i.segment.gsoc vs a threshold of 0.3 in i.segment
 >as
 >I have 3 rasters in my image group. Although the results are now more
 >similar, they still vary a lot.
 >I have attached the images to show the derived segments from
i.segment
 >0.3 and i.segment.gsoc 0.1. Can someone help me to understand why
this
 >is happening? I would appreciate it.
 >Kind regards,
 >Melanie Brauchler



___
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] i.segment vs. i.segment.gsoc

2020-06-11 Thread Moritz Lennert
i.segment.gsoc is the original version developed during GSoC. i.segment is ann 
optimized version that was originally based on the GSoC work, but has known 
different developments since, including in the way the threshold parameter is 
applied.

I would recommend using i.segment.

Moritz

Am 10. Juni 2020 13:13:33 MESZ schrieb mbrauch...@posteo.de:
>Hello list,
>I am working on segmentation of aerial imagery in forest areas and have
>
>used both modules (i.segment and i.segment.gsoc) for some experiments.
>When running i.segment and i.segment.gsoc with radioweight = 1 on the 
>same dataset with a threshold of 0.3, I assumed the output should be 
>similar, but it isn't.
>In the manual of i.segment.gsoc it is stated that the threshold will be
>
>multiplied by the number of rasters in the image group, so I tried a 
>threshold of 0.1 in i.segment.gsoc vs a threshold of 0.3 in i.segment
>as 
>I have 3 rasters in my image group. Although the results are now more 
>similar, they still vary a lot.
>I have attached the images to show the derived segments from i.segment 
>0.3 and i.segment.gsoc 0.1. Can someone help me to understand why this 
>is happening? I would appreciate it.
>Kind regards,
>Melanie Brauchler
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] SQL in GRASS

2020-06-02 Thread Moritz Lennert
Glad to hear that. Please keep threads in the mailing list.

Moritz

Am 2. Juni 2020 18:59:15 MESZ schrieb Uwe Fischer :
>Hello Moritz,
>
>thanks again, it works now. Indeed I had to many useless quotes. Maybe
>it came from former attempts I did with db.execute statements, where I
>needed a lot of quotes. But I could have seen it myself, comparing with
>the SpatiaLite statement that worked fine.
>
>Thanks you.
>
>Mit freundlichen Grüßen,
>UWE FISCHER
>
>--
>
>Ingenieurbüro Fischer
>Esbecker Str. 8
>31036 Eime
>Tel.: 05182/8325
>Mobil: 0172/8876934
>
>-Ursprüngliche Nachricht-
>Von: grass-user [mailto:grass-user-boun...@lists.osgeo.org] Im Auftrag
>von Moritz Lennert
>Gesendet: Dienstag, 2. Juni 2020 15:07
>An: grass-user@lists.osgeo.org
>Betreff: Re: [GRASS-user] SQL in GRASS
>
>On 2/06/20 14:42, Uwe Fischer wrote:
>> Hello list,
>> 
>> I tried the following expression in a Python script, but it does not 
>> work
>
>Please be more specific than just saying "it does not work". Do you see
>an error message ? Wrong results in the table ?
>
>> (I need to subtract the lowest value for column „srtmh“ from all
>other 
>> values for that item and write the result to column „strmh2“):
>> 
>> grass.run_command('v.db.update', map='dgnpt', column='srtmh2', 
>> qcolumn="('srtmh' - (select min('srtmh') from 'dgnpt'))")
>
>I think your quoting is off.
>
>For me such a command works. E.g. in the NC demo dataset:
>
>g.copy vect=censusblk_swwake,test
>v.db.addcolumn test col="test double precision"
>
>and then in python:
>
>import grass.script as g
>g.run_command('v.db.update', map='test', column='test',
>value="'HH_SIZE'-(SELECT avg('HH_SIZE') FROM test)")
>g.run_command('v.db.update', map='test', column='test',
>value="HH_SIZE-(SELECT avg(HH_SIZE) FROM test)")
>
>However, if I quote like you do:
>
>g.run_command('v.db.update', map='test', column='test',
>value="'HH_SIZE'-(SELECT avg('HH_SIZE') FROM 'test')")
>
>the result is all zeroes.
>
>This tells the database that all words in single quotes are strings,
>not db entity names.
>
>
>> The SQL expression itself seems to be ok, because it works in
>SpatiaLite 
>> in the following form:
>> 
>> update dgnpt set srtmh2 = srtmh-(select min(srtmh) from srtmp);
>
>Try running
>
>update dgnpt set srtmh2 = 'srtmh'-(select min('srtmh') from 'srtmp')
>
>You probably won't get what you expect, either.
>
>
>> 
>>   And by the way, when I try scripts I often get a message „Process
>>   ended with non-zero return code 1. See errors in the (error)
>output.“
>> 
>> But what is that error output? Where can I read the error message in 
>> detail? Sorry for that question, but I found no hints in the manual 
>> pages.  :-(
>
>Generally, you have to look further up for the actual error, at the 
>beginning of the error message. E.g. when I run the above command but 
>using an incorrect table name:
>
>g.run_command('v.db.update', map='test', column='test', 
>value="HH_SIZE-(SELECT avg(HH_SIZE) FROM test2)")
>
>I get:
>
>*
>DBMI-SQLite erreur de pilote :
>Error in sqlite3_prepare():
>no such table: test2
>
>DBMI-SQLite erreur de pilote :
>Error in sqlite3_prepare():
>no such table: test2
>
>ERREUR : Error while executing: 'UPDATE test SET test=HH_SIZE-(SELECT
>  avg(HH_SIZE) FROM test2)'
>Traceback (most recent call last):
>   File "/usr/lib/grass78/scripts/v.db.update", line 129, in 
> sys.exit(main())
>   File "/usr/lib/grass78/scripts/v.db.update", line 120, in main
> grass.write_command('db.execute', input='-', database=database, 
>driver=driver, stdin=cmd)
> File "/usr/lib/grass78/etc/python/grass/script/core.py", line 588, in 
>write_command
> return handle_errors(returncode, returncode, args, kwargs)
> File "/usr/lib/grass78/etc/python/grass/script/core.py", line 342, in 
>handle_errors
> raise CalledModuleError(module=None, code=code,
>grass.exceptions.CalledModuleError: Module run None db.execute input=- 
>database=/home/mlennert/GRASSDATA/nc_spm_08_grass7/user1/sqlite/sqlite.db
>
>driver=sqlite ended with error
>Process ended with non-zero return code 1. See errors in the (error)
>output.
>*
>
>I see the 'Process ended with non-zero return code 1" and going further
>
>up I see:
>
>ERREUR : Error while executing: 'UPDATE test SET test=HH_SIZE-(SELECT
>  avg(HH_SIZE) FROM test2)'
>
>and even further up:
>
>DBMI-SQLite erreur de pilote :
>Error in sqlite3_prepare():
>no such table: test2
>
>Moritz
>___
>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] SQL in GRASS

2020-06-02 Thread Moritz Lennert

On 2/06/20 14:42, Uwe Fischer wrote:

Hello list,

I tried the following expression in a Python script, but it does not 
work


Please be more specific than just saying "it does not work". Do you see 
an error message ? Wrong results in the table ?


(I need to subtract the lowest value for column „srtmh“ from all 
other values for that item and write the result to column „strmh2“):


grass.run_command('v.db.update', map='dgnpt', column='srtmh2', 
qcolumn="('srtmh' - (select min('srtmh') from 'dgnpt'))")


I think your quoting is off.

For me such a command works. E.g. in the NC demo dataset:

g.copy vect=censusblk_swwake,test
v.db.addcolumn test col="test double precision"

and then in python:

import grass.script as g
g.run_command('v.db.update', map='test', column='test', 
value="'HH_SIZE'-(SELECT avg('HH_SIZE') FROM test)")
g.run_command('v.db.update', map='test', column='test', 
value="HH_SIZE-(SELECT avg(HH_SIZE) FROM test)")


However, if I quote like you do:

g.run_command('v.db.update', map='test', column='test', 
value="'HH_SIZE'-(SELECT avg('HH_SIZE') FROM 'test')")


the result is all zeroes.

This tells the database that all words in single quotes are strings, not 
db entity names.



The SQL expression itself seems to be ok, because it works in SpatiaLite 
in the following form:


update dgnpt set srtmh2 = srtmh-(select min(srtmh) from srtmp);


Try running

update dgnpt set srtmh2 = 'srtmh'-(select min('srtmh') from 'srtmp')

You probably won't get what you expect, either.




  And by the way, when I try scripts I often get a message „Process
  ended with non-zero return code 1. See errors in the (error) output.“

But what is that error output? Where can I read the error message in 
detail? Sorry for that question, but I found no hints in the manual 
pages.  :-(


Generally, you have to look further up for the actual error, at the 
beginning of the error message. E.g. when I run the above command but 
using an incorrect table name:


g.run_command('v.db.update', map='test', column='test', 
value="HH_SIZE-(SELECT avg(HH_SIZE) FROM test2)")


I get:

*
DBMI-SQLite erreur de pilote :
Error in sqlite3_prepare():
no such table: test2

DBMI-SQLite erreur de pilote :
Error in sqlite3_prepare():
no such table: test2

ERREUR : Error while executing: 'UPDATE test SET test=HH_SIZE-(SELECT
 avg(HH_SIZE) FROM test2)'
Traceback (most recent call last):
  File "/usr/lib/grass78/scripts/v.db.update", line 129, in 
sys.exit(main())
  File "/usr/lib/grass78/scripts/v.db.update", line 120, in main
grass.write_command('db.execute', input='-', database=database, 
driver=driver, stdin=cmd)
  File "/usr/lib/grass78/etc/python/grass/script/core.py", line 588, in 
write_command

return handle_errors(returncode, returncode, args, kwargs)
  File "/usr/lib/grass78/etc/python/grass/script/core.py", line 342, in 
handle_errors

raise CalledModuleError(module=None, code=code,
grass.exceptions.CalledModuleError: Module run None db.execute input=- 
database=/home/mlennert/GRASSDATA/nc_spm_08_grass7/user1/sqlite/sqlite.db 
driver=sqlite ended with error

Process ended with non-zero return code 1. See errors in the (error) output.
*

I see the 'Process ended with non-zero return code 1" and going further 
up I see:


ERREUR : Error while executing: 'UPDATE test SET test=HH_SIZE-(SELECT
 avg(HH_SIZE) FROM test2)'

and even further up:

DBMI-SQLite erreur de pilote :
Error in sqlite3_prepare():
no such table: test2

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

Re: [GRASS-user] Estimating import time for large data file

2020-05-29 Thread Moritz Lennert

On 29/05/20 14:37, Rich Shepard wrote:

On Fri, 29 May 2020, Moritz Lennert wrote:

Importing such a large file can take a lot of time because of the 
cleaning in order to get it into GRASS GIS' topological format.


Moritz,

I assumed it would taka a while, but it seemed to be stuck. Perhaps because
that polygon was large, complex, and needed a lot of cleaning.


I think it really depends on the specific file in terms of geometry
complexity and cleanliness, so difficult to pre-determine. I regularly
launch large import jobs overnight.


Then that's what I'll do tonight: I'll start it running in screen before I
log off and let it do it's thing for as long as it wants.

You should see an information about its progress in the different 
cleaning

steps (note that some cleaning is repeated).


I was using the GUI because I needed to create a new location and have
forgotten how to create a new location and mapset from the command line.



grass --help is your friend ;-)

grass -c epsg:4326 GISDBASE/LOCATION

replace GISDBASE and LOCATION with the respective names

-c can also be used with a file:

-c /path/to/georeferenced/file

Another, untested, path for possibly speeding up import: use ogr2ogr 
with the -simplify option to first simplify the geometry, if that is 
possible in your case. Would be interesting to benchmark v.in.ogr alone 
against ogr2ogr -simply + v.in.ogr.


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

Re: [GRASS-user] Estimating import time for large data file

2020-05-29 Thread Moritz Lennert

On 28/05/20 17:25, Rich Shepard wrote:

I'm trying to import (using v.in.ogr) a rather large file (1.22G *.shp and
4.5M *.dbf). I see a lot of system disk reads, low cpu usage, but after a
half-hour it appears to have stopped processing.


Importing such a large file can take a lot of time because of the 
cleaning in order to get it into GRASS GIS' topological format.




I'm running Slackware-14.2/x86_64 on a desktop with an AMD Ryzen7 2700 CPU
(8 cores/16 threads) and 32G DDR4 memory. GRASS-7.9.dev is configured to
enable largefile and use openmp.

1. Can I do more to facilitate import of this large, statewide wetlands
data set?

2. Is there a way to estimate the time import would take? If so, I'll start
it using screen and let it run in the background, overnight if necessary.


I think it really depends on the specific file in terms of geometry 
complexity and cleanliness, so difficult to pre-determine. I regularly 
launch large import jobs overnight.




3. Is there a realtime progress monitor that informs me grass is chewing on
the import or stuck somewhere?

The GUI layer manager shows the map needs cleaning for many (most? all?)
polygons when it eventually is imported, but that's to be addressed later.


You should see an information about its progress in the different 
cleaning steps (note that some cleaning is repeated).


If you are sure you do not want to do any polygon cleaning during 
import, you can use the -c flag. But you will have to handle the result 
with care.


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

Re: [GRASS-user] v.what.rast - solved

2020-05-29 Thread Moritz Lennert

On 29/05/20 10:09, Micha Silver wrote:


On 29/05/2020 9:42, Uwe Fischer wrote:


Hello list,

thanks to Micha Silver and Helmut Kudrnovsky, the problem ist solved. 
I did not set g.region prior to using v.what.rast. Seems to be a 
typical non-Grass-Professional mistake. Now it works fine.


But to be honest, I do not really understand what it is good for. When 
the raster image and the points to be updated share the same Grass 
location and CRS, why do I have to set a region in addition?




Glad you got it worked out.

The only thing I would add to Stefan's explanation is a pointer to the 
GRASS wiki on region settings:


https://grasswiki.osgeo.org/wiki/Computational_region



Although I am a huge fan and promotor of the computational region 
concept, I actually agree with Uwe that it is debatable whether in the 
specific cas of v.what.rast this should be the default behavior. It is a 
bit counter-intuitive. In any case, it should be clearly and explicitly 
documented in the man page.


Uwe, would you mind posting an issue on this in github [1] ?

Moritz


[1] https://github.com/OSGeo/grass/issues
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Which colour palette is currently applied to a raster

2020-05-27 Thread Moritz Lennert

On 27/05/20 12:39, Paul Shapley wrote:


Hi Users,

How can I tell which colour palette set is currently applied to a raster 
in Grass 7.8.3? nothing is stated in metadata and checked in 
'PERMANENT/colr' for colour palette 'name' but nothing.


Named color palettes are translated into numbers in color tables, some 
absolute, others relative to the maps content (color tables defined by 
percentages). AFAIK, there is currently no heuristic to translate the 
existing color table back into a named palette.


It probably shouldn't be to difficult to get r.colors to write the name 
of the used palette into the colr file, if a named palette was used 
(name could the be 'custom').


If you are not looking for the name of the palette, but just the color 
table itself, you can use r.colors.out.


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

Re: [GRASS-user] Calling all imagery (especially i.maxlik and i.smap) users

2020-05-08 Thread Moritz Lennert

On 6/05/20 08:33, Maris Nartiss wrote:

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).


Subgroups used to be very useful when imagery came without 
georeferencing. One would import the data into XY, and georeference all 
bands contained in one group. In the projected location one could then 
define subgroups to do the actual work on them.


In other word, they were (are?) useful when you have different parts of 
your workflow where one part concerns all bands while other parts only a 
subset of these bands.


As most imagery comes georeferenced nowadays, this workflow is much less 
frequent nowadays and for most of my usage of subgroups today, it could 
be replaced without any problem by the use of groups.




#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.


+1 to remove this functionality.



#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.


I do think that mapset-specific groups make sense and that for me 
personally I see a lot of potential for chaos if I could have signature 
files in a mapset that pertain to groups in other mapsets. It is so easy 
to create a group that I'm not sure what the significant added value 
would be.


So, I'm more skeptical about this one, without having a clear-cut opinion.

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

Re: [GRASS-user] [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

2020-05-07 Thread Moritz Lennert


Am 6. Mai 2020 15:17:08 MESZ schrieb Vaclav Petras :
>On Thu, Apr 30, 2020 at 9:59 PM Vaclav Petras 
>wrote:
>
>> Dear users and devs,
>>
>> I though it would be a good idea to video meet next week and talk
>about
>> what would be the best way of releasing GRASS GIS in the future. As
>always,
>> both contributors and users are invited to share ideas and opinions.
>>
>> ...
>>
>> PS: If you are answering to this email, I cross posted it to both
>user and
>> dev mailing lists, so you may want to take care to reply to just one
>> mailing list.
>>
>
>Scenario 2 on the following page is my attempt to capture the main
>scenario
>we talked about during the call. Thanks to all who participated!
>
>https://trac.osgeo.org/grass/wiki/Release/Schedule


+1 on your scenario 2, with only one possible change: looking at the past, I'm 
not sure it is realistic to wait until March for the x.0.1 release. Probably 
January is more realistic. This would then mean May and September for x.0.2 and 
x.0.3.

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

Re: [GRASS-user] Responding to mail list threads

2020-05-02 Thread Moritz Lennert

Dear Rich,

On 2/05/20 16:27, Rich Shepard wrote:

I have a request for all who post to this maillist: please send it the list
only and not to the list and all individuals who've commented on a thread.

All of us receives the message from the mail list and don't need a second
copy of each addressed to us individually.


Please note that Mailman provides us with the following setting that 
each can set according to their needs:


"Avoid duplicate copies of messages?

When you are listed explicitly in the To: or Cc: headers of a list 
message, you can opt to not receive another copy from the mailing list. 
Select Yes to avoid receiving copies from the mailing list; select No to 
receive copies."


I prefer to be also kept personally in CC of messages in threads I'm 
involved in. This allows me to separate these threads into another 
mailbox from all the other threads in the list, and so be a bit more 
reactive on those.


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

Re: [GRASS-user] slope calculation under lat long

2020-03-19 Thread Moritz Lennert

On 19/03/20 16:37, Giuseppe Amatulli wrote:

Hi,
I wondering if the slope calculation in GRASS
(https://grass.osgeo.org/grass78/manuals/r.slope.aspect.html) take in to 
account the
latitudinal change of the meridian distance or just simply treats the 
raster as square grids also under lat long system (WGS84)?


AFAIK, r.slope.aspect uses the G_distance() function which calculates 
geodetic distance if in a Lat-Long location, so yes it takes into 
account latitudinal change.


If it doesn't, I would consider this a bug.

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

Re: [GRASS-user] RES: v.centerline addon

2020-03-06 Thread Moritz Lennert
MarkusM just merged the PR so you can reinstall the extension and see if it 
works with your python 3 installation now.

Moritz

Am 6. März 2020 17:34:12 GMT+01:00 schrieb Moritz Lennert 
:
>Hi César,
>
>Micha Silver sent a pull request that should solve your issue [1], but
>I currently do not have the access necessary to merge.
>
>If one of the other developers can do it, please feel free, otherwise
>I'll do it on Monday.
>
>Moritz
>
>[1]
>https://github.com/OSGeo/grass-addons/commit/20f8becac918dbd2d81368e9a305e62fcb53efc9
>
>Am 5. März 2020 11:37:14 GMT+01:00 schrieb ce...@fototerra.com.br:
>>Hi Moritz and colleagues!!
>>
>> 
>>
>>Thank you for write and being help me. About the python version make
>>sense
>>because I’m using Python 3.7.
>>
>> 
>>
>>I’ll try install Python 2.x and run again the addon v.centerline and
>>I’ll
>>tell about the result.
>>
>> 
>>
>>Tks.
>>
>> 
>>
>>César de Paula
>>
>> 
>>
>>De: Moritz Lennert  
>>Enviada em: quinta-feira, 5 de março de 2020 05:10
>>Para: ce...@fototerra.com.br; grass-user@lists.osgeo.org
>>Assunto: Re: [GRASS-user] v.centerline addon
>>
>> 
>>
>> 
>>
>>On 4/03/20 18:10, ce...@fototerra.com.br
>><mailto:ce...@fototerra.com.br>
>>wrote:
>>
>>Hello!!!
>>
>> 
>>
>>I’m new user on GRASS and I’m trying to execute the addon v.centerline
>>on
>>GRASS 7.9. As input I’m using a shapefile containing line
>>(MultiLineString)
>>as geometry and when I have run the v.centerline an erro is returning:
>>
>> 
>>
>>“Traceback (most recent call last):
>>
>>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>>
>>/v.centerline.py", line 319, in 
>>
>>main()
>>
>>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>>
>>/v.centerline.py", line 111, in main
>>
>>segment_input += 'P ' + category.strip()
>>
>>TypeError: can only concatenate str (not "bytes") to str
>>
>>(Wed Mar  4 17:27:25 2020) Comando terminado (3 segundos)
>>
>>
>>(Wed Mar  4 17:27:25 2020)
>>
>>
>>v.centerline input=Linha_rio_teste_Centerline@PERMANENT output=teste
>>range=2
>>refline=2
>>
>>Traceback (most recent call last):
>>
>>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>>
>>/v.centerline.py", line 319, in 
>>
>>main()
>>
>>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>>
>>/v.centerline.py", line 111, in main
>>
>>segment_input += 'P ' + category.strip()
>>
>>TypeError: can only concatenate str (not "bytes") to str
>>
>>(Wed Mar  4 17:27:28 2020) Comando terminado (2 segundos)”
>>
>> 
>>
>>I would like help to try understand what’s happening.
>>
>> 
>>
>>I would guess that this is a Python 3 vs Python 2 issue. I never
>>updated the
>>addon to Python 3. If someone else can do this, it would be great, as
>>I'm
>>currently on mission abroad and do not really have the necessary
>access
>>to
>>the development tools to do this from here.
>>
>> 
>>
>>Moritz
>___
>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] RES: v.centerline addon

2020-03-06 Thread Moritz Lennert
Hi César,

Micha Silver sent a pull request that should solve your issue [1], but I 
currently do not have the access necessary to merge.

If one of the other developers can do it, please feel free, otherwise I'll do 
it on Monday.

Moritz

[1] 
https://github.com/OSGeo/grass-addons/commit/20f8becac918dbd2d81368e9a305e62fcb53efc9

Am 5. März 2020 11:37:14 GMT+01:00 schrieb ce...@fototerra.com.br:
>Hi Moritz and colleagues!!
>
> 
>
>Thank you for write and being help me. About the python version make
>sense
>because I’m using Python 3.7.
>
> 
>
>I’ll try install Python 2.x and run again the addon v.centerline and
>I’ll
>tell about the result.
>
> 
>
>Tks.
>
> 
>
>César de Paula
>
> 
>
>De: Moritz Lennert  
>Enviada em: quinta-feira, 5 de março de 2020 05:10
>Para: ce...@fototerra.com.br; grass-user@lists.osgeo.org
>Assunto: Re: [GRASS-user] v.centerline addon
>
> 
>
> 
>
>On 4/03/20 18:10, ce...@fototerra.com.br
><mailto:ce...@fototerra.com.br>
>wrote:
>
>Hello!!!
>
> 
>
>I’m new user on GRASS and I’m trying to execute the addon v.centerline
>on
>GRASS 7.9. As input I’m using a shapefile containing line
>(MultiLineString)
>as geometry and when I have run the v.centerline an erro is returning:
>
> 
>
>“Traceback (most recent call last):
>
>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>
>/v.centerline.py", line 319, in 
>
>main()
>
>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>
>/v.centerline.py", line 111, in main
>
>segment_input += 'P ' + category.strip()
>
>TypeError: can only concatenate str (not "bytes") to str
>
>(Wed Mar  4 17:27:25 2020) Comando terminado (3 segundos)
>
>
>(Wed Mar  4 17:27:25 2020)
>
>
>v.centerline input=Linha_rio_teste_Centerline@PERMANENT output=teste
>range=2
>refline=2
>
>Traceback (most recent call last):
>
>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>
>/v.centerline.py", line 319, in 
>
>main()
>
>  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts
>
>/v.centerline.py", line 111, in main
>
>segment_input += 'P ' + category.strip()
>
>TypeError: can only concatenate str (not "bytes") to str
>
>(Wed Mar  4 17:27:28 2020) Comando terminado (2 segundos)”
>
> 
>
>I would like help to try understand what’s happening.
>
> 
>
>I would guess that this is a Python 3 vs Python 2 issue. I never
>updated the
>addon to Python 3. If someone else can do this, it would be great, as
>I'm
>currently on mission abroad and do not really have the necessary access
>to
>the development tools to do this from here.
>
> 
>
>Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.centerline addon

2020-03-05 Thread Moritz Lennert


On 4/03/20 18:10, ce...@fototerra.com.br wrote:


Hello!!!

I’m new user on GRASS and I’m trying to execute the addon v.centerline 
on  GRASS 7.9. As input I’m using a shapefile containing line 
(MultiLineString) as geometry and when I have run the v.centerline an 
erro is returning:


*“Traceback (most recent call last):*

*  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts*

*/v.centerline.py", line 319, in *

*    main()*

*  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts*

*/v.centerline.py", line 111, in main*

*    segment_input += 'P ' + category.strip()*

*TypeError: can only concatenate str (not "bytes") to str*

*(Wed Mar  4 17:27:25 2020) Comando terminado (3 segundos) *

*(Wed Mar  4 17:27:25 2020) *

*v.centerline input=Linha_rio_teste_Centerline@PERMANENT output=teste 
range=2 refline=2*


*Traceback (most recent call last):*

*  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts*

*/v.centerline.py", line 319, in *

*    main()*

*  File "C:\Users\cesar\AppData\Roaming\GRASS7\addons/scripts*

*/v.centerline.py", line 111, in main*

*    segment_input += 'P ' + category.strip()*

*TypeError: can only concatenate str (not "bytes") to str*

*(Wed Mar  4 17:27:28 2020) Comando terminado (2 segundos)”*

I would like help to try understand what’s happening.



I would guess that this is a Python 3 vs Python 2 issue. I never updated 
the addon to Python 3. If someone else can do this, it would be great, 
as I'm currently on mission abroad and do not really have the necessary 
access to the development tools to do this from here.



Moritz

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

Re: [GRASS-user] Error creating mapset and location.

2020-01-16 Thread Moritz Lennert

On 15/01/20 21:35, barros-l...@uol.com.br wrote:

Error creating mapset and location.
In GRASS 7.6.0, when I create a new location and mapset, the error 
message is displayed: "Location  will be created in the GIS data 
directory . You will need to change the default Gis data 
directory on the GRASS boot screen". I am using a company computer. 
Would anyone know the reason for this error?


Doesn't sound like an error to me. Rather like an information message. 
What exactly is your problem ?


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

Re: [GRASS-user] error while using i.segment.stats

2019-12-05 Thread Moritz Lennert

On 3/12/19 13:26, Veronica Andreo wrote:

Hi Moritz,

Thanks for your answer :)

In smaller subsets (per cutlines tiles), it works just fine.


With grass78 using python 3 ? Then probably it's not a python version issue.

What is the region size ? When it is calculating the raster statistics 
it uses r.univar with extended statistics (-e flag), if the region size 
is too big, actually you are right that this might lead to memory errors 
if it tries to run 4 instances in parallel.


Unfortunately, r.univar does not have a memory option allowing to limit 
memory usage. Maybe i.segment.stats should check the region size and 
available memory and bail out if there's not enough memory. Not sure how 
to calculate the needed memory size, though (especially since r.univar's 
-t flag is also set).


You could also try to reduce parallelization, i.e. run it with two 
processes only. It will obviously be slower.


Moritz




El mar., 3 dic. 2019 a las 12:41, Moritz Lennert 
(mailto:mlenn...@club.worldonline.be>>) 
escribió:


Hi Vero,

Le Mon, 2 Dec 2019 13:43:30 +0100,
Veronica Andreo mailto:veroand...@gmail.com>>
a écrit :

 > Hi,
 >
 > We are trying to use i.segment.stats for a map with 80+ segments
 > and already in two different laptops, we get:
 >
 > bands=`g.list rast pat=IGUAZU_IMG_* sep=,`
 >

RASTER_STATS=(min,max,range,mean,stddev,median,first_quart,third_quart,perc_90)
 > AREA_STATS=(area,perimeter,compact_circle,compact_square,fd)
 >
 > i.segment.stats -rc \
 >                  map=segments_full_region \
 >                  rasters=$bands \
 >                  raster_statistics=$RASTER_STATS \
 >                  area_measures=$AREA_STATS \
 >                  vectormap=segs_stats_map \
 >                  processes=4
 > Calculating geometry statistics...
 > Calculating statistics for raster maps...
 > Exception in thread Thread-3:
 > Traceback (most recent call last):
 >   File "/usr/lib/python3.6/threading.py", line 916, in
 > _bootstrap_inner self.run()
 >   File "/usr/lib/python3.6/threading.py", line 864, in run
 >     self._target(*self._args, **self._kwargs)
 >   File "/usr/lib/python3.6/multiprocessing/pool.py", line 463, in
 > _handle_results
 >     task = get()
 >   File "/usr/lib/python3.6/multiprocessing/connection.py", line 251,
 > in recv return _ForkingPickler.loads(buf.getbuffer())
 > TypeError: __init__() missing 3 required positional arguments:
 > 'module', 'code', and 'returncode'
 >
 > Does it have to do with memory? I used the module a month ago with
 > 50+ segments and it worked just fine...

I don't think memory is the issue, but I find the error message
pretty cryptic, so wouldn't exclude altogether. Could it be some
difference between Python 2 and 3 in the multiprocessing module ? Would
it be possible for you try running it in Python 2 ?

Maybe you could also try to run it on a smaller subset of the
segmentation result ?

Moritz


-- 
Département Géosciences, Environnement et Société Université Libre de

Bruxelles Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax  + 32 2 650.68.30




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

Re: [GRASS-user] SQL: generating numeric class numbers from class text labels?

2019-12-05 Thread Moritz Lennert

On 4/12/19 19:58, Markus Neteler wrote:

Thanks for your answers.
In fact I need it in Python...


Using SQL, you can do something like this (SQLite version):

create table mytab (cat int, label varchar, labelint int);

inserts...

select * from mytab;
1|forest|
2|forest|
3|forest|
4|street|
5|street|
6|forest|
7|forest|
8|street|
9|grass|
10|grass|


SELECT cat, label, rank() OVER win FROM mytab WINDOW win as (ORDER BY 
label);

1|forest|1
2|forest|1
3|forest|1
6|forest|1
7|forest|1
9|grass|6
10|grass|6
4|street|8
5|street|8
8|street|8

Playing around with that should allow you to feed your table.

Or in pure python:

- get unique labels with v.db.select col=label group=label and put them 
in a list
- get numbers with something like this: classnums = [x+1 for x in 
range(len(labels))]

- zip the two lists: zip(labels, classnums)
- for each tuple in the list:
v.db.update col=labelint value=tuple[1] where=label=tuple[0]


Probably there are more elegant solutions.

Moritz




Micha Silver mailto:tsvi...@gmail.com>> schrieb am 
Mi., 4. Dez. 2019, 18:57:


How about doing this in R? The labels will be read into R as
factors, and the factor levels can easily be extracted as numbers.


Something like this:


micha@tp480:~$ v.info  -c stations
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|station_num
TEXT|station_he
TEXT|station_en
TEXT|type
INTEGER|x_coord
INTEGER|y_coord
DOUBLE PRECISION|long
DOUBLE PRECISION|lat
INTEGER|elev
TEXT|date_open
DOUBLE PRECISION|dist
DOUBLE PRECISION|azim


micha@tp480:~$ R


R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
.

 > library(rgrass7)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: GRASS 7.6.0 (2019)
and location: ITM
 > use_sf()
 > stations = readVECT("stations")
WARNING: Vector map  is 3D. Use format specific layer creation
  options (parameter 'lco') to export  stations['new_station_num'] = as.numeric(stations$station_en)
 > stations$new_station_num
  [1] 71 26  6 55 54 63  7  8 31 30 46 84 92 38 32 88 27 12 67 62 47
33 53 76 89
[26]  2 86 11 40 65 64 45 13 85 60 59  1 74 73 22 19 15 39 50 56 14
44 23 36 83
[51] 41 42 43 18 17 75 16 82 81 37 48 28 87  3 66 10 34 91 61 93 94
72  5  4 68
[76] 78 77  9 29 51 58 57 49 52 24 25 80 79 35 70 69 90 21 20

 > writeVECT(SDF=stations, vname="new_stations")

Best regards, Micha


On 04/12/2019 19:11, Markus Neteler wrote:

Hi,

I have a landuse map with text labels (forest, street, ...). For
r.learn.ml    I need to have them as numeric classes.
It is not important for me which number is assigned but I search for
an automated solution, i.e. SQL statement unless there is a different
way.

So:

cat|label|label_int
1|forest|1
2|forest|1
3|street|2
4|forest|1
5|street|2
6|urban|3
...

I guess I have done that already some years ago but I can't remember
the trick :-)

thanks for a hint,
Markus
___
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
https://orcid.org/-0002-1128-1325


___
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] Problem with v.class.mIR

2019-12-04 Thread Moritz Lennert


[Guisseppe sent me the files].

The issue is your training file.

As the manual page states:


"The user provides a set of objects (or segments) to be classified, 
including all feature variables describing these object, and a set of 
objects to be used as training data, including the same feature 
variables as those describing the unknown objects, plus one additional 
column indicating the class each training falls into. The training data 
can, but does not have to be, a subset of the set of objects to be 
classified."


IOW, the training data file has to contain the same feature variables as 
the data you wish to classify.


Your data is:

$ head -1 segmentation_map.csv
cat,area,perimeter,compact_circle,fd

$ head -1 training_map.csv
cat,id,cate

i.e. you training data only includes the id and the class, but not the 
variables describing the objects.


The reason this is organised in this manner is that you might have 
training data which is independent of the data you wish to classify, 
i.e. the ids of the training data might not be linked to the ids in the 
object data.


Another issue is that in your command, you do not provide a good name 
for the column that contains the actual class label in the training data:


v.class.mlR segments_map=gbbb@PERMANENT training_map=tainning@PERMANENT 
train_class_column=fd [...]


v.class.mlR segments_map=gbbb training_map=tainning 
train_class_column=class [...]


Your training data does not contain a column 'fd' nor a column 'class'. 
I suppose that in your data it is the column 'cate'.


Moritz

On 4/12/19 10:38, Moritz Lennert wrote:

Sorry for ignoring you up to now, just to much on the platter right now.

Would it be feasible for you to make the data available, privately if
necessary ? The easiest (and lightest) would be just the csv output of
v.db.select on the training_map and the segments_maps.

Moritz

On 2/12/19 16:31, Giuseppe Cillis wrote:

No one can help me?
GC

Il giorno mer 20 nov 2019 alle ore 14:06 Giuseppe Cillis
mailto:giucil...@gmail.com>> ha scritto:

 Thanks for the answer._
 _
 _
 _
 _v.class.mlR segments_map=gbbb@PERMANENT
 training_map=tainning@PERMANENT train_class_column=fd
 output_class_column=vote output_prob_column=prob folds=5
 partitions=10 tunelength=10 weighting_metric=accuracy_

 _and the same error with this command:
 _
 _v.class.mlR segments_map=gbbb training_map=tainning
 train_class_column=class weighting_mode=smv,swv,qbwwv -i_

 The vector used was elaborated with i.segment.stats module.
 An extract is here:
 catareaperimeter   fd
 1  958 208 1.555034
 2  24  22  1.945217
 3  160 80  1.726846
 4  2036242 1.440904
 5  25  26  2.024344
 6  222 96  1.68966
 7  843510121.530879


 /cat /type Integer (9-0)
 /fd /type double/real (25-9)
 For the training area (t/ainning/), I use a simple vector with
 numerical categories (named/"cate"/) and there are 11 features (just
 for a trying). The type is in integer64 (10)

 Il giorno mer 20 nov 2019 alle ore 12:18 Moritz Lennert
 mailto:mlenn...@club.worldonline.be>>
 ha scritto:

 On 20/11/19 11:55, Giuseppe Cillis wrote:
  > Hi,
  > I'm trying to use this module for classification of an old
 aerial photos.
  > After a segmentation (i.segment and i.segment.stats), I would
 to use a
  > machine learning approach for the real classification.
  > I tried with v.class.mIR which use also R.
  > But there is an error and I don't know how to solve it:
  > */Durante l'avvio - Warning messages:
  > 1: Setting LC_CTYPE=it_IT.cp1252 failed
  > 2: Setting LC_COLLATE=it_IT.cp1252 failed
  > 3: Setting LC_TIME=it_IT.cp1252 failed
  > 4: Setting LC_MONETARY=it_IT.cp1252 failed
  > Carico il pacchetto richiesto: caret
  > Carico il pacchetto richiesto: lattice
  > Carico il pacchetto richiesto: ggplot2
  > Error in `$<-.data.frame`(`*tmp*`, fd, value = integer(0)) :
  >    replacement has 0 rows, data has 11
  > Calls: $<- -> $<-.data.frame/*
  > */
  > /*
  > A part is in italian, I'm sorry.
  > I'm a beginner in grass and R.

 R messages are often not very explicit, unfortunately.

 Could you provide us with the exact command line you use (If you
 use the
 GUI, you can get the command line by clicking the 'Copy' button
 once
 you've filled out all the parameters, or in the history of the
 'Console'
 in the Layer manager.) and an extract of the attribute data you
 feed
 into the module ?

 Moritz



Re: [GRASS-user] Problem with v.class.mIR

2019-12-04 Thread Moritz Lennert

Sorry for ignoring you up to now, just to much on the platter right now.

Would it be feasible for you to make the data available, privately if 
necessary ? The easiest (and lightest) would be just the csv output of 
v.db.select on the training_map and the segments_maps.


Moritz

On 2/12/19 16:31, Giuseppe Cillis wrote:

No one can help me?
GC

Il giorno mer 20 nov 2019 alle ore 14:06 Giuseppe Cillis 
mailto:giucil...@gmail.com>> ha scritto:


Thanks for the answer._
_
_
_
_v.class.mlR segments_map=gbbb@PERMANENT
training_map=tainning@PERMANENT train_class_column=fd
output_class_column=vote output_prob_column=prob folds=5
partitions=10 tunelength=10 weighting_metric=accuracy_

_and the same error with this command:
_
_v.class.mlR segments_map=gbbb training_map=tainning
train_class_column=class weighting_mode=smv,swv,qbwwv -i_

The vector used was elaborated with i.segment.stats module.
An extract is here:
cat areaperimeter   fd
1   958 208 1.555034
2   24  22  1.945217
3   160 80  1.726846
4   2036242 1.440904
5   25  26  2.024344
6   222 96  1.68966
7   843510121.530879


/cat /type Integer (9-0)
/fd /type double/real (25-9)
For the training area (t/ainning/), I use a simple vector with
numerical categories (named/"cate"/) and there are 11 features (just
for a trying). The type is in integer64 (10)

Il giorno mer 20 nov 2019 alle ore 12:18 Moritz Lennert
mailto:mlenn...@club.worldonline.be>>
ha scritto:

On 20/11/19 11:55, Giuseppe Cillis wrote:
 > Hi,
 > I'm trying to use this module for classification of an old
aerial photos.
 > After a segmentation (i.segment and i.segment.stats), I would
to use a
 > machine learning approach for the real classification.
 > I tried with v.class.mIR which use also R.
 > But there is an error and I don't know how to solve it:
 > */Durante l'avvio - Warning messages:
 > 1: Setting LC_CTYPE=it_IT.cp1252 failed
 > 2: Setting LC_COLLATE=it_IT.cp1252 failed
 > 3: Setting LC_TIME=it_IT.cp1252 failed
 > 4: Setting LC_MONETARY=it_IT.cp1252 failed
 > Carico il pacchetto richiesto: caret
 > Carico il pacchetto richiesto: lattice
 > Carico il pacchetto richiesto: ggplot2
 > Error in `$<-.data.frame`(`*tmp*`, fd, value = integer(0)) :
 >    replacement has 0 rows, data has 11
 > Calls: $<- -> $<-.data.frame/*
 > */
 > /*
 > A part is in italian, I'm sorry.
 > I'm a beginner in grass and R.

R messages are often not very explicit, unfortunately.

Could you provide us with the exact command line you use (If you
use the
GUI, you can get the command line by clicking the 'Copy' button
once
you've filled out all the parameters, or in the history of the
'Console'
in the Layer manager.) and an extract of the attribute data you
feed
into the module ?

Moritz


___
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] error while using i.segment.stats

2019-12-02 Thread Moritz Lennert
Hi Vero,

Le Mon, 2 Dec 2019 13:43:30 +0100,
Veronica Andreo  a écrit :

> Hi,
> 
> We are trying to use i.segment.stats for a map with 80+ segments
> and already in two different laptops, we get:
> 
> bands=`g.list rast pat=IGUAZU_IMG_* sep=,`
> RASTER_STATS=(min,max,range,mean,stddev,median,first_quart,third_quart,perc_90)
> AREA_STATS=(area,perimeter,compact_circle,compact_square,fd)
> 
> i.segment.stats -rc \
>  map=segments_full_region \
>  rasters=$bands \
>  raster_statistics=$RASTER_STATS \
>  area_measures=$AREA_STATS \
>  vectormap=segs_stats_map \
>  processes=4
> Calculating geometry statistics...
> Calculating statistics for raster maps...
> Exception in thread Thread-3:
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/threading.py", line 916, in
> _bootstrap_inner self.run()
>   File "/usr/lib/python3.6/threading.py", line 864, in run
> self._target(*self._args, **self._kwargs)
>   File "/usr/lib/python3.6/multiprocessing/pool.py", line 463, in
> _handle_results
> task = get()
>   File "/usr/lib/python3.6/multiprocessing/connection.py", line 251,
> in recv return _ForkingPickler.loads(buf.getbuffer())
> TypeError: __init__() missing 3 required positional arguments:
> 'module', 'code', and 'returncode'
> 
> Does it have to do with memory? I used the module a month ago with
> 50+ segments and it worked just fine...

I don't think memory is the issue, but I find the error message
pretty cryptic, so wouldn't exclude altogether. Could it be some
difference between Python 2 and 3 in the multiprocessing module ? Would
it be possible for you try running it in Python 2 ?

Maybe you could also try to run it on a smaller subset of the
segmentation result ?

Moritz


-- 
Département Géosciences, Environnement et Société Université Libre de
Bruxelles Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax  + 32 2 650.68.30 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] deleting lines by length, from a vector map

2019-12-01 Thread Moritz Lennert

On 1/12/19 08:39, Micha Silver wrote:


On 30/11/2019 16:11, Zoltan Szecsei wrote:

Hi,
I'm trying to write my first Grass python script to load Shape files 
and delete all lines shorter than 50m
I'm trying various permutations of the command below, but  no success 
(No error message and no lines deleted).

Any guidance would be welcome.

gscript.run_command('v.extract','r',input=gen,output=lin, where="( 
$LENGTH > 50 )",overwrite=True)
gscript.run_command('v.out.ogr', 'sce2', input=lin, type='line', 
output=dir_rclout + rcl + '.shp', format='ESRI_Shapefile', 
output_type='line',overwrite=True)




The term $LENGTH looks wrong to me.

In python I usually would do something like:


In [1]: import grass.script as gscript

In [4]: where_expr = "%s > %d" % ("'length'", 5000)

In [5]: where_expr
Out[5]: "'length' > 5000"

In [6]: gscript.run_command('v.extract', input="roads", 
output="roads_long", where=where_expr)


In order for this to work, you need a column 'length' in your attribute 
table. Do you have such a column. Otherwise, you can create it with v.to.db.


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

Re: [GRASS-user] Problem with v.class.mIR

2019-11-20 Thread Moritz Lennert

On 20/11/19 11:55, Giuseppe Cillis wrote:

Hi,
I'm trying to use this module for classification of an old aerial photos.
After a segmentation (i.segment and i.segment.stats), I would to use a 
machine learning approach for the real classification.

I tried with v.class.mIR which use also R.
But there is an error and I don't know how to solve it:
*/Durante l'avvio - Warning messages:
1: Setting LC_CTYPE=it_IT.cp1252 failed
2: Setting LC_COLLATE=it_IT.cp1252 failed
3: Setting LC_TIME=it_IT.cp1252 failed
4: Setting LC_MONETARY=it_IT.cp1252 failed
Carico il pacchetto richiesto: caret
Carico il pacchetto richiesto: lattice
Carico il pacchetto richiesto: ggplot2
Error in `$<-.data.frame`(`*tmp*`, fd, value = integer(0)) :
   replacement has 0 rows, data has 11
Calls: $<- -> $<-.data.frame/*
*/
/*
A part is in italian, I'm sorry.
I'm a beginner in grass and R.


R messages are often not very explicit, unfortunately.

Could you provide us with the exact command line you use (If you use the 
GUI, you can get the command line by clicking the 'Copy' button once 
you've filled out all the parameters, or in the history of the 'Console' 
in the Layer manager.) and an extract of the attribute data you feed 
into the module ?


Moritz

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

Re: [GRASS-user] i.segment: band_suffix does not seem to have effect

2019-11-20 Thread Moritz Lennert

On 20/11/19 11:19, Stefan Blumentrath wrote:

Hi,

I thought that if I give the band_suffix option in i.segment it 
produces bands with modified band values for all input bands. However, 
the option does not seem to have effect (no modified output bands are 
produced). Did I do or understand something wrong?


AFAIR, this option is only relevant if you use the mean shift 
segmentation approach. Is that what you are doing ?


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

Re: [GRASS-user] Trouble getting started

2019-11-15 Thread Moritz Lennert

On 16/11/19 03:10, Tom Trebisky wrote:
I see.  Well I have done my share of Gtk programming in C and via Ruby 
and I remember things of this sort (messages that were difficult or 
impossible to relate to code), especially when callbacks are 
registered.   I presume (or get the impression) that you are a developer 
and not just an end user of Grass.


I find myself half tempted to clone the Git repository and try to build 
Grass from sources, but this is not why I got involved here. And I am 
sure better minds than mine have already looked at this issue.


I might presume/guess that this has been identified as an upstream issue 
in the Python/Gtk bindings or perhaps even in Gtk itself -- and there 
may be better things to work on than chasing this in hopes that the 
teams upstream will do something about all of this.


See https://trac.osgeo.org/grass/ticket/3348.

If you have any suggestions, they are obviously welcome. :-)

Moritz

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

Re: [GRASS-user] Trouble getting started

2019-11-15 Thread Moritz Lennert
Le Fri, 15 Nov 2019 11:27:54 +0100,
Moritz Lennert  a écrit :

> Hi Tom,
> 
> Le Thu, 14 Nov 2019 20:40:31 -0700,
> Tom Trebisky  a écrit :
> 
> > I am totally new to grass and having trouble.  
> 
> Welcome to the community !
> 
> GRASS GIS does have a bit of a learning curve, but once you get past
> the first barriers you won't be able to live without it anymore ! ;-)
> 
> > 
> > I installed grass from RPM on my Fedora 30 linux system.  First I 
> > installed 7.6 from official fedora packages, then I erased that and 
> > installed 7.8 from packages on the Fedora "copr" repository. 

Another question: when exactly did you install these packages. 7.8.1
just arrived in the repository 3 days ago, IISC, so if you still have
7.8.0 you might want to start by installing the latest version.

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

Re: [GRASS-user] Trouble getting started

2019-11-15 Thread Moritz Lennert
Hi Tom,

Le Thu, 14 Nov 2019 20:40:31 -0700,
Tom Trebisky  a écrit :

> I am totally new to grass and having trouble.

Welcome to the community !

GRASS GIS does have a bit of a learning curve, but once you get past
the first barriers you won't be able to live without it anymore ! ;-)

> 
> I installed grass from RPM on my Fedora 30 linux system.  First I 
> installed 7.6 from official fedora packages, then I erased that and 
> installed 7.8 from packages on the Fedora "copr" repository.  I 
> downloaded the sample North Carolina dataset for version 7 (145M). I 
> untarred that into /home/tom/grassdata and when I browse to that,
> grass seems to find it and is ready to go.  But when I click on
> "Start Grass Session" I get two empty and useless windows 

When you say "empty", what does that mean exactly ? Could you provide a
screenshot ?

> and see the
> messages:
> 
> (wxgui.py:30767): Gtk-CRITICAL **: 20:37:16.297: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in
> GtkScrollbar
> 
> (wxgui.py:30767): Gtk-CRITICAL **: 20:37:16.297: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in
> GtkScrollbar

These are just annoying messages, but harmless and AFAIK do not
explain your issue.

> 
> I get the exact same with 7.6 and 7.8.
> 
> The useless windows call themselves "layer manager" and "map display".

These two windows should open by default when you launch the GRASS GIS
GUI, but they should contain buttons and menus.

If they do, then the next step for you should be to use the layer
manager window to add a map which should then appear in the map display
window.

Have you had the opportunity to read these to introductions:

https://grass.osgeo.org/grass78/manuals/helptext.html
https://grasswiki.osgeo.org/wiki/Quick_wxGUI_tutorial

Also check here:

https://grass.osgeo.org/documentation/tutorials/

for some more in depth tutorials.

> This seems like a reasonable way to get started.  What if anything am
> I doing wrong, or is this some known bug?

At this stage we need a bit more info to really know.

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

Re: [GRASS-user] QGIS 3.14.13 Crashes

2019-10-29 Thread Moritz Lennert

On 28/10/19 18:11, Martin Bittens wrote:

Hello QGIS Users,

if I try to open the 'Plugins' menu  in QGIS 3.14.13 QGIS is crashing.
The crash report tells me:


Crash ID: 45ba9a8f60f9a223c957d2c10b2a2b17a42d7c53

Stack Trace

QString::fill :
QString::indexOf :
QDir::fromNativeSeparators :
QFileInfo::QFileInfo :
QFileInfo::QFileInfo :
QgsPluginManager::reloadModelData qgspluginmanager.cpp:549
QgsAppPluginManagerInterface::showPluginManager
qgsapppluginmanagerinterface.cpp:33

QGIS Info
QGIS Version: 3.4.13-Madeira
QGIS code revision: 64ad560274
Compiled against Qt: 5.11.2
Running against Qt: 5.11.2
Compiled against GDAL: 2.4.1
Running against GDAL: 2.4.1

System Info
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.18362


In QGIS 3.9 and 3.10 I can open the 'Plugins' menu without any problems.


Does anybody get an idea what is going wrong in QGIS 3.4.13?


Thank you for your help.


This is the GRASS GIS mailing list. Please contact the QGIS users 
mailing list [1] for help with your problem.


Moritz

[1] https://qgis.org/en/site/getinvolved/mailinglists.html#qgis-mailinglists
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] winGRASS 7.8 64bit preview available in OSGeo4W - new snapshot: f5bfe545c

2019-10-28 Thread Moritz Lennert

On 27/10/19 20:27, Helmut Kudrnovsky wrote:

Helmut Kudrnovsky wrote

next winGRASS snapshot available:

GRASS GIS 7.8.1dev 4785a5b77

testing welcome


a new snapshot preview availabe in OSGeo4W 64bit

GRASS GIS 7.8.1dev f5bfe545c

with a fix for:

#3882 winGRASS: not able to digitize vector polygons
https://trac.osgeo.org/grass/ticket/3882

testing very welcome


Kudos to you, Martin, Anna, and the others who have worked on making 
this happen !


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

Re: [GRASS-user] Using GRASS and PostGIS

2019-10-28 Thread Moritz Lennert

On 22/10/19 21:41, Dheeraj Chand wrote:

Hello, all,

I've been proximal to GRASS for several years but never really used it much. I 
am currently working on macOS Catalina. One of the things that I find is that 
GRASS can get a bit slow here, part of which I attribute to running on 
SQLite/Spatialite.

I know that GRASS and PostGIS have different topology models, but is there some 
way to use it in lieu of SQLite as the primary datastore? I suspect that the 
power of PostgreSQL could make things a lot less painful for some of the bigger 
tasks.


GRASS GIS supports PostgreSQL as database backend for attributes. You 
can set the default database backend in a mapset using db.connect [1]. 
Once this is set, any newly created vector map will use the defined 
backend. For existing maps see v.db.connect [2] and v.db.reconnect.all 
[3]. For general intro see [4].


If you want to store the actual geometries in PostGIS, you can use 
v.external [5] to link the data into a GRASS GIS mapset. You will not, 
however, profit of the full topological power you get when using the 
native GRASS GIS vector format.


Moritz


[1] https://grass.osgeo.org/grass78/manuals/db.connect.html
[2] https://grass.osgeo.org/grass78/manuals/v.db.connect.html
[3] https://grass.osgeo.org/grass78/manuals/v.db.reconnect.all.html
[4] https://grass.osgeo.org/grass78/manuals/databaseintro.html
[5] https://grass.osgeo.org/grass78/manuals/v.external.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.kernel - Points weighted with attribute ?

2019-10-25 Thread Moritz Lennert

On 25/10/19 11:17, Taïs wrote:

Hi Micha,


I successfully run your R script. However to output is weird and I don't 
know how to fix it.


In v.kernel, you can setup the "raduis" parameter to control what I 
assume to be the size of the kernel (of the moving window).


AFAIU, radius is not the size of a moving window, it is the bandwidth of 
the kernel function. If you use a gaussian kernel, for example, it will 
be the standard deviation of the normal function to be used. If you use 
a uniform kernel it is the radius of the circular search window.


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

Re: [GRASS-user] Do not report cells where thousands of maps have no data

2019-09-28 Thread Moritz Lennert

On 27/09/19 17:39, Nikos Alexandris wrote:

GRASS GIS' `r.stats` modules does this:
```
r.stats input=$(g.list rast pattern=cru*.*1 separator=comma) -n -x -N
```

However, it won't do it for thousands of maps. Too many maps will hit
the '[Argument list too long]' error which is triggered by the ARG_MAX
constant.  Is there a work-around?


- use xargs
- use r.series with the -n flag and 'file' parameter



Else, I see no option but to set on a Python script that will loop over
thousands of maps and will identify pixels for which all maps have a
valid value.  Any recommendations (like best to user xarray or numpy or
rasterio or else...)?


I think r.series -n will give you what you want: any none null pixel in 
the output will have a value in all maps.


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

Re: [GRASS-user] Script fails; manual entry works

2019-09-18 Thread Moritz Lennert
Le Wed, 18 Sep 2019 13:22:22 -0700 (PDT),
Rich Shepard  a écrit :

> I've a script that begins this way:
> 
> #!/usr/bin/bash
> 
> # Create projection and exit
> # LDQ-45123G3:
> grass79 -c LDQ-45123G3/2009_OLC_Hood\ to\
> Coast/Bare_Earth/be45123g3/prj.adf /data/grassdata/g3 -e
> 
> grass79 g3/PERMANENT
> sleep 1s
> r.in.gdal in=LDQ-45123G3/2009_OLC_Hood\ to\
> Coast/Bare_Earth/be45123g3/hdr.adf out=45123g3_hood_to_coast
> mem=16000 --o r.import in=LDQ-45123G3/2009_OLC_Hood\ to\
> Coast/Bare_Earth/be45123g3h/hdr.adf out=45123g3h_hood_to_coast
> resamp=lanczos_f mem=16000 --o r.import
> in=LDQ-45123G3/2009_OLC_Willamette\
> Valley/Bare_Earth/be45123g3/hdr.adf out=45123g3_willamette_valley
> resamp=lanczos_f mem=16000 --o r.import
> in=LDQ-45123G3/2009_OLC_North\ Coast/Bare_Earth/be45123g3/hdr.adf
> out=45123g3_north_coast resamp=lanczos_f mem=16000 --o r.import
> in=LDQ-45123G3/2015_ODF_NW\
> Oregon-McGregor/Bare_Earth/be45123g3/hdr.adf
> out=45123g3_oregon_mcgregor resamp=lanczos_f mem=16000 --o exit
> 
> When I run the script, and kill it after a minute or so this is the
> console display:
> 
> GRASS 7.9.dev (g3):/data/grassdata > exit
> exit
> Cleaning up temporary files...
> Done.
> 
> Goodbye from GRASS GIS
> 
> ./process-lidar-dems-row-g.sh: line 12: r.in.gdal: command not found
> ./process-lidar-dems-row-g.sh: line 13: r.import: command not found
> ./process-lidar-dems-row-g.sh: line 14: r.import: command not found
> ./process-lidar-dems-row-g.sh: line 15: r.import: command not found
> ./process-lidar-dems-row-g.sh: line 16: r.import: command not found
> 
> However, when I block each of the first 4 lines in the script (other
> than the sleep command) grass processes r.in.gdal andr.import without
> throwing the 'command not found' error.
> 
> What have I done incorrectly which breaks the script at line 9 (I've
> redacted a few lines in this version)?

You cannot launch GRASS GIS within the script in this way. You have to
put the actual module calls into a script and then either

- launch GRASS GIS and from the GRASS command line launch the script, or
- follow
  https://grasswiki.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs,
  i.e. let the GRASS_BATCH_JOB variable point to your script

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

Re: [GRASS-user] Models using r.buildvrt

2019-09-18 Thread Moritz Lennert
Le Wed, 18 Sep 2019 10:56:04 -0700 (PDT),
Rich Shepard  a écrit :

> There are 29 individual DEM maps for the drainage basin. The
> r.buildvrt manual tells me that using r.buildvrt will produce a
> slower loading map than would loading each raster map individually
> unless only a small portion of the virtual raster will be used.
> 
> Here, small portions of some DEM maps extend past the watershed
> boundary and that vector map will be used as a mask.
> 
> For hydrologic, terrain, and geomorphic analyses might processing
> times be different using all individual maps or a virtual one?

AFAIK, one could summarize in the following way:

- Reading a small map is faster than reading a large map
- Reading one single map is faster than reading many maps

What the above citation from the r.buildvrt man page says is that it's
all about compromise and use case:

- If you have data covering a very large zone, but your actual
  processing always only actually concerns small portions of that zone,
  but these portions might be across more than one existing tile, than
  you are better off combining the tiles virtually using the VRT
  paradigm.

- If however, you always work on the entire zone at once, then tiling +
  VRT will slow things down compared to using one single big map.

Tile size will obviously play a role. Depending on the size of your
DEMs and of the zones you need to treat, you could possibly get better
results by dividing your DEMs into even smaller tiles.

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

Re: [GRASS-user] Explain v.in.ogr error

2019-09-12 Thread Moritz Lennert

On 12/09/19 17:10, Rich Shepard wrote:

On Thu, 12 Sep 2019, Moritz Lennert wrote:


Could it be that your FileGDB contains raster data ?


Moritz,

Yes, it should be raster data.


AFAIK, this not support by GDAL at the moment, and if it was, you would
have to use r.in.gdal, not v.in.ogr.


That is the problem: FileGDB is not supported by GDAL and is not in the
r.in.gdal's list of suported formats.

Is there a tool to convert .gdb to something that r.in.gdal will accept? I'm
not going to have the source change the format as they use only ESRI's
ArcGIS and are likely limited to what export options that has.


I've tried with this: https://github.com/r-barnes/ArcRasterRescue, but 
without success so far.


You can also try Even's script referenced at the link above: 
https://github.com/rouault/dump_gdbtable


So, sorry, this is proprietary format hell with only reverse engineering 
as a solution...


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

Re: [GRASS-user] Explain v.in.ogr error

2019-09-12 Thread Moritz Lennert

On 11/09/19 17:53, Rich Shepard wrote:

Trying to import an ESRI FileGDB with 10m DEM for Oregon. I don't understand
what I've done incorrectly and would appreciate learning from the grass
command error message.

Input file is OR_DEM_10M.gdb

$ ogrinfo -al -so
Geometry: Multi Polygon
Feature Count: 1
Extent: (-106508955.00, -85400955.00) - (109133655.00, 
130241655.00)
Layer SRS WKT:
PROJCS["NAD_1983_Oregon_Statewide_Lambert_Feet_Intl",
  GEOGCS["GCS_North_American_1983",
  DATUM["North_American_Datum_1983",
  SPHEROID["GRS_1980",6378137.0,298.257222101]],
  PRIMEM["Greenwich",0.0],
  UNIT["Degree",0.0174532925199433]],
  PROJECTION["Lambert_Conformal_Conic_2SP"],
  PARAMETER["False_Easting",1312335.958005249],
  PARAMETER["False_Northing",0.0],
  PARAMETER["Central_Meridian",-120.5],
  PARAMETER["Standard_Parallel_1",43.0],
  PARAMETER["Standard_Parallel_2",45.5],
  PARAMETER["Latitude_Of_Origin",41.75],
  UNIT["Foot",0.3048]]
FID Column = OID
Geometry Column = FOOTPRINT
RASTER: Binary (0.0)
FOOTPRINT_Length: Real (0.0)
FOOTPRINT_Area: Real (0.0)

Run error:
v.in.ogr input=/data/grassdata/OR_DEM_10M.gdb output=dem10m
Check if OGR layer  contains polygons...
Creating attribute table for layer ...
WARNING: Column type (Ogr_ftype: 8) not supported (Ogr_fieldname: RASTER)


Could it be that your FileGDB contains raster data ?

AFAIK, this not support by GDAL at the moment, and if it was, you would 
have to use r.in.gdal, not v.in.ogr.


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

Re: [GRASS-user] r3.in.ascii --- Please help!

2019-09-04 Thread Moritz Lennert
Le Wed, 4 Sep 2019 08:17:16 +,
Lindsi Seegmiller  a écrit :

> I cannot get r3.in.ascii to work.  Does anyone have success importing
> 3d rasters?  For example, a simple ascii like the one below.

I can import this without issues. How are you importing it and what
error messages do you get ? And which version of GRASS GIS are you
using on which OS ?

Moritz

> 
> version: grass7
> order: nsbt
> north: 3.00
> south: 0.00
> east: 4.00
> west: 0.00
> top: 2.00
> bottom: 0.00
> rows: 3
> cols: 4
> levels: 2
> 3 4 5 6
> 4 5 6 7
> 5 6 7 8
> 4 5 6 7
> 5 6 7 8
> 6 7 8 9



-- 
Département Géosciences, Environnement et Société Université Libre de
Bruxelles Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax  + 32 2 650.68.30 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Finding equal distant locations from a point on a network

2019-08-27 Thread Moritz Lennert
Le Mon, 26 Aug 2019 15:39:54 -0400,
Mehrdad Varedi  a écrit :

> Hi Everyone,
> 
> Would you please help me to see how can I find all points that have
> the same distance from a specific location on a network?
> For example, we have a road network and want to find locations that
> are 1 km away from a store?

v.net.iso ?

Moritz
-- 
Département Géosciences, Environnement et Société Université Libre de
Bruxelles Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax  + 32 2 650.68.30 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] licensing question: calling GRASS GIS modules via the grass.script API in an MIT/Apache licensed script ?

2019-08-24 Thread Moritz Lennert
Hi Vaclav,

Thanks for taking the time for this !

Le Fri, 23 Aug 2019 21:42:15 -0400,
Vaclav Petras  a écrit :

> On Tue, May 7, 2019 at 4:42 AM Moritz Lennert
>  wrote:
> 
> > Hi,
> >
> > We work with a company on a project where we use GRASS GIS to
> > calculate accessibility indicators. The main output we provide is a
> > Python script which calls GRASS GIS modules via the grass.script
> > API. The company is willing to make this script free software, but
> > would like to license it with a permissive license such as MIT or
> > Apache.
> >
> > I would think that calling GRASS GIS modules in a script does not
> > automatically imply the script has to be GPL, but what about the
> > use of the Python API ?
> >
> > I would think that this case falls in the grey area described at
> > [1] and have tendency to think that MIT/Apache license would be
> > allowed. 
> 
> Hi Moritz,
> 
> To make things more complicated: Note that if MIT is allowed, that
> (would) mean(s) that proprietary is also allowed, i.e. can you
> license it under an arbitrary licensing terms and conditions. So, I
> think you are basically asking if you can create proprietary scripts
> which are using GRASS GIS modules and also if there is a difference
> between a script and a software in this context. Is doing scripting
> in GRASS GIS mere using of GRASS GIS or it is making derived
> programs? There is general agreement that Bash scripts can be
> MIT/proprietary, but is calling GRASS GIS modules the same as calling
> POSIX defined tools? Depending on the answers, you can be looking at
> incorporating GPL-covered software in a proprietary system [2].

I would consider GRASS modules as equivalent to any bash executables.
My question was more about the GRASS GIS Python API which is actual
GRASS GIS code. That's why I was wondering whether such scripts would
be considered as derived work.

> 
> But first, I would be asking for reasons for requiring MIT/Apache.
> Clearly, it is not *fear* of leaking patent rights with GPLv3 because
> that would rule out Apache. If the reason is keeping the option to
> reuse pieces of the code in a propriety product by the company, I
> don't see why that would be an issue because 1) as a copyright
> holder, you can decide to change licensing at any time

If your code falls under GPL rules (because it is derived) that require
the use of GPL (or similar) for any release, can you still decide to
change the licensing ?

> and 2) even if
> you keep GPL, you can use modified GPL code internally without
> releasing it. 

I'll have to discuss this with the company. It was not clear yet where
the code would actually run, possibly in machines of clients (public
administrations, etc). In that case this means they distribute the
code. They suggested MIT, but I think they could be open to GPL if I
can show them that this will not cause any issues for their business. I
guess that if the script remains an independent piece of software that
clients just use, then it can simply be distributed under GPL, but it
will be used in conjuction with other, proprietary, software, so I
guess it is maybe more a question of how they package the whole thing,
possibly distributing the two separately.

> Use of GPL software is oviously not an issue either
> here. On top of that, the increasing use of SaaS and GPL behavior
> there [3] makes me wonder why to even talk about this and not go with
> the obviously save choice GPL >=2.

Again, this is not entirely up to me (otherwise it would obviously be
GPL). Maybe there is just some unjustified fear on their side.

> 
> To push back a little, I would say that if somebody has the capacity
> to have reasons for MIT/Apache which go beyond what I tried to
> describe in the previous paragraph, I would say they have capacity to
> determine the licensing options here, i.e. answer my first paragraph.
> This serves also as my "I'm not a lawyer statement."
> 
> And a more practical note, in case the conclusion of all this is
> still a MIT or Apache license, note that Apache 2.0 is not compatible
> with GPL v2 (it is compatible only with v3), so it would not be
> possible to include the code into GRASS GIS (which is >=2) if
> somebody decides to do so.

It is not code to be included in GRASS GIS, but code that uses GRASS
GIS...

Thanks again !

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

Re: [GRASS-user] licensing question: calling GRASS GIS modules via the grass.script API in an MIT/Apache licensed script ?

2019-08-14 Thread Moritz Lennert

Ping.

Anyone ?

Or a pointer to whom I could ask ?

Moritz

On 7/05/19 10:42, Moritz Lennert wrote:

Hi,

We work with a company on a project where we use GRASS GIS to calculate
accessibility indicators. The main output we provide is a Python script
which calls GRASS GIS modules via the grass.script API. The company is
willing to make this script free software, but would like to license it
with a permissive license such as MIT or Apache.

I would think that calling GRASS GIS modules in a script does not
automatically imply the script has to be GPL, but what about the use of
the Python API ?

I would think that this case falls in the grey area described at [1] and
have tendency to think that MIT/Apache license would be allowed.

Does anyone have a more informed opinion ?

Moritz


[1] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation




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

Re: [GRASS-user] too many categories: buffer overflow

2019-06-20 Thread Moritz Lennert

On 18/06/19 21:51, Ken Mankoff wrote:

Hi Micha and Markus,

On 2019-06-18 at 10:07 -04, Micha Silver  wrote...

Do you really want a vector polygon map with > 2 billion features?


No, and there are not that many.

% r.info -r basins
   min=-2147474681
   max=2147429730

But I don't have categories from 1 to 2147429730. The values are sparse. I 
describe my workflow and why I've created these sparse values in more detail 
below.

Even though << 2 billion, there should be many basins. This is all of Greenland 
at 30 m resolution, which is 4.5 billion features.

Taking a step back, I'm trying to generate unique basin values that match the 
stream and outlet CAT values. Here is my workflow which doesn't appear to have 
any problems when run at 90x90 m resolution (400 million cells) but fails at 
30x30 m resolution (10x as many, or 4.5 billion cells).

1) Find streams:

r.stream.extract elevation=head threshold=${THRESH} memory=16384 direction=dir 
stream_raster=streams stream_vector=streams

2) Find outlets. Where streams have outlets, use the same CAT value so the two can 
be linked in further analysis. But many outlets don't have streams. These need to 
have unique categories for the next step when we find basins. This is where my 
error is. I set the unique value to the cell #, which is > 2 billion when using 
a 30x30 m domain.

r.mapcalc "outlets_all = if(dir < 0, 1, null())"
r.mapcalc "outlets_streams_1 = if((dir < 0) && (not(isnull(streams))), streams, 
outlets_all)"
### BUG INTRODUCED HERE, setting (eventual) cat to cell number:
r.mapcalc "outlets_streams = if(outlets_streams_1 != 1, outlets_streams_1, 
max(outlets_streams_1)+1+col()+(max(col())*(row()-1)))"

# convert outlets to a vector.
r.out.xyz input=outlets_streams | \
 v.in.ascii input=- output=outlets_streams separator=pipe \
 columns="x int, y int, cat int" x=1 y=2 cat=3

Q: How can I create the outlets_streams vector for all locations where dir < 0 
(all outlets), that maintains the same value as the streams raster where that raster 
is defined, but unique values at all other locations where streams is not defined, 
but dir < 0?


3) Find basins

r.stream.basins -m direction=dir points=outlets_streams basins=basins_all 
memory=16384 --verbose


4) Absorb small basins

r.clump -d input=basins_all output=basins_nosmall minsize=124
r.mode base=basins_nosmall cover=basins_all output=basins
### BUG APPEARS HERE
r.to.vect -v input=basins output=basins type=area

# drop outlets for absorbed basins.
r.mapcalc "outlets = if(outlets_streams == basins, basins, null())"
r.to.vect -v input=outlets output=outlets type=point

NOTE: I use r.mode instead of r.area because I need to maintain the category 
value, so that eventual vectors can have linked primary keys. r.area re-assigns 
categories.


Any advice how to generate streams, outlets, and basins all with linked primary 
key would be much appreciated.


Just a rapid, wild guess here, but would it be feasible to just 
vectorize the three separately and then create the link afterwards using 
v.distance ?


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

Re: [GRASS-user] How to check if a raster has a NULL value

2019-06-18 Thread Moritz Lennert

On 18/06/19 15:31, Markus Neteler wrote:

Hi Robert,

On Tue, Jun 18, 2019 at 1:54 PM Robert Nuske  wrote:


Hi Listers,

r.fillnulls exits with an error if the input map has no holes.
r.fillnulls one step in a bash script. The processing is stopped if
r.fillnulls writes no output because of an error.

Thus i would like to check if any holes need to be filled. If this is
the case run r.fillnulls and if not just copy input to output map name.

Is there a handy command which reports if there are any NULLs in the
raster map. The output of the command shall be used in a bash if
construction.


Yes: e.g., r.univar can do that:

GRASS 7.6.2git (nc_spm_08_grass7):~ >

g.region raster=boundary_county_500m
r.univar -g boundary_county_500m
n=616509
null_cells=506073
cells=1122582
min=0
max=199
range=199
mean=87.1764564669778
mean_of_abs=87.1764564669778
stddev=62.4325833627095
variance=3897.82746534167
coeff_var=71.6163352961689
sum=53745070

Usage in a shell script:

g.region raster=boundary_county_500m
eval $(r.univar -g boundary_county_500m)
echo $null_cells
506073



Just watch out that this will not work as expected when you have set a mask:

https://trac.osgeo.org/grass/ticket/3696

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

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

2019-05-22 Thread Moritz Lennert
Le Wed, 22 May 2019 19:25:19 +0200,
Veronica Andreo  a écrit :

> Hi Markus,
> 
> Thanks for the explanation. It is possible to import topologically
> incorrect vectors, but not create them within GRASS. So, as a
> solution to my problem, I rather create (potentially overlapping)
> buffers outside GRASS and import them with -c in v.in.ogr to use
> v.rast.stats with no loss of areas, or follow the procedure that you
> described earlier in the thread.

You can also have a look at the v.rast.bufferstats addon.

Moritz

> 
> Cheers,
> Vero
> 
> El mié., 22 may. 2019 a las 18:48, Markus Metz (<
> markus.metz.gisw...@gmail.com>) escribió:  
> 
> >
> >
> > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo
> >  wrote:  
> > >
> > > Dear all,
> > >
> > > thanks again for your answers. I found an easier way, use -c flag
> > > in  
> > v.in.ogr seems to not build topology of overlapping areas and then
> > v.rast.stats does not complain.  
> > >
> > > However, if one builds buffer areas for points within GRASS,
> > > i.e., using  
> > v.buffer, the problem appears again when buffer areas overlap,
> > which it's pretty common when creating buffers around neighbouring
> > points. Then, to get zonal stats for those areas the approach
> > suggested by Markus Metz should be followed. I believe it is a bit
> > of an overkill for such a common task in GIS. Couldn't v.buffer
> > have a -c flag as v.in.ogr so when overlapping of buffer areas is
> > fine the topology is not built and one would get just one area per
> > input point? Would that be possible?
> >
> > In short, no.
> >
> > The reason is that with a topological vector model, areas are
> > constructed from boundaries and centroids. If you use the -c flag
> > of v.in.ogr and there are polygons that overlap to a large degree
> > or completely, it is not possible to find a centroid for each
> > topological area, i.e. the overlapping input polygons can not be
> > properly represented with a topological model when using the -c
> > flag. As soon as you get incorrect boundaries and/or duplicate
> > centroids when building topology, results are wrong.
> >
> > Markus M
> >  
> > >
> > > cheers,
> > > Vero
> > >
> > >
> > >
> > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
> > mlenn...@club.worldonline.be>) escribió:  
> > >>
> > >> On 16/05/19 03:11, Veronica Andreo wrote:  
> > >> > Dear all,
> > >> >
> > >> > thanks for the answers...
> > >> >
> > >> > @Madi, I know, but that's how I got the data from a colleague
> > >> > using SaTScan to get cluster sizes.
> > >> >
> > >> > So, these "clusters" are 3, they are represented by circular
> > >> > areas  
> > and 2  
> > >> > of them overlap, and it is just fine that they overlap. I just
> > >> > want  
> > one  
> > >> > centroid per area to be able to get one value per original
> > >> > area.
> > >> >
> > >> > I tested your solution, @Micha (thanks much for your time!),
> > >> > but it gives me 4 values, and I need 3. Moreover, I can no
> > >> > longer recognize which polygon is which since v.db.select for
> > >> > layer 3 reports cats  
> > from 1  
> > >> > to 4, but d.vect shows something different (I'd assume 2/3 has
> > >> > become 4?). See screenshot below.  
> > >>
> > >> To see the cat values of layer 3 you have to indicate that layer
> > >> in the label_layer parameter (Labels tab).
> > >>
> > >> You can also see the correspondance between the two layers with
> > >>
> > >> v.category polys_3layers op=print layer=1,3
> > >>  
> > >> >
> > >> > So, is it possible somehow to keep my 3 original polygons? And
> > >> > how  
> > can I  
> > >> > get raster values for my original 3 polygons in GRASS? Or is
> > >> > it that this is not allowed by topology?  
> > >>
> > >> This depends on how you want to get raster values. If
> > >> v.what.rast at the location of the centroid is all you need than
> > >> Micha's solution should  
> > work.  
> > >>
> > >> If you need v.rast.stats then you either have to use Markus'
> > >> suggestion, or you u

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

2019-05-16 Thread Moritz Lennert

On 16/05/19 03:11, Veronica Andreo wrote:

Dear all,

thanks for the answers...

@Madi, I know, but that's how I got the data from a colleague using 
SaTScan to get cluster sizes.


So, these "clusters" are 3, they are represented by circular areas and 2 
of them overlap, and it is just fine that they overlap. I just want one 
centroid per area to be able to get one value per original area.


I tested your solution, @Micha (thanks much for your time!), but it 
gives me 4 values, and I need 3. Moreover, I can no longer recognize 
which polygon is which since v.db.select for layer 3 reports cats from 1 
to 4, but d.vect shows something different (I'd assume 2/3 has become 
4?). See screenshot below.


To see the cat values of layer 3 you have to indicate that layer in the 
label_layer parameter (Labels tab).


You can also see the correspondance between the two layers with

v.category polys_3layers op=print layer=1,3



So, is it possible somehow to keep my 3 original polygons? And how can I 
get raster values for my original 3 polygons in GRASS? Or is it that 
this is not allowed by topology?


This depends on how you want to get raster values. If v.what.rast at the 
location of the centroid is all you need than Micha's solution should work.


If you need v.rast.stats then you either have to use Markus' suggestion, 
or you use Micha's approach running v.rast.stats on layer three and then 
use some magic to transform the output of the above v.category call to a 
correspondance table between layer. Something like this


import grass.script as g
for feature in g.read_command('v.category',
  input_='polys_3layers',
  op='print',
  layer=[3,1]).splitlines():
 cat1 = feature.split('|')[0]
 cats2 = feature.split('|')[1].split('/')
 for cat2 in cats2:
 print cat1, cat2

This correspondance table could then be used to aggregate the raster 
stats per (original) polygon in SQL. This could be the easily put into 
an addon module.


Moritz

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

  1   2   3   4   5   6   7   8   9   10   >