[GRASS-user] wishlist to add a grass module for Landsat ETM+ SLC-off Gapfill

[maning sambale]

Landsat ETM+ SLC-off Gapfill
http://l7gapfill.sourceforge.net/

L7gapfill uses a multi-scale segment model to guide interpolation of
spectral data across gaps in Landsat 7 SLC-off images. Gap pixels are
filled with concurrent spectral data, essential for applications that
require same-day spectral information.

Would be nice to add to the expanding grass LANDSAT modules
-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.out.ogr to KML ERROR 1: Latitude is invalide

[maven apache]

2009/6/22 Micha Silver 

> maven apache wrote:
>
>
>>
>>
>> I did have five vector layer each of which have only one
>> categories,Actually I got the five vector from the commond
>> "v.extract..";
>> Normally you would use d.vect.thematic if you have 5 categories
>>in *one* vector map. Then setting i.e. column=cat would color each
>>different cat value a different color.
>>
>> Where is the generated thematic map,in the display?
>>
> Maybe this will help:
> I have a vector layer "fields". I ran these two commands (after setting the
> region):
>
> # Display fields with different colors based on area
> d.vect.thematic map=fields column=HECTARES color=red-blue


"You must open a display monitor"
I meet this error message when do the commond "d.vect.thecmatic", by the
serach enginee I found this topic has mentioned in the grass-dev mailist,but
I have not found the final way to solve the problem/


>
> # Add a label with the area for each field
> d.vect map=fields display=attr type=centroid attrcol=HECTARES lsize=10
> lcolor=black
>
> And the result is the attached image. The d.vect.thematic broke the fields
> into 4 categories based on size (two larger fields have the same color). I
> could have changed the number of intervals with the nint option.
>
> Cheers,
> Micha
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wishlist to add a grass module for Landsat ETM+ SLC-off Gapfill

[Nikos Alexandris]

maning sambale:
> Landsat ETM+ SLC-off Gapfill
> http://l7gapfill.sourceforge.net/
> 
> L7gapfill uses a multi-scale segment model to guide interpolation of
> spectral data across gaps in Landsat 7 SLC-off images. Gap pixels are
> filled with concurrent spectral data, essential for applications that
> require same-day spectral information.
> 
> Would be nice to add to the expanding grass LANDSAT modules

+1, Nikos

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

Re: [GRASS-user] wishlist to add a grass module for Landsat ETM+ SLC-off Gapfill

[Hamish]

maning sambale wrote:
> Landsat ETM+ SLC-off Gapfill
> http://l7gapfill.sourceforge.net/
> 
> L7gapfill uses a multi-scale segment model to guide interpolation of
> spectral data across gaps in Landsat 7 SLC-off images. Gap pixels are
> filled with concurrent spectral data, essential for applications that
> require same-day spectral information.
> 
> Would be nice to add to the expanding grass LANDSAT modules

feel free to file an enhancement ticket in the trac system with as much detail 
as possible.


see also  http://grass.osgeo.org/wiki/MODIS#Removing_holes


Hamish



  

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

Re: [GRASS-user] can't compile swig python on grass 7: shared no found

[G. Allegri]

Ok, the update solved every error.

thx,
giovanni

2009/6/22 Glynn Clements :
>
> G. Allegri wrote:
>
>> > Python modules are linked using $(CXX); I'm guessing this is empty,
>> > probably due to --with-cxx not being used.
>>
>> Ok, I've added --with-cxx.
>> Now I get the following:
>>
>> In file included from proj_wrap.c:2694:
>> /home/giova/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/gprojects.h:23:29:
>> error: ogr_srs_api.h: Nessun file o directory
>
> Are you using the most recent version of the GRASS source code? I
> believe this has been fixed within the last couple of days.
>
> Also, you should use e.g.
>
>        LC_ALL=C make
>
> if you intend to post error messages to the list.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] i.atcorr for thermal band

[Luca Casagrande]

Hello folks.
Is there a particular reason for the fact that in the module i.atcorr there
is no reference to the Landsat Thermal band for Sensor band input ?

Thank you 
Luca
-- 
View this message in context: 
http://n2.nabble.com/i.atcorr-for-thermal-band-tp3132304p3132304.html
Sent from the Grass - Users mailing list archive at Nabble.com.

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

Re: [GRASS-user] v.lidar.edgedetection very slow

[Hamish]

Michael P wrote:
> I'm running Mac OS X + SQLite with a 64 bit version of
> grass. I ran a whole bunch of tests today and it looks like
> there are at least a couple of things going on and SQLite is
> one of the issues. I ran a 500m x500m tile with three
> different DB back-ends (SQLite, Postgres and DBF) and these
> are the results I obtained;
> (SQLite)
> time v.lidar.edgedetection input=Cal_QTile
> output=Cal_QTile_edges
> real38m53.458s
> user1m17.602s
> sys4m6.353s
> 
> (Postgres)
> time v.lidar.edgedetection input=Cal_QTile
> output=Cal_QTile_edges
> real6m49.060s
> user0m46.622s
> sys1m20.324s
> 
> (DBF)
> time v.lidar.edgedetection input=Cal_QTile
> output=Cal_QTile_edges
> real1m54.065s
> user0m48.530s
> sys1m8.686s
> 
> The results with Postgres and SQLite were a real surprise
> to me.

I am surprised that all DBs spend so much time in "sys" kernel
land. (a good guess there is the time is spent on I/O with disk
controller)  I knew that linux's IO was cleaner than OSX's,
but I didn't know the margin was that much ...

I just ran a test in 64bit linux got the following:

DBF:
real32m14.192s
user32m6.880s
sys 0m5.884s

Sqlite:
real39m45.760s
user34m25.357s
sys 0m23.225s

I would note that the number of passes it takes to complete
varies between ~ 9 and 20 for my test data depending on
settings, and that affects the time to complete hugely.
(1 pass per subregion, but it skips some number of no-points
subregions)

By watching "top" and gkrellm monitor* I can see that the drop
down to single digit processor use for sqlite happens in the
"Point classification" step, and gkrellm shows that during this
time the disk write is about 22mb/sec, so lets say it is limited
by writing to the disk. After it finishes the point class. step
it jumps back up to 100% for the next pass's interpolations.
(dominated by Tcholetsky decomposition function) Also subsequent
passes often seem to have many fewer points to classify, so
are faster to complete that stage.

[*] something similar to gkrellm can be found in the system
monitor app in the OSX Apps/Utility folder


So DBF is faster to write down a zillion new records to disk.
not all that surprising seeing that it has so little overhead
to worry about.


Hamish:
> > if you build from the latest grass 6.5 or 7 svn you
> > can use the --verbose flag to follow the action. setting
> > 'g.gisenv set="DEBUG=1" gives you even more detail (even
> > with existing versions).
> 
> Does this print out the debugging messages that are in the
> code

yes, you just need to switch them on and then you can see what's
happening. already present in all 6.4.0 RC versions.
set it back to "0" to turn debug messages off again.


> or do I need to do something else to see those?

in the devel versions (6.5 and 7) I've moved the milepost
debug messages into verbose messages, so you just need to
add --verbose to the command line to see them. percent complete
too. It's a lot cleaner than the debug messages, but you need to
recompile from source to get this.



Hamish



  

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

Re: [GRASS-user] Ratioing and pan-sharpening

[Hamish]

Knut Arne Bjørndal wrote:
> I tried i.fusion.brovey, and sharpened bands 3, 4 and 5 and
> then tried ratioing based on that but the output was very different
> (in a worse way) than the normal NDVI.

> Oh, and is it possible to pan-sharpen band 6 data too?

i.fusion.brovey is just a shell script, you can edit it in a text editor
and tweak it to read whatever channel you want. also you can extract
the algorithm from it and run on your own. (see formula in the help page)

doesn't really answer your question, but maybe it helps give you an idea.


Hamish





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

[GRASS-user] Landsat classification workflow

[Koen Hufkens]

Hi list,

I'm looking for a tutorial on classifying landsat images with GRASS.

