Re: [GRASS-dev] Re: [GRASS-SVN] r34694 - grass-addons/vector/v.profile

[Hamish]

Maris Nartiss wrote:
> I hope to move v.profile into main GRASS module list after
> 6.4 release.

why not put it into trunk (7.0svn) now?


Hamish



  

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

Re: [GRASS-dev] Re: new version of lib/linkm (linked list memory manager)

[Glynn Clements]

Rosen Matev wrote:

> > We probably don't need (or want) to free individual chunks as they
> > become empty; they can be retained for future allocations. We just
> > need to free everything in link_dispose().
> 
> We don't actually free allocated fixed-sized blocks. However, we need
> to mark when a block is empty (ready to be "allocated" again).

In that case, it's probably easier to just keep blocks permanently
allocated. Free nodes live on a global free list, from where new nodes
are allocated. When the free list is empty, a new block is allocated
and its nodes are immediately placed on the free list.

If it wasn't for link_dispose(), you wouldn't even need to keep any
details of the actual blocks.

> > OTOH, I don't even know if we really need *any* of this. Certainly,
> > the code in lib/Vlib/poly.c could quite easily just use a realloc()ed
> > array, with link pointers being replaced by array indices.
> 
> Let's assume that every time we call realloc() we double the size of
> the array. If we need to allocate N elements, then we will make
> log2(N) calls to realloc(). Moreover, in worst case scenario, the
> realloc()s would have made a total of 2N element copies. We increase
> the constant in the complexity of the algorithm, but my linkm also
> increases it (probably even more).
> Note: the results worsen if we don't use the "double the size of the
> array" rule. For example adding a constant number of elements in every
> realloc() is very bad asymptotically.

Ultimately, the time complexity is still only O(n), and anything which
processes the resulting polygon will be at least O(n), and probably
with a much larger constant.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compilation errors under MinGW

[Glynn Clements]

Rosen Matev wrote:

> There are a few errors that popped out when I tried to compile MinGW.
> As far as I can see only trunk is faulty. I solved the problem by
> updating the problematic files from an older revision. Here is the
> summary:
> 
> COMPILATION ERRORS //in mingw environment
> (revision 34688)
> 
> /trunk/lib/gis
> locale.c:33: error: `LC_MESSAGES' undeclared (first use in this function)
> // the problem is in locale.h bundled with mingw
> // probably not GRASS' issue but I'm not sure

Okay. LC_MESSAGES is POSIX, not ANSI C. I'll conditionalise that upon
"#ifdef LC_MESSAGES" and move it into the "#if ... defined(USE_NLS)"
part. It isn't meaningful if you aren't building with NLS enabled.

> mach_name.c:34:6: #if with no expression
> // the #elif at #34 should be #else

Okay.

> popen.c:55: error: `popen_pid' undeclared (first use in this function)
> // what's the best way to fix this?

With:

G_fatal_error("G_popen() not implemented on Windows")

That code was broken in the first place. Previously, it would compile
but wouldn't work:

1. popen_pid[f] wasn't being set in the MinGW version of G_popen(),
but more significantly ...

2. The MinGW version of G_popen() uses execl(), which effectively
terminates the calling process. It should use _spawnl(_P_NOWAIT).

3. It creates the pipe, but doesn't make the child process use it as
its stdin/stdout. AFAIK, the only way to do this with _spawnl() (or
similar CRT functions) is for the caller to _dup2() its own
stdin/stdout, call _spawnl(), then restore the original descriptor. 
See lib/db/dbmi_client/start.c.

> spawn.c: In function `G_spawn':

Ugh; I forgot to do the MinGW cases when I updated this.

> The fix should be straightforward. I can't commit to trunk so I'm
> letting you know for these.

Can you test r34695?

> Please elaborate on the first error. I fixed it by adding a line
> "#define LC_MESSAGES 6" in locale.h, which pretty lame.

The setlocale() in MSVCRT doesn't understand LC_MESSAGES, so the call
needs to be disabled there. I don't know how gettext handles this on
Windows.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] flip raster

[Glynn Clements]

[CC'd to grass-dev.]

beakins wrote:

> One question that I have: "Is there another file format for the ETOPO1 grids
> that would be of more use to the GRASS community than netcdf?" We could host
> something such as geotiffs of the grids, which we can create easily, but I'm
> not a GRASS user so don't know what grid/raster file format would be easiest
> to import into GRASS. I've also never used QGIS.
> 
> Any ideas or suggestions would be much appreciated.

GRASS' preferred raster format is anything which GDAL supports, and
for which GetGeoTransform() succeeds, with the adfTransform[] array
satisfying the constraints:

adfTransform[1] > 0
adfTransform[2] == 0
adfTransform[4] == 0
adfTransform[5] < 0

[Currently, r.in.gdal/r.external don't bother to check
adfTransform[1]; if it's negative, GRASS may import it okay, but then
refuse to read it.]

IOW, north-to-south, west-to-east, no rotation or shear. If the data
uses a different orientation, GDAL needs to be able to transform it
itself. It isn't a major problem if the georeferencing data isn't
readily available, but a different orientation is (at present).

Ultimately, we could make some changes to support flipped (but not
rotated) rasters, but the format would ideally need to be such that
there isn't a penalty for reading data north-to-south, i.e. any
south-to-north data would need to be in a format which supports
non-sequential access (seeking).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #90: v.parallel: problems with inside corners

[GRASS GIS]

#90: v.parallel: problems with inside corners
--+-
  Reporter:  hamish   |   Owner:  rmatev 
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  unspecified
Resolution:   |Keywords: 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Changes (by hamish):

 * cc: grass-dev@lists.osgeo.org (added)

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: new version of lib/linkm (linked list memory manager)

[Rosen Matev]

Hi,

Here is my two-month-delay answer (sorry, very busy at school).

> We probably don't need (or want) to free individual chunks as they
> become empty; they can be retained for future allocations. We just
> need to free everything in link_dispose().

We don't actually free allocated fixed-sized blocks. However, we need
to mark when a block is empty (ready to be "allocated" again).

> OTOH, I don't even know if we really need *any* of this. Certainly,
> the code in lib/Vlib/poly.c could quite easily just use a realloc()ed
> array, with link pointers being replaced by array indices.

Let's assume that every time we call realloc() we double the size of
the array. If we need to allocate N elements, then we will make
log2(N) calls to realloc(). Moreover, in worst case scenario, the
realloc()s would have made a total of 2N element copies. We increase
the constant in the complexity of the algorithm, but my linkm also
increases it (probably even more).
Note: the results worsen if we don't use the "double the size of the
array" rule. For example adding a constant number of elements in every
realloc() is very bad asymptotically.
Having said that, I couldn't agree more to you that we don't need *any* of this.

> The bitmap code probably could as well, although it would need a bit
> more work. But then, AFAICT, nothing actually creates sparse bitmaps
> (which are the sole reason that the bitmap library uses the link
> library).

I'm not familiar with bitmap.c yet. I'll have a look

Regards,
Rosen Matev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Compilation errors under MinGW

[Rosen Matev]

Hello,

There are a few errors that popped out when I tried to compile MinGW.
As far as I can see only trunk is faulty. I solved the problem by
updating the problematic files from an older revision. Here is the
summary:

COMPILATION ERRORS //in mingw environment
(revision 34688)

/trunk/lib/gis
locale.c:33: error: `LC_MESSAGES' undeclared (first use in this function)
// the problem is in locale.h bundled with mingw
// probably not GRASS' issue but I'm not sure

mach_name.c:34:6: #if with no expression
// the #elif at #34 should be #else

