date:20131204

Markus M:
> >> > >> > But it does not make sense to use a pan band as seeds when
> >> > >> > segmenting the other bands. Seeds are typically the result of a
> >> > >> > previous run of i.segment or the result of a previous
> >> > >> > classification of the same data.

Nikos A:
> >> > >> Then I have inserted a small mistake in my tests/workflow. Wanted to
> >> > >> drive "finer objects" (from Pan) in bigger ones (based on MS).
> >> > >> Will adjust.

MM:
> >> > The seeds map does the opposite. You probably want to do pansharpening
> >> > first.

NA:
> > Just for completeness, ehm... I was too fast. So, I did use sharpenned
> > images only in 2 trials, however, as I can actually see in the history. 
> > The exact same process in two different Mapsets (same Location),
> > QuickBird2 data:

> > --%<--
> > i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02
> > minsize=4 seed=segments_pan_t0.01 memory=3000 iterations=1000
> > -->%--

> > It worked in one case (repeated to be sure) and it failed in another!

> Different computational regions?

Absolutely.  Two different, independent trials. Same Location, different 
Mapsets, different regions ("physically", if I may say so, and 
computationally).

> > In the failing case, before the ERROR message, there are multiple WARNINGS
> > issued:
> > 
> > ..
> > WARNING: Region consists of only one cell, nothing to update
> 
> This should not happen, a bug in the region growing algorithm.
> 
> > Now, I have re-ran the "failed" one and I get this strange:
> > 
> > ..
> > 0..5..10..15..20..25..30..35..40..ERROR: Invalid region id -1489
> 
> Essentially the same like "ERROR: Invalid region id -1". Again, this
> should not happen.
> 
> > ..
> > 
> > I went after looking all of the details of the involved maps.  The only
> > "strange" thing I can see (which I caused) is that the region is 0.6, the
> > seed (segments_pan_t0.01) is also 0.6 while the group of Pan-Sharpened
> > images are (each) of 0.60017817 (ns) x 0.60016801 (we) resolution.  Is
> > this my mistake? The resolution(s) should be identical, right?
> 
> Yes. I guess in the process of pansharpening, the region was set to
> 0.6, then the resolution was adjusted to the extents (for g.region,
> extents have precedence over resolution). The correct way of adjusting
> the region would be to either set the region to the pan band or align
> the region to the band band (g.region align=pan). Note that g.region
> res=0.6 -a can introduce a pixel shift.
> 
> Can you reproduce that with sample data?

I'll try.

> Or give me chance to reproduce that?

If I can't make it with "common" data from the Spearish Location, I can try 
with some publicly available High-Res images.

Nonetheless, I am convinced, for now, that the evil root was my bad choice of 
setting the region using the "-a" flag.  Usually, I try to keep the cell 
resolutions intact, as imported. With many high resolution images I have 
worked recently (IKONOS, QuickBird2, WorldView-1, WorldView-2), this is the 
case. They are not exactly 0.6, 1 or 2.4 or whatever.

However, trying to make the computational region as minimal as possible, I use 
very often something like "g.region zoom=Raster".  This, however, has no 
effect in the region's resolution. It affects only the extent.  And then, I 
easily fall in the trap to reset the resolution, e.g. it was set to match the 
MSes and I need the Pan's, so I do "g.region res=0.6 -a".

What do you think, a short warning in the manual that "the resolution of the 
computational region should be identical between subsequent segmentations that 
make use of a seed map"?

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

Re: [GRASS-dev] i.segment: Invalid region id -1

On Wednesday 04 of December 2013 10:56:48 Nikos Alexandris wrote:
..
> 
> What do you think, a short warning in the manual that "the resolution of the
> computational region should be identical between subsequent segmentations
> that make use of a seed map"?

Or, maybe more "aggressively", a check if the resolution of the seed map is 
identical to the region's resolution at the time of the segmentation process?

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

[GRASS-dev] tgrass compilation issue

2013-12-04 Thread Martin Landa

Hi,

since today I have problem with compilation of temporal modules, see bellow.

if [ "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create"
!= "" ] ; then 
GISRC=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu
PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts:$PATH"
PYTHONPATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:"
LC_ALL=C /opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create
--html-description < /dev/null | grep -v '\|' >
t.create.tmp.html ; fi
Traceback (most recent call last):
  File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create",
line 60, in 
import grass.temporal as tgis
  File 
"/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/__init__.py",
line 25, in 
from mapcalc import *
  File 
"/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/mapcalc.py",
line 16, in 
from open import *
ImportError: No module named open
make: *** [t.create.tmp.html] Error 1
rm t.create.tmp.html

Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] tgrass compilation issue

2013-12-04 Thread Sören Gebbert

Hi Martin,
this issue is hopefully fixed in r58383.

Best regards
Soeren

2013/12/4 Martin Landa :
> Hi,
>
> since today I have problem with compilation of temporal modules, see bellow.
>
> if [ "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create"
> != "" ] ; then 
> GISRC=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
> GISBASE=/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu
> PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts:$PATH"
> PYTHONPATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
> LD_LIBRARY_PATH="/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:"
> LC_ALL=C /opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create
> --html-description < /dev/null | grep -v '\|' >
> t.create.tmp.html ; fi
> Traceback (most recent call last):
>   File "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/t.create",
> line 60, in 
> import grass.temporal as tgis
>   File 
> "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/__init__.py",
> line 25, in 
> from mapcalc import *
>   File 
> "/opt/src/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/mapcalc.py",
> line 16, in 
> from open import *
> ImportError: No module named open
> make: *** [t.create.tmp.html] Error 1
> rm t.create.tmp.html
>
> Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] tgrass compilation issue

2013-12-04 Thread Martin Landa

Hi Soeren!

2013/12/4 Sören Gebbert :

> this issue is hopefully fixed in r58383.

seems to be fine, thanks for super-quick fix! Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [Bug 1037102] New: grass FTBFS if "-Werror=format-security" flag is used

2013-12-04 Thread Maris Nartiss

Easy. Do not use -Werror=format-security flag.

See this thread for details:
http://lists.osgeo.org/pipermail/grass-dev/2012-August/059157.html

Maris.

2013/12/3 Markus Neteler :
> Hi,
>
> with the security flag ("-Werror=format-security") enabled, GRASS
> fails to build.
> How to deal with this kind of error? I could then apply it elsewhere:
>
> cd lib/gis/
> make
> ...
> null_val.c: In function ‘InitError’:
> null_val.c:115:5: error: format not a string literal and no format
> arguments [-Werror=format-security]
>  G_fatal_error(errMsg);
>
> cd vector/v.vol.rst
> main.c: In function ‘main’:
> main.c:587:2: error: format not a string literal and no format
> arguments [-Werror=format-security]
>   G_debug(1, db_get_string(&sql));
>   ^
> cc1: some warnings being treated as errors
>
> and so on.
>
> thanks
> Markus
>
>
> -- Forwarded message --
> From:  
> Date: Tue, Dec 3, 2013 at 4:08 AM
> Subject: [Bug 1037102] New: grass FTBFS if "-Werror=format-security"
> flag is used
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1037102
> Bug ID: 1037102
>Summary: grass FTBFS if "-Werror=format-security" flag is used
>Product: Fedora
>Version: rawhide
>  Component: grass
> ...
>
> Description of problem
> --
>
> grass fails to build if "-Werror=format-security" flag is used.
> ...
>
> a2b.c:103:3: error: format not a string literal and no format arguments
> [-Werror=format-security]
> a2b.c:136:3: error: format not a string literal and no format arguments
> [-Werror=format-security]
> a2b.c:154:3: error: format not a string literal and no format arguments
> [-Werror=format-security]
> a2b.c:172:6: error: format not a string literal and no format arguments
> [-Werror=format-security]
>
> ...
>
> We are working on a proposal to enable "-Werror=format-security" for all
> packages. Once this flag is enabled, GCC will refuse to compile code that 
> could
> be vulnerable to a string format security flaw. For more details, please see
> https://fedorahosted.org/fesco/ticket/1185 page.
>
> To understand why it is important to fix this, please see
> https://fedoraproject.org/wiki/Format-Security-FAQ page.
>
> How to fix this
> ---
>
> The fix for these errors is quite simple. It's a matter of changing a
> line like,
>
>printf(foo);
>
> to read,
>
>printf("%s", foo);
>
> That's it.
>
> Please fix this issue in rawhide with a patch (which you should submit
> to upstream to merge moving forward). Please do a new build with the
> fix in rawhide. Other releases do not need to be directly fixed, but
> there should be no harm in pushing out this fix/patch with other needed
> changes to those branches.
>
> In the event you don't fix this bug before the next mass rebuild,
> provenpackagers may step in and update your package(s) to fix this
> issue.
>
> How reproducible
> 
>
> Build grass-6.4.3-5.fc21.src.rpm with "-Werror=format-security" flag to
> reproduce the problem.
>
> To make this process easier, you can use a modified "redhat-rpm-config" 
> package
> from http://people.fedoraproject.org/~halfie/artifacts/redhat-rpm-config/ URL.
>
> $ sha256sum redhat-rpm-config-9.1.0-56.fc20.*
> faad7594b2080fe76497d0ce50808c905a93dd7b41c1defdde5ca57e3833d3d2
> redhat-rpm-config-9.1.0-56.fc20.noarch.rpm
> 5aa9357174305c7285ffdbc92d7ffe1c07a8a95d5459b930461308f5aad75413
> redhat-rpm-config-9.1.0-56.fc20.src.rpm
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [Bug 1037102] New: grass FTBFS if "-Werror=format-security" flag is used

2013-12-04 Thread Markus Neteler

On Wed, Dec 4, 2013 at 12:44 PM, Maris Nartiss  wrote:
> Easy. Do not use -Werror=format-security flag.

... right, not along with --with-nls.
Thanks for the reminder.

> See this thread for details:
> http://lists.osgeo.org/pipermail/grass-dev/2012-August/059157.html

I have added this hint to the ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1037102

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

[GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

Hi list and Markus.

The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I have an 
issue first with filtering and second with rescaling.


1) I can't see any differences in the derived Principal Components between 
percent=70 and percent=99 for 4 bands which the PCs (both centered and scaled) 
are:

PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually?  Shouldn't percent=70 just filter out the 
rest, somehow?


2) a centered but non-scaled attempt, with rescaling (to [0,255] desired] 
gives me floating point PCs as an output:

r.info -rh PC.1
min=167.116641509957
max=1063.871704546
Data Source:
   
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1 142403.37 ( 0.0058,-0.0899,-0.0817,-0.9926) [93.76%]
   PC2   8979.58 ( 0.4285, 0.7402, 0.5071,-0.1062) [ 5.91%]
   PC3416.51 (-0.3800,-0.3668, 0.8483,-0.0388) [ 0.27%]
   PC4 88.39 (-0.8197, 0.5563,-0.1287,-0.0446) [ 0.06%]
   
   i.pca -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix="P\
   C" rescale=0,255 percent=99

This isn't expected, right?


Thanks for this module as well -- it solved big issues (i.e. with hazed 
images), Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2124: Browser data in Table Attribute Manager, avoid to load all the dataset

2013-12-04 Thread GRASS GIS

#2124: Browser data in Table Attribute Manager, avoid to load all the dataset
---+
 Reporter:  zarch  |   Owner:  grass-dev@…  
 Type:  enhancement|  Status:  new  
 Priority:  trivial|   Milestone:  7.0.0
Component:  wxGUI  | Version:  unspecified  
 Keywords:  vector attributes  |Platform:  Unspecified  
  Cpu:  Unspecified|  
---+

Comment(by mlennert):

 Replying to [ticket:2124 zarch]:
 > I would like that the Browser data, start loading in the gui only a
 chunk of the whole dataset, like the first 250 rows, and then
 automatically loads another chunk of rows when I'm close to the bottom.


 +1

 Large datasets can be quite slow to load...

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Thank you and a request on g.gui.mapswipe

Hi Nikos.


On Wed, Dec 4, 2013 at 2:11 AM, Nikos Alexandris 
wrote:

> Vaclav and Anna,
>
> thank yo so muuch for the advancments in g.gui.mapswipes. Really, very
> useful.
>
>
I am glad you find it useful.


