[GRASS5] sites problem/bug?

[Andreas Lange]

Hi Eric,

thank you for your answer, i know now that the problem is located with
the string attribute, which was not obvious at first from the error
message. 

I don't think that the sites format should go completely, because it
makes small, timesaving hacks possible and is very intuitive. For many
types of data (samples in ecology etc.) a simple point format is
sufficient and convinient (IMHO). Topologically the point format would
belong to vectors, but i think that many functions in GRASS are only
available with the sites modules, so that it would be a lot of work to
reimplement those with vector modules. I don't want to miss the sites
files in GRASS.

cu,

Andreas

Eric G . Miller wrote:
> 
> On Sun, Oct 08, 2000 at 03:18:18PM +0200, Andreas Lange wrote:
> > Hi,
> >
> > i have a problem with a sites file. I can import the file with grass4.3
> > (and export and display it) with s.in.ascii, s.out.ascii and d.sites,
> > but on grass 5.0 i get on importing or exporting a "WARNING: error
> > scanning floating point attribute" and the resulting sites file is
> > empty.
> >
> > The format is e. g.:
> > 16.00000 45.800000 "String"
> > -1.05000 41.667000 "String"
> > ..
> >
> > If i import with grass4.3 or write the format with the "|" separator
> > myself with a perl program, s.out.ascii and d.sites work within
> > grass5.0beta.
> >
> > I am getting mad about those inconsistencies with the sites format. I
> > consider this as a very annoying bug, but if someone knows a workaround,
> > please tell me.
> 
> Yes, s.in.ascii is still buggy.  I did some small patches to it, but
> it's still buggy.  I don't think I can really fix this without rewriting
> the program.  I think the parsing makes too many assumptions about the
> input.  Also, I did notice the grassprogman.pdf says, unprefixed
> attributes should be treated as strings, but s.in.ascii tries to import
> them as doubles.  It still seems buggy about whether there is a cat
> number or not.  Best bet, for the moment, make sure all entries have a
> cat number and all attributes are prefixed with either an '@' for
> string, or an '%' for numeric.
> 
> Since I've gotten rather familiar with site_list processing lately, I
> could change the behavior to default to string attributes rather than
> doubles and generally rewrite the module.  Or be even slicker, try to
> convert unknown attributes to doubles, and if it fails, save them as
> strings.
> 
> In the future, I hope to see sites go away completely in favor of
> attribute tables associated with vector objects (area, line, node,...).
> 
> <example sites that will work>
> 
> GRASS:~ > s.in.ascii d=2 sites=site1
> 23.0098 34.123 #1 %99 @"My big long string"
> end
> 
> GRASS:~ > s.in.ascii d=2 sites=site3
> 303.999 12345.09 #5 909.99
> end
> 
> </example>
> 
> <example sites that fail>
> 
> GRASS:~ > s.in.ascii d=3 sites=site2
> -120.098 33.987 23.45 %99.88
> end
> 
> GRASS:~ > s.in.ascii d=2 sites=site4
> 900.234 67.34 #1 "my string"
> end
> 
> </example>
> 
> --
> /bin/sh ~/.signature:
> Command not found
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'