date:20090617


maven apache:
> This is what I am not sure, I only get the number
> respent the category,but I am not sure what it stand for,for
> example the number in first line:9321,does it stand for red?
> or blue?

d.what.rast or r.what can help. or raster query tool from GUI.


Hamish



  

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

Re: [GRASS-user] v.proj failed

Markus M wrote:
> If the latlon region crosses the 180E/W border, this is an
> inherent bug

note for raster modules -180 to +360 are supported. that way
both -180 to +180 and 0 to 360 are supported. (platenary
scientists like to work in 0-360) 
A goal is that vector modules should be lat/lon wrap aware and
suppot the same (this largely lags behind lat/lon support in
raster libs/modules).

Hamish

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

Re: [GRASS-user] Native WinGRASS 6.4 RC5 g.proj failure


Hamish: 
> > found it,
> >   https://trac.osgeo.org/grass/ticket/654
> > 
> > I traced this back to r37726 where wind_format.c's
> > format_double() uses G_projection() which wants to check
> > the projection type (and that hasn't been created yet).
> > Not sure of the best solution yet.

Glynn:
> I suggest simply reverting r37726. Changing a function so
> that it requires GRASS to have been initialised ($GISRC,
> WIND, etc) when it didn't previously is a fundamental API
> change.

I really hesitate to do that, because then lat/lon support in
the GUIs will again be subject to loss of precision for
resolution and the rounding errors that go along with that.
(%.8f is not enough to preserve the resolution once converted
to DMS and back again)


instead my proposed solution is to remove G_projection() from
format_double() [satisfying your concerns] and allow programmers
to specify "-1" for the target projection option to get full
%.15g instead of lying to the function about the projection type
in order to get the desired format.


Hamish





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

Re: [GRASS-user] Native WinGRASS 6.4 RC5 g.proj failure

2009-06-17 Thread Glynn Clements


Hamish wrote:

> (
> ERROR: region for current mapset is not set
>run "g.region"
> )
> 
> found it,
>   https://trac.osgeo.org/grass/ticket/654
> 
> I traced this back to r37726 where wind_format.c's format_double()
> uses G_projection() which wants to check the projection type (and that
> hasn't been created yet). Not sure of the best solution yet.

I suggest simply reverting r37726. Changing a function so that it
requires GRASS to have been initialised ($GISRC, WIND, etc) when it
didn't previously is a fundamental API change.

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

Re: [GRASS-user] v.proj failed

2009-06-17 Thread Markus GRASS

Tim Michelsen wrote:
> Hello,
> I am trying to reproject a vector from latlon/wgs84 to a UTM/projected
> location
>
> The program aborts with the message:
>
> v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.
>
> What does this mean?
Bug in the spatial index.
>
> How can I get around this?
Maybe outside grass with ogr2ogr -t_srs

If the latlon region crosses the 180E/W border, this is an inherent bug
that could only be fixed by modifying vector coordinates outside grass
AFAIKT.

Please report to trac and if possible make the vector available as
attachment or a link. UTM projection parameters (EPSG code or proj4
string) may also be helpful to reproduce the problem.

Markus M
>
> I run this comand Ubuntu 9.04, 64svn.
>
> Thanks for your help in advance.
>
> Regards,
>
> Timmie
>
> ___
> 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] v.proj failed

2009-06-17 Thread Tim Michelsen


Hello,
I am trying to reproject a vector from latlon/wgs84 to a UTM/projected 
location


The program aborts with the message:

v.proj: split_q.c:69: RTreeClassify: Assertion `!p->taken[i]' failed.

What does this mean?

How can I get around this?

I run this comand Ubuntu 9.04, 64svn.

Thanks for your help in advance.

Regards,

Timmie

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

Re: [GRASS-user] Criteria for v.clean tool=rmdangle

2009-06-17 Thread Dwight Needels

On Jun 17, 2009, at 11:13 AM, Markus GRASS wrote:

Maybe start with a lower threshold first, e.g. 5 ft to remove D and E
first, then increase the threshold for any other, longer dangles you
would like to remove

This is exactly what I ended up doing, and it works great. The only
question is how fine a distinction I want to make (do I really care if
it removes a 25 ft dangle while leaving a 30 ft dangle or removes a 5
ft while leaving a 10 ft?). For my GPS tracks I ended up running
v.clean tool=rmdangle three times with threshold of 10, 20 and 30 ft.

It may be worth having a note called "What is a dangle?", but
regardless it would be good to have a statement that says something
like...

"The rmdangle tool processes dangles sequentially by internal Id,
which may result in short lines with high Id values remaining after
lines with lower Id values have been deleted from the nearest branch
point."

Does any of this look incorrect? Can the processing by internal Id be
confirmed?

According to the source code, the rmdangle tool processes nodes by
internal id, not lines. As soon as it finds a node with only one line
connected, it looks at the length and the other end node. If only one
other line is connected at that other end node, the length of that one
is added. That continues until a node is found with more than two
lines

of the desired type connecting to it. If the accumulated length is
smaller than threshold or threshold is < 0, all lines from the start
node up to that node are removed.

I have updated the manual in grass-6.4.svn, please have a look at it
[1]
and give feedback if it is now better explained what the different
tools
do. You can safe a local copy of the html file for nicer display. I
did
not modify the tooltip description in the GUI, that's long enough
already.

[1]
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/vector/v.clean/description.html

Markus M

I looked at the updated manual, and I like the description for the
rmdangle tool (big improvement). There are several somewhat surprising
(but predictable) behaviors that it might be useful to point out.

A) It sometimes removes lines that are not part of a dangle in the
original vector (line B in my test case). Specifically, if two branch
points are connected by a short line, this connecting line may end up
deleted as part of a newly created dangle. This probably won't happen
very often without a very large or negative thresh, because it
requires a single node with 3 short lines attached.

B) It sometimes doesn't remove lines that are part of a dangle in the
original vector (line E in my test case). Specifically, if the
original vector has a node with two dangles shorter than threshold,
one of them (the one with the larger internal Id) will not be deleted.
This will only happen where there is a single node with 2 short lines
attached (e.g. near a terminus).

C) It sometimes ends up with a vector that still has dangles, which
require a second pass (and, conceivably even a third pass).

D) Use of a negative threshold removes a somewhat surprising number of
lines, but in a useful way (leaving loops and lines connecting loops).
I have attached two screenshots showing this with my averaged GPS
trail data (gray is original vector, red is vector after v.clean tool-
rmdangle thresh=-1).

All of these quirks have the same underlying cause... the rmdangle
tool does not remove all dangles in the original vector, it
sequentially removes dangles one at a time and doesn't go back to
lines it has already processed. If run repeatedly, the final vector
will have no dangles shorter than threshold, but this is different
than removing all of the dangles in the original. Perhaps this
underlying behavior can be communicated with something like the text
below.

Existing text...
"Threshold gives maximum line/boundary length in map units, degrees
for latlon. Dangles shorter than thresh will be removed. All dangles
will be removed if thresh < 0."

Suggested text...
"Threshold gives maximum line/boundary length in map units, degrees
for latlon. Dangles shorter than thresh are removed sequentially.
Lines that are not either part of a loop or connecting two loops will
be removed if thresh < 0."

And perhaps under Notes, something like...

"The lines removed by the rmdangle tool will sometimes not be the same
as the dangles in the original vector. For example, if the original
vector has a node with two dangles shorter than threshold, one of them
(the one with the larger internal Id) will not be deleted, because it
is no longer part of a dangle. If the tool is run repeatedly, the
final vector will have no dangles shorter than thresh. To
preferentially remove the shortest dangles, use a small thresh value
in the first pass, and a larger value in the second pass."

Thanks, -Dwight

<><>___
grass-user maili

RE: [GRASS-user] Write python grass program with osgeo4w

2009-06-17 Thread Moskovitz, Bob

I changed grass.py with the changes in changeset 37075.  Although I'm no longer 
getting any error messages, I am not able to see my script help by simply 
typing "m.test.py --help".  

When I try "python C:\OSGeo4W\apps\grass\grass-6.4.0svn\scripts\m.test.py 
--help", I do see the help.  Without "--help", m.test.py doesn't start up in a 
gui.

What must be done to make python scripts to behave like regular grass commands?

Bob

> -Original Message-
> From: Glynn Clements [mailto:gl...@gclements.plus.com]
> Sent: Saturday, June 13, 2009 7:56 AM
> To: Moskovitz, Bob
> Cc: Grass-User (E-mail)
> Subject: Re: [GRASS-user] Write python grass program with osgeo4w
> 
> 
> 
> Moskovitz, Bob wrote:
> 
> > A coworker and I have been trying to use the first example in
> > 
> > http://download.osgeo.org/grass/grass6_progman/pythonlib.html.  We
> > discovered that "import grass.script as grass" has to be changed to
> > "import grass".  Below is the example and the error we are 
> getting is
> > this:
> >  
> > C:\>m.test.py
> > Traceback (most recent call last):
> >   File 
> "C:\OSGeo4W\apps\grass\GRASS-~1.0SV/scripts\m.test.py", line 
> 31, in 
> > options, flags = grass.parser()
> >   File 
> "C:\OSGeo4W\apps\grass\GRASS-~1.0SV\etc\python\grass.py", 
> line 208, in parser
> > os.execvp("g.parser", [name] + argv)
> >   File "C:\OSGeo4W\apps\Python25\lib\os.py", line 353, in execvp
> > _execvpe(file, args)
> >   File "C:\OSGeo4W\apps\Python25\lib\os.py", line 389, in _execvpe
> > func(fullname, *argrest)
> > OSError: [Errno 22] Invalid argument
> >  
> >  
> > Any ideas what is going on?
> 
> This is a bug in grass.py; Windows requires "g.parser.exe" rather than
> "g.parser". This was fixed with:
> 
>   http://trac.osgeo.org/grass/changeset/37075
> 
> -- 
> Glynn Clements 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.delaunay Bug in Mac OS X

2009-06-17 Thread Michael Perdue


OOPS, forgot to hit the list with this one.

On 17-Jun-09, at 2:30 AM, Hamish wrote:



William wrote:

I don't see any changes in v.delaunay
itself from RC4, though maybe there are changes in the
vector libraries.  Did this work in RC4?


Note since Nov 26 2008 (ie all 6.4.0RCs) v.delaunay has been  
completely

replaced by v.delaunay2 which was a Google summer of code project last
year. It shares the same name and options but is an entirely new  
program

on the inside.

was the working version 6.3.0? (ie old version of the module)


Yes. v.delaunay works fine in 6.3.0 on OS X.

Mike

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

Re: [GRASS-user] Criteria for v.clean tool=rmdangle

2009-06-17 Thread Markus GRASS

Dwight Needels wrote:
> On Jun 16, 2009, at 3:41 AM, Markus GRASS wrote:
>
>> Dwight Needels wrote:
>>>
>>> When the rmdangle tool runs into a pair of dangles at the end of a
>>> line where each is shorter than threshold (a "Y"), it removes one but
>>> leaves the other. This makes sense, because after the first one is
>>> removed the second one is no longer a dangle (it is now the terminal
>>> line segment).
>> "Line segment" is confusing because it refers to a part of a line, e.g.
>> a part of line C or A. Line E may have only one segment, line C is
>> composed of several segments.
>
> Agreed; but I keep using the term unconsciously to distinguish that
> portion of a line that falls between a pair of nodes. The term "line"
> is ambiguous because it is also used to refer to an entire polyline.
> For example,the Vector Introduction says "Note that all lines and
> boundaries can be polylines (with nodes in between)" 
Which is confusing, and I guess comes from some previous GRASS version.
Maybe what is rather meant is that all lines and boundaries can consist
of multiple segments and any number of vertices. The shapefile-like
polyline is not as such supported in GRASS vectors, with the exception
of boundaries that make up an area, but these "polylines" are stored
internally in topology for each area.
> rather than something like:
>
> "line: a directed sequence of connected vertices with exactly two
> endpoints called nodes", and
> "polyline: a non-branching series of connected lines or boundaries
> with a shared node at each connection"
Polyline is not a GRASS vector object available to users, these are only
point,line,boundary,centroid,area,kernel,face.
>
> For this discussion I will try to restrict myself to the above
> definitions, so that the term "line" will never refer to a polyline.
> This seems to be consistent with your usage. Would it be useful to
> make this distinction explicit on the Vector Introduction page?
Definitively!
>
> Line E is not removed, because the sum of the line lengths from
> terminus to the closest branch point/terminus is greater than the
> threshold (despite the length of Line E being below the threshold).
Maybe start with a lower threshold first, e.g. 5 ft to remove D and E
first, then increase the threshold for any other, longer dangles you
would like to remove

>
>
> It may be worth having a note called "What is a dangle?", but
> regardless it would be good to have a statement that says something
> like...
>
> "The rmdangle tool processes dangles sequentially by internal Id,
> which may result in short lines with high Id values remaining after
> lines with lower Id values have been deleted from the nearest branch
> point."
>
> Does any of this look incorrect? Can the processing by internal Id be
> confirmed?
According to the source code, the rmdangle tool processes nodes by
internal id, not lines. As soon as it finds a node with only one line
connected, it looks at the length and the other end node. If only one
other line is connected at that other end node, the length of that one
is added. That continues until a node is found with more than two lines
of the desired type connecting to it. If the accumulated length is
smaller than threshold or threshold is < 0, all lines from the start
node up to that node are removed.

I have updated the manual in grass-6.4.svn, please have a look at it [1]
and give feedback if it is now better explained what the different tools
do. You can safe a local copy of the html file for nicer display. I did
not modify the tooltip description in the GUI, that's long enough already.

[1]
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/vector/v.clean/description.html

Markus M

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

[GRASS-user] Re: [GRASS-dev] New WinGrass Release (6.4.0RC5)

2009-06-17 Thread Martin Landa

Hi,

2009/6/17 Hamish :
>
> Martin wrote:
>> the last time I ended up in the hell of mixing libraries built using
>> mingw (GRASS) and msvs (wxpython). Currently I have no time for this
>> kind of "fun". If somebody put on wiki instructions how to overcome
>> this problem I will be happy to fix MS Windows related bugs to make
>> these extensions working under MS Windows.
>
> have you tried the updated & simplified build instructions using osgeo4w
> as the framework?
>
> https://trac.osgeo.org/grass/wiki/CompileOnWindows

sure, I followed these instructions - but it doesn't help you to make
the Python extensions working (swig-related failure - probably because
wxPython is built using msvs and GRASS with mingw).

Martin

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

[GRASS-user] r.out.vtk RGB / input issue

2009-06-17 Thread peter . loewe

hi,

i am using v.out.vtk on grass6.3 on suse.

trying to export 2.5d rgb-maps to paraview using r.out.vtk always ends up with 
an error message:

According to the module's manual it should be possible to export a RGBmap + dem 
by using the parameters

rgbmaps=redmap,bluemap,greenmap elevation=my_dem output=result.vtk

However, the module reports that the INPUT parameter has to be provided.

trying 

input=rgbmap rgbmaps=redmap,bluemap,greenmap elevation=my_dem output=result.vtk

results in the same as 

input=rgbmap elevation=my_dem output=result.vtk

In both cases "result.vtk" is displayed with interpolated false colors.

How can a RGB composite created in GRASS properly be transferred and displayed 
in Paraview ?

Peter
-- 
Dr. Peter Löwe






GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)

2009-06-17 Thread Daniel Victoria

To be sure what number corresponds to what color, just plot your map
and use the mouse query tool (r.what). Then you can click on a color
and see the category number pop up on screen...

On Wed, Jun 17, 2009 at 10:04 AM, maven apache wrote:
>>> And if you want to improve the output, then two steps:
>>> First use r.category to give a label to each category like so:
>>> (assuming the first is black)
>
> This is what I am not sure, I only get the number respent the category,but I
> am not sure what it stand for,for example the number in first line:9321,does
> it stand for red? or blue?
>>>
>>> echo "0:Black" | r.category outss rules=-
>>> (note the '-' which means "read from stdin")
>>> Next use r.report like so:
>>> r.report outss unit=k
>>> (gives a table with the cat value, the label and area in sqkm)
>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>
>
>
> ___
> 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] can the grass calculate the area of different color for a image(tiff or other?)

>
>  And if you want to improve the output, then two steps:
>> First use r.category to give a label to each category like so:
>> (assuming the first is black)
>>
> This is what I am not sure, I only get the number respent the category,but
I am not sure what it stand for,for example the number in first
line:9321,does it stand for red? or blue?

>
>> echo "0:Black" | r.category outss rules=-
>> (note the '-' which means "read from stdin")
>> Next use r.report like so:
>> r.report outss unit=k
>> (gives a table with the cat value, the label and area in sqkm)
>>
>
>
> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)


Moritz Lennert wrote:


On 17/06/09 14:06, maven apache wrote:
I got a.green a.red a.blue and a.alpha four raster,then follow the 
advise from this list I composite the three map g b r to a new 
raster:outss
then I run the commond r.stats -a input=ou...@permanent 
 fs=space nv=* nsteps=255

got the following output
 
0 429847.542397

9321 212745757.083273
26425 4430667.032198
31744 5444337463.194785
32736 35683640.857434
32767 92624.052023
 
I wonder what do the first number in each line respent? And the 
second number in each respent the area?



RTFM ;-)

The first number is the category number, i.e. the different categories 
(in your case colors) present in your map.
The second number gives the area statistics which are given in units 
of square meters.


Moritz


And if you want to improve the output, then two steps:
First use r.category to give a label to each category like so:
(assuming the first is black)
echo "0:Black" | r.category outss rules=-
(note the '-' which means "read from stdin")
Next use r.report like so:
r.report outss unit=k
(gives a table with the cat value, the label and area in sqkm)


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

This mail was received via Mail-SeCure System.




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

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)

2009-06-17 Thread Moritz Lennert


On 17/06/09 14:06, maven apache wrote:
I got a.green a.red a.blue and a.alpha four raster,then follow the 
advise from this list I composite the three map g b r to a new raster:outss
then I run the commond r.stats -a input=ou...@permanent 
 fs=space nv=* nsteps=255

got the following output
 
0 429847.542397

9321 212745757.083273
26425 4430667.032198
31744 5444337463.194785
32736 35683640.857434
32767 92624.052023
 
I wonder what do the first number in each line respent? And the second 
number in each respent the area?



RTFM ;-)

The first number is the category number, i.e. the different categories 
(in your case colors) present in your map.
The second number gives the area statistics which are given in units of 
square meters.


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

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)

I got a.green a.red a.blue and a.alpha four raster,then follow the advise
from this list I composite the three map g b r to a new raster:outss
then I run the commond r.stats -a input=ou...@permanent fs=space nv=*
nsteps=255
got the following output

0 429847.542397
9321 212745757.083273
26425 4430667.032198
31744 5444337463.194785
32736 35683640.857434
32767 92624.052023

I wonder what do the first number in each line respent? And the second
number in each respent the area?
2009/6/17 Micha Silver 

>  maven apache wrote:
>
> Yes
> My tiff have 5 color, red blue green and pink and yellow. I want get the
> area for each color..
> First I import the tiff .however I got a.green a.red a.blue and a.alpha
> four raster.
>
> Multi-band tiffs are imported as separate bands. You can combine them with
> r.composite.
>
>
> 2009/6/17 Micha Silver 
>
>> maven apache wrote:
>>
>> can the grass calculate the area of different color for a image?
>>> I have a tiff, and I have seen five color in it,I wonder I can calculate
>>> the area for each color with grass?
>>>
>> Did you check out r.stats -a ?
>>
>>
>>> This mail was received via Mail-SeCure System.
>>> 
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>>
>>>
>>
>>
>
> This mail was received via Mail-SeCure System.
>
> --
>
> ___
> grass-user mailing 
> listgrass-u...@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>
> This mail was received via Mail-SeCure System.
>
>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)





maven apache wrote:


  Yes
  My tiff have 5 color, red blue green and pink and yellow. I want
get the area for each color..
  First I import the tiff .however I got a.green a.red a.blue and
a.alpha four raster.
  

Multi-band tiffs are imported as separate bands. You can combine them
with r.composite.


  
  
  2009/6/17 Micha Silver 
  
maven apache wrote:

can the grass calculate the area of different
color for a image?
I have a tiff, and I have seen five color in it,I wonder I can
calculate the area for each color with grass?


Did you check out r.stats -a ?


This mail was received via Mail-SeCure System.

  
___
grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
  
This mail was received via Mail-SeCure System.
  
  
 


  
  
  
  
This mail was received via Mail-SeCure System.
  

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

This mail was received via Mail-SeCure System.


  




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

Re: [GRASS-user] Native WinGRASS 6.4 RC5 g.proj failure


maven apache wrote:
> I think I came across the same problem of the g.proj
> the commond "g.proj -c
> georef=d:\swilAlphaTIFF.tif location=tset" works
> well in grass6.3 get some warning in grass6.4 6.4 RC5
> :
>  
> (Wed Jun 17 18:27:31
> 2009) 
> 
> g.proj -c georef=d:\swilAlphaTIFF.tif location=tset
> 
> Trying to open with OGR...
> Trying to open with GDAL...
> 
> ...succeeded.
> ERROR: 要得到当前地图集未设置的范围
> 请运行 "g.region"
>  

(
ERROR: region for current mapset is not set
   run "g.region"
)

found it,
  https://trac.osgeo.org/grass/ticket/654

I traced this back to r37726 where wind_format.c's format_double() uses 
G_projection() which wants to check the projection type (and that hasn't been 
created yet). Not sure of the best solution yet.


Hamish





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

Re: [GRASS-user] Native WinGRASS 6.4 RC5 g.proj failure





Hamish wrote:


  Micha wrote:
  
  
I installed GRASS on WinXP using the
setup file of the new version of WinGRASS from: 
http://grass.osgeo.org/grass64/binary/mswindows/native/

When starting GRASS, as long as I point to an existing
GRASS GISDBASE it works fine. But if I try to set up a new
GISDBASE, new location and mapset (based on epsg codes) the
"location wizard" fails, popping up an error window (as in
the attached image).

  
  
this doesn't diminish the bug any, but what's wrong with two locations
in the same GISDBASE?
  

Well, nothing of course. But a GISDBASE with *no* location is certainly
a problem ;-)


  

  
  
This bug is something of a show-stopper since without a
properly defined location GRASS will not start. Even if I
start GRASS with the command line and try to run g.proj -c
or g.setproj they also fail. So without jumping thru some
tricky hoops, editting PROJ_INFO, etc. , GRASS is unusable.

Now, if I run the OSGeo4W installer and get 6.4.0svn, these
problems do not appear.

  
  

the error message is from lib/gis/get_window.c when G_fopen_old()
fails.

  

Which means that the WIND or DEFAULT_WIND are not being set up right.

  
(works for me)
  

What I did to double check the problem was to temporarily rename
.grassrc to something else, then try to start WinGRASS. With no
.grassrc it begins the setup grass database and location routine, and
then, after I choose an epsg code for the CRS, I get the failure.

Cheers,
Micha

  

Hamish

  



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

Re: [GRASS-user] Native WinGRASS 6.4 RC5 g.proj failure

I think I came across the same problem of the g.proj
the commond "g.proj -c georef=d:\swilAlphaTIFF.tif location=tset" works well
in grass6.3 get some warning in grass6.4 6.4 RC5 :

(Wed Jun 17 18:27:31
2009)
g.proj -c georef=d:\swilAlphaTIFF.tif
location=tset
Trying to open with OGR...
Trying to open with GDAL...
...succeeded.
ERROR: 要得到当前地图集未设置的范围
请运行 "g.region"




2009/6/17 Hamish 

>
> Micha wrote:
> > I installed GRASS on WinXP using the
> > setup file of the new version of WinGRASS from:
> > http://grass.osgeo.org/grass64/binary/mswindows/native/
> >
> > When starting GRASS, as long as I point to an existing
> > GRASS GISDBASE it works fine. But if I try to set up a new
> > GISDBASE, new location and mapset (based on epsg codes) the
> > "location wizard" fails, popping up an error window (as in
> > the attached image).
>
> this doesn't diminish the bug any, but what's wrong with two locations
> in the same GISDBASE?
>
>
> > This bug is something of a show-stopper since without a
> > properly defined location GRASS will not start. Even if I
> > start GRASS with the command line and try to run g.proj -c
> > or g.setproj they also fail. So without jumping thru some
> > tricky hoops, editting PROJ_INFO, etc. , GRASS is unusable.
> >
> > Now, if I run the OSGeo4W installer and get 6.4.0svn, these
> > problems do not appear.
>
>
> the error message is from lib/gis/get_window.c when G_fopen_old()
> fails.
>
>
> (works for me)
>
>
> Hamish
>
>
>
>
>
> ___
> 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] Native WinGRASS 6.4 RC5 g.proj failure


Micha wrote:
> I installed GRASS on WinXP using the
> setup file of the new version of WinGRASS from: 
> http://grass.osgeo.org/grass64/binary/mswindows/native/
> 
> When starting GRASS, as long as I point to an existing
> GRASS GISDBASE it works fine. But if I try to set up a new
> GISDBASE, new location and mapset (based on epsg codes) the
> "location wizard" fails, popping up an error window (as in
> the attached image).

this doesn't diminish the bug any, but what's wrong with two locations
in the same GISDBASE?


> This bug is something of a show-stopper since without a
> properly defined location GRASS will not start. Even if I
> start GRASS with the command line and try to run g.proj -c
> or g.setproj they also fail. So without jumping thru some
> tricky hoops, editting PROJ_INFO, etc. , GRASS is unusable.
> 
> Now, if I run the OSGeo4W installer and get 6.4.0svn, these
> problems do not appear.


the error message is from lib/gis/get_window.c when G_fopen_old()
fails.


(works for me)


Hamish



  

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

Re: [GRASS-user] r.proj..."has stopped working"


Richard Feldman wrote:
> (Tue Jun 16 11:09:28 2009) 
> r.proj in=elevation.dem location=spearfish60 mapset=PERMANENT 
> out=elevation.dem
> (Tue Jun 16 11:09:31 2009) Command finished (3 sec)


I tried using the latest 6.4.0rc5 wingrass installer and that worked
fine for me on XP.

First I had to run g.region rast/vect= and v.in.region in the source
mapset, then exit & restart to the target mapset and run v.proj to pull
in the region box, 'g.region vect=region_box', then 'g.region res= -p'
to slightly improve on the original resolution (I just 1"), then finally
pull in raster map with r.proj.


I also discovered that concurrent GRASS sessions in WinGrass is a major
don't-go.


valgrind found memory allocation bugs, output copied below. probably this
is another bug which UNIX doesn't mind but Windows chokes on, like r.los
and r.sim.water.

==5480== ERROR SUMMARY: 521 errors from 6 contexts (suppressed: 107 from 1)



(this should go into a bug report)

Hamish


G65> CMD="r.proj in=elevation.dem loc=spearfish60 map=PERMANENT"
G65> valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o
==5480== Memcheck, a memory error detector.
==5480== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5480== Using LibVEX rev 1658, a library for dynamic binary translation.
==5480== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5480== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==5480== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5480== For more details, rerun with: -v
==5480== 
Input Projection Parameters:  +proj=utm +zone=13 +a=6378206.4 +rf=294.9786982 
+no_defs 
+nadgrids=/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/etc/nad/conus
Input Unit Factor: 1
Output Projection Parameters:  +proj=longlat +no_defs +a=6378137 
+rf=298.257223563 +towgs84=0.000,0.000,0.000
Output Unit Factor: 1

Input:
Cols: 633 (633)
Rows: 466 (466)
North: 4928000.00 (4928000.00)
South: 4914020.00 (4914020.00)
West: 590010.00 (590010.00)
East: 609000.00 (609000.00)
EW-res: 30.00
NS-res: 30.00

Output:
Cols: 868 (901)
Rows: 452 (452)
North: 44.500278 (44.500278)
South: 44.374722 (44.374722)
West: -103.870556 (-103.875556)
East: -103.629444 (-103.625278)
EW-res: 0.000278
NS-res: 0.000278

Allocating memory and reading input map...
==5480== Syscall param write(buf) points to uninitialised byte(s)
==5480==at 0x4000792: (within /lib/ld-2.3.6.so)
==5480==by 0x804BF58: main (main.c:391)
==5480==  Address 0x6366A0C is 2,532 bytes inside a block of size 163,840 
alloc'd
==5480==at 0x401D38B: malloc (vg_replace_malloc.c:149)
==5480==by 0x4037B8D: G__malloc (alloc.c:41)
==5480==by 0x804C7D7: readcell (readcell.c:68)
==5480==by 0x804BF58: main (main.c:391)
 100%
Projecting...
 100%
==5480== 
==5480== Invalid read of size 4
==5480==at 0x4010DE9: (within /lib/ld-2.3.6.so)
==5480==by 0x4004B78: (within /lib/ld-2.3.6.so)
==5480==by 0x4006792: (within /lib/ld-2.3.6.so)
==5480==by 0x479246F: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5480==by 0x4791EDE: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x47946FC: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5480==by 0x479475D: __libc_dlopen_mode (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x476E7CF: __nss_lookup_function (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x476E8BF: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x47704E5: __nss_passwd_lookup (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==  Address 0x6364354 is 36 bytes inside a block of size 38 alloc'd
==5480==at 0x401D38B: malloc (vg_replace_malloc.c:149)
==5480==by 0x4006B83: (within /lib/ld-2.3.6.so)
==5480==by 0x479246F: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5480==by 0x4791EDE: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x47946FC: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5480==by 0x479475D: __libc_dlopen_mode (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x476E7CF: __nss_lookup_function (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x476E8BF: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x47704E5: __nss_passwd_lookup (in 
/lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x471EB6E: getpwuid_r (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5480== 
==5480== Conditional jump or move depends on uninitialised value(s)
==5480==at 0x4008ED5: (within /lib/ld-2.3.6.so)
==5480==by 0x47928C4: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (within /lib/ld-2.3.6.so)
==5480==by 0x4791EDE: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x47946FC: (within /lib/tls/i686/cmov/libc-2.3.6.so)
==5480==by 0x400B44E: (

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)

Yes
My tiff have 5 color, red blue green and pink and yellow. I want get the
area for each color..
First I import the tiff .however I got a.green a.red a.blue and a.alpha four
raster.

2009/6/17 Micha Silver 

> maven apache wrote:
>
> can the grass calculate the area of different color for a image?
>> I have a tiff, and I have seen five color in it,I wonder I can calculate
>> the area for each color with grass?
>>
> Did you check out r.stats -a ?
>
>
>> This mail was received via Mail-SeCure System.
>> 
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>>
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: [GRASS-dev] New WinGrass Release (6.4.0RC5)


Martin wrote:
> the last time I ended up in the hell of mixing libraries built using
> mingw (GRASS) and msvs (wxpython). Currently I have no time for this
> kind of "fun". If somebody put on wiki instructions how to overcome
> this problem I will be happy to fix MS Windows related bugs to make
> these extensions working under MS Windows.

have you tried the updated & simplified build instructions using osgeo4w
as the framework?

https://trac.osgeo.org/grass/wiki/CompileOnWindows

then hopefully it is mostly a matter of making sure the PATH order is
correct. (??)


Hamish



  

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

Re: [GRASS-user] Problem exporing rasters


after importing try setting the computation bounds with e.g.
  g.region rast=studyarea


raster mapcalc and output work on the current region settings.


Hamish




--- On Wed, 6/17/09, Milton Cezar Ribeiro  wrote:

> From: Milton Cezar Ribeiro 
> Subject: Re: [GRASS-user] Problem exporing rasters
> To: "Richard Feldman" 
> Cc: "grass-user@lists.osgeo.org" 
> Date: Wednesday, June 17, 2009, 1:27 AM
> Hi Richard,
>  
> Send the outputs of the command below to the
> list:
>  
> g.region -p
> r.info studyarea
> r.info elevation
> r.info newelevation
>  
> This will help the helpers :-)
>  
> Bests,
>  
> milton
> brazil=toronto
>  
> 2009/6/16 Richard Feldman 
> 
> Hi,
> 
> I have two rasters. One is an elevation dataset from
> Worldclim, imported into GRASS using r.in.bin. The other is
> a MODIS raster, which I had previously worked on in ArcGIS.
> Consequently, I imported this raster (.adf) into GRASS using
> r.in.gdal. Both rasters display and manipulate properly in
> GRASS. I used r.mapcalc to mask the raster
> 
> 
> newelevation=if(studya...@mapset, elevat...@mapset)
> 
> and wished to export this new raster as an ascii grid. When
> using either r.out.gdal or r.out.arc, the exported file is
> only 1KB and does not contain any data e.g. elevations).
> (Again, this new raster displays fine in GRASS). With
> r.out.gdal, I have tried both .grd and .tif formats as well
> as “byte,” “int16,” “uint16” and “int32”
> file types. Every time the export takes 0 sec and produces a
> 1-2KB file.
> 
> 
> I have tried exporting elevation.dem from the spearfish
> dataset and it exports fine. I'm using GRASS6-SVN on
> Windows Vista.
> 
> What am I doing wrong?
> 
> 
> Richard
> Feldman___
> 
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> 
> 
> -Inline Attachment Follows-
> 
> ___
> 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] v.delaunay Bug in Mac OS X


works ok in Linux + latest grass 6.5svn, both 32 and 64bit.

but Valgrind does find an error:

G65> CMD="v.delaunay input=DelaunayPoints output=DelaunayTriangles"
G65> valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o
==7844== Memcheck, a memory error detector.
==7844== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7844== Using LibVEX rev 1854, a library for dynamic binary translation.
==7844== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7844== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation 
framework.
==7844== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7844== For more details, rerun with: -v
==7844== 
WARNING: Vector map  already exists and will be
 overwritten
==7844== Syscall param write(buf) points to uninitialised byte(s)
==7844==at 0x71C09F0: write (in /lib/libc-2.7.so)
==7844==by 0x716E909: _IO_file_write (in /lib/libc-2.7.so)
==7844==by 0x716E569: (within /lib/libc-2.7.so)
==7844==by 0x716E8A4: _IO_do_write (in /lib/libc-2.7.so)
==7844==by 0x7170256: _IO_switch_to_get_mode (in /lib/libc-2.7.so)
==7844==by 0x716ED8F: _IO_file_seekoff (in /lib/libc-2.7.so)
==7844==by 0x7164049: ftell (in /lib/libc-2.7.so)
==7844==by 0x5D455FD: dig_ftell (file.c:41)
==7844==by 0x5D4600F: dig__write_head (head.c:56)
==7844==by 0x4E5AC9C: V1_open_new_nat (open_nat.c:127)
==7844==by 0x4E5A155: Vect_open_new (open.c:565)
==7844==by 0x403B0D: main (main.c:106)
==7844==  Address 0x4022009 is not stack'd, malloc'd or (recently) free'd
Building topology for vector map ...
Registering primitives...
15 primitives registered
30 vertices registered
Building areas...
 100%
8 areas built
1 isles built
Number of nodes: 8
Number of primitives: 15
Number of points: 0
Number of lines: 0
Number of boundaries: 15
Number of centroids: 0
Number of areas: 8
Number of isles: 1
Number of areas without centroid: 8
 100%
Building topology for vector map ...
Attaching islands...
 100%
Attaching centroids...
 100%
Number of nodes: 16
Number of primitives: 23
Number of points: 0
Number of lines: 0
Number of boundaries: 15
Number of centroids: 8
Number of areas: 8
Number of isles: 1
==7844== 
==7844== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 2)
==7844== malloc/free: in use at exit: 140,294 bytes in 304 blocks.
==7844== malloc/free: 541 allocs, 237 frees, 236,013 bytes allocated.
==7844== For counts of detected errors, rerun with: -v
==7844== searching for pointers to 304 not-freed blocks.
==7844== checked 2,836,336 bytes.
==7844== 
==7844== 
==7844== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in 
loss record 1 of 13
==7844==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844==by 0x71DD52F: (within /lib/libc-2.7.so)
==7844==by 0x71DDD06: __nss_database_lookup (in /lib/libc-2.7.so)
==7844==by 0xF1F031F: ???
==7844==by 0xF1F102C: ???
==7844==by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844==by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844==by 0x52D6537: G_whoami (whoami.c:70)
==7844==by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844==by 0x4E592BE: Vect__open_old (open.c:145)
==7844==by 0x4E59D8E: Vect_open_old (open.c:415)
==7844==by 0x403AAB: main (main.c:96)
==7844== 
==7844== 
==7844== 80 bytes in 5 blocks are indirectly lost in loss record 2 of 13
==7844==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844==by 0x71DD119: __nss_lookup_function (in /lib/libc-2.7.so)
==7844==by 0xF1F033A: ???
==7844==by 0xF1F102C: ???
==7844==by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844==by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844==by 0x52D6537: G_whoami (whoami.c:70)
==7844==by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844==by 0x4E592BE: Vect__open_old (open.c:145)
==7844==by 0x4E59D8E: Vect_open_old (open.c:415)
==7844==by 0x403AAB: main (main.c:96)
==7844== 
==7844== 
==7844== 160 bytes in 5 blocks are indirectly lost in loss record 3 of 13
==7844==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844==by 0x71CCEC3: tsearch (in /lib/libc-2.7.so)
==7844==by 0x71DD0B9: __nss_lookup_function (in /lib/libc-2.7.so)
==7844==by 0xF1F033A: ???
==7844==by 0xF1F102C: ???
==7844==by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844==by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844==by 0x52D6537: G_whoami (whoami.c:70)
==7844==by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844==by 0x4E592BE: Vect__open_old (open.c:145)
==7844==by 0x4E59D8E: Vect_open_old (open.c:415)
==7844==by 0x403AAB: main (main.c:96)
==7844== 
==7844== 
==7844== 320 bytes in 10 blocks are still reachable in loss record 4 of 13
==7844==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844==by 0x4E523DB: Vect__new_line_struct (line.c:69)
==7844==by 0x4E523A0: Vect_new_line_struct (line.c:59)
==7844==by 0x403A48: ma

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)


maven apache wrote:


can the grass calculate the area of different color for a image?
I have a tiff, and I have seen five color in it,I wonder I can 
calculate the area for each color with grass?

Did you check out r.stats -a ?



This mail was received via Mail-SeCure System.


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

This mail was received via Mail-SeCure System.


  


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

Re: [GRASS-user] v.delaunay Bug in Mac OS X

William wrote:
> I don't see any changes in v.delaunay
> itself from RC4, though maybe there are changes in the
> vector libraries.  Did this work in RC4?

Note since Nov 26 2008 (ie all 6.4.0RCs) v.delaunay has been completely
replaced by v.delaunay2 which was a Google summer of code project last
year. It shares the same name and options but is an entirely new program
on the inside.

was the working version 6.3.0? (ie old version of the module)

Hamish

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

[GRASS-user] Re: GIS Manager map properties (wxpython)

2009-06-17 Thread Tim Michelsen

> > Are the GUI program files byte-compiled into *.pyc files
> > during install?
> 
> not sure what happens in the installer, but if not that should happen
> automatically the first time you run it, assuming you have write
> permissions in the install directory.
> 
> fwiw using the rc5 native wingrass installer I seem to have only .py
> files in $GISBASE/etc/wxpython/, but do see .pyc in
$GISBASE/etc/wxpython/gui_modules and $GISBASE/python.
> 
> (and as you might expect wxgui.py is slow to start)
Below is a script used by PythonXY for opimazation.
Maybe of interest for GRASS, too.

I do not have any further experience with optimazation on windows.
But it happens also on linux that the dialogs take time to pop-up.

For instance calling g.region on CML.

I guess there is happening something inside the wrapper...

(2x1.8Ghz, RAM> 2MB).

BTW, taking about the perfomance of a program shows that the 
design has reached a 
fairly stable state... These are minor improvements.
First, we need to be happy to have it.

Regards,
Timmie


 from PythonXY

# -*- coding: latin-1 -*-
#
#Copyright © 2008 Pierre Raybaut
#
#This program is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#GNU General Public License for more details.
#
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

from PyQt4.QtGui import QApplication, QMessageBox, QFileDialog, QIcon
import os.path as osp
import time, sys, os
from xy.xyutils import getreg

REGXY = getreg()
LIBPATH = osp.join(REGXY['Python'],'Lib')

def optimize(path):
assert osp.exists(path) and osp.isdir(path)
batfile = 'optimize_temp.bat'
f=open(batfile,'w')
f.write('python -O "%s\compileall.py" "%s"' % (LIBPATH,path) )
f.close()
os.startfile(batfile)
time.sleep(3)
os.remove(batfile)

def main():
app = QApplication(sys.argv)
app.setWindowIcon(QIcon(osp.dirname(__file__)+'/img/pyc.png'))
directory = QFileDialog.getExistingDirectory(None,"Select directory to
optimize",osp.join(LIBPATH,'site-packages'))
if not directory.isEmpty() and QMessageBox.question(None, "Optimize",
   "Do you really want to compile all .py
files to .pyo in the following directory?"+"\n\n"+directory,
   QMessageBox.Yes, QMessageBox.No) ==
QMessageBox.Yes:
optimize(directory)

if __name__ == "__main__":
if len(sys.argv)>1:
optimize(sys.argv[1])
else:
main()


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

Re: [GRASS-user] Re: GIS Manager map properties (wxpython)

Tim wrote:
> Are the GUI program files byte-compiled into *.pyc files
> during install?

not sure what happens in the installer, but if not that should happen
automatically the first time you run it, assuming you have write
permissions in the install directory.

fwiw using the rc5 native wingrass installer I seem to have only .py
files in $GISBASE/etc/wxpython/, but do see .pyc in 
$GISBASE/etc/wxpython/gui_modules and $GISBASE/python.

(and as you might expect wxgui.py is slow to start)

???

> I also wanna add that the new GUI is just marvelous and
> makes a lot more fun to use.

three cheers for Martin, Michael, Glynn & the rest on a wonderful job.

Hamish

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

Re: [GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)


maven apache < wrote:
> can the grass calculate the area
> of different color for a image?
> I have a tiff, and I have seen five color in it,I
> wonder I can calculate the area for each color with
> grass?

try r.stats -a, r.report


Hamish



  

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

[GRASS-user] can the grass calculate the area of different color for a image(tiff or other?)