Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Michael Barton via grass-dev]

y   0  0  0
centroid   1 28 28
area   0  0  0
face   0  0  0
kernel 0  0  0
all1 28 28

It stays at cat=28. Oddly, when I display the map and query it, it has no cat 
number visible in the query output in the GUI. But v.category shows that it 
still has a category somewhere. And if I then use v.category to try to add a 
new cat, starting at 1, the result is a map with cat=28 again. And when I 
patch, using your PR, I get the same results I had before.

Michael

_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://comses.net/>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 15, 2024, at 8:51 AM, Huidae Cho  wrote:

Michael,

Just confirmed your issue.

v.random tmp100 npoints=100 seed=100
v.db.addtable tmp100 col="id varchar(20)"
v.db.update tmp100 col=id qcol="'tmp100_' || cat"

v.random tmp10 npoints=10 seed=10
v.db.addtable tmp10 col="id varchar(20)"
v.db.update tmp10 col=id qcol="'tmp10_' || cat"

v.patch tmp100,tmp10 out=tmp110 -e

v.category tmp110 op=report
Layer/table: 1/tmp110
type   countminmax
point110  2112
line   0  0  0
boundary   0  0  0
centroid   0  0  0
area   0  0  0
face   0  0  0
kernel 0  0  0
all  110  2112

In my case, all features in tmp10 are linked in tmp110.

You can recategorize it.

v.category tmp110 out=tmp110_nocats op=del cat=-1
v.category tmp110_nocats out=tmp110_recats op=add

npnts100=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp100 -t | sed '/points=/!d; s/points=//')
npnts10=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp10 -t | sed '/points=/!d; s/points=//')

v.db.update tmp110_recats col=cat qcol=cat-1 where="cat<=$npnts100+1"
v.db.update tmp110_recats col=cat qcol=cat-2 where="cat>$npnts100+1"

Yeah... I know what you may think... Please create an issue on GitHub.

Regards,
Huidae

On Thu, Mar 14, 2024 at 4:42 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Doug and Vincent.

None of this works. I vaguely remember having this same kind of road block 
several years back.

Nothing in v.category lets you change an existing cat value to a different value
v.in.ogr MUST add a column that MUST be named cat (all else causes an 
error--this is a bug) that is a series of consecutive integers from 1-n. So I 
cannot create a file with a cat field that matches my vector areas.

v.edit won't let you change an existing cat number AFAICT. No error but nothing 
changes.

Once I've imported a table using v.in.ogr, I cannot use db.drop.column to 
delete the cat column--even if it is not being used as a key field. This raises 
an error.

No way to rename a column from cat to something else (or something else to cat) 
unless you've already connected it to a vector map even if cat is not the key 
field. So I can't create an integer column to link up my lost vector area with 
a record in my csv file.

This simple task is just not possible in GRASS AFAICT. Or if it is possible, it 
can only be done by such non-obvious and convoluted means that I've yet to find 
a method that works in spite of asking a large number of very skilled GRASS 
users.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5

Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Michael Barton via grass-dev]

Never mind. I figured it out when I saw the post. Now for the next step.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 15, 2024, at 3:29 PM, Michael Barton  wrote:

Something is just not working here.

I can't try the new PR until I can get the original cats fixed. v.category does 
not seem to be working as expected. I have a map with a single area. I clipped 
it out of another map (where it had cat=18) using v.select. When I check the 
categories, it looks like this:

v.category input=SA5@SAA2024 type=centroid option=report
Layer/table: 1/SA5
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   1 28 28
area   0  0  0
face   0  0  0
kernel 0  0  0
all1 28 28

So I want to follow your example to first delete categories and then add them 
back in starting at 1.

v.category --overwrite input=SA5@SAA2024 output=NA5a option=del cat=-1

But delete does not seem to work.

GRASS : ~ > v.category input=SA5a@SAA2024 option=report
Layer/table: 1/SA5a
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   1 28 28
area   0  0  0
face   0  0  0
kernel 0  0  0
all1 28 28

It stays at cat=28. Oddly, when I display the map and query it, it has no cat 
number visible in the query output in the GUI. But v.category shows that it 
still has a category somewhere. And if I then use v.category to try to add a 
new cat, starting at 1, the result is a map with cat=28 again. And when I 
patch, using your PR, I get the same results I had before.

Michael

_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://comses.net/>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 15, 2024, at 8:51 AM, Huidae Cho  wrote:

Michael,

Just confirmed your issue.

v.random tmp100 npoints=100 seed=100
v.db.addtable tmp100 col="id varchar(20)"
v.db.update tmp100 col=id qcol="'tmp100_' || cat"

v.random tmp10 npoints=10 seed=10
v.db.addtable tmp10 col="id varchar(20)"
v.db.update tmp10 col=id qcol="'tmp10_' || cat"

v.patch tmp100,tmp10 out=tmp110 -e

v.category tmp110 op=report
Layer/table: 1/tmp110
type   countminmax
point110  2112
line   0  0  0
boundary   0  0  0
centroid   0  0  0
area   0  0  0
face   0  0  0
kernel 0  0  0
all  110  2112

In my case, all features in tmp10 are linked in tmp110.

You can recategorize it.

v.category tmp110 out=tmp110_nocats op=del cat=-1
v.category tmp110_nocats out=tmp110_recats op=add

npnts100=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp100 -t | sed '/points=/!d; s/points=//')
npnts10=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp10 -t | sed '/points=/!d; s/points=//')

v.db.update tmp110_recats col=cat qcol=cat-1 where="cat<=$npnts100+1"
v.db.update tmp110_recats col=cat qcol=cat-2 where="cat>$npnts100+1"

Yeah... I know what you may think... Please create an iss

[GRASS-dev] v.dissolve confusion

[Michael Barton via grass-dev]

Any suggestions about what is wrong with either of the versions of this 
dissolve command?

v.dissolve --overwrite input=alcala_subsectors@SAA2024 column=ID 
output=alcala_subsectors_dissolved@SAA2024 
aggregate_columns=group_concat(REGION),max(STRATUM),max(SECTOR),avg(SUBSECTOR),group_concat(SECTOR_ID),sum(AREA),group_concat(SURVEYED),avg(IDNUM)
 result_columns="region TEXT,stratum INTEGER,sector INTEGER,subsector 
REAL,sector_ID TEXT,area REAL,surveyed TEXT,IDnum REAL"

v.dissolve --overwrite input=alcala_subsectors@SAA2024 column=ID 
output=alcala_subsectors_dissolved@SAA2024 
aggregate_columns=group_concat(REGION),max(STRATUM),max(SECTOR),avg(SUBSECTOR),group_concat(SECTOR_ID),sum(AREA),group_concat(SURVEYED),avg(IDNUM)
 result_columns="region,stratum,sector,subsector,sector_ID,area,surveyed,IDnum"

I'm trying to maintain my attribute table because of the great difficulty in 
reconnecting it. In both cases, I get the error:
Option  requires all of 

I have the same number of result columns as I do aggregate columns with 
equivalent data types.

I have 8 columns (dissolved by the 9th column ID):
region TEXT
stratum INTEGER
sector INTEGER
subsector REAL
sector_ID TEXT
area REAL
surveyed TEXT
IDnum REAL

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Michael Barton via grass-dev]

Something is just not working here.

I can't try the new PR until I can get the original cats fixed. v.category does 
not seem to be working as expected. I have a map with a single area. I clipped 
it out of another map (where it had cat=18) using v.select. When I check the 
categories, it looks like this:

v.category input=SA5@SAA2024 type=centroid option=report
Layer/table: 1/SA5
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   1 28 28
area   0  0  0
face   0  0  0
kernel 0  0  0
all1 28 28

So I want to follow your example to first delete categories and then add them 
back in starting at 1.

v.category --overwrite input=SA5@SAA2024 output=NA5a option=del cat=-1

But delete does not seem to work.

GRASS : ~ > v.category input=SA5a@SAA2024 option=report
Layer/table: 1/SA5a
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   1 28 28
area   0  0  0
face   0  0  0
kernel 0  0  0
all1 28 28

It stays at cat=28. Oddly, when I display the map and query it, it has no cat 
number visible in the query output in the GUI. But v.category shows that it 
still has a category somewhere. And if I then use v.category to try to add a 
new cat, starting at 1, the result is a map with cat=28 again. And when I 
patch, using your PR, I get the same results I had before.

Michael

_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 15, 2024, at 8:51 AM, Huidae Cho  wrote:

Michael,

Just confirmed your issue.

v.random tmp100 npoints=100 seed=100
v.db.addtable tmp100 col="id varchar(20)"
v.db.update tmp100 col=id qcol="'tmp100_' || cat"

v.random tmp10 npoints=10 seed=10
v.db.addtable tmp10 col="id varchar(20)"
v.db.update tmp10 col=id qcol="'tmp10_' || cat"

v.patch tmp100,tmp10 out=tmp110 -e

v.category tmp110 op=report
Layer/table: 1/tmp110
type   countminmax
point110  2112
line   0  0  0
boundary   0  0  0
centroid   0  0  0
area   0  0  0
face   0  0  0
kernel 0  0  0
all  110  2112

In my case, all features in tmp10 are linked in tmp110.

You can recategorize it.

v.category tmp110 out=tmp110_nocats op=del cat=-1
v.category tmp110_nocats out=tmp110_recats op=add

npnts100=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp100 -t | sed '/points=/!d; s/points=//')
npnts10=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp10 -t | sed '/points=/!d; s/points=//')

v.db.update tmp110_recats col=cat qcol=cat-1 where="cat<=$npnts100+1"
v.db.update tmp110_recats col=cat qcol=cat-2 where="cat>$npnts100+1"

Yeah... I know what you may think... Please create an issue on GitHub.

Regards,
Huidae

On Thu, Mar 14, 2024 at 4:42 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Doug and Vincent.

None of this works. I vaguely remember having this same kind of road block 
several years back.

Nothing in v.category lets you change an existing cat value to a different value
v.in.ogr MUST add a column that MUST be named cat (all else causes an 
error--this is a bug) that is a series of consecutive integers from 1-n. So I 
cannot create a file with a cat field that matches my vector areas.

v.edit won't let you change an existing cat number AFAICT. No error but nothing 
changes.

Once I've imported a table using v.in.ogr, I cannot use db.drop.column to 
delete the cat column--even if it is not being used as a key field. This raises 
an error.

No way to rename a column from cat to something else (or something else to cat) 
unl

Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Michael Barton via grass-dev]

Thanks Huidae,

Your new PR looks like it will seriously simplify patching from the complicated 
and non-intuitive solution and Vincent describe in current GRASS versions.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 15, 2024, at 8:51 AM, Huidae Cho  wrote:

Michael,

Just confirmed your issue.

v.random tmp100 npoints=100 seed=100
v.db.addtable tmp100 col="id varchar(20)"
v.db.update tmp100 col=id qcol="'tmp100_' || cat"

v.random tmp10 npoints=10 seed=10
v.db.addtable tmp10 col="id varchar(20)"
v.db.update tmp10 col=id qcol="'tmp10_' || cat"

v.patch tmp100,tmp10 out=tmp110 -e

v.category tmp110 op=report
Layer/table: 1/tmp110
type   countminmax
point110  2112
line   0  0  0
boundary   0  0  0
centroid   0  0  0
area   0  0  0
face   0  0  0
kernel 0  0  0
all  110  2112

In my case, all features in tmp10 are linked in tmp110.

You can recategorize it.

v.category tmp110 out=tmp110_nocats op=del cat=-1
v.category tmp110_nocats out=tmp110_recats op=add

npnts100=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp100 -t | sed '/points=/!d; s/points=//')
npnts10=$(v.info<https://urldefense.com/v3/__http://v.info__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgeoBImgQ$>
 tmp10 -t | sed '/points=/!d; s/points=//')

v.db.update tmp110_recats col=cat qcol=cat-1 where="cat<=$npnts100+1"
v.db.update tmp110_recats col=cat qcol=cat-2 where="cat>$npnts100+1"

Yeah... I know what you may think... Please create an issue on GitHub.

Regards,
Huidae

On Thu, Mar 14, 2024 at 4:42 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Doug and Vincent.

None of this works. I vaguely remember having this same kind of road block 
several years back.

Nothing in v.category lets you change an existing cat value to a different value
v.in.ogr MUST add a column that MUST be named cat (all else causes an 
error--this is a bug) that is a series of consecutive integers from 1-n. So I 
cannot create a file with a cat field that matches my vector areas.

v.edit won't let you change an existing cat number AFAICT. No error but nothing 
changes.

Once I've imported a table using v.in.ogr, I cannot use db.drop.column to 
delete the cat column--even if it is not being used as a key field. This raises 
an error.

No way to rename a column from cat to something else (or something else to cat) 
unless you've already connected it to a vector map even if cat is not the key 
field. So I can't create an integer column to link up my lost vector area with 
a record in my csv file.

This simple task is just not possible in GRASS AFAICT. Or if it is possible, it 
can only be done by such non-obvious and convoluted means that I've yet to find 
a method that works in spite of asking a large number of very skilled GRASS 
users.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhi94Wl0mw$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!eDFcy3DMNQS8CMpiCzhp6trLuDrQNXlfIg-UEXoodTPi_yE5QtH-fHSHLEzHn3h0gXJrHPn76a9pFhgAFoliVQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 14, 2024, at 7:10 AM, Newcomb, Doug 
mailto:doug_newc...@fws.gov>> wrote:

Have

Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Michael Barton via grass-dev]

Thanks Doug and Vincent.

None of this works. I vaguely remember having this same kind of road block 
several years back.

Nothing in v.category lets you change an existing cat value to a different value
v.in.ogr MUST add a column that MUST be named cat (all else causes an 
error--this is a bug) that is a series of consecutive integers from 1-n. So I 
cannot create a file with a cat field that matches my vector areas.

v.edit won't let you change an existing cat number AFAICT. No error but nothing 
changes.

Once I've imported a table using v.in.ogr, I cannot use db.drop.column to 
delete the cat column--even if it is not being used as a key field. This raises 
an error.

No way to rename a column from cat to something else (or something else to cat) 
unless you've already connected it to a vector map even if cat is not the key 
field. So I can't create an integer column to link up my lost vector area with 
a record in my csv file.

This simple task is just not possible in GRASS AFAICT. Or if it is possible, it 
can only be done by such non-obvious and convoluted means that I've yet to find 
a method that works in spite of asking a large number of very skilled GRASS 
users.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 14, 2024, at 7:10 AM, Newcomb, Doug  wrote:

Have you tried a .csvt file for your .csv file? 
https://gdal.org/drivers/vector/csv.html<https://urldefense.com/v3/__https://gdal.org/drivers/vector/csv.html__;!!IKRxdwAv5BmarQ!dv7XjZX6-VnNpFbpXP6R1XYWkuaA4Y-gDR4RvL3bWazWUkLfURuKDMWqiBFqBS6jlNSHDKZCo02GJKjauaAJ-pCVIKD5JDc$>


From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Wednesday, March 13, 2024 7:02 PM
To: GRASS developers 
mailto:grass-dev@lists.osgeo.org>>; GRASS user list 
mailto:grass-u...@lists.osgeo.org>>
Subject: [EXTERNAL] [GRASS-dev] vector patching frustration




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


I am completely stymied in my attempt to do what should be a simple task. I 
have a map of vector areas, linked with an attribute table. I would like to 
patch in one more vector area, for which I have equivalent attribute 
information. I have tried this multiple ways and I cannot make this patch 
happen so that the added area has attribute info.

The closest I've come is to create and link a one line table to the new area 
that has exactly the same fields as the larger vector area map. The first map 
has 154 areas (i.e., cat=1-155). When I patch the maps and look at the 
resulting attribute table, I indeed see line and cat 155. But it is not linked 
with the patched area--which has been assigned a cat=183 for reasons I cannot 
fathom. The patch also renumbers my cat field to cat=2-155 from the original 
1-154.

This has been made more complicated by the fact that v.in.ogr imports all 
columns of a *.csv as text, regardless of what is in them and assigns cat 
numbers starting at 1. So I can't specify an integer key field of 155 to try 
the linking. Nor can I change the assigned cat of the single area I am trying 
to patch from 1 to 155 using v.category (or anything else I can find).

I'm hoping that someone has a clever solution that I've not seen or I'll just 
have to do this fairly simple and straightforward vector operation in QGIS.

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!dv7XjZX6-VnNpFbpXP6R1XYWkuaA4Y-gDR4RvL3bWazWUkLfURuKDMWqiBFqBS6jlNSHDKZCo02GJKjauaAJ-pCVvuAToIA$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdw

[GRASS-dev] vector patching frustration

[Michael Barton via grass-dev]

I am completely stymied in my attempt to do what should be a simple task. I 
have a map of vector areas, linked with an attribute table. I would like to 
patch in one more vector area, for which I have equivalent attribute 
information. I have tried this multiple ways and I cannot make this patch 
happen so that the added area has attribute info.

The closest I've come is to create and link a one line table to the new area 
that has exactly the same fields as the larger vector area map. The first map 
has 154 areas (i.e., cat=1-155). When I patch the maps and look at the 
resulting attribute table, I indeed see line and cat 155. But it is not linked 
with the patched area--which has been assigned a cat=183 for reasons I cannot 
fathom. The patch also renumbers my cat field to cat=2-155 from the original 
1-154.

This has been made more complicated by the fact that v.in.ogr imports all 
columns of a *.csv as text, regardless of what is in them and assigns cat 
numbers starting at 1. So I can't specify an integer key field of 155 to try 
the linking. Nor can I change the assigned cat of the single area I am trying 
to patch from 1 to 155 using v.category (or anything else I can find).

I'm hoping that someone has a clever solution that I've not seen or I'll just 
have to do this fairly simple and straightforward vector operation in QGIS.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

[Michael Barton via grass-dev]

+1
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 6, 2024, at 1:00 PM, grass-dev-requ...@lists.osgeo.org wrote:

Message: 1
Date: Wed, 6 Mar 2024 15:00:03 +0100
From: Markus Neteler mailto:nete...@osgeo.org>>
To: Anna Petr??ov? mailto:kratocha...@gmail.com>>
Cc: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
Subject: Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
Message-ID:
mailto:CALFmHhuuR3aCbX+GgnqVVMngv=syjdwu2pnpnosafqkhviy...@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Dear all,

On Thu, Feb 22, 2024 at 8:45?PM Anna Petr??ov? 
mailto:kratocha...@gmail.com>> wrote:
On Thu, Feb 22, 2024 at 12:33?PM Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
On Thu, Feb 22, 2024 at 3:59?PM Anna Petr??ov? 
mailto:kratocha...@gmail.com>> wrote:
On Tue, Feb 20, 2024 at 5:45?PM Markus Neteler via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
...
Hopefully no RC2 is needed.

Markus,

a bug in r.horizon came up on gitter recently:
https://urldefense.com/v3/__https://github.com/OSGeo/grass/pull/3441__;!!IKRxdwAv5BmarQ!Yb5NyZn10dooamOgSzkVVdpmg0RmvmcOfKJh0eP-UXvao4kAdIWKY722K5Xg5vMJQEKw62E66qKU8sza4pu5QJLKDQ6-GBuyld013w$

It would be nice to include it in 8.3.2 (with all the other fixes in r.horizon) 
but at the same time I don't want to
trigger RC2 because of this... The bug fix is a small change in r.horizon not 
impacting anything else, so
perhaps we wouldn't need RC2? What do you think?

For me that's okay as it is very isolated.
Feel free to backport it.


Done!

I'd now move on and publish GRASS GIS 8.3.2 unless there are objections.

Markus

