[GRASS-dev] ps.map: scale wrong and no output

GRASS GIS GRASS GIS developer
1

Hi,

ps.map calculates the scale wrong.

In a following region:

$ g.region -g
n=5603200
s=5572300
w=3661900
e=3709600
nsres=100
ewres=100
rows=309
cols=477

a following ps.map syntax:

---
raster dol

paper a0
end

end
---

leads to the calculated scale is wrong:

$ ps.map input=ps.txt out=dol.ps
PS-PAINT: scale set to 1 :
189563909041466328239248756598074334180039196672.
PS-PAINT: reading raster file <dol in PERMANENT> ...
PS-PAINT: PostScript file "dol2.ps" successfully written.

... and the file is corrupted.

Interestingly, each another run calculates a different scale, eg.:

1 : 142326034786662069525054397244000749605886099456
1 : 117895386731897106408980263771204349942212591616
1 : 130987549471569116744136784814156140792334254080

If I define the paper manually, like:

height 46.77
width 33.07
left 1
right 1
bottom 1
top 1

All is OK, the calculated scale is 1:37000.

Maciek

2

Maciej Sieczka wrote:

Hi,

ps.map calculates the scale wrong.

In a following region:

$ g.region -g
n=5603200
s=5572300
w=3661900
e=3709600
nsres=100
ewres=100
rows=309
cols=477

a following ps.map syntax:

---
raster dol

paper a0
end

end
---

leads to the calculated scale is wrong:

$ ps.map input=ps.txt out=dol.ps
PS-PAINT: scale set to 1 :
189563909041466328239248756598074334180039196672.
PS-PAINT: reading raster file <dol in PERMANENT> ...
PS-PAINT: PostScript file "dol2.ps" successfully written.

... and the file is corrupted.

Interestingly, each another run calculates a different scale, eg.:

1 : 142326034786662069525054397244000749605886099456
1 : 117895386731897106408980263771204349942212591616
1 : 130987549471569116744136784814156140792334254080

If I define the paper manually, like:

height 46.77
width 33.07
left 1
right 1
bottom 1
top 1

All is OK, the calculated scale is 1:37000.

Specifying a named paper size doesn't work. More precisely, failing to
specify all of the properties of the paper size doesn't work.

The problem is due to the attempt to handle rotated plots:

  RCS file: /grassrepository/grass6/ps/ps.map/r_paper.c,v
  Working file: r_paper.c
  ----------------------------
  revision 1.2
  date: 2006/08/04 07:25:22; author: markus; state: Exp; lines: +22 -12
  Bob Covill: fix paper size/map scaling for rotated map
  ----------------------------

The updated version of read_paper() attempts to unconditionally fill
in all of the fields related to paper sizes, when it should only be
setting fields which are actually specified. If the user fails to
explicitly specify any of the fields, that field will contain garbage.

--
Glynn Clements <glynn@gclements.plus.com>

3

Maciej Sieczka wrote:
> ps.map calculates the scale wrong.

..

> paper a0
> end

..

> PS-PAINT: scale set to 1 :
> 189563909041466328239248756598074334180039196672.

..

> If I define the paper manually, like:
>
> height 46.77
> width 33.07
> left 1
> right 1
> bottom 1
> top 1
>
> All is OK, the calculated scale is 1:37000.

Specifying a named paper size doesn't work. More precisely, failing to
specify all of the properties of the paper size doesn't work.

The problem is due to the attempt to handle rotated plots:

  RCS file: /grassrepository/grass6/ps/ps.map/r_paper.c,v
  Working file: r_paper.c
  ----------------------------
  revision 1.2
  date: 2006/08/04 07:25:22; author: markus; state: Exp; lines:
  +22 -12 Bob Covill: fix paper size/map scaling for rotated map
  ----------------------------

The updated version of read_paper() attempts to unconditionally fill
in all of the fields related to paper sizes, when it should only be
setting fields which are actually specified. If the user fails to
explicitly specify any of the fields, that field will contain garbage.

Yep. I just figured out the same a few minutes ago & fixed it in CVS.
(+6.2 release branch). It was ok in 6.1.0.

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
   http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
   https://intevation.de/rt/webrt?serial_num=5209

Hamish

4

Hamish wrote:

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
   http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
   https://intevation.de/rt/webrt?serial_num=5209

Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.

Maciek

5

Maciej Sieczka wrote on 11/16/2006 07:07 PM:

Hamish wrote:

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
   http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
   https://intevation.de/rt/webrt?serial_num=5209
    
Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.
  

There are some fixes which didn't make it yet into gis.m of 6.2. There
was offlist communication between Michael, Hamish and me on that
but I completely lost track which change should be submitted there.

Markus

6

Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.

This is not a bug. The single click zoom in (and out) uses the window
geometry to zoom in to fill the display as you get 'closer', while centering
the view (i.e., display region) on the point you click. You can set the
aspect display geometry with a box or with g.region--or you can simply make
the display window the aspect geometry you want and single-click away. It
works like the zoom in/zoom out button that GRASS lacks. IMHO, it's pretty
slick. While some might wish it were otherwise, it is this way with
forethought and intention, and works exactly as designed--so not a bug.

I've tried to notify you about all bug fixes that should be backported. And
if I remember correctly, you've told me that each one was backported. The
only possible outstanding bug is the slightly misleading error message
generated when the GUI fails to start up because gdal is not installed or
incorrectly installed. However, in discussions with Hamish, it is looking
like this would be better trapped before the GUI tries to launch.

Eric Patton's text/laton grid problem is a 6.3 issue that I've not yet been
able to replicate. The same goes for the in-progress nviz updates.

Let me know if there is anything else that comes to mind.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

7

Michael Barton wrote:

The only possible outstanding bug is the slightly misleading error
message generated when the GUI fails to start up because gdal is not
installed or incorrectly installed. However, in discussions with
Hamish, it is looking like this would be better trapped before the GUI
tries to launch.

I wrote [offlist]:
re gis.m failing on startup with "parts(n)" error if libgdal is missing-

I get it now, so by that point g.region is history and we are dealing
with the downstream effects of the failure. It's informative /where/ it
broke for debugging by us, but not /why/ for self-debugging by the user.
Optimally we want to pick up and regurgitate the "libgdal.so not found"
message somehow.

did you figure out how to get the return code from a C module in tcl?
(like "$?" in bash scripts) to test if the module exited with an error
or not? [=0 is success, =something else is failure]

like $GISBASE/etc/grass-run.sh tests.

[see end of http://wiki.tcl.tk/902 ]

or maybe test that the values of n,s,e,w are not empty directly after
the g.region call?

mapcanvas.tcl: line 1035

# Zoom to something loaded from a g.region command
proc MapCanvas::zoom_gregion {mon args} {
  global env

  if {![catch {open [concat "|g.region" "-ug" $args] r} input]} {
    while {[gets $input line] >= 0} {
      regexp -nocase {^([a-z]+)=(.*)$} $line trash key value
      set parts($key) $value
    }
    catch {close $input}

    MapCanvas::zoom_new $mon $parts(n) $parts(s) $parts(e) \
      $parts(w) $parts(nsres) $parts(ewres)

  }
}

I don't fully understand the catch- does it get stderr?:
http://www.wellho.net/mouth/366_Error-handling-in-Tcl-through-catch.html

or maybe the solution is to run a tiny do-nothing C program at start up
which depends on all the compiled-in libraries that were configured
during the build step?
[...]
a little program for Init.sh that needs the core rast,vect,proj libraries:
$(VECTLIB) $(GPROJLIB) $(GISLIB)

Init.sh before starting the GUI:
"$GISBASE"/etc/g.testlibs
if [ $? -ne 0 ] ; then
   echo "library failure of some sort. please fix." >&2
   exit 1
fi

Hamish

8

I've been tied up with a visiting speaker and haven't had time to read email
or check on TclTk-C interaction. I'll try to get to it soon.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Sat, 18 Nov 2006 21:05:36 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] fixes before 6.2.1 [was: ps.map: scale wrong and no
output]

Michael Barton wrote:

The only possible outstanding bug is the slightly misleading error
message generated when the GUI fails to start up because gdal is not
installed or incorrectly installed. However, in discussions with
Hamish, it is looking like this would be better trapped before the GUI
tries to launch.

I wrote [offlist]:
re gis.m failing on startup with "parts(n)" error if libgdal is missing-

I get it now, so by that point g.region is history and we are dealing
with the downstream effects of the failure. It's informative /where/ it
broke for debugging by us, but not /why/ for self-debugging by the user.
Optimally we want to pick up and regurgitate the "libgdal.so not found"
message somehow.

did you figure out how to get the return code from a C module in tcl?
(like "$?" in bash scripts) to test if the module exited with an error
or not? [=0 is success, =something else is failure]

