[GRASS-dev] Re: [GRASS GIS] #1452: wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken
#1452: wx location wizard doesn't ask for datum transform options because proj4
4.7.1's epsg file is broken
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.2
Component: Projections/Datums | Version: svn-releasebranch64
Keywords: wingrass, location wizard, wx |Platform: MSWindows XP
Cpu: x86-32 |
---+
Comment(by hamish):
It seems to go beyond just EPSG codes, e.g. on the msys command line
selecting the nad83 datum also returns no options, although
etc/datumtransform.table indicates that 5 (+ the 1 default) should be
available.
{{{
g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1
}}}
both give no output.
I have added a few debug messages to g.proj in trunk to try and figure out
what the blazes is going on inside GPJ_get_default_datum_params_by_name()
co.
(I've never been exactly sure what G_*() fns we're allowed to use inside
modules that begin with G_no_gisinit(). g.proj uses G_warning(),
G_fatal_error(), and G_message(), so I hope G_debug() is ok too)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1452#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
[GRASS-dev] FDCC standards for US government computers
Hi Folks, Apologies to the Windows dev folks for not posting these earlier. Here are the links to the Federal Desktop Core Configuration guidelines ( mandatory for US federal government computers using Windows XP and Vista. I think Win 7 is still in the pipe ) for secure desktop computing. http://nvd.nist.gov/fdcc/index.cfm http://nvd.nist.gov/fdcc/download_fdcc.cfm Main things to remember, 1) application does not require administrative access to run. 2) application does not use system directories( i.e. Windows or Program Files) for user data/ temp files. Sorry if this is redundant information. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1453: ps.map: various enhancements
#1453: ps.map: various enhancements -+-- Reporter: mmetz| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Ps.map | Version: svn-trunk Keywords: |Platform: All Cpu: All | -+-- Some suggested enhancements for ps.map: * line width of colortables: make it a function of font size instead of width of the colortable, otherwise the border can become really thick; patches in ps_clrtbl.patch and psfclrtbl.patch * allow comments in scripts, patch in key_data.patch * do not draw vector points on top of grids, no reason why vector points should behave different to lines and areas; patch in ps_map.patch * add key width to points; patches in r_plt.patch and do_plt.patch * add keys font and fontsize to scalebar; patches in get_scalebar.patch and do_scalebar.patch * vector area legend: use square boxes, the current shape looks weird; patch in ps_vlegend.patch All patches are against trunk -- Ticket URL: https://trac.osgeo.org/grass/ticket/1453 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] #1101: WinGrass7 + scripts are not found in the command line
#1101: WinGrass7 + scripts are not found in the command line
---+
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Packaging | Version: svn-trunk
Keywords: wingrass, scripts |Platform: MSWindows Vista
Cpu: Unspecified|
---+
Comment(by martinl):
Replying to [comment:11 glynn]:
Replying to [comment:10 hellik]:
1. Does %PATH% contain the scripts directory?
yes,
2. Does PATHEXT include .PY?
yes
When I type
{{{
g.manual
}}}
- `command not found`
Of course
{{{
g.manual.py
}}}
works.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1101#comment:12
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] #1101: WinGrass7 + scripts are not found in the command line
#1101: WinGrass7 + scripts are not found in the command line
---+
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Packaging | Version: svn-trunk
Keywords: wingrass, scripts |Platform: MSWindows Vista
Cpu: Unspecified|
---+
Comment(by glynn):
Replying to [comment:12 martinl]:
2. Does PATHEXT include .PY?
yes
When I type
{{{
g.manual
}}}
- `command not found`
Of course
{{{
g.manual.py
}}}
works.
I'm forgetting that we're dealing with bash here. bash ignores PATHEXT,
and it doesn't use file extensions either (except perhaps .bat?).
OTOH, cmd.exe uses PATHEXT and file extensions but ignores the shebang.
And, on Windows, GRASS' G_spawn(), C's system() and Python's os.system()
and subprocess.Popen() all use cmd.exe, not bash.
If we want Python scripts to work in bash, I suspect that we'll need to
create shell-script wrappers without the .py extension which invoke the
script via e.g. $GRASS_PYTHON. Or just require users to type the .py
when running scripts from a shell. Or, if we're only interested in shells
which are started by GRASS, we can customise the .bashrc file to define
aliases for all of the Python scripts, e.g.:
{{{
alias g.manual='$GRASS_PYTHON $GISBASE/scripts/g.manual.py'
...
}}}
Ultimately, using bash on Windows is always going to be a pain; it's a
struggle just to achieve adequate, and almost impossible to go beyond
that. But I don't know whether bash support really matters to actual
Windows users (as opposed to GRASS developers who are running WinGRASS
solely for testing purposes).
The priority should be to ensure that native support works, i.e.
invoking scripts from the GUI, cmd.exe, Python scripts and C programs.
Personally, I'd prefer it if Windows+bash support was limited to
information on the Wiki, so that users understand that it's a use at your
own risk feature.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1101#comment:13
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] #1447: wxGUI wingrass scripts need whitespace in path
#1447: wxGUI wingrass scripts need whitespace in path +--- Reporter: mmetz | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.2 Component: wxGUI | Version: svn-releasebranch64 Keywords: |Platform: MSWindows XP Cpu: All | +--- Comment(by benducke): What I find strange is that I see the same behavior on Windows with MSYS' sh.exe, without the wxGUI. I am running GRASS shell scripts through the SEXTANTE/GRASS interface of gvSIG. What this interface does is set up the GRASS env variables, create a GRASS mapset, then import the data and call sh.exe to parse the script. The GRASS I use is CLI only and the system does not even have Python installed. Thus my initial guess that the problem goes deeper than wxGUI. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1447#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
[GRASS-dev] G_units_to_meters_factor
G_units_to_meters_factor() (in lib/gis/units.c, in 7.0) has: case U_FEET: return 3.28083989501312;/* 1 / (0.0254 * 12)*/ break; This is correct for the international foot but, AFAIK, most (but not all) non-metric geographical data uses the US survey foot. IMHO, we need both U_FEET and e.g. US_USFEET. Possibly also for miles. Or even U_INTFEET and U_USFEET; calling one of them just feet creates a risk of users selecting the default rather the correct one. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1101: WinGrass7 + scripts are not found in the command line
#1101: WinGrass7 + scripts are not found in the command line
---+
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Packaging | Version: svn-trunk
Keywords: wingrass, scripts |Platform: MSWindows Vista
Cpu: Unspecified|
---+
Comment(by hellik):
Replying to [comment:13 glynn]:
I'm forgetting that we're dealing with bash here. bash ignores PATHEXT,
and it doesn't use file extensions either (except perhaps .bat?).
OTOH, cmd.exe uses PATHEXT and file extensions but ignores the shebang.
And, on Windows, GRASS' G_spawn(), C's system() and Python's os.system()
and subprocess.Popen() all use cmd.exe, not bash.
at the moment wingrass7 GRASS 7.0.SVN with MSYS is started in the
following way:
set_shell_start_grass70svn.bat is invoked
{{{
@echo off
rem
#
rem #
rem # File dynamically created by NSIS installer script
rem #
rem
#
rem #
rem # Set SHELL and start GRASS
rem #
rem
#
rem ***Set SHELL***
set SHELL=C:\Program Files\GRASS 7.0.SVN\msys\bin\sh.exe
C:\Program Files\GRASS 7.0.SVN\grass70svn.bat
}}}
grass70svn.bat
{{{
@echo off
rem
#
rem #
rem # File dynamically created by NSIS installer script;
rem #
rem
#
rem #
rem # GRASS Initialization
rem #
rem
#
rem Set GRASS Installation Directory Variable
set GISBASE=C:\Program Files\GRASS 7.0.SVN
set PATH=C:\Program Files\R\R-2.13.0\bin;%PATH%
call %GISBASE%\etc\env.bat
cd %USERPROFILE%
%GRASS_PYTHON% %WINGISBASE%\grass70.py %*
}}}
and a cmd.exe-windows is opened as command line and the wy-gui is starting
Helmut
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1101#comment:14
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] G_units_to_meters_factor
Glynn wrote: G_units_to_meters_factor() (in lib/gis/units.c, in 7.0) has: case U_FEET: return 3.28083989501312; /* 1 / (0.0254 * 12) */ break; This is correct for the international foot but, AFAIK, most (but not all) non-metric geographical data uses the US survey foot. This is a common misconception among non-USers* which has caused me no end of headaches. The US Survey Foot has been in the process of being phased out since like the 1950s or so, AFAIK only about 2(?) of 50 state planes actively still use it, everyone else has switched over to the translates-to-meters- cleanly version. (down from ~13 states in the last 10 years) Of course it is still relevant for historic datasets. the worst offender I've found is the unix `units` programs, which if it sees you are using an en_US locale silently decides that you want to use the US Survey foot for all calculations of distance, area, etc. argh! [*] I think USers are equally vaguely aware of it, but more used to the idea that units can be less than stable, so more easily accept that sometimes it's this, sometimes it's that, names mean nothing, meh, let's get a hotdog. IMHO, we need both U_FEET and e.g. US_USFEET. If G_units_to_meters_factor() is going to be used, yes.. But I question if it should be. Possibly also for miles. no sure about that one (if it would ever be used in practice). watch out for acres in old land parcels based on the US foot though. Or even U_INTFEET and U_USFEET; calling one of them just feet creates a risk of users selecting the default rather the correct one. true. fwiw, for us survey foot: 1 / 0.30480060960121920243 = 3.280833 G_units_to_meters_factor() seems to be used by misc/m.measure/main.c and vector/v.to.db/units.c which should perhaps follow the location's ultimate source, the meters: multiplier from the PERMANENT/PROJ_UNITS file, not its own hardcoded calculation! for m.measure AFAICT it should definitely be reading from the PROJ_UNITS file for the multiplier and not deciding on its own. that's a bug. for v.to.db, to comes from: parms.units = G_define_standard_option(G_OPT_M_UNITS); parms.units-options = miles,feet,meters,kilometers,acres,hectares,radians,degrees; unless usfoot is added to that list, it should always return the 0.3048m intl. foot. see also general/g.setproj/. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1447: wxGUI wingrass scripts need whitespace in path
#1447: wxGUI wingrass scripts need whitespace in path --+- Reporter: mmetz | Owner: grass-dev@… Type: defect| Status: new Priority: major | Milestone: 6.4.2 Component: wxGUI | Version: svn-releasebranch64 Keywords: wingrass, spaces |Platform: MSWindows XP Cpu: All | --+- Changes (by hamish): * keywords: = wingrass, spaces Comment: Replying to [comment:3 benducke]: What I find strange is that I see the same behavior on Windows with MSYS' sh.exe, without the wxGUI. I am running GRASS shell scripts through the SEXTANTE/GRASS interface of gvSIG. What this interface does is set up the GRASS env variables, create a GRASS mapset, then import the data and call sh.exe to parse the script. The GRASS I use is CLI only and the system does not even have Python installed. Thus my initial guess that the problem goes deeper than wxGUI. you are right, it does, I just merged all these tickets as if we solve for one sh.exe there's a good chance we know how to solve for all cases. * Is gvSIG quoting the path names before invoking GRASS? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1447#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
[GRASS-dev] Re: [GRASS GIS] #1453: ps.map: various enhancements
#1453: ps.map: various enhancements -+-- Reporter: mmetz| Owner: hamish Type: enhancement | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Ps.map | Version: svn-trunk Keywords: |Platform: All Cpu: All | -+-- Changes (by hamish): * cc: grass-dev@… (added) * owner: grass-dev@… = hamish * status: new = assigned Comment: I'll post some per-patch comments soon. explanatory screenshots are always nice. but quickly-- re. comments in the script, fyi they are already allowed but the # must be the first char of the line IIRC (less than ideal). your patch as given for # as first non-whitespace char of the line requires a space after it to work? that is less than ideal too. note I've been meaning to do a bit of a rewrite of the vector legend stuff. I prefer the rectangles (esp. when mixed with lines and points in the legend) but am happy to make the shape adjustable somehow. Jorge has some ideas worth looking at as well. vpoints should be under the grid lines, but points (ie annotations) should be above. if present in the instruction, the masked y|n control can help control the order things get rendered in. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1453#comment:1 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] #1453: ps.map: various enhancements
#1453: ps.map: various enhancements -+-- Reporter: mmetz| Owner: hamish Type: enhancement | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Ps.map | Version: svn-trunk Keywords: |Platform: All Cpu: All | -+-- Comment(by hamish): your patch as given for # as first non-whitespace char of the line requires a space after it to work? maybe just look at *key[0] ? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1453#comment:2 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] New histogramming tool for GRASS 7
Something that I've thought about for quite awhile but only now managed to get around to doing. I have added a new histogramming tool to GRASS 7, based on PyPlot like the profiling tool. It will histogram a single raster map or all the maps in an imagery group. It gives user control over colors and line styles, axes, legends, fonts, and grid. It is available from the analysis toolbar button on the display canvas as Create histogram with PyPlot for now. I've left in the old tool that displays d.hist in a window. It should be especially useful for image analysis. Give it a try and let me know if you hit any bugs. Cheers Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-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] New histogramming tool for GRASS 7
You can save the histogram to various image formats. Here is an example from a set of Landsat bands 1-5, and 7. It took about 1 second to histogram all 6 bands. http://dl.dropbox.com/u/7437464/histogramtest.png C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Sep 22, 2011, at 7:28 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Wed, 21 Sep 2011 22:25:05 -0700 From: Michael Barton michael.bar...@asu.edu Subject: [GRASS-dev] New histogramming tool for GRASS 7 To: GRASS developers grass-developers grass-dev@lists.osgeo.org Message-ID: 4940725d-199d-49ec-bb3e-703ae35fa...@asu.edu Content-Type: text/plain; charset=us-ascii Something that I've thought about for quite awhile but only now managed to get around to doing. I have added a new histogramming tool to GRASS 7, based on PyPlot like the profiling tool. It will histogram a single raster map or all the maps in an imagery group. It gives user control over colors and line styles, axes, legends, fonts, and grid. It is available from the analysis toolbar button on the display canvas as Create histogram with PyPlot for now. I've left in the old tool that displays d.hist in a window. It should be especially useful for image analysis. Give it a try and let me know if you hit any bugs. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