> There is one issue in mirror mode: the cross pointer (othen than the one
> set/used by the Operating System) might be in some cases too difficult to
> identify. This leads in trying to look for the pointer instead of focusing
> in
> comparing differences between mirrored images.
>
> A screenshot here:
> <
> http://nikosalexandris.net/owncloud/public.php?service=files&t=644f7a4dabe6e48b4696ae3b67a25cb3
> >.
>
> In the left part, the pinky one is set by the OS. On the right one, it's
> hard
> to trace the thin cross-pointer. Can at least an implementation of changing
> the color be made? Or, any other
> smart solution...
>

In the picture I cannot really see it, it's just not good quality
screenshot or the cursor disappears?

I will try to add the settings of the cursor width and color when I have
more time, the only problem is to create the gui for this. In the meantime,
if you really need to change it, you can always edit the line which draws
the cursor:

Index: gui/wxpython/mapswipe/mapwindow.py
===
--- gui/wxpython/mapswipe/mapwindow.py (revision 58342)
+++ gui/wxpython/mapswipe/mapwindow.py (working copy)
@@ -184,7 +184,7 @@
 def DrawMouseCross(self, coords):
 """!Draw moving cross."""
 self.pdcTmp.ClearId(self.lineid)
-self.lineid = self.DrawCross(pdc = self.pdcTmp, coords = coords,
size = 10, pen = wx.BLACK_PEN)
+self.lineid = self.DrawCross(pdc = self.pdcTmp, coords = coords,
size = 10, pen = wx.Pen(wx.Colour(250, 250, 250), 3))

So tuple (250, 250, 250) is the color as R, G, B and the 3 is the desired
width (currently it uses width 1).

You can then compile it with 'make' in the gui/wxpython directory.

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

Re: [GRASS-dev] Thank you and a request on g.gui.mapswipe

Anna Petrášová wrote:
..
> In the picture I cannot really see it, it's just not good quality
> screenshot or the cursor disappears?

The cursor is really only easy to identify in white or very light-grey areas. 
Indeed, it kinda "disappears".

Thanks for the handcrafting details :-)

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

Re: [GRASS-dev] Thank you and a request on g.gui.mapswipe

Anna Petrášová wrote:

-- cut ---
> -self.lineid = self.DrawCross(pdc = self.pdcTmp, coords = coords,
> size = 10, pen = wx.BLACK_PEN)
-- cut ---

Anna, is it possible to draw a circle? Is this DrawCross pre-defined or is it 
handmade?  If you don't have the time to reply to this I'll look upon it at 
some point later... !? :-)

Thanks, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Thank you and a request on g.gui.mapswipe

On Wed, Dec 4, 2013 at 9:07 AM, Nikos Alexandris 
wrote:

> Anna Petrášová wrote:
>
> -- cut ---
> > -self.lineid = self.DrawCross(pdc = self.pdcTmp, coords = coords,
> > size = 10, pen = wx.BLACK_PEN)
> -- cut ---
>
> Anna, is it possible to draw a circle? Is this DrawCross pre-defined or is
> it
> handmade?  If you don't have the time to reply to this I'll look upon it at
> some point later... !? :-)
>

It's handmade, defined in mapwin/buffered. I guess drawing circle would be
possible but I am not sure if I would advise you to try it and dig into the
code ... But there is also DrawRectangle method so you can try this one.

Anna

> Thanks, Nikos
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling


On 04/12/13 14:53, Nikos Alexandris wrote:

Hi list and Markus.

The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I have an
issue first with filtering and second with rescaling.


1) I can't see any differences in the derived Principal Components between
percent=70 and percent=99 for 4 bands which the PCs (both centered and scaled)
are:

PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually?  Shouldn't percent=70 just filter out the
rest, somehow?


AFAIU, filtering happens after pca: pca is run on all bands, then 
according to the filter percentage you chose inverse pca is run using 
the principal components necessary to reach the filter percentage of 
variance. In your example, 70% would use PC1 and 2 (unless variances is 
rounded up) and 99% would use PC1,2,3. Any difference you see is in the 
resulting images, not in the PCA.


Example with the Landsat bands in the NC data set (group landsat = all 
mx bands):


i.pca -f input=landsat output_prefix=filt percent=90 



Computing covariance matrix...
Using 2 of 6 principal components for filtering


=> For the inverse PCA, only 2 components are used since PC1+PC2>90%


However the info given is about the entire PCA:

Calculating principal components...
Eigen values, (vectors), and [percent importance]:
PC1   4334.35 ( 0.2824, 0.3342, 0.5092,-0.0087, 0.5264, 0.5217) [83.04%]
PC2588.31 ( 0.2541, 0.1885, 0.2923,-0.7428,-0.5110,-0.0403) [11.27%]
PC3239.22 ( 0.3801, 0.3819, 0.2681, 0.6238,-0.4000,-0.2980) [ 4.58%]
PC4 32.85 ( 0.1752,-0.0191,-0.4053, 0.1593,-0.4435, 0.7632) [ 0.63%]
PC5 20.73 (-0.6170,-0.2514, 0.6059, 0.1734,-0.3235, 0.2330) [ 0.40%]
PC6  4.08 (-0.5475, 0.8021,-0.2282,-0.0607,-0.0208, 0.0252) [ 0.08%]

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

Nikos Alexandris wrote:

> > The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I have
> > an issue first with filtering and second with rescaling.
 
> > 1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal 
Components (synthetic images) and, after applying filtering & backward PCA, 
the resulting images approach the original data -- still they are modified.

> > between percent=70 and percent=99 for 4 bands which the PCs (both centered
> > and scaled) are:
> > 
> > PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
> > PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
> > PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
> > PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

> > What is filtering doing actually?  Shouldn't percent=70 just filter out
> > the rest, somehow?

Moritz Lennert wrote:

> AFAIU, filtering happens after pca: pca is run on all bands, then
> according to the filter percentage you chose inverse pca is run using
> the principal components necessary to reach the filter percentage of
> variance. In your example, 70% would use PC1 and 2 (unless variances is
> rounded up) and 99% would use PC1,2,3. Any difference you see is in the
> resulting images, not in the PCA.

Sure -- I didn't (mean to) state otherwise. But, there are no differences in 
the resulting images (after PCA > Filtering > Backward PCA).  Makes sense?  
Apologies for not being very clear.

Thanks from the prompt reaction, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

On Wednesday 04 of December 2013 16:22:51 Nikos Alexandris wrote:
> Nikos Alexandris wrote:
> > > The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I
> > > have
> > > an issue first with filtering and second with rescaling.
> > > 
> > > 1) I can't see any differences in the derived Principal Components
> 
> okay, to clarify: I mean the resulting images which, initially are Principal
> Components (synthetic images) and, after applying filtering & backward PCA,
> the resulting images approach the original data -- still they are modified.

