Hello all
first I'd like to make a few suggestions to enhance (IMO) our favorite GIS:
- normalize the options in all modules. I noticed that while most
commands take "--overwrite", some (r.neighbors) use "-o"
- some modules require a dummy value when output a list (r.mask,
r.proj, v.proj..). Is this really necessary? this is a very confusing
option (specially for newbies).
- also, I think that _all_ fields (gui speaking now) where a
raster/vector map is to be entered should have the select button, no
matter if it is a field for new maps, because it makes the whole thing
consistent, and it is easier for new users to understant how things
work.
now some issues:
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
this is just out of curiosity:
if there are too many points to be used for interpolation by RST, how
does it chooses which points will be used?
thats all for now,
cheers
Carlos
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Can't stop the signal.
On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
Hello all
first I'd like to make a few suggestions to enhance (IMO) our favorite GIS:
- normalize the options in all modules. I noticed that while most
commands take "--overwrite", some (r.neighbors) use "-o"
+1
- some modules require a dummy value when output a list (r.mask,
r.proj, v.proj..). Is this really necessary? this is a very confusing
option (specially for newbies).
+1
- also, I think that _all_ fields (gui speaking now) where a
raster/vector map is to be entered should have the select button
...especially for r.proj, v.proj where it is necessary to type (or even
go and copy from somewhere in order to paste) the database path
I am always here for complains... 
, no
matter if it is a field for new maps, because it makes the whole thing
consistent, and it is easier for new users to understant how things
work.
now some issues:
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
this is just out of curiosity:
if there are too many points to be used for interpolation by RST, how
does it chooses which points will be used?
thats all for now,
cheers
Carlos
Cheers,
Nikos
On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
Hello all
[...]
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
Probably not! Just tested... and it says: Lat/Long location is not
supported
Maybe check the PhD thesis:
www.soi.city.ac.uk/~jwo/phd/
Nikos Alexandris pisze:
On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
Hello all
[...]
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
it is imposible due to polinominal fitting when window is more than 3
Probably not! Just tested... and it says: Lat/Long location is not
supported
Maybe check the PhD thesis:
www.soi.city.ac.uk/~jwo/phd/
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Carlos "Guâno" Grohmann schrieb:
Hello all
first I'd like to make a few suggestions to enhance (IMO) our favorite GIS:
- normalize the options in all modules. I noticed that while most
commands take "--overwrite", some (r.neighbors) use "-o"
I guess the problem is, that there are to many modules an it my be a lot of work to change them. Also "old" users are used to take the right option for the particular module. Another problem. Where to start? Some users have vers 6.2.3 others 6.3 svn others 6.3 rc5. If you change the manuals in the wiki all will be confused a little more, first of all the newbies. And finally there are also some parameters to be normalized. i.e most times you have >output< for output. but sometimes >out< or >elev< or >elevation<. So where to start and who will do?
- some modules require a dummy value when output a list (r.mask,
r.proj, v.proj..). Is this really necessary? this is a very confusing
option (specially for newbies).
- also, I think that _all_ fields (gui speaking now) where a
raster/vector map is to be entered should have the select button, no
matter if it is a field for new maps, because it makes the whole thing
consistent, and it is easier for new users to understant how things
work.
now some issues:
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
this is just out of curiosity:
if there are too many points to be used for interpolation by RST, how
does it chooses which points will be used?
Not sure.... some ideas: Try to set another region (g.region), use a mask_map (raster) or use the where-parameter (v.surf.rst or v.extract)
thats all for now,
cheers
Carlos
Hi,
2008/3/4, Carlos Guâno Grohmann <carlos.grohmann@gmail.com>:
first I'd like to make a few suggestions to enhance (IMO) our favorite GIS:
- normalize the options in all modules. I noticed that while most
commands take "--overwrite", some (r.neighbors) use "-o"
todo for grass7 development, renaming/removing module parameters
cannot be done in grass6 because of backward compatability.
- some modules require a dummy value when output a list (r.mask,
r.proj, v.proj..). Is this really necessary? this is a very confusing
option (specially for newbies).
Please collect all wishes on wiki [1] or better report in trac, e.g. [2].
- also, I think that _all_ fields (gui speaking now) where a
raster/vector map is to be entered should have the select button, no
matter if it is a field for new maps, because it makes the whole thing
consistent, and it is easier for new users to understant how things
work.
are you talking about tcl/tk or wxpython GUI?
Martin
now some issues:
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
this is just out of curiosity:
if there are too many points to be used for interpolation by RST, how
does it chooses which points will be used?
[1] http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection
[2] http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=7.0.0
thats all for now,
cheers
Carlos
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Can't stop the signal.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Monday 03 March 2008, Jarosław Jasiewicz wrote:
Nikos Alexandris pisze:
> On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
>> Hello all
>
> [...]
>
>> is plan curvature in r.param.scale broken? I can't get a map of it.
>> profc works fine. Also is it possible to make r.param.scale work in
>> latlong regions? (please?)
it is imposible due to polinominal fitting when window is more than 3
This may reveal my level of understanding of the r.param.scale module, but why
should the profile curvature be impossible to calculate when the window size
is > 3x3 ?
Thanks
Dylan
> Probably not! Just tested... and it says: Lat/Long location is not
> supported
>
> Maybe check the PhD thesis:
> www.soi.city.ac.uk/~jwo/phd/
>
>
> _______________________________________________
> 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
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Tue, Mar 4, 2008 at 3:51 AM, Jarosław Jasiewicz <jarekj@amu.edu.pl> wrote:
>
>> is plan curvature in r.param.scale broken? I can't get a map of it.
>> profc works fine. Also is it possible to make r.param.scale work in
>> latlong regions? (please?)
>>
it is imposible due to polinominal fitting when window is more than 3
What do you say that is impossible? Using Wood's approach in LatLong
regions or using a window larger that 3x3?
The module's _intention_ is to provide multi-scale analysis, by means
of different window sizes.
Carlos
--
+-----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke
Can't stop the signal.
Dylan Beaudette wrote:
On Monday 03 March 2008, Jarosław Jasiewicz wrote:
Nikos Alexandris pisze:
On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
Hello all
[...]
is plan curvature in r.param.scale broken? I can't get a map of it.
profc works fine. Also is it possible to make r.param.scale work in
latlong regions? (please?)
it is imposible due to polinominal fitting when window is more than 3
This may reveal my level of understanding of the r.param.scale module, but why should the profile curvature be impossible to calculate when the window size is > 3x3 ?
Thanks
Dylan
Probably not! Just tested... and it says: Lat/Long location is not
supported
Maybe check the PhD thesis:
www.soi.city.ac.uk/~jwo/phd/
_______________________________________________
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
I analised the code of (I need that solution for some other problem). The module use polinominal fitting to calculate is written to work on rectangular grid, so program shoud be compeeltly rewriten to use lat-long. As far as I know - r.param scale is now development as Landserf maybe try this but I cant say if landserf can work on lat-long (I suppose - yes)
On Wednesday 05 March 2008, Jarek Jasiewicz wrote:
Dylan Beaudette wrote:
> On Monday 03 March 2008, Jarosław Jasiewicz wrote:
>> Nikos Alexandris pisze:
>>> On Mon, 2008-03-03 at 22:52 -0300, Carlos "Guâno" Grohmann wrote:
>>>> Hello all
>>>
>>> [...]
>>>
>>>> is plan curvature in r.param.scale broken? I can't get a map of it.
>>>> profc works fine. Also is it possible to make r.param.scale work in
>>>> latlong regions? (please?)
>>
>> it is imposible due to polinominal fitting when window is more than 3
>
> This may reveal my level of understanding of the r.param.scale module,
> but why should the profile curvature be impossible to calculate when the
> window size is > 3x3 ?
>
> Thanks
>
> Dylan
>
>>> Probably not! Just tested... and it says: Lat/Long location is not
>>> supported
>>>
>>> Maybe check the PhD thesis:
>>> www.soi.city.ac.uk/~jwo/phd/
>>>
>>>
>>> _______________________________________________
>>> 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
I analised the code of (I need that solution for some other problem).
The module use polinominal fitting to calculate is written to work on
rectangular grid, so program shoud be compeeltly rewriten to use
lat-long. As far as I know - r.param scale is now development as
Landserf maybe try this but I cant say if landserf can work on lat-long
(I suppose - yes)
Ah- OK. It looks like the problem is with the fitting of polynomials in LL
locations, and NT the > 3x3 grid / plan curv. problem-- that must be related
to a bug.
I don't see a ticket for r.param.scale on the trac site.
Carlos- can you please create one with any example you might have?
Thanks,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341