Re: [GRASS-dev] r.in.xyz: really big ints

Hamish: > > Is it as simple as replacing printf %d with %u ?? (seems to work) Glynn: > Yes. ok, done in SVN r33163,4. I went with unsigned longs instead of floats for the counts. This means 32bit users with datasets > 5 billion points will get garbage counts in the summary message. I am willing

Re: [GRASS-dev] r.in.xyz: really big ints

Hamish wrote: > line: at one point I use if(line % 1 == 0), which I suspect would > prefer ints over FPs, and I'd like to keep that. The % operator doesn't work for FP; you can to use fmod() instead. > G_alloc(rows*cols*sizeof(CELL)) is another thing, but unrelated to the > filesize so a ma

Re: [GRASS-dev] r.in.xyz: really big ints

variables in the main loop that need looking at: line, estimated_lines, count, count_total line: at one point I use if(line % 1 == 0), which I suspect would prefer ints over FPs, and I'd like to keep that. estimates_lines: is set to -1 when can't be estimated (data from stdin) and thus is sa

[GRASS-dev] Re: [GRASS GIS] #264: error querying a layer being edited

#264: error querying a layer being edited ---+ Reporter: msieczka | Owner: martinl Type: defect| Status: assigned Priority: major | Milestone: 6.4.0 Component:

Re: [GRASS-dev] r.in.xyz: really big ints

Andrew Danner wrote: > >> Apparently `wc` on their system can count higher than 2^31, can we? > >> > >> Is it as simple as replacing printf %d with %u ?? (seems to work) > >> In that case should the variable be defined as "unsigned int" for > >> correctness? (%u seems to work correctly with plain

Re: [GRASS-dev] r.in.xyz: really big ints

Hamish wrote: > a user has just successfully imported a 92GB LIDAR data file with r.in.xyz > (2.4 billion data points; 4.5hrs). This has exposed a cosmetic bug, the > number of points processed is reported to the user as -1871174186. > > The raster output is fine AFAIK, but the broken status mes

Re: [GRASS-dev] r.in.xyz: really big ints

Helena Mitasova wrote: On Aug 29, 2008, at 3:19 AM, Hamish wrote: Hi, a user has just successfully imported a 92GB LIDAR data file with r.in.xyz (2.4 billion data points; 4.5hrs). This has exposed a cosmetic bug, the number of points processed is reported to the user as -1871174186. The ra

Re: [GRASS-dev] r.in.xyz: really big ints

On Aug 29, 2008, at 3:19 AM, Hamish wrote: Hi, a user has just successfully imported a 92GB LIDAR data file with r.in.xyz (2.4 billion data points; 4.5hrs). This has exposed a cosmetic bug, the number of points processed is reported to the user as -1871174186. The raster output is fine A

[GRASS-dev] Re: [GRASS-user] weird dbf file in GRASS 6.4

Maciek, > > You used the '-v' switch which means: "Use raster values as categories > instead of unique sequence". Thus, it is normal that the output table > has only that many rows, as many unique cell values were there in the > input raster map. Multiple polygons are linked to the same table row

[GRASS-dev] Re: [GRASS GIS] #267: v.what returns "Line:" attribute for points and centroids

#267: v.what returns "Line:" attribute for points and centroids ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: closed Priority: major | M

[GRASS-dev] r.in.xyz: really big ints

Hi, a user has just successfully imported a 92GB LIDAR data file with r.in.xyz (2.4 billion data points; 4.5hrs). This has exposed a cosmetic bug, the number of points processed is reported to the user as -1871174186. The raster output is fine AFAIK, but the broken status message ain't a good loo

[GRASS-dev] Re: [GRASS GIS] #268: the "command layer" in wxGUI does not work

#268: the "command layer" in wxGUI does not work ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: closed Priority: major | Milestone: 6.4.