like $GISBASE/etc/grass-run.sh tests.

[see end of catch ]

or maybe test that the values of n,s,e,w are not empty directly after
the g.region call?

mapcanvas.tcl: line 1035

# Zoom to something loaded from a g.region command
proc MapCanvas::zoom_gregion {mon args} {
global env

if {![catch {open [concat "|g.region" "-ug" $args] r} input]} {
while {[gets $input line] >= 0} {
regexp -nocase {^([a-z]+)=(.*)$} $line trash key value
set parts($key) $value
}
catch {close $input}

MapCanvas::zoom_new $mon $parts(n) $parts(s) $parts(e) \
$parts(w) $parts(nsres) $parts(ewres)

}
}

I don't fully understand the catch- does it get stderr?:
Error handling in Tcl through catch

or maybe the solution is to run a tiny do-nothing C program at start up
which depends on all the compiled-in libraries that were configured
during the build step?
[...]
a little program for Init.sh that needs the core rast,vect,proj libraries:
$(VECTLIB) $(GPROJLIB) $(GISLIB)

Init.sh before starting the GUI:
"$GISBASE"/etc/g.testlibs
if [ $? -ne 0 ] ; then
   echo "library failure of some sort. please fix." >&2
   exit 1
fi

Hamish

9

Hamish wrote:

did you figure out how to get the return code from a C module in tcl?
(like "$?" in bash scripts) to test if the module exited with an error
or not? [=0 is success, =something else is failure]

"exec" will throw an error if the command either returns a non-zero
exit status or writes to stderr. In the case where the command returns
a non-zero exit status, you can obtain some more information from the
errorCode variable.

For normal termination (i.e. exit() or return from main()), $errorCode
contains:

  CHILDSTATUS <pid> <exit code>
e.g.:
  CHILDSTATUS 21103 1

For termination on a signal, $errorCode contains:

  CHILDKILLED <pid> <signal name> <signal description>
e.g.:
  CHILDKILLED 21105 SIGTERM {software termination signal}

This is on Linux; I don't know about Windows.

--
Glynn Clements <glynn@gclements.plus.com>

10

Hamish wrote:

I don't fully understand the catch- does it get stderr?:
http://www.wellho.net/mouth/366_Error-handling-in-Tcl-through-catch.html

If the command writes to stderr, the text is used as the error message
in the error thrown by "exec". If you pass a variable name as the
second argument to "catch", the variable will contain the error
message, i.e. the text written to stderr.

--
Glynn Clements <glynn@gclements.plus.com>

11

Hi,

2006/11/16, Hamish <hamish_nospam@yahoo.com>:

[snip]

It would be nice to fix this one too:
   https://intevation.de/rt/webrt?serial_num=5209

I have tried to fix this bug (the attached patch). Is it OK? -- then I
will commit it to CVS...

Best, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

v_in_ascii_LL.diff.gz (1000 Bytes)

12

Just a few observations on nviz volume support, hope it provides some
useful informations.

For me, the slovakia3d volume has always worked with NVIZ. Also, when I
create a new volume in that location, I can vizualize it with NVIZ w/o
problems. E.g.:

  r3.mapcalc tmp=1.0

works fine, also if I change the 3D region settings, e.g

  g.region b=2000.0
  r3.mapcalc tmp2=2.0

still displays OK.

HOWEVER, for my vizualization tasks I use very small, local coordinate
ranges (archaeological site stratigraphies of just a few cubic meters)
with very small 3d cell sizes.
E.g., I have a 3D region set to this:

projection: 0 (x,y)
zone: 0
north: 61
south: 58
west: 14
east: 17
top: 12.00000000
bottom: 9.00000000
nsres: 0.05
nsres3: 0.05
ewres: 0.05
ewres3: 0.05
tbres: 0.05
rows: 60
rows3: 60
cols: 60
cols3: 60
depths: 60
cells: 3600
3dcells: 216000

Now, when I create a simple volume like above, It does not display in
nviz, I can neither create iso surfaces nor slices.
When I zoom out (increasing the "Height" slider) then NVIZ * sometimes *
shows the outlines of the volume and I can see, that it has been totally
displaced, below my 3d working region (see attached image)!

Apparently, there are some scale effects here and nviz cannot handle
volumes at these small region and resolution settings.

Another remaining problem (though not a bug) is that NULL values
in volumes cannot be set transparent independently of other 3d cell
values (not so sure if this is possible for 2d rasters in nviz).