I can't seem to find anything on the web. Some pointers would be nice.

Kind regards,
Koen Hufkens
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.lidar.edgedetection very slow

[Markus GRASS]

Michael Perdue wrote:
>
>
> I read through the one of the papers today  ( M. A. Brovelli , M.
> Cannata and U. M. Longoni, 2002.  Managing and processing LIDAR data
> within GRASS,  Proceedings of the  / Open source GIS - GRASS users
> conference 2002)  and the authors recommended a step value or 3 to 4
> time the average point spacing of the data set. So 4m sen & see values
> seems appropriate for a data set that has an average coverage of 1
> return/m^2. Unfortunately, the authors didn't really explain why it
> should be 3-4 times and not say 10. I can only guess that a smaller
> step size would produce finer details in the interpolation and better
> feature isolation for the classification./
>
> There definitely seems to be something funky going on between the
> spline step size and the division of the region into subregion. I ran
> tests using v.lidar.edgedetection on tiles of 500x500m, 800x800m ,
> 801x801m and 1000x1000m. Times for each run
> were 1m54.065s, 6m35.420s, 22m16.708s & 68m25.265s respectively. There
> was a ~3 fold increase in processing time when I grew the data set by
> 1m from  (800m)^2 (what I understand to be the maximum size of the
> region before it is broken up into subregions) to (801m)^2 and
> it tripled again when I jumped to (1000m)^2. I also recompiled grass
> with NSPLX_MAX and NSPLY_MAX set to 1500 instead of the current 200
> and the time to process a (1000m)^2 tile dropped from 68 minutes to 12
> minutes.
>
> My understanding is that a region is broken up into smaller subregions
> to avoid memory limitations while processing. I can't see any reason
> why the division of the region into more smaller subregions should
> increase the resolution of those subregions. I'm far from an expert on
> these programs, and I'm not skilled enough to read through the code
> and know what it is doing, but if I understand you correctly, your
> arguments make sense to me. If you're kind enough to share your
> changes I'll apply them and do some more testing.
I didn't get to look into that in more detail, stopped at
edgedetection.c without getting a working solution. The general idea is
either to use the current geographic region resolution or to use point
density for estimated resolution, then use sen and see as step size. I
can not possibly say if that makes sense, I have to read the references,
but will not get to it soon. How about contacting the original authors?

Markus M

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

Thanks for the info.  I didn't know about the assoc and ftype.  Looking at the 
output of these two commands, I see that my system is set up correctly.  

So, I still don't know why the grass.parser() is not working for me.  I even 
modified my program to use pdb to see what is happening.  The debugger is 
aborted right after I reach os.execvp("g.parser.exe", [name] + argv) in 
grass.py.  But if I use "python 
c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help", I get the 
expected results.

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the 
individual or entity to which it is addressed. This message contains 
information from the State of California, California Geological Survey, which 
may be privileged, confidential and exempt from disclosure under applicable 
law, including the Electronic Communications Privacy Act. If the reader of this 
communication is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited.



