.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-b
I'm much more in favour for out of core providers, for the same reasons
reported by Victor. Having only GDAL and QGIS algorithms in core will
reduce the number of available algorithms out of the box, but:
- from my experience - comprising years of feedbacks from the courses I
teach - the most
Congratulations! I've compiled my first GRASS when 5.0 was going to be
released... what a long way has been done meanwhile!
giovanni
Il 22/feb/2015 23:41 Paulo van Breugel p.vanbreu...@gmail.com ha
scritto:
Congratulations to all developers!!
On Sun, Feb 22, 2015 at 10:51 PM, Markus Neteler
Sorry for cross posting from grass-user but maybe here there are more
vector gurus :-)
I haven't been able to find an explanation to the meaning of the square
boxes that appear around my lines layer's nodes, when I display topological
informations on the map.
Just a curiosity: what/where is the python cartography module?
A long time away from GRASS made me miss lot of things...
2012/6/27 Martin Landa landa.mar...@gmail.com
2012/6/27 Michael Barton michael.bar...@asu.edu:
There is a python module needed to do previews. I forget what it is
called.
Ok, I see [1], but I didn't know PIL was somehow involved. Is it?
I'ma PIL lover :)
giovanni
http://trac.osgeo.org/grass/browser/grass/tags/release_20120219_grass_6_4_2/gui/wxpython/gui_modules/psmap.py
2012/6/27 Martin Landa landa.mar...@gmail.com
Hi,
2012/6/27 G. Allegri gioha
In 7.0, I've added nmin, nmax, nmedian and nmode functions which
ignore nulls.
Great Glynn!
Thanks.
giovannni
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
Following a thread I've opened on the grass-users list, I would like to
suggest a proposal to add a flag, to the r.mapcalc command, to discrd
NULL values when evaluating aggregation functions like max(), min(),
mode(), etc.
Looking into the code of, for example., the max() function [1], it seems
Shouldn't it be the default behavior?
I supposed it too, but it isn't ;)
giovanni
ciao madi
This would let us do filtering (with row/columns offsets) as it is done
in r.neighbors, where the NULL values are directly discarded.
giovanni
[1]
Hi. It's a long time since I built GRASS on Windows by myself, so forgive
my dummy questions...
I would like to build grass on windows with debug infos, to debug a couple
of things (inside the core and a plugin).I suppose I should use the -g
flag, but I cannot do it from ./configure CFLAGS=-g,
thanks martin, it seems to run ;)
giovanni
2012/3/26 Martin Landa landa.mar...@gmail.com
Hi,
2012/3/26 G. Allegri gioha...@gmail.com:
Hi. It's a long time since I built GRASS on Windows by myself, so
forgive my
dummy questions...
I would like to build grass on windows with debug
Thanks very much! ;)
giovanni
2011/12/1 Markus Neteler nete...@osgeo.org
On Thu, Dec 1, 2011 at 7:57 AM, Glynn Clements gl...@gclements.plus.com
wrote:
...
If you want to parse the output, set GRASS_MESSAGE_FORMAT=gui in the
environment when running the command and read from the
I resume (first as a repeat to myself) what I've learned from the various
email on the topic
Vectors can be:
LEVEL 1:
- no topology - very limited use
LEVEL 2:
- unclean topology - limited use
- clean topology - full support
I previously thought that LEVEL 2 was only possible for clean
Ops, wrong post. I wanted to send it to the users maling list.
I'll post it there.
sorry,
giovanni
2011/12/1 G. Allegri gioha...@gmail.com
I resume (first as a repeat to myself) what I've learned from the various
email on the topic
Vectors can be:
LEVEL 1:
- no topology - very limited
I've seen that the grass.script.core.percent() module method wraps the
g.message -p command.
It's ok when the work is done within the python code, but how to grab the
progress emitted by a GRASS command (i,e, G_percent)?
There are many ways to run a command from python. What is the most
Just for testing purposes I've installed GRASS 7 nightly build for Windows
from Martin.
I'm evaluating the python scripting system, and I've found that on my
Windows 7 machine no windows are opened inside the GUI for whatevere script.
E.g. v.report, v.db.join, etc. don't show up.
The problem seems
, then on trying to implement this
particular feature.
But as always, that's only my less than 2 cents worth...
Moritz
Moritz Lennert schrieb:
I don't want to make this discussion go on too long, but
On 20/04/10 13:38, G. Allegri wrote:
1 - we had to make a simple points in polygon count. The polygon
.
thanks,
giovanni
2010/4/21 Markus Metz markus.metz.gisw...@googlemail.com:
On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri gioha...@gmail.com wrote:
These are respectable points of view. As I've repeated many times in
this post, I don't expect Grass to work different. My only questions
With rapidly I meant: load data, do-the-op, save the results.
maybe using something like GEOS directly is more efficient in that case?
well, it can be for a user with some scripting/programming skills, not
for a medium end-user...
___
grass-dev
Yes, but the fundamental question here is: should the speed of these
operations be more important then their quality ?
The quality is always important. I think the question is: is topology
always required to guarantee it? The answar, IMHO, is no. In that
cases the quality doesn't depend on the
But even a simple overlay can give wrong results if the data is not
topologically clean... I personally cherish the fact that GRASS doesn't make
it easy to do things quick and dirty.
Probably we mean different things, or maybe I've msunderstood topology
in Grass. Spatial operators like Overlay
Is it correct to say that pseudo-topology is at feature level, while
full-topology is at layer level?
2010/4/20 G. Allegri gioha...@gmail.com:
But even a simple overlay can give wrong results if the data is not
topologically clean... I personally cherish the fact that GRASS doesn't make
, Chapter 6
http://portal.opengeospatial.org/files/?artifact_id=18242
2010/4/19 Markus Metz markus.metz.gisw...@googlemail.com
G. Allegri wrote:
I open a new post on the argument because it's something more general
that me and my collegues need to unsertstand.
I've tried to make the point
2010/4/19 Markus Metz markus.metz.gisw...@googlemail.com
G. Allegri wrote:
Hi Markus,
thanks for the clarifying reply.
For SF algorithms I mean those that can apply to SF structures, as meant
by the OGC definition. For example a simple clip based on the SF spatial
operators (like those
eyes;
On 19/04/10 17:46, G. Allegri wrote:
No problem, this is not what I expect. I just expect a user to be able
to import a polygonal layer, without worrying about topology correctness
(clean/build operations), and do spatial operations on it. Obviously the
correctness of results depend
?
thanks again,
giovanni
2010/4/6 Martin Landa landa.mar...@gmail.com:
[back to ML]
Hi,
2010/4/6 G. Allegri gioha...@gmail.com:
So it's not meant to be used for ogc simple featurer processing (like
in qgis or saga). The topo build step is required for processing. I
thought it was an option
I open a new post on the argument because it's something more general
that me and my collegues need to unsertstand.
I've tried to make the point with the various vector structures and
modes in grass7 and I admit to be a bit confused.
- v.external is meant to read ogr data sources without the
Hello,
it's a long time I'm away from Grass, because of various reasons. Some
days ago I've decided to come back to have a look to Grass7, and my
first thought/wish was: it would be great to have direct simple
features processing supported, along the native structures... and
that's what Martin
...@gmail.com:
Hi,
2010/4/6 G. Allegri gioha...@gmail.com:
I admit that this news has raised new interest in me, and some
collegues of mine. I've given a look at the code, to see what is
needed to make the v.* commands support direct ogr, but I haven't been
able to highlight where the magics is done
+1
I understand the importance and the need to give all the best to the
core dev, as there are many parts that need to be
mantained/updated/refactored/built (ie the raster core code in
qgis...), but I support a boost to the 'joints' of the systems
integration. as I think that their integration is
of
view. The best would be to have osgeo4w setup, and standalone NSI
installers... but I'm talking with no experience on what this would
require, or if it's possible.
I hope the discussion will go on.
2009/3/27 Moritz Lennert mlenn...@club.worldonline.be:
On 27/03/09 10:30, G. Allegri wrote
Anyway, IIUC Glynn and Jurgen:
the problem on mixing MSVC and MinGW built things (at C level) is
just a problem of a clean memory management (malloc/free). So, my
question is: would changing the build system (GNU make - cmake) solve
this? Or they're unrelated things?
2009/3/27 G. Allegri gioha
I am not aware of any postings in this regard from Marco.
Please point us to that to better understand the issues he found.
I've just asked him if he can partecipate to the discussion to explain this...
Question: Did you try to update the installer from Marco? Maybe
it works out of the box
...@norbit.de:
Hi Giovanni,
On Fri, 27. Mar 2009 at 12:36:43 +0100, G. Allegri wrote:
the problem on mixing MSVC and MinGW built things (at C level) is
just a problem of a clean memory management (malloc/free). So, my
question is: would changing the build system (GNU make - cmake) solve
Hello. The subject could rise an infinte flame, but it's just to grab
the attention!
I've digged into the windows wgi-grass world last days, and I see it's
in a stall moment.
1 - Many, in the osgeo4w dev group, is trying to make grass (built
with mingw) friend of the vc built software in the
could you elaborate on that? What's needed, what's missing in terms
of *deep refactoring*?
I'm not so expert to elaborate this. I've just gathered talks and
thought around MLs and chats. Someone says it shouldn't be so hard,
others say yes. I would like to know from developers (first of all
I try to summarize. Everybody wish to solve the grass and qgis-grass
windows build issue in the more feasable way. Two major streams are
there:
1 - do it inside osgeo4w, using the vc built libs and apps there
(from gdal to qgis). AFAIK there are problems with linking MinGW built
things and the
Dear all developers,
in these days me, and other users, are facing serious problems with
the actual status of grass (and qgis-grass plugin) over the Windows
Vista system. I've spent two days the give an insight in the structure
of the build environment for Windows, MinGW and MSVC, and with the hep
I've finally compiled a basic grass-6.4.0RC3 on Windows Vista from scratch
(also libraries), without wxpython and geos (I have to solve build errors).
Now g.proj.exe doesn't crash, so it seems a problem related to the actual
OSGeo4W stack...
___
IMPORTANT: I forgot to say that I've built gdal with MinGW, but I
suppose that in OSGeo4W it's built with MSVC, right?
A curiosity: has grass been built against the MSVC gdal?
2009/3/19 G. Allegri gioha...@gmail.com:
I've finally compiled a basic grass-6.4.0RC3 on Windows Vista from scratch
The next step is to compile GRASS from scratch on Vista to see if the
problem is in GRASS or related to the OSGeo4W packaging. That could take a
while but it needs done so hopefully it will get done.
I hope someone can do it (Marco Pasetti?), because I have little
experience on Windows (I'm
Hello list.
I've just setup grass from osgeo4w. I'm a Linux user but I need to
develop some grass scripts on windows.
When launching it from grass64.bat as tcltk iface, I obtain the
classic prompt for location. I try to set it from EPSG codes but when
I've choosen the name and the code, g.proj.exe
Sorry, I was going to answer. It was a typo in my version... don't know why
but svn update has made it!
thx anyway
2008/12/17 Martin Landa landa.mar...@gmail.com
Hi,
2008/12/17 G. Allegri gioha...@gmail.com:
I had a problem while I was compiling from develbranch6:
r.univar_main.c
I had a problem while I was compiling from develbranch6:
r.univar_main.c: In function 'set_params':
r.univar_main.c:37: error: 's' undeclared (first use in this function)
r.univar_main.c:37: error: (Each undeclared identifier is reported only once
r.univar_main.c:37: error: for each function it
A little patch to permit the use of multiple percentiles inside v.rast.stats
http://www.geospatial.it/allegri/v.rast.stats.diff
Giovanni
Index: v.rast.stats
===
--- v.rast.stats(revisione 33591)
+++ v.rast.stats
I didn't see the new versions of script. Wow, I've seen grass.py lib, very good!
Will all the scripts be converted?
2008/9/29 Glynn Clements [EMAIL PROTECTED]:
G. Allegri wrote:
A little patch to permit the use of multiple percentiles inside v.rast.stats
http://www.geospatial.it/allegri
Hi to everyone.
In the last period I've been working a lot with GRASS for my daily job, and
it permitted me to develop a series of wishes for the future...
I will share them in the GRASS 7 ideas collection but I would like to ask
some questions before:
VECTORS
1 - OGR datasources: one important
v.external?
http://grass.itc.it/grass62/manuals/html62_user/v.external.html
BTW, a r.external would be a great addition.
Hi Paolo,
I know v.external, but It's still a bit far from what the user
experience is in, let's say, Qgis/uDig/gvSIG/etc.
The main restriction is that it's read-only. It
I'm very much interested to the SWIG Python interface, as I'm
considering some investments to do with Grass functionalities. I'm
going to test the methods used by JGrass to interface Java with Grass
native commands, but I think it would be a great improvemente to
support it for Python too, as
I've read the long interesting discussion about 3d-polygons and TINs:
http://www.nabble.com/convert-3D-polygons-or-Tins-to-a-DEM--td14998420.html
AFAIU, code to manage the creation (and editing?) of 3d features, like
TINs, is still undergoing development.
I think this is a good moment to propose
, at 6:14 AM, G. Allegri wrote:
I would have asked the same question as Luca. Wouldn't it be more
profitable using QT, as it is already the way Python script are written in
QGis? I know the two projects are independent, but having a common GUI
language could improve the development of scripts
I would have asked the same question as Luca. Wouldn't it be more profitable
using QT, as it is already the way Python script are written in QGis? I know
the two projects are independent, but having a common GUI language could
improve the development of scripts in both the environments and the
,
2008/1/25, G. Allegri [EMAIL PROTECTED]:
I would have asked the same question as Luca. Wouldn't it be more
profitable
using QT, as it is already the way Python script are written in QGis? I
know
yes, that's true, it would be profitable at the end.
the two projects are independent, but having
53 matches
Mail list logo
