date:20150717

Re: [GRASS-dev] [GRASS GIS] #2624: r.horizon problem in Windows (horizon_zud)

2015-07-17 Thread GRASS GIS

#2624: r.horizon problem in Windows (horizon_zud)
-+-
  Reporter:  rorschach   |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.1
 Component:  LibGIS  |Version:  7.0.0
Resolution:  |   Keywords:  r.horizon, r.sun, wingrass,
   CPU:  |  basename.c
  Unspecified|   Platform:  Unspecified
-+-
Changes (by andrei):

 * cc: andrei (added)
 * keywords:  r.horizon, r.sun, wingrass => r.horizon, r.sun, wingrass,
 basename.c
 * component:  Raster => LibGIS
 * platform:  MSWindows 8 => Unspecified
 * priority:  normal => major


Comment:

 this has its origin in grass/trunk/lib/gis/basename.c on lines:

 {{{
 91  sprintf(intfmt, "%%0%zud", ndigits);
 96  sprintf(decfmt, "_%%0%zud", ndecimals);
 }}}

 My C skills are very rusty and I would not like to make things worse, but
 I think that these two lines have to be changed to:


 {{{
 91  sprintf(intfmt, "%%0%u", ndigits);
 96  sprintf(decfmt, "_%%0%u", ndecimals);
 }}}

 and the problem would be solved. I'm not that good with old-school format
 specifiers, but I have internet and there's no %z format specifier.

 This problem appeared after this discussion
 [[https://trac.osgeo.org/grass/ticket/2136|2136]] that decided that all
 basename functionality should be moved to this file.

 This makes every module that outputs multiple files with file names like
 basename_001, basename_002, etc (and uses basename.c), unusable, since all
 output files will be named ''basename_zud'' and each will overwrite the
 previous result. In the end these modules will only leave the last result
 as final output.

 In my opinion this is at least a major bug, if not critical since it can
 cause loss of data if the overwrite option is used.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Re: [gdal-dev] Setting NODATA to -nan

2015-07-17 Thread Yann Chemin

Hi,

it might be that some communication improvement from GRASS-GDAL could be
done?

is there a clear NODATA/NAN definition understood within GDAL that we could
use within r.out.gdal as a target NODATA value whenever anything than a
number is used (i.e. NaN, nan, -nan, helloworld, mynameisbee, etc.)

typically MODIS users are used to -28768 and similar "standard" NODATA
numbers, but that maybe another story.

0.01c



On Thu, Jul 16, 2015 at 6:34 PM Markus Neteler  wrote:

> Hi devs,
>
> FWD of an issue with r.out.gdal in G7. Any ideas?
>
> Markus
>
>
> -- Forwarded message --
> From: Even Rouault 
> Date: Thu, Jul 16, 2015 at 2:07 AM
> Subject: Fwd: Re: [gdal-dev] Setting NODATA to -nan
> To: nete...@osgeo.org
>
>
> Hi Markus,
>
> Below you'll find the original report about what discussed on the way to
> the
> party tonight, and then my analysis. The GDAL ticket with the dataset is
> https://trac.osgeo.org/gdal/ticket/6036
>
> I'm not sure there's really an issue in practice on the GDAL side. It is
> just
> that dealing with nan is odd to anybody (and the way Windows and Linux
> displays nan as a string is different).
>
> Even
>
>
>
>
> [gdal-dev] Setting NODATA to -nan
> From:   Homme Zwaagstra 
> To: gdal-dev 
> Date:   Yesterday 11:21:54
> Hello,
>
> I've got the following raster exported from GRASS using `r.out.gdal`:
>
> gdalinfo ppp-2015.tif
> Driver: GTiff/GeoTIFF
> Files: ppp-2015.tif
> ppp-2015.tif.aux.xml
> Size is 432017, 216009
> Coordinate System is:
> GEOGCS["WGS 84",
>  DATUM["WGS_1984",
>  SPHEROID["WGS 84",6378137,298.257223563,
>  AUTHORITY["EPSG","7030"]],
>  AUTHORITY["EPSG","6326"]],
>  PRIMEM["Greenwich",0],
>  UNIT["degree",0.0174532925199433],
>  AUTHORITY["EPSG","4326"]]
> Origin = (-180.000,90.000)
> Pixel Size = (0.000833300541414,-0.000833298612558)
> Metadata:
>AREA_OR_POINT=Area
> Image Structure Metadata:
>COMPRESSION=DEFLATE
>INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
> Lower Left  (-180.000, -90.000) (180d 0' 0.00"W, 90d 0' 0.00"S)
> Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
> Lower Right ( 180.000, -90.000) (180d 0' 0.00"E, 90d 0' 0.00"S)
> Center  (   0.000,   0.000) (  0d 0' 0.01"E,  0d 0' 0.01"N)
> Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
>NoData Value=nan
>Metadata:
>  COLOR_TABLE_RULES_COUNT=5
>  COLOR_TABLE_RULE_RGB_0=0.00e+00 1.681282e+03 255 255 0 0 255 0
>  COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255
>  COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255
>  COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255
>  COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0
>  Generated_with=GRASS GIS 7.0.0
>
> As you can see the NoData is set to `nan`.  However, within the data it is
> actually `-nan`:
>
> gdallocationinfo ppp-2015.tif -wgs84 42.0776 30.9305
> Report:
>Location: (266503P,70886L)
>Band 1:
>  Value: -nan
>
> I have tried to force the NoData to `-nan` as follows but with no joy:
>
> gdal_translate -a_nodata '-nan' -of VRT ppp-2015.tif ppp-2015.vrt
>
> gdalinfo ppp-2015.vrt
> Driver: VRT/Virtual Raster
> Files: ppp-2015.vrt
> /data/data/ppp_v2c_2015/ppp-2015.tif
> Size is 432017, 216009
> Coordinate System is:
> GEOGCS["WGS 84",
>  DATUM["WGS_1984",
>  SPHEROID["WGS 84",6378137,298.257223563,
>  AUTHORITY["EPSG","7030"]],
>  AUTHORITY["EPSG","6326"]],
>  PRIMEM["Greenwich",0],
>  UNIT["degree",0.0174532925199433],
>  AUTHORITY["EPSG","4326"]]
> Origin = (-180.000,90.000)
> Pixel Size = (0.000833300541414,-0.000833298612558)
> Metadata:
>AREA_OR_POINT=Area
> Image Structure Metadata:
>INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
> Lower Left  (-180.000, -90.000) (180d 0' 0.00"W, 90d 0' 0.00"S)
> Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
> Lower Right ( 180.000, -90.000) (180d 0' 0.00"E, 90d 0' 0.00"S)
> Center  (   0.000,   0.000) (  0d 0' 0.01"E,  0d 0' 0.01"N)
> Band 1 Block=128x128 Type=Float32, ColorInterp=Gray
>NoData Value=nan
>Metadata:
>  COLOR_TABLE_RULES_COUNT=5
>  COLOR_TABLE_RULE_RGB_0=0.00e+00 1.681282e+03 255 255 0 0 255 0
>  COLOR_TABLE_RULE_RGB_1=1.681282e+03 3.362563e+03 0 255 0 0 255 255
>  COLOR_TABLE_RULE_RGB_2=3.362563e+03 5.043845e+03 0 255 255 0 0 255
>  COLOR_TABLE_RULE_RGB_3=5.043845e+03 6.725127e+03 0 0 255 255 0 255
>  COLOR_TABLE_RULE_RGB_4=6.725127e+03 8.406408e+03 255 0 255 255 0 0
>  Generated_with=GRASS GIS 7.0.0
>
> Even editing the VRT to contain `-nan` yields a
> positive nan value in gdalinfo.
>
> This looks like it might b

Re: [GRASS-dev] [GRASS GIS] #335: export floats and doubles with correct precision

2015-07-17 Thread GRASS GIS

#335: export floats and doubles with correct precision
---+--
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  task  | Status:  new
  Priority:  critical  |  Milestone:  6.4.6
 Component:  Default   |Version:  svn-develbranch6
Resolution:|   Keywords:  precision
   CPU:  All   |   Platform:  All
---+--

Comment (by mlennert):

 This is probably relevant for g7 as well, no ?

 So probably the Version and Milestone settings should be pushed up to
 trunk in order to raise the visibility of this issue.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:9 martinl]:
 > Replying to [comment:8 mlennert]:
 > > Replying to [comment:7 martinl]:
 > > > Probably we could have a new addon module called `v.convert.g6`
 doing conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?
 > >
 > > might be a nice convenience module. But just v.db.connect won't be
 enough if you want to change from dbf to sqlite. The easiest would
 probably be db.connect + g.copy + g.rename, or something like that.
 >
 > not really, see (1)

 Right, forgot about v.db.reconnect.all.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] Batch modify: #335, #943, #2037, #2392, #2393, #2430, ...

2015-07-17 Thread Moritz Lennert


On 17/07/15 09:13, Martin Landa wrote:

Hi,

I wanted to ask you what is our policy when closing the milestone,
should we move milestone for such ticket the next milestone as it has
been done in this case?


Sounds good to me, although I have the feeling that there are some bugs 
which just move from milestone to milestone without much attention.


Don't know if anyone has looked at these old bugs. For example: I just 
closed #337 as the fix been in trunk for 7 years !


But as long as we don't have the man power to go through all these bugs, 
I agree that pushing up the milestone is the least bad solution.


Moritz



Thanks, Martin

2015-07-16 19:01 GMT+02:00 GRASS GIS :

Batch modification to #335, #943, #2037, #2392, #2393, #2430, #2477, #2558, 
#72, #494, #1071, #1283, #1397, #1440, #1445, #2125, #2530, #2550, #337, #1318, 
#1323, #1325, #1405, #1430, #1490, #1508, #1510, #1594, #1599, #1631, #1664, 
#1790, #1924, #1990, #2035, #2095, #2310, #2352, #2367, #2413, #2419, #2492, 
#2545, #2599, #2607, #2610, #2635, #2667, #2688, #141, #1327, #1635 by martinl:
milestone to 6.4.6

--
Tickets URL: 

GRASS GIS 








___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #337: r.resamp.stats - enable -w flag for min max sampling

2015-07-17 Thread GRASS GIS

#337: r.resamp.stats - enable -w flag for min max sampling
--+--
  Reporter:  dickeya  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  6.4.6
 Component:  Raster   |Version:  svn-develbranch6
Resolution:  fixed|   Keywords:  r.resamp.stats
   CPU:  All  |   Platform:  Unspecified
--+--
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 As the changes have been in both g7 and g6 for years, and there have been
 no complaints, I'm closing this bug as fixed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 Replying to [comment:8 mlennert]:
 > Replying to [comment:7 martinl]:
 > > Probably we could have a new addon module called `v.convert.g6` doing
 conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?
 >
 > might be a nice convenience module. But just v.db.connect won't be
 enough if you want to change from dbf to sqlite. The easiest would
 probably be db.connect + g.copy + g.rename, or something like that.

 not really, see (1)

 (1)
 http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:7 martinl]:
 > Probably we could have a new addon module called `v.convert.g6` doing
 conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

 might be a nice convenience module. But just v.db.connect won't be enough
 if you want to change from dbf to sqlite. The easiest would probably be
 db.connect + g.copy + g.rename, or something like that.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 Probably we could have a new addon module called `v.convert.g6` doing
 conversion from GRASS 6 to GRASS 7 (v.build + v.db.connect)?

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 Replying to [comment:5 mlennert]:
 > > I modified the message in r65600 to mention `v.build/v.build.all`. If
 no objection I will do backport to relbr70.
 >
 > +1

 done in r65601

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:4 martinl]:
 > Replying to [comment:3 mlennert]:
 > > Whatever the discussion, I don't think this is a "critical" bug. The
 message is clear, the solution (v.build) is clear and so it's more of a
 question of convenience.
 >
 > Right, decreasing the priority.
 >
 > > As a first gut reaction, I would say don't do anything this
 fundamental "behind the user's back". I would think that most users won't
 switch wildly between grass6 and grass7 on the same data. If they do,
 v.build and v.build.all exist to help them.
 >
 > I modified the message in r65600 to mention `v.build/v.build.all`. If no
 objection I will do backport to relbr70.

 +1

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

2015-07-17 Thread GRASS GIS

#2386: wxGUI: check for old vector topology format
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.0.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  v.build.all
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * priority:  critical => normal


Comment:

 Replying to [comment:3 mlennert]:
 > Whatever the discussion, I don't think this is a "critical" bug. The
 message is clear, the solution (v.build) is clear and so it's more of a
 question of convenience.

 Right, decreasing the priority.

 > As a first gut reaction, I would say don't do anything this fundamental
 "behind the user's back". I would think that most users won't switch
 wildly between grass6 and grass7 on the same data. If they do, v.build and
 v.build.all exist to help them.

 I modified the message in r65600 to mention `v.build/v.build.all`. If no
 objection I will do backport to relbr70.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] Batch modify: #335, #943, #2037, #2392, #2393, #2430, ...

2015-07-17 Thread Martin Landa

Hi,

I wanted to ask you what is our policy when closing the milestone,
should we move milestone for such ticket the next milestone as it has
been done in this case?

Thanks, Martin

2015-07-16 19:01 GMT+02:00 GRASS GIS :
> Batch modification to #335, #943, #2037, #2392, #2393, #2430, #2477, #2558, 
> #72, #494, #1071, #1283, #1397, #1440, #1445, #2125, #2530, #2550, #337, 
> #1318, #1323, #1325, #1405, #1430, #1490, #1508, #1510, #1594, #1599, #1631, 
> #1664, #1790, #1924, #1990, #2035, #2095, #2310, #2352, #2367, #2413, #2419, 
> #2492, #2545, #2599, #2607, #2610, #2635, #2667, #2688, #141, #1327, #1635 by 
> martinl:
> milestone to 6.4.6
>
> --
> Tickets URL: 
> 
> GRASS GIS 
>



-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2624: r.horizon problem in Windows (horizon_zud)

Re: [GRASS-dev] Fwd: Re: [gdal-dev] Setting NODATA to -nan

Re: [GRASS-dev] [GRASS GIS] #335: export floats and doubles with correct precision

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] Batch modify: #335, #943, #2037, #2392, #2393, #2430, ...

Re: [GRASS-dev] [GRASS GIS] #337: r.resamp.stats - enable -w flag for min max sampling

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] #2386: wxGUI: check for old vector topology format

Re: [GRASS-dev] [GRASS GIS] Batch modify: #335, #943, #2037, #2392, #2393, #2430, ...

13 matches

Site Navigation

Mail list logo

Footer information