Well, good luck fixing these and the other issues with nviz.
I think it would be tremendously important to finally have working
3d raster vizualization in GRASS. I for one would be extremely
grateful for it.

Benjamin

Markus Neteler wrote:

Maciej Sieczka wrote on 11/16/2006 07:07 PM:

Hamish wrote:

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
  http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
  https://intevation.de/rt/webrt?serial_num=5209
   
Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.

There are some fixes which didn't make it yet into gis.m of 6.2. There
was offlist communication between Michael, Hamish and me on that
but I completely lost track which change should be submitted there.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

(attachments)

nviz-trouble.jpg

13

Benjamin,

What I have found so far is that what is displayed is very strongly
dependent on polygon resolution--especially for isosurfaces. If you set it
wrong, you can get nothing, rendering that will last into the next day, or
different looking surfaces. I'm not sure it's incorrect, but it is very
sensitive. The critical resolutions will also depend on the size of the
region and number of voxels in the volume. I've had to experiment with each
volume I do.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Date: Mon, 20 Nov 2006 13:39:08 +0100
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] fixes before 6.2.1 [was: ps.map: scale wrong and no
output]

Just a few observations on nviz volume support, hope it provides some
useful informations.

For me, the slovakia3d volume has always worked with NVIZ. Also, when I
create a new volume in that location, I can vizualize it with NVIZ w/o
problems. E.g.:

r3.mapcalc tmp=1.0

works fine, also if I change the 3D region settings, e.g

g.region b=2000.0
r3.mapcalc tmp2=2.0

still displays OK.

HOWEVER, for my vizualization tasks I use very small, local coordinate
ranges (archaeological site stratigraphies of just a few cubic meters)
with very small 3d cell sizes.
E.g., I have a 3D region set to this:

projection: 0 (x,y)
zone: 0
north: 61
south: 58
west: 14
east: 17
top: 12.00000000
bottom: 9.00000000
nsres: 0.05
nsres3: 0.05
ewres: 0.05
ewres3: 0.05
tbres: 0.05
rows: 60
rows3: 60
cols: 60
cols3: 60
depths: 60
cells: 3600
3dcells: 216000

Now, when I create a simple volume like above, It does not display in
nviz, I can neither create iso surfaces nor slices.
When I zoom out (increasing the "Height" slider) then NVIZ * sometimes *
shows the outlines of the volume and I can see, that it has been totally
displaced, below my 3d working region (see attached image)!

Apparently, there are some scale effects here and nviz cannot handle
volumes at these small region and resolution settings.

Another remaining problem (though not a bug) is that NULL values
in volumes cannot be set transparent independently of other 3d cell
values (not so sure if this is possible for 2d rasters in nviz).

Well, good luck fixing these and the other issues with nviz.
I think it would be tremendously important to finally have working
3d raster vizualization in GRASS. I for one would be extremely
grateful for it.

Benjamin

Markus Neteler wrote:

Maciej Sieczka wrote on 11/16/2006 07:07 PM:

Hamish wrote:

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
  http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
  https://intevation.de/rt/webrt?serial_num=5209
   
Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.

There are some fixes which didn't make it yet into gis.m of 6.2. There
was offlist communication between Michael, Hamish and me on that
but I completely lost track which change should be submitted there.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

14

OK, I have done some experimenting and this is what it looks like for
me:

It indeed seems to be a problem with small region settings.
Basically, anything with a cell resolution < 1.0 in any axis does not
seem to display (i.e. results gets totally displaced as illustrated
in the screenshot I sent earlier).

IN ADDITION, the number of rows, cols and depths must at least be
10! If any of those fall below, the result gets more or less strongly
displaced.

Now, I am not sure if this is a problem with some sort of scaling or
translation, maybe something that also happens with larger cells and
region settings but goes unnoticed in those cases, because the offsets
shrinks to a very small value ???

I am not sure if that also makes sense in relation to Michael's report.

Benjamin

Helena Mitasova wrote:

Benjamin,

can you do a small test to confirm that the problem is indeed with
small numbers by multiplying the coordinates in your area by 100 (so you will
get res=5) and see whether nviz volumes still don't work?
The volumes support for nviz was implemented when the 3D region
was handled separately from 2D region, after everything was merged into
a single file it may not be reading the region correctly when the numbers are small,

thanks Helena

Benjamin Ducke wrote:

Just a few observations on nviz volume support, hope it provides some
useful informations.

