Re: [GRASS-dev] Right way to use G_getl2
Glynn Clements wrote: FWIW, I suggest changing the existing behaviour [of G_getl2()] so that it always reads an entire line, even if it can't store it all. IOW, read until EOL or EOF, stop storing characters once the buffer is full. +1 Unlike with fgets(), which stores the line terminator in the buffer, there is no way for the caller of G_getl2() to determine that an incomplete line was read. If the buffer is too small, you lose either way; discarding the trailing characters is likely to be more robust than returning them as if they were a subsequent line (the current behaviour). The caller could know if a line was only partially read if G_getl2() would return -1 (anything but 0, 1) in case the buffer is too small. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles -+-- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: d.barscale |Platform: All Cpu: All | -+-- Would be nice to implement drop-down menu for barscale styles (1), ie. `d.barscale style=` and probably also for `d.barscale north_arrow=` similarly to `d.vect symbol=`. (1) http://grasswiki.osgeo.org/wiki/Cartography#Display_monitors -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077 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] #1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows
#1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows --+- Reporter: venkat| Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: wingrass |Platform: MSWindows 7 Cpu: x86-32| --+- Comment(by martinl): Replying to [comment:22 mlennert]: Ah, OK, it's probably caused by the fact that the standalone installer puts `python27.dll` to the different directory (ie. `extralib`) compared to `python.exe` (`extrabin`). Directory `extralib` is in the path source:grass/trunk/mswindows/env.bat#L17, but it's probably not enough. The problem could be solved by moving `python27.dll` to `extrabin`. Then we could probably move all DLL files to `extrabin` and get rid of this directory. It's comment practice to have DLL files together with EXE files in the same directory. I don't know why the standalone installer separates them to the two different directories, ie. `extrabin` and `extralib`. Try it, it helped, GRASS now starts, python scripts called from command line also starts. My suggestion is to apply patches r57639 and r57646 also in GRASS 6.x, ie. to remove `extralib` directory from standalone installer. Any objections? but ISTR that there is also an issue with the Windows registry, i.e. that the dlls called depend on registry entries (I think that this came up as a problem at least in the case of python scripts called from python scripts). Right, it's open issue. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1941#comment:28 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] #1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows
#1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows --+- Reporter: venkat| Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: wingrass |Platform: MSWindows 7 Cpu: x86-32| --+- Comment(by hellik): Replying to [comment:28 martinl]: Try it, it helped, GRASS now starts, python scripts called from command line also starts. My suggestion is to apply patches r57639 and r57646 also in GRASS 6.x, ie. to remove `extralib` directory from standalone installer. Any objections? +1 for backport but ISTR that there is also an issue with the Windows registry, i.e. that the dlls called depend on registry entries (I think that this came up as a problem at least in the case of python scripts called from python scripts). Right, it's open issue. I can't find any registry entry for calling python dlls here on my win7-box. isn't it an issue with file extension-association? Helmut -- Ticket URL: http://trac.osgeo.org/grass/ticket/1941#comment:29 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] #1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows
#1941: wxGUI fails with Japanese locale -- mixed Python installs on Windows --+- Reporter: venkat| Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: wingrass |Platform: MSWindows 7 Cpu: x86-32| --+- Comment(by wenzeslaus): Replying to [comment:29 hellik]: Replying to [comment:28 martinl]: but ISTR that there is also an issue with the Windows registry, i.e. that the dlls called depend on registry entries (I think that this came up as a problem at least in the case of python scripts called from python scripts). Right, it's open issue. I can't find any registry entry for calling python dlls here on my win7-box. isn't it an issue with file extension-association? For the file association, we have even a separate ticket #2015. But the comments deal with other problems (actually, I don't know if they are related or not) and my original problem was never confirmed (although we had it one more than one computer). -- Ticket URL: http://trac.osgeo.org/grass/ticket/1941#comment:30 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 wiki: broken link to ps.map cartography example
Hi, wiki page http://grasswiki.osgeo.org/wiki/Cartography contains in text Thematic maps of Belgium invalid link to http://geog-pc40.ulb.ac.be/grass/psmap/ Do we have something to replace this? Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS wiki: broken link to ps.map cartography example
On 14/09/13 15:13, Vaclav Petras wrote: Hi, wiki page http://grasswiki.osgeo.org/wiki/Cartography contains in text Thematic maps of Belgium invalid link to http://geog-pc40.ulb.ac.be/grass/psmap/ Do we have something to replace this? I had already replaced the link on the wiki page http://grasswiki.osgeo.org/wiki/Ps.map_scripts#Script_examples but had overlooked this one. However, due to a change in our configuration this machine is not online all the time currently. I'll try to find a more permanent solution, maybe best directly in the wiki. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.neighbors in GRASS7 much slower ?
On 14/09/13 00:12, Markus Metz wrote: On Fri, Sep 13, 2013 at 5:02 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Hi, In grass64release, running: v.distance from=hospitals@PERMANENT to=hospitals@PERMANENT col=to_cat,dist up=cat,dist -p dmin=0.0001 gives me an almost instant response. In grass7, it takes _much_ longer. What has changed ? That was a bug in the new search method, fixed in r57657. Thanks for the quick fix ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS wiki: broken link to ps.map cartography example
On Sat, Sep 14, 2013 at 9:53 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 14/09/13 15:13, Vaclav Petras wrote: Hi, wiki page http://grasswiki.osgeo.org/**wiki/Cartographyhttp://grasswiki.osgeo.org/wiki/Cartography contains in text Thematic maps of Belgium invalid link to http://geog-pc40.ulb.ac.be/**grass/psmap/http://geog-pc40.ulb.ac.be/grass/psmap/ Do we have something to replace this? I had already replaced the link on the wiki page http://grasswiki.osgeo.org/**wiki/Ps.map_scripts#Script_**exampleshttp://grasswiki.osgeo.org/wiki/Ps.map_scripts#Script_examples but had overlooked this one. However, due to a change in our configuration this machine is not online all the time currently. I'll try to find a more permanent solution, maybe best directly in the wiki. Definitively, if the licence allows it is the best solution to put all your material directly on the wiki (if it is not very large, for example videos are on youtube). Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] patch for v.nn.py
Michael,
I've attached a patch to your very useful v.nn.py addon script. The
patch provides the following:
- a change of option names from input1,2 to 'from' and 'to'
- the possibility to provide a vector map with polygons giving the
contours of the study area for which to calculate the nearest neighbor
coefficient - the script just gets the total of all areas and all
perimeters in the given map
- the possibility to provide numerical values for area and perimeter
Even though some people argue that the absolute value of the coefficient
does not mean much and that the exact size of the study area does not
have an influence on the relative values of the coefficient, I think it
is a plus to have the possibility to circumscribe the area. Especially
since in its current state the module gets the area and perimenter from
the current region and as this is a vector module most people won't even
think about region settings. (Running the module in the default n=1 s=0
w=0 e=1 region gives very weird coefficient values.
Up to you to decide whether you want to add this into your script.
BTW: the script works perfectly in grass7 as well.
Moritz
--- /data/GRASS/SCRIPTS/v.nn.py 2013-09-13 14:55:37.0 +0200
+++ v.nn2.py 2013-09-14 18:07:33.0 +0200
@@ -29,7 +29,7 @@
#%End
#%option
-#% key: input1
+#% key: from
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector points base file
@@ -37,15 +37,38 @@
#%end
#%option
-#% key: input2
+#% key: to
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector points file to compare with base file
#% required : no
#%end
+#%option
+#% key: areamap
+#% type: string
+#% gisprompt: old,vector,vector
+#% description: Vector polygon file with study zone
+#% required : no
+#%end
+
+#%option
+#% key: area
+#% type: double
+#% description: Area of the study zone
+#% required : no
+#%end
+
+#%option
+#% key: perimeter
+#% type: double
+#% description: Perimeter of the study zone
+#% required : no
+#%end
+
+
import math
-import os
+import os,sys
if not os.environ.has_key(GISBASE):
print You must be in GRASS GIS to run this program.
@@ -58,16 +81,19 @@
sys.exit(_(No GRASS-python library found))
-def NNcalc(map1, map2):
+def NNcalc(map1, map2, area, perimeter):
calculates nearest neighbor coefficient for a single map
or for two maps
-## Calculate region perimeter and area (rectangular area only)
-ns_extent = float(grass.parse_command('g.region', flags='eg')['ns_extent'])
-ew_extent = float(grass.parse_command('g.region', flags='eg')['ew_extent'])
-area = ns_extent * ew_extent
-perimeter = (2 * ns_extent) + (2 * ew_extent)
+if area == '' or perimeter == '':
+## Calculate region perimeter and area (rectangular area only)
+ns_extent = float(grass.parse_command('g.region', flags='eg')['ns_extent'])
+ew_extent = float(grass.parse_command('g.region', flags='eg')['ew_extent'])
+area = ns_extent * ew_extent
+perimeter = (2 * ns_extent) + (2 * ew_extent)
+grass.message(_(Using area = %g and perimeter = %g.) % (area, perimeter))
+
## Calculates the number of points in each vector points file
npts1 = int(grass.parse_command('v.info', map=map1, flags='t')['points'])
npts2 = int(grass.parse_command('v.info', map=map2, flags='t')['points'])
@@ -97,19 +123,36 @@
def main():
Main method for script
-map1 = options['input1']
-map2 = options['input2']
+map1 = options['from']
+map2 = options['to']
+areamap = options['areamap']
+area = options['area']
+perimeter = options['perimeter']
+if (area != '' or perimeter != '') and (areamap != ''):
+grass.message(_(If both area/perimeter and areamap are given, areamap has precedence))
+if areamap == '' and ((area != '' and perimeter == '') or (area == '' and perimeter != '')):
+sys.exit(_(If one of area or perimeter is given, the other must be given as well))
+
if map2 == '' or map1 == map2:
# Single map nearest neighbor for clustering analysis
map2 = map1
-header = 'Nearest neighbor coeficient for points in %s: ' % map1
+header = 'Nearest neighbor coefficient for points in %s: ' % map1
else:
# Nearest neighbor for correspondence between two point maps
-header = 'Nearest neighbor coeficient of association between points in %s and %s: ' % (map2, map1)
+header = 'Nearest neighbor coefficient of association between points in %s and %s: ' % (map2, map1)
+
+if areamap != '':
+res = grass.read_command('v.to.db', flags='pc', map=areamap, option='area')
+area = float(res.splitlines()[-1].split('|')[1])
+res = grass.read_command('v.to.db', flags='pc', map=areamap, option='perimeter')
+perimeter = float(res.splitlines()[-1].split('|')[1])
+elif area != '' and perimeter != '':
+area =
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles -+-- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: d.barscale |Platform: All Cpu: All | -+-- Changes (by hamish): * version: unspecified = svn-trunk Comment: Hi, yes, I think that would be helpful as it's a bit difficult to find specific names for all of the different styles, and of course being locked into English those names in the current drop down list are not so helpful when using GRASS translated. (fwiw, also I've been trying to keep them all starting with a unique letter) for the north arrows I didn't even try to describe them in a single word. those already have png icon versions for `d.vect symbol=`, but probably better to have a second set for this at ~ 75-100px square. see Anna's /trunk/gui/images/symbols/README for standardized thumbnail creation instructions. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2077#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
Re: [GRASS-dev] [GRASS GIS] #2014: r.sun using EPSG:3031 projection gives strange results
#2014: r.sun using EPSG:3031 projection gives strange results
---+
Reporter: pierreroudier | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: r.sun |Platform: Linux
Cpu: x86-64 |
---+
Comment(by hamish):
Hi, I had a try using Mt. Erebus as the shadowing body r.sun in mode 2
(integrated over the entire day),
{{{
north: -128
south: -1372500
west: 24
east: 339500
nsres: 100
ewres: 100
}}}
and cubic-reprojected etopo1 for elevation. (can probably dig out some
lidar for Ross Island from someone in our dept; 100m DEM from Colorado is
currently offline due to flooding)
test setup for grass 6.5 looked like this:
{{{
DAYS=001 030 045 060 070 080
for DAY in $DAYS ; do
r.sun -s elevin=etopo1.ross_island step=0.05 \
beam_rad=erebus.direct.$DAY diff=erebus.diffuse.$DAY day=$DAY
done
wait
DAYS=085 090 095 100 105 110 115
for DAY in $DAYS ; do
r.sun -s elevin=etopo1.ross_island step=0.05 \
beam_rad=erebus.direct.$DAY diff=erebus.diffuse.$DAY day=$DAY
done
for map in `g.mlist pat=erebus.d*` ; do
r.colors $map col=bcyr
done
}}}
day 115 is near last-light of the autumn, not exactly the same sunrise/set
as these values for McMurdo, but pretty close I'm not sure which
definition they're using.
http://www.timeanddate.com/worldclock/astronomy.html?n=1032month=4year=2013obj=sunafl=-11day=1
There's an obvious low-sun-angle bug in the diffuse output map, which I'll
file in a separate report, and obviously the default albedo and linke
values in the module won't be much good, but the direct beam results seem
ok if I look at the individual days. I'm still waiting for days 1 30 to
finish, but looking at the result for day 45 makes it seem like for
summertime there might be some counter-intuitive irradiation pattern, with
more light on the true-south side of the mountain. If day 1 or 30 show the
same, the next thing would be to run r.sun in mode 1 quarter-hourly over
that one day and see if that can make more sense.
todo: test with grass7. The main differences in the versions is that by
default shadowing effect of the DEM is turned on in G7, while in grass 6.x
you needed to use the -s flag; and the lat/lon reprojection code is backed
out of the main loop for speed and to make parallelization/GPU assist
easier.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2014#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] #2014: r.sun using EPSG:3031 projection gives strange results
#2014: r.sun using EPSG:3031 projection gives strange results ---+ Reporter: pierreroudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.sun |Platform: Linux Cpu: x86-64 | ---+ Comment(by hamish): yeah, looking at the results for day=1 and 30 there's significantly more light showing on the true-south side of Erebus at that time of year. To test if that's a counter-intuitive cumulative time-spent effect or not, next things to try I think are to plot the sun's position through the day, and try it in another Antarctic stereographic projection that puts grid- north and true-north in alignment and see if we get the same result. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2014#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] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles -+-- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: d.barscale |Platform: All Cpu: All | -+-- Comment(by annakrat): Just to make it clear, do you want to create the images once and keep it in the repository or generate it during compilation (like color tables)? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2077#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
