[GRASS-user] Re: grassuser Digest, Vol 11, Issue 18
Jorge Echeverri
jorge.echeverri at Stein.de
Wed Mar 14 04:34:10 EDT 2007
Hi Maciek,
I got the right tip already. This error message was caused by a blank
line at the end of the file. That's why despite of the error the data
were read correctly.
Thanks,
Jorge
Message: 6
> Date: Tue, 13 Mar 2007 20:12:10 +0100
> From: Maciej Sieczka <tutey at o2.pl>
> Subject: Re: [GRASS-user] points to lines
> To: Jorge Echeverri <Jorge.Echeverri at Stein.de>, GRASSLIST
> <grassuser at grass.itc.it>
> Message-ID: <45F6F78A.1060003 at o2.pl>
> Content-Type: text/plain; charset=ISO-8859-2
>
> Jorge Echeverri wrote:
> > I still don't find out the error:
> >
> > Input file:
> > #"X_COORDINATE","Y_COORDINATE"
> > L 2 1
> > 3400630.04 5718486.603
> > 3400639.238 5718515.776
> > 1 1
> > L 2 1
> > 3400639.238 5718515.776
> > 3400648.641 5718546.057
> > 1 2
> > L 2 1
> > 3400648.641 5718546.057
> > 3400665.041 5718562.99
> > 1 3
> > L 2 1
> > 3400665.041 5718562.99
> > 3400625.996 5718597.349
> > 1 4
> >
> > Then
> > GRASS 6.2.1 (luenenxy):~ > v.in.ascii
> > input=/home/jorge/GrassGIS/luenenxy/jorge/koord2.csv out=koord_grass2
> > format=standard --overwrite
> > Error reading ascii file:
> > [ ]
>
> Use -n to omit checking for header in the input ASCII vector, like I
> wrote before. Look into v.in.ascii, v.out.ascii and pages linked there
> for details.
>
> > Erzeuge Topologie ...
> > 4 primitives registriert
> > Building areas: 100%
> > 0 Flchen erstellt
> > 0 Inselflchen erstellt
> > Fge Inselflchen hinzu:
> > Fge Zentroide hinzu: 100%
> > Die Topologie wurde erstellt.
> > Anzahl von Knoten : 5
> > Anzahl von Primitives : 4
> > Anzahl von Punkten : 0
> > Anzahl von Linien : 4
> > Anzahl von Boundaries : 0
> > Anzahl von Zentroiden : 0
> > Anzahl von Flchen : 0
> > Anzahl von Inseln : 0
> >
> > But the lines are rightly imported, so I guess this error message can be
> > ignored, isn't it?
>
> Are you sure there was no more info about the error besides the:
>
> > Error reading ascii file:
> > [ ]
>
> as you quoted it? Strange.
>
> Anyway, in 6.3 CVS v.in.ascii format=standard won't proceed with a
> malformed or missing header if -n is not used. It might be different in
> 6.2.1 which you are using though. But that would be a bug.
>
> [after a while]
>
> I have confirmed the -n switch is not processed right in 6.2.2 CVS
> either (yet somewhat diffrently than in 6.2.1, which issues an
> enigmatic error, while 6.2.2 does not issue any Error); see the note
> dated 2007-03-13 20:07 on
> http://wald.intevation.org/tracker/index.php?func=detail&aid=328&group_id=21&atid=204
>
> Maciek
Am Mittwoch, den 14.03.2007, 05:46 +0100 schrieb
grassuser-request at grass.itc.it:
> Send grassuser mailing list submissions to
> grassuser at grass.itc.it
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://grass.itc.it/mailman/listinfo/grassuser
> or, via email, send a message with subject or body 'help' to
> grassuser-request at grass.itc.it
>
> You can reach the person managing the list at
> grassuser-owner at grass.itc.it
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grassuser digest..."
>
>
> Today's Topics:
>
> 1. Re: Compiling grass 6.2.1: i.class error (Sean Fulton)
> 2. Re: Compiling grass 6.2.1: i.class error (Sean Fulton)
> 3. r3.in.v5d works? examples? (mespana at ugr.es)
> 4. pan/zoom while digitizing (Ricardo Oliveira)
> 5. Re: Compiling grass 6.2.1: i.class error (Glynn Clements)
> 6. Re: points to lines (Maciej Sieczka)
> 7. v.breach and v.line.center GRASS addons (Maciej Sieczka)
> 8. Help reqired (Arindam Nath)
> 9. Re: pan/zoom while digitizing (Hamish)
> 10. Re: r.in.srtm help, again (Hamish)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Mar 2007 10:53:20 -0400
> From: Sean Fulton <seanasy at gmail.com>
> Subject: Re: [GRASS-user] Compiling grass 6.2.1: i.class error
> To: grassuser at grass.itc.it
> Message-ID: <et6dsv$da2$1 at sea.gmane.org>
> Content-Type: text/plain; charset=Big5-HKSCS; format=flowed
>
> On 2007-03-09 12:59:56 -0500, Glynn Clements <glynn at gclements.plus.com> said:
>
> >
> > Sean Fulton wrote:
> >
> >>>> I'm trying to compile 6.2.1 on Mac OS X 10.4.8. I get an undefined
> >>>> symbol (_I_vask_subgroup_old) error compliling i.class.
> >>>>
> >>>> Can anyone point me in the right direction for resolving this? Output is below.
> >>>
> >>> How/where did you get the source code? The file containing that
> >>> function (lib/imagery/vask_group.c) has been removed from the CVS
> >>> trunk, but is still present in the 6.2 branch.
> >>>
> >>> Also, if you have a 6.3 version installed such that the linker will
> >>> find its libraries, that could potentially cause this problem.
> >>
> >> So, are you recommending using the CVS version? (I'd rather not)
> >
> > No, I was just suggesting one possible explanation. But I may have
> > found another.
> >
> >> Is there any clue to what the problem is?
> >
> > The body of lib/imagery/vask_group.c is conditionalised upon:
> >
> > #ifdef HAVE_CURSES_H
> >
> > Is HAVE_CURSES_H defined in include/config.h and/or
> > dist.i686-apple-darwin8.8.1/include/config.h?
> >
> > If not, that would explain the problem. However, failure to detect
> > curses.h should be a fatal configure error; unless you use
> > --without-curses, and I would expect more than just i.class to fail in
> > that situation.
> >
> > [Although curses is technically an optional dependency, a lot of GRASS
> > components require it, and many of them don't explicitly check for its
> > presence; they just assume it is available and fail (with an error) if
> > it isn't.]
>
> I'll look into that. I know I did try to compile it --without-curses
> and sputtered and choked. Is that switch useful for some reason?
> Compiling libgrass?
>
> The build system doesn't seem to be very smart about finding libs and
> includes so I might have missed a necessary configure option somewhere.
> I'll go over those in more detail.
>
> Thanks for your help.
>
> Sean
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 13 Mar 2007 11:34:09 -0400
> From: Sean Fulton <seanasy at gmail.com>
> Subject: Re: [GRASS-user] Compiling grass 6.2.1: i.class error
> To: grassuser at grass.itc.it
> Message-ID: <et6g9g$n3p$1 at sea.gmane.org>
> Content-Type: text/plain; charset=Big5-HKSCS; format=flowed
>
> On 2007-03-09 12:59:56 -0500, Glynn Clements <glynn at gclements.plus.com> said:
>
> >
> > Sean Fulton wrote:
> >
> >>>> I'm trying to compile 6.2.1 on Mac OS X 10.4.8. I get an undefined
> >>>> symbol (_I_vask_subgroup_old) error compliling i.class.
> >>>>
> >>>> Can anyone point me in the right direction for resolving this? Output is below.
> >>>
> >>> How/where did you get the source code? The file containing that
> >>> function (lib/imagery/vask_group.c) has been removed from the CVS
> >>> trunk, but is still present in the 6.2 branch.
> >>>
> >>> Also, if you have a 6.3 version installed such that the linker will
> >>> find its libraries, that could potentially cause this problem.
> >>
> >> So, are you recommending using the CVS version? (I'd rather not)
> >
> > No, I was just suggesting one possible explanation. But I may have
> > found another.
> >
> >> Is there any clue to what the problem is?
> >
> > The body of lib/imagery/vask_group.c is conditionalised upon:
> >
> > #ifdef HAVE_CURSES_H
> >
> > Is HAVE_CURSES_H defined in include/config.h and/or
> > dist.i686-apple-darwin8.8.1/include/config.h?
> >
> > If not, that would explain the problem. However, failure to detect
> > curses.h should be a fatal configure error; unless you use
> > --without-curses, and I would expect more than just i.class to fail in
> > that situation.
> >
> > [Although curses is technically an optional dependency, a lot of GRASS
> > components require it, and many of them don't explicitly check for its
> > presence; they just assume it is available and fail (with an error) if
> > it isn't.]
>
> Actually, I'm an idiot.
>
> I forgot to 'make clean' before making changes to configure and
> recompiling. The older built libs were still in the dist directory.
>
> Sorry for bugging you. Hopefully it will serve as a lesson for someone
> in the future.
>
> Sean
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 13 Mar 2007 16:47:54 +0100 (CET)
> From: mespana at ugr.es
> Subject: [GRASS-user] r3.in.v5d works? examples?
> To: grassuser at grass.itc.it
> Message-ID: <48770.150.214.103.80.1173800874.squirrel at goliat4.ugr.es>
> Content-Type: text/plain;charset=iso-8859-1
>
> Dear grassuser,
>
> I'm trying to use the r3.in.v5d module, to load a MM5 (atmospheric
> modelling) output from vis5d. I read at the manual pages that the command
> imports only one variable and one step time. Ok, but after that, I cannot
> visualize with Nviz the resulting g3d map.
>
> I've followed the next sequence of actions at Grass shell:
>
> r3.in.v5d input=vis5dmap.file output=SOC_mm5
> g.region rast3d=SOC_mm5
> nviz -q
> Load volumes visualization panel.
> choose SOC_mm5 as new volume
> change attribute threshold with constants within the range of levels
>
> I can't see nothing.
>
> Maybe I'm doing something wrong. I trained with the tutorial from
> Slovakia3D data set, and I've got the correct results.
>
> I've also tried to import vis5d example files, like hole.v5d or LAMPS.v5d,
> but it didn't go on.
>
> I wonder if anyone can help me in this question as experimented grass
> user, because I was looking for articles, manuals o similar using this
> command, but I didn't find anything.
>
> Thanks for your attention.
>
> Miriam
>
>
>
> --
> -------
> <>
> <> Miriam Espaa Acebal
> <> Ingeniera en Informatica / Computer Science Engineer
> <> Departamento de Fisica Aplicada / Applied Physics Department
> <> G. I. Fisica Atmosferica / Atmospheric Physics Research Group
> <> Universidad de Granada / University of Granada
> <> Espaa / Spain
> <> mespana at ugr.es
> <>
> -------
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 13 Mar 2007 16:20:05 -0000
> From: "Ricardo Oliveira" <autopilot at oniduo.pt>
> Subject: [GRASS-user] pan/zoom while digitizing
> To: <grassuser at grass.itc.it>
> Message-ID: <CD40D420FBE630488EF0CC85AED081423B271A at RVS2.at.isp>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear friends,
>
> While i am using r.digit i need to zoom/pan but i haven`t found a way to do so...the window size is locked?
> Any ideas?
>
> Ricardo Oliveira
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://grass.itc.it/pipermail/grassuser/attachments/20070313/dca9864e/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Tue, 13 Mar 2007 16:22:27 +0000
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-user] Compiling grass 6.2.1: i.class error
> To: Sean Fulton <seanasy at gmail.com>
> Cc: grassuser at grass.itc.it
> Message-ID: <17910.53187.37429.30986 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Sean Fulton wrote:
>
> > > [Although curses is technically an optional dependency, a lot of GRASS
> > > components require it, and many of them don't explicitly check for its
> > > presence; they just assume it is available and fail (with an error) if
> > > it isn't.]
> >
> > I'll look into that. I know I did try to compile it --without-curses
> > and sputtered and choked.
>
> If you have a partial build, you need to run "make distclean" before
> re-running configure with different switches. GRASS doesn't have
> complete dependency information (the sheer number of subdirectories
> makes this impractical), so if the configuration options are changed,
> some things which need to be re-built won't be.
>
> > Is that switch useful for some reason? Compiling libgrass?
>
> It's potentially useful if you only need a partial build (e.g. for a
> web application), and are willing to deal with any problems (e.g.
> lib/init is going to fail on set_data etc, so you will need "make -k"
> to get it to build other stuff in that directory). In that situation,
> you need to be able to force configure not to fail because of the lack
> of curses.
>
> Every other --without-* switch should work without requiring
> additional effort from the user, but curses is currently sufficiently
> ingrained that making --without-curses work nicely is too much effort
> for a relatively obscure usage case.
>
> > The build system doesn't seem to be very smart about finding libs and
> > includes so I might have missed a necessary configure option somewhere.
>
> It doesn't try to be smart; it tries to do what it's told. E.g. it
> will only add additional -I and/or -L switches in response to a
> corresponding --with-*-includes= or --with-*-libs= switch.
>
> At one time it tried being smart; frequently, it would pick up things
> which it shouldn't have (particularly on commercial Unices with both
> vendor and GNU versions of various packages which didn't like being
> mixed) resulting in complete failure to build anything (telling gcc to
> use the vendor's libc headers instead of its own tends to do that).
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 13 Mar 2007 20:12:10 +0100
> From: Maciej Sieczka <tutey at o2.pl>
> Subject: Re: [GRASS-user] points to lines
> To: Jorge Echeverri <Jorge.Echeverri at Stein.de>, GRASSLIST
> <grassuser at grass.itc.it>
> Message-ID: <45F6F78A.1060003 at o2.pl>
> Content-Type: text/plain; charset=ISO-8859-2
>
> Jorge Echeverri wrote:
> > I still don't find out the error:
> >
> > Input file:
> > #"X_COORDINATE","Y_COORDINATE"
> > L 2 1
> > 3400630.04 5718486.603
> > 3400639.238 5718515.776
> > 1 1
> > L 2 1
> > 3400639.238 5718515.776
> > 3400648.641 5718546.057
> > 1 2
> > L 2 1
> > 3400648.641 5718546.057
> > 3400665.041 5718562.99
> > 1 3
> > L 2 1
> > 3400665.041 5718562.99
> > 3400625.996 5718597.349
> > 1 4
> >
> > Then
> > GRASS 6.2.1 (luenenxy):~ > v.in.ascii
> > input=/home/jorge/GrassGIS/luenenxy/jorge/koord2.csv out=koord_grass2
> > format=standard --overwrite
> > Error reading ascii file:
> > [ ]
>
> Use -n to omit checking for header in the input ASCII vector, like I
> wrote before. Look into v.in.ascii, v.out.ascii and pages linked there
> for details.
>
> > Erzeuge Topologie ...
> > 4 primitives registriert
> > Building areas: 100%
> > 0 Flchen erstellt
> > 0 Inselflchen erstellt
> > Fge Inselflchen hinzu:
> > Fge Zentroide hinzu: 100%
> > Die Topologie wurde erstellt.
> > Anzahl von Knoten : 5
> > Anzahl von Primitives : 4
> > Anzahl von Punkten : 0
> > Anzahl von Linien : 4
> > Anzahl von Boundaries : 0
> > Anzahl von Zentroiden : 0
> > Anzahl von Flchen : 0
> > Anzahl von Inseln : 0
> >
> > But the lines are rightly imported, so I guess this error message can be
> > ignored, isn't it?
>
> Are you sure there was no more info about the error besides the:
>
> > Error reading ascii file:
> > [ ]
>
> as you quoted it? Strange.
>
> Anyway, in 6.3 CVS v.in.ascii format=standard won't proceed with a
> malformed or missing header if -n is not used. It might be different in
> 6.2.1 which you are using though. But that would be a bug.
>
> [after a while]
>
> I have confirmed the -n switch is not processed right in 6.2.2 CVS
> either (yet somewhat diffrently than in 6.2.1, which issues an
> enigmatic error, while 6.2.2 does not issue any Error); see the note
> dated 2007-03-13 20:07 on
> http://wald.intevation.org/tracker/index.php?func=detail&aid=328&group_id=21&atid=204
>
> Maciek
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 13 Mar 2007 21:06:18 +0100
> From: Maciej Sieczka <tutey at o2.pl>
> Subject: [GRASS-user] v.breach and v.line.center GRASS addons
> To: grass-dev <grass-dev at grass.itc.it>
> Cc: GRASSLIST <grassuser at grass.itc.it>
> Message-ID: <45F7043A.7020600 at o2.pl>
> Content-Type: text/plain; charset=ISO-8859-2
>
> Hi
>
> I have submitted 2 new scripts for GRASS 6.x to GRASS WIKI
> http://grass.gdf-hannover.de/wiki/GRASS_AddOns:
>
> v.line.center creates a points vector map with each point located in
> the middle of the length of one input vector line.
>
> v.breach creates vector maps of lines and points of continously
> lowering elevation down the input watercourses, based on the input
> raster DEM.
>
>
>
> v.line.center is a simple self-explanatory tool.
>
> v.breach is more complex. It is similar to r.carve -n, with the
> following differences:
>
> 1. It takes the direction of input vector lines into account; which
> means it is less prone to artifacts in the input DEM but more demanding
> to input watercourses. As a result you can breach DEM even against the
> slope, if that's needed ;).
>
> 2. It does not breach the DEM itself, but outputs vector points which
> have the breached elevation attribute stored in the table. These points
> can be used as additional data for interpolating more hydrologicaly
> sound DEM from scratch, or rasterized and burned into the input DEM
> manually (v.to.rast, r.mapcalc).
>
> 3. It also outputs vector lines, which are the input vector
> watercourses segmented one segment per each DEM cell through which a
> given input watercourse flows. Those segments have the breached
> elevation attribute same as the output vector points. I needed such
> output for my work. Maybe it will be of some use for others.
>
> 4. It is way slower than r.carve. Shell (I have got rid of bashisms I
> hope) + Awk + standard UNIX tools.
>
> See the v.breach manual for more details.
>
> Maciek
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 13 Mar 2007 18:24:42 -0500
> From: "Arindam Nath" <arindam04 at gmail.com>
> Subject: [GRASS-user] Help reqired
> To: grassuser at grass.itc.it
> Message-ID:
> <1e61caaf0703131624w10369417k2e1e8248e21f02dc at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
> I am trying if I can use the source code for GRASS and compile in VC++
> (Windows.) so that I can run from Windows platfrom without Cygwin. The
> desire is to run it just as a VC++ workspace.
> Can any one please help me in ths regard.
> Regards,
> Arindam Nath.
> MSEE, University of Texas at Arlington
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://grass.itc.it/pipermail/grassuser/attachments/20070313/889f013a/attachment-0001.html
>
> ------------------------------
>
> Message: 9
> Date: Wed, 14 Mar 2007 15:43:17 +1300
> From: Hamish <hamish_nospam at yahoo.com>
> Subject: Re: [GRASS-user] pan/zoom while digitizing
> To: "Ricardo Oliveira" <autopilot at oniduo.pt>
> Cc: grassuser at grass.itc.it
> Message-ID: <20070314154317.50010e93.hamish_nospam at yahoo.com>
> Content-Type: text/plain; charset=US-ASCII
>
> Ricardo Oliveira wrote:
> >
> > While i am using r.digit i need to zoom/pan but i haven`t found a way
> > to do so...the window size is locked?
>
> Yes, the region is locked while the module is running.
>
> > Any ideas?
>
> You might try the GRASS vector digitizer in QGIS + v.to.rast.
> (www.qgis.org)
>
> (v.digit has the same problem, but at least you don't have to exit the
> module to change the zoom, just the current tool)
>
>
>
> Hamish
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 14 Mar 2007 17:44:29 +1300
> From: Hamish <hamish_nospam at yahoo.com>
> Subject: Re: [GRASS-user] r.in.srtm help, again
> To: antonio rodriguez <antonio.raju at gmail.com>
> Cc: grassuser at grass.itc.it
> Message-ID: <20070314174429.6c8f80aa.hamish_nospam at yahoo.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> antonio rodriguez wrote:
> > I have some bathymetric data from GEBCO which are in .grd format (GMT)
> >
> > so I've tried:
> >
> > r.in.bin -h in=data.grd out=bati
> >
> > and I get:
> >
> > ERROR: North must be north of south
> >
> > The coordinates of the data are 38n/34n 9w/2e
> >
> > I've tried too:
> >
> > r.in.bin input=/home/toni/tmp/38n34n9w2e/38n34n9w2e.grd output=bati
> > north=38 south=34 east=2 west=-9
> >
> > Using rows=4 cols=11
>
> ^^^^
>
> > ATENCIN: Bytes do not match File size
> > ATENCIN: File Size 319216 ... Total Bytes 44
> > ATENCIN: Try bytes=7254 or adjusting input parameters
> >
> > So I tried with bytes=7254 (bytes=7255, bytes=7256) but I never get
> > the right number
> >
> > Any idea?
>
>
> set the correct rows= and cols= options. Right now it is guessing the
> raster resolution is 1 pixel = 1 degree x 1 degree.
>
> note the bytes description; it will mostly always be 1, 2, or 4:
> bytes Number of bytes per cell (1, 2, 4)
> default: 1
>
>
>
> Hamish
>
>
>
>
> ------------------------------
>
> _______________________________________________
> grassuser mailing list
> grassuser at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>
>
> End of grassuser Digest, Vol 11, Issue 18
> *****************************************
--
Jorge Echeverri, BSc Civ. Eng.
S & P CONSULT GMBH
Technologiequartier
Konrad-Zuse-Str. 6
D-44801 Bochum, Germany
Geschäftsführer: Dipl.-Ing. Robert Stein
Registergericht: Amtsgericht Bochum HRB 10769
Phone: +49(0) 234 51 67 193
Fax: +49(0) 234 51 67 109
Email: jorge.echeverri at stein.de
Internet: www.stein.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20070314/c210d2d7/attachment.html
More information about the grass-user
mailing list