Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
Glynn Clements wrote: Markus Metz wrote: OK, but I have tested r.out.gdal with type = GDT_Int32 and nodata = 0x8000. Same result: NULL cells become -2147483648 but the nodata value in the metadata says 2147483648 (gdalinfo on the export output), Yes. I know. Running r.out.gdal ... nodata=0x8000 is misinterpreting what I was saying, as r.out.gdal parses nodata= as a floating-point value. I'm talking about using (GDT_Int32)0x8000 (i.e. -2^31) I think I slowly begin to understand. You suggest to use (GDT_Int32)0x8000 for both the GDAL metadata info and the GDAL raster data although GDAL metadata nodata is double? When using a default nodata value, what I want to get in the exported map is identical values for the metadata nodata value and the value assigned to NULL cells. GDAL metadata nodata value is always double (GDALSetRasterNoDataValue()), the value assigned to NULL cells is of the selected GDAL datatype. So 0x8000 for GDT_Int32 will be 2^31 in metadata and -2^31 in the data if passed as such to the corresponding GDAL functions, (double ) 0x8000 for metadata info and (GDT_Int32) 0x8000 for raster data. or (GDT_UInt32)0x8000 (i.e. +2^31) as appropriate for the destination type. I was assuming that not only CELL, but also FCELL and DCELL maps may be exported as GDT_UInt32. Then 2^31 can occur in the raster to be exported. Actually, I was assuming that any GRASS raster type may be exported as any GDAL data type. For r.out.gdal, there was discussion about not to override user options and instead issue an error or a warning (going for error now) that the nodata value is out of range. This isn't about overriding user options, but interpreting them correctly. Close to the module knows better which is not desirable according to Dylan and Moritz. No, the opposite. Writing code which does what the user asks for rather than doing something else which is easier to code. What if the user asks for a nodata value to be out of range, i.e. really wants it to be out of range, leading to a mismatch between the nodata value in the metadata and the value assigned to NULL cells in the GDAL export? I understood that this was requested to be possible. If r.out.gdal should support out of range nodata values, and the nodata value is read with atof(), 2^31 should stay 2^31and not be cast to -2^31. The GUI description of the nodata option says that it is of type float (actually it's a double), i.e. suggesting that any value that is representable as floating point is ok. That's a limitation of the parser. If the input is CELL, then the nodata value which the input data uses isn't any kind of float. It might be more correct to have separate int/float nodata options. OTOH, GDAL's no-data value is always a double, even for integer data. I would rather stick to GDAL's method of handling nodata options and try to mimic that in r.out.gdal. OTOH, reading as FP allows you to specify +2^31 as the nodata value when exporting CELL as UInt32. Maybe it would be better to read as double then cast to the destination type. Hmm, then it would be no longer possible to have an out-of-range nodata value in the metadata. I would support that solution, but it was explicitly requested to obey all user options when the -f flag is used, also writing the nodata value as it is to the metadata. It is then up to the user to figure out what happened to the NULL cells, assuming that the user knows what happens when using the -f flag. I can see some point to that, but may be confusing for the user, who may assume that they're talking about the data's no-data value when they're actually specifying GDAL's no-data value. That's why there are warnings if there will be a mismatch between the GDAL metadata nodata value and the GDAL raster nodata value (out of range test). And having this mismatch is only possible with the -f flag, when forcing r.out.gdal to use exactly the given parameters and options. The GDAL API documentation says To clear the nodata value, just set it with an out of range value. This is currently possible with the -f flag, but r.out.gdal then does not give any information on what value is assigned to NULL cells, only what nodata value is written to the metadata. Even so, 0x8000 is still the ideal value for exporting CELL data to either UInt32 or Int32. You just have to pick the correct interpretation of it (unsigned int or signed int respectively). The current as well as previous policy of r.out.gdal is to not to interpret the nodata value. It is written as is (currently double) to metadata, same like e.g. gdal_translate -a_nodata behaves. It doesn't have any choice about interpreting it. nodataopt-answer is a char*, while GDALSetRasterNoDataValue() expects a double. There are several ways to convert a char* to a double; atof() may be the simplest to implement, but is it the most correct? No idea. If you can't think if a more correct way,
[GRASS-dev] Re: [GRASS GIS] #554: wxGUI location wizard: Search in description with 0 hits
#554: wxGUI location wizard: Search in description with 0 hits ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Resolution:|Keywords: location wizard Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by cnielsen): could we release also weekly updated native installer? - to enable users to test recently fixed bugs? I'm having some hardware issues right now (my laptop screen died). I'll release another wingrass installer when I get this resolved. Sorry for the inconvenience. However, the files and steps required (recently updated) to make an installer are in the source code if someone else wants to give it a try in the meantime. -Colin -- Ticket URL: http://trac.osgeo.org/grass/ticket/554#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [Fwd: RE: [GRASS GIS] #562: patch proposal: do not show delimiters for empty labels in case of multiple cats per feature]
[Posting this for Adam] Original Message Subject:RE: [GRASS GIS] #562: patch proposal: do not show delimiters for empty labels in case of multiple cats per feature Date: Sat, 18 Apr 2009 07:25:00 -0700 From: Adam Dershowitz adershow...@exponent.com To: mlenn...@club.worldonline.be References: 042.45ad6fb25e89cb830d20b5d08c2a4...@osgeo.org Moritz, Yes, this is exactly what I had in mind. I will watch for any discussions. I have two other related suggestions. 1) I would love an option to change the delimiter character from / to something else. That is fine for a default, but being able to use \n would be great also. 2) I found that v.label behaves differently from d.vect. v.label actually just displays the first value, and no delimiter or other data. I would suggest a patch to have it create labels that are the same as d.vect. Thoughts? The email below went to Bcc so I am just sending this to you, but feel free to put it on any lists that you feel are appropriate for such discussions. Thanks much for following up on this. --Adam -Original Message- From: GRASS GIS [mailto:t...@osgeo.org] Sent: Sat 4/18/2009 5:54 AM To: undisclosed-recipients Subject: [GRASS GIS] #562: patch proposal: do not show delimiters for empty labels in case of multiple cats per feature #562: patch proposal: do not show delimiters for empty labels in case of multiple cats per feature -+-- Reporter: mlennert | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: default | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- The attached patch (against svn7) slightly modifies d.vect in that it only displays delimiters (/) for those category values where label values actually exist. I attache two screenshots to make clearer what the patch does. I would just submit the patch without posting, but I'm not sure if some people find it important to see the existance of null values for some categories. However, if no one objects, I'll commit. Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/562 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #507: CSV output option for r.report
On Wed, Apr 15, 2009 at 11:02 PM, GRASS GIS t...@osgeo.org wrote: #507: CSV output option for r.report --+- Reporter: dylan | Owner: grass-...@lists.osgeo.org Type: enhancement | Status: new Priority: minor | Milestone: 6.5.0 Component: Raster | Version: svn-develbranch6 Resolution: | Keywords: r.report Platform: All | Cpu: All --+- Comment (by hamish): So does r.stats fill the need, or do you need to convert units of measure? Hamish r.stats should be sufficient. Thanks. Dylan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: Re: [GRASS-dev] g_parser() ERROR
I wonder if those standard schemes should be hardcoded in a *.h file, with an option to chose one of them by name or custom with an optional and add/rename a new option called rules= to load the custom file? then less work to specify path to the *.dat file... Yes Hamish, I'm agree! but (as you can see) I'm not a C guru and the only solution I found is a *.h file wit n array fore storage all texture coordinate, now in *.dat file. This isn' t a very smart solution . I'm looking for examples in other grass module but without results. Could you show me any solution? also, what should the two sand and clay maps look like? percent/fraction makeup of soil for each cell? sand and clas has to be in 0-1 range. I will indicate in option module Thanks Hamish, sincerely! gianluca ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: Re: [GRASS-dev] g_parser() ERROR
I mean sand and class has to be in 0-100 range. I will indicate in option module Thanks Hamish, sincerely! gianluca ___ grass-dev mailing list grass- d...@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] Google SoC
Hi all, let me to congratulate to the students with the accepted proposals [1]. I hope that those who not succeed will be successful next year. I am looking forward to see results of the GRASS-related projects. Best regards, Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
Markus Metz wrote: OK, but I have tested r.out.gdal with type = GDT_Int32 and nodata = 0x8000. Same result: NULL cells become -2147483648 but the nodata value in the metadata says 2147483648 (gdalinfo on the export output), Yes. I know. Running r.out.gdal ... nodata=0x8000 is misinterpreting what I was saying, as r.out.gdal parses nodata= as a floating-point value. I'm talking about using (GDT_Int32)0x8000 (i.e. -2^31) I think I slowly begin to understand. You suggest to use (GDT_Int32)0x8000 for both the GDAL metadata info and the GDAL raster data although GDAL metadata nodata is double? Yes; for the latter, the value would be: (double) (GDT_Int32) 0x8000 IOW, -2147483648.0. Note that this isn't the same as atof(0x8000), which would be positive. When using a default nodata value, what I want to get in the exported map is identical values for the metadata nodata value and the value assigned to NULL cells. GDAL metadata nodata value is always double (GDALSetRasterNoDataValue()), the value assigned to NULL cells is of the selected GDAL datatype. So 0x8000 for GDT_Int32 will be 2^31 in metadata and -2^31 in the data if passed as such to the corresponding GDAL functions, (double ) 0x8000 for metadata info and (GDT_Int32) 0x8000 for raster data. That depends upon how you interpret 0x8000. (double) (GDT_Int32) 0x8000 is equal to -2147483648.0, while atof(0x8000) is equal to +2147483648.0. GDT_Int32 itself cannot represent +2^31. When writing CELL data as GDT_Int32, the default null value should be (GDT_Int32) 0x8000, as that's the only value which cannot occur in the source data. The GDAL no-data value should be that value cast to a double, i.e.: (double) (GDT_Int32) 0x8000 or: atof(-0x8000) or: -2147483648.0 or any other permutation which produces the same double value. or (GDT_UInt32)0x8000 (i.e. +2^31) as appropriate for the destination type. I was assuming that not only CELL, but also FCELL and DCELL maps may be exported as GDT_UInt32. Then 2^31 can occur in the raster to be exported. Actually, I was assuming that any GRASS raster type may be exported as any GDAL data type. Right. But exporting FCELL or DCELL as GDT_UInt32 is inherently lossy. For DCELL, every possible GDT_UInt32 value may occur in the source data, so there isn't any ideal default no-data value. For r.out.gdal, there was discussion about not to override user options and instead issue an error or a warning (going for error now) that the nodata value is out of range. This isn't about overriding user options, but interpreting them correctly. Close to the module knows better which is not desirable according to Dylan and Moritz. No, the opposite. Writing code which does what the user asks for rather than doing something else which is easier to code. What if the user asks for a nodata value to be out of range, i.e. really wants it to be out of range, leading to a mismatch between the nodata value in the metadata and the value assigned to NULL cells in the GDAL export? I understood that this was requested to be possible. Hmm. To allow that, you can't cast to the source or destination type, so the user will have to understand the conversion issues even if they never use an out-of-range value. Ultimately, its either usability or flexibility. If r.out.gdal should support out of range nodata values, and the nodata value is read with atof(), 2^31 should stay 2^31and not be cast to -2^31. The GUI description of the nodata option says that it is of type float (actually it's a double), i.e. suggesting that any value that is representable as floating point is ok. That's a limitation of the parser. If the input is CELL, then the nodata value which the input data uses isn't any kind of float. It might be more correct to have separate int/float nodata options. OTOH, GDAL's no-data value is always a double, even for integer data. I would rather stick to GDAL's method of handling nodata options and try to mimic that in r.out.gdal. I don't have any preference, although I suspect that users will regularly get bitten by the conversion issues. OTOH, reading as FP allows you to specify +2^31 as the nodata value when exporting CELL as UInt32. Maybe it would be better to read as double then cast to the destination type. Hmm, then it would be no longer possible to have an out-of-range nodata value in the metadata. I would support that solution, but it was explicitly requested to obey all user options when the -f flag is used, also writing the nodata value as it is to the metadata. It is then up to the user to figure out what happened to the NULL cells, assuming that the user knows what happens when using the -f flag. I can see some point to that, but may be confusing for the user,
[GRASS-dev] [GRASS GIS] #565: r.colors: glibc double free error with -ae
#565: r.colors: glibc double free error with -ae
--+-
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: minor | Milestone: 6.5.0
Component: Raster| Version: svn-develbranch6
Keywords: r.colors |Platform: Linux
Cpu: x86-32|
--+-
Hi,
I'm unable to recreate it right now, but yesterday I was consistently
getting a rather ugly `*** glibc ...` error which said something about an
invalid double free().
looked rather worse than a standard segfault and not something I've seen
much of before. this is on the 20 month old version of Debian/stable and I
haven't changed anything so expect glibc versions is as stable well
tested as it ever could be.
the command line looked like
{{{
r.colors map1 color=bcyr -ae
}}}
the input map is gone now and I've changed r.surf.volcano enough
that I don't get it anymore, but it can be assumed that there were
0.0s in the map. (-g blocks 0s but -a doesn't?)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/565
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