--
Markus Neteler, PhD
https://urldefense.com/v3/__https://www.mundialis.de__;!!IKRxdwAv5BmarQ!Yb5NyZn10dooamOgSzkVVdpmg0RmvmcOfKJh0eP-UXvao4kAdIWKY722K5Xg5vMJQEKw62E66qKU8sza4pu5QJLKDQ6-GBsN0fsMTg$
  - company
https://urldefense.com/v3/__https://grass.osgeo.org__;!!IKRxdwAv5BmarQ!Yb5NyZn10dooamOgSzkVVdpmg0RmvmcOfKJh0eP-UXvao4kAdIWKY722K5Xg5vMJQEKw62E66qKU8sza4pu5QJLKDQ6-GBtBcVXDew$
  - FOSS
https://urldefense.com/v3/__https://neteler.org__;!!IKRxdwAv5BmarQ!Yb5NyZn10dooamOgSzkVVdpmg0RmvmcOfKJh0eP-UXvao4kAdIWKY722K5Xg5vMJQEKw62E66qKU8sza4pu5QJLKDQ6-GBt9qK1QWQ$
  - freelancing & blog


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

Re: [GRASS-dev] [GRASS-user] [EXTERNAL] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

 compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , 
https://youtu.be/0NHdWSF96o0<https://urldefense.com/v3/__https://youtu.be/0NHdWSF96o0__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmh8d9eLE$>
 .  The 2021 is the same.  The .img /ige file is 26 GB for 1 year nationwide. 
Converting to deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug


From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan mailto:brendan.har...@gmail.com>>
Cc: GRASS users 
mailto:grass-u...@lists.osgeo.org>>; evillasenor713 
mailto:evillasenor...@gmail.com>>; GRASS developers 
list mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Thanks!
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmYULrX7M$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmuzKOqRQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan 
mailto:brendan.har...@gmail.com>> wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7ExxQeoo$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7qCnxTyY$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:08 PM, Brendan 
mailto:brendan.har...@gmail.com>> wrote:

Hi Michael, I've attached an NLCD legend in csv format and text files with 
categories and color table for GRASS in case it helps.

On Fri, Mar 1, 2024 at 4:34 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Ana,

I was able to do that. I'm trying to look at the NLCD. While it opens fine and 
is classified, there are no text labels for the landcover categories. Would 
these be hiding in the *.ige file?

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYczH51sZMg$>)
Director, Network for Co

Re: [GRASS-dev] [EXTERNAL] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

Ah!! So that is what the *.ige file is for.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 4, 2024, at 10:57 AM, Newcomb, Doug  wrote:

No,
The .ige file is what spills over after the 4GB of the .img file fills up.  You 
need to have both.


From: Michael Barton 
Sent: Monday, March 4, 2024 12:12 PM
To: Newcomb, Doug 
Cc: Brendan ; GRASS users 
; evillasenor713 ; GRASS 
developers list 
Subject: Re: [EXTERNAL] [GRASS-dev] Can GRASS import a *.ige file?

The info I downloaded for 2021 had a much more modes sized *.img file and a 
huge *.ige file (25 Gb or so). It looks like the best approach is to use the 
*.img file and discard the *.ige file. Perhaps that latter is the uncompressed 
one.

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!cbaw5GkV3_dbrW6HsMxMGAWs2z5GvJeuC590WttGJejzDPNm_zQ_jt6_z-uJrpiLnPlzyZ205TaoaSnnpI3bVQ6zwbAKdLM$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!cbaw5GkV3_dbrW6HsMxMGAWs2z5GvJeuC590WttGJejzDPNm_zQ_jt6_z-uJrpiLnPlzyZ205TaoaSnnpI3bVQ6zAV3ir9U$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 4, 2024, at 7:56 AM, Newcomb, Doug  wrote:

Michael,
The last time I checked, the NLCD data in .img format is an uncompressed 
raster.  You can save a massive amount of hard drive space by converting the 
.img files to deflate compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , 
https://youtu.be/0NHdWSF96o0<https://urldefense.com/v3/__https://youtu.be/0NHdWSF96o0__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmh8d9eLE$>
 .  The 2021 is the same.  The .img /ige file is 26 GB for 1 year nationwide. 
Converting to deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug


From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan mailto:brendan.har...@gmail.com>>
Cc: GRASS users 
mailto:grass-u...@lists.osgeo.org>>; evillasenor713 
mailto:evillasenor...@gmail.com>>; GRASS developers 
list mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Thanks!
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmYULrX7M$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmuzKOqRQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=nc

Re: [GRASS-dev] [EXTERNAL] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

The info I downloaded for 2021 had a much more modes sized *.img file and a 
huge *.ige file (25 Gb or so). It looks like the best approach is to use the 
*.img file and discard the *.ige file. Perhaps that latter is the uncompressed 
one.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 4, 2024, at 7:56 AM, Newcomb, Doug  wrote:

Michael,
The last time I checked, the NLCD data in .img format is an uncompressed 
raster.  You can save a massive amount of hard drive space by converting the 
.img files to deflate compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , 
https://youtu.be/0NHdWSF96o0<https://urldefense.com/v3/__https://youtu.be/0NHdWSF96o0__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmh8d9eLE$>
 .  The 2021 is the same.  The .img /ige file is 26 GB for 1 year nationwide. 
Converting to deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug

From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan mailto:brendan.har...@gmail.com>>
Cc: GRASS users 
mailto:grass-u...@lists.osgeo.org>>; evillasenor713 
mailto:evillasenor...@gmail.com>>; GRASS developers 
list mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Thanks!
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmYULrX7M$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmuzKOqRQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7ExxQeoo$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7qCnxTyY$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:08 PM, Brendan 
mailto:brendan.har...@gmail.com>> wrote:

Hi Michael, I've attached an NLCD legend in csv format and text files w

Re: [GRASS-dev] r.copy doesn't respect computational region??

[Michael Barton via grass-dev]

I was mainly just surprised as I thought I remembered (incorrectly it seems) 
that all raster commands that create new maps respect the computational region. 

