2011/6/3 Hamish hamis...@yahoo.com:
Martin wrote:
wouldn't be better to sync makefile systems in GRASS6 with
GRASS7 and require 3.81 also for GRASS6?
please follow the path of least change to fix bugs in the stable
branch.
speaking about develbr6, are you considering also this branch as
Hi All,
this is to inform you about updates in my GSoC project.
== Work done during week 2 ==
During current week
* I studied some of the r.stream modules to be managed by the GUI. The idea
is to manage the hydrological study in two steps, as detailed on my
project's wiki page [0].
* I opened
Martin Landa wrote:
is an order-only dependency, which requires GNU make 3.81. In 6.x,
this syntax is normally conditional upon ifneq ($(BROKEN_MAKE),). It
appears that someone back-ported from 7.0 (where GNU make 3.81 is a
requirement) without changing this.
lib/python/Makefile has
Soeren Gebbert wrote:
i have updated the wiki and added a simple Python example of a
hypothetical r.series test. Please have a look at:
http://grass.osgeo.org/wiki/Test_Suite#Test_framework
The sample Python code shows in principle how a test case would look
like and what kind of methods
Hi Glynn,
2011/6/3 Glynn Clements gl...@gclements.plus.com:
Soeren Gebbert wrote:
i have updated the wiki and added a simple Python example of a
hypothetical r.series test. Please have a look at:
http://grass.osgeo.org/wiki/Test_Suite#Test_framework
The sample Python code shows in
Markus,
Were you planning on adding filtering options by return number on
v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a useful thing to create a vector layer composed only of 1st
On Fri, Jun 3, 2011 at 3:30 PM, doug_newc...@fws.gov wrote:
Markus,
Were you planning on adding filtering options by return number on
v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a
Soeren Gebbert wrote:
I was thinking about a similar approach, but the effort to parse the
modules XML interface description to identify the command line
arguments to compare the created data was to much effort for me.
I don't see a need to parse the command; just execute it and see what
Hi,
from other Linux applications I am used to mark test (say, module
messages) with the left mouse button and paste it with the
middle mouse button into a whatever text editor.
But in the wxGUI it is not possible, I am forced to use CTRL-C/V.
Any idea how to make the wxGUI behave normal in this
Markus,
Were you planning on adding filtering options by return number
on v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a useful thing to create a vector layer composed only of 1st
#1375: wxGUI: vector digitizer: cannot close (empty) vector map
--+-
Reporter: neteler | Owner: martinl
Type: defect | Status: closed
Priority: normal | Milestone:
On Fri, Jun 3, 2011 at 4:55 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
from other Linux applications I am used to mark test (say, module
messages) with the left mouse button and paste it with the
middle mouse button into a whatever text editor.
But in the wxGUI it is not possible, I am
Hi all,
This is my 2nd week report. Thanks to Maris for his help in this weeks work.
*1) What do I have completed this week?*
I have completed the following by this week.
- Read the programmers manual for WXGUI [1], [2], [3].
- Written a standalone helloWorld application in WXGUI and
Hi,
1) What do I have completed this week?
Fixed bugs in lighting, preferences, drawing vectors on surfaces and others.
I realized that 3D mode can be used only in one map display window due to ogsf
library,
so I make some changes to prevent user from using more windows in 3D mode (I'm
not
FYI
-- Forwarded message --
From: Alex Mandel tech_...@wildintellect.com
Date: Fri, Jun 3, 2011 at 9:06 PM
Subject: [OSGeo-Discuss] NOTICE: Server Maintenance Today
To: OSGeo Discussions disc...@lists.osgeo.org
All,
Some OSGeo services will be down briefly (about 30 minutes)
All:
I have compiled various versions of GRASS on Linux (Redhat) in the past
without problems and recently complied GRASS 6.4.1 on Linux. If I try to
import a shapefile using GRASS 6.4.1 using v.in.ogr, it takes more than
an order of magnitude longer than previous versions of GRASS that I
ok, something seems to mess up my osgeo4w-build-environment. because in the
started osgeo4w-msys-shell there is
GNU Make version 3.79.1.
but, following http://trac.osgeo.org/grass/wiki/CompileOnWindows, if I change
in C:\OSGeo4W\apps\msys\bin
within the osgeo4w-msys-shell there is GNU Make
so I have to find where 3.79.1 comes from, no idea at the moment ...
a qgis-1.6-standalone installation was interfering with the
osgeo4w-build-environment. :o(
Helmut
___
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
hi,
compiling grass65svn-r46561 in the osgeo4w-stack.
I get following:
python -m py_compile
/c/osgeo4w/usr/src/grass6_devel/dist.i686-pc-mingw32/etc/wxpython/gui_modules/menu.py
File
c:/osgeo4w/usr/src/grass6_devel/dist.i686-pc-mingw32/etc/wxpython/gui_modules/menu.py,
line 52
Anna,
I have updated, recompiled and tested the latest wxNviz and it works GREAT!
All the major issues with control view options and lightning are resolved and
work smoothly
and the organization of panels is more intuitive now.
The scrollbar shows up correctly for the FoldPanelBar
but I am
20 matches
Mail list logo
