Re: [GRASS-user] Grass on MacOS

[Adam Dershowitz]

Thanks, but…I use Macports for a bunch of things, and homebrew and maports 
don’t play well together.  So, I can’t easily do that.
I did get the macports version to work after I asked the question.  It was 
actually just due to the fact that I have been using the Kyngchoas version for 
a long time, and that used to require that GRASS_PYTHON be set in 
.bash_profile.  But, I had set it to point to an old directory a while back, 
and that folder didn’t exist.  So, I just had to delete that environmental 
variable and the macports version now works fine.
And, the Kyngchaos version of qgis does seem to work fine.

Thanks for the suggestion.
I suppose that it would be useful to have working binaries to avoid these kinds 
of issues.


-- Adam


From: Carlos Grohmann <carlos.grohm...@gmail.com>
Date: Saturday, January 13, 2018 at 6:59 PM
To: Dershowitz Adam <adershow...@exponent.com>
Cc: "grass-user@lists.osgeo.org" <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] Grass on MacOS

Adam,

I keep my GRASS up and running with homebrew. Just head to 
https://brew.sh<https://urldefense.proofpoint.com/v2/url?u=https-3A__brew.sh=DwMFaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=MFs4gjKGO2QJYHCjY3pj1uEo53pn2C5qTj5KRyQVo1Q=IYpW4PLMsIvNNktuabzSPkZB_cLfHKQZF6ywa3KizuY=>
 and follow a few steps to set it up. Then, go to 
https://github.com/OSGeo/homebrew-osgeo4mac<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OSGeo_homebrew-2Dosgeo4mac=DwMFaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=MFs4gjKGO2QJYHCjY3pj1uEo53pn2C5qTj5KRyQVo1Q=Vr-n3MZdL65kKLvsZkV-58CnNx6itgZFIKtDK7dLl-s=>
 to ‘tap’ the recipes for OSGeo software. You can install QGIS this way also.

Best

Carlos


On Sat, 13 Jan 2018 at 19:19 Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:
Has there been any progress in getting Grass to continue to work on current Mac 
computers?
It used to run fine, but then it ran into issues with SIP security on when 
10.11 came out.  And now, the same problem remains on 10.12.  It appears that 
the available mac binaries for grass7 haven’t been updated in a year and a 
half.  I’ve also tried to install grass7 using macports, but that gui won’t run 
(I created a ticket for that)
So, I’m just looking for any news or suggestions for how to run grass7.


Thanks,


-- Adam

___
grass-user mailing list
grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-user<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_grass-2Duser=DwMFaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=MFs4gjKGO2QJYHCjY3pj1uEo53pn2C5qTj5KRyQVo1Q=97Xoz-XoL0wIWc6Z7ztaKNojh4cXuiyCtWP256RFYVg=>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Grass on MacOS

[Adam Dershowitz]

Has there been any progress in getting Grass to continue to work on current Mac 
computers?
It used to run fine, but then it ran into issues with SIP security on when 
10.11 came out.  And now, the same problem remains on 10.12.  It appears that 
the available mac binaries for grass7 haven’t been updated in a year and a 
half.  I’ve also tried to install grass7 using macports, but that gui won’t run 
(I created a ticket for that)
So, I’m just looking for any news or suggestions for how to run grass7.


Thanks,


-- Adam

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

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

Michael,

Was there ever a solution found to running GRASS on the Mac (10.11 or now 
10.12) without disabling SIP?

Thanks,


-- Adam


From: grass-user  on behalf of Michael 
Barton 
Date: Wednesday, June 1, 2016 at 7:50 PM
To: GRASS developers list , grass-user grass-user 

Subject: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

I just posted a new binary for GRASS 7.3 built fully 64 bit, with wxPython 
3.0.2.0 to the GRASS for Mac site 
(http://grassmac.wikidot.com)

It turns out the previous "64bit" GRASS binary still ran 32bit Python. I had to 
hack the python_wrapper.py file, but this one is fully 64bit AFAICT. I also 
tried some hacks that might be a way to solve the inability to run GRASS on El 
Capitan with SIP enabled. There are a couple of known bugs in the wxPython 3.x 
GUI

1. The most serious is switching to 3D mode and back to 2D mode leaves one of 
the map display menu buttons corrupted. It seems the only thing you can do is 
to close the map display and open a new one.

2. There are also some popup lists (e.g., for switching mapsets) that do not 
behave as they should. You cannot select an item with a mouse (but you can 
select with arrow keys and ) unless you hit  to destroy part of 
the control. Then you can use the mouse to click something.

Please let us know if you encounter any other bug or strange behavior.

Also,  and importantly if anyone is running El Capitan, it would be great if 
you could reenable SIP (if you've turned it off) and see if this version runs.  
Of course, maybe I've "fixed" it so that it only runs on my system and crashes 
on everyone else's.

Enjoy!
Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton,
 
http://csdc.asu.edu















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

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I just tried it, and see the same error as before:

$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Python 2.7.10 found.
Cleaning up temporary files...
Starting GRASS GIS...
Traceback (most recent call last):
  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 
from core import globalvar
  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 
import wx
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 
from wx._core import *
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 
import _core_
ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/cmbarton/grass_source/wxp3/Users/cmbarton/grass_source/wxp3/lib/libwx_osx_cocoau-3.0.0.2.0.dylib
  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
  Reason: image not found
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
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.


[Process completed]




Good luck with the other attempt.  I’m happy to test it out, once you get it in 
the right form.  

-- Adam









On 6/13/16, 6:00 PM, "Michael Barton" <michael.bar...@asu.edu> wrote:

>It's been a busier day than I anticipated. But I've got a clean binary of 
>GRASS 7.3 64bit, using wxPython 3.0.2.0 on my website now. I doubt that this 
>will work any better under SIP, but perhaps...
>
>
>
>Please try if you can. I appreciate the tests.
>
>
>
>I'm also working on another angle, with the help of a software engineer here 
>at ASU. Working from my notes, he seems to have compiled GRASS under El 
>Capitan, with SIP enabled and it works fine. He will be working on a package 
>that we can make available for testing. I just had a long discussion with him 
>and there are some caveats. 
>
>
>
>1. GRASS would not compile with some of the 32 bit frameworks that can be 
>installed from my site. So he recompiled all frameworks dual architecture 
>32/64 bit.
>
>2. Like me, he compiled wxPython from source to a folder outside the sensitive 
>system folders that SIP is protecting. 
>
>3. He is going to try the new Mac package maker system (pkgbuild) to create a 
>complete package with all dependencies packaged together for distribution. 
>They will all install into a new GRASS framework to avoid conflicts with any 
>other software. 
>
>
>
>He's also setting up a virtual machine for me that I can use to test compiling 
>GRASS under El Capitan and SIP, using frameworks and other dependencies as 
>they are now. So we can see how that goes. 
>
>
>
>Wish us luck with this.
>
>
>
>Michael
>
>
>
>C. Michael Barton
>
>Director, Center for Social Dynamics & Complexity 
>
>Professor of Anthropology, School of Human Evolution & Social Change
>
>Head, Graduate Faculty in Complex Adaptive Systems Science
>
>Arizona State University
>
>
>
>voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>www: 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=PXmZfNM0LMsRCxHT_shcR9SONBT6CCuy6LMkPaKJpCE=kt5-aRX_2LUhw3GqQZzVMHYYOBW2CWO0DK34KUVXrDc=
> , 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=PXmZfNM0LMsRCxHT_shcR9SONBT6CCuy6LMkPaKJpCE=k8zClgrEQGSZF9m91uUTAhMX-FWcRkiECffSHqglsRM=
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On Jun 13, 2016, at 9:25 AM, Agustin Diez Castillo <agustin.d...@uv.es> 
>> wrote:
>
>> 
>
>>> 
>
>>> On 13 Jun 2016, at 17:10, Adam Dershowitz <adershow...@exponent.com> wrote:
>
>>> 
>
>>> That is with the newest version? (I downloaded from the web site an hour 
>>> ago)
>
>> As far as I can say GRASS GIS 7.3.svn-160606, dated June, 2.
>
>>> 
>
>>> That is really strange.  Michael, does the installer change any paths?  
>>> Agustin, did 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

That is with the newest version? (I downloaded from the web site an hour ago)  
That is really strange.  Michael, does the installer change any paths?  
Agustin, did you already having anything in /usr/local/lib/wxPython-3.0.2.0?  
Perhaps, in a non-SIP, machine, the installer puts stuff in /usr/local, and the 
installer then adjusts the paths accordingly, while it can’t on a SIP machine, 
so it installs into the package bundle itself?  

-- Adam








On 6/13/16, 10:38 AM, "Agustin Diez Castillo" <agustin.d...@uv.es> wrote:

>I have no clue, but this is not the same in my machine, there nothing is 
>pointing to Michael’s machine.
>otool -L /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
>/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so:
>   /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
> version 7.4.0)
>   /usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
> (compatibility version 3.0.0, current version 3.0.0)
>   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
> (compatibility version 1.0.0, current version 275.0.0)
>   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
> (compatibility version 2.0.0, current version 136.0.0)
>   /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
> (compatibility version 1.0.0, current version 12.0.0)
>   
> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 
> (compatibility version 1.0.0, current version 1.0.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 111.1.4)
>   /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
> (compatibility version 1.0.0, current version 1.0.0)
>   /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
> 1.0.0)
>   
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 150.0.0, current version 476.18.0)
>   
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  (compatibility version 1.0.0, current version 34.0.0)
>
>El 13Jun, 2016, a las 4:25 PM, Adam Dershowitz <adershow...@exponent.com> 
>escribió:
>
>> Strange.  Because you local path is explicitly in the binary.  Here is what 
>> shows for the libraries for _core_.so  on my machine.  I don’t see why 
>> disabling SIP should change this:
>> 
>> $otool -L /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
>> /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so:
>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
>> version 56.0.0)
>>  
>> /Users/cmbarton/grass_source/wxp3/usr/local/lib/libwx_osx_cocoau-3.0.0.2.0.dylib
>>  (compatibility version 3.0.0, current version 3.0.0)
>>  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
>> (compatibility version 1.0.0, current version 275.0.0)
>>  /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
>> (compatibility version 2.0.0, current version 155.0.0)
>>  /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
>> (compatibility version 1.0.0, current version 19.0.0)
>>  
>> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>> version 169.3.0)
>>  /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>> 1669.0.0)
>>  
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
>>  (compatibility version 150.0.0, current version 744.19.0)
>>  
>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>  (compatibility version 1.0.0, current version 45.0.0)
>> 
>> 
>> 
>> 
>> Perhaps without SIP, it falls back to searching another way, instead of just 
>> using this path?  While with SIP, it only uses the explicit path?
>> The libraries are present in the application bundle, so the problem is just 
>> “telling” it where to look for them.
>> 
>> -- Adam
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 6/13/16, 10:15 AM, "Michael Barton" <michael.bar...@asu.edu> wrote:
>> 
>>> Except that this error only occurs with SIP enabled. Disable SIP and the 
>>> error goes away and everything runs fine.
>>> 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

Strange.  Because you local path is explicitly in the binary.  Here is what 
shows for the libraries for _core_.so  on my machine.  I don’t see why 
disabling SIP should change this:

$otool -L /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 56.0.0)

/Users/cmbarton/grass_source/wxp3/usr/local/lib/libwx_osx_cocoau-3.0.0.2.0.dylib
 (compatibility version 3.0.0, current version 3.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 155.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 19.0.0)

/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
1669.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 744.19.0)

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 45.0.0)




Perhaps without SIP, it falls back to searching another way, instead of just 
using this path?  While with SIP, it only uses the explicit path?  
The libraries are present in the application bundle, so the problem is just 
“telling” it where to look for them.  

-- Adam








On 6/13/16, 10:15 AM, "Michael Barton" <michael.bar...@asu.edu> wrote:

>Except that this error only occurs with SIP enabled. Disable SIP and the error 
>goes away and everything runs fine. 
>
>Michael Barton
>School of Human Evolution  Change
>Center for Social Dynamics & Complexity
>Arizona State University
>
>...Sent from my iPad
>
>> On Jun 13, 2016, at 6:18 AM, Adam Dershowitz <adershow...@exponent.com> 
>> wrote:
>> 
>> I was traveling last week, so just got to this.
>> 
>> No luck.  And, it doesn’t look like a SIP issue.  Instead, the path is now 
>> hard coded to something on your machine.  Here is the error I get when it 
>> try to open the application:
>> 
>> $ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit
>> Rebuilding Addon HTML manual pages index...
>> Rebuilding Addon menu...
>> Python 2.7.10 found.
>> Cleaning up temporary files...
>> Starting GRASS GIS...
>> Traceback (most recent call last):
>>  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
>> line 31, in 
>>from core import globalvar
>>  File 
>> "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
>> line 96, in 
>>import wx
>>  File 
>> "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", line 
>> 45, in 
>>from wx._core import *
>>  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
>> line 4, in 
>>import _core_
>> ImportError: 
>> dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 
>> 2): Library not loaded: 
>> /Users/cmbarton/grass_source/wxp3/usr/local/lib/libwx_osx_cocoau-3.0.0.2.0.dylib
>>  Referenced from: 
>> /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
>>  Reason: image not found
>> 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
>> Saving session...
>> ...copying shared history...
>> ...saving history...truncating history files...
>> ...completed.
>> 
>> 
>> [Process completed]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- Adam
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 6/9/16, 8:37 PM, "Michael Barton" <michael.bar...@asu.edu> wrote:
>>> 
>>> I've replaced the build from earlier today with one that is sort of

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

f Human Evolution & Social Change
>
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>
>> Arizona State University
>
>> 
>
>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>> www: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=ZHG1SBIrTbYkWcpw0RMifv4qtTknor0PcekUo29_faA=t-evT5rQyQQdd5Yl-DU1zeDo8ybQZ4me2JzEEZ1ddA4=
>>  , 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=ZHG1SBIrTbYkWcpw0RMifv4qtTknor0PcekUo29_faA=xdYPqcLWa0qS3KHYIxFxDSyf5TRG7ewwV8xNHfIrBfI=
>>  
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>> 
>
>>> On Jun 9, 2016, at 1:50 PM, Anna Petrášová <kratocha...@gmail.com> wrote:
>
>>> 
>
>>> On Thu, Jun 9, 2016 at 4:30 PM, Michael Barton <michael.bar...@asu.edu> 
>>> wrote:
>
>>>> yet another GRASS 7.3 64 bit.
>
>>>> 
>
>>>> In this version (just uploaded a few minutes ago to the website), I've 
>>>> built
>
>>>> wxPython from source and installed it in a non-system folder. I built GRASS
>
>>>> against this local build of wxPython. There should be no problems for SIP 
>>>> if
>
>>>> it is only the bundled dependencies. And this should not require any
>
>>>> additional packages like Anaconda.
>
>>> 
>
>>> I tested it on old Yosemite (before SIP came) and works great, but I
>
>>> was wondering, since you decided to compile wxpython, could you use
>
>>> wxpython 3.0.3? It's not released, but a lot of bugs are supposed to
>
>>> be solved there.
>
>>> 
>
>>> Thanks
>
>>> 
>
>>> Anna
>
>>>> 
>
>>>> Let me know
>
>>>> Michael
>
>>>> 
>
>>>> C. Michael Barton
>
>>>> Director, Center for Social Dynamics & Complexity
>
>>>> Professor of Anthropology, School of Human Evolution & Social Change
>
>>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>
>>>> Arizona State University
>
>>>> 
>
>>>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>>>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>>>> www: 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=ZHG1SBIrTbYkWcpw0RMifv4qtTknor0PcekUo29_faA=t-evT5rQyQQdd5Yl-DU1zeDo8ybQZ4me2JzEEZ1ddA4=
>>>>  , 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=ZHG1SBIrTbYkWcpw0RMifv4qtTknor0PcekUo29_faA=xdYPqcLWa0qS3KHYIxFxDSyf5TRG7ewwV8xNHfIrBfI=
>>>>  
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> On Jun 6, 2016, at 12:37 PM, Michael Barton <michael.bar...@asu.edu> wrote:
>
>>>> 
>
>>>> OK. This means the /usr/local/... path is hardwired into the wxPython Mac
>
>>>> binary itself. Not sure if this changes how we need to deal with this.
>
>>>> 
>
>>>> Michael
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> C. Michael Barton
>
>>>> Director, Center for Social Dynamics & Complexity
>
>>>> Professor of Anthropology, School of Human Evolution & Social Change
>
>>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>
>>>> Arizona State University
>
>>>> 
>
>>>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>>>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>>>> www: 
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=ZHG1SBIrTbYkWc

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

Just run install_name_tool commands, as I listed, as part of the build process?
I just noticed that in my prior email, I had listed the prior set of commands 
that I had used.  This is the set that worked for the new download:


install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gdi_.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_windows_.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_controls_.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_misc_.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_combo.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_aui.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_html.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gizmos.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_stc.so

adershowitzMBP15:Geo data adershowitz$ install_name_tool -change 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_wizard.so



-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Monday, June 6, 2016 at 3:37 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>, Helena 
Mitasova <hmit...@unity.ncsu.edu<mailto:hmit...@unity.ncsu.edu>>, Anna 
Petrášová <kratocha...@gmail.com<mailto:kratocha...@gmail.com>>, William 
Kyngesburye <kyngch...@kyngchaos.com<mailto:kyngch...@kyngchaos.com>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

OK. This means the /usr/local/... path is hardwired into the wxPython Mac 
binary itself. Not sure if this changes how we need to deal with this.

Michael



C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=KfpLBtZo0896ZGH4dOr-WKNJ4qMysE-9MyKe2VjSapI=pPYEfTWQU59iOGxaLVi-lTQ_e3jD72ZjkCBuKtPM2sY=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

It looks like you got the libintl.8.dylib corrected from the earlier version.  
But, not the other issues.  I again, tried to just change the paths by doing 
this:


install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gdi_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_windows_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_controls_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_misc_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_combo.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_aui.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_html.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gizmos.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_stc.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_wizard.so

And, with those changes it does start up, but still gives this error


Starting GRASS GIS...

Unable to import pyGRASS: grass_gis.7.3.svn not found.

Some functionality will be not accessible


And still doesn’t have the 3D menu item, or vector.  It just has 2D and Raster 
digitizer.


-- Adam


From: grass-user 
<grass-user-boun...@lists.osgeo.org<mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>
Date: Monday, June 6, 2016 at 3:15 PM
To: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Cc: GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>, Helena 
Mitasova <hmit...@unity.ncsu.edu<mailto:hmit...@unity.ncsu.edu>>, GRASS 
developers <grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

I just downloaded it, and tried it.  No luck.  It still doesn’t find the 
libraries that it needs:


'/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

ERROR: Error in GUI startup. See messages above (if any) 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I just downloaded it, and tried it.  No luck.  It still doesn’t find the 
libraries that it needs:


'/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/usr/local/lib/wxPython-3.0.2.0/lib/libwx_osx_cocoau-3.0.0.2.0.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

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

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.

Deleting expired sessions...none found.


[Process completed]


-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Monday, June 6, 2016 at 2:50 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>, Helena 
Mitasova <hmit...@unity.ncsu.edu<mailto:hmit...@unity.ncsu.edu>>, Anna 
Petrášová <kratocha...@gmail.com<mailto:kratocha...@gmail.com>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Adam and others,

Yet another GRASS 64 bit. I just uploaded to the GRASS for Mac site.

I tried something else. I am hoping that this works with SIP enabled in El 
Capitan and does not add Anaconda as a required dependency.

If you have a chance, give it a try.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMF-g=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=EptVyHvN5Hy-kJAyE5zVpjKVi-Hj12JwOOKM6yUgzF0=34kfotLDUf5mRfMlJY9uXiBzLxZFhHfdFsRiE5hwz0s=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMF-g=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=EptVyHvN5Hy-kJAyE5zVpjKVi-Hj12JwOOKM6yUgzF0=M_LT_GhsO_-fWH5lR5tqThIl7ZwPXZN68wY9zdZVpwM=>






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

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

But, I would expect an error about not finding the library, like I was seeing 
for the other ones.  So, I’m not sure what library can’t find gdal?
In my map display window, if I open a raster, I see a pull down the that 2D 
view and Raster digitizer.  Is that where there also should be a 3D view?

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 4:49 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers grass-developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

I’ve had no problem running 3D (in the map display window). Maybe you didn’t 
get a path set for the wx…gdal… library?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=vjhLrubVoF-sjcYsbddVAVITTG-R9J2vxvkD2ryxpWA=HSb2ejphgIk2ThFvvABiX5O7wuYmHCYlJF4opQ6_D70=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=vjhLrubVoF-sjcYsbddVAVITTG-R9J2vxvkD2ryxpWA=UDcv_mm1lzEDJ2ZLIiZ09GFO3Y7oFP_49S_w6sK-cj4=>















On Jun 2, 2016, at 1:34 PM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I went back to the prior version that I downloaded, where I made the changes to 
the paths.  What I had not noticed before is that I don’t see any way to run 
nviz.  I only see a 2D view.  Is that something that should be installed, but 
it might also be a path issue?
When I do run grass, I also see this:  Unable to import pyGRASS: 
grass_gis.7.3.svn not found.   So, that might relate to 3D, or might just be a 
sign of another part of the path to dynamic library issue.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 3:48 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers grass-developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Darn!

It is as I was afraid of. Building with Anaconda wxPython means that the GUI is 
looking for the Anaconda Python distribution too. So this approach will not 
work.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=IovcDfAWhG30sZ7BGwZXrYH6f41WBK7HRKHkuPNgkrA=z7A7QhuV1iwhyXBpOAjNf8wCV1DiNMR5FhyYuyczMjQ=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=IovcDfAWhG30sZ7BGwZXrYH6f41WBK7HRKHkuPNgkrA=oqfEXF7oF6JcoKPOafzbNpJjBr9QxSgliE0Bbq6IzsA=>















On Jun 2, 2016, at 12:15 PM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I just downloaded the version on the site, and when I run it, I have the same 
problem.  wxPython is looking in the wrong place for shared libraries:

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Python 2.7.10 found.
Cleaning up temporary files...
Starting GRASS GIS...
Traceback (most recent call last):
  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 
from core import globalvar
  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 
import wx
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 
from wx._core import *
  File 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I went back to the prior version that I downloaded, where I made the changes to 
the paths.  What I had not noticed before is that I don’t see any way to run 
nviz.  I only see a 2D view.  Is that something that should be installed, but 
it might also be a path issue?
When I do run grass, I also see this:  Unable to import pyGRASS: 
grass_gis.7.3.svn not found.   So, that might relate to 3D, or might just be a 
sign of another part of the path to dynamic library issue.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 3:48 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers grass-developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Darn!

It is as I was afraid of. Building with Anaconda wxPython means that the GUI is 
looking for the Anaconda Python distribution too. So this approach will not 
work.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=IovcDfAWhG30sZ7BGwZXrYH6f41WBK7HRKHkuPNgkrA=z7A7QhuV1iwhyXBpOAjNf8wCV1DiNMR5FhyYuyczMjQ=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=IovcDfAWhG30sZ7BGwZXrYH6f41WBK7HRKHkuPNgkrA=oqfEXF7oF6JcoKPOafzbNpJjBr9QxSgliE0Bbq6IzsA=>















On Jun 2, 2016, at 12:15 PM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I just downloaded the version on the site, and when I run it, I have the same 
problem.  wxPython is looking in the wrong place for shared libraries:

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Python 2.7.10 found.
Cleaning up temporary files...
Starting GRASS GIS...
Traceback (most recent call last):
  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 
from core import globalvar
  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 
import wx
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 
from wx._core import *
  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 
import _core_
ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: @loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib
  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so
  Reason: image not found
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
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]


-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 2:41 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Adam,

I just now uploaded a new binary to the GRASS Mac website. I built wxPython 
against the Anaconda distribution and Python against system Python. I disabled 
gettext so that it hopefully will not cause issues. This works on my system, so 
it's not a total bomb. Now to see if it works without Anaconda Python.

One thing to test is whether v.in.lidar will actually work (64bit LASlib).

Thanks again.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I just downloaded the version on the site, and when I run it, I have the same 
problem.  wxPython is looking in the wrong place for shared libraries:


Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: @loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

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

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.


[Process completed]


-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 2:41 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Adam,

I just now uploaded a new binary to the GRASS Mac website. I built wxPython 
against the Anaconda distribution and Python against system Python. I disabled 
gettext so that it hopefully will not cause issues. This works on my system, so 
it's not a total bomb. Now to see if it works without Anaconda Python.

One thing to test is whether v.in.lidar will actually work (64bit LASlib).

Thanks again.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=y-jMjjS3WhJh263Ah2U5_wE9cEgPJNKNu8jgHKEWT0A=c9sHgLYlfxX5Q3gk_OuDf1THj5sts3ScXDSIGoicYZk=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=y-jMjjS3WhJh263Ah2U5_wE9cEgPJNKNu8jgHKEWT0A=j8_8WD6umq8XpQezRjG0RNLhavbX-c2snykORzQ8-ik=>















On Jun 2, 2016, at 10:56 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

Yes, I’m happy to try it out, once you get it built.  Once you do, let me know 
if there are any specific features that would use specific libraries, so I can 
test them.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 1:53 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers grass-developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Adam,

Excellent. I’ll trudge over to the other office and do another version soon. I 
hope you can try it.

There are complications in running install_name_tool during the bundling 
process. I am working in parallel on a way to do something like that. But in 
the meantime, a lot of problems could be avoided if I can build GRASS against 
dependencies that are compiled outside the system folders (/usr/..). I’ve done 
that with LASlib and it caused you no problems. I’ve been able to build gettext 
outside of the system area but GRASS can’t find it so far. In this build, I 
tried packaging the relevant gettext libraries with GRASS, but it still looks 
for them in /usr/local. I was afraid of that but though

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

Yes, I’m happy to try it out, once you get it built.  Once you do, let me know 
if there are any specific features that would use specific libraries, so I can 
test them.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 1:53 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers grass-developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Adam,

Excellent. I’ll trudge over to the other office and do another version soon. I 
hope you can try it.

There are complications in running install_name_tool during the bundling 
process. I am working in parallel on a way to do something like that. But in 
the meantime, a lot of problems could be avoided if I can build GRASS against 
dependencies that are compiled outside the system folders (/usr/..). I’ve done 
that with LASlib and it caused you no problems. I’ve been able to build gettext 
outside of the system area but GRASS can’t find it so far. In this build, I 
tried packaging the relevant gettext libraries with GRASS, but it still looks 
for them in /usr/local. I was afraid of that but thought I’d try that. I don’t 
want to build wxPython from scratch, but can get the right version in the 
Anaconda package. I will now try to build GRASS against that version. What I 
don’t know is whether it will then complain if you don’t also have the Anaconda 
Python 2.7. We’ll see.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=0ZNWuvxDctpCtAIkbJv2o2RO_0FkffPars5lM4Q5v8Q=LyM5xdK-7R3OuZiARY5oTW8Mwe9AhKs7nY_os92kjMc=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=0ZNWuvxDctpCtAIkbJv2o2RO_0FkffPars5lM4Q5v8Q=86KUh3vJ1XFUeWMNXRzyQW-RRCGLRXE5bTL0rPYeunM=>















On Jun 2, 2016, at 10:12 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I don’t have Anaconda installed.

An option would be to put the commands that I sent into whatever build script 
you are using.  The changes that are made by install_name_tool can be made to 
the dozen or so files and then you could package it up to the installer.
The only problems, I have seen and fixed are with the paths to 
libwx_osx_cocoau-3.0.0.2.0.dylib and libintl.8.dylib

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 12:17 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Thanks Adam,

This is disappointing but informative. Do you have the Anaconda Python package 
installed? I am hoping you do not so I can test another alternative too.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMFAg=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=TS6ZbfcSESNcquxh-zPAqGnCaZgzRAIcMTujuqBSCWM=7ErhRu9AyP2KPJO1ugPquhJlYakqzc-hPP7lsh8d6Gk=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMFAg=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=TS6ZbfcSESNcquxh-zPAqGnCaZgzRAIcMTujuqBSCWM=ptMCJeZkpJL1oa3gUPm17Bx8T8MVCyXPhupTp0i2lk0=>















On Jun 2, 2016, at 8:19 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I used install_name_tool to change the path that the files use to find dynamic 
libraries.  Th

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I don’t have Anaconda installed.

An option would be to put the commands that I sent into whatever build script 
you are using.  The changes that are made by install_name_tool can be made to 
the dozen or so files and then you could package it up to the installer.
The only problems, I have seen and fixed are with the paths to 
libwx_osx_cocoau-3.0.0.2.0.dylib and libintl.8.dylib

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 12:17 PM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, GRASS users 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Thanks Adam,

This is disappointing but informative. Do you have the Anaconda Python package 
installed? I am hoping you do not so I can test another alternative too.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMFAg=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=TS6ZbfcSESNcquxh-zPAqGnCaZgzRAIcMTujuqBSCWM=7ErhRu9AyP2KPJO1ugPquhJlYakqzc-hPP7lsh8d6Gk=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMFAg=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=TS6ZbfcSESNcquxh-zPAqGnCaZgzRAIcMTujuqBSCWM=ptMCJeZkpJL1oa3gUPm17Bx8T8MVCyXPhupTp0i2lk0=>















On Jun 2, 2016, at 8:19 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

I used install_name_tool to change the path that the files use to find dynamic 
libraries.  The actual specific command I used are my later emails.
For example here is one:
install_name_tool -change /usr/local/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib


The issue is that this library:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib  was 
trying to dynamically link to this:  /usr/local/lib/libintl.8.dylib  (which 
doest exist on my system, but probably does on yours) instead it should have 
been using this:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib (which had been 
correctly installed on my system by the installer).

Each of the other commands that I sent showed that a number of other libraries 
were each looking for this:  
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib when the correct path 
is this:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
 (again, on your machine, both might exist from when you were building).

Each of these paths is hard coded into the binaries at build time, so there is 
some flag that can generally be used to set them correctly.  All I did was 
changed them using using install_name_tool which is a bit of a kludge.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 11:06 AM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers list 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Thanks for the report Adam. When you say you fixed the path, what exactly did 
you do?

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

...Sent from my iPad

On Jun 2, 2016, at 6:54 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

Looks like you missed a library, or path.  I just tried it on 10.11 with SIP 
enabled, and I get this error:

$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Python 2.7.10 found.
Cleaning up temporary files...
Starting GRASS GIS...
dyld: Library not loaded: /usr/local/lib/libintl.8.dylib
  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib
  Reason: image not found
Traceback (most recent call last):
  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gi

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

I used install_name_tool to change the path that the files use to find dynamic 
libraries.  The actual specific command I used are my later emails.
For example here is one:
install_name_tool -change /usr/local/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib


The issue is that this library:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib  was 
trying to dynamically link to this:  /usr/local/lib/libintl.8.dylib  (which 
doest exist on my system, but probably does on yours) instead it should have 
been using this:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib (which had been 
correctly installed on my system by the installer).

Each of the other commands that I sent showed that a number of other libraries 
were each looking for this:  
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib when the correct path 
is this:  
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
 (again, on your machine, both might exist from when you were building).

Each of these paths is hard coded into the binaries at build time, so there is 
some flag that can generally be used to set them correctly.  All I did was 
changed them using using install_name_tool which is a bit of a kludge.

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Thursday, June 2, 2016 at 11:06 AM
To: Adam Dershowitz <adershow...@exponent.com<mailto:adershow...@exponent.com>>
Cc: GRASS developers list 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Thanks for the report Adam. When you say you fixed the path, what exactly did 
you do?

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

...Sent from my iPad

On Jun 2, 2016, at 6:54 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:

Looks like you missed a library, or path.  I just tried it on 10.11 with SIP 
enabled, and I get this error:


$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

dyld: Library not loaded: /usr/local/lib/libintl.8.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib

  Reason: image not found

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 29, in 

from core.debug import Debug

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 77, in 

Debug = DebugMsg()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 39, in __init__

self.SetLevel()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 45, in SetLevel

self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 458, in read_command

process = pipe_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 433, in pipe_command

return start_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 372, in start_command

if debug_level() > 0:

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 1536, in debug_level

_debug_level = int(gisenv().get('DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 461, in read_command

return handle_errors(returncode, stdout, args, kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 329, in handle_errors

returncode=returncode)

grass.exceptions.CalledModuleError: Module run None ['g.gisenv', '-n'] ended 
with error

Process ended with non-zero return code 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

There were a bunch of other paths I had to fix as well.  But, after doing the 
following, it does now run with the gui:


$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gdi_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_windows_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_controls_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_misc_.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_combo.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_aui.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_html.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_gizmos.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_stc.so

$ install_name_tool -change 
@loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libwx_osx_cocoau-3.0.0.2.0.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_wizard.so

In addition to the prior fix:

install_name_tool -change /usr/local/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn



I opened and displayed a single mapset, so I haven’t tested most other 
features, but it does now seem to run with SIP enabled.  So, it looks like you 
just missed the correct paths in the build to a few dynamic libraries that you 
have correctly included.


Thanks much for getting this going.



-- Adam


From: grass-user 
<grass-user-boun...@lists.osgeo.org<mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>
Date: Thursday, June 2, 2016 at 10:06 AM
To: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>, 
GRASS developers list 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

And, I tried fixing that one path like this:


install_name_tool -change /usr/local/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib



but then I get this dynamic library error:


$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Appl

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

And, I tried fixing that one path like this:


install_name_tool -change /usr/local/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libintl.8.dylib 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib



but then I get this dynamic library error:


$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 96, in 

import wx

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: @loader_path/../../../../libwx_osx_cocoau-3.0.0.2.0.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

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

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.


[Process completed]


-- Adam


From: Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>
Date: Thursday, June 2, 2016 at 9:54 AM
To: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>, 
GRASS developers list 
<grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org>>, grass-user 
grass-user <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

Looks like you missed a library, or path.  I just tried it on 10.11 with SIP 
enabled, and I get this error:


$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

dyld: Library not loaded: /usr/local/lib/libintl.8.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib

  Reason: image not found

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 29, in 

from core.debug import Debug

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 77, in 

Debug = DebugMsg()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 39, in __init__

self.SetLevel()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 45, in SetLevel

self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 458, in read_command

process = pipe_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 433, in pipe_command

return start_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 372, in start_command

if debug_level() > 0:

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 1536, in debug_level

_debug_level = int(gisenv().get('DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 461, in read_command

return handle_errors(returncode, stdout, args, kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 329, in handle_errors

returncode=returncode)

grass.exceptions.CalledModuleError: Module run None ['g.gisenv', '-n'] ended 

Re: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP problem - please test

[Adam Dershowitz]

Looks like you missed a library, or path.  I just tried it on 10.11 with SIP 
enabled, and I get this error:


$ '/Applications/GRASS-7.3.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

dyld: Library not loaded: /usr/local/lib/libintl.8.dylib

  Referenced from: 
/Applications/GRASS-7.3.app/Contents/MacOS/lib/libgrass_gis.7.3.svn.dylib

  Reason: image not found

Traceback (most recent call last):

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 29, in 

from core.debug import Debug

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 77, in 

Debug = DebugMsg()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 39, in __init__

self.SetLevel()

  File "/Applications/GRASS-7.3.app/Contents/MacOS/gui/wxpython/core/debug.py", 
line 45, in SetLevel

self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 458, in read_command

process = pipe_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 433, in pipe_command

return start_command(*args, **kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 372, in start_command

if debug_level() > 0:

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 1536, in debug_level

_debug_level = int(gisenv().get('DEBUG', 0))

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 953, in gisenv

s = read_command("g.gisenv", flags='n')

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 461, in read_command

return handle_errors(returncode, stdout, args, kwargs)

  File 
"/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/grass/script/core.py", 
line 329, in handle_errors

returncode=returncode)

grass.exceptions.CalledModuleError: Module run None ['g.gisenv', '-n'] ended 
with error

Process ended with non-zero return code -5. 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

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.




-- Adam


From: grass-user 
> 
on behalf of Michael Barton 
>
Date: Wednesday, June 1, 2016 at 7:50 PM
To: GRASS developers list 
>, grass-user 
grass-user >
Subject: [GRASS-user] GRASS for Mac 64bit, wxPython 3, maybe fix for SIP 
problem - please test

I just posted a new binary for GRASS 7.3 built fully 64 bit, with wxPython 
3.0.2.0 to the GRASS for Mac site 
(http://grassmac.wikidot.com)

It turns out the previous "64bit" GRASS binary still ran 32bit Python. I had to 
hack the python_wrapper.py file, but this one is fully 64bit AFAICT. I also 
tried some hacks that might be a way to solve the inability to run GRASS on El 
Capitan with SIP enabled. There are a couple of known bugs in the wxPython 3.x 
GUI

1. The most serious is switching to 3D mode and back to 2D mode leaves one of 
the map display menu buttons corrupted. It seems the only thing you can do is 
to close the map display and open a new one.

2. There are also some popup lists (e.g., for switching mapsets) that do not 
behave as they should. You cannot select an item with a mouse (but you can 
select with arrow keys and ) unless you hit  to destroy part of 
the control. Then you can use the mouse to click something.

Please let us know if you encounter any other bug or strange behavior.

Also,  and importantly if anyone is running El Capitan, it would be great if 
you could reenable SIP (if you've turned it off) and see if this version runs.  
Of course, maybe I've 

Re: [GRASS-user] GRASS GIS 7.0.4 released

[Adam Dershowitz]

Has there been any progress getting GRASS to run on the current Mac OS?  I know 
that there was some work going on, and that there is a 7.0.4 Mac binary now, 
but the web page still indicates a problem with OS 10.11.x

Thanks,

-- Adam


From: grass-user 
> 
on behalf of Markus Neteler >
Date: Tuesday, May 3, 2016 at 3:23 AM
To: GRASS-announce list 
>
Cc: GRASS user list 
>, OSGeo-discuss 
>, 
"freegis-l...@intevation.de" 
>, GRASS 
developers list >, 
"geowank...@lists.burri.to" 
>
Subject: [GRASS-user] GRASS GIS 7.0.4 released

We are pleased to announce the new stable release of GRASS GIS 7.0.4

[GRASS GIS 7.0.4 
released!]

[GRASS GIS 7.0.4 
released!]



What's new in a nutshell

The new GRASS GIS 7.0.4 release provides 150 stability fixes and manual 
improvements compared to 7.0.3.

About GRASS GIS 7: Its graphical user interface supports the user to make 
complex GIS operations as simple as possible. The updated Python interface to 
the C 
library
 permits users to create new GRASS GIS-Python modules in a simple way while yet 
obtaining powerful and fast modules. Furthermore, the libraries were 
significantly improved for speed and efficiency, along with support for huge 
files.
 A lot of effort has been invested to standardize parameter and flag names. 
Finally, GRASS GIS 7 comes with a series of new modules to analyse raster and 
vector data, along with a full temporal framework. For a detailed overview, see 
the list of new 
features.
 As a stable release series, 7.0.x enjoys long-term support.

Binaries/Installer download:

  *   winGRASS 7.0.4: 32bit standalone 
installer
 | 64bit standalone 
installer
  *   winGRASS 7.0.4 OSGeo4W - testing area: 32bit OSGeo4W 
installer
 | 64bit OSGeo4W 
installer
  *   Arch 

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

On 3/16/16, 6:24 AM, "Rainer M Krug" <rai...@krugs.de> wrote:

>Rainer M Krug <rai...@krugs.de> writes:
>
>> Adam Dershowitz <adershow...@exponent.com> writes:
>>
>>> Got it.  Now, based on that, I have found it.  Apparently, it is for
>>> protected processes:
>>>
>>> 
>>>https://developer.apple.com/library/mac/documentation/Security/Conceptua
>>>l/S
>>> 
>>>ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.h
>>>tml
>>>
>>
>> Which seems to be the reason why during the make step (make is in
>> /usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
>> ignored.
>>
>> But when running GRASS, it should work.
>>
>> Has anybody tried out to
>>
>> 1) disable SIP
>> 2) compile GRASS from source
>> 3) install GRASS
>> 4) enable SIP
>>
>> and does it run?
>
>
>Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
>affects the compilation / installation of GRASS.


Based on what you tried above I decided to try a different test:  I just
disabled SIP, installed GRASS (from binaries), and then reenabled SIP and
found that it doesn’t work.  So, the details of your compilation must be
different from that of the provided binaries.  Yours are probably set for
just your computer (32/64 bit, OS version etc) while the binaries try to
work for everyone so make some of that determination at startup time.



>
>
>>
>> Do you know if Macports uses an own make (and possibly other tools?), or
>> the one supplied by OS X?


I think that the answer is that by default macport uses the Apple provided
make, but specific ports can require other ports as dependencies.  And
those can include things like gmake etc.  So, some ports do require
non-Apple versions….
That said, the grass7 port lists:

Build Dependencies:   pkgconfig
Library Dependencies: freetype, fftw-3, gdal, geos, tiff, libpng, proj,
cairo, readline, python27, py27-pillow, wxPython-3.0,
  py27-wxPython-3.0


While any of those could then require other ports, they look pretty
standard, so likely just use Apple supplied make.

But, I am not completely sure that about other make tools that macports
could use, but I think that the above is correct.

>>
>>
>>> So, would it be possible to just just the paths that are used for the
>>> search paths in the Application bundle itself?
>>>
>>> -- Adam
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 3/15/16, 4:43 PM, "William Kyngesburye" <wokl...@kyngchaos.com>
>>>wrote:
>>>
>>>>GRASS does not write to those SIP-restricted locations.
>>>>
>>>>From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH,
>>>>no
>>>>matter where it points to.  And the errors that have been reported
>>>>point
>>>>to it as well.
>>>>
>>>>> On Mar 15, 2016, at 3:06 PM, Adam Dershowitz
>>>>><adershow...@exponent.com>
>>>>>wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>>>>> <grass-user-boun...@lists.osgeo.org on behalf of
>>>>>wokl...@kyngchaos.com>
>>>>> wrote:
>>>>> 
>>>>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug <rai...@krugs.de> wrote:
>>>>>>> 
>>>>>>> William Kyngesburye <wokl...@kyngchaos.com> writes:
>>>>>>> 
>>>>>>>> This is also a known issue, related to but separate from the
>>>>>>>>packaging
>>>>>>>> issue.  During compilation, GRASS also uses DYLD_LIBRARY_PATH to
>>>>>>>>find
>>>>>>>> the in-compilation copies of the libraries so it can run the
>>>>>>>>modules
>>>>>>>> to create the help files.
>>>>>>> 
>>>>>>> OK - this aligns with what I guessed from the error messages.
>>>>>>> 
>>>>>>> So the  DYLD_LIBRARY_PATH is only used during compilation - and not
>>>>>>> during execution, even without "make install"?
>>>>>>> 
>>>>>> No, DYLD_LIBRARY_PATH is also used during execution, that's what's
>>>>>> causing trouble in the app bundling.
>>>>>> 
>>>>>>

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

On 3/16/16, 9:03 AM, "Michael Barton" <michael.bar...@asu.edu> wrote:

>I've held off updating to make sure I could continue to provide binaries
>for the GRASS community. If you are right, I will upgrade one of my
>computers to the new OS and try this. SIP off and compile.


I hope that will work. But, I did just try to install your binaries
without SIP, then reenabled and it failed to run.  Hopefully, your rebuild
will fix it.  
FYI, I do really appreciate that you provide the binaries!  Thank you.

> 
>
>
>
>The question then is whether users need to turn SIP off to install in the
>normal applications folder.


No, they don’t.  The vast majority of applications have not had any
problems transitioning to SIP.  The only exceptions that I have heard of
having any problems are an application that tries to do some low-level
finder stuff (so it actually could be considered a real security risk) and
GRASS.  Although, my sampling is far from complete!


>
>
>
>Michael
>
>
>
>C. Michael Barton
>
>Director, Center for Social Dynamics & Complexity
>
>Professor of Anthropology, School of Human Evolution & Social Change
>
>Head, Graduate Faculty in Complex Adaptive Systems Science
>
>Arizona State University
>
>
>
>voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>www: 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7E
>cmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28T
>aiOmWcn6rCn8wM=8a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs=brH8l8fvJcn
>BOtKN-Iit46NVfqgp0TIE-1AzhSS-BOs= ,
>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwIGaQ;
>c=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=8
>a8vJwN3CLQA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs=4QJPzCYG_0w7Wr4CmDr_AQ1GzmaYY
>SRUHhN3ywKiNnk= 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On Mar 16, 2016, at 12:24 PM, Rainer M Krug <rai...@krugs.de> wrote:
>
>> 
>
>> Rainer M Krug <rai...@krugs.de> writes:
>
>> 
>
>>> Adam Dershowitz <adershow...@exponent.com> writes:
>
>>> 
>
>>>> Got it.  Now, based on that, I have found it.  Apparently, it is for
>
>>>> protected processes:
>
>>>> 
>
>>>> 
>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.co
>>>>m_library_mac_documentation_Security_Conceptual_S=CwIGaQ=t0wRGL5ICV
>>>>zH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=8a8vJwN3CL
>>>>QA76SAkEtMdsfp_z-HB2Vqa_5GDDVCFJs=lpyQ9k04zOgM7WEr5IuYKSvzyOXTxIPvKFF
>>>>p5HLGOCU= 
>
>>>> 
>>>>ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.
>>>>html
>
>>>> 
>
>>> 
>
>>> Which seems to be the reason why during the make step (make is in
>
>>> /usr/bin, therefore a protected binary), the DYLD_LIBRARY_PATH is
>
>>> ignored.
>
>>> 
>
>>> But when running GRASS, it should work.
>
>>> 
>
>>> Has anybody tried out to
>
>>> 
>
>>> 1) disable SIP
>
>>> 2) compile GRASS from source
>
>>> 3) install GRASS
>
>>> 4) enable SIP
>
>>> 
>
>>> and does it run?
>
>> 
>
>> 
>
>> Just tried it out, ant it works. So the DYLD_LIBRARY_PATH issue only
>
>> affects the compilation / installation of GRASS.
>
>> 
>
>> 
>
>>> 
>
>>> Do you know if Macports uses an own make (and possibly other tools?),
>>>or
>
>>> the one supplied by OS X?
>
>>> 
>
>>> 
>
>>>> So, would it be possible to just just the paths that are used for the
>
>>>> search paths in the Application bundle itself?
>
>>>> 
>
>>>> -- Adam
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> 
>
>>>> On 3/15/16, 4:43 PM, "William Kyngesburye" <wokl...@kyngchaos.com>
>>>>wrote:
>
>>>> 
>
>>>>> GRASS does not write to those SIP-restricted locations.
>
>>>>> 
>
>>>>> From what I've read, SIP also causes apps to ignore
>>>>>DYLD_LIBRARY_PATH, no
>
>>>>> matter where it points to.  And the errors that have been reported
>>>>

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

Got it.  Now, based on that, I have found it.  Apparently, it is for
protected processes:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/S
ystem_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

So, would it be possible to just just the paths that are used for the
search paths in the Application bundle itself?

-- Adam






On 3/15/16, 4:43 PM, "William Kyngesburye" <wokl...@kyngchaos.com> wrote:

>GRASS does not write to those SIP-restricted locations.
>
>From what I've read, SIP also causes apps to ignore DYLD_LIBRARY_PATH, no
>matter where it points to.  And the errors that have been reported point
>to it as well.
>
>> On Mar 15, 2016, at 3:06 PM, Adam Dershowitz <adershow...@exponent.com>
>>wrote:
>> 
>> 
>> 
>> 
>> 
>> On 3/15/16, 3:37 PM, "grass-user on behalf of William Kyngesburye"
>> <grass-user-boun...@lists.osgeo.org on behalf of wokl...@kyngchaos.com>
>> wrote:
>> 
>>> On Mar 15, 2016, at 2:05 PM, Rainer M Krug <rai...@krugs.de> wrote:
>>>> 
>>>> William Kyngesburye <wokl...@kyngchaos.com> writes:
>>>> 
>>>>> This is also a known issue, related to but separate from the
>>>>>packaging
>>>>> issue.  During compilation, GRASS also uses DYLD_LIBRARY_PATH to find
>>>>> the in-compilation copies of the libraries so it can run the modules
>>>>> to create the help files.
>>>> 
>>>> OK - this aligns with what I guessed from the error messages.
>>>> 
>>>> So the  DYLD_LIBRARY_PATH is only used during compilation - and not
>>>> during execution, even without "make install"?
>>>> 
>>> No, DYLD_LIBRARY_PATH is also used during execution, that's what's
>>> causing trouble in the app bundling.
>>> 
>>>>> 
>>>>> The packaging issue with DYLD_LIBRARY_PATH can be fixed in packaging
>>>>> so that everything within the GRASS app package looks directly inside
>>>>> the package for libraries and not rely on DYLD_LIBRARY_PATH.
>>>>> Homebrew, Macports and /usr/local builds don't need to worry about it
>>>>> because the extra dependencies that are bundled in the app are
>>>>>already
>>>>> in their proper place.
>>>> 
>>>> OK - so in homebrew (I can't speak for Macports) the issue is at the
>>>> moment only the one you discuss below.
>>>> 
>>>>> 
>>>>> The compilation issue needs work to compile all libraries with the
>>>>> temporary path inside the libraries and modules (this part is easy)
>>>>>so
>>>>> that during compilation help file generation works.
>>>> 
>>>> OK - so can you give me any suggestions how I can solve this to make
>>>> GRASS at least compile on homebrew?
>>>> 
>>>> Speaking generally - is this really the right approach to take, i.e.
>>>>use
>>>> the generated binaries to generate the help files during installation?
>>>> Wouldn't it be much easier to do this during installation?
>>>> 
>>> Well, the compilation approach is how it's been done as long as I can
>>> remember, it's nothing specific to OS X.  Changing this would be major.
>>> 
>>>>> And then during installation change all the embedded library paths to
>>>>> the final destination (this is harder, to figure out the complex
>>>>> makefile include system of GRASS to get this operation in the right
>>>>> place).
>>>> 
>>>> The paths are in the grass script file? Or in others as well?
>>>> 
>>> No, the paths are embedded in the libraries and binary executables.
>>> 
>>>> Wouldn't it make sense to
>>>> 
>>>> 1) split the generation of the help files from the build step into a
>>>> separate make target
>>>> 2) call the make target for help pages as a last step in the install
>>>> step?
>>>> 
>>>> This might make packaging more difficult, but wouldn't it make the
>>>>whole
>>>> process clearer?
>>>> 
>>>>> Homebrew, Macports, /usr/local AND app installs do have a problem
>>>>>with
>>>>> this.
>>>> 
>>>> It worked with Yosemite without problems. So this only needs to be
>>>>done,
>>>> because of the issues you describe above?
>>&g

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

l (and me) for the "official" packages because we
>>> compile on older systems that don't have SIP.
>> 
>> Thanks for these clarifications.
>> 
>> I would very much appreciate if we could see to get the compilation and
>> installation working using homebrew so that there is at least one way of
>> t=running GRASS on El Capitan without having to interfere with the
>> security settings.
>> 
>> Thanks,
>> 
>> Rainer
>> 
>>> 
>>>> On Mar 15, 2016, at 11:39 AM, Rainer M Krug <rai...@krugs.de> wrote:
>>>> 
>>>> 
>>>> I tried again to install 7.1 head without GUI using homwbrew, and I
>>>>get
>>>> the following error:
>>>> 
>>>> ,
>>>> | bash-4.3$ less
>>>>/Users/rainerkrug/Library/Logs/Homebrew/grass-71/02.make
>>>> | bash-4.3$ cd
>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/scripts/d.rast.leg
>>>> | bash-4.3$ ls
>>>> | Makefiled.rast.leg.html d.rast.leg.py
>>>> | bash-4.3$ make
>>>> | if [
>>>> | 
>>>>"/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15
>>>>.3.0/scripts/d.rast.leg"
>>>> | != "" ] ; then
>>>> | 
>>>>GISRC=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>win15.3.0/demolocation/.grassrc71
>>>> | 
>>>>GISBASE=/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-d
>>>>arwin15.3.0
>>>> | 
>>>>PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-dar
>>>>win15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-a
>>>>pple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/dist.
>>>>x86_64-apple-darwin15.3.0/scripts:$PATH"
>>>> | 
>>>>PYTHONPATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-app
>>>>le-darwin15.3.0/etc/python:/private/tmp/grass-7120160315-47344-1ybn5ar/
>>>>dist.x86_64-apple-darwin15.3.0/gui/wxpython:$PYTHONPATH"
>>>> | 
>>>>DYLD_LIBRARY_PATH="/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86
>>>>_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-1ybn5ar/
>>>>dist.x86_64-apple-darwin15.3.0/bin:/private/tmp/grass-7120160315-47344-
>>>>1ybn5ar/dist.x86_64-apple-darwin15.3.0/scripts:/private/tmp/grass-71201
>>>>60315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:/private/tmp/gra
>>>>ss-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.3.0/lib:"
>>>> | LC_ALL=C
>>>> | 
>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
>>>>3.0/scripts/d.rast.leg
>>>> | --html-description < /dev/null | grep -v '\|' >
>>>> | d.rast.leg.tmp.html ; fi
>>>> | dyld: Library not loaded:
>>>>/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn.
>>>>dylib
>>>> |   Referenced from:
>>>> | 
>>>>/private/tmp/grass-7120160315-47344-1ybn5ar/dist.x86_64-apple-darwin15.
>>>>3.0/bin/g.parser
>>>> |   Reason: image not found
>>>> | make: *** [d.rast.leg.tmp.html] Error 1
>>>> | rm d.rast.leg.tmp.html
>>>> | bash-4.3$
>>>> `
>>>> 
>>>> In other words: grass is looking during the compilation for a dynamic
>>>> library
>>>> 
>>>>(/usr/local/Cellar/grass-71/HEAD/grass-7.1.svn/lib/libgrass_gis.7.1.svn
>>>>.dylib)
>>>> which has been created, but will only be there when installing.
>>>> 
>>>> Also important: this error only occurs when the html manual pages are
>>>> created!
>>>> 
>>>> Cheers,
>>>> 
>>>> Rainer
>>>> 
>>>> 
>>>> Rainer M Krug <rai...@krugs.de> writes:
>>>> 
>>>>> Adam Dershowitz <adershow...@exponent.com> writes:
>>>>> 
>>>>>> I use Macports for a  bunch of other things (and Homebrew is
>>>>>>incompatible
>>>>>> with Macports)   So, I figured that I would just tried to install
>>>>>>grass7
>>>>>> using macports.  It does seem to install, but the gui doesn¹t work:
>>>>>> 
>>>>>> $grass70 
>>>>>> Cleaning up temporary files...
>>>>>> Starting GRASS GIS...
>>>>>> ERROR: wxGUI requires wxPython. No module named wxversion
>>>>>> Error in GUI startup. If necessary, please report this error to the
>>>>>>GRASS
>>>>>> developers.
>>>>>> Switching to text mode now.
>>>>>> 
>>>>> 
>>>>> I don't use MacPorts - but can you try to install without GUI?
>>>>> 
>>>>>> 
>>>>>> Hit RETURN to continue...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> This is odd, since wxpython is installed.
>>>>>> But, it seems like this is a different problem.
>>>>>> 
>
>-
>William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kyngchaos.com_=C
>wIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8
>wM=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rFc=4w5wYepEPeebD54T1h_V7mJ
>Bf8t6V3mbREBfgUP8u90=
>
>"Oh, look, I seem to have fallen down a deep, dark hole.  Now what does
>that remind me of?  Ah, yes - life."
>
>- Marvin
>
>
>___
>grass-user mailing list
>grass-user@lists.osgeo.org
>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailma
>n_listinfo_grass-2Duser=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLt
>SzGmh8YEvbco28TaiOmWcn6rCn8wM=r1HkNs7RjOpSnmLwmP3Cs2L1e3PUB46Ip-W1bup-rF
>c=Wvr4pv5ar3OjaTpiOn-UaLvVb2_IFgxGgKN0IHHRSXo= 

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

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

I don’t see an option to do that.  The portfile has a few variants, but
nothing related to the gui.

-- Adam






On 3/15/16, 12:32 PM, "Rainer M Krug" <rai...@krugs.de> wrote:

>Adam Dershowitz <adershow...@exponent.com> writes:
>
>> I use Macports for a  bunch of other things (and Homebrew is
>>incompatible
>> with Macports)   So, I figured that I would just tried to install grass7
>> using macports.  It does seem to install, but the gui doesn’t work:
>>
>>  $grass70 
>> Cleaning up temporary files...
>> Starting GRASS GIS...
>> ERROR: wxGUI requires wxPython. No module named wxversion
>> Error in GUI startup. If necessary, please report this error to the
>>GRASS
>> developers.
>> Switching to text mode now.
>>
>
>I don't use MacPorts - but can you try to install without GUI?
>
>>
>> Hit RETURN to continue...
>>
>>
>>
>> This is odd, since wxpython is installed.
>> But, it seems like this is a different problem.
>>
>>
>> -- Adam
>>
>>
>>
>>
>>
>>
>> On 3/15/16, 9:50 AM, "Rainer M Krug" <rai...@krugs.de> wrote:
>>
>>>Michael Barton <michael.bar...@asu.edu> writes:
>>>
>>>> The reason is that I (and William) package some key dependencies with
>>>> the binary. The most important is wxPython, which is required by the
>>>> GUI. If a user does not have exactly the same version of wxPython used
>>>> to compile the binary, the GUI will fail. Making this more complicated
>>>> is the fact that the only versions of wxPython that work completely
>>>> correctly with Mac GRASS are 32 bit. But some other components are 64
>>>> bit. This means that I need to compile GRASS with 32/64 bit dual
>>>> architecture. So this is a consequence of making binaries that run on
>>>> anyone's Mac (except the newest system with SIP enabled).
>>>
>>>OK - so if I understand you correctly, installing via homebrew, should
>>>not be that difficult, as GRASS is compiled for a specific wxPython -
>>>correct?
>>>
>>>
>>>
>>>>
>>>> Michael
>>>> 
>>>> C. Michael Barton
>>>> Director, Center for Social Dynamics & Complexity
>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>>> Arizona State University
>>>>
>>>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>
>>>> On Mar 15, 2016, at 3:14 PM, Carlos Grohmann
>>>> <carlos.grohm...@gmail.com> wrote:
>>>>
>>>> 
>>>> 
>>>> I run GRASS on OSX El Capitan (with SIP disabled). I don't think
>>>> that setting up a CLI-only version would be a solution as well. As
>>>> Rainer said, other software runs natively (see QGIS) and they
>>>> don't have any problems with OSX/SIP. We should look into that.
>>>> 
>>>> 
>>>> I don't understand why GRASS is offending SIP. Perhaps we should
>>>> seek out for help from others. Maybe Apple itself.
>>>> 
>>>> 
>>>> One point is that we need to disable SIP for the binary provided
>>>> by Michael Barton, but not if you compile it from source (or using
>>>> homebrew), so this could be fixable by changing paths, like Adam
>>>> suggested. Homebrew uses /usr/local, why can't we?
>>>> 
>>>> 
>>>> best
>>>> 
>>>> 
>>>> Carlos
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
>>>> <adershow...@exponent.com> wrote:
>>>> 
>>>> Yes, SIP is a new security feature that prevents any applications
>>>> from
>>>> writing to a few key OS paths. I believe that it really is
>>>> that simple.
>>>> (see: https://support.apple.com/en-us/HT204899 )
>>>> Which, does beg the questionŠwhy does running GRASS require

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

I use Macports for a  bunch of other things (and Homebrew is incompatible
with Macports)   So, I figured that I would just tried to install grass7
using macports.  It does seem to install, but the gui doesn’t work:

 $grass70 
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
Error in GUI startup. If necessary, please report this error to the GRASS
developers.
Switching to text mode now.


Hit RETURN to continue...



This is odd, since wxpython is installed.
But, it seems like this is a different problem.


-- Adam






On 3/15/16, 9:50 AM, "Rainer M Krug" <rai...@krugs.de> wrote:

>Michael Barton <michael.bar...@asu.edu> writes:
>
>> The reason is that I (and William) package some key dependencies with
>> the binary. The most important is wxPython, which is required by the
>> GUI. If a user does not have exactly the same version of wxPython used
>> to compile the binary, the GUI will fail. Making this more complicated
>> is the fact that the only versions of wxPython that work completely
>> correctly with Mac GRASS are 32 bit. But some other components are 64
>> bit. This means that I need to compile GRASS with 32/64 bit dual
>> architecture. So this is a consequence of making binaries that run on
>> anyone's Mac (except the newest system with SIP enabled).
>
>OK - so if I understand you correctly, installing via homebrew, should
>not be that difficult, as GRASS is compiled for a specific wxPython -
>correct?
>
>
>
>>
>> Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>>
>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>> On Mar 15, 2016, at 3:14 PM, Carlos Grohmann
>> <carlos.grohm...@gmail.com> wrote:
>>
>> 
>> 
>> I run GRASS on OSX El Capitan (with SIP disabled). I don't think
>> that setting up a CLI-only version would be a solution as well. As
>> Rainer said, other software runs natively (see QGIS) and they
>> don't have any problems with OSX/SIP. We should look into that.
>> 
>> 
>> I don't understand why GRASS is offending SIP. Perhaps we should
>> seek out for help from others. Maybe Apple itself.
>> 
>> 
>> One point is that we need to disable SIP for the binary provided
>> by Michael Barton, but not if you compile it from source (or using
>> homebrew), so this could be fixable by changing paths, like Adam
>> suggested. Homebrew uses /usr/local, why can't we?
>> 
>> 
>> best
>> 
>> 
>> Carlos
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz
>> <adershow...@exponent.com> wrote:
>> 
>> Yes, SIP is a new security feature that prevents any applications
>> from
>> writing to a few key OS paths. I believe that it really is
>> that simple.
>> (see: https://support.apple.com/en-us/HT204899 )
>> Which, does beg the questionŠwhy does running GRASS require
>> writes to any
>> of these folders? That suggests that GRASS is doing something
>> that it
>> shouldn¹t be doing. Why should it be writing to system folders
>> at all at
>> runtime?
>> It is the only application that I have run into that has any
>> problems with
>> SIP. It would seem that this should be an easy fix. (for
>> example just
>> use /usr/local instead of /usr, or whatever the problem folder
>> is).
>> 
>> 
>> -- Adam
>> 
>> 
>>
>> 
>> 
>> -- 
>> 
>> 
>> 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/-0001-5073-5572
>> 
>> 
>> Can’t stop the signal.
>>
>>
>
>-- 
>Rainer M. Krug
>email: Rainerkrugsde
>PGP: 0x0F52F982

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

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

I don’t understand why that should matter.  It Is great that it is packaged 
with the whole combination to run in different configurations.  But, does GRASS 
then write to /usr at runtime?  Can’t it just run the correct library from in 
the Application package?
Or is there something about SIP beyond protection against writing to a few key 
folders?
Just to be clear, I’m not trying to be the last bit accusatory, but I’m just 
curious about understanding the problem.  If all of the correct included 
versions of libraries are included in the application package, then the issue 
should just be about pointing to the correct dynamic libraries.  Why should SIP 
care about that at all?

-- Adam


From: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Tuesday, March 15, 2016 at 9:36 AM
To: Carlos Guâno Grohmann 
<carlos.grohm...@gmail.com<mailto:carlos.grohm...@gmail.com>>
Cc: Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>, Rainer M Krug 
<rai...@krugs.de<mailto:rai...@krugs.de>>, grass-user grass-user 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>, William 
Kyngesburye <kyngch...@kyngchaos.com<mailto:kyngch...@kyngchaos.com>>, Anna 
Petrášová <kratocha...@gmail.com<mailto:kratocha...@gmail.com>>
Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The reason is that I (and William) package some key dependencies with the 
binary. The most important is wxPython, which is required by the GUI. If a user 
does not have exactly the same version of wxPython used to compile the binary, 
the GUI will fail. Making this more complicated is the fact that the only 
versions of wxPython that work completely correctly with Mac GRASS are 32 bit. 
But some other components are 64 bit. This means that I need to compile GRASS 
with 32/64 bit dual architecture. So this is a consequence of making binaries 
that run on anyone's Mac (except the newest system with SIP enabled).

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas=OOfq3SrregbqJyJJsSRq_KnX6v97McV_ZatMot9KoUo=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas=aW2Qzkj3CbpJ_WG702f-HFbsFcbHaDAMFuOnfIPKnto=>















On Mar 15, 2016, at 3:14 PM, Carlos Grohmann 
<carlos.grohm...@gmail.com<mailto:carlos.grohm...@gmail.com>> wrote:

I run GRASS on OSX El Capitan (with SIP disabled). I don't think that setting 
up a CLI-only version would be a solution as well. As Rainer said, other 
software runs natively (see QGIS) and they don't have any problems with 
OSX/SIP. We should look into that.

I don't understand why GRASS is offending SIP. Perhaps we should seek out for 
help from others. Maybe Apple itself.

One point is that we need to disable SIP for the binary provided by Michael 
Barton, but not if you compile it from source (or using homebrew), so this 
could be fixable by changing paths, like Adam suggested. Homebrew uses 
/usr/local, why can't we?

best

Carlos



On Tue, Mar 15, 2016 at 9:51 AM, Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>> wrote:
Yes, SIP is a new security feature that prevents any applications from
writing to a few key OS paths.  I believe that it really is that simple.
(see:  
https://support.apple.com/en-us/HT204899<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.apple.com_en-2Dus_HT204899=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=N34HRpJ-bC99jAGZ6tcCUmsLYWp4ag3ao63cVcQxtas=a-oC6gCKpo7blZOUSNUaANduhi07GUVwoFKvZ6jYnoI=>
 )
Which, does beg the questionŠwhy does running GRASS require writes to any
of these folders?  That suggests that GRASS is doing something that it
shouldn¹t be doing.  Why should it be writing to system folders at all at
runtime?
It is the only application that I have run into that has any problems with
SIP.  It would seem that this should be an easy fix.  (for example just
use /usr/local instead of /usr, or whatever the problem folder is).


-- Adam


--
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sens

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

Yes, SIP is a new security feature that prevents any applications from
writing to a few key OS paths.  I believe that it really is that simple.
(see:  https://support.apple.com/en-us/HT204899 )
Which, does beg the questionŠwhy does running GRASS require writes to any
of these folders?  That suggests that GRASS is doing something that it
shouldn¹t be doing.  Why should it be writing to system folders at all at
runtime?
It is the only application that I have run into that has any problems with
SIP.  It would seem that this should be an easy fix.  (for example just
use /usr/local instead of /usr, or whatever the problem folder is).


-- Adam






On 3/15/16, 5:20 AM, "Michael Barton" <michael.bar...@asu.edu> wrote:

>After this problem was discovered 4-6 months ago, we've been working on a
>way to remedy it. We have a basic plan that William has suggested, but it
>takes some time to work out how to implement it. So far, no one has had
>the time needed to do this. It seems solvable with some effort.
>
>
>
>My understanding is that SIP is a new security feature. Disabling it
>leaves the Mac at the same level of security it has under Yosemite.
>
>
>
>Michael
>
>
>
>C. Michael Barton
>
>Director, Center for Social Dynamics & Complexity
>
>Professor of Anthropology, School of Human Evolution & Social Change
>
>Head, Graduate Faculty in Complex Adaptive Systems Science
>
>Arizona State University
>
>
>
>voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
>fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>
>www: 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7E
>cmbarton=CwIGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28T
>aiOmWcn6rCn8wM=Du-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks=BMSNf4uJ_w2
>ewwUgMTyEGQGU5wecIjrAaBpBY-3ebyA= ,
>https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwIGaQ;
>c=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=D
>u-iDnFBgCWnlt2qQbjsC_YSg06yHml6QRl_8z3v6Ks=nYM20vxBK7g_tQPNjML5LWX-szqTa
>83D4p5P1fuat1o= 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> On Mar 15, 2016, at 11:00 AM, Rainer M Krug <rai...@krugs.de> wrote:
>
>> 
>
>> Adam Dershowitz <adershow...@exponent.com> writes:
>
>> 
>
>>> So it looks like this is actually the known problem with System
>
>>> Integrity Protection. I hate to turn off a security feature, and do
>
>>> two reboots, to be able to run a single application. Has there been
>
>>> any progress in getting this fixed?
>
>> 
>
>> No - I have the feeling that the ones using GRASS on OS X are still
>
>> avoiding upgrading to El Capitan, and the ones who have are out in the
>
>> cold. I raised the issue several times already.
>
>> 
>
>> I slowly really think the best would be to abandon GRASS on OS X and
>
>> focus on setting up an official docker image which can be used on OS X,
>
>> Windows and Linux.
>
>> 
>
>> Please convince me otherwise.
>
>> 
>
>> Cheers,
>
>> 
>
>> Rainer
>
>> 
>
>>> 
>
>>> Thanks,
>
>>> 
>
>>> -- Adam
>
>>> 
>
>>> From: Adam Dershowitz <adershow...@exponent.com>
>
>>> Date: Monday, March 14, 2016 at 11:21 PM
>
>>> To: Michael Barton <michael.bar...@asu.edu>, grass-user grass-user
>
>>> <grass-user@lists.osgeo.org>
>
>>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>
>>> wxPython (missing)
>
>>> 
>
>>> And, I just tried to run 6.4, which I still had installed, and it also
>
>>> won¹t run, but with a different error:
>
>>> 
>
>>> Python 2.7.10 found.
>
>>> 
>
>>> Cleaning up temporary files ...
>
>>> 
>
>>> Starting GRASS ...
>
>>> 
>
>>> Traceback (most recent call last):
>
>>> 
>
>>> File
>
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>
>>> line 37, in 
>
>>> 
>
>>> from core import globalvar
>
>>> 
>
>>> File
>
>>> 
>>>"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.
>>>py",
>
>>> line 74, in 
>
>>> 
>
>>> import wx
>
>>> 
>
>>> File
>
>>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__ini

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

If people are avoiding a useful system upgrade because of a single
application, that indicates that the application is important.
One of the great things about GRASS is that it runs cross platform.  It
would be a big shame to give that up.  I hope that the project can move
forward to keep Mac OS support.
I¹ve never used docker, but was just checking up on, and it doesn¹t appear
to be free, nor does it appear to work on Macs.  I could be wrong about
either, but GRASS runs natively so well, that there really should not be a
need to give that up.  I believe the one of the reasons for the shift to
wxpython, years ago, was to keep cross platform support.

-- Adam






On 3/15/16, 5:00 AM, "Rainer M Krug" <rai...@krugs.de> wrote:

>Adam Dershowitz <adershow...@exponent.com> writes:
>
>> So it looks like this is actually the known problem with System
>> Integrity Protection. I hate to turn off a security feature, and do
>> two reboots, to be able to run a single application. Has there been
>> any progress in getting this fixed?
>
>No - I have the feeling that the ones using GRASS on OS X are still
>avoiding upgrading to El Capitan, and the ones who have are out in the
>cold. I raised the issue several times already.
>
>I slowly really think the best would be to abandon GRASS on OS X and
>focus on setting up an official docker image which can be used on OS X,
>Windows and Linux.
>
>Please convince me otherwise.
>
>Cheers,
>
>Rainer
>
>>
>> Thanks,
>>
>> -- Adam
>>
>> From: Adam Dershowitz <adershow...@exponent.com>
>> Date: Monday, March 14, 2016 at 11:21 PM
>> To: Michael Barton <michael.bar...@asu.edu>, grass-user grass-user
>> <grass-user@lists.osgeo.org>
>> Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>>
>> And, I just tried to run 6.4, which I still had installed, and it also
>> won¹t run, but with a different error:
>>
>> Python 2.7.10 found.
>>
>> Cleaning up temporary files ...
>>
>> Starting GRASS ...
>>
>> Traceback (most recent call last):
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py",
>> line 37, in 
>>
>> from core import globalvar
>>
>> File
>> 
>>"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.p
>>y",
>> line 74, in 
>>
>> import wx
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py",
>> line 45, in 
>>
>> from wx._core import *
>>
>> File
>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py",
>> line 4, in 
>>
>> import _core_
>>
>> ImportError: dlopen
>> (/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so,
>> 2): Library not loaded:
>> /Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib
>>
>> Referenced from:
>> /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so
>>
>> Reason: image not found
>>
>> Error in GUI startup. If necessary, please
>>
>> report this error to the GRASS developers.
>>
>> Switching to text mode now.
>>
>> Hit RETURN to continue...
>>
>> Has anyone had any luck running GRASS on 10.11 at all?
>>
>> -- Adam
>>
>> From: grass-user <grass-user-boun...@lists.osgeo.org> on behalf of
>> Michael Barton <michael.bar...@asu.edu>
>> Date: Monday, February 15, 2016 at 3:24 PM
>> To: grass-user grass-user <grass-user@lists.osgeo.org>
>> Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with
>> wxPython (missing)
>>
>> The packaging seems to have gone awry. I've been out of the country
>> and then sick since returning. Once I get well enough to get to the
>> office, I'll try and fix this.
>>
>> Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>>
>> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>> On Feb 15, 2016, at 12:59 PM, grass-user-requ...@lists.osgeo.org
>> wrote:
>>
>> 
>> 
>> From: gene <martin.lal...@gmail.com>
>> 
>>

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

So it looks like this is actually the known problem with System Integrity 
Protection.  I hate to turn off a security feature, and do two reboots,  to be 
able to run a  single application.  Has there been any progress in getting this 
fixed?

Thanks,

-- Adam


From: Adam Dershowitz 
<adershow...@exponent.com<mailto:adershow...@exponent.com>>
Date: Monday, March 14, 2016 at 11:21 PM
To: Michael Barton <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>, 
grass-user grass-user 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

And, I just tried to run 6.4, which I still had installed, and it also won’t 
run, but with a different error:


Python 2.7.10 found.

Cleaning up temporary files ...

Starting GRASS ...

Traceback (most recent call last):

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py", 
line 37, in 

from core import globalvar

  File 
"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py", 
line 74, in 

import wx

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib

  Referenced from: 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

Error in GUI startup. If necessary, please

report this error to the GRASS developers.

Switching to text mode now.

Hit RETURN to continue...




Has anyone had any luck running GRASS on 10.11 at all?


-- Adam


From: grass-user 
<grass-user-boun...@lists.osgeo.org<mailto:grass-user-boun...@lists.osgeo.org>> 
on behalf of Michael Barton 
<michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
<grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4=hiCFoOIof6xOrTVN-DtaoSCJKiGlG1cbfpgCAh75ATw=>,
 
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4=LUWEhxCbJLRMSGP1xOrwKsANc9PwKuLL8M8DAqgRa3c=>




On Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org<mailto:grass-user-requ...@lists.osgeo.org> 
wrote:

From: gene <martin.lal...@gmail.com<mailto:martin.lal...@gmail.com>>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: <grass-user@lists.osgeo.org<mailto:grass-user@lists.osgeo.org>>


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
<http://grassmac.wikidot.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__grassmac.wikidot.com_=CwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=mQkXH1ueNkuN6x_ULoNTVKf8HhzY3BksHkBifuT4ei4=noVWFNeapzu4k_YxtrbHFY7wpnxZuLJcx6PEmEIKXrM=>>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



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

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

Any luck with this?
I just tried to use 7.0.2 and when it failed, I download and tried 7.0.3, which 
also failed.

When I try to run it, I see this:


Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

dyld: Library not loaded: /usr/local/lib/libintl.8.dylib

  Referenced from: 
/Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.3.dylib

  Reason: image not found


And, then as a work around I tried to use the Macports version of that file 
like this:

install_name_tool -change /usr/local/lib/libintl.8.dylib 
/opt/local/lib/libintl.8.dylib 
/Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.3.dylib


but instead I now get this error:

adershowitzMBP15:~ adershowitz$ 
'/Applications/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit

Rebuilding Addon HTML manual pages index...

Rebuilding Addon menu...

Python 2.7.10 found.

Cleaning up temporary files...

Starting GRASS GIS...

Traceback (most recent call last):

  File "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/gis_set.py", 
line 31, in 

from core import globalvar

  File 
"/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/globalvar.py", 
line 84, in 

import wx

  File "/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/usr/local/lib/wxPython-unicode-2.8.12.1/lib/libwx_macud-2.8.0.dylib

  Referenced from: 
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

Error in GUI startup. If necessary, please report this error to the GRASS 
developers.

Switching to text mode now.

Any suggestions or work around would be greatly appreciated.  I have some data 
that I need access to, and usually GRASS is solid and reliable, so not being 
able to use it is worrisome.

Thanks,


-- Adam


From: grass-user 
> 
on behalf of Michael Barton 
>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton,
 
http://csdc.asu.edu




On Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org 
wrote:

From: gene >
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: >


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



___
grass-user mailing list

Re: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython (missing)

[Adam Dershowitz]

And, I just tried to run 6.4, which I still had installed, and it also won’t 
run, but with a different error:


Python 2.7.10 found.

Cleaning up temporary files ...

Starting GRASS ...

Traceback (most recent call last):

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py", 
line 37, in 

from core import globalvar

  File 
"/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/core/globalvar.py", 
line 74, in 

import wx

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py", 
line 45, in 

from wx._core import *

  File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", 
line 4, in 

import _core_

ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
Library not loaded: 
/Users/Shared/unix/wxpython-cocoa-lion/lib/libwx_osx_cocoau-3.0.dylib

  Referenced from: 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so

  Reason: image not found

Error in GUI startup. If necessary, please

report this error to the GRASS developers.

Switching to text mode now.

Hit RETURN to continue...




Has anyone had any luck running GRASS on 10.11 at all?


-- Adam


From: grass-user 
> 
on behalf of Michael Barton 
>
Date: Monday, February 15, 2016 at 3:24 PM
To: grass-user grass-user 
>
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)

The packaging seems to have gone awry. I've been out of the country and then 
sick since returning. Once I get well enough to get to the office, I'll try and 
fix this.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton,
 
http://csdc.asu.edu




On Feb 15, 2016, at 12:59 PM, 
grass-user-requ...@lists.osgeo.org 
wrote:

From: gene >
Subject: [GRASS-user] GRASS GIS 7.03 for Mac OS X, problem with wxPython 
(missing)
Date: February 15, 2016 at 11:55:37 AM MST
To: >


With the 7.0.3 version of  GRASS GIS on the Mac (M.Barton)
>
   I can only launch GRASS-7.0.app (7.0.3) in
text mode.

When I try to launch the App or use g.gui wxpython in the Grass shell the
error is:

"Launching  GUI in the background, please wait…
ERROR: wxGUI requires wxPython. No module named wxversion

In the 7.0.2 version, wxPython is installed in
/Applications/GRASS-7.0.app/Contents/MacOS/etc/python (wx, wxpython and
pyparsing.py and wxversion.py) and it works.

But none of these files/folders exist in the same folder of the 7.0.3
version

Compilation error ?

The size of the zip files are also different (80.19 and 83.89 for GRASS 7.01
and GRASS 7.02, 35 .12 for GRASS 7.03)

Many thanks



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

Re: [GRASS-user] [GRASS-dev] [cmbarton.wikidot.com] Contact via Wikidot.com

[Adam Dershowitz]

Just to add a bit more data.  I have a 10.9 machine and also use macports,
so have macports python 2.7 installed.
The Kyngchaos 6.4 seems to run just fine.  But, I recently tried Grass
7.0.beta2 (Barton) and I have also run into python errors.
If I just try to run it I get this error:

ImportError: 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pyth
on2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image found.
 Did find:

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture


So, I tried switching to System python:

sudo port select python python27-apple


But, oddly, got the same error.  So, it seems to still be using Macports
numpy.  But, then I tried setting:
setenv GRASS_PYTHON /usr/bin/pythonw


And now I get a different error:

GRASS 7.0.0svn (KDEN):~  g.gui
Launching wxpython GUI in the background, please wait...
Traceback (most recent call last):
  File 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py,
line 25, in module
from core import globalvar
  File 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/globalv
ar.py, line 84, in module
import wx
  File 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__.py
, line 45, in module
from wx._core import *
  File 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py,
line 4, in module
import _core_
ImportError: 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so:
no appropriate 64-bit architecture (see man python for running in 32-bit
mode)


But, now it is trying to use the library included with Grass, but still
isn't working.  


-- Adam






On 5/22/14, 9:27 AM, William Kyngesburye wokl...@kyngchaos.com wrote:

The way the GRASS-Mac startup is configured, it looks for python in this
order:

  what's set in GRASS_PYTHON (full path to pythonw, needed for wxpython
GUI)

  what is found in the PATH (/opt is probably in your PATH)

  the python.org Python (/Library/Frameworks)

  the system python

It checks each for the python version needed, but not the architecture.
the error you are getting is probably because GRASS needs to run python
32bit because of Wxpython limitations, but the /opt python is 64bit only.
 That's odd that macports does that since you need wxpython 3 to be able
to run 64bit.  But GRASS should have its own wxpython bundled, and it's
best to use the python it was compiled for (system python as Michael
said).

On May 22, 2014, at 4:31 AM, Michael Barton c.michael.bar...@gmail.com
wrote:

 I haven't installed PostGIS, so you'll have to ask William about that.
But I do have Mavericks, GRASS 6 and 7, and QGIS v. 2 working together.
I don't know how to best set the environment to use the system python.
It is best to ask the list if someone has done this (copied here). OS X
is a version of Unix, which is similar but not identical to Linux. Many
of the configuration files for setting environmental variables are
similar between OS X and Linux, but they can vary sometimes.
 
 
 Michael Barton
 
 
 
 On May 22, 2014, at 5:32 AM, John Payne jpa...@wcs.org wrote:
 
 Hi Michael,
 
 Thank you -- I remember reading about conflicts between multiple Python
 versions but I don't know how to tell whether the /opt version is being
 used by other software so I'm hesitant to remove it.  I haven't
switched
 to Mavericks yet for fear that it would break things, but perhaps it's
 time to take the plunge.  It looks to me as though you and William
 Kyngesbury have made it possible to install this combination:
 
 Mavericks
 PostgreSQL with PostGIS (postGIS is critical to me)
 GRASS 7
 QGIS
 
 Šbut please tell me if that is not the case.
 
 Also can you tell me which environment variable I need to change to
allow
 GRASS to use the system Python only?   I hate to waste your time, but
 being an ex-Windows user, these OS X installations seem like black
magic
 to me and the OS X books that I've seen are all way too general to be
 useful (push the big happy button and you're done!).  Maybe Unix
books
 are more useful?  I'm guessing that experts like you simply learn the
hard
 way, by experience, but I would love to be able to study on my own if
you
 have any recommendations.
 
 Lastly, I have been using MacPorts and I see that they have wxPython
 version 2.8.12.1.  Is that close enough to the one that you compiled
with?
 
 Thanks,
 
 John  
 
 
 
 On 5/21/14 11:15 PM, Michael Barton c.michael.bar...@gmail.com
wrote:
 
 You have another Python installed in /opt in addition to the system
 Python. The computer is confused. You will need to change your path or
 python path to allow GRASS to use your system Python only. Also, the
Mac
 binaries bundle wxPython with the program. You don't need to install
 this. If you have it, you should probably have exactly the same
version
 that was used for compiling. Currently, I'm 

Re: [GRASS-user] [GRASS-dev] [cmbarton.wikidot.com] Contact via Wikidot.com

[Adam Dershowitz]

Now, I can't seem to reproduce the error I was having.  So maybe macports
has fixed this, and is now loading only its own stuff.  At least I will
assume that for now, until I run into the bug again.

-- Adam






On 5/22/14, 2:32 PM, William Kyngesburye wokl...@kyngchaos.com wrote:

Sounds like the Macports python is loading the system python global
site-packages (/Library/Python).  Bad form really, because you can't
expect modules to work between different builds of python, even if
they're the same version.  Maybe there is some option in Macports python
to exclude the system site-packages.

To get GRASS to always use the system python, just set GRASS_PYTHON (you
can set this in your .bash_profile):

export GRASS_PYTHON=/usr/bin/pythonw2.7

The version is important because of the way GRASS forces 32bit.

On May 22, 2014, at 10:28 AM, Adam Dershowitz adershow...@exponent.com
wrote:

 In my case, the problem was that I had uninstalled NumPy (from kyngchaos
 GDAL).  It was causing a conflict with Macports scipy stuff.  The
macports
 version is installed as universal but apparently is actually just 64
 bit!  
 So the workaround I have at the moment is to install NumPy when I need
to
 use GRASS 7, and then uninstall so I can use macports python (which I
need
 for other libraries and such).
 This seems like a inconvenient fix for now.  Is there any way to set
some
 paths so that they can both co-exist and GRASS will find the correct
one?
 
 -- Adam
 
 
 
 
 
 
 On 5/22/14, 10:12 AM, Adam Dershowitz adershow...@exponent.com
wrote:
 
 Just to add a bit more data.  I have a 10.9 machine and also use
macports,
 so have macports python 2.7 installed.
 The Kyngchaos 6.4 seems to run just fine.  But, I recently tried Grass
 7.0.beta2 (Barton) and I have also run into python errors.
 If I just try to run it I get this error:
 
 ImportError: 
 
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/p
yt
 h
 on2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image
found.
 Did find:
 
 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2
.7
 /
 site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture
 
 
 So, I tried switching to System python:
 
 sudo port select python python27-apple
 
 
 But, oddly, got the same error.  So, it seems to still be using
Macports
 numpy.  But, then I tried setting:
 setenv GRASS_PYTHON /usr/bin/pythonw
 
 
 And now I get a different error:
 
 GRASS 7.0.0svn (KDEN):~  g.gui
 Launching wxpython GUI in the background, please wait...
 Traceback (most recent call last):
 File 
 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py
,
 line 25, in module
   from core import globalvar
 File 
 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/gui/wxpython/core/glob
al
 v
 ar.py, line 84, in module
   import wx
 File 
 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/__init__
.p
 y
 , line 45, in module
   from wx._core import *
 File 
 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py
,
 line 4, in module
   import _core_
 ImportError: 
 
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core_.so
:
 no appropriate 64-bit architecture (see man python for running in
32-bit
 mode)
 
 
 But, now it is trying to use the library included with Grass, but still
 isn't working. 
 
 
 -- Adam
 
 
 
 
 
 
 On 5/22/14, 9:27 AM, William Kyngesburye wokl...@kyngchaos.com
wrote:
 
 The way the GRASS-Mac startup is configured, it looks for python in
this
 order:
 
 what's set in GRASS_PYTHON (full path to pythonw, needed for wxpython
 GUI)
 
 what is found in the PATH (/opt is probably in your PATH)
 
 the python.org Python (/Library/Frameworks)
 
 the system python
 
 It checks each for the python version needed, but not the
architecture.
 the error you are getting is probably because GRASS needs to run
python
 32bit because of Wxpython limitations, but the /opt python is 64bit
only.
 That's odd that macports does that since you need wxpython 3 to be
able
 to run 64bit.  But GRASS should have its own wxpython bundled, and
it's
 best to use the python it was compiled for (system python as Michael
 said).
 
 On May 22, 2014, at 4:31 AM, Michael Barton
c.michael.bar...@gmail.com
 wrote:
 
 I haven't installed PostGIS, so you'll have to ask William about
that.
 But I do have Mavericks, GRASS 6 and 7, and QGIS v. 2 working
together.
 I don't know how to best set the environment to use the system
python.
 It is best to ask the list if someone has done this (copied here).
OS X
 is a version of Unix, which is similar but not identical to Linux.
Many
 of the configuration files for setting environmental variables are
 similar between OS X and Linux, but they can vary sometimes.
 
 
 Michael Barton
 
 
 
 On May 22, 2014, at 5:32 AM, John Payne jpa...@wcs.org wrote:
 
 Hi Michael,
 
 Thank you -- I remember reading about conflicts between multiple
 Python
 versions but I don't know how

Re: [GRASS-user] GRASS GIS 7.0.0beta1 is out

[Adam Dershowitz]

I just tried to install this.  I had a very recent 7.0 of yours installed.
 When I run the installer, it makes it through most of the steps.  Then,
near the end, it says, validating and finally brings up an error.

Here is what shows in the box:

There were errors with the installation.  You may want to try (then the
message is cut off).
The installation failed.
The installer encountered n error that caused the installation to tail.
Contact the software manufacturer for assistance.

The install log is below:

Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: LSExceptions
[0x608b9380] loaded
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: @(#)PROGRAM:Install
PROJECT:Install-846
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: @(#)PROGRAM:Installer
PROJECT:Installer-721
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Hardware: MacBookPro9,1
@ 2.60 GHz (x 8), 8192 MB RAM
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Running OS Build: Mac
OS X 10.9.2 (13C64)
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
PATH=/usr/bin:/bin:/usr/sbin:/sbin
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
TMPDIR=/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: SHELL=/bin/bash
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
HOME=/Users/adershowitz
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: USER=adershowitz
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: LOGNAME=adershowitz
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
GPG_AGENT_INFO=/Users/adershowitz/.gnupg/S.gpg-agent:634:1
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
SSH_AUTH_SOCK=/tmp/launch-cRtteu/Listeners
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
Apple_PubSub_Socket_Render=/tmp/launch-YoZwJc/Render
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
DISPLAY=/tmp/launch-UzS5ph/org.macosforge.xquartz:0
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-LKGofO/unix_domain_listener
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
__CF_USER_TEXT_ENCODING=0x490111B3:0:0
Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: __CHECKFIX1436934=1
Apr  7 09:39:02 adershowitzMBP15 Installer[57796]: GRASS-7.0  Installation
Log
Apr  7 09:39:02 adershowitzMBP15 Installer[57796]: Opened from:
/Users/adershowitz/Downloads/Navigate etc/GRASS-7.0beta1.pkg
Apr  7 09:39:03 adershowitzMBP15 Installer[57796]: Referenced component
packages (1) trustLevel=100
Apr  7 09:39:13 adershowitzMBP15 Installer[57796]: LSExceptions
[0x608b9380] unloaded
Apr  7 09:39:34 adershowitzMBP15 Installer[57796]:
InstallerStatusNotifications plugin loaded
Apr  7 09:39:42 adershowitzMBP15 runner[57801]: Administrator
authorization granted.
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
===
=
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: User picked Standard
Install
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Choices selected for
installation:
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:  Upgrade: GRASS-7.0
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:  
GRASS-7.0beta1.pkg :
org.osgeo.grass7_0 : 7.0.140403.7.0
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
===
=
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: It took 0.00 seconds to
summarize the package selections.
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: -[IFPKGDerivedDocument
sortedPackageLocations]: result = (
file://localhost
)
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
-[IFDInstallController(Private) _buildInstallPlan]: location =
file://localhost
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
-[IFDInstallController(Private) _buildInstallPlan]:
file://localhost/Users/adershowitz/Downloads/Navigate%20etc/GRASS-7.0beta1.
pkg
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Set authorization level
to root for session
Apr  7 09:39:42 adershowitzMBP15 runner[57801]: Administrator
authorization granted.
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Will use PK session
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Starting installation:
Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Configuring volume
Macintosh HD
Apr  7 09:39:43 adershowitzMBP15 Installer[57796]: Preparing disk for
local booted install.
Apr  7 09:39:43 adershowitzMBP15 Installer[57796]: Free space on
Macintosh HD: 121.37 GB (121369862144 bytes).
Apr  7 09:39:43 adershowitzMBP15 Installer[57796]: Create temporary
directory 
/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T//Install.577965qM2wZ
Apr  7 09:39:43 adershowitzMBP15 Installer[57796]: IFPKInstallElement (1
packages)
Apr  7 09:39:43 adershowitzMBP15 Installer[57796]: Using authorization
level of root for IFPKInstallElement
Apr  7 09:39:43 adershowitzMBP15 installd[48393]: 

Re: [GRASS-user] GRASS GIS 7.0.0beta1 is out

[Adam Dershowitz]

I tried to install 7.0.0beta1, that I downloaded today.  I have OS 10.9.2

I didn’t upgrade or change any frameworks, but I have the set that I had
upgraded from kyngchaos.com a few weeks ago.  And that set was working
fine with a very recent 7.0 from your site, and a recent 6.4 from
Kyngchaos.  

Does the installer now try to verify some frameworks are present?

-- Adam






On 4/7/14, 4:53 PM, Michael Barton michael.bar...@asu.edu wrote:

Adam,

Which version did you try to install? What is your OS? While frameworks
did you install?

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:   http://csdc.asu.edu, http://shesc.asu.edu
   http://www.public.asu.edu/~cmbarton

On Apr 7, 2014, at 6:47 AM, Adam Dershowitz adershow...@exponent.com
wrote:

 I just tried to install this.  I had a very recent 7.0 of yours
installed.
 When I run the installer, it makes it through most of the steps.  Then,
 near the end, it says, validating and finally brings up an error.
 
 Here is what shows in the box:
 
 There were errors with the installation.  You may want to try (then the
 message is cut off).
 The installation failed.
 The installer encountered n error that caused the installation to tail.
 Contact the software manufacturer for assistance.
 
 The install log is below:
 
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: LSExceptions
 [0x608b9380] loaded
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: @(#)PROGRAM:Install
 PROJECT:Install-846
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: @(#)PROGRAM:Installer
 PROJECT:Installer-721
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Hardware:
MacBookPro9,1
 @ 2.60 GHz (x 8), 8192 MB RAM
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Running OS Build: Mac
 OS X 10.9.2 (13C64)
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 PATH=/usr/bin:/bin:/usr/sbin:/sbin
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 TMPDIR=/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: SHELL=/bin/bash
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 HOME=/Users/adershowitz
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env: USER=adershowitz
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
LOGNAME=adershowitz
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 GPG_AGENT_INFO=/Users/adershowitz/.gnupg/S.gpg-agent:634:1
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 SSH_AUTH_SOCK=/tmp/launch-cRtteu/Listeners
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 Apple_PubSub_Socket_Render=/tmp/launch-YoZwJc/Render
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 DISPLAY=/tmp/launch-UzS5ph/org.macosforge.xquartz:0
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-LKGofO/unix_domain_listener
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
 __CF_USER_TEXT_ENCODING=0x490111B3:0:0
 Apr  7 09:39:01 adershowitzMBP15 Installer[57796]: Env:
__CHECKFIX1436934=1
 Apr  7 09:39:02 adershowitzMBP15 Installer[57796]: GRASS-7.0
Installation
 Log
 Apr  7 09:39:02 adershowitzMBP15 Installer[57796]: Opened from:
 /Users/adershowitz/Downloads/Navigate etc/GRASS-7.0beta1.pkg
 Apr  7 09:39:03 adershowitzMBP15 Installer[57796]: Referenced component
 packages (1) trustLevel=100
 Apr  7 09:39:13 adershowitzMBP15 Installer[57796]: LSExceptions
 [0x608b9380] unloaded
 Apr  7 09:39:34 adershowitzMBP15 Installer[57796]:
 InstallerStatusNotifications plugin loaded
 Apr  7 09:39:42 adershowitzMBP15 runner[57801]: Administrator
 authorization granted.
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
 
=
==
 =
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: User picked Standard
 Install
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: Choices selected for
 installation:
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:   Upgrade: GRASS-7.0
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:   
 GRASS-7.0beta1.pkg
:
 org.osgeo.grass7_0 : 7.0.140403.7.0
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
 
=
==
 =
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]: It took 0.00 seconds
to
 summarize the package selections.
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
-[IFPKGDerivedDocument
 sortedPackageLocations]: result = (
  file://localhost
  )
 Apr  7 09:39:42 adershowitzMBP15 Installer[57796]:
 -[IFDInstallController(Private) _buildInstallPlan]: location

Re: [GRASS-user] GRASS and Mavericks (OS X 10.9) on Macs

[Adam Dershowitz]

For some reason I had problems getting this to work (not related to GRASS)  So, 
I hunted around, and it is not obvious, but the command line tools are still 
available for download from:  https://developer.apple.com/downloads
You need to have an account (free) and login, but then one of the download 
options is Command Line Tools (OS X Mavericks).



-- Adam


From: Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu
Date: Wednesday, November 27, 2013 at 12:48 PM
To: GRASS developers grass-developers 
grass-...@lists.osgeo.orgmailto:grass-...@lists.osgeo.org, grass-user 
grass-user grass-user@lists.osgeo.orgmailto:grass-user@lists.osgeo.org
Cc: Helena Mitasova hmit...@unity.ncsu.edumailto:hmit...@unity.ncsu.edu
Subject: [GRASS-user] GRASS and Mavericks (OS X 10.9) on Macs

I upgraded all of my Macs to Mavericks over the past week. GRASS works fine.

GRASS 7 g.extension was having problems on other people’s machines because I 
failed to package a couple libraries for gettext. I’ve repackaged my 1 November 
GRASS 7 (Snow Leopard compatible) with these libraries included. This seems to 
have mostly fixed g.extension problems.

In order for g.extension to correctly compile source code extensions (i.e., in 
C rather than in Python), anyone upgrading to Mavericks also has to upgrade 
Xcode and the command line tools. Xcode is a free download from the app store. 
The command line tools are harder to come by now. AFAICT, there is no longer a 
link to download and install them from the Apple Developer site. This is weird, 
but there is a work around.

After install Xcode, open a terminal and enter:

xcode-select --install

You’ll get a dialog that allows you to install Xcode (no need to do that again) 
or install the command line tools. Click the install button to do that.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

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

[GRASS-user] r.surf.nnbathy with GRASS 7?

[Adam Dershowitz]

Is r.surf.nnbathy compatible with GRASS 7.0?  It doesn't seem to be listed on 
the GRASS7 Raster AddOns page.  And, the install instructions that I have found 
all refer to GRASS 6.

I have the nnbathy binary from 6 working fine.  Can I just copy over the script 
and binary?  Is there a new version?

Thanks,

-- Adam

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

Re: [GRASS-user] rounding raster values

[Adam Dershowitz]

You can convert, and convert back.  I think that this would work:

r.mapcalc output = round(input * 1000)/1000.0

-- Adam


From: Paulo van Breugel p.vanbreu...@gmail.commailto:p.vanbreu...@gmail.com
Date: Wednesday, May 1, 2013 11:48 AM
To: GRASS users email list 
grass-user@lists.osgeo.orgmailto:grass-user@lists.osgeo.org
Subject: [GRASS-user] rounding raster values

Hi,

I have floating raster layers which values I want to round to x decimal places. 
I wonder if there is an function that allows me to round raster values to 
values x decimal places? There is the option round() in r.mapcalc, but that 
rounds the raster values to nearest integer. I can work with integer values, 
using e.g., r.mapcalc output = round(input * 1000). But an option to round 
values would be more convenient. Any suggestion?

Rgds

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

Re: [GRASS-user] GRASS on Mac OS 10.8.3

[Adam Dershowitz]

I figured out the problem and a temporary work around, that I figured I would 
let people know.  But, if anyone has  a better solution, I would love to hear 
it.
The problem seems to be that I have macports installed, and there appears to be 
an issue with python versions, and where it is being found.

I first tried using the acceptable macports way of changing to different 
versions of python, but these didn't help:
sudo port select python python26
sudo port select python python27-apple
Etc, but these didn't allow either 6.4 or 7.0 to run.

But, if I get rid of all my macports stuff by doing:
Sudo mv /opt/local /opt/local_tmp
Then I can open either GRASS 6.4 or 7.0.  I can then move opt/local back and 
then either GRASS seems to work fine.  Even if I quit and restart the gui they 
are fine.
This was not a problem for me on OS 10.6 and earlier.  So, something is 
different about search paths and/or environmental variables.
Renaming like that is not a viable long term solution, as I need macports stuff 
a bunch.  Any suggestions about how the application is searching and why it is 
not finding a good version?  Or maybe the real problem is that I don't have the 
correct port (or version) of something installed in Macports, and if I do then 
it might be that the macports version is fine, and would work.  I believe that 
there might have been a change between 10.6 and 10.8 related to 32 bit versus 
64 bit being default builds, so could there be an issue with which version of 
wx, or some other library is being searched for?

Any thoughts or guidance?

-- Adam


From: Adam Dershowitz 
adershow...@exponent.commailto:adershow...@exponent.com
Date: Monday, April 8, 2013 4:59 PM
To: grass-user@lists.osgeo.orgmailto:grass-user@lists.osgeo.org 
grass-user@lists.osgeo.orgmailto:grass-user@lists.osgeo.org
Subject: GRASS on Mac OS 10.8.3

I recently upgrade to a  new machine that has mac OS 10.8.3 on it (from 10.6).  
Now, GRASS seems not to be working.  What's the status of GRASS on 10.8.3?
Here are the details.

I tried kyngchaos binary 6.4.2 and if I double click on it, I initially get:

 '/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh'; exit
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
dyld: DYLD_ environment variables being ignored because main executable 
(/usr/bin/osascript) is code signed with entitlements
Python 2.6.8 found.

WELCOME TO GRASS  Version 6.4.2 2012

   1) Have at your side all available GRASS tutorials

   2) When working on your location, the following materials
  are extremely useful:
  - A topo map of your area
  - Current catalog of available computer maps

   3) Check the GRASS webpages for feedback mailinglists and more:
  http://www.grass-gis.org
  http://grass.osgeo.org

Hit RETURN to continue


If I then hit return I get:


Starting GRASS ...
Traceback (most recent call last):
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py, 
line 35, in module
from gui_modules import globalvar
  File 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
 line 76, in module
import wx
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py, 
line 45, in module
from wx._core import *
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py, 
line 4, in module
import _core_
ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
no suitable image found.  Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so: mach-o, but 
wrong architecture
Error in GUI startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue...

I then tried downloading the newest 7.0 from cmbarton and ran into similar 
problems.  Any thoughts or suggestions?

Thanks much.


-- Adam

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

Re: [GRASS-user] GRASS on Mac OS 10.8.3

[Adam Dershowitz]

That did the job.  
In my case it was actually in .profile.  I think that by default Macports,
on recent systems, builds 64 bit.  But, to complicate things, I actually
have a universal build of python, but not wxPython.  My guess is that
the problem was actually with wx, not with python itself.

Thank you much!  


-- Adam






On 4/9/13 5:04 PM, William Kyngesburye wokl...@kyngchaos.com wrote:

There was someone else with this problem, but I didn't have a solution
then.  maybe this will help them.

GRASS (OS X) needs a Python compatible with the bundled wxPython.  So far
this has been limited to 32bit, though the rest of GRASS can be 64bit.
So OS X has a wrapper that forces python to run 32bit, and the startup
tries to find a suitable Python.

It's possible that it still somehow executes the Macports Python, and the
Macports Python may be 64bit only, then you get the error about the wrong
architecture (32bit vs 64bit).

The order for finding Python is:

GRASS_PYTHON
PATH
/Library/Frameworks (the python.org python)
system

Now that I look at it, when finding Python, it doesn't check the
available architectures, so it's very possible to find the Macports
Python (suspected 64bit only) in the PATH, then fail to run when it's
needed.

Try setting GRASS_PYTHON in your .bash_profile to (exactly):

/usr/bin/pythonw2.6

On Apr 9, 2013, at 11:23 AM, Adam Dershowitz wrote:

 I figured out the problem and a temporary work around, that I figured I
would let people know.  But, if anyone has  a better solution, I would
love to hear it.
 The problem seems to be that I have macports installed, and there
appears to be an issue with python versions, and where it is being
found.  
 
 I first tried using the acceptable macports way of changing to
different versions of python, but these didn't help:
 sudo port select python python26
 sudo port select python python27-apple
 Etc, but these didn't allow either 6.4 or 7.0 to run.
 
 But, if I get rid of all my macports stuff by doing:
 Sudo mv /opt/local /opt/local_tmp
 Then I can open either GRASS 6.4 or 7.0.  I can then move opt/local
back and then either GRASS seems to work fine.  Even if I quit and
restart the gui they are fine.
 This was not a problem for me on OS 10.6 and earlier.  So, something is
different about search paths and/or environmental variables.
 Renaming like that is not a viable long term solution, as I need
macports stuff a bunch.  Any suggestions about how the application is
searching and why it is not finding a good version?  Or maybe the real
problem is that I don't have the correct port (or version) of something
installed in Macports, and if I do then it might be that the macports
version is fine, and would work.  I believe that there might have been a
change between 10.6 and 10.8 related to 32 bit versus 64 bit being
default builds, so could there be an issue with which version of wx, or
some other library is being searched for?
 
 Any thoughts or guidance?
 
 -- Adam

-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.


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

Re: [GRASS-user] GRASS on Mac OS 10.8.3

[Adam Dershowitz]

On 4/9/13 6:02 PM, William Kyngesburye wokl...@kyngchaos.com wrote:

On Apr 9, 2013, at 7:37 PM, Adam Dershowitz wrote:

 That did the job.
 In my case it was actually in .profile.  I think that by default
Macports,
 on recent systems, builds 64 bit.  But, to complicate things, I actually
 have a universal build of python, but not wxPython.  My guess is that
 the problem was actually with wx, not with python itself.
 
 Thank you much! 

Well, if you have a universal Python in Macports, then it should work
because it will execute 32bit.  If you mean you have universal Python
somewhere else, then Macports 32bit Python is probably found first.

I did mean that I built Python universal in macports.  Although the
macports wx is not universal (and fails to build that way)


The problem IS python, not wx.  GRASS knows wx is 32bit only, it's just
that Python somehow executes 64bit (ie from Macports).  wxPython has been
limited to 32bit on OS X until very recently.  My GRASS 6.4.2 includes
and the GUI only supports 32bit wxPython.  GRASS 6.4.3 has fixes in the
GUI to support the development version of wxPython that can be 64bit on
OS X, but I don't think Michael has updated yet.

But, I have found something odd.  Again, as the problem is solved, this is
not at all a big deal.  But, but just something interesting.
It seems that once I set GRASS_PYTHON (either in .profile or
.bash_profile) that it works.  But, if I then comment it out and run GRASS
again, it continues to work fine (6.4.2, or 7.0).  Furthermore, in the
terminal that GRASS opens, if I do:
which python, what shows is
/Applications/GRASS-6.4.app/Contents/MacOS/bin/python

And these environmental variables are set in that terminal
GRASS_PYTHON=python
GRASS_PYTHONWX=/usr/bin/pythonw2.6

So, it seems like once I set GRASS_PYTHON a single time, it then saves
that value and uses it, even if GRASS_PYTHON is not set the next time.
 


Good to know that GRASS_PYTHON fixes the problem without fuss.

Note: .bash_profile is the standard shell init file on OS X, at least for
Terminal.  OS X Terminal is an oddball in the loading of init files.  On
my OS X 10.7 Mac .profile is NOT loaded (it may have been loaded on
earlier systems).  So it's a good idea to get into the habit of using
.bash_profile, even if .profile happens to work for you.



That's what I have done now.

Again, thanks for the help.

--Adam

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

[GRASS-user] GRASS on Mac OS 10.8.3

[Adam Dershowitz]

I recently upgrade to a  new machine that has mac OS 10.8.3 on it (from 10.6).  
Now, GRASS seems not to be working.  What's the status of GRASS on 10.8.3?
Here are the details.

I tried kyngchaos binary 6.4.2 and if I double click on it, I initially get:

 '/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh'; exit
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
dyld: DYLD_ environment variables being ignored because main executable 
(/usr/bin/osascript) is code signed with entitlements
Python 2.6.8 found.

WELCOME TO GRASS  Version 6.4.2 2012

   1) Have at your side all available GRASS tutorials

   2) When working on your location, the following materials
  are extremely useful:
  - A topo map of your area
  - Current catalog of available computer maps

   3) Check the GRASS webpages for feedback mailinglists and more:
  http://www.grass-gis.org
  http://grass.osgeo.org

Hit RETURN to continue


If I then hit return I get:


Starting GRASS ...
Traceback (most recent call last):
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py, 
line 35, in module
from gui_modules import globalvar
  File 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
 line 76, in module
import wx
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py, 
line 45, in module
from wx._core import *
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py, 
line 4, in module
import _core_
ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
no suitable image found.  Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so: mach-o, but 
wrong architecture
Error in GUI startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue...

I then tried downloading the newest 7.0 from cmbarton and ran into similar 
problems.  Any thoughts or suggestions?

Thanks much.


-- Adam

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

Re: [GRASS-user] 3-D plane workflow

[Adam Dershowitz]

Thanks very much.
That is just what I had in mind. Is it then possible to convert that to a 
raster elevation to use for some height calculations?

--Adam


-Original Message-
From: Anna Kratochvílová [kratocha...@gmail.commailto:kratocha...@gmail.com]
Sent: Saturday, March 02, 2013 09:12 AM Pacific Standard Time
To: Adam Dershowitz
Cc: GRASS user list
Subject: Re: [GRASS-user] 3-D plane workflow


On Wed, Feb 27, 2013 at 12:38 AM, Adam Dershowitz
adershow...@exponent.com wrote:
 I would like to be able to put some surfaces in the space over a DEM.  In
 other words, I have a DEM, and then I need to calculate some regions that
 are keep-out zones in space above.  I can calculate where these surfaces
 are fairly easily in Python, for example.  So the output of my calculation
 would be some points.  In the easiest example, it would just be 4 sets of
 x,y,z that represent the four corners of a plane.
 I would then like to be able to visually show this plane (or multiple
 planes), over the DEM, and show that the DEM does, or doesn't, penetrate
 this surface.  If it does penetrate, I would like to be able to calculate
 the penetration height.

 The kind of thing that I would like to do, would end up looking like the
 examples of Slovakia precipitation that Mitasova has done.  Some of those
 examples show a DEM, and then a surface that is being penetrated by the DEM.
 I have been reading some of the examples for 3D visualization (such as here:
 http://grasswiki.osgeo.org/wiki/Help_with_3D), but figured that a post here,
 but might get me a little more guidance about a general suggested workflow.

 In those examples, are the isosurfaces does as 3D rasters?  If I just want a
 plane in space, and I have the four corner points, is a 3D raster seem like
 the best way to draw it?  Are those examples displayed with NVIZ or
 paraview?

 Is the following a reasonable approach:

 Calculate the surfaces in some code and export as faces:

 F 4
  0 100 10
  50 50 80
  0 0 10
  0 100 10

 Then, import into Grass with v.in.ascii.
 Next, I would have to convert to a raster:  v.to.rast.
 Then, I would have to convert to an elevation:  r.to.rast3elev
 Finally, I could export both the surfaces and the ground DEM with
 r3.out.vtk, and visualize with paraview.

 Is this a reasonable workflow?  If I just need a semitransparent surface, is
 it necessary for it to be 3D, or can it be done with 2.5D (all I really need
 is x,y and elevation, like a DEM).  For, example, I might be able to just
 skip the raster version and use v.out.vtk?Or maybe I can just use nviz
 to visualize what I need, if I can get it to the right format.
 If I do convert the plane to a raster, I suppose I can then use mapcalc to
 calculate the height difference between the plane and the ground DEM?

 I am just looking for some general workflow guidance for a good overall
 approach to get going.  It seems like there are some things that are not as
 clear about 3D work in GRASS, and I am just trying to get a reasonable
 picture.
 Any thoughts are greatly appreciate.

 Thanks much,



Hi Adam,

I am not sure if this is exactly what you want but have a look at the
attached screenshots. This is done in wxNviz. I created a plane (3
points) with

v.in.ascii -n input=inputFile.txt output=out format=standard separator=   z=3

The file containes what you already used (F 4 ...). Then you can
display it in 3D view. However, the transparency of the surface is not
working well together with the vector (note to developers: the same
issue is in old nviz). You can play with using wire style as in the
screenshot. If it is not clear, just ask for more details.

Regards,
Anna
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] 3-D plane workflow

[Adam Dershowitz]

I would like to be able to put some surfaces in the space over a DEM.  In other 
words, I have a DEM, and then I need to calculate some regions that are 
keep-out zones in space above.  I can calculate where these surfaces are 
fairly easily in Python, for example.  So the output of my calculation would be 
some points.  In the easiest example, it would just be 4 sets of x,y,z that 
represent the four corners of a plane.
I would then like to be able to visually show this plane (or multiple planes), 
over the DEM, and show that the DEM does, or doesn't, penetrate this surface.  
If it does penetrate, I would like to be able to calculate the penetration 
height.

The kind of thing that I would like to do, would end up looking like the 
examples of Slovakia precipitation that Mitasova has done.  Some of those 
examples show a DEM, and then a surface that is being penetrated by the DEM.
I have been reading some of the examples for 3D visualization (such as here: 
http://grasswiki.osgeo.org/wiki/Help_with_3D), but figured that a post here, 
but might get me a little more guidance about a general suggested workflow.

In those examples, are the isosurfaces does as 3D rasters?  If I just want a 
plane in space, and I have the four corner points, is a 3D raster seem like the 
best way to draw it?  Are those examples displayed with NVIZ or paraview?

Is the following a reasonable approach:

Calculate the surfaces in some code and export as faces:

F 4
 0 100 10
 50 50 80
 0 0 10
 0 100 10

Then, import into Grass with v.in.ascii.
Next, I would have to convert to a raster:  v.to.rast.
Then, I would have to convert to an elevation:  r.to.rast3elev
Finally, I could export both the surfaces and the ground DEM with r3.out.vtk, 
and visualize with paraview.

Is this a reasonable workflow?  If I just need a semitransparent surface, is it 
necessary for it to be 3D, or can it be done with 2.5D (all I really need is 
x,y and elevation, like a DEM).  For, example, I might be able to just skip the 
raster version and use v.out.vtk?Or maybe I can just use nviz to visualize 
what I need, if I can get it to the right format.
If I do convert the plane to a raster, I suppose I can then use mapcalc to 
calculate the height difference between the plane and the ground DEM?

I am just looking for some general workflow guidance for a good overall 
approach to get going.  It seems like there are some things that are not as 
clear about 3D work in GRASS, and I am just trying to get a reasonable picture.
Any thoughts are greatly appreciate.

Thanks much,


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

Re: [GRASS-user] 3-D plane workflow

[Adam Dershowitz]

On 2/26/13 9:56 PM, Hamish hamis...@yahoo.com wrote:

Adam wrote:
 I would like to be able to put some surfaces in the space over
 a DEM.

in NVIZ, add a new raster surface, and set the map to a constant
value instead of a map name. You can either change the value of
the constant or the z-position offset to move it around.

That won't do what I need.  The problem is that the planes I want are
finite and not horizontal.  Instead they are polygons where I have the
corner points defined.  For example, just picture an arbitrarily oriented
square floating in space over the DEM based ground.



For a finite surface area, use r.plane or like
  r.mapcalc constmap = 100
and load a second raster surface in NVIZ's raster controls.

I suppose I could calculate out the dip and azimuth for r.plane, or the
equivalent equations for r.mapcalc.  Then, I would need to  generate a
mask as well.  
Another thought that I had was to import the points as vectors, then to
use r.surf.nnbathy to generate the raster surface values.


You can also set its transparency level to make it translucent
for a nice see-through effect.

3D vector faces may work as well, but they are not as mature.


Hamish

ps- Helena/Carla: re. the shading I think there is some bug in
at least tcl/tk NVIZ where one of the light sources (the direct
one?) gets turned off and does not go back on. the only way back
is to save the state and restart NVIZ.


Thanks for the info.  It is helpful.

--Adam

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

Re: [GRASS-user] pyhton script-how to get the pixel value from r.what

[Adam Dershowitz, Ph.D., P.E.]

On Mar 28, 2012, at 2:38 PM, tigrida wrote:

 Hello!
 
 I am writing a python script, and I want to do mathematical operations with
 some pixels, but I can't. Can anyone help me?
 
 
 script:
 ts_f= grass.read_command(r.what,input=Ts, east_north= %s,%s %
 (eastF,northF))
 print Ts pixel frio=,ts_f
 lambda_f=(2.501-(0.00236*(ts_f-273.15)))*100
 
 error:
 Ts pixel frio= 180740.539419|2399806.55602||290.266289112492
 
 Traceback (most recent call last):
  File vslp2.py, line 284, in module
lambda_f=(2.501-(0.00236*(ts_f-273.15)))*100
 TypeError: unsupported operand type(s) for -: 'str' and 'float'
 
 
 I really appreciate any suggestions
 
 
 



It looks like the grass.read_command returns a string, and you are then trying 
to do math on it.
You probably want something like:

import string
ts_f= grass.read_command(r.what,input=Ts, east_north= %s,%s %
(eastF,northF))
print Ts pixel frio=,ts_f
ts_values=string.split(ts_f,'|')

I am not sure which value you then want.  Probably ts_values[3]:

lambda_f=(2.501-(0.00236*(ts_values[3]-273.15)))*100
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.viewshed build

[Adam Dershowitz, Ph.D., P.E.]

On Oct 10, 2011, at 12:51 AM, Glynn Clements wrote:

 
 Adam Dershowitz, Ph.D., P.E. wrote:
 
 I just tried to build and run r.viewshed.  When I build it, it seems to
 compile fine, but then latter in the make process, I saw this error go
 past:
 
 MM error: limit =0B. allocating 16B. limit exceeded by 24B.
 Assertion failed: (0), function operator new, file mm.cc, line 326.
 
 Any thoughts or suggestions what might be going on with this?
 
 Something is trying to allocate memory before the memory manager
 object has been initialised.
 
 The order in which static objects are constructed is undefined. So if
 a static object dynamically allocates memory in its constructor, it's
 a matter of luck whether the memory manager object has been
 constructed at that point.
 
 Fortunately, the MM_register class doesn't actually need construction. 
 Unfortunately, the limit-checking mode is statically initialised to
 abort, then changed to ignore in the constructor.
 
 This has (hopefully) been fixed in 7.0 with r38702, but the problem
 remains in 6.x.
 
 The fix involves changing line 443 of lib/iostream/mm.cc from:
 
   MM_mode MM_register::register_new = MM_ABORT_ON_MEMORY_EXCEEDED; 
 to:
   MM_mode MM_register::register_new = MM_IGNORE_MEMORY_EXCEEDED;
 
 -- 
 

Thanks.
I assume that means 1)  the only way to fix this is to recompile the grass 
iostream static library?  (I have been using the binary of grass).  2)  Will 
the same change work in 6.x?  Or would the change potentially introduce other 
problems or be more complicated?

--Adam

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

[GRASS-user] r.viewshed build

[Adam Dershowitz, Ph.D., P.E.]

I just tried to build and run r.viewshed.  When I build it, it seems to compile 
fine, but then latter in the make process, I saw this error go past:

MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.


However, after that, it does apparently complete the build and generate a 
binary.  But, if I try to run the binary, I get exactly that error.  Even just 
trying to get help:

 r.viewshed  -h
MM error: limit =0B. allocating 16B. limit exceeded by 24B.
Assertion failed: (0), function operator new, file mm.cc, line 326.
Abort trap

So, it seems that something is odd with build.  
I am running on a Mac, using Kyngchaos binaries and modbuild.  So, the make 
command I used is just:
make GRASS_HOME='/Users/dersh/Library/GRASS/6.4/modbuild' 
GRASS_APP='/Applications/GRASS-6.4.app'

Any thoughts or suggestions what might be going on with this?
I really am not sure if it is an issue with r.viewshed, GRASS, Mac version, mac 
building etc?

Thanks for any ideas.



--Adam



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

[GRASS-user] Import/conversion problem

[Adam Dershowitz, Ph.D., P.E.]

I am trying to import some data in GRASS and have run into a problem.  I hope 
someone can give me a little insight to help out.
I downloaded some aerial imagery from here:
http://www.michigan.gov/dnr/0,1607,7-153-10371_14546-30211--,00.html

I want to import it into a UTM zone 17 project.  So I did the following:
gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid

gdapwarp responds with an error, but then continues with the conversion:
ERROR 6: Failed to initialize PROJ.4 with `+proj=omerc +lat_0=0 +lonc=0 
+alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs '.
lat_0 = 0 or 90 or alpha = 90
0...10...20...30...40...50...60...70...80...90...100 - done.