popen.c:55: error: `popen_pid' undeclared (first use in this function)
// what's the best way to fix this?

spawn.c: In function `G_spawn':
spawn.c:84: warning: passing arg 3 of `_spawnv' from incompatible
pointer type
spawn.c: In function `do_redirects':
spawn.c:215: warning: control reaches end of non-void function
spawn.c: In function `do_spawn':
spawn.c:232: error: `redirects' undeclared (first use in this function)
spawn.c:232: error: `num_redirects' undeclared (first use in this function)
spawn.c:233: error: `bindings' undeclared (first use in this function)
spawn.c:233: error: `num_bindings' undeclared (first use in this function)
spawn.c:236: error: `background' undeclared (first use in this function)
spawn.c:236: error: `args' undeclared (first use in this function)
spawn.c:237: warning: passing arg 4 of `spawnvpe' from
incompatible pointer type
spawn.c: In function `G_vspawn_ex':
spawn.c:631: warning: passing arg 1 of `do_spawn' from
incompatible pointer type
spawn.c:631: error: too many arguments to function `do_spawn'
spawn.c: In function `G_spawn_ex':
spawn.c:655: warning: passing arg 1 of `do_spawn' from
incompatible pointer type
spawn.c:655: error: too many arguments to function `do_spawn'
// some more errors...

The fix should be straightforward. I can't commit to trunk so I'm
letting you know for these.

Please elaborate on the first error. I fixed it by adding a line
"#define LC_MESSAGES 6" in locale.h, which pretty lame.

Regards,
Rosen Matev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: Testing results of new r.watershed against r.terraflow

[Isaac Ullah]

Sorry, I transposed the links. The top link is the results using r.terraflow
in r.landscape.evol, and the bottom link is the results using r.watershed,
not vice versa. Also, I should note that these maps are the absolute value
of the 10th year dem with smoothing enabled minus the 10th year dem with no
smoothing.

On 12/3/08, Isaac Ullah <[EMAIL PROTECTED]> wrote:
>
> Here are some additional results of testing between new version of
> r.watershed and r.terraflow.
>
> *Time costs:*
>
> Map A (2.8 million cells), r.watershed is 52 seconds faster than
> r.terraflow
>
> Map B (21 millions cells), r.watershed is 2 minutes 58 seconds faster than
> r.terraflow
>
> *Accuracy in r.landscape.evol simulations:*
>
> Maps produced using r.watershed for flowacc show realistic values of
> erosion and deposition *with no smoothing* after 10 model cycles(1 cycle =
> 1 sim year). The difference between smoothed and unsmoothed maps is at
> maximum only .5 meters, and the diffs are dispersed topographically. Image
> link:
> http://www.public.asu.edu/~iullah/files/MEDLAND/smo_nosmo_diff_terraflw.png
>
> Maps produced using r.terraflow for flowacc show spikes as high as +/- 96
> meters (with no smoothing) after 10 model cycles. Spikes are concentrated in
> the channels, and diff between smoothed and un smoothed results also show
> anamolies are concetrated in the channels. Image link:
> http://www.public.asu.edu/~iullah/files/MEDLAND/smo_nosmo_diff_rwshd.png
>
> I am currently testing new r.watershed in a longterm model run (100 cycles)
> with no smoothing, and will report the results here. In r.lnadscape.evol for
> a 2.8 million cell map, the smoothing routine costs 23.5 seconds. Using new
> r.watershed with the smoothing turned on takes 1 minute 5.5 seconds. Without
> smoothing takes only 42 seconds. Using r.terraflow with smoothing takes 1
> min 57 seconds. Using r.terraflow without smoothing takes 1 minute 33
> seconds, but produces unusable results. Also, using r.watershed eliminates
> the need to run r.fill.dir before each model run--an additional time
> savings...
>
> Cheers
> --
>
> Isaac I Ullah, M.A.
>
> Archaeology PhD Student,
> ASU School of Evolution and Social Change
>
> Research Assistant,
> Mediterranean Landscape Dynamics Project
> ***
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> http://www.public.asu.edu/~iullah
> ***