Example (using i.pca in G7, though r.info below executed from G64):



and details for

P=90) r.info -rh PC90N.1

min=171.596979136065
max=1107.42672094831
Data Source:
   
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
   PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
   PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
   PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]
   
   i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
   ="PC90N" rescale=0,0 percent=90


P=70) r.info -rh PC70N.1

min=171.596979136065
max=1107.42672094831
Data Source:
   
   
Data Description:
   generated by i.pca
Comments:
   Eigen values, (vectors), and [percent importance]:
   PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
   PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
   PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
   PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]
   
   i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
   ="PC70N" rescale=0,0 percent=70

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

On 04/12/13 15:22, Nikos Alexandris wrote:

Nikos Alexandris wrote:

The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I have
an issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components

okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.

between percent=70 and percent=99 for 4 bands which the PCs (both centered
and scaled) are:

PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

What is filtering doing actually?  Shouldn't percent=70 just filter out
the rest, somehow?

Moritz Lennert wrote:

AFAIU, filtering happens after pca: pca is run on all bands, then
according to the filter percentage you chose inverse pca is run using
the principal components necessary to reach the filter percentage of
variance. In your example, 70% would use PC1 and 2 (unless variances is
rounded up) and 99% would use PC1,2,3. Any difference you see is in the
resulting images, not in the PCA.

Sure -- I didn't (mean to) state otherwise. But, there are no differences in
the resulting images (after PCA > Filtering > Backward PCA).  Makes sense?
Apologies for not being very clear.

Here I see a difference:

> r.info -r lsat7_2002_10
min=42
max=255

 > r.info -r filt.1
min=49.4097659695008
max=200.074494678242

> r.info -r lsat7_2002_20
min=28
max=255

r.info -r filt.2
min=29.93376973921
max=204.43559249011

etc.

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

Nikos Alexandris wrote:
> > > > 1) I can't see any differences in the derived Principal Components
..
> > okay, to clarify: I mean the resulting images which, initially are
> > Principal Components (synthetic images) and, after applying filtering &
> > backward PCA, the resulting images approach the original data -- still
> > they are modified.

> Example (using i.pca in G7, though r.info below executed from G64):

>..
>PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
>..

Ignore please. I picked the wrong example. It works with percentage = 99 for 
example. Because 70 + 20 = 90 was still inside the 1st component (=96.52).

Sorry for the noise. Then I need to see why the rescaling is not getting at 
[0,255].

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling


On 04/12/13 15:34, Nikos Alexandris wrote:

On Wednesday 04 of December 2013 16:22:51 Nikos Alexandris wrote:

Nikos Alexandris wrote:

The i.pca module in G7 offers a "forward/filtering/backward" PCA.  I
have
an issue first with filtering and second with rescaling.

1) I can't see any differences in the derived Principal Components


okay, to clarify: I mean the resulting images which, initially are Principal
Components (synthetic images) and, after applying filtering & backward PCA,
the resulting images approach the original data -- still they are modified.


Example (using i.pca in G7, though r.info below executed from G64):



and details for

P=90) r.info -rh PC90N.1

min=171.596979136065
max=1107.42672094831
Data Source:


Data Description:
generated by i.pca
Comments:
Eigen values, (vectors), and [percent importance]:
PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
="PC90N" rescale=0,0 percent=90


P=70) r.info -rh PC70N.1

min=171.596979136065
max=1107.42672094831
Data Source:


Data Description:
generated by i.pca
Comments:
Eigen values, (vectors), and [percent importance]:
PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

i.pca -n -f input="Blue_DNs,Green_DNs,Red_DNs,NIR_DNs" output_prefix\
="PC70N" rescale=0,0 percent=70



Which components are used ? IIUC, in both cases it will be PCs 1 and 2 as

PC1 < 70% and PC1 + PC2 > 90%

Moritz


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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

Moritz Lennert wrote:
> Which components are used ? IIUC, in both cases it will be PCs 1 and 2 as
> PC1 < 70% and PC1 + PC2 > 90%

Absolutely true (see previous post, I didn't cc you :().  Yet, consider the 
following cases (just to justify why I started this thread):

1) Centered and Scaled with:

PC1  2.78 ( 0.4947, 0.5922, 0.5743, 0.2735) [69.53%]
PC2  1.08 ( 0.5196, 0.0517,-0.0974,-0.8473) [26.99%]
PC3  0.11 ( 0.4210, 0.2486,-0.7926, 0.3644) [ 2.86%]
PC4  0.03 (-0.5551, 0.7647,-0.1805,-0.2729) [ 0.63%]

here: 69.53 + 26.99 = 96.52

1.1) Get only the 1st

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC70N -f -n percent=70 --o

> r.info -r PC70N.1
min=171.596979136065
max=1107.42672094831

> r.info -r PC70N.2
min=180.569566126261
max=1871.35099616711


1.2) Just above the 1st+2nd, setting p=96.53 > 96.52

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC9653N -f -n percent=96.53 --
o
>r.info -r PC9653N.1
min=171.596979136065
max=1107.42672094831

> r.info -r PC9653N.2
min=180.569566126261
max=1871.35099616711

Why same results here?

1.3) Clearly above 1st + 2nd, setting p=97 > 96.52

i.pca in=Blue_DNs,Green_DNs,Red_DNs,NIR_DNs out=PC97N -f -n percent=97 --o

> r.info -r PC97N.1
min=170.679128221915
max=1090.28043417784

> r.info -r PC97N.2
min=172.894850271274
max=1849.10208527211

The "percent=96.53" gets rounded I guess or so... ? I think in one of my tests 
I got confused due to this.

and 2) Centered only

PC1 142403.37 ( 0.0058,-0.0899,-0.0817,-0.9926) [93.76%]
PC2   8979.58 ( 0.4285, 0.7402, 0.5071,-0.1062) [ 5.91%]
PC3416.51 (-0.3800,-0.3668, 0.8483,-0.0388) [ 0.27%]
PC4 88.39 (-0.8197, 0.5563,-0.1287,-0.0446) [ 0.06%]

here: 93.76 + 5.91 = 99.67

2.1) 1st

>r.info -r PC94N.1
min=171.596979136065


max=1107.42672094831



> r.info -r PC94N.2
min=180.569566126261


max=1871.35099616711



> r.info -r PC9968.1
min=167.116641509957


max=1063.871704546  



> r.info -r PC9968.2
min=180.695102005218
max=1831.85035336866

Here, immediate effect when percent=99.68.  I guess it gets rounded to 99.7 ?

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling


On 04/12/13 16:18, Nikos Alexandris wrote:



Here, immediate effect when percent=99.68.  I guess it gets rounded to 99.7 ?



Actually, the man page says "percent=integer". The input is treated with 
atoi(). I don't know if that rounds or floors..


Moritz

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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

Nikos Alexandris:
> > Here, immediate effect when percent=99.68.  I guess it gets rounded to
> > 99.7 ?

Moritz Lennert:
> Actually, the man page says "percent=integer". The input is treated with
> atoi(). I don't know if that rounds or floors..

Heck, overlooked that :-(.  In my very humble and ever-wannabe-scientist 
opinnion, though, we need those extra digits to make it easy rejecting last 
Principal Component(s) prior to the backward PCA. Might be one, two or 
numerous (?) depending on the dimensions.

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

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve done 
so far.

1. I had to uninstall and reinstall Xcode and the CommandLineTools. You may or 
may not have to do this. If you have not yet updated Xcode, you should delete 
your existing Xcode before doing so. There are several approaches to doing this 
depending on how you installed it. There are references to using an 
Uninstall_Devtools utility that supposedly lives in /Library/Developer. I’ve 
never had this. If you installed from the app store, you need to open the 
launch pad and delete Xcode from there. AFAIK, there is no way to delete the 
CommandLineTools (unless you want to do it one by one). I also installed the 
AuxTools because I had these before. I don’t know that I need them though.

2. I also installed wxPython 2.9.5 so I can compile in 64bit Python 2.7. I also 
installed all the current frameworks from William’s site (I only had to update 
to GDAL 1.10)

3. I had to drop out of my configuration script reference to gettext and odbc. 
I supposed I need to recompile gettext under Mavericks (and maybe LAS but I 
don’t yet know). But I don’t know where the ODBC issue is coming from. I didn’t 
explicitly install that previously.

4. I opened a terminal window, cd to the proper source directory and then typed…

export CXX=g++


5. I configured with…

./configure --with-freetype 
--with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
 /Library/Frameworks/FreeType.framework/unix/include" 
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj 
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config 
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-cairo 
--with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo 
/Library/Frameworks/cairo.framework/unix/include" 
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
--with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-sqlite 
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib 
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include 
--with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include 
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x 
--with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS 
--enable-macosx-app --with-python 
--with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config 
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers 
/Library/Frameworks/Tk.framework/Headers 
/Library/Frameworks/Tk.framework/PrivateHeaders" 
--with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 
x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl

6. I ran…

make GDAL_DYNAMIC=

7. I ran…

make bindist


Making a binary distribution package partly failed. I got a GRASS app but not a 
package, because the packagemaker is no longer with the AuxTools. I’ll need 
guidance from William as to how to use whatever new package making tools are in 
the Dev Tools.


So far, I have not compiled for 10.7 compatibility or bundled wxPython (I’m 
doing that now)

wxPython still crashes on startup due to its inability to create menutree.xml 
and module_tree_menudata.xml. I have to do a work around. I was hoping that 
this might clear up with Python 2.7 and wxPython 2.9. But it has not. So this 
is a problem in the code and not in trying to maintain backward compatibility. 


Once I did all this, GRASS 7 launches. It looks different with wxPython 
2.9—more Linux like and less Maclike to my eyes. 

Also, the terminal begins kicking out the following message every second or so:

2013-12-04 15:31:50.761 Python[78631:d0b] CoreText performance note: Client 
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with 
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript 
names when calling this AP

This needs to be fixed.

I’ll keep you all informed about compiling for Lion and packaging wxPython.

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 (SHES

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

Forgot to mention that r.terraflow and r.viewshed do not compile. I assume this 
is a C++ issue.

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

On Dec 4, 2013, at 3:50 PM, Michael Barton  wrote:

> I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve 
> done so far.
> 
> 1. I had to uninstall and reinstall Xcode and the CommandLineTools. You may 
> or may not have to do this. If you have not yet updated Xcode, you should 
> delete your existing Xcode before doing so. There are several approaches to 
> doing this depending on how you installed it. There are references to using 
> an Uninstall_Devtools utility that supposedly lives in /Library/Developer. 
> I’ve never had this. If you installed from the app store, you need to open 
> the launch pad and delete Xcode from there. AFAIK, there is no way to delete 
> the CommandLineTools (unless you want to do it one by one). I also installed 
> the AuxTools because I had these before. I don’t know that I need them though.
> 
> 2. I also installed wxPython 2.9.5 so I can compile in 64bit Python 2.7. I 
> also installed all the current frameworks from William’s site (I only had to 
> update to GDAL 1.10)
> 
> 3. I had to drop out of my configuration script reference to gettext and 
> odbc. I supposed I need to recompile gettext under Mavericks (and maybe LAS 
> but I don’t yet know). But I don’t know where the ODBC issue is coming from. 
> I didn’t explicitly install that previously.
> 
> 4. I opened a terminal window, cd to the proper source directory and then 
> typed…
> 
> export CXX=g++
> 
> 
> 5. I configured with…
> 
> ./configure --with-freetype 
> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
>  /Library/Frameworks/FreeType.framework/unix/include" 
> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config 
> --with-proj 
> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
>  --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
> --with-cairo 
> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo 
> /Library/Frameworks/cairo.framework/unix/include" 
> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql 
> --with-sqlite 
> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib 
> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include 
> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include 
> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x 
> --with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS 
> --enable-macosx-app --with-python 
> --with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config 
> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers 
> /Library/Frameworks/Tk.framework/Headers 
> /Library/Frameworks/Tk.framework/PrivateHeaders" 
> --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 
> x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl
> 
> 6. I ran…
> 
> make GDAL_DYNAMIC=
> 
> 7. I ran…
> 
> make bindist
> 
> 
> Making a binary distribution package partly failed. I got a GRASS app but not 
> a package, because the packagemaker is no longer with the AuxTools. I’ll need 
> guidance from William as to how to use whatever new package making tools are 
> in the Dev Tools.
> 
> 
> So far, I have not compiled for 10.7 compatibility or bundled wxPython (I’m 
> doing that now)
> 
> wxPython still crashes on startup due to its inability to create menutree.xml 
> and module_tree_menudata.xml. I have to do a work around. I was hoping that 
> this might clear up with Python 2.7 and wxPython 2.9. But it has not. So this 
> is a problem in the code and not in trying to maintain backward 
> compatibility. 
> 
> 
> Once I did all this, GRASS 7 launches. It lo

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

Hi Michael,

thank you for the instructions, I will try it tomorrow or so.

Anna


On Wed, Dec 4, 2013 at 5:50 PM, Michael Barton wrote:

> I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve
> done so far.
>
> 1. I had to uninstall and reinstall Xcode and the CommandLineTools. You
> may or may not have to do this. If you have not yet updated Xcode, you
> should delete your existing Xcode before doing so. There are several
> approaches to doing this depending on how you installed it. There are
> references to using an Uninstall_Devtools utility that supposedly lives in
> /Library/Developer. I’ve never had this. If you installed from the app
> store, you need to open the launch pad and delete Xcode from there. AFAIK,
> there is no way to delete the CommandLineTools (unless you want to do it
> one by one). I also installed the AuxTools because I had these before. I
> don’t know that I need them though.
>
> 2. I also installed wxPython 2.9.5 so I can compile in 64bit Python 2.7. I
> also installed all the current frameworks from William’s site (I only had
> to update to GDAL 1.10)
>
> 3. I had to drop out of my configuration script reference to gettext and
> odbc. I supposed I need to recompile gettext under Mavericks (and maybe LAS
> but I don’t yet know). But I don’t know where the ODBC issue is coming
> from. I didn’t explicitly install that previously.
>
> 4. I opened a terminal window, cd to the proper source directory and then
> typed…
>
> export CXX=g++
>
>
> 5. I configured with…
>
> ./configure --with-freetype
> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
> /Library/Frameworks/FreeType.framework/unix/include"
> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
> --with-proj
> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
> --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-cairo
> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
> /Library/Frameworks/cairo.framework/unix/include"
> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql
> --with-sqlite
> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include
> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x
> --with-cxx --with-opengl=aqua --without-readline
> --prefix=/Applications/GRASS --enable-macosx-app --with-python
> --with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config
> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers
> /Library/Frameworks/Tk.framework/Headers
> /Library/Frameworks/Tk.framework/PrivateHeaders"
> --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386
> x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl
>
> 6. I ran…
>
> make GDAL_DYNAMIC=
>
> 7. I ran…
>
> make bindist
>
>
> Making a binary distribution package partly failed. I got a GRASS app but
> not a package, because the packagemaker is no longer with the AuxTools.
> I’ll need guidance from William as to how to use whatever new package
> making tools are in the Dev Tools.
>
>
> So far, I have not compiled for 10.7 compatibility or bundled wxPython
> (I’m doing that now)
>
> wxPython still crashes on startup due to its inability to create
> menutree.xml and module_tree_menudata.xml. I have to do a work around. I
> was hoping that this might clear up with Python 2.7 and wxPython 2.9. But
> it has not. So this is a problem in the code and not in trying to maintain
> backward compatibility.
>
>
> Once I did all this, GRASS 7 launches. It looks different with wxPython
> 2.9—more Linux like and less Maclike to my eyes.
>
> Also, the terminal begins kicking out the following message every second
> or so:
>
> 2013-12-04 15:31:50.761 Python[78631:d0b] CoreText performance note:
> Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got
> font with PostScript name ".LucidaGrandeUI". For best performance, only use
> PostScript names when calling this AP
>
> This needs to be fixed.
>
> I’ll keep you all informed about compiling for Lion and packaging

[GRASS-dev] Manual of r.reclass regarding removal of reclass maps

Suggestion to alter the manual of r.reclass regarding the removal of an 
"r.reclass" map,

Fom:

Because r.reclass generates a table referencing some original raster map layer 
rather than creating a reclassed raster map layer, a r.reclass map layer will 
no longer be accessible if the original raster map layer upon which it was 
based is later removed.

To:

Because r.reclass generates a table, referencing some original raster map 
layer, rather than creating a reclassed raster map layer, an r.reclass map 
layer would be no longer accessible if the original raster map layer, upon 
which it was based, would have been removed.  Therefore, attempting to remove 
a raster map layer from which an r.reclass has been derived, is only possible 
if the latter is removed first.  Alternatively, a r.reclass map can be removed 
along with its base map by using g.mremove's -b flag.

-- zip --

Also, in the event where the reclass maps have been removed and the the "base" 
maps wont let be removed by g.remove (because the "system" still thinks they 
exist... happens!?), one can force the removal, i.e. `g.remove -f `.  I am not 
sure that this fits in the manual though. It shouldn't happen in first place.  
See also: .

Nikos

ps- I have a diff if this is of interest.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

Some updates.

I changed my terminal environment and configure string for Lion (OSX 10.7) 
compatibility. This involves:

export MACOSX_DEPLOYMENT_TARGET=10.7
export CXX=g++

./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk --with-freetype 
--with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
 /Library/Frameworks/FreeType.framework/unix/include" 
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj 
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config 
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-cairo 
--with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo 
/Library/Frameworks/cairo.framework/unix/include" 
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
--with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-sqlite 
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib 
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include 
--with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include 
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x 
--with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS 
--enable-macosx-app --with-python 
--with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config 
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers 
/Library/Frameworks/Tk.framework/Headers 
/Library/Frameworks/Tk.framework/PrivateHeaders" 
--with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 
x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl

When I did this, r.terraflow and r.viewshed compiled.

I still have the xml problem

This message is still repeating in the terminal:

2013-12-04 16:25:16.568 Python[17513:d0b] CoreText performance note: Client 
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with 
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript 
names when calling this API.

A raster map displays fine

When I first tried NVIZ, I got an error in the terminal. When I tried it again, 
it worked and the error disappeared (so I cannot copy and paste it here).

I got this warning once:

/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gui_core/goutput.py:234:
 wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints’. 

The digitizer is acting funny. When I called my new test vector “delete”, it 
crashed the GUI. When I tried it again, with “testdelete1” it is OK. But now it 
is giving me an error that the cat number is duplicated  with my first area. It 
is locked up and I can’t get out of some kind of loop with the dialog to create 
a table entry. But this may be problems with the digitizer in general rather 
than the new compilation. 

I had the GUI lock up earlier but it seems to be working OK now, if a bit 
sluggish. Tearoff menus are fine. The vector graphics look much nicer. I think 
that Cairo is displaying better with this wxPython. 

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

On Dec 4, 2013, at 3:54 PM, Michael Barton  wrote:

> Forgot to mention that r.terraflow and r.viewshed do not compile. I assume 
> this is a C++ issue.
> 
> 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
> 
> On Dec 4, 2013, at 3:50 PM, Michael Barton  wrote:
> 
>> I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve 
>> done so

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

After clicking the “save” buttons in preferences, the GUI is no longer 
responsive.

Also, the “window” menu has disappeared so I can no longer see if any other 
wxPython windows are open or not.

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

On Dec 4, 2013, at 3:54 PM, Michael Barton  wrote:

> Forgot to mention that r.terraflow and r.viewshed do not compile. I assume 
> this is a C++ issue.
> 
> 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
> 
> On Dec 4, 2013, at 3:50 PM, Michael Barton  wrote:
> 
>> I was able to compile and open GRASS 7 under Mavericks. Here is what I’ve 
>> done so far.
>> 
>> 1. I had to uninstall and reinstall Xcode and the CommandLineTools. You may 
>> or may not have to do this. If you have not yet updated Xcode, you should 
>> delete your existing Xcode before doing so. There are several approaches to 
>> doing this depending on how you installed it. There are references to using 
>> an Uninstall_Devtools utility that supposedly lives in /Library/Developer. 
>> I’ve never had this. If you installed from the app store, you need to open 
>> the launch pad and delete Xcode from there. AFAIK, there is no way to delete 
>> the CommandLineTools (unless you want to do it one by one). I also installed 
>> the AuxTools because I had these before. I don’t know that I need them 
>> though.
>> 
>> 2. I also installed wxPython 2.9.5 so I can compile in 64bit Python 2.7. I 
>> also installed all the current frameworks from William’s site (I only had to 
>> update to GDAL 1.10)
>> 
>> 3. I had to drop out of my configuration script reference to gettext and 
>> odbc. I supposed I need to recompile gettext under Mavericks (and maybe LAS 
>> but I don’t yet know). But I don’t know where the ODBC issue is coming from. 
>> I didn’t explicitly install that previously.
>> 
>> 4. I opened a terminal window, cd to the proper source directory and then 
>> typed…
>> 
>> export CXX=g++
>> 
>> 
>> 5. I configured with…
>> 
>> ./configure --with-freetype 
>> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
>>  /Library/Frameworks/FreeType.framework/unix/include" 
>> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
>> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config 
>> --with-proj 
>> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
>> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
>> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
>> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
>>  --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
>> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
>> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
>> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
>> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
>> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
>> --with-cairo 
>> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
>>  /Library/Frameworks/cairo.framework/unix/include" 
>> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
>> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql 
>> --with-sqlite 
>> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib 
>> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include 
>> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include 
>> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x 
>> --with-cxx --with-opengl=aqua --without-readline 
>> --prefix=/Applications/GRASS --enable-macosx-app --with-python 
>> --with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config 
>> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers 
>> /Library/Frameworks/Tk.framework/Headers 
>> /Library/Frameworks/Tk.framework/PrivateHeaders" 
>> --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386 
>> x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl
>> 
>> 6. I ran…
>>

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

On Wed, Dec 4, 2013 at 6:39 PM, Michael Barton wrote:

> Some updates.
>
> I changed my terminal environment and configure string for Lion (OSX 10.7)
> compatibility. This involves:
>
> export MACOSX_DEPLOYMENT_TARGET=10.7
> export CXX=g++
>
> ./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk
> --with-freetype
> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
> /Library/Frameworks/FreeType.framework/unix/include"
> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
> --with-proj
> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
> --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-cairo
> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
> /Library/Frameworks/cairo.framework/unix/include"
> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql
> --with-sqlite
> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include
> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x
> --with-cxx --with-opengl=aqua --without-readline
> --prefix=/Applications/GRASS --enable-macosx-app --with-python
> --with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config
> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers
> /Library/Frameworks/Tk.framework/Headers
> /Library/Frameworks/Tk.framework/PrivateHeaders"
> --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386
> x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl
>
>
> When I did this, r.terraflow and r.viewshed compiled.
>
> I still have the xml problem
>
> This message is still repeating in the terminal:
>
> 2013-12-04 16:25:16.568 Python[17513:d0b] CoreText performance note:
> Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got
> font with PostScript name ".LucidaGrandeUI". For best performance, only use
> PostScript names when calling this API.
>

If this is not causing anything, I would ignore it, this is apparently
related to Maverick, maybe they will fix it later.


> A raster map displays fine
>
> When I first tried NVIZ, I got an error in the terminal. When I tried it
> again, it worked and the error disappeared (so I cannot copy and paste it
> here).
>
> I got this warning once:
>
> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gui_core/goutput.py:234:
> wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints’.
>

This is harmless, I could probably remove the  calls of
SetVirtualSizeHints, but I am not sure if it is needed in the older
wxPython versions.

>
> The digitizer is acting funny. When I called my new test vector “delete”,
> it crashed the GUI. When I tried it again, with “testdelete1” it is OK. But
> now it is giving me an error that the cat number is duplicated  with my
> first area. It is locked up and I can’t get out of some kind of loop with
> the dialog to create a table entry. But this may be problems with the
> digitizer in general rather than the new compilation.
>
> I had the GUI lock up earlier but it seems to be working OK now, if a bit
> sluggish. Tearoff menus are fine. The vector graphics look much nicer. I
> think that Cairo is displaying better with this wxPython.
>

Please report the issues (via trac) related to the wxPython 2.9, I already
tried to fix some of these but there will be more of them. I need the
issues to be reproducible.


Anna



> 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
>
> On Dec 4, 2013, at 3:54 PM, Michael Barton  wrote:
>
> > Forgot to mention that r.terraflow and r.viewshed do not compile. I
> assume this is a C

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

On Dec 4, 2013, at 7:16 PM, Anna Petrášová
mailto:kratocha...@gmail.com>> wrote:

On Wed, Dec 4, 2013 at 6:39 PM, Michael Barton
mailto:michael.bar...@asu.edu>> wrote:
Some updates.

I changed my terminal environment and configure string for Lion (OSX 10.7)
compatibility. This involves:

export MACOSX_DEPLOYMENT_TARGET=10.7
export CXX=g++

./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk --with-freetype
--with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
/Library/Frameworks/FreeType.framework/unix/include"
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--with-cairo
--with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
/Library/Frameworks/cairo.framework/unix/include"
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
--with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-sqlite
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include
--with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x
--with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS
--enable-macosx-app --with-python
--with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers
/Library/Frameworks/Tk.framework/Headers
/Library/Frameworks/Tk.framework/PrivateHeaders"
--with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386
x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl

When I did this, r.terraflow and r.viewshed compiled.

I still have the xml problem

This message is still repeating in the terminal:

2013-12-04 16:25:16.568 Python[17513:d0b] CoreText performance note: Client
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript
names when calling this API.

If this is not causing anything, I would ignore it, this is apparently related
to Maverick, maybe they will fix it later.

This only happens when I am running GRASS. It makes GRASS very difficult to
use. There is something going on that is causing this with GRASS that is not
happening with other apps run from the terminal.

A raster map displays fine

When I first tried NVIZ, I got an error in the terminal. When I tried it again,
it worked and the error disappeared (so I cannot copy and paste it here).

I got this warning once:

/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gui_core/goutput.py:234:
wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints’.

This is harmless, I could probably remove the calls of SetVirtualSizeHints,
but I am not sure if it is needed in the older wxPython versions.

I assume this is a function of wxPython 2.9

The digitizer is acting funny. When I called my new test vector “delete”, it
crashed the GUI. When I tried it again, with “testdelete1” it is OK. But now it
is giving me an error that the cat number is duplicated with my first area. It
is locked up and I can’t get out of some kind of loop with the dialog to create
a table entry. But this may be problems with the digitizer in general rather
than the new compilation.

I had the GUI lock up earlier but it seems to be working OK now, if a bit
sluggish. Tearoff menus are fine. The vector graphics look much nicer. I think
that Cairo is displaying better with this wxPython.

Please report the issues (via trac) related to the wxPython 2.9, I already
tried to fix some of these but there will be more of them. I need the issues to
be reproducible.

I am wondering if I should revert to wxPython 2.8. This requires some hacks to
it runs 32bit I think. But it is what I was using before.

Michael

Anna

Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State Unive

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks

On Wed, Dec 4, 2013 at 10:47 PM, Michael Barton wrote:

>
>
>  On Dec 4, 2013, at 7:16 PM, Anna Petrášová  wrote:
>
>
>
>
> On Wed, Dec 4, 2013 at 6:39 PM, Michael Barton wrote:
>
>> Some updates.
>>
>> I changed my terminal environment and configure string for Lion (OSX
>> 10.7) compatibility. This involves:
>>
>> export MACOSX_DEPLOYMENT_TARGET=10.7
>> export CXX=g++
>>
>> ./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk
>> --with-freetype
>> --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2
>> /Library/Frameworks/FreeType.framework/unix/include"
>> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
>> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
>> --with-proj
>> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
>> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
>> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
>> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
>> --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
>> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
>> --with-cairo
>> --with-cairo-includes="/Library/Frameworks/cairo.framework/unix/include/cairo
>> /Library/Frameworks/cairo.framework/unix/include"
>> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
>> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql
>> --with-sqlite
>> --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
>> --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include
>> --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
>> --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x
>> --with-cxx --with-opengl=aqua --without-readline
>> --prefix=/Applications/GRASS --enable-macosx-app --with-python
>> --with-wxwidgets=/usr/local/lib/wxPython-2.9.5.0/bin/wx-config
>> --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers
>> /Library/Frameworks/Tk.framework/Headers
>> /Library/Frameworks/Tk.framework/PrivateHeaders"
>> --with-tcltk-libs="/usr/local/tcltk_active/lib" --with-macosx-archs="i386
>> x86_64" --with-liblas="/usr/local/bin/liblas-config" --with-opencl
>>
>>
>> When I did this, r.terraflow and r.viewshed compiled.
>>
>> I still have the xml problem
>>
>> This message is still repeating in the terminal:
>>
>> 2013-12-04 16:25:16.568 Python[17513:d0b] CoreText performance note:
>> Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got
>> font with PostScript name ".LucidaGrandeUI". For best performance, only use
>> PostScript names when calling this API.
>>
>
>  If this is not causing anything, I would ignore it, this is apparently
> related to Maverick, maybe they will fix it later.
>
>
>  This only happens when I am running GRASS. It makes GRASS very difficult
> to use. There is something going on that is causing this with GRASS that is
> not happening with other apps run from the terminal.
>

Does it happen only with the gui open?


>
>
>
>> A raster map displays fine
>>
>> When I first tried NVIZ, I got an error in the terminal. When I tried it
>> again, it worked and the error disappeared (so I cannot copy and paste it
>> here).
>>
>> I got this warning once:
>>
>> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gui_core/goutput.py:234:
>> wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints’.
>>
>
>  This is harmless, I could probably remove the  calls of
> SetVirtualSizeHints, but I am not sure if it is needed in the older
> wxPython versions.
>
>
>  I assume this is a function of wxPython 2.9
>

SetVirtualSizeHints is used in wxPython 2.8, in 2.9 it's not needed, that's
why the depreciation warning.


>
>
>> The digitizer is acting funny. When I called my new test vector “delete”,
>> it crashed the GUI. When I tried it again, with “testdelete1” it is OK. But
>> now it is giving me an error that the cat number is duplicated  with my
>> first area. It is locked up and I can’t get out of some kind of loop with
>> the dialog to create a table entry. But this may be problems with the
>> digitizer in general rather than the new compilation.
>>
>> I had the GUI lock up earlier but it seems to be working OK now, if a bit
>> sluggish. Tearoff menus are fine. The vector graphics look much nicer. I
>> think that Cairo is displaying better with this wxPython.
>>
>
>  Please report the issues (via trac) related to the wxPython 2.9, I
> already tried to fix some of these but there will be more of them. I need
> the issues

Re: [GRASS-dev] trying to compile GRASS 7 on Mavericks