If I then try to import the image, into my project, it does work, but places it 
WAY off from where it should be (millions of meters!).  I guess I should not be 
surprised, since the error says that it is trying to use a lat/long of 0.  But 
I don't understand why it is not working correctly.  

So, clearly something is wrong with how I am doing the conversion.  Am I 
missing a flag or something?  It looks to me like gdalinfo is doing a correct 
read, but somehow gdalwarp is missing something on the input.
Any help would be greatly appreciated.  

If I do gdalinfo on the input file, here is what I get:

Driver: MrSID/Multi-resolution Seamless Image Database (MrSID)
Files: oakgrove_sw.sid
   oakgrove_sw.sdw
   oakgrove_sw.sid.aux.xml
Size is 6415, 8061
Coordinate System is:
PROJCS[IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Projection = Oblique Mercator (Hotine)|IMAGINE,
GEOGCS[NAD83,
DATUM[North_American_Datum_1983,
SPHEROID[GRS 1980,6378137,298.2572221010002,
AUTHORITY[EPSG,7019]],
AUTHORITY[EPSG,6269]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4269]],
PROJECTION[Hotine_Oblique_Mercator],
PARAMETER[latitude_of_center,0],
PARAMETER[longitude_of_center,0],
PARAMETER[azimuth,0],
PARAMETER[rectified_grid_angle,90],
PARAMETER[scale_factor,1],
PARAMETER[false_easting,0],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]]]
Origin = (663144.500,240035.500)
Pixel Size = (1.000,-1.000)
Metadata:
  IMAGE__INPUT_NAME=K:\blk18\oakgrove_sw.tif
  IMAGE__INPUT_FILE_SIZE=155199578.00
  GEOTIFF_NUM__1024__GTModelTypeGeoKey=1
  GEOTIFF_CHAR__GTModelTypeGeoKey=ModelTypeProjected
  GEOTIFF_NUM__1025__GTRasterTypeGeoKey=1
  GEOTIFF_CHAR__GTRasterTypeGeoKey=RasterPixelIsArea
  GEOTIFF_NUM__1026__GTCitationGeoKey=IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Projection Name = Oblique Mercator (Hotine)
