Markus Metz wrote:
> The range of the differences between the original and the re-import is
>
> min=-6.10348170084762e-05
> max=6.10349170528934e-05
>
> which is magnitudes larger than the 32 bit floating point precision limit.
No, that is the limit for values in that range.
The range of the
On Thu, Apr 4, 2013 at 12:09 PM, Glynn Clements
wrote:
> Markus Neteler wrote:
...
>> cat /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/sys/types.h
>
> Can you visually compare this file to the preprocessor output from
...
(file sent offlist for inspection)
> However: adding -D_POSI
On Thu, Apr 4, 2013 at 6:08 PM, Markus Neteler wrote:
> (deriving this from " Re: [GRASS-dev] could r.stream.* become part of
> GRASS core?"
>
> On Thu, Apr 4, 2013 at 10:47 AM, Hamish wrote:
> ...
>> Very much straying offtopic now, I'd also advocate a series of
>> wrapper scripts to run from GU
#1916: Map loader just shows maps of current and PERMANENT mapset
---+
Reporter: timmie| Owner: grass-dev@…
Type: defect| Status: closed
Priority: norma
On Thu, Apr 4, 2013 at 9:39 PM, Benjamin Ducke wrote:
> On 04/04/2013 09:15 PM, Hamish wrote:
>>
>> Markus Metz wrote:
>>>
>>> I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
>>> now imported as GRASS DCELL (64 bit floating point). The
>>> original and the
>>> re-import are now identic
#800: r.random and r.reclass - buffer overflow on long mapset/map names
---+
Reporter: ferrouswheel | Owner: grass-dev@…
Type: defect| Status: closed
Prio
#800: r.random and r.reclass - buffer overflow on long mapset/map names
---+
Reporter: ferrouswheel | Owner: grass-dev@…
Type: defect| Status: closed
Prio
On Thu, Apr 4, 2013 at 9:39 PM, Benjamin Ducke wrote:
> On 04/04/2013 09:15 PM, Hamish wrote:
>>
>> Markus Metz wrote:
>>>
>>> I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
>>> now imported as GRASS DCELL (64 bit floating point). The
>>> original and the
>>> re-import are now identic
#800: r.random and r.reclass - buffer overflow on long mapset/map names
--+-
Reporter: ferrouswheel | Owner: grass-dev@…
Type: defect| Status: new
Priority: no
On 04/04/2013 09:15 PM, Hamish wrote:
Markus Metz wrote:
I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
now imported as GRASS DCELL (64 bit floating point). The
original and the
re-import are now identical.
Should this change be backported to GRASS 6?
yes please.
+1
Does this
Markus Metz wrote:
> I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
> now imported as GRASS DCELL (64 bit floating point). The
> original and the
> re-import are now identical.
>
> Should this change be backported to GRASS 6?
yes please.
thanks for noticing,
Hamish
On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa wrote:
> Hi,
>
> 2013/4/4 Markus Neteler :
>> On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler wrote:
>>> since the r.stream.* modules are continuously requested and IMHO
>>> sufficiently
>>> tested (according to user reports), I would move them to co
r.in.gdal imports GDAL GDT_Float64 (64 bit floating point) as GRASS
FCELL (32 bit floating point). This leads to surprisingly large
differences between an original DCELL raster map and the re-import of
that map:
# nc_spm_08 dataset
g.region -p rast=elev_state_500m@PERMANENT res=100
r.resamp.interp
On Apr 3, 2013, at 10:13 PM, Hamish wrote:
> no answer for you, just fyi see also 'd.what.vect -e' and
> 'g.mapsets -s' for common compiled C modules calling tcl/tk
> forms.
On Apr 4, 2013, at 6:16 AM, Glynn Clements wrote:
> William Kyngesburye wrote:
>
>> Trying to understand the linking of T
(deriving this from " Re: [GRASS-dev] could r.stream.* become part of
GRASS core?"
On Thu, Apr 4, 2013 at 10:47 AM, Hamish wrote:
...
> Very much straying offtopic now, I'd also advocate a series of
> wrapper scripts to run from GUI buttons for simple-mode d.vect.
> (see also my d.* helper/wrappe
#1916: Map loader just shows maps of current and PERMANENT mapset
---+
Reporter: timmie| Owner: grass-dev@…
Type: defect| Status: closed
Priority: norma
[again - please keep communication on ML!]
2013/4/4 suprakash maitra :
> v.out.ogr -c input=fields type=area dsn='PG:host=localhost dbname=grass
> user=grassuser password=grassuser' olayer=fields2postgis layer=1
> format=PostgreSQL
> ERROR: value out of range for parameter
>
as I mentioned earl
William Kyngesburye wrote:
> Trying to understand the linking of TclTk in GRASS 6.4... I was poking
> around and noticed that libgrass_form itself does not link TclTk, and
> it appears it just creates form content in text and html. This content
> can be displayed with TclTk by the "form" applet,
#1916: Map loader just shows maps of current and PERMANENT mapset
---+
Reporter: timmie| Owner: grass-dev@…
Type: defect| Status: closed
Priority: norma
#1916: Map loader just shows maps of current and PERMANENT mapset
---+
Reporter: timmie| Owner: grass-dev@…
Type: defect| Status: closed
Priority: norma
#1916: Map loader just shows maps of current and PERMANENT mapset
---+
Reporter: timmie| Owner: grass-dev@…
Type: defect| Status: closed
Priority: norma
Markus Neteler wrote:
> > In which case, you need to look at that version of sys/types.h to
> > figure out why off_t isn't getting seen.
>
> I found the path with
> /opt/freeware/bin/gcc -print-search-dirs
> ...
>
> Hence ("randomly" citing):
> cat /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/
#1916: Map loader just shows maps of current and PERMANENT mapset
-+--
Reporter: timmie | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#1916: Map loader just shows maps of current and PERMANENT mapset
-+--
Reporter: timmie | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal
#1915: v.out.ogr: problem to export certain column(s)
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal
#1915: v.out.ogr: problem to export certain column(s)
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal
re. the ubuntu package buildbot for grass7 + ubuntu "raring"
(13.04) the new trouble seems to be a gcc 4.7 compiler error.
from the linked build log:
[...]
house.c: In function 'house':
house.c:10:6: internal compiler error: in rewrite_use_nonlinear_expr, at
tree-ssa-loop-ivopts.c:6215
Please sub
#1915: v.out.ogr: problem to export certain column(s)
---+
Reporter: neteler| Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Markus N wrote:
> > since the r.stream.* modules are continuously requested
> > and IMHO sufficiently tested (according to user reports), I
> > would move them to core if there are no objections.
>
> Coming back to this topic (delayed due to my "outage" in
> winter): no objections, it seems.
I wo
#1914: Possible infinite loop in v.in.dxf (present in 6.4.3RC2)
+---
Reporter: RikSaunderson | Owner: grass-dev@…
Type: defect | Status: new
Priority:
On 04/04/13 05:59, Markus Neteler wrote:
On Thu, Mar 28, 2013 at 12:57 PM, sandeep kumar
wrote:
Hi,
My name is sandeep and i am doing my MS by Research in Spatial
Informatics at IIIT-Hyderabad. I am a good programmer and a quick learner.
This is the first time i am applying for GSoC.
Hi,
2013/4/4 Markus Neteler :
> On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler wrote:
>> since the r.stream.* modules are continuously requested and IMHO sufficiently
>> tested (according to user reports), I would move them to core if there are
>> no objections.
only after major clean-up. If no
32 matches
Mail list logo