-- 

Isaac I Ullah, M.A.

Archaeology PhD Student,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project
***
[EMAIL PROTECTED]
[EMAIL PROTECTED]

http://www.public.asu.edu/~iullah
***
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Testing results of new r.watershed against r.terraflow

[Isaac Ullah]

Here are some additional results of testing between new version of
r.watershed and r.terraflow.

*Time costs:*

Map A (2.8 million cells), r.watershed is 52 seconds faster than r.terraflow

Map B (21 millions cells), r.watershed is 2 minutes 58 seconds faster than
r.terraflow

*Accuracy in r.landscape.evol simulations:*

Maps produced using r.watershed for flowacc show realistic values of erosion
and deposition *with no smoothing* after 10 model cycles(1 cycle = 1 sim
year). The difference between smoothed and unsmoothed maps is at maximum
only .5 meters, and the diffs are dispersed topographically. Image link:
http://www.public.asu.edu/~iullah/files/MEDLAND/smo_nosmo_diff_terraflw.png

Maps produced using r.terraflow for flowacc show spikes as high as +/- 96
meters (with no smoothing) after 10 model cycles. Spikes are concentrated in
the channels, and diff between smoothed and un smoothed results also show
anamolies are concetrated in the channels. Image link:
http://www.public.asu.edu/~iullah/files/MEDLAND/smo_nosmo_diff_rwshd.png

I am currently testing new r.watershed in a longterm model run (100 cycles)
with no smoothing, and will report the results here. In r.lnadscape.evol for
a 2.8 million cell map, the smoothing routine costs 23.5 seconds. Using new
r.watershed with the smoothing turned on takes 1 minute 5.5 seconds. Without
smoothing takes only 42 seconds. Using r.terraflow with smoothing takes 1
min 57 seconds. Using r.terraflow without smoothing takes 1 minute 33
seconds, but produces unusable results. Also, using r.watershed eliminates
the need to run r.fill.dir before each model run--an additional time
savings...

Cheers
-- 

Isaac I Ullah, M.A.

Archaeology PhD Student,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project
***
[EMAIL PROTECTED]
[EMAIL PROTECTED]

http://www.public.asu.edu/~iullah
***
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by glynn):

 Replying to [comment:12 hamish]:

 > thanks a lot for looking into this- to me this issue is a really bad
 look for us, sloppy output makes the project look sloppy. (and annoying
 for me to have to use xwd instead of d.out.file in 6.4.

 If you want quality, I would expect both the cairo and PS drivers to
 produce better results overall than either PNG or XDRIVER. However, you
 might run into corner cases where code relies upon the half pixel down-
 right shift, which isn't present in those drivers. You might also run into
 problems with the distinction between polylines and multiple line segments
 (caps versus joins) being visible.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-SVN] r34694 - grass-addons/vector/v.profile

[Maris Nartiss]

Hello Markus,
thanks for tip.
I hope to move v.profile into main GRASS module list after 6.4
release. It could be interesting to include such functionality in GUI
based profiling tools, as v.profile is a nice add-on to existing
raster profiling functionality (i.e. create elevation profile from
raster and put place marks from vectors where profile crosses roads,
rivers etc.) and then editing Makefile/providing env variable will not
be required anymore.

Maris.

2008/12/3, Markus Neteler <[EMAIL PROTECTED]>:
> Hi Maris,
>
> On Wed, Dec 3, 2008 at 10:36 AM,  <[EMAIL PROTECTED]> wrote:
>
>> +nano Makefile # edit MODULE_TOPDIR setting
>> +make
>
> You can just do this instead:
>
> make MODULE_TOPDIR=/path/to/grass64/
>
> cheers
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #355: ps.map generates invalid postscript when vlegend item does not appear on map

[GRASS GIS]

