[GRASS-user] large shapefile not importing properly with v.import

GRASS GRASS user
,
1

Hi GRASS List,

I have what I think is a large shapefile. It is 122 MB (30 MB dbf file and 90 MB shp file). v.import also reports:

47957 primitives registered
3761520 vertices registered

and then, much later

Number of nodes: 33786
Number of primitives: 51112
Number of points: 0
Number of lines: 0
Number of boundaries: 37935
Number of centroids: 13177
Number of areas: 31681
Number of isles: 27720
WARNING: Number of incorrect boundaries: 1586
WARNING: Number of centroids outside area: 186
WARNING: Number of duplicate centroids: 631

When I open it in QGIS it takes ~1 second and everything looks good. If I reproject it on-the-fly, it still looks good.

I'm working in EPSG:3413 and gdalsrsinfo reports "PROJ.4 : '+proj=longlat +datum=WGS84 +no_defs '" for this shapefile. When I v.import it in GRASS, it takes ~2 hours, and there are many boundaries that appear incorrect. If I set "snap=-1" it only takes a few minutes, but there are more errors.

Can anyone offer advice how do work with this shapefile in GRASS? Is this likely an error in the shapefile, or a limitation to v.import? Should I import it into its native projection and then v.proj after import?

Thanks,

  -k.

2

I have what I think is a large shapefile. It is 122 MB (30 MB dbf file and

90 MB shp file).

not that large; a few weeks ago I've imported a ~1 GB shapefile; it took
some time to import because of topological building, but it worked.

WARNING: Number of incorrect boundaries: 1586
WARNING: Number of centroids outside area: 186
WARNING: Number of duplicate centroids: 631

it seems there may be some issues e.g. overlapping polygons,
self-intersections of boundaries, very small areas etc.

try to use v.in.ogr instead in a location with the original projection and
then reproject it.

sometimes I get data sets with such warnings; first I open such data in
QGIS; in master aka QGIS 3, there is a nice new topology checker to inspect
about topological errors. after some cleaning in QGIS, I try to import the
data by v.in.ogr without cleaning and afterwards clean the vector data by
v.clean e.g. remove small areas, etc

HTH

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

3

On Fri, Oct 20, 2017 at 8:22 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

I have what I think is a large shapefile. It is 122 MB (30 MB dbf file and
90 MB shp file).

not that large; a few weeks ago I’ve imported a ~1 GB shapefile; it took
some time to import because of topological building, but it worked.

WARNING: Number of incorrect boundaries: 1586
WARNING: Number of centroids outside area: 186
WARNING: Number of duplicate centroids: 631

it seems there may be some issues e.g. overlapping polygons,
self-intersections of boundaries, very small areas etc.

try to use v.in.ogr instead in a location with the original projection and
then reproject it.

sometimes I get data sets with such warnings; first I open such data in
QGIS; in master aka QGIS 3, there is a nice new topology checker to inspect
about topological errors. after some cleaning in QGIS, I try to import the
data by v.in.ogr without cleaning and afterwards clean the vector data by
v.clean e.g. remove small areas, etc

The cleaning part of v.in.ogr should be renamed to “converting non-topological polygons to topological areas areas”. The real cleaning happens only if the snap option is set to > 0. v.in.ogr should provide a topologically correct vector map. Overlapping areas are ok if the input polygons are really supposed to overlap.

Can you provide examples where v.in.ogr with cleaning/polygon conversion did not work, but v.in.ogr -c + v.clean produced better results? This would help to improve v.in.ogr, which should be able to produce a reasonable output, maybe with some parameter tuning.

I noticed that v.in.ogr complains about overlapping areas, which were input polygons that should not overlap, but snapping did not help there, instead I needed to remove small areas afterwards with v.clean. Should the current min_area option of v.in.ogr also be used to remove small areas in the output?

Markus M

HTH

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

4

Can you provide examples where v.in.ogr with cleaning/polygon conversion did

not work, but v.in.ogr -c + >v.clean produced better results?

really good data sets with all kind of (topological) mess are (from [correct
and incorrect] overlapping to self intersections etc):

o Natura 2000 data (~ 1GB):

https://www.eea.europa.eu/data-and-maps/data/natura-8#tab-gis-data

o World database of protected areas (~ 1 GB):

https://www.protectedplanet.net/

The real cleaning happens only if the snap option is set to > 0.

v.in.ogr gives some hints about the snap option, sometimes I don't know what
should be the optimal setting.

noticed that v.in.ogr complains about overlapping areas, which were input

polygons that should not >overlap, but snapping did not help there, instead
I needed to remove small areas afterwards with v.clean.

same experiences here.

Should the current min_area option of v.in.ogr also be used to remove small

areas in the output?

never used this option:

min_area=float
    Minimum size of area to be imported (square meters)
    Smaller areas and islands are ignored. Should be greater than snap^2
    Default: 0.0001

do you mean the small areas shouldn't be imported or small areas should be
added to the neighbor area with the longest adjacent boundaries?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

5

On 2017-10-20 at 18:22, Helmut Kudrnovsky <hellik@web.de> wrote:

try to use v.in.ogr instead in a location with the original projection
and then reproject it.

If I import into its native projection with ~v.in.ogr~ it displays fine. If I then reproject with ~v.proj~, data is once again dropped.

~v.in.ogr~ complained about overlaps, which I don't think should exist, even if they are valid in theory. I am currently re-importing with ~snap=1E-13~ as suggested by ~v.in.ogr~, but that is taking a few hours. Anyway, it seems likely the reprojection won't work in this case either.

I find it strange that QGIS handles this both instantly and correctly (at least correctly based on a cursory visual examination).

  -k.

6

Ken Mankoff wrote

On 2017-10-20 at 18:22, Helmut Kudrnovsky &lt;

hellik@

&gt; wrote:

try to use v.in.ogr instead in a location with the original projection
and then reproject it.

If I import into its native projection with ~v.in.ogr~ it displays fine.
If I then reproject with ~v.proj~, data is once again dropped.

~v.in.ogr~ complained about overlaps, which I don't think should exist,
even if they are valid in theory. I am currently re-importing with
~snap=1E-13~ as suggested by ~v.in.ogr~, but that is taking a few hours.
Anyway, it seems likely the reprojection won't work in this case either.

I find it strange that QGIS handles this both instantly and correctly (at
least correctly based on a cursory visual examination).

  -k.

QGIS doesn't use a topological data model when it displays such data; GRASS
tries to rebuild correct topology when importing such data; that's may be
the difference.

Have you tried to reproject your data with ogr2ogr?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

7

On 2017-10-21 at 08:42, Ken Mankoff <mankoff@gmail.com> wrote:

On 2017-10-20 at 18:22, Helmut Kudrnovsky <hellik@web.de> wrote:

try to use v.in.ogr instead in a location with the original
projection and then reproject it.

Importing, reprojecting, and saving in QGIS allows me to import using ~v.in.ogr~ in GRASS and then everything looks good.

  -k.

8

On Sat, Oct 21, 2017 at 10:54 AM, Helmut Kudrnovsky <hellik@web.de> wrote:

Have you tried to reproject your data with ogr2ogr?

I had not. Thank you for the suggestion. That works! And now I can use the
data in GRASS without launching QGIS.

Thanks,

   -k.

9

first replying to your initial post:

I’m working in EPSG:3413 and gdalsrsinfo reports “PROJ.4 : '+proj=longlat +datum=WGS84 +no_defs '” for this shapefile.

The corresponding PROJ.4 term for EPSG:3413 should be
+proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs

When I v.import it in GRASS, it takes ~2 hours, and there are many boundaries that appear incorrect. If I set “snap=-1” it only takes a few minutes, but there are more errors.

this is because v.import snaps by default with snap=1e-13. A fixed snapping threshold does not make sense, it depends on the actual input data. Therefore I have changed v.import in trunk and relbr72 (r71577,8) to not snap by default.

On Sat, Oct 21, 2017 at 10:42 AM, Ken Mankoff <mankoff@gmail.com> wrote:

On 2017-10-20 at 18:22, Helmut Kudrnovsky <hellik@web.de> wrote:

try to use v.in.ogr instead in a location with the original projection
and then reproject it.

If I import into its native projection with ~v.in.ogr~ it displays fine. If I then reproject with ~v.proj~, data is once again dropped.

Can you post the error message of v.proj, why data are dropped?

~v.in.ogr~ complained about overlaps, which I don’t think should exist, even if they are valid in theory.

Overlapping polygons can be ok, depending on what kind of information should be in the input.

I am currently re-importing with ~snap=1E-13~ as suggested by ~v.in.ogr~, but that is taking a few hours. Anyway, it seems likely the reprojection won’t work in this case either.

I find it strange that QGIS handles this both instantly and correctly (at least correctly based on a cursory visual examination).

Can you post a link to the problematic shapefile? Then we can 1) try to find out what exactly is causing these problems, 2) fix these problems.

Markus M

-k.

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

10

On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

Can you provide examples where v.in.ogr with cleaning/polygon conversion did
not work, but v.in.ogr -c + >v.clean produced better results?

really good data sets with all kind of (topological) mess are (from [correct
and incorrect] overlapping to self intersections etc):

o Natura 2000 data (~ 1GB):

https://www.eea.europa.eu/data-and-maps/data/natura-8#tab-gis-data

Apparently, there are a lot of polygons in Natura2000 data that are really overlapping, e.g.
SITECODE: UK0030395
SITENAME: Southern North Sea
with
SITECODE: UK0030352
SITENAME: Dogger Bank

Maybe some sites have been updated (both spatial delineation and name), but the old versions have not been deleted

v.in.ogr without snapping gives me lots of warnings about
WARNING: Unable to calculate area centroid

this is a symptom of floating point precision errors, so I tried v.in.ogr with snapping. With snap=1e-3, these warnings disappeared. Small areas could still be removed with v.clean tool=rmarea. In this example, there are still 75 areas smaller than 100 square meters which are most probably noise.

A hint for snapping: v.in.ogr suggest for these data a range of [1e-08, 1] for suitable snapping values. The exponent thus ranges from -8 to 0. Testing all possible values in this range obviously takes a lot of time.

You could set low = -8 , high = 0, and set mid to (low + high) / 2 = -4
Test with snap=1e$mid

If you still get errors, increase: set low to mid, get new mid with (low + high) / 2

else, decrease: set high to mid, get new mid with (low + high) / 2
Continue this until you found the threshold were these warnings just disappeared.

Snapping is slow and uses quite a bit of memory because it needs a spatial search tree. The nearest-neighbor tree (kd tree) currently used could do with some more optimization, but I (as the author of that beast) would need quite a bit of time to come up with a faster balancing method.

o World database of protected areas (~ 1 GB):

https://www.protectedplanet.net/

The real cleaning happens only if the snap option is set to > 0.

v.in.ogr gives some hints about the snap option, sometimes I don’t know what
should be the optimal setting.

noticed that v.in.ogr complains about overlapping areas, which were input
polygons that should not >overlap, but snapping did not help there, instead
I needed to remove small areas afterwards with v.clean.

same experiences here.

Should the current min_area option of v.in.ogr also be used to remove small
areas in the output?

never used this option:

min_area=float
Minimum size of area to be imported (square meters)
Smaller areas and islands are ignored. Should be greater than snap^2
Default: 0.0001

do you mean the small areas shouldn’t be imported or small areas should be
added to the neighbor area with the longest adjacent boundaries?

Thinking about it, small areas should be removed afterwards with v.clean tool=rmarea.

Markus M

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

11

Thanks for testing

Apparently, there are a lot of polygons in Natura2000 data that are >really

overlapping, e.g.

SITECODE: UK0030395
SITENAME: Southern North Sea
with
SITECODE: UK0030352
SITENAME: Dogger Bank

Maybe some sites have been updated (both spatial delineation >and name),

but the old versions have not been deleted

there are 3 site types in the data: sites according to the Bird directive
(A), sites according the Habitat directive (B) and sites according to both
Directives (C).

Overlapping of A and B are ok, overlapping A and B or A and C should be
incorrect.

I've implemented an GRASS addon for importing the SQLite version of this
data:

https://grass.osgeo.org/grass72/manuals/addons/v.in.natura2000.html

what I've seen while importing sites for some species or habitats, there are
such error messages already mentioned.

According to your findings, I try to adapt the add-on, when time permits...

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

12

On Sun, Oct 22, 2017 at 10:07 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

Thanks for testing

Apparently, there are a lot of polygons in Natura2000 data that are >really
overlapping, e.g.
SITECODE: UK0030395
SITENAME: Southern North Sea
with
SITECODE: UK0030352
SITENAME: Dogger Bank

Maybe some sites have been updated (both spatial delineation >and name),
but the old versions have not been deleted

there are 3 site types in the data: sites according to the Bird directive
(A), sites according the Habitat directive (B) and sites according to both
Directives (C).

Overlapping of A and B are ok, overlapping A and B or A and C should be
incorrect.

That explains a lot of the errors. Thus I should import only one of the site types A, B, C at a time, e.g. v.in.ogr where=“SITETYPE=‘A’”, correct?

Unfortunately, with the example I mentioned, the two overlapping polygons are both of site type B, suggesting that the update of the database did not remove the old entry.

Markus M

I’ve implemented an GRASS addon for importing the SQLite version of this
data:

https://grass.osgeo.org/grass72/manuals/addons/v.in.natura2000.html

what I’ve seen while importing sites for some species or habitats, there are
such error messages already mentioned.

According to your findings, I try to adapt the add-on, when time permits…

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

13

That explains a lot of the errors. Thus I should import only one of >the

site types A, B, C at a time, e.g. v.in.ogr where="SITETYPE='A'", >correct?

yes

Unfortunately, with the example I mentioned, the two overlapping >polygons

are both of site type B, suggesting that the update of the >database did not
remove the old entry

sites of the same type shouldn't overlap, these are artefacts of different
data sources over Europe compiled in a not "cleaned" data set

I'm aware that not all of these issues could/should be "automagically"
solved during import, some precision errors/self intersection/....
correction would be nice :slight_smile:

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

14

On Sun, Oct 22, 2017 at 10:51 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

That explains a lot of the errors. Thus I should import only one of >the
site types A, B, C at a time, e.g. v.in.ogr where=“SITETYPE=‘A’”, >correct?

yes

Unfortunately, with the example I mentioned, the two overlapping >polygons
are both of site type B, suggesting that the update of the >database did not
remove the old entry

sites of the same type shouldn’t overlap, these are artefacts of different
data sources over Europe compiled in a not “cleaned” data set

In this case, the user has to decide what is correct. Both polygons have the same “RELEASE_DA: 2017-01-30”, no way to decide which one is newer.

I’m aware that not all of these issues could/should be “automagically”
solved during import, some precision errors/self intersection/…
correction would be nice :slight_smile:

v.in.ogr can fix precision errors with a suitable value for snapping. Areas that are too small to be considered valid areas can be removed with v.clean tool=rmarea. For everything else, as in the example above, the user must decide what is correct and what not.

In short, software “a” can fix errors created by software “b”, but most often only humans can fix human errors. In the end, human decision about what is correct and what not is needed. Regarding the problem with Natura2000, I am pretty sure that someone added a certain site and that same person, and/or another one doing cross-checking, did not notice that there is an earlier version of that site, maybe with a different name but same location.

Markus M

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

15

Markus Metz-3 wrote

On Sun, Oct 22, 2017 at 10:51 PM, Helmut Kudrnovsky &lt;

hellik@

&gt; wrote:

>That explains a lot of the errors. Thus I should import only one of >the
site types A, B, C at a time, e.g. v.in.ogr where="SITETYPE='A'",
correct?

yes

>Unfortunately, with the example I mentioned, the two overlapping
polygons
are both of site type B, suggesting that the update of the >database did

not

remove the old entry

sites of the same type shouldn't overlap, these are artefacts of
different
data sources over Europe compiled in a not "cleaned" data set

In this case, the user has to decide what is correct. Both polygons have
the same "RELEASE_DA: 2017-01-30", no way to decide which one is newer.

I'm aware that not all of these issues could/should be "automagically"
solved during import, some precision errors/self intersection/....
correction would be nice :slight_smile:

v.in.ogr can fix precision errors with a suitable value for snapping.
Areas
that are too small to be considered valid areas can be removed with
v.clean
tool=rmarea. For everything else, as in the example above, the user must
decide what is correct and what not.

In short, software "a" can fix errors created by software "b", but most
often only humans can fix human errors. In the end, human decision about
what is correct and what not is needed. Regarding the problem with
Natura2000, I am pretty sure that someone added a certain site and that
same person, and/or another one doing cross-checking, did not notice that
there is an earlier version of that site, maybe with a different name but
same location.

Markus M

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

I agree with you all above. :slight_smile:

I'm in exchange with EEA as data provider to improve this nice data set.

Could you send me off-list your example site mentioned above, then I will
forward the issue to the data provider.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

16

On to the next one:

On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

[…]

o World database of protected areas (~ 1 GB):

https://www.protectedplanet.net/

First problems: lots of warnings like
WARNING: Degenerate island (1 vertices)
WARNING: Feature (cat ): degenerated polygon (1 vertices)

These are invalid geometries in the input

The real cleaning happens only if the snap option is set to > 0.

From the WDPA manual:
“There are many overlapping protected areas in the WDPA. These can be overlapping areas with
different IUCN categories or the overlap of national protected areas with designations under
regional or international conventions and agreements.”

Thus I would not regard all overlapping areas as errors. I used a spatial subset for testing:
v.in.ogr spatial=5.467,43.842,14.3,50.558
that’s the Alps and a bit around.

v.in.ogr suggests a snapping value in the range 1e-5, 1e-13. I started with 1e-9 and got rid of the warnings like
WARNING: Unable to calculate area centroid

but some incorrect boundaries remained in the output. With snap=1e-8, these incorrect boundaries disappeared.

The output contains lots of small areas. According to GIS_AREA in the attribute table, the smallest areas in the input are larger than 100 square meters, so I cleaned with v.clean tool=rmarea thresh=100, getting rid of 60% of all areas in the output.

In earlier years, the WDPA was separated into different shapefiles: one for marine areas, one for IUCN I-VI, one for all other areas. Now everything is in one shapefile / GDB. When importing these data, a spatial and an attribute filter should be set for v.in.ogr.

HTH,

Markus M

v.in.ogr gives some hints about the snap option, sometimes I don’t know what
should be the optimal setting.

noticed that v.in.ogr complains about overlapping areas, which were input
polygons that should not >overlap, but snapping did not help there, instead
I needed to remove small areas afterwards with v.clean.

same experiences here.

Should the current min_area option of v.in.ogr also be used to remove small
areas in the output?

never used this option:

min_area=float
Minimum size of area to be imported (square meters)
Smaller areas and islands are ignored. Should be greater than snap^2
Default: 0.0001

do you mean the small areas shouldn’t be imported or small areas should be
added to the neighbor area with the longest adjacent boundaries?

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

17

Markus Metz-3 wrote

On to the next one:

On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky &lt;

hellik@

&gt; wrote:

[...]

o World database of protected areas (~ 1 GB):

https://www.protectedplanet.net/

First problems: lots of warnings like
WARNING: Degenerate island (1 vertices)
WARNING: Feature (cat
<XY>
): degenerated polygon (1 vertices)

These are invalid geometries in the input

>The real cleaning happens only if the snap option is set to > 0.

From the WDPA manual:
"There are many overlapping protected areas in the WDPA. These can be
overlapping areas with
different IUCN categories or the overlap of national protected areas with
designations under
regional or international conventions and agreements."

Thus I would not regard all overlapping areas as errors. I used a spatial
subset for testing:
v.in.ogr spatial=5.467,43.842,14.3,50.558
that's the Alps and a bit around.

v.in.ogr suggests a snapping value in the range 1e-5, 1e-13. I started
with
1e-9 and got rid of the warnings like
WARNING: Unable to calculate area centroid

but some incorrect boundaries remained in the output. With snap=1e-8,
these
incorrect boundaries disappeared.

The output contains lots of small areas. According to GIS_AREA in the
attribute table, the smallest areas in the input are larger than 100
square
meters, so I cleaned with v.clean tool=rmarea thresh=100, getting rid of
60% of all areas in the output.

In earlier years, the WDPA was separated into different shapefiles: one
for
marine areas, one for IUCN I-VI, one for all other areas. Now everything
is
in one shapefile / GDB. When importing these data, a spatial and an
attribute filter should be set for v.in.ogr.

thanks for also testing this data set. I'll add some notes in the wiki about
importing these datasets.

thanks.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

18

Hi –

A few days ago I upgraded the operating system on my MacBook Pro from 10.11 to 10.13 (High Sierra). Most everything seems to still be working - except GRASS and QGIS. I have been running Barton’s binaries and Kyngs’s frameworks for a number of years without any major problems. I have 3 GRASS versions installed - 6.4.5, 7.3 (py2), and 7.3 (py3). 6.4 gives the most succinct error messages on startup and it’s possible to continue on the command line (no gui):

dyld: Library not loaded: /Applications/GRASS/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.5svn.dylib
Referenced from: /Applications/GRASS-6.4.app/Contents/MacOS/bin/g.gisenv
Reason: image not found

The library in question is still where it’s always been.

7.3 is more verbose, but basically says the same thing:

Starting GRASS GIS…
dyld: Library not loaded: /Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib
Referenced from: /Applications/GRASS-7.3_py3.app/Contents/MacOS/bin/g.gisenv
Reason: image not found
Traceback (most recent call last):
File “/Applications/GRASS-7.3_py3.app/Contents/MacOS/gui/wxpython/gis_set.py”, line 31, in
from core import globalvar

…

grass.exceptions.CalledModuleError: Module run None [‘g.gisenv’, ‘-n’] ended with error
Process ended with non-zero return code -6. See errors in the (error) output.
ERROR: Error in GUI startup. See messages above (if any) and if necessary, please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package, probably named grass-gui, installed.
To run GRASS GIS in text mode use the -text flag.
Exiting…
logout

I tried a fresh installation of 7.3 using macports (grass7) and strangely, had a failure where wxWidgets could not be found:

—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from https://pek.cn.distfiles.macports.org/macports/distfiles/wxWidgets/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://ncu.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://netcologne.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://biolpc22.york.ac.uk/pub/3.0.2/
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://her.gr.distfiles.macports.org/wxWidgets/3.0.2
Error: Failed to fetch wxPython-3.0: The requested URL returned error: 404 Not Found
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_wxWidgets-3.0/wxPython-3.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port grass7 failed

Macports attempted to fetch wxWidgets from all its sources. But the currently installed (and considered up to date) version is wxWidgets-3.0.3 - strange.

So there does appear to be something unusual going on with wxpython and OS X 10.13

The bad news may be that there is currently no source of a binary version of GRASS for anyone with a new Mac or upgrading their OS. I did get the Macports version of QGIS to install and run - but I need my GRASS to run !

Happy to pursue this further if anyone has any ideas to try …

thx

Stu

19

Hello Stu

I’m still with Sierra but I use homebrew to install GRASS. I also had some issues with wxpython, and to fix it I had to add this to bash_profile:

export PYTHONPATH=/usr/local/lib/python2.7/site-packages:/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa:$PYTHONPATH

hope it helps

Carlos

···

On Mon, Oct 23, 2017 at 1:41 PM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi –

A few days ago I upgraded the operating system on my MacBook Pro from 10.11 to 10.13 (High Sierra). Most everything seems to still be working - except GRASS and QGIS. I have been running Barton’s binaries and Kyngs’s frameworks for a number of years without any major problems. I have 3 GRASS versions installed - 6.4.5, 7.3 (py2), and 7.3 (py3). 6.4 gives the most succinct error messages on startup and it’s possible to continue on the command line (no gui):

dyld: Library not loaded: /Applications/GRASS/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.5svn.dylib
Referenced from: /Applications/GRASS-6.4.app/Contents/MacOS/bin/g.gisenv
Reason: image not found

The library in question is still where it’s always been.

7.3 is more verbose, but basically says the same thing:

Starting GRASS GIS…
dyld: Library not loaded: /Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib
Referenced from: /Applications/GRASS-7.3_py3.app/Contents/MacOS/bin/g.gisenv
Reason: image not found
Traceback (most recent call last):
File “/Applications/GRASS-7.3_py3.app/Contents/MacOS/gui/wxpython/gis_set.py”, line 31, in
from core import globalvar

…

grass.exceptions.CalledModuleError: Module run None [‘g.gisenv’, ‘-n’] ended with error
Process ended with non-zero return code -6. See errors in the (error) output.
ERROR: Error in GUI startup. See messages above (if any) and if necessary, please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package, probably named grass-gui, installed.
To run GRASS GIS in text mode use the -text flag.
Exiting…
logout