For me, the slovakia3d volume has always worked with NVIZ. Also, when I
create a new volume in that location, I can vizualize it with NVIZ w/o
problems. E.g.:

    r3.mapcalc tmp=1.0

works fine, also if I change the 3D region settings, e.g

    g.region b=2000.0
    r3.mapcalc tmp2=2.0

still displays OK.

HOWEVER, for my vizualization tasks I use very small, local coordinate
ranges (archaeological site stratigraphies of just a few cubic meters)
with very small 3d cell sizes.
E.g., I have a 3D region set to this:

projection: 0 (x,y)
zone: 0
north: 61
south: 58
west: 14
east: 17
top: 12.00000000
bottom: 9.00000000
nsres: 0.05
nsres3: 0.05
ewres: 0.05
ewres3: 0.05
tbres: 0.05
rows: 60
rows3: 60
cols: 60
cols3: 60
depths: 60
cells: 3600
3dcells: 216000

Now, when I create a simple volume like above, It does not display in
nviz, I can neither create iso surfaces nor slices.
When I zoom out (increasing the "Height" slider) then NVIZ * sometimes *
shows the outlines of the volume and I can see, that it has been totally
displaced, below my 3d working region (see attached image)!

Apparently, there are some scale effects here and nviz cannot handle
volumes at these small region and resolution settings.

Another remaining problem (though not a bug) is that NULL values
in volumes cannot be set transparent independently of other 3d cell
values (not so sure if this is possible for 2d rasters in nviz).

Well, good luck fixing these and the other issues with nviz.
I think it would be tremendously important to finally have working
3d raster vizualization in GRASS. I for one would be extremely
grateful for it.

Benjamin

Markus Neteler wrote:

Maciej Sieczka wrote on 11/16/2006 07:07 PM:

Hamish wrote:

So ps.map is pretty much broken in 6.2.0. Bummer.

If we can figure out why NVIZ volumes are broken and fix the following
bug, I'd vote for a quick 6.2.1 release.

NVIZ volume problem (test with slovakia3d dataset) - sometimes it works
* fails from command line; ok if the volume added within NVIZ (bug #4725)
  http://intevation.de/rt/webrt?serial_num=4725

It would be nice to fix this one too:
  https://intevation.de/rt/webrt?serial_num=5209
   
Fixing the gis.m, so that it preserved the aspect ratio for
single-click zooming in the restricted mode, is also a critical issue.

There are some fixes which didn't make it yet into gis.m of 6.2. There
was offlist communication between Michael, Hamish and me on that
but I completely lost track which change should be submitted there.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

------------------------------------------------------------------------

------------------------------------------------------------------------

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

15

Martin Landa wrote:

> https://intevation.de/rt/webrt?serial_num=5209

I have tried to fix this bug (the attached patch). Is it OK? -- then I
will commit it to CVS...

re. "column type" text, it is probably not a good idea to mix
fprintf(stderr, and G_message(). I can see why you kept the first bit
with fprintf (no newline), but the module output will look really weird
if called with the --quiet flag as only G_message() part would disappear.

What seems to be needed is a G__message() or G_message_no_newline() or
somesuch fn that doesn't terminate with a newline.

This could be used for "Percent complete:"+G_percent() as well.
Then both msgs get switched on/off together with quiet/verbose.

The following looks good to me, but to preserve precision should "%lf"
be used instead of "%f", perhaps combined with G_trim_decimal()?

Index: vector/v.in.ascii/points.c

RCS file: /home/grass/grassrepository/grass6/vector/v.in.ascii/points.c,v
retrieving revision 1.21
diff -u -r1.21 points.c
--- vector/v.in.ascii/points.c 18 Oct 2006 05:09:22 -0000 1.21
+++ vector/v.in.ascii/points.c 19 Nov 2006 16:45:25 -0000
@@ -368,7 +368,15 @@
                if (strlen(tokens[i]) > 0) {
                    if (coltype[i] == DB_C_TYPE_INT ||
                        coltype[i] == DB_C_TYPE_DOUBLE) {
- sprintf(buf2, "%s", tokens[i]);
+ if (G_projection() == PROJECTION_LL &&
+ (i == xcol || i == ycol)) {
+ if (i == xcol)
+ sprintf(buf2, "%f", x);
+ else
+ sprintf(buf2, "%f", y);
+ }
+ else
+ sprintf(buf2, "%s", tokens[i]);
                    }
                    else {
                        db_set_string(&val, tokens[i]);

thanks,
Hamish