#355: ps.map generates invalid postscript when vlegend item does not appear on
map
---+
  Reporter:  scottygamm|   Owner:  hamish  
  Type:  defect|  Status:  assigned
  Priority:  minor |   Milestone:  6.4.0   
 Component:  ps.map| Version:  6.3.0   
Resolution:|Keywords:  
  Platform:  MSWindows CygWin  | Cpu:  x86-32  
---+
Changes (by hamish):

  * milestone:  6.3.1 => 6.4.0

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #363: Accsess Denied in .grassrc6

[GRASS GIS]

#363: Accsess Denied in .grassrc6
---+
  Reporter:  roykouda  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  minor |   Milestone:  6.3.1
 Component:  default   | Version:  6.3.0
Resolution:|Keywords:   
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hamish):

 did you resolve this?
 does it continue to happen every time you run grass, or just the first
 time you installed it? (when presumably .grassrc6 didn't exist, it gets
 created the first time you run GRASS)


 ie no one else has reported this problem, can we close the bug?


 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 Replying to [comment:11 glynn]:
 > Okay. There were two problems with the existing polygon filler,
 > which should be fixed by attachment:ticket:72:pngdriver-polygon.patch.
 ...
 > The one issue which this patch doesn't attempt to address is the
 > fact that all lines are effectively shifted half a pixel down and
 > to the right. This is inherent in the use of integer coordinates.

 any preprocessing floor(0.5+x) voodoo of the line data to align them with
 the polygon rendering? [yeah, that's what got us into this mess in the
 first place]

 > While you can draw a polygon with orthogonal edges perfectly
 > aligned to the pixel grid, you can't draw a single-pixel
 > orthogonal stroke with its centre-line so aligned.

 ... as it would have to be zero or two pixels wide.


 > I have attached PNG files containing the output before and after
 > the patch, as well as corresponding SVG files which show exactly
 > what is happening in more detail.

 I've attached a zoom of "after" showing the left over stray pixels
 shown in the SVG. Even with those, a nice improvement.


 thanks a lot for looking into this- to me this issue is a really bad look
 for us, sloppy output makes the project look sloppy. (and annoying for me
 to have to use xwd instead of d.out.file in 6.4.


 I'll try the patch in the AM.

 cheers,
 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-SVN] r34694 - grass-addons/vector/v.profile

[Markus Neteler]

Hi Maris,

On Wed, Dec 3, 2008 at 10:36 AM,  <[EMAIL PROTECTED]> wrote:

> +nano Makefile # edit MODULE_TOPDIR setting
> +make

You can just do this instead:

make MODULE_TOPDIR=/path/to/grass64/

cheers
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by glynn):

 Replying to [comment:10 hamish]:
 {{{
 echo "symbol geology/strike_triangle 22 50 50 black black" >
 draw_triangle.dgr
 d.graph draw_triangle.dgr
 }}}

 Okay. There were two problems with the existing polygon filler, which
 should be fixed by attachment:ticket:72:pngdriver-polygon.patch.

 The first is that the x coordinates were calculated for the top of the
 pixel rather than the centre, causing an effective downward shift.

 The second is that the x coordinates were truncated rather than rounded,
 causing a leftward shift.

 In the test case, both of these contribute to the gap on the right-hand
 side, while the latter contributes to the overlap on the left-hand side.

 The one issue which this patch doesn't attempt to address is the fact that
 all lines are effectively shifted half a pixel down and to the right. This
 is inherent in the use of integer coordinates. While you can draw a
 polygon with orthogonal edges perfectly aligned to the pixel grid, you
 can't draw a single-pixel orthogonal stroke with its centre-line so
 aligned.

 I have attached PNG files containing the output before and after the
 patch, as well as corresponding SVG files which show exactly what is
 happening in more detail. The actual vertices passed to the rendering
 functions (both line and polygon) are [(315,240), (320,229), (325,240)].
 This corresponds to the black triangle. The red triangle shows the half
 pixel down-right shift inherent in the line drawing.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev