#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#2454: wxgui: list of db columns only becomes available after entering layer
number by hand
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: new
#2501: r.out.gdal -t creates offset values in raster table for integer grids
with
values beginning with 1
---+
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect| Status:
#2501: r.out.gdal -t creates offset values in raster table for integer grids
with
values beginning with 1
---+
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect| Status:
On 26 November 2014 at 21:31, Anna Petrášová wrote:
>
> Anyway, we have a lot of options... We have to decide for one.
yes, the proposal are:
- shoreline ocean
- contour from precip and/or temp
- contour from LIDAR
so?
>
> do we have any? We would have to have a timeseries of points for a str3
On 26 November 2014 at 21:10, Markus Neteler wrote:
>
> But polygons would be better for zonal statistics.
>
As Anna wrote we need points, but we should have both. Maybe
census_wake2000 or nc_state?
>
> Markus
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
On 26 November 2014 at 21:02, Helena Mitasova wrote:
>
>
> Anna is right - in fact these are the stations which were used to create the
> rasterized climate time series so there is no need to create
> virtual weather stations - we already have the real ones. We can get more
> complete data for t
On 26 November 2014 at 20:22, Anna Petrášová wrote:
>
>
> yes, but there are no NC towns as points in the standard dataset. You could
> use precip_30ynormals@PERMANENT which are the meteorology stations, which
> probably doesn't make much sense since but maybe it's still good for the
> dataset.
>
On Wed, Nov 26, 2014 at 9:31 PM, Anna Petrášová wrote:
> On Wed, Nov 26, 2014 at 3:10 PM, Markus Neteler wrote:
>> On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová
>> > Do we have any temporal data for 3d raster? I don't think we necessarily
>> > have to create this dataset.
>>
>> 3D point soil d
On Wed, Nov 26, 2014 at 8:13 PM, Michael Barton wrote:
> For any version of GRASS for which there is any reasonable development, all
> binary extensions will be out of date as soon as the first update is made.
No - as mentioned *only* is the libgis API is changed.
Example: see the frequency of
On Wed, Nov 26, 2014 at 3:10 PM, Markus Neteler wrote:
> On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová
> wrote:
> ...
> > yes, but there are no NC towns as points in the standard dataset.
>
> There is a (small) geonames layer in the standard NC dataset which we
> could add (updated).
> But pol
#2501: r.out.gdal -t creates offset values in raster table for integer grids
with
values beginning with 1
---+
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect| Status:
I just realized temporal framework doesn't work with recent GRASS 70
version on Windows:
t.list or t.create give me:
Traceback (most recent call last):
File "", line 1, in
File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 380,
in main
prepare(preparation_d
On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová wrote:
...
> yes, but there are no NC towns as points in the standard dataset.
There is a (small) geonames layer in the standard NC dataset which we
could add (updated).
But polygons would be better for zonal statistics.
...
> Helena suggests here
On Nov 26, 2014, at 2:22 PM, Anna Petrášová wrote:
> On Wed, Nov 26, 2014 at 12:10 PM, Luca Delucchi wrote:
> On 8 October 2014 at 03:21, Anna Petrášová wrote:
>
> > as you know we need to decide which data are we going to use for t.vect.*
> > examples. One possibility is to use oceanfront shor
#2439: g.gui.iclass crashes
---+
Reporter: madi | Owner: grass-dev@…
Type: defect | Status: new
Prior
#2501: r.out.gdal -t creates offset values in raster table for integer grids
with
values beginning with 1
--+-
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect
On Wed, Nov 26, 2014 at 12:10 PM, Luca Delucchi
wrote:
> On 8 October 2014 at 03:21, Anna Petrášová wrote:
> > Hi,
> >
>
> Hi,
>
> > as you know we need to decide which data are we going to use for t.vect.*
> > examples. One possibility is to use oceanfront shorelines of North
> Carolina,
> > we
For any version of GRASS for which there is any reasonable development, all
binary extensions will be out of date as soon as the first update is made. So
they all will need to be recompiled. Why do we need to do this? Most will work
fine without recompiling.
Michael
C. Mich
On Nov 26, 2014 8:02 PM, "Michael Barton" wrote:
>
> Will this be the case for all extensions built against a revision of
current - 1?
Today yes, due to an API change in libgis.
> If so, then there is no point in installing any binary module.
Why?
As soon as G7 is stable these changes will unl
#1242: vector fills and line widths not displaying in latlon regions
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Will this be the case for all extensions built against a revision of current -
1?
If so, then there is no point in installing any binary module.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution
#2501: r.out.gdal -t creates offset values in raster table for integer grids
with
values beginning with 1
--+-
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect
Hi,
2014-11-26 19:32 GMT+01:00 Michael Barton :
> ERROR: Module built against version $Revision: 61095 $ but trying to use
>version $Revision: 62364 $. You need to rebuild GRASS GIS or
>untangle multiple installations.
you need to rebuild extension
g.extension.all ope=rebuild
Ma
#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Pri
In the new trunk GRASS 7.1, I’m running into an error check like the following:
GRASS 7.1.svn (Penaguila):~ > r.flip &
[1] 76586
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple ins
This almost sound like the PostGIS Garden Test:
http://trac.osgeo.org/postgis/wiki/DevWikiGardenTest
Robert Moskovitz
California Geological Survey
Seismic Hazards Zonation Program
CONFIDENTIALITY NOTICE: This communication is intended only for the use of the
individual or entity to which it is
On 26/11/14 18:10, Luca Delucchi wrote:
On 8 October 2014 at 03:21, Anna Petrášová wrote:
Hi,
Hi,
as you know we need to decide which data are we going to use for t.vect.*
examples. One possibility is to use oceanfront shorelines of North Carolina,
we can get this data easily from here:
h
#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Pri
On 8 October 2014 at 03:21, Anna Petrášová wrote:
> Hi,
>
Hi,
> as you know we need to decide which data are we going to use for t.vect.*
> examples. One possibility is to use oceanfront shorelines of North Carolina,
> we can get this data easily from here:
>
> http://portal.ncdenr.org/web/cm/do
On Wed, Nov 26, 2014 at 8:33 AM, Markus Neteler wrote:
> > It would be great if we could automatically test all the changes that
> > i have introduced in the release branch using the testsuite.
>
> Do you mean "online" on a server?
I believe Soeren means by running the tests (in any way) as opp
On Wed, Nov 26, 2014 at 11:07 AM, Martin Landa
wrote:
> Hi,
>
> is it need to have such script in the path?
>
> test.r3flowtest.raster3d.lib
>
>
Honestly, I don't know.
This is one of the issues why I'm hesitating to backport the testing. I'm
not sure how much this was discussed on maili
hi,
the updated g.list in G7 still has two issues:
1) when identical map names exist in the current and an/other
mapset(s), the @mapset should be always printed (even if current):
GRASS 7.1.svn (nc_spm_08_grass7):~ > g.list rast | grep
lsat5_1987_div__pielou_size_5
lsat5_1987_div__pielou_size_5.
On Wed, Nov 26, 2014 at 10:44 AM, Markus Neteler wrote:
> Hi,
>
> in the recent past I added a series of examples to various manual
> pages. Most of them might qualify for (basic) testing of the
> respective command.
>
I totally agree. I have the same idea in my mind for some time and I would
re
On Thu, Sep 18, 2014 at 12:43 AM, wrote:
> Author: glynn
> Date: 2014-09-17 15:43:22 -0700 (Wed, 17 Sep 2014)
> New Revision: 62026
>
> Modified:
>grass/trunk/display/d.info/main.c
>grass/trunk/include/defs/display.h
>grass/trunk/lib/display/r_raster.c
>grass/trunk/lib/display/set
Hi,
is it need to have such script in the path?
test.r3flowtest.raster3d.lib
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.
Hi,
in the recent past I added a series of examples to various manual
pages. Most of them might qualify for (basic) testing of the
respective command.
Since it is a bit time consuming to write these standard tests
manually, would there be a chance to develop a test case generator
e.g. driven by a
On Wed, Nov 26, 2014 at 8:48 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
> On 26/11/14 14:33, Markus Neteler wrote:
>
>> On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
>> wrote:
>>
>>> Backport done in r62858 - r62867.
>>> I hope everything works fine.
>>>
>>
>> Great, thanks for y
#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2256: No projection for web service layer
+---
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: major
Is there anyone willing to check ticket #2059 out? [0]
I am attaching an `R` session through which I obtained the numbers fed
to `create_iwave.py` for the template creation.
Is there, perhaps, important to keep the band-width order (instead of
the band numbering in delivered products)? Maybe
The band follow that order (if i remember correcty) because they are
ordered by ascending wavelength since its the same scema the other
sensors follow.
No reason not to change the order if its needed
On Tue, Nov 25, 2014 at 7:10 PM, GRASS GIS wrote:
> #2305: i.atcorr landsat8 support
> -
#2500: r.surf.idw vs. r.surf.idw2
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
#2059: WorldView2 relative spectral response data for i.atcorr
--+-
Reporter: nikosa| Owner: grass-dev@…
Type: enhancement | Status: new
Priori
On 26/11/14 14:33, Markus Neteler wrote:
On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
wrote:
Backport done in r62858 - r62867.
I hope everything works fine.
Great, thanks for your efforts!
It would be great if we could automatically test all the changes that
i have introduced in the rele
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
wrote:
> Backport done in r62858 - r62867.
> I hope everything works fine.
Great, thanks for your efforts!
> It would be great if we could automatically test all the changes that
> i have introduced in the release branch using the testsuite.
Do yo
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
Newcomb, Doug wrote:
> Hi Folks,
>
> I was running r.geomorphon,
> http://grass.osgeo.org/grass70/manuals/addons/r.geomorphon.html, to generate
> a landscape integer grid. I decided to share the output with a colleague
> running ArcGIS. I exported with the raster attribute table option to HFA (
>
#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Pri
#2272: Improve consistency in random generator usage
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: major| Miles
#1242: vector fills and line widths not displaying in latlon regions
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker
57 matches
Mail list logo