Units = meters
GeoTIFF Units = meters|
  GEOTIFF_NUM__2048__GeographicTypeGeoKey=4269
  GEOTIFF_CHAR__GeographicTypeGeoKey=GCS_NAD83
  GEOTIFF_NUM__2060__GeogAzimuthUnitsGeoKey=9102
  GEOTIFF_CHAR__GeogAzimuthUnitsGeoKey=Angular_Degree
  GEOTIFF_NUM__3072__ProjectedCSTypeGeoKey=32767
  GEOTIFF_CHAR__ProjectedCSTypeGeoKey=User-Defined
  GEOTIFF_NUM__3073__PCSCitationGeoKey=IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Projection Name = Oblique Mercator (Hotine)
Units = meters
GeoTIFF Units = meters|
  GEOTIFF_NUM__3074__ProjectionGeoKey=32767
  GEOTIFF_CHAR__ProjectionGeoKey=User-Defined
  GEOTIFF_NUM__3075__ProjCoordTransGeoKey=3
  GEOTIFF_CHAR__ProjCoordTransGeoKey=CT_ObliqueMercator
  GEOTIFF_NUM__3076__ProjLinearUnitsGeoKey=9001
  GEOTIFF_CHAR__ProjLinearUnitsGeoKey=Linear_Meter
  
GEOTIFF_NUM__3088__ProjCenterLongGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  
GEOTIFF_NUM__3089__ProjCenterLatGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  
GEOTIFF_NUM__3090__ProjCenterEastingGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  
GEOTIFF_NUM__3091__ProjCenterNorthingGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  
GEOTIFF_NUM__3093__ProjScaleAtCenterGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  
GEOTIFF_NUM__3094__ProjAzimuthAngleGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00
  IMAGE__Z_RESOLUTION=0.00
  GEO__ModelTypeGeoKey=1
  

Re: [GRASS-user] Import/conversion problem

[Adam Dershowitz, Ph.D., P.E.]

I am also working on OS X.  But, I am using the MrSID plugin, from William 
Kyngesburye.  So it seems that both gdalwarp and r.in.gdal are willing to 
import it.  But, maybe I will try to search around for the apps that you are 
referring to, to see if they might do a better job on the conversion.  
Are you suggesting that the MrSID plugin that I have is working, but is loosing 
reference data along the way?

--Adam



On Feb 11, 2011, at 10:47 AM, Stuart Edwards wrote:

 MrSID files are a bit tricky.  This is a proprietary format owned by 
 LizardTech (see http://www.gdal.org/frmt_mrsid.html).  That being said, they 
 freely provide decode tools at their website (http://www.lizardtech.com/).  
 Working on OS X, I use their Raster_DSDK in a little command line routine to 
 convert the file to a geotiff (tifg) and then import it into GRASS with 
 r.in.gdal.  Note that the MrSID format is very efficient and boils a quad 
 down to about 1.5 Gb.  This will become 3 or 4 times greater as a tif so make 
 sure you have plenty of room to store it and process it.  I use an old 
 version of Expressview (a LizardTech viewer that used to be available for OS 
 X) to look at the image and determine the coordinates of the bit that I 
 really want in order to minimize the resulting file sizes.
 
 AFAIK there are no open source apps that deal with MrSID directly (for those 
 that do, you have to install your own version of the decoder first)
 
 Stu
 
 
 On Feb 11, 2011, at 12:23 PM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I am trying to import some data in GRASS and have run into a problem.  I 
 hope someone can give me a little insight to help out.
 I downloaded some aerial imagery from here:
 http://www.michigan.gov/dnr/0,1607,7-153-10371_14546-30211--,00.html
 
 I want to import it into a UTM zone 17 project.  So I did the following:
 gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid
 
 gdapwarp responds with an error, but then continues with the conversion:
 ERROR 6: Failed to initialize PROJ.4 with `+proj=omerc +lat_0=0 +lonc=0 
 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs '.
 lat_0 = 0 or 90 or alpha = 90
 0...10...20...30...40...50...60...70...80...90...100 - done.
 
 If I then try to import the image, into my project, it does work, but places 
 it WAY off from where it should be (millions of meters!).  I guess I should 
 not be surprised, since the error says that it is trying to use a lat/long 
 of 0.  But I don't understand why it is not working correctly.  
 
 So, clearly something is wrong with how I am doing the conversion.  Am I 
 missing a flag or something?  It looks to me like gdalinfo is doing a 
 correct read, but somehow gdalwarp is missing something on the input.
 Any help would be greatly appreciated.  
 
 If I do gdalinfo on the input file, here is what I get:
 
 Driver: MrSID/Multi-resolution Seamless Image Database (MrSID)
 Files: oakgrove_sw.sid
  oakgrove_sw.sdw
  oakgrove_sw.sid.aux.xml
 Size is 6415, 8061
 Coordinate System is:
 PROJCS[IMAGINE GeoTIFF Support
 Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
 @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
 Projection = Oblique Mercator (Hotine)|IMAGINE,
   GEOGCS[NAD83,
   DATUM[North_American_Datum_1983,
   SPHEROID[GRS 1980,6378137,298.2572221010002,
   AUTHORITY[EPSG,7019]],
   AUTHORITY[EPSG,6269]],
   PRIMEM[Greenwich,0],
   UNIT[degree,0.0174532925199433],
   AUTHORITY[EPSG,4269]],
   PROJECTION[Hotine_Oblique_Mercator],
   PARAMETER[latitude_of_center,0],
   PARAMETER[longitude_of_center,0],
   PARAMETER[azimuth,0],
   PARAMETER[rectified_grid_angle,90],
   PARAMETER[scale_factor,1],
   PARAMETER[false_easting,0],
   PARAMETER[false_northing,0],
   UNIT[metre,1,
   AUTHORITY[EPSG,9001]]]
 Origin = (663144.500,240035.500)
 Pixel Size = (1.000,-1.000)
 Metadata:
 IMAGE__INPUT_NAME=K:\blk18\oakgrove_sw.tif
 IMAGE__INPUT_FILE_SIZE=155199578.00
 GEOTIFF_NUM__1024__GTModelTypeGeoKey=1
 GEOTIFF_CHAR__GTModelTypeGeoKey=ModelTypeProjected
 GEOTIFF_NUM__1025__GTRasterTypeGeoKey=1
 GEOTIFF_CHAR__GTRasterTypeGeoKey=RasterPixelIsArea
 GEOTIFF_NUM__1026__GTCitationGeoKey=IMAGINE GeoTIFF Support
 Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
 @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
 Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support
 Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
 @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
 Projection Name = Oblique Mercator (Hotine)
 Units = meters
 GeoTIFF Units = meters|
 GEOTIFF_NUM__2048__GeographicTypeGeoKey=4269
 GEOTIFF_CHAR__GeographicTypeGeoKey=GCS_NAD83
 GEOTIFF_NUM__2060__GeogAzimuthUnitsGeoKey=9102
 GEOTIFF_CHAR__GeogAzimuthUnitsGeoKey=Angular_Degree
 GEOTIFF_NUM__3072__ProjectedCSTypeGeoKey=32767

Re: [GRASS-user] Import/conversion problem

[Adam Dershowitz, Ph.D., P.E.]

On Feb 11, 2011, at 12:14 PM, Stuart Edwards wrote:

 I'm not familiar with the Kyngesburye plugin and haven't used gdalwarp, but 
 here:
 
 I want to import it into a UTM zone 17 project.  So I did the following:
 gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid
 
 it looks like you are just trying to create a new .sid file in zone 17 
 (output_utm.sid).  From the meta file at the MI source, I think the file is 
 already projected in utm - probably in zone 17, and with units of 'meters'.  
 So what you maybe intended was to just create a .tiffg from the .sid so that 
 it can be imported into GRASS.
 
 In mrsiddecode (the app that does all the work inside the plugin - I assume) 
 I would just issue the command
 
 ./mrsiddecode -i Hancock.sid -o Hancock_south.tif -of tifg -ulxy 0 0 -lrxy 
 71145 29160  
 
 where
 
 -i - input
 -o - output
 -of - output file type
 ulxy - upper left x,y
 lrxy - lower right x,y
 
 and you get a nice geotiff that r.in.gdal will recognize - already in utm 
 zone 17 most likely.  Actually, in my case, the OH mrsids are projected in 
 state plane coordinates but you get the picture.
 
 To get the mrsiddecode app you must register at 
 
 http://developer.lizardtech.com/ 
 
 so you can access to the Mac version of the decoder and mrsidinfo download 
 page.  And be slightly comfortable on the command line.
 
 Stu
 
 

Nope, that's not doing it.  I downloaded mrsiddecode and ran it.  It nicely 
generates a geotiff.  But, if I try to import that I still get an error because 
the project is UTM, while the image is Oblique Mercator with omerc projection.  
I tried to use gdalwarp to go from the geotiff to utm, but I get an error:

 gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84'  oak_grove_sw.tifg 
oak_grove_sw_utm.tifg
ERROR 1: latitude or longitude exceeded limits
ERROR 1: Too many points (441 out of 441) failed to transform,
unable to compute output bounds.

If I run gdalinfo on the geotiff I get it looks to me like the projection has 
lat long near 0.  So, I don't think that the problem is a MrSID problem.  But 
instead there is just something wrong with how I am doing the projection, or 
something is wrong with the file itself.

Here is the output of gdalinfo oak_grove_sw.tifg:


Driver: GTiff/GeoTIFF
Files: oak_grove_sw.tifg
Size is 6415, 8061
Coordinate System is:
PROJCS[Projection = Oblique Mercator (Hotine),
GEOGCS[NAD83,
DATUM[North_American_Datum_1983,
SPHEROID[GRS 1980,6378137,298.2572221010002,
AUTHORITY[EPSG,7019]],
AUTHORITY[EPSG,6269]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4269]],
PROJECTION[Hotine_Oblique_Mercator],
PARAMETER[latitude_of_center,0.9996],
PARAMETER[longitude_of_center,0.9996],
PARAMETER[azimuth,0.9996],
PARAMETER[rectified_grid_angle,90],
PARAMETER[scale_factor,0.9996],
PARAMETER[false_easting,0.9996],
PARAMETER[false_northing,0.9996],
UNIT[metre,1,
AUTHORITY[EPSG,9001]]]
Origin = (663144.500,240035.500)
Pixel Size = (1.000,-1.000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  663144.500,  240035.500) (  6d57'27.03E,  3d 9'14.09N)
Lower Left  (  663144.500,  231974.500) (  6d57'25.53E,  3d 4'52.96N)
Upper Right (  669559.500,  240035.500) (  7d 0'53.76E,  3d 9'12.88N)
Lower Right (  669559.500,  231974.500) (  7d 0'52.24E,  3d 4'51.77N)
Center  (  666352.000,  236005.000) (  6d59'9.64E,  3d 7'2.93N)
Band 1 Block=6415x1 Type=Byte, ColorInterp=Red
Band 2 Block=6415x1 Type=Byte, ColorInterp=Green
Band 3 Block=6415x1 Type=Byte, ColorInterp=Blue

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

[GRASS-user] Re: Import/conversion problem

[Adam Dershowitz, Ph.D., P.E.]

On Feb 11, 2011, at 9:23 AM, Adam Dershowitz, Ph.D., P.E. wrote:

 I am trying to import some data in GRASS and have run into a problem.  I hope 
 someone can give me a little insight to help out.
 I downloaded some aerial imagery from here:
 http://www.michigan.gov/dnr/0,1607,7-153-10371_14546-30211--,00.html
 
 I want to import it into a UTM zone 17 project.  So I did the following:
 gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid
 


I googled around some and it looks like this is actually an issue with the 
Michigan projection in Proj4.  

I found this link:
http://www.osgeo.org/pipermail/mapserver-users/2006-July/018292.html

And this seems to give reasonable results, based on the above:

gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' -s_srs '+proj=omerc 
+lat_0=45.30917 +lonc=-86.0 +alpha=337.25556 +k=0.9996 +x_0=499839.8337 
+y_0=528600.2398 +ellps=GRS80 +datum=NAD83 +units=m' oakgrove_sw.sid 
oakgrove_sw_utm.tifg


Then it imports into grass fine.  So, it seems like something is broken with 
that projection.

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

Re: [GRASS-user] Using Access .mdb Files

[Adam Dershowitz, Ph.D., P.E.]

The .mdb file is a proprietary Microsoft Access format.

Here is some info about importing:
http://grass.osgeo.org/wiki/Data_formats#MicroSoft_Access

One option, mentioned there, is to convert it to sqlite then import.  

These might help:
http://code.google.com/p/mdb-sqlite/
http://www.sqlite.org/cvstrac/wiki?p=ConverterTools


--Adam



On Jan 11, 2011, at 12:01 PM, Rich Shepard wrote:

  This is a new one for me. The BLM (Bureau of Land Management, one of two
 agencies that manage federal lands in the US) has land status data I'd like
 to incorporate into a project. The data come in a .mdb file. This landowner
 file has vector data.
 
  I don't see an obvious v.in.whatever appropriate for .mdb files. What
 should I use for this?
 
 Thanks,
 
 Rich
 
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] No elevation in dxf polylines

[Adam Dershowitz, Ph.D., P.E.]

A while back I received a dxf file that contained contour elevation lines.  The 
problem is that when I imported it, the polylines all showed up at elevation 0, 
instead of at their correct elevation.
At the time, I had several discussions about this, but never figured out a 
solution.  Then, a year and a half ago, I saw a similar problem crop up on this 
list, along with a final outcome that it had been fixed, but no other details 
about that.
I just received a new elevation contour dxf file, from a different source, and 
sure enough, I am having the same problem with it.  It seems to import fine, 
but the polylines all show as elevation 0.  
I tried to import both with v.in.dxf and with v.in.ogr.  In the second case, I 
also tried -z.  
I am on a Mac using Kyngesburye's GRASS-6.4.0-3-Snow.

Any suggestions would be greatly appreciated.  

Thanks,

--Adam



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

Re: [GRASS-user] No elevation in dxf polylines

[Adam Dershowitz, Ph.D., P.E.]

I hunted around some more.  
It looks like that was fixed by hcho in changeset 36804, 20 months ago.  
So, either it wasn't actually fixed correctly, or that change was not 
incorporated into the binary that I have?  Is there a way to determine that 
easily?
If it was not included, I would greatly appreciate it if, it could be added in. 
 I am hoping not to have to download and build everything, just to get this one 
fix.

Thanks,

--Adam



On Dec 14, 2010, at 5:48 AM, Adam Dershowitz, Ph.D., P.E. wrote:

 A while back I received a dxf file that contained contour elevation lines.  
 The problem is that when I imported it, the polylines all showed up at 
 elevation 0, instead of at their correct elevation.
 At the time, I had several discussions about this, but never figured out a 
 solution.  Then, a year and a half ago, I saw a similar problem crop up on 
 this list, along with a final outcome that it had been fixed, but no other 
 details about that.
 I just received a new elevation contour dxf file, from a different source, 
 and sure enough, I am having the same problem with it.  It seems to import 
 fine, but the polylines all show as elevation 0.  
 I tried to import both with v.in.dxf and with v.in.ogr.  In the second case, 
 I also tried -z.  
 I am on a Mac using Kyngesburye's GRASS-6.4.0-3-Snow.
 
 Any suggestions would be greatly appreciated.  
 
 Thanks,
 
 --Adam
 
 
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] Display 3-D volume

[Adam Dershowitz, Ph.D., P.E.]

I would like to calculate and draw a 3-D volume, but I am not really sure if 
nviz can do it, or how to accomplish it.  
In this case I have two surfaces that are both in space over a boundary.  In 
other words, there is a boundary on the ground and then there are two 
surfaces in space above them.  These surfaces are not parallel to each other.  
The surfaces are defined using vector points.  
I am able to use v.to.rast to convert these surfaces to rasters and 
r.surf.nnbathy to fill in the two surfaces.  
I can then use mapcalc to find the local elevation difference between the two 
surfaces.  But that doesn't really solve my problem.  I want to be able to draw 
a 3-D image of this volume of space, where the top of the volume is the one of 
the initial surfaces, and the bottom is the other.  Then the horizontal extent 
should be the ground boundary.
If the above is not clear, then a simplified example would be to imagine 
drawing the airspace above someone's square property that goes from 1000 ft to 
1500 ft.  The result would be a cube floating in space above the property.  In 
my case the shapes are more complicated, but the idea is the same.
Is there any way I can use grass to display this shape?  
It seems that nviz would need to have the shape as a vector shape, but I don't 
really see how I can calculate out this shape.
If anyone has any thought or ideas I would greatly appreciate hearing them.

Thanks,


--Adam



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

Re: [GRASS-user] r.out.pov scale question

[Adam Dershowitz, Ph.D., P.E.]

Thanks.  This is helpful for some ideas.  
Although, it uses a vertical scale that is just a constant of 65535.  But, my 
followup email probably crossed with yours.  



--Adam



On Nov 3, 2010, at 4:22 AM, Markus Neteler wrote:

 Adam,
 
 find attached my (old) r.out.povscript script which does the needed
 calculations. Perhaps
 giving some ideas. the Povray scales are a bit tricky.
 
 cheers
 Markus
 
 On Wed, Oct 27, 2010 at 6:07 PM, Adam Dershowitz, Ph.D., P.E.
 adershow...@exponent.com wrote:
 I have been trying to use r.out.pov but something is not clear to me from 
 the documentation, and examples I can find on the web.
 If I use hftype=0 (the default) then, as I understand it it, each step, from 
 0-65535 represents one map unit (meters in my case).  That is giving me too 
 much stair-stepping in POVRAY.
 I think that part of the issue is that there is too much rounding of 
 elevations.  So, I decided to try hrtype=1.  As I understand it that will 
 scale the height of the image to use more of the range (my map just goes 
 from 61-1086 meters).  But, I can't seem to figure out how much it scales 
 by.  There is also the scale= option in r.out.pov, but I am not sure if that 
 is a multiplier or a divider?
 This is important because I need to then scale the heighfield in my POV 
 file.  If I use hrtype=0 then this is correct:
 scale  dx, 65535, dy 
 
 But, if I use hftype=1, what is the correct value for the above scale 
 command?  Is it 65535/1086 (max height in the map?)
 65535/(1086-61)  (vertical range of my map?)
 
 If I use scale=10 then should it be?
 scale  dx, 65535/10, dy 
 scale  dx, 65535*10, dy 
 scale  dx, 10, dy 
 
 Or should I use scale=0.1?  Or should I use r.out.pov scale=65535/1086
 
 Thanks,
 
 --Adam
 
 
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 r.out.povscript

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

Re: [GRASS-user] r.out.pov scale question

[Adam Dershowitz, Ph.D., P.E.]

I have not heard anything back on this, so decided to go to the source code of 
r.out.pov.  I figured out the answer and wanted to post it, in case it is 
useful to anyone else, or someone might want to add it to the help page.
Here is what I figured out.  
1)  scale, and hftype are independent.  
So, first each cell is multiplied by scale (so, if a cell elevation is 12m and 
scale is 10, then the new value is 120.)  The default value of scale is 1.0.  
If hftype is set to 1, then each cell is multiplied by 65535/(maximum elevation 
value in the map).  

So, when using hftype=1, the correct scaling in the POV ray file is the maximum 
height in the map.  For example, if the maximum elevation is 1086 m, then this 
should go in the POV file:
scale  1391, 1086, 1810  // dx,dz,dy of extent in meters

Finally, I believe that there is a bug in r.out.pov!  It seems that bias is 
read in, in order to apply a bias to the height field, however hfBias is the 
variable that is actually being used for the calculations, and it is never 
assigned a value.  And bias is not actually used in any calculations.

--Adam



On Oct 27, 2010, at 9:07 AM, Adam Dershowitz, Ph.D., P.E. wrote:

 I have been trying to use r.out.pov but something is not clear to me from the 
 documentation, and examples I can find on the web.
 If I use hftype=0 (the default) then, as I understand it it, each step, from 
 0-65535 represents one map unit (meters in my case).  That is giving me too 
 much stair-stepping in POVRAY.  
 I think that part of the issue is that there is too much rounding of 
 elevations.  So, I decided to try hrtype=1.  As I understand it that will 
 scale the height of the image to use more of the range (my map just goes from 
 61-1086 meters).  But, I can't seem to figure out how much it scales by.  
 There is also the scale= option in r.out.pov, but I am not sure if that is a 
 multiplier or a divider?  
 This is important because I need to then scale the heighfield in my POV file. 
  If I use hrtype=0 then this is correct:
 scale  dx, 65535, dy 
 
 But, if I use hftype=1, what is the correct value for the above scale 
 command?  Is it 65535/1086 (max height in the map?)
 65535/(1086-61)  (vertical range of my map?)
 
 If I use scale=10 then should it be?
 scale  dx, 65535/10, dy 
 scale  dx, 65535*10, dy 
 scale  dx, 10, dy 
 
 Or should I use scale=0.1?  Or should I use r.out.pov scale=65535/1086
 
 Thanks,
 
 --Adam
 
 
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Database question

[Adam Dershowitz, Ph.D., P.E.]

Thanks.  That is just what I needed!
(There was still a little trick that the first time I used it I used the whole 
path to the old db, instead of just sqlite.db.  The path failed, while just the 
file name worked)



--Adam



On Oct 25, 2010, at 11:30 AM, Achim Kisseler wrote:

 Hi,
 
 try v.db.reconnect.all or v.db.connect for single vector layers.
 
 Achim
 
 Am 25.10.2010 18:54, schrieb Adam Dershowitz, Ph.D., P.E.:
 This seems like it must be really easy and I am just missing something
 I have a project but I accidentally created the sqlite database file in the 
 wrong location.
 So, all of my project files are in one directory, but, in my home directory 
 I have a file sqlite.db.
 
 I just moving that file to where I want it.  Then I did:
 db.connect driver=sqlite database=/NewLocation/test.db
 
 Now if I do db.connect -p I see the correct path, but if I try to access a 
 vector that uses that database I get an error No such table.
 If I move the file back to the old location then the error goes away, even 
 if I don't use db.connect to point to the other location.  So, I am just 
 missing something about how to have grass know the correct location of a 
 database.
 If I just move the file, how can I get the vector map to know the correct 
 file to use, since db.connect is not doing the job?
 
 Thanks.
 
 --Adam
 
 
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Import question

[Adam Dershowitz, Ph.D., P.E.]

On Oct 1, 2010, at 4:06 AM, Micha Silver wrote:

 On 10/01/2010 01:35 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 I have a series of points in an ascii files that represent points along a 
 line.  I would like to import them as a line, or import and convert to a 
 line.
 I see that 6.5 has v.in.lines, but I am using 6.4.  Is there any other way 
 to do that conversion?
 
 The data is 3D x,y,z points.  I can just import them using v.in.ascii, but 
 then they are points, with no lines.  Is there another way to either import, 
 directly, or convert?
 
   
 If it's only one line, then the simplest might be to re-write the ASCII file 
 formated in the GRASS standard format, as a line. You'll need to add the 
 header lines, something like:
 VERTI:
 L n 1
 X_coord Y_coord
 ...
 ...
 1 1
 
 Where 'n' is the number of points.
 
 Then run v.in.ascii ... format=standard and it should result in a line vector.



Thanks.  It is actually one line, at the moment, so I did that, and it worked 
fine.  But I will have others.  so was hoping for a generic solution.  I wrote 
a shell script that transforms my particular data into standard and it seems 
to be working fine.

Again, thanks for the response.

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

Re: [GRASS-user] Import question

[Adam Dershowitz, Ph.D., P.E.]

On Oct 1, 2010, at 4:18 PM, Hamish wrote:

 Adam wrote:
 I see that 6.5 has v.in.lines, but I am using 6.4.
 
 since it seems to be open season on backporting stuff, if there
 is widespread demand, and no objections, I'd consider backporting
 it for 6.4.1. but really it is just a wrapper script around
 v.in.mapgen. the most valuable thing about it is the easy to
 understand module name.
 
 
 

Thanks.  Once I heard that it is just a script, I downloaded it myself.  So, 
don't backport it on my account.  But, I do appreciate the thought.

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

[GRASS-user] Import question

[Adam Dershowitz, Ph.D., P.E.]

I have a series of points in an ascii files that represent points along a line. 
 I would like to import them as a line, or import and convert to a line.
I see that 6.5 has v.in.lines, but I am using 6.4.  Is there any other way to 
do that conversion?

The data is 3D x,y,z points.  I can just import them using v.in.ascii, but then 
they are points, with no lines.  Is there another way to either import, 
directly, or convert?

Thanks,

--Adam



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

[GRASS-user] Import question

[Adam Dershowitz, Ph.D., P.E.]

I have a large ortho image, that is in MrSID format  (A full county at high 
res).  The file is ~3.5 gig.  It covers a much larger area then I need.  So I 
set my region to the size that I do need, and then imported.  The import took 
something like 10 hrs.  And, I now see that in my PERMANENT folder I have 3 
files that are each 15 gig (one red, one blue, one green),  
The map was imported, but if I zoom to the size of the current map, it seems 
that the whole map was imported, not just the area inside the current region.
  
I thought that imports are cropped to the current region?  Am I mistaken about 
this?  Is there some setting to cause this to happen?  

I did the import with r.in.gdal.  I am using the binary release of 6.4 on a 
Mac.  
The reasons that I care are 1)  This map, for a small area of interest, it 
taking up 45 gig on my hard drive.  2)  Because the map is so large, it takes a 
while for the display to update when I make any changes.  

Any guidance?

Thanks,

--Adam



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

[GRASS-user] Planet coordinate systems?

[Adam Dershowitz, Ph.D., P.E.]

I am interested if anyone has used GRASS with data from Mars, or any other 
non-earth based system?  I don't see any epsg codes that would apply.  
So, I am looking for some general ideas and guidance to get going.  
If anyone has used GRASS this way, please let me know about your experience, 
useful links, or other things that might be helpful to deal with some of the 
existing planetary data, and how to use it.

Thanks,


--Adam



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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

Thanks.  I ended up just selecting each point, then typing them into the GCP 
dialog.  Very annoying, but it did the job.

--Adam



On Dec 1, 2009, at 8:01 PM, Richard Chirgwin wrote:

 Adam,
 
 If all else fails, work with a command line process ... I've never had happy 
 experiences with the purely GUI rectification.
 
 i.group (groupname) (mapname)
 i.target (groupname) Target_Location Target_Mapset
 d.mon X0
 i.points (groupname) - this launches the GCP capture GUI (old style, 
 X-windows but it works!)
 i.rectify (groupname) extension=something order=(polynomial order)
 
 RC
 --
 
 Message: 1
 Date: Mon, 30 Nov 2009 14:38:04 -0700
 From: Michael Barton michael.bar...@asu.edu
 Subject: Re: [GRASS-user] Georectify problem
 To: grass-user@lists.osgeo.org grass-user@lists.osgeo.org
 Message-ID: 6c956e66-153c-4152-809e-b4c28ab74...@asu.edu
 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
 
 Given the platform you are on and the fact that you are using an up-to- date 
 build of GRASS 6.4, I recommend you do this with the new wxPython  GUI 
 instead of the TclTk one. I think it will work better for you.
 
 Michael
 
 On Nov 30, 2009, at 2:16 PM, grass-user-requ...@lists.osgeo.org wrote:
 
  
 Date: Mon, 30 Nov 2009 09:57:42 -0800
 From: Adam Dershowitz adershow...@exponent.com
 Subject: [GRASS-user] Georectify problem
 To: GRASS user list grass-user@lists.osgeo.org
 Message-ID: 684bacb4-ceaf-4cdd-98d1-9f3ee5742...@exponent.com
 Content-Type: text/plain; charset=us-ascii
 
 I am trying to georectify an xy image.  I think that I am doing  things 
 correctly yet I keep getting an error.  Perhaps someone can  clear things 
 up for me.
 I imported the image into an XY location.  I then went to the  location 
 that I want to import into and brought up a map so I could  click on points.
 If then select file- georectify.  I fill in the info and then click  Start 
 georectifying.  It brings up the manage ground control points  window and a 
 display showing the xy map to be georectified.  If I  click there I can add 
 the GCP xy coords.  But if I then click in my  original window to select 
 the georgraphic coords I get an error:  can't read b1 coords : no such 
 variable.
 
 can't read b1coords: no such variable
 can't read b1coords: no such variable
   while executing
 $geoentry insert 0 $b1coords
   invoked from within
 if { [info exists geoentry] } {
   $geoentry insert 0 $b1coords
   }
   (command bound to event)
 
 I can't figure out why it will not let me select the points.  I have  
 selected the arrow tool in the map display.
 
 I am using a Mac with William Kyngesburye's binary builds.  I have  6.4 
 RC5-3 Snow with OS 10.6.2
 
 Thanks,
 
 --Adam

 
 
 
 --
 
 Message: 2
 Date: Mon, 30 Nov 2009 14:40:45 -0700
 From: Michael Barton michael.bar...@asu.edu
 Subject: Re: [GRASS-user] Trouble setting location and projection
 To: grass-user@lists.osgeo.org grass-user@lists.osgeo.org
 Message-ID: 01b9bf6f-b613-45fa-8520-38ec61489...@asu.edu
 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
 
 
 
 On Nov 30, 2009, at 2:16 PM, grass-user-requ...@lists.osgeo.org wrote:
 
  
 Date: Mon, 30 Nov 2009 13:03:16 -0600
 From: Ross Benisch benisc...@hotmail.com
 Subject: [GRASS-user] Trouble setting location and projection
 To: grass-user@lists.osgeo.org
 Message-ID: col121-w561c882825f5984eb916e8b6...@phx.gbl
 Content-Type: text/plain; charset=iso-8859-1
 
 
 I am trying to set the project location and cordinate system using  the 
 6.4.0svn version for windows but I keep getting the projection  error,
 
 'g.proj.exe-p' when I try and start Grass.  I have a GIS background  and I 
 am frustrated that I can't get it to work. I want to use the  projection 
 nad83UTM Zone 14N.  I have read through all of the  tuturiols and help 
 sheets and looked at the FAQs with no such luck.   I really want to use 
 this program to help with my job so if you  would help me get started I 
 would greatly appreciate it.
 
 
 
 Sincerely,
 
 Ross Benisch

 
 Can you give us some more specific information? Are you using the  location 
 wizard? Is this the newest windows binary? Which version of  Windows are you 
 using? What exactly is the error message that you get?
 
 Michael
 
 
 --
 
 Message: 3
 Date: Tue, 01 Dec 2009 01:37:43 +0100
 From: Helmut Kudrnovsky hel...@web.de
 Subject: [GRASS-user] Trouble setting location and projection
 To: grass-user@lists.osgeo.org
 Message-ID:
  5304763.17158.1259627864390.javamail.fm...@fmcert01.dlan.cinetic.de
 Content-Type: text/plain; charset=iso-8859-15
 
 
  
 I am trying to set the project location and cordinate system using the 
 6.4.0svn version for windows but I keep getting the projection error, 
 'g.proj.exe-p' when I try and start Grass.  I have a GIS background and I 
 am frustrated

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

I did try it, but I can't currently get it to run.  My guess is that it is an 
issue of the current built of GRASS that I am using (6.4 RC5-3 on a 64 bit 
machine):

g.gui wxpython
Traceback (most recent call last):
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py, line 
55, in module
import gui_modules.globalvar as globalvar
  File 
/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
 line 59, in module
import wx
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py, 
line 45, in module
from wx._core import *
  File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py, 
line 4, in module
import _core_
ImportError: 
dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 2): 
no suitable image found.  Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so: 
mach-o, but wrong architecture



--Adam



On Dec 2, 2009, at 6:47 AM, Michael Barton wrote:

 Important to note that this will not work with Windows, since Windows doesn't 
 run x11 unless you the Cygwin unix emulator.
 
 Have you tried georectification with the new wxPython GUI?
 
 Michael
 
 
 On Dec 1, 2009, at 11:20 PM, grass-user-requ...@lists.osgeo.org wrote:
 
 Date: Wed, 02 Dec 2009 15:01:23 +1100
 From: Richard Chirgwin rchirg...@ozemail.com.au
 Subject: [GRASS-user] Re: Georectify problem
 To: grass-user@lists.osgeo.org
 Message-ID: 4b15e693.1010...@ozemail.com.au
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 Adam,
 
 If all else fails, work with a command line process ... I've never had
 happy experiences with the purely GUI rectification.
 
 i.group (groupname) (mapname)
 i.target (groupname) Target_Location Target_Mapset
 d.mon X0
 i.points (groupname) - this launches the GCP capture GUI (old style,
 X-windows but it works!)
 i.rectify (groupname) extension=something order=(polynomial order)
 
 RC
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

Sorry, Mac 10.6.2 using William Kyngesburye's binary builds.

--Adam



On Dec 2, 2009, at 8:35 AM, Michael Barton wrote:

 What OS platform?
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:34 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I did try it, but I can't currently get it to run.  My guess is that it is 
 an issue of the current built of GRASS that I am using (6.4 RC5-3 on a 64 
 bit machine):
 
 g.gui wxpython
 Traceback (most recent call last):
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py, 
 line 55, in module
   import gui_modules.globalvar as globalvar
 File 
 /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
  line 59, in module
   import wx
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py, 
 line 45, in module
   from wx._core import *
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py, 
 line 4, in module
   import _core_
 ImportError: 
 dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 
 2): no suitable image found.  Did find:
  /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so: 
 mach-o, but wrong architecture
 
 
 
 --Adam
 
 
 
 On Dec 2, 2009, at 6:47 AM, Michael Barton wrote:
 
 Important to note that this will not work with Windows, since Windows 
 doesn't run x11 unless you the Cygwin unix emulator.
 
 Have you tried georectification with the new wxPython GUI?
 
 Michael
 
 
 On Dec 1, 2009, at 11:20 PM, grass-user-requ...@lists.osgeo.org wrote:
 
 Date: Wed, 02 Dec 2009 15:01:23 +1100
 From: Richard Chirgwin rchirg...@ozemail.com.au
 Subject: [GRASS-user] Re: Georectify problem
 To: grass-user@lists.osgeo.org
 Message-ID: 4b15e693.1010...@ozemail.com.au
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 Adam,
 
 If all else fails, work with a command line process ... I've never had
 happy experiences with the purely GUI rectification.
 
 i.group (groupname) (mapname)
 i.target (groupname) Target_Location Target_Mapset
 d.mon X0
 i.points (groupname) - this launches the GCP capture GUI (old style,
 X-windows but it works!)
 i.rectify (groupname) extension=something order=(polynomial order)
 
 RC
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 

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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

I do have python installed as I have a bunch of things installed with macports 
and some of them depend on it and so installed it as part of the builds.  So I 
can't really get rid of it.  But, as part of macports, I do have python_select, 
which is a small port that allows me to switch which python is active and I am 
currently using the Apple installed Python 2.6, not one of the Macport 
installed versions.  So I don't think that is the problem?
I am downloading one of your builds to test out right now.

Thanks,

--Adam



On Dec 2, 2009, at 8:53 AM, Michael Barton wrote:

 Did you install Python yourself? If so, you will need to get rid of it. I 
 know how to do so with 10.5, but am not sure of 10.6. William might be able 
 to offer guidance on this.
 
 If you did not install a separate Python, I'm not sure what the problem is. 
 But you can try one of my builds. They work with Snow Leopard on at least one 
 student machine I know of. I've posted very recent binaries for 6.4, 6.5, and 
 7.0.
 
 http://www.public.asu.edu/~cmbarton/files/grass_mac
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:44 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 Sorry, Mac 10.6.2 using William Kyngesburye's binary builds.
 
 --Adam
 
 
 
 On Dec 2, 2009, at 8:35 AM, Michael Barton wrote:
 
 What OS platform?
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:34 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I did try it, but I can't currently get it to run.  My guess is that it is 
 an issue of the current built of GRASS that I am using (6.4 RC5-3 on a 64 
 bit machine):
 
 g.gui wxpython
 Traceback (most recent call last):
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py, 
 line 55, in module
 import gui_modules.globalvar as globalvar
 File 
 /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
  line 59, in module
 import wx
 File 
 /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/__init__.py, 
 line 45, in module
 from wx._core import *
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py, 
 line 4, in module
 import _core_
 ImportError: 
 dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so, 
 2): no suitable image found.  Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core_.so: 
 mach-o, but wrong architecture
 
 
 
 --Adam
 
 
 
 On Dec 2, 2009, at 6:47 AM, Michael Barton wrote:
 
 Important to note that this will not work with Windows, since Windows 
 doesn't run x11 unless you the Cygwin unix emulator.
 
 Have you tried georectification with the new wxPython GUI?
 
 Michael
 
 
 On Dec 1, 2009, at 11:20 PM, grass-user-requ...@lists.osgeo.org wrote:
 
 Date: Wed, 02 Dec 2009 15:01:23 +1100
 From: Richard Chirgwin rchirg...@ozemail.com.au
 Subject: [GRASS-user] Re: Georectify problem
 To: grass-user@lists.osgeo.org
 Message-ID: 4b15e693.1010...@ozemail.com.au
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 Adam,
 
 If all else fails, work with a command line process ... I've never had
 happy experiences with the purely GUI rectification.
 
 i.group (groupname) (mapname)
 i.target (groupname) Target_Location Target_Mapset
 d.mon X0
 i.points (groupname) - this launches the GCP capture GUI (old style,
 X-windows but it works!)
 i.rectify (groupname) extension=something order=(polynomial order)
 
 RC
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 
 
 

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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

For each port that you install with macports it determines what other ports are 
necessary.  Macports project has taken the attitude that they always want to 
use their own version of code so that changes by Apple won't break other 
specific dependencies, which has happened to them a number of times.  That 
leads to most ports working well, but can lead to other problems, so their are 
some pluses and minus to this approach.  But, that is the current approach, and 
if I were to try to force uninstall any python stuff, it would break other 
ports.  Apple actually has 2.6.1 installed, while macports installs 2.6.4.  
That said, python_select just changes links and moves files around so that only 
one version of python is visible and the others are hidden, except to 
explicit paths.  And I have confirmed that from the command line using 
python_select does change which version gets used.
So, according to macports, I have python2.5 python2.6 and python26-apple 
installed right now, but only the apple version should be visible, so I doubt 
that this is causing the problem.

--Adam



On Dec 2, 2009, at 9:11 AM, Michael Barton wrote:

 If you have a second python and it is in your python path, you'll have 
 trouble. Do you know what the Macports python_select script does?
 
 You really don't need to install any extra Python because your Mac already 
 comes with Python 2.6, the most up-to-date of the 2.x series. It should not 
 be necessary to run anything downloaded from MacPorts as any Python app 
 should use the system Python unless it needs an earlier version. If MacPorts 
 is installing 2.3 or 2.4 this could be a pretty big headache since GRASS 
 requires at least 2.4 and possibly 2.5 or above to run its wxPython GUI 
 (we've tried not to break 2.4 compatibility but I haven't tested it). I've 
 heard of other people having trouble with conflicts from MacPorts. I uses to 
 use Fink but ran into some of the same issues. And by now I don't really need 
 it since many applications are now available on the Mac in a more native way. 
 You might try getting rid of the MacPorts Python and see if GRASS run--and if 
 MacPorts Python apps still run.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 10:00 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I do have python installed as I have a bunch of things installed with 
 macports and some of them depend on it and so installed it as part of the 
 builds.  So I can't really get rid of it.  But, as part of macports, I do 
 have python_select, which is a small port that allows me to switch which 
 python is active and I am currently using the Apple installed Python 2.6, 
 not one of the Macport installed versions.  So I don't think that is the 
 problem?
 I am downloading one of your builds to test out right now.
 
 Thanks,
 
 --Adam
 
 
 
 On Dec 2, 2009, at 8:53 AM, Michael Barton wrote:
 
 Did you install Python yourself? If so, you will need to get rid of it. I 
 know how to do so with 10.5, but am not sure of 10.6. William might be able 
 to offer guidance on this.
 
 If you did not install a separate Python, I'm not sure what the problem is. 
 But you can try one of my builds. They work with Snow Leopard on at least 
 one student machine I know of. I've posted very recent binaries for 6.4, 
 6.5, and 7.0.
 
 http://www.public.asu.edu/~cmbarton/files/grass_mac
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:44 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 Sorry, Mac 10.6.2 using William Kyngesburye's binary builds.
 
 --Adam
 
 
 
 On Dec 2, 2009, at 8:35 AM, Michael Barton wrote:
 
 What OS platform?
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:34 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I did try it, but I can't currently get it to run.  My guess is that it 
 is an issue of the current built of GRASS that I am using (6.4 RC5-3 on 
 a 64 bit machine):
 
 g.gui wxpython
 Traceback (most recent call last):
 File /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py, 
 line 55, in module
 import gui_modules.globalvar as globalvar
 File 
 /Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
  line 59

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

I just tried your 6.4 build and I noticed two things.  1)  When I double click 
on it, I see this in the terminal:
Rebuilding Addon menu...
Python 2.5.4 found.

But, if I try to switch to the non-default gui, here is what I get:

  g.gui wxpython
Traceback (most recent call last):
  File 
/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/wxpython/wxgui.py,
 line 55, in module
import gui_modules.globalvar as globalvar
  File 
/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py,
 line 62, in module
import wx
  File 
/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/python/wx/__init__.py,
 line 45, in module
from wx._core import *
  File 
/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/python/wx/_core.py,
 line 4, in module
import _core_
ImportError: 
dlopen(/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/python/wx/_core_.so,
 2): no suitable image found.  Did find:

/Applications/Grass/GRASS-6.4_Barton.app/Contents/MacOS/etc/python/wx/_core_.so:
 no matching architecture in universal wrapper

While, when I run William Kyngesburye's build I see this in the terminal:
Rebuilding Addon menu...
Python 2.6.4 found.

But, at the command line, if I just do python, I end up with Apple version 
2.6.1.  I will also ask about this on the macports list, which is very active.

For what it is worth, I know that in the past, with 10.5, and Macports 
installed I was able to run the wxpython version, but I can't seem to get it to 
work now.  

--Adam



On Dec 2, 2009, at 9:11 AM, Michael Barton wrote:

 If you have a second python and it is in your python path, you'll have 
 trouble. Do you know what the Macports python_select script does?
 
 You really don't need to install any extra Python because your Mac already 
 comes with Python 2.6, the most up-to-date of the 2.x series. It should not 
 be necessary to run anything downloaded from MacPorts as any Python app 
 should use the system Python unless it needs an earlier version. If MacPorts 
 is installing 2.3 or 2.4 this could be a pretty big headache since GRASS 
 requires at least 2.4 and possibly 2.5 or above to run its wxPython GUI 
 (we've tried not to break 2.4 compatibility but I haven't tested it). I've 
 heard of other people having trouble with conflicts from MacPorts. I uses to 
 use Fink but ran into some of the same issues. And by now I don't really need 
 it since many applications are now available on the Mac in a more native way. 
 You might try getting rid of the MacPorts Python and see if GRASS run--and if 
 MacPorts Python apps still run.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 10:00 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 I do have python installed as I have a bunch of things installed with 
 macports and some of them depend on it and so installed it as part of the 
 builds.  So I can't really get rid of it.  But, as part of macports, I do 
 have python_select, which is a small port that allows me to switch which 
 python is active and I am currently using the Apple installed Python 2.6, 
 not one of the Macport installed versions.  So I don't think that is the 
 problem?
 I am downloading one of your builds to test out right now.
 
 Thanks,
 
 --Adam
 
 
 
 On Dec 2, 2009, at 8:53 AM, Michael Barton wrote:
 
 Did you install Python yourself? If so, you will need to get rid of it. I 
 know how to do so with 10.5, but am not sure of 10.6. William might be able 
 to offer guidance on this.
 
 If you did not install a separate Python, I'm not sure what the problem is. 
 But you can try one of my builds. They work with Snow Leopard on at least 
 one student machine I know of. I've posted very recent binaries for 6.4, 
 6.5, and 7.0.
 
 http://www.public.asu.edu/~cmbarton/files/grass_mac
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:44 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 Sorry, Mac 10.6.2 using William Kyngesburye's binary builds.
 
 --Adam
 
 
 
 On Dec 2, 2009, at 8:35 AM, Michael Barton wrote:
 
 What OS platform?
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 9:34 AM, Adam Dershowitz, Ph.D

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

I didn't install wxPython and neither did macports.

Macports is all installed in /opt/local and my .profile just adds that to my 
PATH and LIBRARY_PATH.  

I find it very odd that your build and William's build are finding different 
versions of python (and neither is the apple one).

By the way, if I run either of them, and then at the command line I run python, 
I do see the expected one.  In other words, yours reports Python 2.5.4 found. 
but then if I type python it shows 2.6.1, (while Williams reports 2.6.4)

How are you searching for python?  Are you not just using the typical path from 
.profile?

--Adam



On Dec 2, 2009, at 9:34 AM, Michael Barton wrote:

 Did you install wxPython? Did Macports?
 
 I understand how MacPorts works in this regard. Fink does the same thing, 
 though you can opt not to install dependencies and can also install binaries 
 that might need the dependencies (i.e., only needed to compile). This is a 
 Linux-like package installer model. It is handy but can have problems playing 
 nicely with other unix software installed on your system outside of the 
 MacPorts (or Fink) package hierarchy. I know that both try to wall off their 
 stuff into separate areas, but sometimes it doesn't work.
 
 To try and overcome the complications of having more than one Python version 
 and more than one wxPython version, both William and I now include a wxPython 
 build in our GRASS binaries. However, I'm not sure what will happen in a 
 situation like yours. Hopefully my binary will work.
 
 You might need to search out and look at your various system configuration 
 files and see if any of them refer to the MacPorts Python. These normally 
 live in your home folder and the etc folder. They begin with a ., so are 
 invisible unless you run something like Invisibility Toggler.app, use Text 
 Wrangler's open hidden function, or use the command line utilties.
 
 Files to look for include .profile and .bashrc. There might be others too 
 depending on how MacPorts manages setting system configurations.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 10:24 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 For each port that you install with macports it determines what other ports 
 are necessary.  Macports project has taken the attitude that they always 
 want to use their own version of code so that changes by Apple won't break 
 other specific dependencies, which has happened to them a number of times.  
 That leads to most ports working well, but can lead to other problems, so 
 their are some pluses and minus to this approach.  But, that is the current 
 approach, and if I were to try to force uninstall any python stuff, it would 
 break other ports.  Apple actually has 2.6.1 installed, while macports 
 installs 2.6.4.
 That said, python_select just changes links and moves files around so that 
 only one version of python is visible and the others are hidden, except to 
 explicit paths.  And I have confirmed that from the command line using 
 python_select does change which version gets used.
 So, according to macports, I have python2.5 python2.6 and python26-apple 
 installed right now, but only the apple version should be visible, so I 
 doubt that this is causing the problem.
 
 --Adam
 
 
 
 On Dec 2, 2009, at 9:11 AM, Michael Barton wrote:
 
 If you have a second python and it is in your python path, you'll have 
 trouble. Do you know what the Macports python_select script does?
 
 You really don't need to install any extra Python because your Mac already 
 comes with Python 2.6, the most up-to-date of the 2.x series. It should not 
 be necessary to run anything downloaded from MacPorts as any Python app 
 should use the system Python unless it needs an earlier version. If 
 MacPorts is installing 2.3 or 2.4 this could be a pretty big headache since 
 GRASS requires at least 2.4 and possibly 2.5 or above to run its wxPython 
 GUI (we've tried not to break 2.4 compatibility but I haven't tested it). 
 I've heard of other people having trouble with conflicts from MacPorts. I 
 uses to use Fink but ran into some of the same issues. And by now I don't 
 really need it since many applications are now available on the Mac in a 
 more native way. You might try getting rid of the MacPorts Python and see 
 if GRASS run--and if MacPorts Python apps still run.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 On Dec 2, 2009, at 10:00 AM, Adam Dershowitz, Ph.D., P.E. wrote

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

On Dec 2, 2009, at 10:20 AM, William Kyngesburye wrote:

 On Dec 2, 2009, at 11:43 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 While, when I run William Kyngesburye's build I see this in the terminal:
 Rebuilding Addon menu...
 Python 2.6.4 found.
 
 But, at the command line, if I just do python, I end up with Apple version 
 2.6.1.  I will also ask about this on the macports list, which is very 
 active.
 
 For what it is worth, I know that in the past, with 10.5, and Macports 
 installed I was able to run the wxpython version, but I can't seem to get it 
 to work now.  
 
 Where does MacPorts install its Python?  And is it a frameowrk build?  I know 
 it normally keeps everything isolated in its own folder, but maybe Python is 
 different, if it's a framework.

It does put it into /opt/local.  Yes, it is a framework build, but in the 
macports directories.  So it puts a few things into /opt/local/bin and 
opt/local/lib but most of it goes into 
/opt/local/Library/Frameworks/Python.framework

 
 The way I have the python detection setup in the OSX startup, the first 
 priority is always the same major.minor version it was built with, and for my 
 Snow build it's 2.6.  Then the priorities are:
 
 $GRASS_PYTHON setting
 in $PATH
 /Library/Frameworks/Python.framework
 System python
 
 So, if you have the system python in your PATH (running python from a 
 Terminal), somehow that is failing, and if MacPorts python is in 
 /Library/Frameworks, it finds that.
 
 What does this give you:
 
 type -p pythonw2.6

type -p pythonw2.6
/opt/local/bin/pythonw2.6

 
 and this:
 
 `type -p pythonw2.6` -V

`type -p pythonw2.6` -V
Python 2.6.4


 
 Then we get to the architectures.  Does MacPorts build universal by default 
 or just the default ssytem architecture?  Try:
 
 file /path/to/macports/python/bin/python

file /opt/local/bin/python2.6
/opt/local/bin/python2.6: Mach-O 64-bit executable x86_64

 
 If it's only x86_64 (default on Snow), then yes wxpython will fail, as that 
 is only possible 32bit.
 

So, yes this one is x84_64 only.  

But this one:

file /opt/local/bin/python
/opt/local/bin/python: Mach-O universal binary with 3 architectures
/opt/local/bin/python (for architecture x86_64):Mach-O 64-bit 
executable x86_64
/opt/local/bin/python (for architecture i386):  Mach-O executable i386
/opt/local/bin/python (for architecture ppc7400):   Mach-O executable ppc

is not.  

And I was able to determine that python_select is just a script.  What it does 
to select the apple version of python is just the following:

ln -sf python26-apple /opt/local/etc/select/python/current
ln -snf /usr/bin/python2.6 /opt/local/bin/python
ln -snf /usr/bin/pythonw2.6 /opt/local/bin/pythonw
ln -snf /usr/bin/python2.6-config /opt/local/bin/python-config
rm -f /opt/local/bin/idle
ln -snf /usr/bin/pydoc2.6 /opt/local/bin/pydoc
ln -snf /usr/bin/smtpd2.6.py /opt/local/bin/smtpd.py
rm -f /opt/local/share/man/man1/python.1
ln -snf /usr/share/man/man1/python2.6.1.gz /opt/local/share/man/man1/python.1.gz
rm -f /opt/local/Library/Frameworks/Python.framework/Versions/Current
rm -f /opt/local/Library/Frameworks/Python.framework/Headers
rm -f /opt/local/Library/Frameworks/Python.framework/Resources
rm -f /opt/local/Library/Frameworks/Python.framework/Python

So it looks to me like it should be creating the correct links.  So if I do 
this:
which python
/opt/local/bin/python
I do get the link in macports, but that is just a link to the apple version.  

I just noticed something however.  Are you actually searching for python or 
python2.6 as your first priority?  The reason that I am asking is that 
python does point to the apple version. But python2.6 points to the macports 
version.  I wonder if that is the problem?
Finally, you said that you actually start by trying $GRASS_PYTHON.  If, my my 
.profile,  I just point that to the system python should that fix this issue?

Thanks,

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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

On Dec 2, 2009, at 10:20 AM, William Kyngesburye wrote:

 On Dec 2, 2009, at 11:43 AM, Adam Dershowitz, Ph.D., P.E. wrote:
 
 While, when I run William Kyngesburye's build I see this in the terminal:
 Rebuilding Addon menu...
 Python 2.6.4 found.
 
 But, at the command line, if I just do python, I end up with Apple version 
 2.6.1.  I will also ask about this on the macports list, which is very 
 active.
 
 For what it is worth, I know that in the past, with 10.5, and Macports 
 installed I was able to run the wxpython version, but I can't seem to get it 
 to work now.  
 
 Where does MacPorts install its Python?  And is it a frameowrk build?  I know 
 it normally keeps everything isolated in its own folder, but maybe Python is 
 different, if it's a framework.
 
 The way I have the python detection setup in the OSX startup, the first 
 priority is always the same major.minor version it was built with, and for my 
 Snow build it's 2.6.  Then the priorities are:
 
 $GRASS_PYTHON setting
 in $PATH
 /Library/Frameworks/Python.framework
 System python

Success!  
Just doing this in my .profile:
 export GRASS_PYTHON=/usr/bin/pythonw2.6

solved the problem.  So I think that the issue is that macports just makes 
links for python and pythonw while you were actually searching for 
pythonw2.6.

But, Micheal, this fix doesn't work for your build.  I think that reason is 
that your version of MacOS/grass.sh in 6.4 (I haven't checked any others) 
actually contains this:
pyver_want=2.5

While William's contains this:
pyver_want=2.6

So, your version is searching for, and finding, pythonw2.5, which is the 
macports only version.  If macports wasn't installed, then it would move on to 
the 2.6 version, since it can't find 2.5.  

Thanks for all the help from both of you
Although I have not yet tried to georectify with wxpython, which was the whole 
point of this exercise initially.

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

Re: [GRASS-user] Re: Georectify problem

[Adam Dershowitz, Ph.D., P.E.]

On Dec 2, 2009, at 6:47 AM, Michael Barton wrote:

 Important to note that this will not work with Windows, since Windows doesn't 
 run x11 unless you the Cygwin unix emulator.
 
 Have you tried georectification with the new wxPython GUI?

Again, thanks for the help.  After that problem with getting wxPython to work, 
yes the georectify seems to work in the wxPython gui version.


 
 Michael
 
 
 On Dec 1, 2009, at 11:20 PM, grass-user-requ...@lists.osgeo.org wrote:
 
 Date: Wed, 02 Dec 2009 15:01:23 +1100
 From: Richard Chirgwin rchirg...@ozemail.com.au
 Subject: [GRASS-user] Re: Georectify problem
 To: grass-user@lists.osgeo.org
 Message-ID: 4b15e693.1010...@ozemail.com.au
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
 Adam,
 
 If all else fails, work with a command line process ... I've never had
 happy experiences with the purely GUI rectification.
 
 i.group (groupname) (mapname)
 i.target (groupname) Target_Location Target_Mapset
 d.mon X0
 i.points (groupname) - this launches the GCP capture GUI (old style,
 X-windows but it works!)
 i.rectify (groupname) extension=something order=(polynomial order)
 
 RC
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] Georectify problem

[Adam Dershowitz]

I am trying to georectify an xy image.  I think that I am doing things 
correctly yet I keep getting an error.  Perhaps someone can clear things up for 
me.
I imported the image into an XY location.  I then went to the location that I 
want to import into and brought up a map so I could click on points.
If then select file- georectify.  I fill in the info and then click Start 
georectifying.  It brings up the manage ground control points window and a 
display showing the xy map to be georectified.  If I click there I can add the 
GCP xy coords.  But if I then click in my original window to select the 
georgraphic coords I get an error: can't read b1 coords : no such variable.

can't read b1coords: no such variable
can't read b1coords: no such variable
while executing
$geoentry insert 0 $b1coords
invoked from within
if { [info exists geoentry] } {
$geoentry insert 0 $b1coords
}
(command bound to event)

I can't figure out why it will not let me select the points.  I have selected 
the arrow tool in the map display.  

I am using a Mac with William Kyngesburye's binary builds.  I have 6.4 RC5-3 
Snow with OS 10.6.2

Thanks,

--Adam



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

[GRASS-user] Fire Simulation bug

[Adam Dershowitz]

I downloaded the 6.x firesimulation data set and demo script from:
http://www.hpcc.nectec.or.th/grass/download/data6.php  (Yes, I am  
using the script on that page, not the one that is included in the  
compressed file)

But, when I run it I get an error:

It gets as far as this:
 r.random my_spread n=10 raster_output=my_path
Collecting Stats...
 100%
Writing raster map my_path ...
 100%

But then reports an error here:
r.spreadpath -v x_input=my_spread.x y_input=my_spread.y \
 output=my_path
ERROR: option output: my_path exists.

It is correct that my_path exists, because it was created in the prior  
step.  But the documentation for r.spreadpath says in part:


output=name
Name of raster map layer to contain output. Also can be used as the  
map layer of the input target points. If so used, the input target  
point map will be overwritten by the output.


It seems like the script is trying to use this as both the input and  
output, as it says should be allowed.  But it is instead giving an  
error.  I also tried to add --overwrite to r.spreadpath, but then I  
just get a completely yellow window for the output with no paths at all.


Is there a bug in the script, or a bug in r.spreadpath?

I am using William Kyngesburye's Grass 6.4RC5 on a Mac OS 10.5.

Thanks,

--Adam



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

[GRASS-user] v.label.sa

[Adam Dershowitz]

I noticed that v.label.sa is not being built by default.  But that it  
is in the release brach of the 6.4 source.  I was able to download it  
and get it to build, however.


It is not included for a specific reason?  Was there an oversight, or  
is anything that I should be aware of for this module?


--Adam



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

[GRASS-user] v.what problem

[Adam Dershowitz]

I just upgraded to 6.4RC4.  I am using a Mac.
If I click on a vector point, after clicking on the query button on  
the top of the map, I see v.what appear in the output, and then GRASS  
crashes.  This is a new problem that didn't happen with 6.4RC3.


I attached the long stack trace that I get from the crash.

Any idea what changed, and what I can do about it?  This feature still  
works fine for me with 6.3.



--Adam


Process: Wish [38930]
Path:/usr/local/bin/../../../Library/Frameworks/ 
Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish

Identifier:  com.tcltk.wish
Version: 8.5.6 (8.5.6)
Code Type:   X86 (Native)
Parent Process:  sh [38926]

Date/Time:   2009-04-17 09:16:59.304 -0700
OS Version:  Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0047
Crashed Thread:  0

Thread 0 Crashed:
0   ??? 0x07807791 0 + 125859729
1   com.tcltk.tcllibrary0x0a0961a3 TclServiceIdle + 65
2   com.tcltk.tcllibrary0x0a07b1e2 Tcl_DoOneEvent + 380
3   com.tcltk.tklibrary 0x0b00b154 Tk_UpdateObjCmd + 44
4   com.tcltk.tcllibrary0x0a00e2e7 TclEvalObjvInternal + 744
5   com.tcltk.tcllibrary0x0a04a98b TclExecuteByteCode + 4628
6   com.tcltk.tcllibrary0x0a089e28 TclObjInterpProcCore + 981
7   com.tcltk.tcllibrary0x0a00e2e7 TclEvalObjvInternal + 744
8   com.tcltk.tcllibrary0x0a010d75 TclEvalEx + 1769
9   com.tcltk.tcllibrary0x0a0110ed Tcl_EvalEx + 46
10  com.tcltk.tklibrary 0x0b005a9a Tk_BindEvent + 4436
11  com.tcltk.tklibrary 0x0b00a6b8 TkBindEventProc + 329
12  com.tcltk.tklibrary 0x0b0125d9 Tk_HandleEvent + 1562
13  com.tcltk.tklibrary 0x0b02b821 TkDoConfigureNotify + 115
14  com.tcltk.tklibrary   	0x0b0c72da GenerateConfigureNotify  
+ 66
15  com.tcltk.tklibrary   	0x0b0c72c4 GenerateConfigureNotify  
+ 44
16  com.tcltk.tklibrary   	0x0b0c72c4 GenerateConfigureNotify  
+ 44

17  com.tcltk.tklibrary 0x0b0c7c9e XMoveResizeWindow + 136
18  com.tcltk.tklibrary 0x0b02c181 Tk_MoveResizeWindow + 78
19  com.tcltk.tklibrary   	0x0b08f9e3 TkTextEmbWinDisplayProc  
+ 275

20  com.tcltk.tklibrary 0x0b085af3 DisplayText + 5222
21  com.tcltk.tcllibrary0x0a0961a3 TclServiceIdle + 65
22  com.tcltk.tcllibrary0x0a07b1e2 Tcl_DoOneEvent + 380
23  com.tcltk.tklibrary   	0x0b0c8f4d  
TkMacOSXProcessWindowEvent + 792

24  com.tcltk.tklibrary 0x0b0b8e5d TkMacOSXProcessEvent + 107
25  com.tcltk.tklibrary   	0x0b0d0fba CarbonEventHandlerProc +  
95
26  com.apple.HIToolbox   	0x92add143  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
27  com.apple.HIToolbox   	0x92adc57d  
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,  
HandlerCallRec*) + 405
28  com.apple.HIToolbox   	0x92adc3e2  
SendEventToEventTargetWithOptions + 58
29  com.apple.HIToolbox   	0x92b0ad54  
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,  
OpaqueEventRef*, void*) + 356
30  com.apple.HIToolbox   	0x92add4fc  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 2134
31  com.apple.HIToolbox   	0x92adc57d  
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,  
HandlerCallRec*) + 405
32  com.apple.HIToolbox   	0x92af8ed2 SendEventToEventTarget +  
52
33  com.tcltk.tklibrary   	0x0b0d151d  
TkMacOSXReceiveAndDispatchEvent + 136

34  com.tcltk.tklibrary 0x0b0c4f71 CarbonEventsCheckProc + 46
35  com.tcltk.tcllibrary0x0a07b1c4 Tcl_DoOneEvent + 350
36  com.tcltk.tklibrary 0x0b00b154 Tk_UpdateObjCmd + 44
37  com.tcltk.tcllibrary0x0a00e2e7 TclEvalObjvInternal + 744
38  com.tcltk.tcllibrary0x0a04a98b TclExecuteByteCode + 4628
39  com.tcltk.tcllibrary0x0a089e28 TclObjInterpProcCore + 981
40  com.tcltk.tcllibrary0x0a00e2e7 TclEvalObjvInternal + 744
41  com.tcltk.tcllibrary0x0a010d75 TclEvalEx + 1769
42  com.tcltk.tcllibrary0x0a0110ed Tcl_EvalEx + 46
43  com.tcltk.tklibrary 0x0b005a9a Tk_BindEvent + 4436
44  com.tcltk.tklibrary 0x0b00a6b8 TkBindEventProc + 329
45  com.tcltk.tklibrary 0x0b0125d9 Tk_HandleEvent + 1562
46  com.tcltk.tklibrary 0x0b02b821 TkDoConfigureNotify + 115
47  com.tcltk.tklibrary 0x0b02b98c Tk_MakeWindowExist + 361
48  com.tcltk.tklibrary 0x0b02b9b5 Tk_MapWindow + 35
49  com.tcltk.tklibrary 0x0b02590e 

Re: [GRASS-user] Label crash

[Adam Dershowitz, Ph.D., P.E.]

On Apr 17, 2009, at 7:43 AM, Glynn Clements wrote:



Markus Neteler wrote:


If I generate a label:
v.label map=Labels column=stuff font=/usr/X11R6/lib/X11/fonts/TTF/ 
Vera.ttf
then it displays fine in the gui.  But if I try to use other  
monitors from

the command line I consistently get a crash.  For example:

d.mon start=PS
d.labels labels=Labels


I have tried with Spearfish, GRASS 6.4.0RC4, Linux 64bit:

v.label  map=roads colum=label font=/usr/share/fonts/TTF/Vera.ttf
d.mon start=PS
d.labels labels=roads
d.mon stop=PS
kghostview map.ps

No problem, looks fine.
It seems to be Mac specific.


And I get the following repeated a whole bunch of times:

The process has forked and you cannot use this CoreFoundation  
functionality

safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ 
()

to debug.

The same thing happens if I use d.mon start=PNG.


could fork() in
lib/driver/main.c
be the problem?


Yes. It's basically a symptom of MacOSX is sort of Unix, but not
quite.


Actually MacOSX is Unix and Linux is almost Unix.




A similar issue affects libW11 on Cygwin. There, mon.start runs the
driver in the background (spawnl(_P_DETACH, ...)) with argv[2] = -,
which prevents it from fork()ing.

Something similar could be done for MacOSX. However, this isn't
robust, as it relies upon mon.select retrying upon failure. If the
driver takes too long to start, mon.select will fail.



This explains the problem:  
http://developer.apple.com/technotes/tn2005/tn2083.html#SECDAEMONVSFRAMEWORKS

Although I am not sure about the solution.


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

Re: [GRASS-user] Multiple to one question

[Adam Dershowitz, Ph.D., P.E.]

On Apr 16, 2009, at 3:02 AM, Moritz Lennert wrote:


On 16/04/09 06:29, Adam Dershowitz, Ph.D., P.E. wrote:
I really liked the suggestion, so I tried itbut it doesn't  
work. To continue my simple example, I did  create view less2  
cat,Value

from data where Value  2; So I end up with a view, as expected. The
problem is that if I now link my map to that view, I get an error: No
attribute found for cat 1 (since the object still tries to link to  
1).  And, the same for 2 and 4.  And, I still see the points and

slashes (ie it still draws point a and puts a null value then a slash
then 1.1. So is there a way to have it not draw a symbol and not draw
null text when it can't find an attribute?  Since, the whole point
of what I am trying to do in this case is to eliminate certain data
with a query?


What do you mean by eliminate ?


Maybe you should be more precise about your objectives. Are you  
trying to display something on a map, or not ? If all your looking  
for is tables, than you don't need GRASS at all.


Hmmm, I guess I was not that clear.  Sorry, and thanks for your help  
and patients.


What I mean is that I have a map that has a bunch of sites on it, and  
values shown next to each site as a label.  In many cases there are  
multiple values shown.


What I want to do is draw a second map, where I only show sites where  
the value is greater then a certain threshold.  In other words, my  
first map has all values shown.  My second map should just show sites  
where value is, for example, greater than 2.0 (or whatever).


So what I ended up doing was copying my original map, and then linking  
my new map to a view of the original data.  But that didn't work  
because then all the sites that are below the threshold (and therefor  
are not in the view) don't have a correct value or cat, but the icons  
are still shown, and when there were multiple values in the original a  
slash is still drawn, since it seems that it is using a null value  
for the labels.







On 16/04/09 07:35, Adam Dershowitz, Ph.D., P.E. wrote:
 It seems like I should be able to edit the cats, and I tried a few

different things with v.edit, but I have not had any luck.  I tried
some things like this: v.edit map=foo tool=catdel -r where=cat   
0 but it gives me: ERROR: Tool catdel requires option cats  
Although the

above seems to work with tool=select, which I was using to test
things about before doing the delete.


As the message says, tool catdel does not work with a select, but  
you have to give it a list of cats. You can do that with something  
like this:


v.edit map=foo tool=catdel cats=`v.db.select -c foo col=cat  
where=XYZ | awk '{printf%i,,$1} END{print}'`

(note the back ticks)


I ended up doing something pretty similar to this last night, although  
I ended up using environmental variables to store the select results.   
And it accomplished half of what I need.  The problem is that all  
sites are still shown, even if they no no longer have any values, in  
the cases where the edit has eliminated all of them.  So if a vector  
point had a value of 1.0, it is still drawn.


If I follow the above with:
v.edit map=foo tool=delete -r where=cat  0 then it also eliminates  
the sites that no longer have any categories.  So I guess I have  
things working, but it feels like a kluge, and there should be a  
cleaner solution.






I copied my original vectors, and created the view.  Now what I want
to do is to delete all the categories in this vector that point to
null. Is there a way to do that?


Why do you want to do that ? If I understood you correctly, all of  
these cats have a meaning. Maybe not in the currently linked view,  
but in the original table. So if you delete these cats, you will  
lose the link to the values in the original table.


Again, I think we need a better explanation of what it is you are  
trying to get at.


Moritz



Here is a bigger picture explanation.

A bunch of samples were taken at different locations and different  
times.  I want to be able to generate a few different maps:

1)  Show all sampling locations (that one is easy and already done).
2)  Show all sample locations, and values, where value is  2.0, for  
example.  In other words, if the value at a location is below 2.0 then  
don't display the value, and if all the values at that location are  
below 2.0 don't even display the icon for the location.
Essentially what I am trying to do is to put a red dot where ever the  
I had a measurement above 2.0, and also list those values by the red  
dot.


So far I have not been able to get the above using views and linking  
to those views, because GRASS still knows about the points that are  
below 2.0 and tries to display them even if they are not in the view  
and treats them as null values, rather then as values to be ignored.


So far the solution that seems to work is:
1)  Create my master map showing all locations and values.
2)  Make a copy map that I

[GRASS-user] Label crash

[Adam Dershowitz]

I have run into a consistent crash problem.

If I generate a label:
v.label map=Labels column=stuff font=/usr/X11R6/lib/X11/fonts/TTF/ 
Vera.ttf
then it displays fine in the gui.  But if I try to use other monitors  
from the command line I consistently get a crash.  For example:


d.mon start=PS
d.labels labels=Labels

And I get the following repeated a whole bunch of times:

The process has forked and you cannot use this CoreFoundation  
functionality safely. You MUST exec().
Break on  
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ 
() to debug.


The same thing happens if I use d.mon start=PNG.

The same thing also happens with 6.3, 6.4RC3 and 6.4RC4.  I am on a  
Mac 10.5.6, and I am using the Kyngchaos binaries.  I was in touch  
with William Kyngesburye about it and he realized that the crash only  
happens when using true type fonts.  And some of the core info looks  
like it is freetype related.


Any suggestions would be appreciated.

Thanks,

--Adam



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

[GRASS-user] Multiple to one question

[Adam Dershowitz, Ph.D., P.E.]

This is somewhat a followup to my prior post and somewhat a new, but  
related problem.


I ended up doing what I had proposed, which is I have a table that has  
each sample value and location:


LocationValue cat
a   3.1 1
b   2.1 2
a   1.1 3
c   4.1 4

etc.

Then I have linked each vector point to multiple categories by using
v.edit map=foo layer=1 where=cat==1 type=point tool=catadd cat=3   
(for example)  So then I have an vector point that has a cat of both 1  
and 3.  So far so good.
If I then try to display Label vectors using Value for the attribute,  
it works fine.  Each value is displayed separated by a slash /.


The problem is if I try to use a SQL query, it is not working as  
expected.  I think that what it is doing is just applying the test to  
the first value, then showing or hiding the other values based on that  
first test (although I am not 100% sure that is what it is doing).
So, for example, if I were to do Use SQL query: Value  2.0 it would  
draw a label like this:  3.1/1.1  And if I were to use a query of  
Value  2.0 it would not display anything.  What I want it to do is to  
show all values that are actually greater than 2. and not to display  
the others.


Any suggestions of what it is doing, or what I can do about it?

I am using 6.4 RC3 on a Mac, and using sqlite for my db.
If I connect to the db just using the command line to connect to  
sqlite, then the query works as expected.


As a secondary question, is it possible to change the / separator  
that is used in the labels?  Where is that determined?  Can I instead  
make it /n and get each value below?


Thanks,

--Adam

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

Re: [GRASS-user] Multiple to one question

[Adam Dershowitz, Ph.D., P.E.]

--Adam



On Apr 15, 2009, at 9:29 PM, Adam Dershowitz, Ph.D., P.E. wrote:



On Apr 15, 2009, at 4:29 PM, Moritz Lennert wrote:


On 16/04/09 01:00, Adam Dershowitz, Ph.D., P.E. wrote:
This is somewhat a followup to my prior post and somewhat a new,  
but related problem.
I ended up doing what I had proposed, which is I have a table that  
has each sample value and location:

LocationValue cat
a3.11
b2.12
a1.13
c4.14
etc.
Then I have linked each vector point to multiple categories by using
v.edit map=foo layer=1 where=cat==1 type=point tool=catadd  
cat=3  (for example)  So then I have an vector point that has a  
cat of both 1 and 3.  So far so good.
If I then try to display Label vectors using Value for the  
attribute, it works fine.  Each value is displayed separated by a  
slash /.
The problem is if I try to use a SQL query, it is not working as  
expected.  I think that what it is doing is just applying the test  
to the first value, then showing or hiding the other values based  
on that first test (although I am not 100% sure that is what it is  
doing).
So, for example, if I were to do Use SQL query: Value  2.0 it  
would draw a label like this:  3.1/1.1  And if I were to use a  
query of Value  2.0 it would not display anything.  What I want  
it to do is to show all values that are actually greater than 2.  
and not to display the others.

Any suggestions of what it is doing, or what I can do about it?


Create a view in your database containing the results of your  
query, including cat values, and link your map to that view,  
instead of the table. If you want to change the content, just drop  
the view and recreate it with a different query. You can do all  
this either directly in sqlite, or via the db.execute GRASS module.


Moritz


I really liked the suggestion, so I tried itbut it doesn't work.
To continue my simple example, I did  create view less2 cat,Value  
from data where Value  2;

So I end up with a view, as expected.
The problem is that if I now link my map to that view, I get an  
error:  No attribute found for cat 1 (since the object still tries  
to link to 1).  And, the same for 2 and 4.  And, I still see the  
points and slashes (ie it still draws point a and puts a null value  
then a slash then 1.1.
So is there a way to have it not draw a symbol and not draw null  
text when it can't find an attribute?  Since, the whole point of  
what I am trying to do in this case is to eliminate certain data  
with a query?





It seems like I should be able to edit the cats, and I tried a few  
different things with v.edit, but I have not had any luck.  I tried  
some things like this:

v.edit map=foo tool=catdel -r where=cat  0
but it gives me:
ERROR: Tool catdel requires option cats
Although the above seems to work with tool=select, which I was using  
to test things about before doing the delete.


I copied my original vectors, and created the view.  Now what I want  
to do is to delete all the categories in this vector that point to  
null.  Is there a way to do that?


Thanks,

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

Re: [GRASS-user] Multiple to one question

[Adam Dershowitz, Ph.D., P.E.]

On Apr 14, 2009, at 9:51 AM, Vincent Bain wrote:

Hmmm, not sure you understood what I suggested (or maybe I did not  
catch

your point of view !). Let's consider you add two measures a week for
point A (cat=1), and 1 measure monthly for point B (cat=2), then after
one year you have :
* in table1 (cat integer):
2 recors (cat=1 and cat=2)

* in table2 (cat integer, mes float):
116 records (104 records with cat=1 and 12 records with cat=2).


Thank you.  I didn't understand before (I thought that you meant a  
column for each measurement date).  But this does explain it, and it  
makes a lot of sense.


--Adam



Where is there a problem for you ?
Hope this helps,

VB


Le mardi 14 avril 2009 à 09:38 -0700, Adam Dershowitz, Ph.D., P.E. a
écrit :

On Apr 14, 2009, at 4:06 AM, Moritz Lennert wrote:


On 14/04/09 08:37, Vincent Bain wrote:

Hello Adam,
maybe another solution in this case would be a set of 2 tables :
* one linking to the geometry, that is containing nothing but cat
values,
* another one, containing a cat column (related to the geometric
table) and different data columns corresponding to your sampling.


I think that if all you want is calculate some means or similar
across dates and then display the results, Vincent's solution is the
easiest.

But you could also use layers [1]:

layer 1 = January round of sampling
layer 2 = February round of sampling
etc.

You would have to give each point a category value in each layer (cf
v.category) and then either create separate tables for each period
linking each to one of the layers or at least create some obvious
cat values (i.e. 100s for January, 200s for February, etc) and link
on single table to all the layers, but with different cat values in
each layer.


Moritz

[1] See Vector object categories and attribute management on 
http://grass.osgeo.org/grass64/manuals/html64_user/vectorintro.html
for a quick introduction


Thanks,

But, the problem with both of these approaches, columns, and layers,
(Vincent or Moritz version) is that I don't have consistent times for
each site.  So, at site A I might have 5 samples, once a month and at
site B I have 2 samples, one each year, and site C I have a few  
spread

over a few years.
So both of those approaches essentially need to have a column, or
layer, for each possible time of sampling.  But that is not really
appropriate for the quasi-random times of the samples.






Does this help ?
VB
Le lundi 13 avril 2009 à 14:23 -0700, Adam Dershowitz a écrit :

I am trying to set up a new project in Grass, and I have a
question  about the best approach.
I have different vector locations, and at each one there were
multiple  samples taken.  At the moment I have each sample as a
row in a data  base.
My question is how best to put this data into a set of vector
points.
I believe that I can do it in either of two ways (of not others).
1)  I can create a vector point at each location, then I think
that I  can have multiple cats for that object.  So I think I can
do cat=1,3,6  for a given location.
Will that work OK?
2)  I can just create different vector objects, that happen to be
at  the identical location, and have each one point to a different
cat.

If the above is not clear, here is a bit more detailed example.
At location A there was a sample collected on 1/1 with a value of
2.1,  on 2/2 with a value of 2.2 and on 3/3 with a value of 3.3

The above data is already 3 rows in a database.

I want to be able to display data about point A (say, average
value or  things like that).  Should I just create a vector point
A and then do  cat=1,2,3 or should I create 3 different vector
points at A, each one  having a different cat?

Any guidance about the benefits or limitations each approach (or
any  other approach to consider) would be greatly appreciated.

Thanks,

--Adam



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


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









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

[GRASS-user] Multiple to one question

[Adam Dershowitz]

I am trying to set up a new project in Grass, and I have a question  
about the best approach.
I have different vector locations, and at each one there were multiple  
samples taken.  At the moment I have each sample as a row in a data  
base.

My question is how best to put this data into a set of vector points.
I believe that I can do it in either of two ways (of not others).
1)  I can create a vector point at each location, then I think that I  
can have multiple cats for that object.  So I think I can do cat=1,3,6  
for a given location.

Will that work OK?
2)  I can just create different vector objects, that happen to be at  
the identical location, and have each one point to a different cat.


If the above is not clear, here is a bit more detailed example.
At location A there was a sample collected on 1/1 with a value of 2.1,  
on 2/2 with a value of 2.2 and on 3/3 with a value of 3.3


The above data is already 3 rows in a database.

I want to be able to display data about point A (say, average value or  
things like that).  Should I just create a vector point A and then do  
cat=1,2,3 or should I create 3 different vector points at A, each one  
having a different cat?


Any guidance about the benefits or limitations each approach (or any  
other approach to consider) would be greatly appreciated.


Thanks,

--Adam



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

Re: [GRASS-user] face to DEM?

[Adam Dershowitz, Ph.D., P.E.]

Thanks.  I did, but didn't have any luck.  In one case I ended up  
making some pretty art, but it wasn't helpful.  The problem was that  
it included all the stuff outside of the face, as well as inside  
where it should have covered and I need.
And I just tried it again, with another simple shape and a different  
map, and this time, even though I first set the region to match the  
input map, I am still getting strip exists with insufficient data.   
ERROR2:  zero point in the given region!  Input failed.


--Adam



On Feb 20, 2009, at 2:12 AM, Jachym Cepicky wrote:


Hi,

you can try v.surf.rst as well

j

Vincent Bain píše v Ne 15. 02. 2009 v 10:32 +0100:

Hello Adam,
hope I understood what you mean to do. If I had to cope with your
problem, I would import the source file as points, then run  
v.to.rast,

and r.surf.nnbathy with the l interpolation method.
The risk for this solution is the triangulation performed by
r.surf.nnbathy be different from your source TIN...

Good luck,
Vincent.

Le samedi 14 février 2009 à 16:42 -0800, Adam Dershowitz a écrit :

I have some 3-d vector faces.  They were defined in a text file like
this:
F 10
1 2 1
2 2 2
...
...
etc.

I imported them into grass like this:
v.in.ascii -zn input=faces.txt out=faces format=standard
and all seems fine.

I can see the faces, and if I click on points around the edges I can
get a height as well.
I can't figure out how to generate a raster DEM from these faces.
Essentially I would like to know the approximate elevation at each
raster point inside the faces.
I tried v.to.rast but then I get Column parameter missing
For v.to.rast3 I get  Unable to get layer info for vector map
I also tried v.extrude but I see all 0s (ie Number of areas: 0 etc.)

Did I do something wrong on my import?  Did I miss some other way to
do the conversion?
I want to be able to do some mapcalcs with the heights of an these
faces compared to another raster map, but I can't figure out how to
convert these faces to something that I can work with.

Thanks much,

--Adam



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



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

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

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


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

[GRASS-user] face to DEM?

[Adam Dershowitz]

I have some 3-d vector faces.  They were defined in a text file like  
this:

F 10
1 2 1
2 2 2
...
...
etc.

I imported them into grass like this:
v.in.ascii -zn input=faces.txt out=faces format=standard
and all seems fine.

I can see the faces, and if I click on points around the edges I can  
get a height as well.
I can't figure out how to generate a raster DEM from these faces.   
Essentially I would like to know the approximate elevation at each  
raster point inside the faces.

I tried v.to.rast but then I get Column parameter missing
For v.to.rast3 I get  Unable to get layer info for vector map
I also tried v.extrude but I see all 0s (ie Number of areas: 0 etc.)

Did I do something wrong on my import?  Did I miss some other way to  
do the conversion?
I want to be able to do some mapcalcs with the heights of an these  
faces compared to another raster map, but I can't figure out how to  
convert these faces to something that I can work with.


Thanks much,

--Adam



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

Re: [GRASS-user] Volumes of intersections

[Adam Dershowitz, Ph.D., P.E.]

I am still somewhat stuck on this.  I have defined a face (3-d area)  
and it seems that very few of the vector functions can do anything  
with a face like that.

Any other suggestions for doing these types of calculation?

Thanks,

--Adam



On Jan 2, 2009, at 5:14 PM, G. Allegri wrote:


I don't know the latest devlopments on the 3d vector system, but I
would convert the vector to rasters (2d or 3d) and then use map
algebra...

giovanni

2009/1/3 Adam Dershowitz adershow...@exponent.com:
Is it possible to use grass to calculate the volume of a part of a  
3-D

vector object?
What I mean is if I have a mountain, for example, that is defines  
in one
vector map.  Then, in another map, I define an area (a plane for  
example).

This represents a slice through the mountain.
Is it possible to calculate the volume of the mountain that lies  
above the
second plane?  (how much rock is above the slice through it?) It  
seems like

it should be doable, but I am not really sure how to get going.
Any suggestions?

Thanks,

--Adam



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



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

[GRASS-user] r.in.wms issues

[Adam Dershowitz]

I am trying to use r.in.wms to get elevation data from  
wms.jpl.nasa.gov, but I have been running into two different  
problems.  I have been using the gui on a mac with 6.3, although I  
also tried 6.4 RC2 and got similar results.  The files do download but  
then I can't seem to work with them properly.  I have tried geotiff  
and png.  I have tried a bunch of other combinations as well.



The first problem seems to be with how temporary files are being named  
so that patching is not working properly.  Here is the command that is  
being generated by the gui:


r.in.wms output=elev_us_ned2 mapserver=wms.jpl.nasa.gov/wms.cgi  
layers=us_ned format=png wmsquery=version=1.1.1 maxcols=1024  
maxrows=1024 {wgetoptions=-c -t 5 -nv} {curloptions=-C - --retry 5 -s - 
S} method=cubic v=1


This is followed by this long list of errors:
Calculating tiles
Requesting 2 tiles.
Downloading tiles
Tile already downloaded
Tile already downloaded
All tiles downloaded successfully
Creating output file that is 972P x 558L.
Processing input file /Users/dersh/grass/wms_download/ 
elev_us_ned2__0.png.

Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 - done.
Invalid map elev_us_ned2_tile_0_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_0.1 not found
Invalid map elev_us_ned2_tile_0_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_0.2 not found
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Raster map elev_us_ned2_tile_0_tmp.1
elev_us_ned2_tile_0_tmp.2 not found
Illegal filename. Character 
 not allowed.
raster: couldn't be removed
Illegal filename. Character 
 not allowed.
header: couldn't be removed
Illegal filename. Character 
 not allowed.
category: couldn't be removed
Illegal filename. Character 
 not allowed.
color: couldn't be removed
Illegal filename. Character 
 not allowed.
history: couldn't be removed
Illegal filename. Character 
 not allowed.
misc: couldn't be removed
Illegal filename. Character 
 not allowed.
fcell: couldn't be removed
Illegal filename. Character 
 not allowed.
g3dcell: couldn't be removed
Illegal filename. Character 
 not allowed.
colr2/PERMANENT: couldn't be removed
elev_us_ned2_tile_0_tmp.1
elev_us_ned2_tile_0_tmp.2 nothing removed
Creating output file that is 971P x 560L.
Processing input file /Users/dersh/grass/wms_download/ 
elev_us_ned2__1.png.

Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 - done.
Invalid map elev_us_ned2_tile_1_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_1.1 not found
Invalid map elev_us_ned2_tile_1_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_1.2 not found
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Raster map elev_us_ned2_tile_1_tmp.1
elev_us_ned2_tile_1_tmp.2 not found
Illegal filename. Character 
 not allowed.
raster: couldn't be removed
Illegal filename. Character 
 not allowed.
header: couldn't be removed
Illegal filename. Character 
 not allowed.
category: couldn't be removed
Illegal filename. Character 
 not allowed.
color: couldn't be removed
Illegal filename. Character 
 not allowed.
history: couldn't be removed
Illegal filename. Character 
 not allowed.
misc: couldn't be removed
Illegal filename. Character 
 not allowed.
fcell: couldn't be removed
Illegal filename. Character 
 not allowed.
g3dcell: couldn't be removed
Illegal filename. Character 
 not allowed.
colr2/PERMANENT: couldn't be removed
elev_us_ned2_tile_1_tmp.1
elev_us_ned2_tile_1_tmp.2 nothing removed
Patching [.1] channel
r.patch - elev_us_ned2_tile_0.1 not found
r.patch - elev_us_ned2_tile_1.1 not found
One or more input maps not found
Raster map elev_us_ned2_tile_0.1 not found
elev_us_ned2_tile_0.1 nothing removed
Raster map elev_us_ned2_tile_1.1 not found
elev_us_ned2_tile_1.1 nothing removed
Patching [.2] channel
r.patch - elev_us_ned2_tile_0.2 not found
r.patch - elev_us_ned2_tile_1.2 not found
One or more input maps not found
Raster map elev_us_ned2_tile_0.2 not found
elev_us_ned2_tile_0.2 nothing removed
Raster map elev_us_ned2_tile_1.2 not found
elev_us_ned2_tile_1.2 nothing removed
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset

The odd thing is that I am left with four temporary maps in the  
mapset:  elev_us_ned2_tile_0_tmp.1 elev_us_ned2_tile_0_tmp.2  
elev_us_ned2_tile_1_tmp.1 elev_us_ned2_tile_1_tmp.1  so it seems that  
the script can't find these maps for some reasons.


The second problem, that might or might not be related, is that if I  
open the temporary files, there is a slot between them.  It appears  
as though they just don't line up properly. 

Re: [GRASS-user] r.in.wms issues

[Adam Dershowitz, Ph.D., P.E.]

On Jan 27, 2009, at 1:50 PM, Adam Dershowitz wrote:

I am trying to use r.in.wms to get elevation data from  
wms.jpl.nasa.gov, but I have been running into two different  
problems.  I have been using the gui on a mac with 6.3, although I  
also tried 6.4 RC2 and got similar results.  The files do download  
but then I can't seem to work with them properly.  I have tried  
geotiff and png.  I have tried a bunch of other combinations as well.



The first problem seems to be with how temporary files are being  
named so that patching is not working properly.  Here is the command  
that is being generated by the gui:


r.in.wms output=elev_us_ned2 mapserver=wms.jpl.nasa.gov/wms.cgi  
layers=us_ned format=png wmsquery=version=1.1.1 maxcols=1024  
maxrows=1024 {wgetoptions=-c -t 5 -nv} {curloptions=-C - --retry 5 - 
s -S} method=cubic v=1


This is followed by this long list of errors:
Calculating tiles
Requesting 2 tiles.
Downloading tiles
Tile already downloaded
Tile already downloaded
All tiles downloaded successfully
Creating output file that is 972P x 558L.
Processing input file /Users/dersh/grass/wms_download/ 
elev_us_ned2__0.png.

Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 - done.
Invalid map elev_us_ned2_tile_0_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_0.1 not found
Invalid map elev_us_ned2_tile_0_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_0.2 not found
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Raster map elev_us_ned2_tile_0_tmp.1
elev_us_ned2_tile_0_tmp.2 not found
Illegal filename. Character 
 not allowed.
raster: couldn't be removed
Illegal filename. Character 
 not allowed.
header: couldn't be removed
Illegal filename. Character 
 not allowed.
category: couldn't be removed
Illegal filename. Character 
 not allowed.
color: couldn't be removed
Illegal filename. Character 
 not allowed.
history: couldn't be removed
Illegal filename. Character 
 not allowed.
misc: couldn't be removed
Illegal filename. Character 
 not allowed.
fcell: couldn't be removed
Illegal filename. Character 
 not allowed.
g3dcell: couldn't be removed
Illegal filename. Character 
 not allowed.
colr2/PERMANENT: couldn't be removed
elev_us_ned2_tile_0_tmp.1
elev_us_ned2_tile_0_tmp.2 nothing removed
Creating output file that is 971P x 560L.
Processing input file /Users/dersh/grass/wms_download/ 
elev_us_ned2__1.png.

Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 - done.
Invalid map elev_us_ned2_tile_1_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_1.1 not found
Invalid map elev_us_ned2_tile_1_tmp.alpha
Parse error
Raster map elev_us_ned2_tile_1.2 not found
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Illegal filename. Character 
 not allowed.
Raster map elev_us_ned2_tile_1_tmp.1
elev_us_ned2_tile_1_tmp.2 not found
Illegal filename. Character 
 not allowed.
raster: couldn't be removed
Illegal filename. Character 
 not allowed.
header: couldn't be removed
Illegal filename. Character 
 not allowed.
category: couldn't be removed
Illegal filename. Character 
 not allowed.
color: couldn't be removed
Illegal filename. Character 
 not allowed.
history: couldn't be removed
Illegal filename. Character 
 not allowed.
misc: couldn't be removed
Illegal filename. Character 
 not allowed.
fcell: couldn't be removed
Illegal filename. Character 
 not allowed.
g3dcell: couldn't be removed
Illegal filename. Character 
 not allowed.
colr2/PERMANENT: couldn't be removed
elev_us_ned2_tile_1_tmp.1
elev_us_ned2_tile_1_tmp.2 nothing removed
Patching [.1] channel
r.patch - elev_us_ned2_tile_0.1 not found
r.patch - elev_us_ned2_tile_1.1 not found
One or more input maps not found
Raster map elev_us_ned2_tile_0.1 not found
elev_us_ned2_tile_0.1 nothing removed
Raster map elev_us_ned2_tile_1.1 not found
elev_us_ned2_tile_1.1 nothing removed
Patching [.2] channel
r.patch - elev_us_ned2_tile_0.2 not found
r.patch - elev_us_ned2_tile_1.2 not found
One or more input maps not found
Raster map elev_us_ned2_tile_0.2 not found
elev_us_ned2_tile_0.2 nothing removed
Raster map elev_us_ned2_tile_1.2 not found
elev_us_ned2_tile_1.2 nothing removed
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset
Raster map elev_us_ned2 not found in current mapset

The odd thing is that I am left with four temporary maps in the  
mapset:  elev_us_ned2_tile_0_tmp.1 elev_us_ned2_tile_0_tmp.2  
elev_us_ned2_tile_1_tmp.1 elev_us_ned2_tile_1_tmp.1  so it seems  
that the script can't find these maps for some reasons.


The second problem, that might or might not be related, is that if I  
open the temporary files, there is a slot between them

Re: [GRASS-user] r.in.wms issues

[Adam Dershowitz, Ph.D., P.E.]

On Jan 27, 2009, at 5:57 PM, Hamish wrote:


Adam Dershowitz wrote:

I am trying to use r.in.wms to get elevation data from
wms.jpl.nasa.gov, but I have been running into two different  
problems.
I have been using the gui on a mac with 6.3, although I also tried  
6.4

RC2 and got similar results.


which/who's Mac binaries?


Kyngesburye



what version of gdal tools? (gdalinfo --version from the command  
prompt)


GDAL 1.5.4, released 2009/01/07
(I have also tried out the 1.6 release, and it reports GDAL 1.6.0,  
released 2008/12/04.)







The files do download but then I can't seem to work with them
properly.  I have tried geotiff and png.  I have tried a bunch
of other combinations as well.



Here is the command that is being generated by the gui:

r.in.wms output=elev_us_ned2 mapserver=wms.jpl.nasa.gov/wms.cgi \
  layers=us_ned format=png wmsquery=version=1.1.1 \
  maxcols=1024 maxrows=1024 {wgetoptions=-c -t 5 -nv} \
  {curloptions=-C - --retry 5 -s -S} method=cubic v=1


mapserver= usually starts with http://;. This appears to be  
optional for

wget; but I don't know about curl.


But the download seems to go fine.  Although in my early testing I had  
it set for a higher resolution so it was getting a bunch of downloads  
and sometimes the server would complain that it was too busy.  I only  
figured out that problem because in those cases the .geotiff files  
were much smaller.  When I checked they contained the error message.   
But r.in.wms tried to use them anyway





method=cubic is irrelevant if the location is WGS84 Lat/lon, you can  
omit it.


I am using UTM not Lat/Long.  And that is why it is trying to do the  
conversion, I think.






srs= is missing in above command?


By default it was filling in src=EPSG:4326, which I believe is fine  
for UTM nad83 in the US.  I tried it both with and without that with  
the same results.








This is followed by this long list of errors:



Invalid map elev_us_ned2_tile_0_tmp.alpha
Parse error


?
perhaps a Mac/BSD vs GNU command line util using a non-portable  
command?


On linux(debian/etch) I get the same result/errors as Markus.


Markus:

I tried in 6.4 and got (copying your command line):




I just tried that command again with 6.4RC2.  I also get the identical  
results to Markus.  (and adding style=feet_real make it reasonable  
units).  However there are the two files created.  If I try to view  
one of them there is still that crack across the middle, where it  
looks like one is rotated and the other is not.  And if I try to view  
the other one it is just all zeros.




6.4.0rcX or develbranch6?  Note in develbranch6 null values are  
broken:

trac #455, #392?   http://trac.osgeo.org/grass/ticket/455

!!

GR65 r.info -r elev_us_ned65.1
min=-2147483648
max=53

#fix
GR65 r.null elev_us_ned65.1 setnull=-2147483648


strange, for .2 min is given as -2147483648 but r.univar shows
zero null cells.




Using band 2 of source image as alpha.
0...10...20...30...40...50...60...70...80...90...100 -
done.
Rename raster elev_us_ned2_tile_0.1 to elev_us_ned2.1
Rename raster elev_us_ned2_tile_0.2 to elev_us_ned2.2


so far so good,


ERROR: Raster map elev_us_ned2 not found in current mapset
ERROR: Raster map elev_us_ned2 not found in current mapset
ERROR: Raster map elev_us_ned2 not found in current mapset
ERROR: Raster map elev_us_ned2 not found in current mapset
ERROR: Raster map elev_us_ned2 not found in current mapset
ERROR: Raster map elev_us_ned2 not found in current mapset

Slightly better/different but eventually failing, too. :(


fwiw, these ERROR: Raster map  not found in current mapset are
from the 6 r.support calls in the r.in.wms script just after:

eval r.in.gdalwarp $GDALWARP
if [ $? -ne 0 ] ; then
  exit 1
fi

(I am not sure if that $? check really works: is it testing that eval
could run the command, not if the command exited successfully?)


the problem here is that the output is called map.1 and map.2 so  
the

raster map name passed to r.support are wrong.  map.2 is apparently
alpha layer (empty map), while map.1 contains the data.


in a lat/lon WGS84 location:

grass640 g.region n=46:04N s=39:30N w=80:24W e=71:20W res=0:00:30

grass640 r.in.wms output=elev_us_ned64 \
  mapserver=wms.jpl.nasa.gov/wms.cgi   layers=us_ned format=png \
  wmsquery=version=1.1.1   maxcols=1024 maxrows=1024 \
  wgetoptions=-c -t 5 -nv   curloptions=-C - --retry 5 -s -S \
  method=cubic v=1 --o --v

I get data in the .1 file.

because the format is PNG  style is default, the values refer to  
color
and are in the range of 0-53. To see anything but mostly-black I  
needed

to do:
grass640 r.colors elev_us_ned64.1 col=bcyr

and you get a nice image.


'r.in.wms -l' says the us_ned layer is supposed to show:

LAYER: us_ned
 Title: United States elevation, 30m
 |
 |Continental United States elevation, produced from the  
USGS National Elevation.
 |The default style is scaled to 8 bit from the orginal

[GRASS-user] v.in.dxf lines with no elevation

[Adam Dershowitz]

I have a dxf file that contains both lines and points.  If I import it  
into grass with v.in.dxf the lines end up at an elevation of 0, while  
the points show up correctly.  I have verified that the lines do in  
fact have an elevation by importing the dxf both into google sketch up  
and blender as a test.
I googled around some and it seems like it used to be necessary to run  
v.in.dxf3d but I can't find that, and it appears that it was just  
incorporated into v.in.dxf, best I can tell.

Any suggestions for getting the lines to the correct elevation?

Thanks,

--Adam



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

Re: [GRASS-user] v.in.dxf lines with no elevation

[Adam Dershowitz]

On Jan 5, 2009, at 6:02 PM, Adam Dershowitz wrote:

I have a dxf file that contains both lines and points.  If I import  
it into grass with v.in.dxf the lines end up at an elevation of 0,  
while the points show up correctly.  I have verified that the lines  
do in fact have an elevation by importing the dxf both into google  
sketch up and blender as a test.
I googled around some and it seems like it used to be necessary to  
run v.in.dxf3d but I can't find that, and it appears that it was  
just incorporated into v.in.dxf, best I can tell.

Any suggestions for getting the lines to the correct elevation?

Thanks,

--Adam




Also, when I do the import I get a warning 3-d data in dxf file
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Volumes of intersections

[Adam Dershowitz]

Is it possible to use grass to calculate the volume of a part of a 3-D  
vector object?
What I mean is if I have a mountain, for example, that is defines in  
one vector map.  Then, in another map, I define an area (a plane for  
example).  This represents a slice through the mountain.
Is it possible to calculate the volume of the mountain that lies above  
the second plane?  (how much rock is above the slice through it?) It  
seems like it should be doable, but I am not really sure how to get  
going.

Any suggestions?

Thanks,

--Adam



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

Re: [GRASS-user] G_malloc: out of memory

[Adam Dershowitz]

On Nov 23, 2008, at 12:42 PM, William Kyngesburye wrote:


On Nov 22, 2008, at 7:42 PM, Kurt Springs wrote:

Okay, I'm willing to try.  I hope 6.4 will help in getting nodes to  
snap.


Kurt
On Nov 22, 2008, at 11:22 AM, William Kyngesburye wrote:

I'm somewhat caught up on other distractions and can focus more on  
GRASS again.  I can package up a 6.4svn.


If your up to it, there are detailed OSX compile instructions in  
the source, though I should look them over for any changes needed.



I have 6.4 SVN binaries online now.  Tested on Leopard so far.  I  
also updated the build instructions in the source.


A couple important changes from my previous binaries (the build  
instructions also reflect these changes):


- It uses ActiveTcl 8.5 now for the TclTk GUI and NVIZ.  This aqua- 
fies the TclTk GUI.  The X11 TclTk is not bundled now and not needed.


- It uses up-to-date wxPython binaries, even on Leopard.  Starting  
with wxPython 2.8.8, it can install to be used with the Leopard  
system Python 2.5 as well as the python.org Python.  This may  
interfere with the wx gui in GRASS 6.3, but it's not as well  
developed anyways.


-



I downloaded this.  So far the basics seem fine, but I get an error  
when I try to use nviz.  The error is below:


Process: nviz [5420]
Path:/Applications/GRASS-6.4.app/Contents/MacOS/etc/ 
nviz2.2/nviz

Identifier:  nviz
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  wish [5215]

Date/Time:   2008-12-01 10:40:24.737 -0800
OS Version:  Mac OS X 10.5.5 (9F33)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Crashed Thread:  0

Dyld Error Message:
  Library not loaded: /Library/Frameworks/Tk.framework/Versions/8.5/Tk
  Referenced from: /Applications/GRASS-6.4.app/Contents/MacOS/etc/ 
nviz2.2/nviz

  Reason: image not found

Do I have to separately install a new version of TclTK?  I have both  
whatever is installed with the default 10.5.5, and I also use MacPorts  
and I have tcl 8.5.5 and tk 8.5.5 installed from Macports.
Do I need to install something else?  Or is nviz just looking in the  
wrong place and needs to get pointed in the right direction?


Thanks,

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

Re: [GRASS-user] Going back to 6.3

[Adam Dershowitz]

On Nov 25, 2008, at 8:51 PM, William Kyngesburye wrote:


On Nov 25, 2008, at 10:33 PM, Kurt Springs wrote:

If you are using my GRASS 6.3, there is no need to delete  
ActiveTcl.  It has its own internal TclTk X11 binaries that it  
explicitly uses.  In fact, no need to delete 6.3 before installing  
6.4.


6.4 actually overwrote 6.3.  I'd assumed the reverse would be true.


Odd, GRASS 6.3 and 6.4 have different names:

GRASS-6.3.app
GRASS-6.4.app





I can confirm that the 6.4 install doesn't actually delete  
GRASS-6.3.app, it just empties it out.  So that it is now 6.5 meg,  
while it used to be much larger (6.4 is 74 meg).  And when I double  
click on 6.3 I get a error in my log:
posix_spawnp(/Applications/GRASS-6.3.app/Contents/MacOS/GRASS, ...):  
No such file or directory


So it looks like the 6.4 installer deletes most, but not all, of the  
stuff that was in 6.3. 
 
___

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

Re: [GRASS-user] Going back to 6.3

[Adam Dershowitz]

On Dec 1, 2008, at 11:51 AM, Adam Dershowitz wrote:



On Nov 25, 2008, at 8:51 PM, William Kyngesburye wrote:


On Nov 25, 2008, at 10:33 PM, Kurt Springs wrote:

If you are using my GRASS 6.3, there is no need to delete  
ActiveTcl.  It has its own internal TclTk X11 binaries that it  
explicitly uses.  In fact, no need to delete 6.3 before  
installing 6.4.


6.4 actually overwrote 6.3.  I'd assumed the reverse would be true.


Odd, GRASS 6.3 and 6.4 have different names:

GRASS-6.3.app
GRASS-6.4.app





I can confirm that the 6.4 install doesn't actually delete  
GRASS-6.3.app, it just empties it out.  So that it is now 6.5 meg,  
while it used to be much larger (6.4 is 74 meg).  And when I double  
click on 6.3 I get a error in my log:
posix_spawnp(/Applications/GRASS-6.3.app/Contents/MacOS/ 
GRASS, ...): No such file or directory


So it looks like the 6.4 installer deletes most, but not all, of the  
stuff that was in 6.3.___


I just tested it and just re-installing 6.3, while 6.4 is there, seems  
to allow both to coexist fine.


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

[GRASS-user] NVIZ vectors

[Adam Dershowitz]

I used d.nviz to create a sample script that I am using as a basis to  
create a script for NVIZ.  The problem is that I am not seeing any  
sites showing up.  I tried using the -e option and I see that it adds:

SendScriptLine Nshow_vect on
SendScriptLine Nshow_sites on
to the script.  By adding these two lines I am seeing the addition of  
my vectors, like I want, but not my sites.  If I manually move around  
in NVIZ the sites are showing up fine, but then when I run the script,  
to save snapshots, the points sites don't show up.

I am using the mac binary of 6.3.
Any idea why, or what I can do to get them to show up?

Thanks,

--Adam



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

[GRASS-user] d.rast.edit issues

[Adam Dershowitz]

I am trying to use d.rast.edit and I can't get it to work properly.   
If I open it, either from the menu, or from the command line, it seems  
to open fine, but the size of my overview window is much larger then  
the size of my screen, so I can't see much of the window.  If I resize  
the window then I don't get any scroll bars, so that doesn't help.  So  
I can't figure out how to get to the lower 3/4 of my image.  The edit  
window itself seems fine, but I can't get get it to select the correct  
part of the image, since I can't move to it in the overview window.   
What might or might not be relevant is that the only menu item that  
appears on either window is on the edit window I have a File menu with  
Save and Exit.


Am I missing something?  Is there any way to force the size of the  
window to stay on my screen?  Or to force it to just show a different  
section?  I could edit the different parts at different times if I  
could get to that lower area at all.
I did try changing the region and the default region to see if that  
would allow me to choose a different part of the image, with no luck  
at all.


I am using the kyngchaos mac 6.3 binary builds with the newest Mac  
X11: 2.3.0 and the tcltk interface.


Thanks,

--Adam



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