On 09/02/09 08:32, Hamish wrote:
Michael:
I also want to note that while a multi-package over-the-internet
installer is perfectly normal in the Linux world, it is not the
norm either for Mac or Windows.
Maybe we can go in this direction:
http://blog.qgis.org/node/124
Moritz
_
Michael:
> I also want to note that while a multi-package over-the-internet
> installer is perfectly normal in the Linux world, it is not the
> norm either for Mac or Windows.
(point them to background automatic software updates)
I guess Cygwin & Fink examples don't count :)
> In fact, in many s
Thanks a lotit works
Andi
Hamish wrote:
Andreas Jochem wrote:
I was trying to compile the test.c file in lib/vector/rtree
directory but I always get some error messages.
/usr/local/src/grass-6.3.0/lib/vector/rtree/test.c:49:
undefined reference to `RTreeNewIndex'
/usr/local/src/gras
Glynn:
> > But, if the nature of the algorithm is such that processing time
> > becomes a problem long before memory does, then there's no point to
> > using any form of segmentation.
as the module gets faster, the size of map you attempt to run it on
gets bigger and memory does start to become a
#103: wx-python gui: NVIZ (tcltk) not starting
---+
Reporter: hellik| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: reopened
Priority: major | Milest
Glynn wrote:
>>> I have added experimental multi-threading support to r.mapcalc in 7.0
Markus:
> > r.shaded.relief seems to have the most complex r.mapcalc expression of
> > any of the supplied scripts.
>
> I have built r.mapcalc with 'make USE_PTHREAD=1' in 7,
> this are the results:
> GRA
Michael Barton wrote:
> For example, the GRASS 6.3 windows package installer has been working
> fine for a year, and 6.3 works fine with Windows XP. Yet this is still
> listed on the GRASS site as the "GRASS Windows-Native Experimental
> Project". There are always issues to fix, but this is far be
Andreas Jochem wrote:
> I was trying to compile the test.c file in lib/vector/rtree
> directory but I always get some error messages.
>
> /usr/local/src/grass-6.3.0/lib/vector/rtree/test.c:49:
> undefined reference to `RTreeNewIndex'
> /usr/local/src/grass-6.3.0/lib/vector/rtree/test.c:63:
> und
#486: wx-GUI - SQL-Builder
-+--
Reporter: hellik | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor| Milestone: 6.4.0
#485: r.external crash
-+--
Reporter: hellik | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
On Sun, Feb 8, 2009 at 8:18 PM, Markus Neteler wrote:
> On Sun, Feb 8, 2009 at 5:19 PM, Glynn Clements
> wrote:
>>
>> Markus Neteler wrote:
>>
>>> PS: I would like to do testing but don't know how to start grass64.bat
>>> in the mingw shell in wine...
>>
>> You're not supposed to start it from t
Here are some Mac tests, below...
On Feb 8, 2009, at 12:45 PM, wrote:
Date: Sun, 8 Feb 2009 20:24:21 +0100
From: Markus Neteler
Subject: Re: [GRASS-dev] r.surf.contour inefficiency?
To: Glynn Clements
Cc: grass-dev
Message-ID:
<86782b610902081124y52abb470n258ee1a8ce455...@mail.gmail
On Fri, Jan 9, 2009 at 5:51 PM, Glynn Clements wrote:
> Markus Neteler wrote:
>
>> > I have added experimental multi-threading support to r.mapcalc in 7.0
>> > (r34440). It isn't enabled by default; to enable it, use
>> > "make USE_PTHREAD=1". It only uses a handful of pthread functions, so
>> > t
Glynn Clements wrote:
Markus Metz wrote:
I like the point of Ivan that off_t is the native type for file offsets.
Could G_fseek then use fseeko whenever fseeko is available (ditto for
ftello)?
Well, that's the general idea. The only advantage of fseek/ftell is
that they are always av
On Sun, Feb 8, 2009 at 5:25 PM, Glynn Clements wrote:
> Markus Neteler wrote:
>
>> > I'll remove the segmentation code in 7.0.
>>
>> Here the timing comparison:
>>
>> # NC data set
>> g.region vect=elev_lid792_cont1m res=1 -p
>> v.to.rast elev_lid792_cont1m out=elev_lid792_cont1m use=z
>> time r.s
On Sun, Feb 8, 2009 at 5:19 PM, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
>> PS: I would like to do testing but don't know how to start grass64.bat
>> in the mingw shell in wine...
>
> You're not supposed to start it from the MSys shell, but from the
> Windows command prompt (cmd.exe).
>
>
On Sun, Feb 8, 2009 at 6:08 PM, Michael Barton wrote:
> For example, the GRASS 6.3
> windows package installer has been working fine for a year, and 6.3 works
> fine with Windows XP. Yet this is still listed on the GRASS site as the
> "GRASS Windows-Native Experimental Project". There are always i
Hello,
I have a set of polygons and I am trying to insert them in a rtree to
speed up spatial queries. Has anybody done this before?? Is there some
example code available?
I was trying to compile the test.c file in lib/vector/rtree directory
but I always get some error messages.
/usr/loca
#484: Cannot reload maps to wxnviz
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.5.0
I agree that this could be difficult for an individual open source dev
team to do (Although I bet the GRASS user/developer community would
catch, announce, and remove embedded malware very fast). I'm
suggesting this as something that the large OSGeo umbrella might look
into as a benefit to
Michael Barton wrote:
> Along these lines, it might be worth thinking about a bit of a
> different model for open source disclaimers. They generally say if
> prominent type that 'hey, you're on your own with this; we're not
> responsible for anything'. I wonder if we could have some kind of
#479: wxgui mapset access module broken
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major| Milestone: 6.5.
Markus Neteler wrote:
> >> > I have added experimental multi-threading support to r.mapcalc in 7.0
> >> > (r34440). It isn't enabled by default; to enable it, use
> >> > "make USE_PTHREAD=1". It only uses a handful of pthread functions, so
> >> > there's a reasonable chance of it working on MacOS
On Feb 8, 2009, at 8:44 AM, wrote:
Date: Sun, 8 Feb 2009 08:54:18 +0100
From: Markus Neteler
Subject: Re: [GRASS-dev] Re: [GRASS-user] Referencias de GRASS 6.3.0
nativo para MS-Windows
To: hamis...@yahoo.com
Cc: GRASS developers list
Message-ID:
<86782b610902072354r7412b067
Markus Metz wrote:
> >> Do I understand right that fseeko and ftello are only needed on 32-bit
> >> systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns long which
> >> is on my 64bit Linux 64bit, I guess that's why I can write coor files >
> >> 2GB with the current vector libs.
> >>
Markus Neteler wrote:
> > I'll remove the segmentation code in 7.0.
>
> Here the timing comparison:
>
> # NC data set
> g.region vect=elev_lid792_cont1m res=1 -p
> v.to.rast elev_lid792_cont1m out=elev_lid792_cont1m use=z
> time r.surf.contour elev_lid792_cont1m out=dem
>
> Results:
> * GRASS
Markus Neteler wrote:
> PS: I would like to do testing but don't know how to start grass64.bat
> in the mingw shell in wine...
You're not supposed to start it from the MSys shell, but from the
Windows command prompt (cmd.exe).
It should be mostly usable without having MSys installed.
--
Glynn
On Feb 8, 2009, at 12:44 AM, wrote:
Date: Sat, 7 Feb 2009 23:07:35 -0800 (PST)
From: Hamish
Subject: [GRASS-dev] Re: [GRASS-user] Referencias de GRASS 6.3.0
nativo para MS-Windows
To: grass-dev@lists.osgeo.org
Message-ID: <828225.60901...@web110010.mail.gq1.yahoo.com>
Content-Type
#482: wx NVIZ crashes when adding a vector map
---+
Reporter: msieczka | Owner: martinl
Type: defect| Status: assigned
Priority: major | Milestone: 6.4.0
Compon
#481: clicking on wx NVIZ map canvas causes an error
---+
Reporter: msieczka | Owner: martinl
Type: defect| Status: assigned
Priority: major | Milestone: 6.4.0
#480: wx NVIZ prints debug info to terminal
---+
Reporter: msieczka | Owner: martinl
Type: defect| Status: assigned
Priority: major | Milestone: 6.5.0
Component
#37: grass: wxpython gui issues
--+-
Reporter: jachym | Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
On Fri, Jan 9, 2009 at 5:51 PM, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
>> > I have added experimental multi-threading support to r.mapcalc in 7.0
>> > (r34440). It isn't enabled by default; to enable it, use
>> > "make USE_PTHREAD=1". It only uses a handful of pthread functions, so
>> >
Glynn Clements wrote:
Markus Metz wrote:
Do I understand right that fseeko and ftello are only needed on 32-bit
systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns long which
is on my 64bit Linux 64bit, I guess that's why I can write coor files >
2GB with the current vector libs.
On Sun, Feb 8, 2009 at 8:26 AM, Glynn Clements wrote:
> I'll remove the segmentation code in 7.0.
Here the timing comparison:
# NC data set
g.region vect=elev_lid792_cont1m res=1 -p
v.to.rast elev_lid792_cont1m out=elev_lid792_cont1m use=z
time r.surf.contour elev_lid792_cont1m out=dem
Results:
> Glynn Clements writes:
>> Do I understand right that fseeko and ftello are only needed on
>> 32-bit systems that want D_FILE_OFFSET_BITS=64? fseek e.g. returns
>> long which is on my 64bit Linux 64bit, I guess that's why I can
>> write coor files > 2GB with the current vector libs.
>
36 matches
Mail list logo