Re: [GRASS-user] Landsat classification workflow

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/

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

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

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

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)pa

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

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 g

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

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 whe

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

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

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

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

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, 2

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:

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

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:\o

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 t

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

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 :-)

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

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-

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

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

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

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

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

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.

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

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

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 debu

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

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

[GRASS-user] Landsat classification workflow

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.or

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

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 scri

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

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

[GRASS-user] i.atcorr for thermal band

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

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

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 i

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

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 applicati

Re: [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 th

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

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.

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

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