I am trying to make use of this amazing tool but whenever I "save" &
"exit" & "d.rast" my new raster it looks like the old one!
Is there a secret setting?
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Nikos Alexandris wrote:
I am trying to make use of this amazing tool but whenever I "save" &
"exit" & "d.rast" my new raster it looks like the old one!Is there a secret setting?
No. You are looking at the new map (output=), not the original
(input=), right? If you're trying to edit a map "in place" (i.e. input
and output are the same map), I don't think that's been tested.
Are there any error messages or warnings displayed in the terminal?
--
Glynn Clements <glynn@gclements.plus.com>
No errors!
Hmmm... ! I though that it works as follows (and did):
1. Open a raster and give a name for the new raster (open a raster with
areas, all having the same value "5")
2. edit, save, exit (I "erased lots of pixels from various areas by
assigning the * -- that is NULL, no?)
3. load the NEW raster and see the changes (I load the NEW raster and it
is identical with the old map)
Is it the * values? Effects take place with non-NULL values maybe?
On Thu, 2008-02-21 at 08:02 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> I am trying to make use of this amazing tool but whenever I "save" &
> "exit" & "d.rast" my new raster it looks like the old one!
>
> Is there a secret setting?No. You are looking at the new map (output=), not the original
(input=), right? If you're trying to edit a map "in place" (i.e. input
and output are the same map), I don't think that's been tested.Are there any error messages or warnings displayed in the terminal?
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Ohhhh! I got it!
It's the "*" I am using. With the value "66" for example it worked!
But why not with "*". It's a perfect tool if one needs to manually
correct some details.
And why not having a magic "key" with which one can "fly" over pixels
with the mouse pointer and assign new values instead of "countless
clicks".
I know many occasions were this is necessary to be done and there is no
fastest and more precise method than just doing it by hand.
Cheers 
On Thu, 2008-02-21 at 12:14 +0100, Nikos Alexandris wrote:
No errors!
Hmmm... ! I though that it works as follows (and did):
1. Open a raster and give a name for the new raster (open a raster with
areas, all having the same value "5")2. edit, save, exit (I "erased lots of pixels from various areas by
assigning the * -- that is NULL, no?)3. load the NEW raster and see the changes (I load the NEW raster and it
is identical with the old map)Is it the * values? Effects take place with non-NULL values maybe?
On Thu, 2008-02-21 at 08:02 +0000, Glynn Clements wrote:
> Nikos Alexandris wrote:
>
> > I am trying to make use of this amazing tool but whenever I "save" &
> > "exit" & "d.rast" my new raster it looks like the old one!
> >
> > Is there a secret setting?
>
> No. You are looking at the new map (output=), not the original
> (input=), right? If you're trying to edit a map "in place" (i.e. input
> and output are the same map), I don't think that's been tested.
>
> Are there any error messages or warnings displayed in the terminal?
>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Nikos Alexandris wrote:
Hmmm... ! I though that it works as follows (and did):
1. Open a raster and give a name for the new raster (open a raster with
areas, all having the same value "5")2. edit, save, exit (I "erased lots of pixels from various areas by
assigning the * -- that is NULL, no?)3. load the NEW raster and see the changes (I load the NEW raster and it
is identical with the old map)Is it the * values? Effects take place with non-NULL values maybe?
Ah. I have just realised that d.rast.edit won't allow you to set cells
to null.
The problem is this:
d.rast.edit only works on a portion of the map (an editing window with
100,000 cells would consume vast amounts of memory and be
impractically slow). When you save the map, or switch to a different
portion, it imports the edited portion into grass as a separate map
(using r.in.ascii), and merges it with rest of the map using r.patch.
However, this only replaces non-null cells. Any null cells result in
the corresponding cells in the orignal map remaining untouched.
I could fix d.rast.edit to use r.mapcalc instead of r.patch. But it
might be better to add an option to r.patch to support this type of
usage.
In the meantime, the only solution I can offer is to use a cell value
which doesn't occur in the map being edited in place of the null
value, then use r.null to change that value to null once editing is
complete.
--
Glynn Clements <glynn@gclements.plus.com>
On Fri, 2008-02-22 at 02:32 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> Hmmm... ! I though that it works as follows (and did):
>
> 1. Open a raster and give a name for the new raster (open a raster with
> areas, all having the same value "5")
>
> 2. edit, save, exit (I "erased lots of pixels from various areas by
> assigning the * -- that is NULL, no?)
>
> 3. load the NEW raster and see the changes (I load the NEW raster and it
> is identical with the old map)
>
>
> Is it the * values? Effects take place with non-NULL values maybe?Ah. I have just realised that d.rast.edit won't allow you to set cells
to null.The problem is this:
d.rast.edit only works on a portion of the map (an editing window with
100,000 cells would consume vast amounts of memory and be
impractically slow). When you save the map, or switch to a different
portion, it imports the edited portion into grass as a separate map
(using r.in.ascii), and merges it with rest of the map using r.patch.
Thanks for the details.
However, this only replaces non-null cells. Any null cells result in
the corresponding cells in the orignal map remaining untouched.I could fix d.rast.edit to use r.mapcalc instead of r.patch. But it
might be better to add an option to r.patch to support this type of
usage.
Would be nice to have that.
And another question: Is it possible to ad something else besides an
Aspect map? Use maybe transparencyt and a background command (like with
r.digit)? What are the limitations?
In the meantime, the only solution I can offer is to use a cell value
which doesn't occur in the map being edited in place of the null
value, then use r.null to change that value to null once editing is
complete.
Yep, that's what I did
I have specific codes (corresponding to land cover classes) so I used a
"strange" number and used r.null.
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Nikos Alexandris wrote:
> However, this only replaces non-null cells. Any null cells result in
> the corresponding cells in the orignal map remaining untouched.
>
> I could fix d.rast.edit to use r.mapcalc instead of r.patch. But it
> might be better to add an option to r.patch to support this type of
> usage.Would be nice to have that.
And another question: Is it possible to ad something else besides an
Aspect map? Use maybe transparencyt and a background command (like with
r.digit)? What are the limitations?
I'm not sure how a background map could work; it would be obscured by
the map being edited.
The aspect map feature was only added because it was present in the
original d.rast.edit module which the script replaces. I have no idea
what purpose it serves.
--
Glynn Clements <glynn@gclements.plus.com>
It makes (some) sense for me. I was and still am doing a lot of visual
interpretation (currently upon MODIS imagery).
I need to collect samples for i.smap for example and with MODIS (MOD09,
250m pix.res) this task is a challenge. And I am not only digitising
samples from the scratch, but I use also some classes (e.g. Urban) from
valid existing land cover maps. Yet, I need to correct the borders for
some of these Urban areas.
From this perspective all kinds of "ancillary" data are useful. Aspect
helped me to identify some flat areas in agricultural zones (it is
expected that flat areas have "one" common aspect... no?). It would be
even more useful if DEM values (pure numbers) could be visualized (like
"add cell values layer") or any kind of values from a thematic map.
Sure there other ways to support that... but I still think that the best
way to get the highest accuracy for land cover mapping is not the
"automatic" way. It's necessary to get involved!
This is why I like the "link" option in OpenEV (FWTools), the "cell
value layer", the "directional arrows layer".
Thank you Glynn,
Nikos
On Fri, 2008-02-22 at 09:07 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> > However, this only replaces non-null cells. Any null cells result in
> > the corresponding cells in the orignal map remaining untouched.
> >
> > I could fix d.rast.edit to use r.mapcalc instead of r.patch. But it
> > might be better to add an option to r.patch to support this type of
> > usage.
>
> Would be nice to have that.
>
> And another question: Is it possible to ad something else besides an
> Aspect map? Use maybe transparencyt and a background command (like with
> r.digit)? What are the limitations?I'm not sure how a background map could work; it would be obscured by
the map being edited.The aspect map feature was only added because it was present in the
original d.rast.edit module which the script replaces. I have no idea
what purpose it serves.
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Nikos Alexandris wrote:
And why not having a magic "key" with which one can "fly" over pixels
with the mouse pointer and assign new values instead of "countless
clicks".
FWIW I find the old xmon & terminal based d.rast.edit's 3 button
click-workflow to be incredibly well thought out and implemented. It
has a nice compromise of speed, simplicity, and caution which has a
natural feel to it. The need for an undo button is not as great if you
have a same-button confirmation click. Having to do a pseudo double
click doesn't slow you down much, and the mid-click higlight gives your
brain a chance to reconsider/redo.
The annoying thing with the old version is that you can't add a value
outside of that map's range, but that relic has nothing to do with the
workflow design.
Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
I just now realised the use of the "right mouse button". But I am not
able to figure out how the "middle" button works. How does it work? I
take back my words for the "magic" key if this "highlight" function is
working
Cheers,
Nikos
On Fri, 2008-02-22 at 04:41 -0800, Hamish wrote:
Nikos Alexandris wrote:
> And why not having a magic "key" with which one can "fly" over pixels
> with the mouse pointer and assign new values instead of "countless
> clicks".FWIW I find the old xmon & terminal based d.rast.edit's 3 button
click-workflow to be incredibly well thought out and implemented. It
has a nice compromise of speed, simplicity, and caution which has a
natural feel to it. The need for an undo button is not as great if you
have a same-button confirmation click. Having to do a pseudo double
click doesn't slow you down much, and the mid-click higlight gives your
brain a chance to reconsider/redo.The annoying thing with the old version is that you can't add a value
outside of that map's range, but that relic has nothing to do with the
workflow design.Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
Nikos Alexandris wrote:
> > And another question: Is it possible to ad something else besides an
> > Aspect map? Use maybe transparencyt and a background command (like with
> > r.digit)? What are the limitations?
>
> I'm not sure how a background map could work; it would be obscured by
> the map being edited.
>
> The aspect map feature was only added because it was present in the
> original d.rast.edit module which the script replaces. I have no idea
> what purpose it serves.It makes (some) sense for me. I was and still am doing a lot of visual
interpretation (currently upon MODIS imagery).I need to collect samples for i.smap for example and with MODIS (MOD09,
250m pix.res) this task is a challenge. And I am not only digitising
samples from the scratch, but I use also some classes (e.g. Urban) from
valid existing land cover maps. Yet, I need to correct the borders for
some of these Urban areas.From this perspective all kinds of "ancillary" data are useful.
I'm not doubting the utility of a background map, I'm just not sure
how it would be implemented.
Aspect
helped me to identify some flat areas in agricultural zones (it is
expected that flat areas have "one" common aspect... no?).
It depends what you mean by "flat". A common aspect implies zero
curvature rather than zero gradient. Exactly horizontal areas have an
undefined aspect (the direction of steepest slope isn't meaningful if
there is no slope). Areas which are roughly horizontal tend to have
essentially random aspect.
It would be
even more useful if DEM values (pure numbers) could be visualized (like
"add cell values layer") or any kind of values from a thematic map.
It would be easy enough to add additional information, e.g. numbers. I
suppose that editing a map displayed as numbers over a background
of filled rectangles would be feasible, as would the converse.
But if the both the foreground and background consist of filled
rectangles, you are only going to be able see one of them.
--
Glynn Clements <glynn@gclements.plus.com>
Very informative mail
On Sat, 2008-02-23 at 02:42 +0000, Glynn Clements wrote:
Nikos Alexandris wrote:
> > > And another question: Is it possible to ad something else besides an
> > > Aspect map? Use maybe transparencyt and a background command (like with
> > > r.digit)? What are the limitations?
> >
> > I'm not sure how a background map could work; it would be obscured by
> > the map being edited.
> >
> > The aspect map feature was only added because it was present in the
> > original d.rast.edit module which the script replaces. I have no idea
> > what purpose it serves.
>
> It makes (some) sense for me. I was and still am doing a lot of visual
> interpretation (currently upon MODIS imagery).
>
> I need to collect samples for i.smap for example and with MODIS (MOD09,
> 250m pix.res) this task is a challenge. And I am not only digitising
> samples from the scratch, but I use also some classes (e.g. Urban) from
> valid existing land cover maps. Yet, I need to correct the borders for
> some of these Urban areas.
>
> From this perspective all kinds of "ancillary" data are useful.I'm not doubting the utility of a background map, I'm just not sure
how it would be implemented.
Sorry for my "brilliant ideas"... I have no clue how this could be done.
> Aspect
> helped me to identify some flat areas in agricultural zones (it is
> expected that flat areas have "one" common aspect... no?).It depends what you mean by "flat". A common aspect implies zero
curvature rather than zero gradient. Exactly horizontal areas have an
undefined aspect (the direction of steepest slope isn't meaningful if
there is no slope). Areas which are roughly horizontal tend to have
essentially random aspect.
Hmmm, I see... - depends also on the resolution of the data. Have to be
more careful.
> It would be
> even more useful if DEM values (pure numbers) could be visualized (like
> "add cell values layer") or any kind of values from a thematic map.It would be easy enough to add additional information, e.g. numbers. I
suppose that editing a map displayed as numbers over a background
of filled rectangles would be feasible, as would the converse.But if the both the foreground and background consist of filled
rectangles, you are only going to be able see one of them.
Yep, it's going to be overfilled.
This is why I got stuck with the "linking of two map displays function".
I wish I could program... I would start right away creating this
tool 
--
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel. +49 (0) 761 203 3697 / Fax. +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany