Hi,
I though that we three already discussed this topic but I cannot find
the thread. Anyway, I totally agree that GRASS needs one big single
window (we should also keep the old behavior to satisfy existing
users). For this a refactoring of the wxGUI source code is needed.
Anna and I already did s
#1852: r.profile: accept lines vector map as profile
--+-
Reporter: dericke | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: norma
Hi,
I had developed Catalog in 2010 before grass7 and updated it for grass 6.4,
6.5 & to 7. But since there is no much interest and another problem is
wxpython. Other developers needs to keep MapFrame as wx.Frame and I
completely support their decision. But wxPython doesnt allow to embed
wx.Frame
Hi,
I had asked list long back regarding integrated gui. please see this
thread[0]. What GRASS needs is to maitain current style and add integrated
ui as optional.
Btw, what do you mean by "unable to advance to a suitable single window".
if catalog is running then it should show up a single wind
Dear all,
Any body can tell me the progress of proposed single window developement
for GRASS GIS. Actually, I am C/C++ developer. I have not much knowledge
in Python. As RASAD give me the source code for GRASS CATALOG. I build it
successfuly. But from this I am unable to advance it to a suitable
Hi All,
As I discussed with markus Netler he pointed out the idea of having a pure
pixel identification module for GRASS GIS. This will be very helful for
spectral unmixing because pure pixels are found in the corners of PCA
space and since PCA transformed its spatial position is lost. see my oth
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
Absolutely Markus. Let's also keep in mind that comparing segmentation
results is a very tricky exercise. There's no such thing as a perfect
segmentation result IMHO.
Pierre
2013/2/12 Markus Metz :
> On Mon, Feb 11, 2013 at 8:18 PM, Pierre Roudier
> wrote:
>> Thanks Markus and Eric,
>>
>> I have
Thank you Anna,
i'll be happy to try any solution.
in the main time i opened a bug :
http://trac.osgeo.org/grass/ticket/1884
related to the cairodriver, is mac specific but not directly related to the gui
Massimo.
Il giorno 08/feb/2013, alle ore 06:28, Anna Kratochvílová
ha scritto:
> Hi
#1884: grass7 - cairodriver fails to detect right architecture - OSX 10.8
---+
Reporter: epifanio | Owner: grass-dev@…
Type: defect | Status: new
Priority: major
On Mon, Feb 11, 2013 at 8:18 PM, Pierre Roudier
wrote:
> Thanks Markus and Eric,
>
> I have similar feedback when testing on various SPOT5 scenes. XL results are
> not entirely identical of course, but reasonably similar, so I support
> Markus' decision.
I can make the results more similar, but o
On Mon, 11 Feb 2013 20:23:14 +0100
Margherita Di Leo wrote:
> FYI
Hello all!
stay tuned for OSGeo updates on GSoC. It's a good time for mentors and
students to get in touch with their favourite projects and start
working on the Ideas pages.
More info on last year's OSGeo participation here:
ht
FYI
-- Forwarded message --
From: Carol Smith
Date: Mon, Feb 11, 2013 at 8:02 PM
Subject: Google Summer of Code 2013
To: Google Summer of Code Announce <
google-summer-of-code-annou...@googlegroups.com>
Hi all,
We're pleased to announce that Google Summer of Code will be happen
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
Thanks Markus and Eric,
I have similar feedback when testing on various SPOT5 scenes. XL results
are not entirely identical of course, but reasonably similar, so I support
Markus' decision.
Cheers,
Pierre
On Feb 11, 2013 10:53 PM, "Markus Metz"
wrote:
> Hi all,
>
> I have tested again i.segmen
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
#1883: v.surf.rst gives bad result
+---
Reporter: dnewcomb| Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.0.0
#1883: v.surf.rst gives bad result
--+-
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect| Status: new
Priority: major | Milestone: 7.0.0
Seth,
I appreciate the effort. Working with large rasters, this will make a big
difference!
Doug
On Sun, Feb 10, 2013 at 9:18 PM, Seth Price wrote:
> They should. I didn't really make any changes to the calculations, I just
> rearranged the code to make it more processor and compiler friend
#1882: new query display needs to update on mouse click
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Mil
On Mon, Feb 11, 2013 at 12:27 PM, Markus Metz wrote:
> On Mon, Feb 11, 2013 at 11:30 AM, Rashad M
> wrote:
> > But I need the whole data and to do some geo processing over it.
>
> OK. In contrast to GADM v1, GADM v2 contains a lot of floating point
> representation errors in the coordinates, mos
On Mon, Feb 11, 2013 at 11:30 AM, Rashad M wrote:
> But I need the whole data and to do some geo processing over it.
OK. In contrast to GADM v1, GADM v2 contains a lot of floating point
representation errors in the coordinates, most probably created by the
software used to create GADM v2. You nee
But I need the whole data and to do some geo processing over it.
On Mon, Feb 11, 2013 at 3:18 PM, Markus Metz
wrote:
> On Mon, Feb 11, 2013 at 9:55 AM, Rashad M
> wrote:
> > Hi,
> >
> > I cant import very large data in GRASS7 && G6. it reads the features but
> > hangs with 98% Breaking Boundari
Markus Metz wrote:
> Hi all,
>
> I have tested again i.segment and discovered that for the NC Landsat
> 2000 imagery the module takes nearly 7 hours for reasonable
> segmentation. The i.segment.xl module does the same in 10 seconds. The
> region consists of 250 000 cells, not so much. In the docum
Hi all,
I have tested again i.segment and discovered that for the NC Landsat
2000 imagery the module takes nearly 7 hours for reasonable
segmentation. The i.segment.xl module does the same in 10 seconds. The
region consists of 250 000 cells, not so much. In the documentation it
says that processin
On Mon, Feb 11, 2013 at 9:55 AM, Rashad M wrote:
> Hi,
>
> I cant import very large data in GRASS7 && G6. it reads the features but
> hangs with 98% Breaking Boundaries when building topology
>
> I am using latest grass from svn maybe 3 days old
>
> If somebody needs to test for this problem you c
Hi,
I cant import very large data in GRASS7 && G6. it reads the features but
hangs with 98% Breaking Boundaries when building topology
I am using latest grass from svn maybe 3 days old
If somebody needs to test for this problem you can get data here[1]
[1] http://www.gadm.org/data2/gadm_v2_shp.
29 matches
Mail list logo