> -Original Message-
> From: Glynn Clements [mailto:gl...@gclements.plus.com]
> Sent: Friday, June 19, 2009 7:03 PM
> To: Moskovitz, Bob
> Cc: Grass-User (E-mail)
> Subject: Re: [GRASS-user] Problems with GRASS python code in osgeo4w
> 
> 
> 
> Moskovitz, Bob wrote:
> 
> > I'm trying to figure out how to write python scripts using grass.py
> > under osgeo4w.  I was hoping that python script (and the binary
> > commands) would behave similarly to the grass environment 
> on my Ubuntu
> > box.  You know...just type the command and the gui for that command
> > comes up.  What I have to do now is type "python
> > c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py" 
> instead of
> > just type "m.dipslope.py".  I've also notice that the command gui or
> > even the command help does not come up when you just enter 
> the command.
> > Ultimately I would like to put my commands in the QGIS GRASS module
> > tree.
> 
> 1. Ensure that .py files are configured to be run with the Python
> interpreter. You should be able to double-click on a .py file in
> Explorer and have it run. This should be done by the Python installer,
> but I don't know if the OSGeo4W installer does this.
> 
> If it isn't, you can use e.g.:
> 
>   assoc .py=python.file
>   ftype python.file="C:\Program Files\Python25\python.exe" "%1"
> 
> [Change the pathname to wherever Python is installed.]
> 
> 2. The PATHEXT environment variable needs to contain ".PY" if you want
> to use "m.dispslope" rather than "m.dispslope.py". You can do this
> temporarily with:
> 
>   set PATHEXT=%PATHEXT%;.PY
> 
> or you can make it persistent either using the Control Panel or
> through the registry.
> 
> For the Control Panel in XP, it's:
> 
> My Computer
>  Control Panel
>   System
>Advanced (Tab)
> Environment Variables
> 
> For the registry, the system-wide setting is taken from the PATHEXT
> value of the key:
> 
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
> 
> Or you can override it for the current user by adding a PATHEXT value
> to the key HKCU\Environment
> 
> -- 
> Glynn Clements 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Hamish]

Bob Moskovitz wrote:
> So, I still don't know why the grass.parser() is not
> working for me.  I even modified my program to use pdb
> to see what is happening.  The debugger is aborted
> right after I reach os.execvp("g.parser.exe", [name] + argv)
> in grass.py.  But if I use "python
> c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help",
> I get the expected results.


try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in your %PATH%.
when g.parser is complete it reruns the script but only by its filename.
If the script isn't in the PATH* it fails at that point because it
can't find it. The above seems like it should be in the path.. do other
"official" scripts in that directory work?

[*] (the current dir is typically also checked in MS Windows although it
typically is not in UNIX)

see also GRASS_ADDONS_PATH enviro variable.

for grass 7 Glynn may have just changed this a couple of days ago??



Hamish



  

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

I see that c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts is already in the PATH 
and "v.report --help" gives me the command usage.  

I do notice that there is no prompting of options or gui forms when I execute 
any grass command without arguments.  I've noticed this behavior on several 
machines.

> -Original Message-
> From: Hamish [mailto:hamis...@yahoo.com]
> Sent: Monday, June 22, 2009 10:42 AM
> To: Glynn Clements; Moskovitz, Bob
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
> 
> 
> 
> Bob Moskovitz wrote:
> > So, I still don't know why the grass.parser() is not
> > working for me.  I even modified my program to use pdb
> > to see what is happening.  The debugger is aborted
> > right after I reach os.execvp("g.parser.exe", [name] + argv)
> > in grass.py.  But if I use "python
> > c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help",
> > I get the expected results.
> 
> 
> try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in 
> your %PATH%.
> when g.parser is complete it reruns the script but only by 
> its filename.
> If the script isn't in the PATH* it fails at that point because it
> can't find it. The above seems like it should be in the 
> path.. do other
> "official" scripts in that directory work?
> 
> [*] (the current dir is typically also checked in MS Windows 
> although it
> typically is not in UNIX)
> 
> see also GRASS_ADDONS_PATH enviro variable.
> 
> for grass 7 Glynn may have just changed this a couple of days ago??
> 
> 
> 
> Hamish
> 
> 
> 
>   
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] "g.region -cd" creates an unusable WIND file instead of printing error messages

[Nikos Alexandris]

Can anybody confirm that running the (irrational to me) command
"g.region -cd" creates an (almost empty) unusable WIND file? Is this a
bug that should be reported?


# issue irrational command
g.region -cd

# verify broken WIND file
g.region -p

ERROR: region for current mapset is invalid
   
   run "g.region"


# attempt to restore region fails, e.g.
g.region rast=StudyArea -pa

ERROR: region for current mapset is invalid
   
   run "g.region"


Kind regards, Nikos
---

Details

While testing *.region.* qgis-grass tools I saw that in r.region.region
one can select both "Set from current region" and "Set from default
region". Before writing down my comments about this I wanted to ensure
that this is also NOT possible (or rational) to use in grass itself. A
report with respect *.region.* qgis-grass tools will follow in a few
days.

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