Michael Barton
School of Human Evolution  Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Mar 3, 2024, at 4:05 PM, Markus Neteler  wrote:
> 
> On Sun, Mar 3, 2024 at 2:48 AM Vaclav Petras via grass-dev
>  wrote:
>>>> On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
>>>>  wrote:
>>>>> It's been awhile since I've done this but I thought I remembered that a 
>>>>> new map created with r.copy is constrained by the computational region.
>>>>> That does not seem to the case, at least in 8.4 dev. Maybe it has been 
>>>>> this way for awhile (long while?) and I didn't notice it.
>>> 
>>> I think, but I'm not 100% sure, that has always been the case.
>> 
>> Here is g.copy documentation from v6.4 it does not mention anything about 
>> region. It seems to go back to US Army CERL.
>> 
>> https://urldefense.com/v3/__https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html*L6__;Iw!!IKRxdwAv5BmarQ!Y6OmEvsONiL6z0N7vRJlQqVXljNtzIOk8D1PWEriQg2IARIxPIAf1QzY53D3FI_FTS25VthLEr8Wg6Qn7TZhlg$
> 
> Here is also the GRASS GIS 4.0 manual page (:
> https://urldefense.com/v3/__https://github.com/OSGeo/grass-legacy/blob/releasebranch_4_0/man/man1/g.copy__;!!IKRxdwAv5BmarQ!Y6OmEvsONiL6z0N7vRJlQqVXljNtzIOk8D1PWEriQg2IARIxPIAf1QzY53D3FI_FTS25VthLEr8Wg6TQstBnZg$
> 
> To easily read it, click the "Raw" button, save to disk as
> "g.copy.man", then render the man page with:
> 
> man ./g.copy.man
> 
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

[Michael Barton via grass-dev]

Thanks. I’ll check it out
__
Michael Barton

Sent from  my iPhone
Please excusr any typoz

On Mar 2, 2024, at 6:48 PM, Vaclav Petras  wrote:




On Sat, 2 Mar 2024 at 07:04, Paulo van Breugel via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:


On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
>It's been awhile since I've done this but I thought I remembered that a new 
>map created with r.copy is constrained by the computational region. That does 
>not seem to the case, at least in 8.4 dev. Maybe it has been this way for 
>awhile (long while?) and I didn't notice it.


g.copy is a general tool which creates a copy of the data. Perhaps you are 
interested in r.clip which is a raster tool and is driven by the computational 
region as expected. r.clip clips according to the current computation region 
(preserves original raster alignment  by default).

https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html<https://urldefense.com/v3/__https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html__;!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB0FyiU3Aw$>


I think, but I'm not 100% sure, that has always been the case.

Here is g.copy documentation from v6.4 it does not mention anything about 
region. It seems to go back to US Army CERL.

https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6<https://urldefense.com/v3/__https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html*L6__;Iw!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB0EwccY8A$>

In any case, it seems to be the logical behavior, otherwise it wouldn't be a 
true copy?

Are the different expectations coming from differences between raster tools and 
general tools? With r.copy (as opposed to g.copy), you could perhaps argue for 
respecting the computational region, but I think the "true copy" expectation 
would still be strong.

Vaclav



>
>Michael
>_
>
>C. Michael Barton
>Associate Director, School of Complex Adaptive Systems 
>(https://scas.asu.edu<https://scas.asu.edu/>)
>Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
>Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
>Arizona State University
>Tempe, AZ 85287-2701
>USA
>
>Executive Director, Open Modeling Foundation 
>(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io__;!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB2bt1bIhg$><https://openmodelingfoundation.github.io/<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB0JD-cSLQ$>>)
>Director, Network for Computational Modeling in Social & Ecological Sciences 
>(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB0xLCQgig$>)
>
>personal website: http://www.public.asu.edu/~cmbarton
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev<https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/grass-dev__;!!IKRxdwAv5BmarQ!bX6BJARtmhekJ3SG9PaerPBuEiEiQkRVfYrnDVdOljsw5vo69FcPmMNw7rpgTjuONRDgrZBYDLMSvZddoB1u5GUh6g$>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

Thanks!
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7ExxQeoo$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7qCnxTyY$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:08 PM, Brendan 
mailto:brendan.har...@gmail.com>> wrote:

Hi Michael, I've attached an NLCD legend in csv format and text files with 
categories and color table for GRASS in case it helps.

On Fri, Mar 1, 2024 at 4:34 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Ana,

I was able to do that. I'm trying to look at the NLCD. While it opens fine and 
is classified, there are no text labels for the landcover categories. Would 
these be hiding in the *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYczH51sZMg$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYcz1dBigD8$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 3:01 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
It doesn't look like r.in.gdal does this. Is there an extension or other way to 
import an ERDAS *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fuerQQvh1Q$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__

[GRASS-dev] r.copy doesn't respect computational region??

[Michael Barton via grass-dev]

It's been awhile since I've done this but I thought I remembered that a new map 
created with r.copy is constrained by the computational region. That does not 
seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile 
(long while?) and I didn't notice it.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:08 PM, Brendan  wrote:

Hi Michael, I've attached an NLCD legend in csv format and text files with 
categories and color table for GRASS in case it helps.

On Fri, Mar 1, 2024 at 4:34 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Ana,

I was able to do that. I'm trying to look at the NLCD. While it opens fine and 
is classified, there are no text labels for the landcover categories. Would 
these be hiding in the *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYczH51sZMg$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYcz1dBigD8$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 3:01 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
It doesn't look like r.in.gdal does this. Is there an extension or other way to 
import an ERDAS *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fuerQQvh1Q$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fueXhgcoaQ$>)

personal website: http://www.public.asu.edu/~cmbarton


___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev<https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/grass-dev__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fuepg1HNbo$>

___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev<https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/grass-dev__;!!IKRxdwAv5BmarQ!bVxBv8fT07vVYMHReffcj46QeSJAOyIOA16eJ_3q6fBQ7vAnFxJLli7AZ-NGLJXL2OxJ3h3sxzkspsmF4eq_UYcz28NVTcw$>


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

Re: [GRASS-dev] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

Thanks Ana,

I was able to do that. I'm trying to look at the NLCD. While it opens fine and 
is classified, there are no text labels for the landcover categories. Would 
these be hiding in the *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 3:01 PM, Anna Petrášová  wrote:

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
It doesn't look like r.in.gdal does this. Is there an extension or other way to 
import an ERDAS *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fuerQQvh1Q$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fueXhgcoaQ$>)

personal website: http://www.public.asu.edu/~cmbarton


___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev<https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/grass-dev__;!!IKRxdwAv5BmarQ!fudlB0xFlO51zk0b4JnSIyVxMZfbrnjh5DDgX_3YvhtKbUyVC6kMDWh-tA0uov3VLJvJy1abd878bkRl5fuepg1HNbo$>

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

[GRASS-dev] Can GRASS import a *.ige file?

[Michael Barton via grass-dev]

It doesn't look like r.in.gdal does this. Is there an extension or other way to 
import an ERDAS *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

[Michael Barton via grass-dev]

Just want let all know that I’ve posted new Mac binaries of GRASS 8.3.2RC1 at 
the GRASS for Mac site.

https://cmbarton.github.io/grass-mac/download/

Michael

Michael Barton
School of Human Evolution  Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University

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

Re: [GRASS-dev] [GRASS-user] cost surface with negative friction odd behavior

[Michael Barton via grass-dev]

Done
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Nov 30, 2023, at 11:29 AM, Anna Petrášová  wrote:

Michael, could you please create a PR for the documentation?

On Wed, Nov 29, 2023 at 3:56 PM Michael Barton via grass-user 
mailto:grass-u...@lists.osgeo.org>> wrote:
Thanks Anna and Doug,

I did not expect it to work (thought it would be useful if it did). Rather I 
was surprised by the fact that r.walk DID run and that it gave very odd results.

Adding to the docs is a good idea. Even better would also to have a friction 
map with a negative value (min<0) raise an error in r.walk, saying that all 
values in a friction map must be ≥ 0

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Nov 29, 2023, at 1:00 PM, 
grass-user-requ...@lists.osgeo.org 
wrote:

Date: Wed, 29 Nov 2023 10:17:19 -0500
From: Anna Petr??ov? mailto:kratocha...@gmail.com>>
To: Michael Barton mailto:michael.bar...@asu.edu>>
Cc: GRASS developers 
mailto:grass-dev@lists.osgeo.org>>, GRASS user list
mailto:grass-u...@lists.osgeo.org>>
Subject: Re: [GRASS-user] cost surface with negative friction odd
behavior
Message-ID:
mailto:cae0edeofhx75u2r6qc8ek5p8czg2cd1iwr8j3vx8qiwwe8z...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

I think r.walk was not written for negative friction and while I imagine
some small (in absolute sense) negative values may work, your negative
values are pretty extreme, meaning the resulting travel time through a cell
would be negative. That can cause all kinds of issues in the algorithm. So
I would say friction should not be negative. I am not sure I would check
that in the code, because you would need to check that for each cell and I
think it's unnecessary overhead. Maybe just adding a note to documentation
may be enough. I haven't looked into the code itself, so this is just my
guess.

Anna

On Tue, Nov 28, 2023 at 5:48?PM Michael Barton via grass-user <
grass-u...@lists.osgeo.org> wrote:

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

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

Re: [GRASS-dev] cost surface with negative friction odd behavior

[Michael Barton via grass-dev]

Thanks Anna and Doug,

I did not expect it to work (thought it would be useful if it did). Rather I 
was surprised by the fact that r.walk DID run and that it gave very odd results.

Adding to the docs is a good idea. Even better would also to have a friction 
map with a negative value (min<0) raise an error in r.walk, saying that all 
values in a friction map must be ≥ 0

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Nov 29, 2023, at 1:00 PM, grass-user-requ...@lists.osgeo.org wrote:

Date: Wed, 29 Nov 2023 10:17:19 -0500
From: Anna Petr??ov? mailto:kratocha...@gmail.com>>
To: Michael Barton mailto:michael.bar...@asu.edu>>
Cc: GRASS developers 
mailto:grass-dev@lists.osgeo.org>>, GRASS user list
mailto:grass-u...@lists.osgeo.org>>
Subject: Re: [GRASS-user] cost surface with negative friction odd
behavior
Message-ID:
mailto:cae0edeofhx75u2r6qc8ek5p8czg2cd1iwr8j3vx8qiwwe8z...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

I think r.walk was not written for negative friction and while I imagine
some small (in absolute sense) negative values may work, your negative
values are pretty extreme, meaning the resulting travel time through a cell
would be negative. That can cause all kinds of issues in the algorithm. So
I would say friction should not be negative. I am not sure I would check
that in the code, because you would need to check that for each cell and I
think it's unnecessary overhead. Maybe just adding a note to documentation
may be enough. I haven't looked into the code itself, so this is just my
guess.

Anna

On Tue, Nov 28, 2023 at 5:48?PM Michael Barton via grass-user <
grass-u...@lists.osgeo.org> wrote:

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

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Michael Barton via grass-dev]

Most of these don't affect the Mac and there are more pressing issues for 
coloring vectors than the #3196 and #3206 IMHO (e.g., see #3126-3128). So OK 
with me to release 8.3.1 to fix a couple of really major issues and bump the 
others to 8.3.2.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Oct 22, 2023, at 12:00 PM, grass-dev-requ...@lists.osgeo.org wrote:

Date: Sun, 22 Oct 2023 14:27:57 +0200
From: Markus Neteler mailto:nete...@osgeo.org>>
To: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
Subject: Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
Message-ID:
mailto:CALFmHhtv5areiqHhRvkaXg=8k86deogijw5cphvywekeuhm...@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Hi devs,

Still 6 items to go or bump to the 8.3.2 milestone:
https://urldefense.com/v3/__https://github.com/OSGeo/grass/issues?q=is*3Aopen*label*3A*22backport*to*8.3*22*milestone*3A8.3.1__;JSslJSsrJSsl!!IKRxdwAv5BmarQ!ZZlVQcxd8ELL0evmQ9tvYVnHAgAIg7IoynvKPdv_C1dGVz7uyh27k26_rVs7VTUeFS-LTB6FNssO3RQceRO23rxbMXIFrKCRl20$

Given the urgency of 8.3.1 final I suggest to merge what's possible
and bump the rest.
Or, rather bump all and release 8.3.1 final.

Markus

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

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Michael Barton via grass-dev]

+1 from me

I’m traveling and probably won’t be able to compile until next week

Michael Barton
School of Human Evolution  Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Sep 28, 2023, at 12:00 PM, grass-dev-requ...@lists.osgeo.org wrote:
> 
> Subject: Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi devs,
> 
> May we schedule RC1 by end of the week?
> 
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Michael Barton via grass-dev]

The university won’t let me lag that long. But I never upgrade when a major 
version just comes out. 

Most people will want Rosetta for a little while at least. That will change 
with time of course  But I’m concerned that there might be compiling problems. 

Michael Barton
School of Human Evolution  Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Sep 25, 2023, at 5:44 AM, Nicklas Larsson  wrote:
> 
> I think that would be wise.
> 
> Personally I am very careful to update OS in general, just jumped to 13 from 
> 12 the other day. Lagging about one year.
> 
> 
>> On 25 Sep 2023, at 14:38, Michael Barton  wrote:
>> 
>> Does this mean I should hole off upgrading to Sonoma for a bit?
>> 
>> Michael Barton
>> School of Human Evolution  Change
>> School of Complex Adaptive System Science
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> ...Sent from my iPad
>> 
 On Sep 25, 2023, at 4:12 AM, Nicklas Larsson  wrote:
>>> 
>>> 
 On 25 Sep 2023, at 12:30, Gregor Hintner  wrote:
 
 Niklas, 
 
 
 thank you on the committed exploration of this issue, also independently 
 verifying my own findings. 
 
>>> 
>>> I’m afraid this is a problem that will be a major issue in the time to 
>>> come, that we will have to deal with. Thank you for reporting!
>>> 
>>> 
 From a layperson perspective it does seem reasonable to me that macOS 
 wanted apps to initialize through a conventionally made and signed binary, 
 and would appreciate if your team would consider that. I hope Apple would 
 offer free signing certificates, or even developer program memberships for 
 open source projects. 
 
>>> 
>>> It will be difficult to make a “conventionally made” Mac application of 
>>> GRASS, but a "fully working as expected" and signed one is possible. We are 
>>> fully aware that the present solution isn’t optimal, but it has worked. So 
>>> far. Now, apparently we will have to invest the time and sweat for making 
>>> it right.
>>> 
>>> 
 By chance, did you check whether FreeCAD, the second app I encountered 
 with an ARM release that caused the Rosetta dialog, has the same problem? 
 
>>> 
>>> Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal 
>>> does work as well, so there is the same problem behind I guess. FreeCAD is 
>>> however code signed (so that’s not issue causing the Rosetta problem).
>>> 
>>> 
>>> Nicklas
>>> 
>>> 
>>> 
 Their team never replied to my inquiry on X, but perhaps we could help get 
 them started to fix this too. 
 
 
 Cheers, 
 Gregor
 
 
>> On 2023-09-25, at 11:59 AM, Nicklas Larsson  wrote:
> 
> Gregor,
> 
> I now had the opportunity to test on macOS 14 RC and I can confirm this 
> issue. The problem seems related somehow to being initialised by a script.
> 
> I __did___ manage to start GRASS via Terminal:
> 
> 
> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
> 
> 2. System will complain…
> 
> 3. Go to 'System Settings > Privacy & Security > Security'
> 
> 4. In the settings I enabled GRASS to be allowed
> 
> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will 
> work
> 
> 
> This is only a workaround, I will look into how this can be solved 
> properly. Maybe we have to make a binary that does the job the script now 
> does (that used to be the case some time ago). We should also invest some 
> time in creating a code signed app as well.
> 
> 
> Nicklas
> 
> 
> 
>> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev 
>>  wrote:
>> 
>> Gregor, thanks very much for the info! At least it ruled some things 
>> out, but I have still no idea what is causing this and it’s very 
>> difficult do the needed poking around without a similar setup (macOS 14 
>> without Rosetta installed). I’ll have to ponder on this, if this really 
>> is caused by some change by macOS 14, a solution must be found sooner 
>> rather than later.
>> 
>> An alternative way to install GRASS with native architecture for ARM is 
>> with MacPorts [1]. It does, however, involve some Terminal-batics! If 
>> you are in need for other GIS software like QGIS in particular, MacPorts 
>> is currently, in my experience, a most solid solution with available 
>> GRASS plugin (as there is no native official QGIS.app bundle for ARM).
>> 
>> To be continued…
>> 
>> Cheers,
>> Nicklas
>> 
>> [1] 
>> https://urldefense.com/v3/__https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts__;!!IKRxdwAv5BmarQ!dgVkpS9cztwvGGv-hsTRc5Vc0o6QJ28v5wxcBt3iZpXBnC-G0_E1qUasCdMvWceVKSW2z3TMfHwuQ7CtEnL2MQ$
>>  
>> 
>> 
 On 20 Sep 2023, at 16:47, 

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Michael Barton via grass-dev]

Does this mean I should hole off upgrading to Sonoma for a bit?

Michael Barton
School of Human Evolution  Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

> On Sep 25, 2023, at 4:12 AM, Nicklas Larsson  wrote:
> 
> 
>> On 25 Sep 2023, at 12:30, Gregor Hintner  wrote:
>> 
>> Niklas, 
>> 
>> 
>> thank you on the committed exploration of this issue, also independently 
>> verifying my own findings. 
>> 
> 
> I’m afraid this is a problem that will be a major issue in the time to come, 
> that we will have to deal with. Thank you for reporting!
> 
> 
>> From a layperson perspective it does seem reasonable to me that macOS wanted 
>> apps to initialize through a conventionally made and signed binary, and 
>> would appreciate if your team would consider that. I hope Apple would offer 
>> free signing certificates, or even developer program memberships for open 
>> source projects. 
>> 
> 
> It will be difficult to make a “conventionally made” Mac application of 
> GRASS, but a "fully working as expected" and signed one is possible. We are 
> fully aware that the present solution isn’t optimal, but it has worked. So 
> far. Now, apparently we will have to invest the time and sweat for making it 
> right.
> 
> 
>> By chance, did you check whether FreeCAD, the second app I encountered with 
>> an ARM release that caused the Rosetta dialog, has the same problem? 
>> 
> 
> Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal does 
> work as well, so there is the same problem behind I guess. FreeCAD is however 
> code signed (so that’s not issue causing the Rosetta problem).
> 
> 
> Nicklas
> 
> 
> 
>> Their team never replied to my inquiry on X, but perhaps we could help get 
>> them started to fix this too. 
>> 
>> 
>> Cheers, 
>> Gregor
>> 
>> 
 On 2023-09-25, at 11:59 AM, Nicklas Larsson  wrote:
>>> 
>>> Gregor,
>>> 
>>> I now had the opportunity to test on macOS 14 RC and I can confirm this 
>>> issue. The problem seems related somehow to being initialised by a script.
>>> 
>>> I __did___ manage to start GRASS via Terminal:
>>> 
>>> 
>>> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>>> 
>>> 2. System will complain…
>>> 
>>> 3. Go to 'System Settings > Privacy & Security > Security'
>>> 
>>> 4. In the settings I enabled GRASS to be allowed
>>> 
>>> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will 
>>> work
>>> 
>>> 
>>> This is only a workaround, I will look into how this can be solved 
>>> properly. Maybe we have to make a binary that does the job the script now 
>>> does (that used to be the case some time ago). We should also invest some 
>>> time in creating a code signed app as well.
>>> 
>>> 
>>> Nicklas
>>> 
>>> 
>>> 
 On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev 
  wrote:
 
 Gregor, thanks very much for the info! At least it ruled some things out, 
 but I have still no idea what is causing this and it’s very difficult do 
 the needed poking around without a similar setup (macOS 14 without Rosetta 
 installed). I’ll have to ponder on this, if this really is caused by some 
 change by macOS 14, a solution must be found sooner rather than later.
 
 An alternative way to install GRASS with native architecture for ARM is 
 with MacPorts [1]. It does, however, involve some Terminal-batics! If you 
 are in need for other GIS software like QGIS in particular, MacPorts is 
 currently, in my experience, a most solid solution with available GRASS 
 plugin (as there is no native official QGIS.app bundle for ARM).
 
 To be continued…
 
 Cheers,
 Nicklas
 
 [1] 
 https://urldefense.com/v3/__https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts__;!!IKRxdwAv5BmarQ!dgVkpS9cztwvGGv-hsTRc5Vc0o6QJ28v5wxcBt3iZpXBnC-G0_E1qUasCdMvWceVKSW2z3TMfHwuQ7CtEnL2MQ$
  
 
 
>> On 20 Sep 2023, at 16:47, Gregor Hintner  
>> wrote:
> 
> Niklas,
> 
> 
> please find my answers below:
> 
>> `file /usr/bin/osascript`
> 
> evidently still a universal binary, see this screenshot
> 
> 
>> `osascript -i`
> 
> worked with no noticeable issues
> 
>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh
> 
> produced the unverified developer warning as expected. Logically I could 
> and should probably override this, but with 10 years since my last time 
> coding, and having never learned the basics of UNIX, I would prefer to 
> follow the strictest Apple security guidelines, or sometimes perhaps 
> theater, when possible.
> 
> 
>> `sw_vers -productVersion`
> 14.0
> 
> 
>> file /usr/bin/sw_vers
> universal binary
> 
> 
> 
> Hope this helps,
> Gregor
> 
> 
>> On 2023-09-20, at 9:52 AM, Nicklas Larsson  wrote:
>> 
>> 

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Michael Barton via grass-dev]

Edouard,

I have compiled this using ARM and am running it on an ARM M2 Mac with no 
problem. It is unsigned. This issue of requiring Rosetta is only showing up in 
the Sonoma beta so far.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


Today's Topics:

  1. Re: GRASS GIS for Apple Silicon Macs (Edouard Choini?re)


--

Message: 1
Date: Fri, 22 Sep 2023 18:33:29 +
From: Edouard Choini?re 
To: Michael Barton 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Message-ID:


Content-Type: text/plain; charset="utf-8"

Well, it?s not new, it?s been like that since 2020 with Big Sur and the 
introduction of M1 (before that M1 isn?t supported).  Big Sur (version 11), was 
followed by Monterey (version 12), then Ventura (version 13), then Sonoma 
(version 14), which is the beta you?re talking about and the expected General 
availability is on September 26, 2023, in a couple of days.

Even homebrew had problems at that time, so we?re not alone.


Edouard Choini?re

Le 22 sept. 2023 ? 14:23, Michael Barton via grass-dev 
 a ?crit :

? This would be a major change by Apple and a royal PITA. I hope it is only 
something in the current beta and not in the final release (which I have not 
yet installed).

We can probably sign through OSGEO. But when I looked into signing, it seems 
difficult unless you use Apple XCode. That would be a big step back from the 
current ease of compiling Mac binaries with Conda. When I looked into it 
several years ago, I could not find any clear instructions about how to sign 
code without XCode, although it may be possible.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://urldefense.com/v3/__https://openmodelingfoundation.github.io__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDicV79WYqU$
 
<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDic47FvxW0$
 >)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDicVwKRqQM$
 )

personal website: http://www.public.asu.edu/~cmbarton


On Sep 22, 2023, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote:

Date: Fri, 22 Sep 2023 17:33:54 +
From: Edouard Choini?re mailto:e@outlook.com>>
To: Nicklas Larsson mailto:n_lars...@yahoo.com>>
Cc: GRASS developers 
mailto:grass-dev@lists.osgeo.org>>
Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Message-ID:
mailto:sa1pr12mb73447ec8cde24093c1f2bd14ef...@sa1pr12mb7344.namprd12.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

I think I figured out an explanation. I tried to read about CI for macOS, then 
on why there aren?t a lot of CI for macOS (especially Apple Silicon). I also 
couldn?t look into the build infrastructure used for your grass macOS builds 
since they don?t seem to be available on GitHub. Is it local only?

Ok, so now to a possible explanation on why Rosetta 2 is asked to be installed.
It seems that with Apple Silicon, arm64 code needs to be signed (which is new), 
while x86_64 doesn?t, like before. I think it was mentioned in the thread that 
the app might be unsigned. So I suspect that even if a universal binary 
contains arm64 and x86_64 binaries, if it is unable to use the arm64 binary, it 
will try using the intel ones.


<https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$>
[Apple-Silicon-Rosetta-2-and-the-Challenges-for-Endpoint-Securi

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Michael Barton via grass-dev]

This would be a major change by Apple and a royal PITA. I hope it is only 
something in the current beta and not in the final release (which I have not 
yet installed).

We can probably sign through OSGEO. But when I looked into signing, it seems 
difficult unless you use Apple XCode. That would be a big step back from the 
current ease of compiling Mac binaries with Conda. When I looked into it 
several years ago, I could not find any clear instructions about how to sign 
code without XCode, although it may be possible.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Sep 22, 2023, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote:

Date: Fri, 22 Sep 2023 17:33:54 +
From: Edouard Choini?re mailto:e@outlook.com>>
To: Nicklas Larsson mailto:n_lars...@yahoo.com>>
Cc: GRASS developers 
mailto:grass-dev@lists.osgeo.org>>
Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Message-ID:
mailto:sa1pr12mb73447ec8cde24093c1f2bd14ef...@sa1pr12mb7344.namprd12.prod.outlook.com>>

Content-Type: text/plain; charset="utf-8"

I think I figured out an explanation. I tried to read about CI for macOS, then 
on why there aren?t a lot of CI for macOS (especially Apple Silicon). I also 
couldn?t look into the build infrastructure used for your grass macOS builds 
since they don?t seem to be available on GitHub. Is it local only?

Ok, so now to a possible explanation on why Rosetta 2 is asked to be installed.
It seems that with Apple Silicon, arm64 code needs to be signed (which is new), 
while x86_64 doesn?t, like before. I think it was mentioned in the thread that 
the app might be unsigned. So I suspect that even if a universal binary 
contains arm64 and x86_64 binaries, if it is unable to use the arm64 binary, it 
will try using the intel ones.



[Apple-Silicon-Rosetta-2-and-the-Challenges-for-Endpoint-Security-7.jpg]
Why Your macOS EDR Solution Shouldn't Be Running Under Rosetta 
2
sentinelone.com

In particular, see the part where it says:


That?s because one of the changes Apple brought in with Big 
Sur that only applies to Apple silicon Macs is that native arm64 code cannot 
execute on an M1 Mac unless it has a valid code signature.

An Apple silicon Mac doesn?t permit native arm64 code execution under any 
conditions unless a valid signature is attached. Translated x86_64 code, 
however, is not subject to this 
restriction: translated x86_64 code is permitted to execute through Rosetta with no 
signature information at all.



There?s also that thread that was linked to from my reading some Reddit threads 
(like