Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
#2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account +--- Reporter: nikosa | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 7.0.0 Component: Raster | Version: unspecified Keywords: r.recode, DCELL, CELL, rules, needinfo |Platform: Unspecified Cpu: Unspecified | +--- Comment(by lucadelu): Replying to [comment:15 annakrat]: Replying to [comment:12 annakrat]: Otherwise this ticket should be solved once r62518 is backported. Backported in r62557. Could we close this ticket? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2053#comment:16 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] Error in GRASS GIS 7.0 database
Hi List, I was running two commands, listed below, simultaneously in a Linux environment. 1. r.mapcalc was running as a python mulitprocess command the background and 2. r.what was running in the foreground to extract some pixel values for several rast images. I'm not sure what happened or my GRASS GIS database got corrupt. Because whenever I run any command, I get the following error: ERROR: Duplicate t-b resolution field And because of the error above, all my background processes came to halt. Any help or suggestion, will highly be appreciated. Thanks in advance. Erick ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Comment(by nikosa): This is still unresolved. I did my part for option (c) a year ago, launching an open and direct discussion with a Digital Globe's representative salesman n Europe. No reply in the end. I still feel that the default import scheme shouldn't take red, green and blue for granted. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: FOSDEM 2015
On 21/11/14 10:23, Markus Neteler wrote: On Thu, Nov 20, 2014 at 10:10 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 17/11/14 15:45, Moritz Lennert wrote: As you can see below, Margherita contacted me concerning a GRASS presentation at the geospatial devromm foreseen for the first time at the upcoming FOSDEM. (here the conf link: https://fosdem.org/2015/ - Brussels / 31 January 1 February 2015) I can present something, but would like to know 1) if other devs are planning to attend and if yes, if they were planning to present anything I would be interested to go. Great ! 2) which themes you think would be the most interesting to present from a GRASS perspective Currently, I've been thinking about two themes: - The obvious what's new in GRASS 7, but I'm not sure that this is the most appropriate for the mostly developper crowd present at a FOSDEM. I have never participated but I could offer talks at various tech level :) - A focus on the different APIs in GRASS from C to pygrass to grass.script, explaining structure and use cases of each. Any other ideas ? - GRASS GIS and HPC (satellite data processing) If you want to go for one of the two themes, you are probably better qualified than me to present them. But I am willing to help where I can. Margherita, I don't know how many slots there are, but I guess that one for the GRASS project is enough ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
#2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account +--- Reporter: nikosa | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 7.0.0 Component: Raster | Version: unspecified Keywords: r.recode, DCELL, CELL, rules, needinfo |Platform: Unspecified Cpu: Unspecified | +--- Comment(by nikosa): Works for me. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2053#comment:17 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error in GRASS GIS 7.0 database
Erick Opiyo wrote: Hi List, I was running two commands, listed below, simultaneously in a Linux environment. 1. r.mapcalc was running as a python mulitprocess command the background and 2. r.what was running in the foreground to extract some pixel values for several rast images. I'm not sure what happened or my GRASS GIS database got corrupt. Because whenever I run any command, I get the following error: ERROR: Duplicate t-b resolution field What's g.region saying about? Does resetting the t-b resolution help? Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RFC4 discussion call
Dear all, as we are closer and closer to GRASS 7 release I would like to open discussion related to Release procedure - RFC4 [1]. Ideally (I would say) it would make sense to find a way how accept such procedure before we start with GRASS RCs... Thanks for your feedback in advance! Martin [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): related to attachment:prefix_to_basename.diff I don't fully understand why to define key 'output' for basename options. I thought that `G_OPT_BASENAME_OUTPUT` will have default key like 'basename_output' or 'output_basename' (better for backward compatibility). Similarly `G_OPT_BASENAME_INPUT` 'input_basename'. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:18 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
On 24/11/14 14:38, Martin Landa wrote: Dear all, as we are closer and closer to GRASS 7 release I would like to open discussion related to Release procedure - RFC4 [1]. Ideally (I would say) it would make sense to find a way how accept such procedure before we start with GRASS RCs... Thanks for your feedback in advance! Martin [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Rereading it I found parts that didn't seem clear, so I reordered the sentences slightly to make the meaning clearer. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory +--- Reporter: martinl | Owner: grass-dev@… Type: task| Status: new Priority: critical| Milestone: 7.1.0 Component: Projections/Datums | Version: unspecified Keywords: gdal|Platform: Unspecified Cpu: Unspecified | +--- Comment(by martinl): For record list of affected files: * coordinate_axis.csv * ellipsoid.csv * gcs.csv * gcs.override.csv * gdal_datum.csv * gt_datum.csv * gt_ellips.csv * pcs.csv * pcs.override.csv * prime_meridian.csv * projop_wparm.csv * stateplane.csv * unit_of_measure.csv -- Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
#2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account --+- Reporter: nikosa | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 7.0.0 Component: Raster | Version: unspecified Resolution: fixed|Keywords: r.recode, DCELL, CELL, rules, needinfo Platform: Unspecified | Cpu: Unspecified --+- Changes (by mlennert): * status: new = closed * resolution: = fixed Comment: Works for me as well, so closing. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2053#comment:18 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: FOSDEM 2015
Hi, On Mon, Nov 24, 2014 at 2:19 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/11/14 10:23, Markus Neteler wrote: On Thu, Nov 20, 2014 at 10:10 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 17/11/14 15:45, Moritz Lennert wrote: As you can see below, Margherita contacted me concerning a GRASS presentation at the geospatial devromm foreseen for the first time at the upcoming FOSDEM. (here the conf link: https://fosdem.org/2015/ - Brussels / 31 January 1 February 2015) I can present something, but would like to know 1) if other devs are planning to attend and if yes, if they were planning to present anything I would be interested to go. Great ! 2) which themes you think would be the most interesting to present from a GRASS perspective Currently, I've been thinking about two themes: - The obvious what's new in GRASS 7, but I'm not sure that this is the most appropriate for the mostly developper crowd present at a FOSDEM. I have never participated but I could offer talks at various tech level :) - A focus on the different APIs in GRASS from C to pygrass to grass.script, explaining structure and use cases of each. Any other ideas ? - GRASS GIS and HPC (satellite data processing) If you want to go for one of the two themes, you are probably better qualified than me to present them. But I am willing to help where I can. Margherita, I don't know how many slots there are, but I guess that one for the GRASS project is enough ? It is great to have you both there! Yes I think that dedicating one slot to the grass project will make the conference more balanced respect to other projects as well. Does it sound reasonable to you to share one slot? Regarding the time available for each slot, I can't say nothing yet, because we will try to balance the time according to all the proposals that are coming. I'll keep you posted. Thank you! -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: FOSDEM 2015
On 24/11/14 15:38, Margherita Di Leo wrote: Hi, On Mon, Nov 24, 2014 at 2:19 PM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: On 21/11/14 10:23, Markus Neteler wrote: On Thu, Nov 20, 2014 at 10:10 AM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: On 17/11/14 15:45, Moritz Lennert wrote: As you can see below, Margherita contacted me concerning a GRASS presentation at the geospatial devromm foreseen for the first time at the upcoming FOSDEM. (here the conf link: https://fosdem.org/2015/ - Brussels / 31 January 1 February 2015) I can present something, but would like to know 1) if other devs are planning to attend and if yes, if they were planning to present anything I would be interested to go. Great ! 2) which themes you think would be the most interesting to present from a GRASS perspective Currently, I've been thinking about two themes: - The obvious what's new in GRASS 7, but I'm not sure that this is the most appropriate for the mostly developper crowd present at a FOSDEM. I have never participated but I could offer talks at various tech level :) - A focus on the different APIs in GRASS from C to pygrass to grass.script, explaining structure and use cases of each. Any other ideas ? - GRASS GIS and HPC (satellite data processing) If you want to go for one of the two themes, you are probably better qualified than me to present them. But I am willing to help where I can. Margherita, I don't know how many slots there are, but I guess that one for the GRASS project is enough ? It is great to have you both there! Yes I think that dedicating one slot to the grass project will make the conference more balanced respect to other projects as well. Does it sound reasonable to you to share one slot? Sure. As I said, if Markus comes and presents I think he's more competent than I am to do so, but I'm willing to support in any way. Moritz P.S. I propose that we move the discussion on details off-list again, but if anyone else is interested don't hesitate to say so. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory
+---
Reporter: martinl | Owner: grass-dev@…
Type: task| Status: new
Priority: critical| Milestone: 7.1.0
Component: Projections/Datums | Version: unspecified
Keywords: gdal|Platform: Unspecified
Cpu: Unspecified |
+---
Comment(by hellik):
Replying to [ticket:2456 martinl]:
Currently GRASS contains copy of several CSV files from GDAL
source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries
to read these files dynamically.
Any comments?
AFAIU winGRASS does it already(?)
e.g.
C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\env.bat
{{{
set GISBASE=%OSGEO4W_ROOT%\apps\grass\grass-7.1.svn
REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
set GRASS_HTML_BROWSER=explorer
set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python.exe
set PYTHONHOME=%OSGEO4W_ROOT%\apps\Python27
set GRASS_PROJSHARE=%OSGEO4W_ROOT%\share\proj
set PROJ_LIB=%OSGEO4W_ROOT%\share\proj
set GDAL_DATA=%OSGEO4W_ROOT%\share\gdal
set GEOTIFF_CSV=%OSGEO4W_ROOT%\share\epsg_csv
set PATH=%OSGEO4W_ROOT%\apps\msys\bin;%PATH%
}}}
but there is also
C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj
{{{
datum.table
datumtransform.table
desc.table
ellipse.table
ellipse.table.solar.system
FIPS.code
nad
ogr_csv
parms.table
projections
state27
state83
units.table
}}}
and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\ogr_csv
{{{
coordinate_axis.csv
ellipsoid.csv
gcs.csv
gcs.override.csv
gdal_datum.csv
gt_datum.csv
gt_ellips.csv
pcs.csv
pcs.override.csv
prime_meridian.csv
projop_wparm.csv
stateplane.csv
unit_of_measure.csv
}}}
and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\nad
{{{
alaska
conus
FL
hawaii
MD
prvi
src
stgeorge
stlrnc
stpaul
TN
WI
WO
}}}
and C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\proj\nad\src
{{{
alaska.lla
conus.lla
FL.lla
hawaii.lla
MD.lla
prvi.lla
stgeorge.lla
stlrnc.lla
stpaul.lla
TN.lla
WI.lla
WO.lla
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:4
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1665: Grass SVN (51807) doesn’t launch: Path '…/UNKNOWN/UNKNOWN' doesn't exist
#1665: Grass SVN (51807) doesn’t launch: Path '…/UNKNOWN/UNKNOWN' doesn't exist ---+ Reporter: vince | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Startup| Version: svn-trunk Keywords: |Platform: MacOSX Cpu: OSX/Intel | ---+ Comment(by lucadelu): Replying to [comment:2 vince]: I'm going to test this. Give me two or three days to figure out. Thanks! Do you have any news? Could we close this ticket? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1665#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1665: Grass SVN (51807) doesn’t launch: Path '…/UNKNOWN/UNKNOWN' doesn't exist
#1665: Grass SVN (51807) doesn’t launch: Path '…/UNKNOWN/UNKNOWN' doesn't exist ---+ Reporter: vince | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Startup| Version: svn-trunk Keywords: |Platform: MacOSX Cpu: OSX/Intel | ---+ Comment(by vince): Geez. I'm sorry, I totally overlooked that. Can it wait until next week? I'll then get down to help on the packaging of Grass 7 for Macports and so I'll have time to test that out. Sorry for the (inacceptable, granted) delay. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1665#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory
+---
Reporter: martinl | Owner: grass-dev@…
Type: task| Status: new
Priority: critical| Milestone: 7.1.0
Component: Projections/Datums | Version: unspecified
Keywords: gdal|Platform: Unspecified
Cpu: Unspecified |
+---
Comment(by martinl):
Replying to [comment:4 hellik]:
{{{
set GDAL_DATA=%OSGEO4W_ROOT%\share\gdal
}}}
yes, but it has no effect, GRASS still uses local copies
source:grass/trunk/lib/proj/convert.c#L718
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by wenzeslaus): Replying to [comment:18 martinl]: related to attachment:prefix_to_basename.diff I don't fully understand why to define key 'output' for basename options. I thought that `G_OPT_BASENAME_OUTPUT` will have default key like 'basename_output' or 'output_basename' (better for backward compatibility). Similarly `G_OPT_BASENAME_INPUT` 'input_basename'. Currently, it seems to me that the current option naming policy is to use input or output regardless of type. So input can be raster for one module but vector or imagery group for another. Basename is just another item in the list of possible types/meanings. I think that in case that the output is group or spatio temporal dataset, the option name `basename` is appropriate if you want to set the basename for maps differently from the name of the group. When opening #2136 it was not clear to me when `output`, `output_basename`/`basename_output` or `basename` are appropriate. The motivation for #2136 was unification and creation of standard mechanism in the first place. But especially after going through Pietro's list in comment:5:ticket:2136, it seems to me that basename is nothing special and the default/most used name for the option should be the same as if it would be raster or vector, so `output` and `input` in these cases. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:19 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory
+---
Reporter: martinl | Owner: grass-dev@…
Type: task| Status: new
Priority: critical| Milestone: 7.1.0
Component: Projections/Datums | Version: unspecified
Keywords: gdal|Platform: Unspecified
Cpu: Unspecified |
+---
Comment(by martinl):
Replying to [comment:3 martinl]:
For record list of affected files:
* pcs.csv
The attached patch attachment:gdal_data.diff forces GRASS to use CSV files
from GDAL. First found problem:
GRASS defines 5514 as
{{{
pcs.csv:5514,S-JTSK / Krovak East
North,9001,4818,19952,9819,1,0,6501,8806,0,9001,8807,0,9001,8811,49.3,9110,8813,30.1717303,9110,8818,78.3,9110,8819,0.,9201,8833,42.3,9110
}}}
-
{{{
g.proj epsg=5514 -p
-PROJ_INFO-
name : Krovak
proj : krovak
datum : hermannskogel
ellps : bessel
lat_0 : 49.5
lon_0 : 42.5
alpha : 30.2881397222
k : 0.
x_0: 0
y_0: 0
pm : ferro
no_defs: defined
-PROJ_UNITS
unit : meter
units : meters
meters : 1
}}}
GDAL as
{{{
pcs.csv:5514,S-JTSK / Krovak East
North,9001,4156,5510,1041,1,0,4499,1036,30.1717303,9110,8806,0,9001,8807,0,9001,8811,49.3,9110,8818,78.3,9110,8819,0.,9201,8833,24.5,9110
}}}
-
{{{
.proj epsg=5514 -p
-PROJ_INFO-
name : Krovak
proj : krovak
ellps : bessel
lat_0 : 49.5
lon_0 : 24.83
alpha : 30.2881397222
k : 0.
x_0: 0
y_0: 0
towgs84: 589,76,480,0,0,0,0
no_defs: defined
-PROJ_UNITS
unit : meter
units : meters
meters : 1
}}}
The `wgs84` causes that
{{{
g.proj epsg=5514 datum_trans=-1
ERROR: No output format specified, define one of flags -p, -g, -j, or -w
}}}
will not work.
Should be:
{{{
g.proj epsg=5514 datum_trans=-1
---
1
Used in whole hermannskogel region
towgs84=653.000,-212.000,449.000
Default 3-Parameter Transformation (May not be optimum for older datums;
use this only if no more appropriate options are available.)
---
2
Used in Austria
towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
Accuracy approx. 1.5m
---
3
Used in Czech Republic
towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
---
4
Used in Slovakia
towgs84=485.021,169.465,483.839,7.786342,4.397554,4.102655,0
---
5
Used in Slovenia
towgs84=426.9,142.6,460.1,4.91,4.49,-12.42,17.1
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:6
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory +--- Reporter: martinl | Owner: grass-dev@… Type: task| Status: new Priority: critical| Milestone: 7.1.0 Component: Projections/Datums | Version: unspecified Keywords: gdal|Platform: Unspecified Cpu: Unspecified | +--- Comment(by martinl): Replying to [comment:6 martinl]: The attached patch attachment:gdal_data.diff forces GRASS to use CSV files from GDAL. First found problem: attachment:gdal_data.diff.gz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:19 wenzeslaus]: Currently, it seems to me that the current option naming policy is to use input or output regardless of type. So input can be raster for one module but vector or imagery group for another. Basename is just another item in the list of possible types/meanings. then why the default key is set to `basename` ? source:grass/trunk/lib/gis/parser_standard_options.c#L336 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:20 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): For those how would like to spend some energy and check possible inconsistency in parameter names I attached attachment:module_params_overview-2014-11-24.csv.gz -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:21 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #969: move color structs to colors.h?
#969: move color structs to colors.h? +--- Reporter: hamish | Owner: grass-dev@… Type: task| Status: new Priority: blocker | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: needinfo, RGBA_Color, G_str_to_color() |Platform: All Cpu: All | +--- Comment(by martinl): what is status of this ticket? -- Ticket URL: http://trac.osgeo.org/grass/ticket/969#comment:8 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] GRASS cannot find addons folders
I now have recompiled GRASS trunk and it is working with some workarounds for the errors I reported on Friday. But it will not find my add-ons folders. Scripts in these folders are found without problem by the versions I compiled in August but not the current version. For example, the default location for add-ons is/was /Users/cmbarton/Library/GRASS/7.1/Modules/script What has changed? Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by wenzeslaus): Replying to [comment:20 martinl]: Replying to [comment:19 wenzeslaus]: Currently, it seems to me that the current option naming policy is to use input or output regardless of type. So input can be raster for one module but vector or imagery group for another. Basename is just another item in the list of possible types/meanings. then why the default key is set to `basename` ? source:grass/trunk/lib/gis/parser_standard_options.c#L336 And also the description could be better. I can fix it when I get to it. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:22 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
On 24.11.2014 20:42, GRASS GIS wrote: #2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Hi Martin, can I ask for the script, or the way, you extracted the flags and options per module? Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass with LASzip
Hi I was trying to compile GRASS with libLAS with LASzip support on Ubuntu. I compiled LASzip and installed it in not standard path. Modules r/v.in.lidar then don't compile because they miss liblaszip.so.6. When I export LD_LIBRARY_PATH to the liblaszip.so.6, modules compile. Shouldn't this be handled in configure? Thanks, Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] winGRASS 71 binaries missing
On Mon, Nov 24, 2014 at 12:59 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Tue, Nov 18, 2014 at 9:02 AM, Anna Petrášová kratocha...@gmail.com wrote: Martin, I realized the last grass 71 binary is from November 13, but the last log doesn't show any error? Hi Martin, just a soft reminder in case this email got buried because of other traffic on the mailing list. The old 71s are now deleted and logs seems OK, so something is working there but new builds are not added. 70 is from 17 and 21. Thanks, Vaclav http://wingrass.fsv.cvut.cz/grass70/ http://wingrass.fsv.cvut.cz/grass71/ Martin kindly fixed it, by tomorrow morning Italian time they should be back. ciao Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass with LASzip
On Mon, Nov 24, 2014 at 10:55 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi I was trying to compile GRASS with libLAS with LASzip support on Ubuntu. I compiled LASzip and installed it in not standard path. Modules r/v.in.lidar then don't compile because they miss liblaszip.so.6. When I export LD_LIBRARY_PATH to the liblaszip.so.6, modules compile. Shouldn't this be handled in configure? Not sure. I have here a ld-conf file for it: cat /etc/ld.so.conf.d/liblas.conf /usr/local/lib (remember to run ldconfig as root) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by glynn): Replying to [ticket:2409 martinl]: Before releasing G7 we should check all the modules and use the standardized options as much as possible. Changing key of an option or a flag will be not possible after releasing GRASS 7.0.0. It should be safe to change a key provided that the old value is an accepted abbreviation for the new value. And on that note, if anyone is planning on changing any keys, please 1. Avoid abbreviating keys; the user can always abbreviate, but they can't unabbreviate. 2. Place an underscore between distinct words, to increase the set of accepted abbreviations (e.g. line_color can be abbreviated to lcol bult linecolor can't). To recap: if an option key consists of multiple words (sequences of characters separated by underscores), the key can be abbreviated to any combination of prefixes of the individual words. The first letter of the first word must be provided; subsequent words may be omitted entirely. Underscores are optional. The main limitation is that each word can only be abbreviated to a (possibly empty) prefix, so 1. Compound words cannot have their components abbreviated individually, so background cannot be abbreviated to bg. back_ground can be abbreviated to background or bg, but looks ugly. 2. Plurals cannot be abbreviated to a plural, so columns can be abbreviated to col but not to cols. Again, column_s could be abbreviated to column_s or col or cols, but also looks ugly. It would be reasonably straightforward to extend the code to support an invisible word separator, which would behave like underscore but would be omitted from the --help output. So if background was changed to e.g. back'ground it would show as background in the --help output but could be abbreviated to bg. One possible drawback is that if an abbreviation was rejected due to being a valid abbreviation for more than option, the conflicting option wouldn't necessarily be apparent to the user (due to the separator being hidden). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:23 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
Ciao Niko, 2014-11-24 20:09 GMT+01:00 Nikos Alexandris n...@nikosalexandris.net: can I ask for the script, or the way, you extracted the flags and options per module? sure, http://svn.osgeo.org/grass/sandbox/martinl/print_module_parameters_csv.py Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #222: v.in gns broken in grass 7.0 trunk
#222: v.in gns broken in grass 7.0 trunk --+- Reporter: gisix| Owner: gisix Type: defect | Status: closed Priority: blocker | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed|Keywords: v.in.gns Platform: Linux| Cpu: x86-32 --+- Changes (by lucadelu): * status: assigned = closed * resolution: = fixed Comment: Replying to [comment:9 neteler]: I agree that v.in.gns should be moved to Addons (superseded by v.in.geonames). See http://grasswiki.osgeo.org/wiki/GRASS_7_ideas_collection#Dead_code_cleanup I fixed it with the last version of GNS in r62900, I'm able to load all the txt files inside the th.zip. I also moves the script to addons r62902 (it is possible to install it using g.extension). -- Ticket URL: http://trac.osgeo.org/grass/ticket/222#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #969: move color structs to colors.h?
#969: move color structs to colors.h? +--- Reporter: hamish | Owner: grass-dev@… Type: task| Status: new Priority: blocker | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: needinfo, RGBA_Color, G_str_to_color() |Platform: All Cpu: All | +--- Comment(by martinl): Replying to [comment:5 mmetz]: Should we also change `G_str_to_color()`? This would be a blocker too. IMHO no, because there is no bug reported for `G_str_to_color()`, using `unsigned char` instead of `int` means that a range check can no longer be done, and changing `G_str_to_color()` implies changing it sounds like something for G8 and not G7 (we are in beta stage)... -- Ticket URL: http://trac.osgeo.org/grass/ticket/969#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
Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library
#2496: r.random.surface error from RAN C library --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.random.surface |Platform: MacOSX Cpu: Unspecified | --+- Comment(by cmbarton): This patch seems to fix the problem. I'll know for sure after our script repeated enough times. Most of the times, r.random.surface failed on the first or second time run. Once it did not fail until the 62nd iteration. I'm up to 65 iterations with no errors yet. So it looks good. Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/2496#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory
#2456: read CSV from GDAL data directory +--- Reporter: martinl | Owner: grass-dev@… Type: task| Status: new Priority: critical| Milestone: 7.1.0 Component: Projections/Datums | Version: unspecified Keywords: gdal|Platform: Unspecified Cpu: Unspecified | +--- Comment(by neteler): Here some historical notes to better understand the actual concept in GDAL: * http://fwarmerdam.blogspot.it/2010/03/in-last-few-weeks-i-believe-i -have-made.html * Paul Kelly's comments: http://lists.osgeo.org/pipermail/grass- dev/2010-March/049674.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2456#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass with LASzip
On Mon, Nov 24, 2014 at 5:59 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Nov 24, 2014 at 10:55 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi I was trying to compile GRASS with libLAS with LASzip support on Ubuntu. I compiled LASzip and installed it in not standard path. Modules r/v.in.lidar then don't compile because they miss liblaszip.so.6. When I export LD_LIBRARY_PATH to the liblaszip.so.6, modules compile. Shouldn't this be handled in configure? Not sure. I have here a ld-conf file for it: cat /etc/ld.so.conf.d/liblas.conf /usr/local/lib (remember to run ldconfig as root) I did that. I didn't have problems until now when compiling grass with libLAS, but in order to read laz file, I had to compile libLAS with LASzip support and that's what causing the problem, as can be seen from the error I got (missing liblaszip.so.6). LibLAS can be configured in grass, so it seems that we should be able to specify LASzip library in configure too. It's possible I did something wrong so I was wondering if anyone else was trying to do the same. Anna Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
Hi Nikos, Thanks for the reply. When I run g.region and I give any raster name as an option, I still got the same error. I didn’t try changing the t-b resolution, though. But after further looking around I found out that the file WIND inside my mapset was being changed every time, whenever a file was being edited in the database. When I looked at it I found two entries for t-b resolution, I thought it's supposed to be locked only for edit by one process at a time? After removing the duplicate entry the error when away. Erick ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