[GRASS-user] Re: "g.region -cd" creates an unusable WIND file instead of printing error messages

[Nikos Alexandris]

On Mon, 2009-06-22 at 21:40 +0300, Nikos Alexandris wrote:
> Can anybody confirm that running the (irrational to me) command
> "g.region -cd" creates an (almost empty) unusable WIND file? Is this a
> bug that should be reported?

Probably my "default" region is empty which in turn results in an
(almost) empty WIND file! Not sure... :-?

g.region -d "breaks" the WIND file.

Anyhow, I also confused g.region with r.region. The issue with
r.region.region (a qgis-grass tool) issue will be reported in the
respective QGIS locations. Sorry for the traffic.

Nikos

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

Re: [GRASS-user] Re: "g.region -cd" creates an unusable WIND file instead of printing error messages

[Hamish]

Nikos wrote:
> g.region -d "breaks" the WIND file.

fixed in svn, but not in time for 6.4.0rc5.

https://trac.osgeo.org/grass/ticket/654


if you have a broken DEFAULT_WIND file you will need to remove/
replace it manually.


Hamish



  

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

Re: [GRASS-user] Re: "g.region -cd" creates an unusable WIND file instead of printing error messages

[Nikos Alexandris]

Nikos:
> > g.region -d "breaks" the WIND file.

Hamish:
> fixed in svn, but not in time for 6.4.0rc5 
> 
> if you have a broken DEFAULT_WIND file you will need to remove/replace it 
> manually.

Alright - Thanks :-)

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Glynn Clements]

Moskovitz, Bob wrote:

> Thanks for the info.  I didn't know about the assoc and ftype.  Looking
> at the output of these two commands, I see that my system is set up
> correctly.  
> 
> So, I still don't know why the grass.parser() is not working for me.  I
> even modified my program to use pdb to see what is happening.  The
> debugger is aborted right after I reach os.execvp("g.parser.exe", [name]
> + argv) in grass.py.  But if I use "python
> c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help", I
> get the expected results.

Does it work if you run the script using its full path, i.e.:

 c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

?

You could try modifying etc/python/grass/script/core.py to print the
arguments which are passed to g.parser.

The code attempts to determine the script's full pathname, as g.parser
needs this so that it can open the script to read the #% comments
(PATH won't help here).

It appears that this part is where the problem lies. If the script is
run with --help or --ui, g.parser doesn't get around to re-invoking
the script, so that isn't an issue.

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Glynn Clements]

Hamish wrote:

> > So, I still don't know why the grass.parser() is not
> > working for me.  I even modified my program to use pdb
> > to see what is happening.  The debugger is aborted
> > right after I reach os.execvp("g.parser.exe", [name] + argv)
> > in grass.py.  But if I use "python
> > c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help",
> > I get the expected results.
> 
> 
> try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in your %PATH%.
> when g.parser is complete it reruns the script but only by its filename.

g.parser uses the filename passed as argv[1]. This needs to be the
complete path to the script, so that g.parser can fopen() it and read
the #% comments; PATH won't help here.