I tried a fresh installation of 7.3 using macports (grass7) and strangely, had a failure where wxWidgets could not be found:

—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from https://pek.cn.distfiles.macports.org/macports/distfiles/wxWidgets/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://ncu.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://netcologne.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://biolpc22.york.ac.uk/pub/3.0.2/
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://her.gr.distfiles.macports.org/wxWidgets/3.0.2
Error: Failed to fetch wxPython-3.0: The requested URL returned error: 404 Not Found
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_wxWidgets-3.0/wxPython-3.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port grass7 failed

Macports attempted to fetch wxWidgets from all its sources. But the currently installed (and considered up to date) version is wxWidgets-3.0.3 - strange.

So there does appear to be something unusual going on with wxpython and OS X 10.13

The bad news may be that there is currently no source of a binary version of GRASS for anyone with a new Mac or upgrading their OS. I did get the Macports version of QGIS to install and run - but I need my GRASS to run !

Happy to pursue this further if anyone has any ideas to try …

thx

Stu

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

–

Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil

  • Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/0000-0001-5073-5572

Can’t stop the signal.

20

Carlos

Thanks for the quick response… Unfortunately that did not cure the problem. You say you are using homebrew - that was my first choice, but I don’t see GRASS in their package list - am I missing something?

Stu

···

On Mon, Oct 23, 2017 at 1:41 PM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi –

A few days ago I upgraded the operating system on my MacBook Pro from 10.11 to 10.13 (High Sierra). Most everything seems to still be working - except GRASS and QGIS. I have been running Barton’s binaries and Kyngs’s frameworks for a number of years without any major problems. I have 3 GRASS versions installed - 6.4.5, 7.3 (py2), and 7.3 (py3). 6.4 gives the most succinct error messages on startup and it’s possible to continue on the command line (no gui):

dyld: Library not loaded: /Applications/GRASS/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.5svn.dylib
Referenced from: /Applications/GRASS-6.4.app/Contents/MacOS/bin/g.gisenv
Reason: image not found

The library in question is still where it’s always been.

7.3 is more verbose, but basically says the same thing:

Starting GRASS GIS…
dyld: Library not loaded: /Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib
Referenced from: /Applications/GRASS-7.3_py3.app/Contents/MacOS/bin/g.gisenv
Reason: image not found
Traceback (most recent call last):
File “/Applications/GRASS-7.3_py3.app/Contents/MacOS/gui/wxpython/gis_set.py”, line 31, in
from core import globalvar

…

grass.exceptions.CalledModuleError: Module run None [‘g.gisenv’, ‘-n’] ended with error
Process ended with non-zero return code -6. See errors in the (error) output.
ERROR: Error in GUI startup. See messages above (if any) and if necessary, please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package, probably named grass-gui, installed.
To run GRASS GIS in text mode use the -text flag.
Exiting…
logout

I tried a fresh installation of 7.3 using macports (grass7) and strangely, had a failure where wxWidgets could not be found:

—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from https://pek.cn.distfiles.macports.org/macports/distfiles/wxWidgets/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://ncu.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://netcologne.dl.sourceforge.net/project/wxwindows/3.0.2
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://biolpc22.york.ac.uk/pub/3.0.2/
—> Attempting to fetch wxWidgets-3.0.3.tar.bz2 from http://her.gr.distfiles.macports.org/wxWidgets/3.0.2
Error: Failed to fetch wxPython-3.0: The requested URL returned error: 404 Not Found
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_wxWidgets-3.0/wxPython-3.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port grass7 failed

Macports attempted to fetch wxWidgets from all its sources. But the currently installed (and considered up to date) version is wxWidgets-3.0.3 - strange.

So there does appear to be something unusual going on with wxpython and OS X 10.13

The bad news may be that there is currently no source of a binary version of GRASS for anyone with a new Mac or upgrading their OS. I did get the Macports version of QGIS to install and run - but I need my GRASS to run !

Happy to pursue this further if anyone has any ideas to try …

thx

Stu

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

–

Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil

  • Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/0000-0001-5073-5572

Can’t stop the signal.