Unix shells normally have the full pathname as $0 (the kernel sees the
#!/bin/sh line and invokes /bin/sh with the full path to the script).
On Windows, shell scripts are invoked via windows_launch.bat, which
invokes the script by its full path.

The Python parser() function attempts to construct an absolute path,
but I don't know if this is working; it doesn't look like it. The
--help option is handled without re-invoking the script; if that
doesn't work, it suggests that g.parser cannot fopen() the script.

> If the script isn't in the PATH* it fails at that point because it
> can't find it. The above seems like it should be in the path.. do other
> "official" scripts in that directory work?
> 
> [*] (the current dir is typically also checked in MS Windows although it
> typically is not in UNIX)
> 
> see also GRASS_ADDONS_PATH enviro variable.
> 
> for grass 7 Glynn may have just changed this a couple of days ago??

I have, but it won't make any difference in this case.

FWIW, the changes involve adding a -s switch. When used, g.parser
doesn't re-invoke the script; it simply writes all of the flag and
option settings to stdout. The Python parser() interface then parses
this output.

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

There is no etc/python/grass/script/core.py.  Just etc\python\grass.py.  Here 
is a part of a pdb debug session:

> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()
-> if sys.platform == "win32":
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
-> try:
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) p [name] + argv
['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py', 'c:\\osgeo
4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
(Pdb)

> -Original Message-
> From: Glynn Clements [mailto:gl...@gclements.plus.com]
> Sent: Monday, June 22, 2009 3:30 PM
> To: Moskovitz, Bob
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
> 
> 
> 
> Moskovitz, Bob wrote:
> 
> > Thanks for the info.  I didn't know about the assoc and 
> ftype.  Looking
> > at the output of these two commands, I see that my system is set up
> > correctly.  
> > 
> > So, I still don't know why the grass.parser() is not 
> working for me.  I
> > even modified my program to use pdb to see what is happening.  The
> > debugger is aborted right after I reach 
> os.execvp("g.parser.exe", [name]
> > + argv) in grass.py.  But if I use "python
> > c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py 
> --help", I
> > get the expected results.
> 
> Does it work if you run the script using its full path, i.e.:
> 
>  c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help
> 
> ?
> 
> You could try modifying etc/python/grass/script/core.py to print the
> arguments which are passed to g.parser.
> 
> The code attempts to determine the script's full pathname, as g.parser
> needs this so that it can open the script to read the #% comments
> (PATH won't help here).
> 
> It appears that this part is where the problem lies. If the script is
> run with --help or --ui, g.parser doesn't get around to re-invoking
> the script, so that isn't an issue.
> 
> -- 
> Glynn Clements 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

I also wanted to add that I did run the program like this:  
c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

> -Original Message-
> From: grass-user-boun...@lists.osgeo.org
> [mailto:grass-user-boun...@lists.osgeo.org]on Behalf Of Moskovitz, Bob
> Sent: Monday, June 22, 2009 4:07 PM
> To: Glynn Clements
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
> 
> 
> There is no etc/python/grass/script/core.py.  Just 
> etc\python\grass.py.  Here is a part of a pdb debug session:
> 
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()
> -> if sys.platform == "win32":
> (Pdb)
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
> -> try:
> (Pdb)
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) p [name] + argv
> ['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslop
> e.py', 'c:\\osgeo
> 4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
> (Pdb)
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

I debugged a bit deeper with pdb and found this:
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) s
 snip ===
> c:\warmerda\release\apps\python25\lib\os.py(389)_execvpe()
-> func(fullname, *argrest)
(Pdb) p fullname
'c:\\osgeo4w\\bin\\g.parser.exe'
(Pdb) PATH
['c:\\osgeo4w\\bin', 'C:\\OSGeo4W/apps/grass/grass-6.4.0svn\\bin', 'C:\\OSGeo4W/
apps/grass/grass-6.4.0svn\\lib', 'C:\\OSGeo4W\\bin', 'C:\\Perl\\bin\\', 'C:\\WIN
DOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem', 'C:\\Perl\\bin\\'
,'C:\\WINDOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem']

There is no c:\osgeo4w\bin\g.parser.exe but there is a 
C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\g.parser.exe.

> -Original Message-
> From: Moskovitz, Bob 
> Sent: Monday, June 22, 2009 4:17 PM
> To: Moskovitz, Bob; Glynn Clements
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
> 
> 
> I also wanted to add that I did run the program like this:  
> c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help
> 
> > -Original Message-
> > From: grass-user-boun...@lists.osgeo.org
> > [mailto:grass-user-boun...@lists.osgeo.org]on Behalf Of 
> Moskovitz, Bob
> > Sent: Monday, June 22, 2009 4:07 PM
> > To: Glynn Clements
> > Cc: Grass-User (E-mail)
> > Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
> > 
> > 
> > There is no etc/python/grass/script/core.py.  Just 
> > etc\python\grass.py.  Here is a part of a pdb debug session:
> > 
> > > 
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()
> > -> if sys.platform == "win32":
> > (Pdb)
> > > 
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
> > -> try:
> > (Pdb)
> > > 
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> > -> os.execvp("g.parser.exe", [name] + argv)
> > (Pdb) p [name] + argv
> > ['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslop
> > e.py', 'c:\\osgeo
> > 4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
> > (Pdb)
> > 
> > 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Compiling the weekly source (configure bug?)

[Seth Price]

Hey all, I'm interested in making some changes to the GRASS core so I'm
trying to work with the latest source package. However, I'm having a hard
time getting it to install. It says it's unable to locate my FreeType
includes. I think that there's bug in the configure where someone forgot
to include "-I/usr/local/include/freetype2"

Thoughts on the problem and/or how to get this configured? Here's my
Terminal's text and a bunch of relevant info:
$ ./configure --enable-shared --prefix=/Applications --enable-macosx-app
--with-opengl=aqua && make && sudo make install
checking host system type... i386-apple-darwin9.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
[... snip ...]
checking for cairo_xlib_surface_create_with_xrender_format... yes
checking for cairo_xlib_surface_get_xrender_format... yes
checking whether to use FreeType... yes
checking for location of FreeType includes...
checking for ft2build.h... no
configure: error: *** Unable to locate FreeType includes.
$ freetype-config
Usage: freetype-config [OPTION]...
Get FreeType compilation and linking information.

Options:
  --prefix   display `--prefix' value used for building the
 FreeType library
  --prefix=PREFIXoverride `--prefix' value with PREFIX
  --exec-prefix  display `--exec-prefix' value used for building
 the FreeType library
  --exec-prefix=EPREFIX  override `--exec-prefix' value with EPREFIX
  --version  display libtool version of the FreeType library
  --ftversiondisplay FreeType version number
  --libs display flags for linking with the FreeType library
  --libtool  display library name for linking with libtool
  --cflags   display flags for compiling with the FreeType
 library
$ tail -n 20 config.log
configure:13590: checking for cairo.h
configure:13598: gcc -E -I/usr/local/include/cairo
-I/usr/local/include/pixman-1 -I/usr/local/include/freetype2
-I/usr/local/include -I/usr/local/include/libpng12 -I/usr/X11/include   
conftest.c >/dev/null 2>conftest.out
configure:13634: checking for location of cairo library
configure:13654: checking for cairo linking flags
configure:13670: checking for cairo_create
configure:13696: gcc -o conftest -g -O2   conftest.c  -L/usr/local/lib
-L/usr/X11/lib -lfreetype -lfontconfig -lXrender -lSM -lICE -lX11 -lcairo 
   1>&5
configure:13730: checking for cairo_xlib_surface_create_with_xrender_format
configure:13756: gcc -o conftest -g -O2   conftest.c  -L/usr/local/lib
-L/usr/X11/lib -lfreetype -lfontconfig -lXrender -lSM -lICE -lX11 -lcairo 
   1>&5
configure:13789: checking for cairo_xlib_surface_get_xrender_format
configure:13815: gcc -o conftest -g -O2   conftest.c  -L/usr/local/lib
-L/usr/X11/lib -lfreetype -lfontconfig -lXrender -lSM -lICE -lX11 -lcairo 
   1>&5
configure:13857: checking whether to use FreeType
configure:13876: checking for location of FreeType includes
configure:13902: checking for ft2build.h
configure:13910: gcc -E   conftest.c >/dev/null 2>conftest.out
In file included from configure:13906:
/usr/local/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No
such file or directory
configure: failed program was:
#line 13905 "configure"
#include "confdefs.h"
#include 
$ locate ftheader.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/freetype2/freetype/config/ftheader.h
/Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/freetype2/freetype/config/ftheader.h
/usr/X11/include/freetype2/freetype/config/ftheader.h
/usr/local/freetype/freetype-2.3.9/include/freetype/config/ftheader.h
/usr/local/include/freetype2/freetype/config/ftheader.h
$



Thanks,
Seth

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

Re: [GRASS-user] Compiling the weekly source (configure bug?)

[Glynn Clements]

Seth Price wrote:

> Hey all, I'm interested in making some changes to the GRASS core so I'm
> trying to work with the latest source package. However, I'm having a hard
> time getting it to install. It says it's unable to locate my FreeType
> includes. I think that there's bug in the configure where someone forgot
> to include "-I/usr/local/include/freetype2"
> 
> Thoughts on the problem and/or how to get this configured? Here's my
> Terminal's text and a bunch of relevant info:
> $ ./configure --enable-shared --prefix=/Applications --enable-macosx-app
> --with-opengl=aqua && make && sudo make install

It looks like you need --with-freetype-includes=/usr/local/include/freetype2

The configure script (intentionally) won't attempt to figure this out
for itself.

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

Re: [GRASS-user] Compiling the weekly source (configure bug?)

[Hamish]

Seth Price wrote:
> Hey all, I'm interested in making some changes to the GRASS
> core so I'm trying to work with the latest source package.
> However, I'm having a hard time getting it to install. It says
> it's unable to locate my FreeType includes.

> Thoughts on the problem and/or how to get this configured?

> checking whether to use FreeType... yes
> checking for location of FreeType includes...
> checking for ft2build.h... no
> configure: error: *** Unable to locate FreeType includes.

> $ freetype-config
> Usage: freetype-config [OPTION]...

what does "freetype-config --cflags" say?


> $ tail -n 20 config.log

> /usr/local/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No 
> such file or directory

does that file exist on your computer? where is it?

did you set
 ./configure --with-freetype \
   --with-freetype-includes=/usr/include/freetype2

or similar to point where that directory is?


Hamish



  

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

RE: [GRASS-user] Problems with GRASS python code in osgeo4w

[Glynn Clements]

Moskovitz, Bob wrote:

> There is no etc/python/grass/script/core.py. Just
> etc\python\grass.py.

That changed in the last month or so, but I don't think that it has
any bearing on this.

> Here is a part of a pdb debug session:
> 
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()

I don't like the look of the "grass-~1.0sv" bit.

> -> if sys.platform == "win32":
> (Pdb)
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
> -> try:
> (Pdb)
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) p [name] + argv
> ['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py', 
> 'c:\\osgeo
> 4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
> (Pdb)

That much looks okay.

> I debugged a bit deeper with pdb and found this:
> (Pdb)
> > c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) s
>  snip ===
> > c:\warmerda\release\apps\python25\lib\os.py(389)_execvpe()
> -> func(fullname, *argrest)
> (Pdb) p fullname
> 'c:\\osgeo4w\\bin\\g.parser.exe'
> (Pdb) PATH
> ['c:\\osgeo4w\\bin', 'C:\\OSGeo4W/apps/grass/grass-6.4.0svn\\bin', 
> 'C:\\OSGeo4W/
> apps/grass/grass-6.4.0svn\\lib', 'C:\\OSGeo4W\\bin', 'C:\\Perl\\bin\\', 
> 'C:\\WIN
> DOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem', 
> 'C:\\Perl\\bin\\'
> ,'C:\\WINDOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem']
> 
> There is no c:\osgeo4w\bin\g.parser.exe but there is a 
> C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\g.parser.exe.

This is a red herring. os.execvp() iterates through PATH, attempting
each directory in turn until it succeeds.

However, the fact that the GRASS bin and lib directories have forward
slashes might be a problem. Try correcting PATH from the command line
first.

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

Re: [GRASS-user] Compiling the weekly source (configure bug?)

[Hamish]

Glynn wrote:
> It looks like you need
> --with-freetype-includes=/usr/local/include/freetype2
> 
> The configure script (intentionally) won't attempt to
> figure this out for itself.

now that `freetype-config --cflags` is widespread, maybe we should
take advantage of that, if present.


Hamish



  

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

Re: [GRASS-user] Landsat classification workflow

[Hamish]

Koen Hufkens wrote:
> I'm looking for a tutorial on classifying landsat images
> with GRASS.

try  http://grass.osgeo.org/wiki/Imagery#Image_classification


Hamish



  

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