Re: [GRASS-dev] GRASS module version strictness (libgrass_gis)

[Benjamin Ducke]

Dear Markus:

On 12/03/2021 22:35, Markus Metz wrote:


On Fri, Mar 5, 2021 at 8:30 PM Benjamin Ducke <mailto:bendu...@fastmail.fm>> wrote:

 >
 > Dear Devs,
 >
 > I am trying to find a way to inject GRASS modules (C code)
 > compiled  in a GRASS 7 source tree into an already installed
 > version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
 > then copy into a GRASS 7.8.5 (i.e. exact version match)
 > installation, I get this:
 >
 > ERROR: Module built against version 2021-03-04T21:51:47+00:00 but 
trying to
 >         use version 2021-01-01T10:33:43+00:00. You need to rebuild 
GRASS GIS

 >         or untangle multiple installations.

GRASS uses the git revision to check if separately compiled modules are 
compatible with the current version. If the git revision is not 
available, the date of compilation is used instead. This is a safety 
measure to ensure binary compatibility. The idea of using the date of 
compilation as surrogate is targeted at branches under development and 
might not be appropriate for released versions that do not change any 
more. Apparently we need to distinguish between released versions and 
versions under development and adjust the check for binary compatibility 
accordingly.


Thanks for the explanation. This makes a lot of sense.
If it would be possible to somehow change the behaviour
of release version binaries in this regard, then I would
vote for checking against major, minor and revision
number at runtime, and:

1. Do nothing, if major, minor and revision of module and
GRASS libs are identical.

2. Warn, if revision numbers differ (but major and minor
are identical).

3. Throw an error, if major or minor versions differ.

This should result in acceptable and sage behaviour for
externally compiled modules.

Best,

Ben



Markus M

 >
 > This is coming from 'libgrass_gis'.
 >
 > Apparently, GRASS keeps exact timestamps of the binaries and
 > won't allow any mixing.
 >
 > Is it really necessary to be this strict about build versions?
 > Would it be possible to relax this, so that a module compiled with
 > GRASS 7.8.a can be run under GRASS 7.8.b?
 >
 > I worked around this issue with some LD_LIBRARY_PATH "magic",
 > and even running 7.8.1 binaries in a 7.8.5 installation seems
 > to work flawlessly.
 >
 > Background: I am trying to find a way to provide sets of
 > additional modules, that are not part of the GRASS base
 > distribution, for injection into an existing GRASS installation.
 > This is exceedingly hard if all dependencies have to be
 > exact matches; especially if the modules are to be injected
 > into a version of GRASS bundled with QGIS.
 >
 > Best,
 >
 > Ben
 >
 > ___
 > grass-dev mailing list
 > grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
 > https://lists.osgeo.org/mailman/listinfo/grass-dev 
<https://lists.osgeo.org/mailman/listinfo/grass-dev>


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS module version strictness (libgrass_gis)

[Benjamin Ducke]

Hi,

On 05/03/2021 21:14, Jürgen E. Fischer wrote:

Hi,

On Fri, 05. Mar 2021 at 20:23:47 +0100, Benjamin Ducke wrote:

I am trying to find a way to inject GRASS modules (C code)
compiled  in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:

ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.

This is coming from 'libgrass_gis'.



Apparently, GRASS keeps exact timestamps of the binaries and
won't allow any mixing.


Note: In OSGeo4W testing I've disabled that check in lib/gis/gisinit.c.  The
DLLs already carry the major and minor version number in their name already.


Ha! I was at exactly that point, as well. Good to know that I
am not just imaging an obstacle here.



I guess it's there because the ABI could change anytime - even in point
releases - and the libs are only meant for GRASS itself AFAIK.


That is probably the reason. But as it stands, this strictness
even prevents mixing of binaries from the same point release,
if the modules were not compiled at the same time as the GRASS libs.

I would also expect the fundamental GRASS lib (libgrass_gis) to
be quite stable as far as the ABI is concerned. GRASS is a very
conservative design -- and has done extremely well by it over
the decades.



But I'd also think that the chance for breakages is reasonable small enough to
do this.  Using the libs with a different compiler in the QGIS plugin like we
do is probably a bigger risk anyway.


Yes, that's another "mixing case" that I did not even
think about. C objects are so wonderfully simple and
flexible to link. Why not allow a little more freedom
here?

How about changing the behaviour of libgrass_gis to issue
a warning as along as the major and minor revisions match,
and an error only if that is not the case?

Best,

Ben




Jürgena.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS module version strictness (libgrass_gis)

[Benjamin Ducke]

Dear Devs,

I am trying to find a way to inject GRASS modules (C code)
compiled  in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:

ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
   use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
   or untangle multiple installations.

This is coming from 'libgrass_gis'.

Apparently, GRASS keeps exact timestamps of the binaries and
won't allow any mixing.

Is it really necessary to be this strict about build versions?
Would it be possible to relax this, so that a module compiled with
GRASS 7.8.a can be run under GRASS 7.8.b?

I worked around this issue with some LD_LIBRARY_PATH "magic",
and even running 7.8.1 binaries in a 7.8.5 installation seems
to work flawlessly.

Background: I am trying to find a way to provide sets of
additional modules, that are not part of the GRASS base
distribution, for injection into an existing GRASS installation.
This is exceedingly hard if all dependencies have to be
exact matches; especially if the modules are to be injected
into a version of GRASS bundled with QGIS.

Best,

Ben

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] build system: module overlinking?

[Benjamin Ducke]

Dear Devs:

$ ldd r.surf.area

.. produces the list of linked libraries below.
AFAICT, this includes GDAL/OGR and all of their dependencies.

Should it not be enough for "r.surf.area" [insert any other
r.*/v.* module here] to link against the GRASS libs (plus
a handful of essential system runtime libs)?

Best,

Ben

---


linux-vdso.so.1
libgrass_raster.7.8.so => /opt/grass/lib/libgrass_raster.7.8.so
libgrass_gis.7.8.so => /opt/grass/lib/libgrass_gis.7.8.so
libm.so.6 => /usr/lib/libm.so.6
libc.so.6 => /usr/lib/libc.so.6
libgrass_gproj.7.8.so => /opt/grass/lib/libgrass_gproj.7.8.so
libdl.so.2 => /usr/lib/libdl.so.2
libgrass_datetime.7.8.so => /opt/grass/lib/libgrass_datetime.7.8.so
libz.so.1 => /usr/lib/libz.so.1
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
libzstd.so.1 => /usr/lib/libzstd.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libgdal.so.26 => /usr/lib/libgdal.so.26
libproj.so.15 => /usr/lib/libproj.so.15
libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
libpoppler.so.107 => /usr/lib/libpoppler.so.107
libjson-c.so.5 => /usr/lib/libjson-c.so.5
libfreexl.so.1 => /usr/lib/libfreexl.so.1
libgeos_c.so.1 => /usr/lib/libgeos_c.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libxerces-c-3.2.so => /usr/lib/libxerces-c-3.2.so
libopenjp2.so.7 => /usr/lib/libopenjp2.so.7
libnetcdf.so.18 => /usr/lib/libnetcdf.so.18
libhdf5.so.200 => /usr/lib/libhdf5.so.200
libgif.so.7 => /usr/lib/libgif.so.7
libjpeg.so.8 => /usr/lib/libjpeg.so.8
libgeotiff.so.5 => /usr/lib/libgeotiff.so.5
libtiff.so.5 => /usr/lib/libtiff.so.5
libpng16.so.16 => /usr/lib/libpng16.so.16
libcfitsio.so.9 => /usr/lib/libcfitsio.so.9
libpq.so.5 => /usr/lib/libpq.so.5
librt.so.1 => /usr/lib/librt.so.1
libspatialite.so.7 => /usr/lib/libspatialite.so.7
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0
libpcre.so.1 => /usr/lib/libpcre.so.1
libcurl.so.4 => /usr/lib/libcurl.so.4
libxml2.so.2 => /usr/lib/libxml2.so.2
liblzma.so.5 => /usr/lib/liblzma.so.5
libicui18n.so.68 => /usr/lib/libicui18n.so.68
libicuuc.so.68 => /usr/lib/libicuuc.so.68
libicudata.so.68 => /usr/lib/libicudata.so.68
libmariadb.so.3 => /usr/lib/libmariadb.so.3
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
liblcms2.so.2 => /usr/lib/liblcms2.so.2
libsmime3.so => /usr/lib/libsmime3.so
libnss3.so => /usr/lib/libnss3.so
libplc4.so => /usr/lib/libplc4.so
libnspr4.so => /usr/lib/libnspr4.so
libgeos-3.8.1.so => /usr/lib/libgeos-3.8.1.so
libnsl.so.2 => /usr/lib/libnsl.so.2
libhdf5_hl.so.200 => /usr/lib/libhdf5_hl.so.200
libsz.so.2 => /usr/lib/libsz.so.2
libmpi.so.40 => /usr/lib/openmpi/libmpi.so.40
libssl.so.1.1 => /usr/lib/libssl.so.1.1
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
libnghttp2.so.14 => /usr/lib/libnghttp2.so.14
libidn2.so.0 => /usr/lib/libidn2.so.0
libssh2.so.1 => /usr/lib/libssh2.so.1
libpsl.so.5 => /usr/lib/libpsl.so.5
libkrb5.so.3 => /usr/lib/libkrb5.so.3
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
libcom_err.so.2 => /usr/lib/libcom_err.so.2
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
libnssutil3.so => /usr/lib/libnssutil3.so
libplds4.so => /usr/lib/libplds4.so
libtirpc.so.3 => /usr/lib/libtirpc.so.3
libaec.so.0 => /usr/lib/libaec.so.0
libopen-rte.so.40 => /usr/lib/openmpi/libopen-rte.so.40
libopen-pal.so.40 => /usr/lib/openmpi/libopen-pal.so.40
libutil.so.1 => /usr/lib/libutil.so.1
libhwloc.so.15 => /usr/lib/libhwloc.so.15
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2
libsasl2.so.3 => /usr/lib/libsasl2.so.3
libunistring.so.2 => /usr/lib/libunistring.so.2
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libudev.so.1 => /usr/lib/libudev.so.1

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Port Dempster-Shafer module from grass6 to grass7

[Benjamin Ducke]

Hi,

I wrote most of that code almost 20 years ago and then
ported it to GRASS 6 about 6-8 years later. That's the
kind of antiquity you must be prepared to face.

Otherwise, the GRASS 6 API  related code is actually quite
simple. I don't expect much trouble porting it to 7.
But do expect some code quality issues.

I would be delighted if someone showed this code some
love, and I will be available for advice if needed. You can
contact me by PM, and I will make sure that you have the
latest version of the source code ( it's been a while since
I last sync'd with the add-ons SVN).

Best,

Ben

On Wed, Jun 12, 2019, at 17:51, Moritz Lennert wrote:
> Hi,
> 
> Colleagues of mine would be interested in the dst addon family of 
> modules that currently exists for GRASS 6, but would need it for GRASS 
> 7. Does anyone have ann idea how difficult it would be to port them to 
> GRASS7 ?
> 
> Moritz
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Spatial clustering of vector objects?

[Benjamin Ducke]

On 04/05/17 19:22, Markus Neteler wrote:
> Hi,
> 
> in order to parallelize some heavy computation I was wondering how to
> do spatial clustering of vector objects, i.e. building footprints
> (vector polygons).
> 
> I have to perform zonal statistics on thousands of buildings and would
> like to split them up into "tiles" and then run the computation in
> parallel for each tile.
> 
> The examples in v.cluster look somehow promising
> https://grass.osgeo.org/grass72/manuals/v.cluster.html
> 
> but in the best case each "tile" would contain a similar amount of
> buildings in order to balance the computation across the CPUs.

Hi,

I think that you would need to partition
space into overlapping tiles, with the
amount of overlap depending on the maximum
distance parameter of the clustering algorithm.
Otherwise you would get a serious edge effect
in each tile.

Prior to spatial clustering, you could use a cluster
algorithm that aims to produce clusters with
(nearly) equal number of points for "tiling":

https://stats.stackexchange.com/questions/8744/clustering-procedure-where-each-cluster-has-an-equal-number-of-points

You would then select the points for each
cluster, buffer their convex hull by the max
distance of your spatial cluster algorithm
and set the working region for each "tile" to
be the bounding box of the buffered convex
hull (don't forget to catch all points from
all other clusters that fall within the "tile"
and add them to the working region's set).

If that works, please make it a GRASS add-on...

Regarding building footprints, I guess another
tricky part is how to represent them as
points: Centroids? Outer edge vertices? Both?

Oh, by the way: A fellow computer scientist
who works a lot with concurrent processing
once told me that the frequently used

number of processes = number of CPUs/cores

is actually not ideal! Apparently, modern
CPU schedulers are optimized to handle many
more processes than there are CPUs/cores,
and if the two counts match, then you can
get fringe situations where processes keep
getting transferred between cores, which
incurs a huge performance penalty. His
recommendation was to use a factor of
about 2.5 (times more processes than cores).

I never got around to testing his theory,
but if you have the time, I'd love to know!

Best,

Ben

> 
> Any idea?
> 
> thanks,
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Hole / NULL filling module naming

[Benjamin Ducke]

On 19/04/17 09:31, Maris Nartiss wrote:
> Hello list,
> as r.fill.gaps add on got ported from G6, it sparked my interest in
> hole (NULL area) filling. At the moment there is one dedicated tool
> r.fillnulls, but I would put my +1 of moving r.fill.gaps to main trunk
> (with some light changes). Still it raises a question - how it should
> be named? And in more general - how other hole filling modules should
> be named? Answer is not so easy, as current r.fillnulls is a Python
> script thus any new C based method would result in a separate module.
> 
> One option would be splitting everything into separate modules based
> on method/method group. Thus r.fillnulls could become i.e.
> r.fill.spline (as at the moment all options are spline based) and
> r.fill.gaps could become i.e. r.fill.stats. Such approach would allow
> to add new C or Py modules as r.fill.idw, r.fill.nn, r.fill.nat etc.
> 

I would be in favour of that option.
A common naming scheme for modules with similar
purposes makes good sense.

Best,

Ben

> Second option would be just integrate new methods into r.fillnulls. At
> the moment module already is a wrapper script around other modules
> thus adding extra methods + their parameter groups would not be too
> hard thus not creating tens of small modules. Other plus would be
> keeping its "cool"/easy to understand name. Downside of this approach
> would be r.fillnulls becoming a real monster with a gazzillion of
> parser options.
> 
> Of course, for the lifetime of G7, r.fillnulls will have to remain as
> is to provide backwards compatibility.
> 
> Wbr,
> Māris.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Benjamin Ducke]

On 16/04/17 03:40, Vaclav Petras wrote:
> 
> On Sat, Apr 15, 2017 at 8:32 AM, Benjamin Ducke  <mailto:bendu...@fastmail.fm>> wrote:
> 
> The thing is: I originally developed this module for
> gradiometer data. That data is very noisy and has
> high local variation. Interpolating that type of
> data while preserving original measurements will
> usually result in unsatisfactory output. Also note
> that the smoothing increases with the interpolation
> radius. For tiny holes in LiDAR data, try "distance=1"
> or "2". Of course, LiDAR data probably has different
> properties and does not need low-pass filtering
> like gradiometer data. So try "-p" to preserve the
> original values.
> 
> An alternative would be to invert the behaviour of
> the module and assume "-p" by default.
> 
> I don't work with LiDAR data myself, but I would very
> interested to know your results!
> 
> 
> 
> I've added a figure which shows the r.slope.aspect products from the
> surface without and with -p. You can see that the smoothing gives
> significantly different results and probably better ones. I had the same
> experience in past when trying to patch result of r.neighbors with the
> original raster. Perhaps using smaller distance as you say or greater
> power would help, but I haven't tested that yet.

I find the results for "curvature" most interesting.
In the unsmoothed LiDAR data, that metric is basically useless.

If I understand correctly, then slope, aspect
and curvature are all computed within a small
neighbourhood of cells. So if LiDAR data is
also noisy by nature, then it is not surprising
that these metrics are all distorted by strongly
fluctuating local means.

Please try experimenting with the power parameter,
if you have the time. In theory, this should allow
you to interpolate over larger distances with less
of a low-pass effect (or the other way around,
depending on what you want to achieve).

> 
> I managed to commit just the figure its caption. If somebody gets to it,
> please extent the section.

I will update the HTML page, including a more
prominent mentioning of the default smoothing.
I also found some small typos that need fixing.

Best,

Ben
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Benjamin Ducke]

On 15/04/17 14:57, Markus Neteler wrote:
> 
> On Apr 15, 2017 2:52 PM, "Vaclav Petras"  <mailto:wenzesl...@gmail.com>> wrote:
>>
>> On Sat, Apr 15, 2017 at 8:03 AM, Markus Neteler  <mailto:nete...@osgeo.org>> wrote:
>> >
>> > > it is nice to see porting of old addons.
>> > > As you added an example with LiDAR data - it is too large. Reduce its
>> > > size as default module help tab is much more narrow.
>> >
>> > The HTML code currently is this:
>> >
>> >src="r_fill_gaps_02.png" alt="Gaps filled">
>>
>>
>> These are 250x232,
> 
> Would it be possible to have larger pics here? I guess they come from
> Benjamin?

No, the ones I submitted are really tiny.
The new LiDAR images are much larger. They
use the "width=" HMTL attribute, so they show
up much smaller on screen than they actually
are. Supposedly, the wxPython HTML renderer
does not apply "width=" correctly and does not
resize the image on the fly. However,
"Submitting/Docs" seems to assume that "width="
_will_ be processed correctly. So maybe the
best "fix" would be to add a statement to the
Wiki that images should be resized with an
external graphics editor (to 600 pixels width
or less) before including them in HTML man pages.

Cheers,

Ben

> 
>> so I assume you mean r_fill_gaps_lidar.png.
>>
>> > Please use the img code as per submitting docs style guide in trac.
>>
>> The current code is:
>>
>> 
>> 
>> 
>>
>> which is almost exactly the following from Submitting/Docs [1]:
> 
> Ah I see... I'm mostly on mobile currently due to traveling, hence no
> easy reading of commit msgs.
> 
>> 
>> 
>> 
>>
>> The submitting guide does not consider the wxPython GUI manual tab
> which doesn't understand more advanced HTML correctly. Please advise on
> the next steps.
> 
> Ok just ignore my comment :)
> 
> Markus
> 
>> Vaclav
>>
>> [1] https://trac.osgeo.org/grass/wiki/Submitting/Docs
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Benjamin Ducke]

Hi,

Regarding the the smoothing, the description
states:

"Flags:

[..]

-p
Preserve original cell values
By default original values are smoothed"

The first paragraph under "DESCRIPTION" says:

"Alternatively, setting the -p flag will preserve the original cell values."

Is that not clear enough? If you want then I can add
a more prominent statement at the beginning of the
help page.

The thing is: I originally developed this module for
gradiometer data. That data is very noisy and has
high local variation. Interpolating that type of
data while preserving original measurements will
usually result in unsatisfactory output. Also note
that the smoothing increases with the interpolation
radius. For tiny holes in LiDAR data, try "distance=1"
or "2". Of course, LiDAR data probably has different
properties and does not need low-pass filtering
like gradiometer data. So try "-p" to preserve the
original values.

An alternative would be to invert the behaviour of
the module and assume "-p" by default.

I don't work with LiDAR data myself, but I would very
interested to know your results!

Best,

Ben


On 15/04/17 13:51, Maris Nartiss wrote:
> Hello,
> it is nice to see porting of old addons.
> As you added an example with LiDAR data - it is too large. Reduce its
> size as default module help tab is much more narrow.
> A bigger problem is the modules description - as I was checking the
> output of module, it is reinterpolating all values instead of just
> filling gaps. Thus the result is smoothened instead of just being
> filled. This is in a sharp contrast to r.fill.nulls and thus should be
> stressed out.
> 
> Thanks for a good work!
> Māris.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] custom CRS

[Benjamin Ducke]

On 19/03/17 20:11, Paulo van Breugel wrote:
> 
> 
> On 19/03/2017 12:27, Benjamin Ducke wrote:
>> On 18/03/17 12:15, Paulo van Breugel wrote:
>>>
>>> On 18-03-17 10:06, Paulo van Breugel wrote:
>>>> Dear all,
>>>>
>>>> I have a shapefile which is in CRS ESRI:37203 [1], which is defined in
>>>> the prj file as
>>>>
>>>> GEOGCS["GCS_Everest_India_Nepal",DATUM["D_Everest_India_Nepal",SPHEROID["Everest_Definition_1962",6377301.243,300.8017255]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
>>>>
>> [SNIP]
>>
>>>> +proj=longlat +a=6377301.243 +b=6356100.2284
>>>> +towgs84=295,736,257,0,0,0,0 +no_defs
>> Are you sure that your "+towgs84" parameters are correct?
>> It seems to me that you intend to apply a three parameter
>> transformation, but you are specifying a seven parameter
>> transform with the scaling (last parameter) set to "0",
>> which might have unintended consequences.
> Good question. I am not sure, I have copied that from
> https://github.com/klokantech/epsg.io/issues/49 (the same is given in
> [2]). This is not my area of expertise, so any tips (for dummies) how I
> can test or find out more about this would be great. 

Because your source system does not use the WGS84
datum, you should specify a datum transform. This is
assuming that you wish to reproject your data at some
point from the Indian Grid System into something more
modern, such as UTM with WGS84 datum. If you will
never need to reproject, then you can just ignore all
of the following.

Re. the datum transformation:
You'll know there is a problem when you get a result
with rather lousy accuracy after reprojection. I would
expect a simple three parameter datum transform to give
you ca. 5m of result accuracy.

Simple datum transformations have three parameters:

1-3: x/y/z translations

... or an additional four (more accurate):

4-6:  x/y/z rotations
7: scaling

It's a common mistake to set the seventh parameter
to "0", believing that this means "skip this"
(and by "common" I mean: I've done this myself before).
This is true for parameters 1-6 (translating or rotating
by "0" does "nothing"). But it is not true for 7!
Scaling a number by "0" sets its value to "0". Scaling
by "1" is the operation that "does nothing".

To be on the safe side, specify only the three parameters
that your datum transform actually has:

+towgs84=295,736,257

> I have just send an
> email forwarding your question to the person that proposed the proj
> definition, so hopefully I'll get some useful feedback.

This seems to be a rather nice page:

http://kanchu_deep.tripod.com/igintro.htm

It has the three parameters for your datum transform
plus a bunch of very useful literature at the bottom
of the page.

Best,

Ben

> 
>>   To specify a three parameter datum transform:
>>
>> +towgs84=295,736,257
>>
>> If you really want to specify all seven parameters, but
>> want only the first three to take effect:
>>
>> +towgs84=295,736,257,0,0,0,1
>>
>> Best,
>>
>> Ben
>>
>>>> Question 2: In QGIS it is possible to define a custom CRS using the
>>>> above. Can I do this in GRASS as well, and if so, how? Or can / should
>>>> I add this to the datum information files in $GISBASE/etc/proj/ogr_csv?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Paulo
>>>>
>>>>
>>>> [1] https://epsg.io/37203
>>>> [2]
>>>> https://disqus.com/home/discussion/qgistutorials/georeferencing_topo_sheets_and_scanned_maps/#comment-1426454689
>>>>
>>> A link that provides further relevant information
>>>
>>> https://github.com/klokantech/epsg.io/issues/49
>>>
>>>
>>>
>>>
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] custom CRS

[Benjamin Ducke]

On 18/03/17 12:15, Paulo van Breugel wrote:
> 
> 
> On 18-03-17 10:06, Paulo van Breugel wrote:
>> Dear all,
>>
>> I have a shapefile which is in CRS ESRI:37203 [1], which is defined in
>> the prj file as
>>
>> GEOGCS["GCS_Everest_India_Nepal",DATUM["D_Everest_India_Nepal",SPHEROID["Everest_Definition_1962",6377301.243,300.8017255]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

[SNIP]

>> +proj=longlat +a=6377301.243 +b=6356100.2284
>> +towgs84=295,736,257,0,0,0,0 +no_defs

Are you sure that your "+towgs84" parameters are correct?
It seems to me that you intend to apply a three parameter
transformation, but you are specifying a seven parameter
transform with the scaling (last parameter) set to "0",
which might have unintended consequences.

To specify a three parameter datum transform:

+towgs84=295,736,257

If you really want to specify all seven parameters, but
want only the first three to take effect:

+towgs84=295,736,257,0,0,0,1

Best,

Ben

>>
>> Question 2: In QGIS it is possible to define a custom CRS using the
>> above. Can I do this in GRASS as well, and if so, how? Or can / should
>> I add this to the datum information files in $GISBASE/etc/proj/ogr_csv?
>>
>>
>> Regards,
>>
>> Paulo
>>
>>
>> [1] https://epsg.io/37203
>> [2]
>> https://disqus.com/home/discussion/qgistutorials/georeferencing_topo_sheets_and_scanned_maps/#comment-1426454689
> 
> A link that provides further relevant information
> 
> https://github.com/klokantech/epsg.io/issues/49
> 
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X 10.11)

[Benjamin Ducke]

ent 
>>>> University of North Carolina at Chapel Hill
>>>> 
>>>>> On Oct 8, 2015, at 8:14 PM, grass-dev-requ...@lists.osgeo.org
>>>>> wrote:
>>>>> 
>>>>> From: Michael Barton  Date: October
>>>>> 8, 2015 at 8:07:58 PM EDT To: GRASS developers
>>>>> grass-developers , "grass-user
>>>>> grass-user"  Subject: [GRASS-dev]
>>>>> WARNING TO MAC USERS - WAIT UPDATING TO EL CAPITAN (OS X
>>>>> 10.11)
>>>>> 
>>>>> 
>>>>> I've had reports of GRASS not running for users updating to
>>>>> El Capitan. There is a possible workaround, but it is
>>>>> cumbersome and not guaranteed to work. I recommend that you
>>>>> do wait to update while we try to solve this.
>>>>> 
>>>>> I've also heard that El Capitan breaks R.
>>>>> 
>>>>> Michael  C. Michael Barton Director,
>>>>> Center for Social Dynamics & Complexity Professor of
>>>>> Anthropology, School of Human Evolution & Social Change Head,
>>>>> Graduate Faculty in Complex Adaptive Systems Science Arizona
>>>>> State University
>>>>> 
>>>>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) 
>>>>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC) www:
>>>>> http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>> 
>>> 
>> 
> 
> - William Kyngesburye  
> http://www.kyngchaos.com/
> 
> All generalizations are dangerous, even this one.
> 
> 
> ___ grass-dev mailing
> list grass-dev@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] point cloud analysis: new features

[Benjamin Ducke]

On 08/01/15 23:46, Markus Metz wrote:

[..]

>> Thanks Markus, this is excellent progress.
>> It seems to me that the approximation of cluster shapes from grouped
>> points is a generic problem that would best be solved with a separate
>> module. As long as the shapes are roughly convex, the existing v.hull
>> should work fine. For concave shapes, AFAIK things become messy because
>> common methods such as alpha shapes require the user to provide
>> threshold values.
> 
> This is true, but v.concave.hull [0] could help ;-)
> 
> Markus M
> 
> [0] 
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.concave.hull
> 

Wow. And it's been there for a while. How could I not see that?
I think it's high time that I switch from GRASS 6 to 7.

Nevertheless, since you did all that work on v.cluster in GRASS 6,
maybe it would be worth implementing this:

http://grasswiki.osgeo.org/wiki/Create_concave_hull

... in a GRASS 6 shell script?

I am looking forward to trying the new clustering algorithms,
especially "density" and "optics2"

Many thanks,

Ben


-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] point cloud analysis: new features

[Benjamin Ducke]

On 04/01/15 23:00, Paulo van Breugel wrote:
> Tried it out, and it works like a charm, great!
> 
> One question/request, would it be terribly difficult to add an option to
> compute an user-defined number of clusters of equal size?
> 

I think you are looking for a completely different algorithm
there. There are many clustering methods that will produce
exactly k clusters. But what do you mean by size: number of
points per cluster or spatial extent/area?

In both cases, I am not sure how you would reconcile the
two opposing goals: (A) find the actual cluster shapes,
(B) make the cluster shapes so that all clusters are of
equal size.

(please see also my comment to Markus below).

> 
> 
> On Sun, Jan 4, 2015 at 9:02 PM, Markus Metz
> mailto:markus.metz.gisw...@gmail.com>>
> wrote:
> 
> 
> Done in trunk r63952 as v.cluster. It is not a GRASS7 addon because it
> does not work with G7.0. At the moment it only identifies and labels
> clusters. Connectivity graphs and cluster shapes are not implemented.
> In future, I would like to add OPTICS because OPTICS can better handle
> different clusters with different densities.
>

Thanks Markus, this is excellent progress.
It seems to me that the approximation of cluster shapes from grouped
points is a generic problem that would best be solved with a separate
module. As long as the shapes are roughly convex, the existing v.hull
should work fine. For concave shapes, AFAIK things become messy because
common methods such as alpha shapes require the user to provide
threshold values.

Cheers,

Ben

> Markus M
> 
> >
> > There is a reference implementation (albeit in Java) that you can
> > use to compare it with other clustering algorithms:
> >
> >   http://elki.dbs.ifi.lmu.de/
> >
> > An implementation in C (that I have not tried) is here:
> >
> >   https://github.com/siddharth950/DBSCAN
> >
> > The one drawback of DBSCAN is that it needs an efficient spatial
> > index to perform well -- and you have just taken care of that!
> >
> >> - point cloud thinning: a sample can be generated from a large point
> >> cloud by specifying a minimum distance between sample points. To be
> >> implemented.
> >>
> >> The new k-d tree is now used by v.clean tool=snap
> (Vect_snap_lines()),
> >> reducing both memory consumption and processing time.
> >>
> >
> > I would also like to point out that SAGA GIS is moving into
> > the same direction, i.e. more efficient processing of very
> > large point clouds. The latest release includes a number
> > of new point cloud tools. Perhaps it's worth a look.
> >
> > Most importantly, SAGA GIS has introduced a new file format,
> > the SAGA Pointcloud (.spc) format. It is compact and yet
> > flexible enough for a variety of purposes. I recommend to
> > consider implementing import/export of this format in GRASS 7,
> > preferably not via v.in.ogr, to avoid the OGR model conversion
> > overhead.
> >
> > If you think this would be an interesting option, then you can
> > find a summary on our tracker:
> >
> >   http://gvsigce.sourceforge.net/mantis/view.php?id=595
> >
> > (we are going to implement ".spc" in gvSIG CE, as well).
> >
> > Best wishes,
> >
> > Ben
> >
> >>
> >> More technical:
> >> the new k-d tree finds the exact nearest neighbor(s), not some
> >> approximation. It supports up to 255 dimensions. It is dynamic, i.e.
> >> points can be inserted and removed at any time. It is balanced to
> >> improve search performance. It provides k nearest neighbor search
> >> (find k neighbors to a given coordinate) as well as radius or
> distance
> >> search (find all neighbors within radius, i.e. not farther away than
> >> radius to a given coordinate).
> >>
> >> Markus M
> >> ___
> >> grass-dev mailing list
> >> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> >
> >
> >
> > --
> > Dr. Benjamin Ducke
> > {*} Geospatial Consultant
> > {*} GIS Developer
>     >
>     > Spatial technology for the masses, not the classes:
> > experience free and open source GIS at http://gvs

Re: [GRASS-dev] point cloud analysis: new features

[Benjamin Ducke]

Hi Markus,

On 01/01/15 22:18, Markus Metz wrote:
> Hi all,
> 
> a new spatial index for point data is available in lib/btree2: a
> multidimensional search tree, also known as k-d tree.
>

Excellent news.

> What is it good for:
> 
> - nearest neighbor statistics: test if points are randomly
> distributed. The current GRASS addon v.nnstat uses an external k-d
> tree from PCL (which in turn uses flann) which finds the approximate,
> not the exact nearest neighbor. The new GRASS-native k-d tree always
> finds the real nearest neighbor.
> 
> - spatial cluster analysis: a point cloud can be partitioned into
> separate clusters where points within each cluster are closer to each
> other than to points of another cluster. To be implemented.
>

I suggest implementing DBSCAN: http://en.wikipedia.org/wiki/DBSCAN
It is density-based and thus produces more useful results than
centroid-based methods (k-means and relatives). It can actually
trace the shapes of spatial clusters (even concave ones) and does
not require a priori knowledge about the number of clusters. It
can also handle noise.

There is a reference implementation (albeit in Java) that you can
use to compare it with other clustering algorithms:

  http://elki.dbs.ifi.lmu.de/

An implementation in C (that I have not tried) is here:

  https://github.com/siddharth950/DBSCAN

The one drawback of DBSCAN is that it needs an efficient spatial
index to perform well -- and you have just taken care of that!

> - point cloud thinning: a sample can be generated from a large point
> cloud by specifying a minimum distance between sample points. To be
> implemented.
> 
> The new k-d tree is now used by v.clean tool=snap (Vect_snap_lines()),
> reducing both memory consumption and processing time.
>

I would also like to point out that SAGA GIS is moving into
the same direction, i.e. more efficient processing of very
large point clouds. The latest release includes a number
of new point cloud tools. Perhaps it's worth a look.

Most importantly, SAGA GIS has introduced a new file format,
the SAGA Pointcloud (.spc) format. It is compact and yet
flexible enough for a variety of purposes. I recommend to
consider implementing import/export of this format in GRASS 7,
preferably not via v.in.ogr, to avoid the OGR model conversion
overhead.

If you think this would be an interesting option, then you can
find a summary on our tracker:

  http://gvsigce.sourceforge.net/mantis/view.php?id=595

(we are going to implement ".spc" in gvSIG CE, as well).

Best wishes,

Ben

> 
> More technical:
> the new k-d tree finds the exact nearest neighbor(s), not some
> approximation. It supports up to 255 dimensions. It is dynamic, i.e.
> points can be inserted and removed at any time. It is balanced to
> improve search performance. It provides k nearest neighbor search
> (find k neighbors to a given coordinate) as well as radius or distance
> search (find all neighbors within radius, i.e. not farther away than
> radius to a given coordinate).
> 
> Markus M
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

[Benjamin Ducke]

On 14/11/14 14:14, Helmut Kudrnovsky wrote:
> NikosAlexandris wrote
>> What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and 
>> why should I prefer for my script(s)?
>>
>> Is there a step-by-step run-through of all options for composing header 
>> definitions?
>>
>> -- 
>> Nikos
>> ___
>> grass-dev mailing list
> 
>> grass-dev@.osgeo
> 
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> see
> 
> http://grass.osgeo.org/programming7/gis_8h.html#a5521b5269c52afe64e5051348b08fc69
> 

But that table doesn't really answer the question,
does it? For both "G_OPT_R_INPUT" and "G_OPT_R_MAP"
it lists "old input raster map". AFAIU, "G_OPT_R_MAP"
is for modules that use only one input raster map.
In those cases, the corresponding input option should
be named "map=". "G_OPT_R_INPUT" would then be for
modules that have either several raster map inputs or
raster and vector maps as inputs. The corresponding
input options would then be called "raster=" and
"vector=" in case of exactly one raster and one vector
input map. Further special cases are covered by
"G_OPT_R_BASE", "G_OPT_R_ELEV", etc.: They all exist
for semantical purposes. All of them stand for raster
input maps.

Ben

> 
> 
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/G-OPT-R-MAP-vs-G-OPT-R-INPUT-tp5173026p5173030.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Topographic prominence in GRASS

[Benjamin Ducke]

Well, there is already r.prominence:

http://grass.osgeo.org/grass65/manuals/addons/r.prominence.html

See also this older mailing list post:

http://lists.osgeo.org/pipermail/grass-user/2009-November/053220.html

The source code in the Add-ons repository seems outdated.
I have attached a more recent version in which I have outsourced
the normalization functions to a separate module (r.normalize),
also attached.

I doubt that r.prominence captures the entire concept of
"prominence" as used in mountaineering, but maybe it's a
starting point.

Best,

Ben


On 21/10/14 10:28, Martin Landa wrote:
> Hi all,
> 
> when searching for a suitable topic (smaller project) for one student
> of mine I found [1,2].
> 
> """
> Create a new GRASS module to find the topographic_prominence of peaks
> from a raster elevation map within the region. (probably this would
> only make up 1/4 to 1/2 of a multi-part GSoC project)
> """
> 
> I don't know this topic enough, is there anyone who has any opinion,
> suggestion or comment?
> 
> Thanks in advance, Martin
> 
> [1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012
> [2] http://en.wikipedia.org/wiki/Topographic_prominence
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org


r.prominence.tar.bz2
Description: application/bzip


r.normalize.tar.bz2
Description: application/bzip
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Wrong sqlite3.dll used on MS Windows

[Benjamin Ducke]

All I know is that "system32" is the default
"go-to" path for many 32-bit programs. It seems to
me that many applications are hard-linked to that
directory. If you have any such candidate in your
toolchain, then "system32", and thus "SysWoW64",
are "sucked" into your PATH, whether you like it
or not. Welcome to DLL hell.

Best,

Ben

On 06/10/14 21:16, Vaclav Petras wrote:
> Hi,
> 
> here is some minor issue on MS Windows, did somebody experienced
> something like the following?
> 
> GRASS was not starting for one student on MS Windows. The reported error
> was that it cannot find some symbol/procedure in sqlite3.dll. The
> problem was possible to workaround by finding another sqlite3.dll on
> disk and renaming it to something arbitrary.
> 
> The strange think is that GRASS directory extrabin should be, and indeed
> is, at the beginning of PATH variable, so it should look first there.
> However, because of the error and fix it seems that it is looking
> elsewhere first.
> 
> What was also strange is that the other DLL was in SysWoW64 directory
> and I don't see this directory on PATH (in or outside GRASS session) but
> if I understand correctly, there is some magic which makes system32
> directory (which contains 64bit libs on 64bit system) to link to
> SysWoW64 (where are 32bit DLLs) for 32bit applications. Wow!
> 
> Still, there is no reason why it should pick the system directory,
> unless it is using some other magic.
> 
> Any ideas?
> 
> Vaclav
> 
> 
> 
> Related:
> 
> The procedure entry point sqlite3_rtree_geometry_callback couldn't be
> located
> http://trac.osgeo.org/grass/ticket/2197#comment:1
> 
> WoW64
> http://en.wikipedia.org/wiki/WoW64
> 
> How to fix "The entry point for the procedure sqlite3_open_v2 cannot be
> found in the dynamic link library sqlite3.dll"
> http://gis.stackexchange.com/questions/30432/how-to-fix-the-entry-point-for-the-procedure-sqlite3-open-v2-cannot-be-found-in
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Who wants GUI and who does not and why

[Benjamin Ducke]

ead the wxPython GUI now...
>>
>>
>> On 16 April 2014 08:00, Vaclav Petras > <mailto:wenzesl...@gmail.com>> wrote:
>>
>> Hi all,
>>
>> I believe, I was calling for this discussion recently, and I'm
>> calling for it again. It seems that there are quite different
>> opinions on GRASS GIS GUI ranging from "GUI is the only thing
>> which brings us new users" to "no GUI needed".
>>
>> There is no better time to discuss this: we are discussing issues
>> with MS Windows support, planing to release 7, working towards
>> compatibility of 7 with QGIS and gvSIG, and we also discussed
>> WebGRASS topic recently.
>>
>> Here are recent quotations from "Handling of Python scripts on MS
>> Windows" discussion
>> (http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with
>> few notes and questions but feel free to start wherever you want.
>>
>>
>> On Sun, Apr 13, 2014 at 12:52 PM, Benjamin
>> Ducke mailto:bendu...@fastmail.fm>> wrote:
>> > On Sun, Apr 13, 2014 at 11:03 AM, Moritz
>> Lennert > <mailto:mlenn...@club.worldonline.be>> wrote:
>>
>> > [Side note: The same discussion should also constantly be
>> held about
>> > functionality which is specific to the GUI, because specifically
>> > developed for it), i.e. not just a GUI layer above command line
>> > functionality, something I'm afraid to see creep in more and
>> more...]
>> >
>>
>> Does this mean that you want remove everything from `gui/*`
>> besides `gui/wxpython/forms/*`?
>>  
>>
>> Agreed. Once more, I plead for a clean separation between GUI
>> and CLI developments, and a disconnection of their release cycles.
>>
>>
>> I see some advantages, for example just using same bug tracker
>> makes difficult to say what is critical issue; but there are some
>> GUI errors are tightly coupled to core module issues.
>>
>> On the other hand, I don't see how these disconnected release
>> cycles would work. Also it seems that it is impossible or very
>> hard to create good GUI without the support of the processing and
>> management tools.
>>  
>>
>> The wxPython GUI can be considered a monolithic application,
>> and FWIW it can pull every trick in the book to integrate a
>> Python interpreter, and to make it all easier for Windows users.
>>
>> ...
>>
>> I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
>> monolithic applications and let their maintainers figure out how
>> to deal with this. In the gvSIG CE project, we do a lot of hair-
>> raising stuff to hide the complexity of GRASS and its dependencies
>> from the end user, and I suspect so does QGIS. But I would not
>> advocate the same approach to the core GRASS architecture.
>>
>>
>> Than perhaps, no wxGUI is needed because we have QGIS and gvSIG
>> plugins. Managing one GUI less in 
>>
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

c applications and let their maintainers figure out how
to deal with this. In the gvSIG CE project, we do a lot of hair-
raising stuff to hide the complexity of GRASS and its dependencies
from the end user, and I suspect so does QGIS. But I would not
advocate the same approach to the core GRASS architecture.

>> if you take a look on all threads related to this topic in grass-dev
>> ML you will count more that 150 messages, but without real consensus.
> 
> Well, there have been different proposals for possible solutions,
> amongst which the Python launcher which I tested last summer [1], but
> except for Helmut, none of those who are pushing for a quick solution of
> the issue seem to have been sufficiently interested to test that path. I
> know I haven't been very active on that front, and so will not throw
> stones, but others shouldn't either...
> 

Just to re-iterate my main point: By now I think that such "solutions"
(or rather work-arounds) are perfectly acceptable for QGIS or gvSIG CE,
which are less flexible and more controlled environments than CLI
GRASS by design, anyway. We will certainly explore these options for
gvSIG CE, but I have come to think they are futile efforts for core
GRASS.

> But whatever the solution, unless we want to turn GRASS4Win into a
> different application than GRASS on other platforms, there will have to
> be a minimal amount of intervention by the user to chose how she wants
> to handle Python on her machine.
> 

I think some intervention is perfectly acceptable. This is already
required from all those (Windows) users that want to install proprietary
format support, such as ECW or MrSID on their machines, due to choices
they have to make re. licensing terms. On Windows, this can all be
handled in a unified way by the OSGeo4W installer.

> To come back to a general note about this debate: As should be clear
> from this and previous interventions, I have my opinion of the direction
> to follow, but I would never claim this to be the one and only. The way
> the debate is being held on the list, does give the impression, though,
> that some think that the solution is obvious and that anyone who opposes
> that solution is just to stubborn/conservative/thick to understand it.
> And that attitude really irritates me.
> 

Yes, there is some cause of irritation. But this discussion is still
important and has produced some really good insights. So I think we
should all take a deep breath and carry on, as exhausting as it may be.
These are important directional decisions and they should not be rushed.

Cheers,

Ben

> Moritz
> 
> [1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Benjamin Ducke]

And that's why I love this mailing list:
There are insights here that are simply
impossible to get elsewhere. Thanks for
this one, Glynn!

Ben

On 09/04/14 17:18, Glynn Clements wrote:
> 
> Benjamin Ducke wrote:
> 
>> GEOS is a heavy C++ beast and difficult to compile using GCC
>> on Windows (at least if you want the result to pass all
>> validation tests).
>>
>> I would prefer to stick to C dependencies only for the core
>> modules, if only to avoid DLL hell when mixing Visual C++
>> and GCC DLLs on Windows (different name mangling styles).
> 
> It's not just name mangling. There isn't an official ABI for C++ on
> Windows. Even if all components are compiled with MSVC, simply using
> different compiler switches can result in incompatibilities (e.g. the
> layout of pointer-to-member values can vary according to the /vm*
> switches used).
> 
> Different compilers use different mangling rules because their code is
> inherently incompatible. Changing the name mangling just prevents
> people from trying to do things which aren't going to work anyhow.
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Benjamin Ducke]

Has somebody here figured out yet how to compile GEOS
using GCC on Windows (MinGW), so that it passes all of
its own validation tests? That's where I am stuck
at this point:

http://gvsigce.sourceforge.net/wiki/index.php/Compiling_the_C/C%2B%2B_support_libraries#GEOS_.28currently_disabled.29

Cheers,

Ben

On 09/04/14 12:02, Jürgen E. Fischer wrote:
> Hi Martin,
> 
> On Wed, 09. Apr 2014 at 11:52:34 +0200, Martin Landa wrote:
>>> That's why GEOS has a C API.  Doesn't GRASS use that anyway?
>  
>> of course the GRASS modules are based C-API. Martin
> 
> That's what I thought - but I didn't have to build GRASS on Windows for a
> while.  Thanks ;)
> 
> 
> Jürgen
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] relbr6 - devbr6 differences

[Benjamin Ducke]

GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).

I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).

Ben

On 09/04/14 09:36, Moritz Lennert wrote:
> On 09/04/14 08:35, Martin Landa wrote:
>> Hi Markus,
>>
>> 2014-04-09 8:28 GMT+02:00 Markus Metz :
>>
>>> - wxGUI backport?
>>
>> will take a look...
>>
>> [...]
>>
>>> - v.buffer differs, but is broken in both branches. Only the
>>> GEOS-enabled version in G7 works. Since this is a bugfix, I would
>>> suggest to backport v.buffer from G7 to G6.
> 
> +1
> 
> If GEOS thus becomes a mandatory dependency, this will also
> automatically enable the additional operators in v.select which I think
> is a good thing.
> 
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Benjamin Ducke]

On 07/04/14 11:22, Moritz Lennert wrote:
> On 06/04/14 15:25, Martin Landa wrote:
>> Hi,
>>
>> 2014-04-06 15:16 GMT+02:00 Moritz Lennert :
>>> As already mentioned I was also a bit surprised by this. I'm not sure
>>> we are
>>> really ready for something more than a tech-preview (and not a real
>>> release), but maybe it could be the kick in the behind that we need
>>> to once
>>> and for all move over to GRASS7 as the main official branch...
>>
>> well, what is missing from your point of view?
> 
> In my understanding we were still quite far away from solving the python
> on windows issues.
> 
> On Linux GRASS7 already works marvelously (although encoding issues in
> the GUI just seem to be multiplying, but that's a discussion for bug
> tickets not here).
> 

So if the core libraries and modules work fine under all
supported OS, why not detach the GRASS 7 core release cycle
from that of the GUI?

If we considered both the GUI and the Python support optional,
then it would be possible to release a stable GRASS 7 core
soon and allow third parties, such as QGIS and gvSIG, do build
on it, no?

Best,

Ben

> Not even to speak about the debate about the general form of GRASS
> ("program" to launch or environment) launched by Glynn. But maybe this
> is more for grass8 ?
> 
>> I would be able to
>> imagine to release 7.0.0 around June...
> 
> I we can solve the outstanding problems by then, great.
> 
> Moritz
> _______
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

[Benjamin Ducke]

One last addition to this from my side:

Since, as I mentioned, we have evaluated many of the
issues discussed in this thread in the design of the
GRASS plug-in for SEXTANTE/gvSIG CE, here are some things
you might want to take into consideration:

On 28/03/14 11:48, Paolo Cavallini wrote:
> Il 28/03/2014 08:34, Paolo Cavallini ha scritto:
> 
>> Thanks to all for the interesting comments. Obviously we have a varied
>> and rich ecosystem here, that's why I want to preserve it.
>> Obviously we all want to have all. IMHO the points are:
>>
>> * can we (GRASS+QGIS) agree on a specific course of actions?
>> * can we find the resource to implement it?
>>
>> Of course we could think of sticking with GRASS6, but I think sooner or
>> later this will be untenable (e.g. major distros will switch to GRASS7
>> once out), so better prepare now.
> 
> Quick interesting chat with Luca Delucchi and Martin Landa from GRASS
> dev team.
> One interesting option would be:
> * to add GRASS browsing capabilities in QGIS file browser

Browsing capabilities for existing GRASS mapsets would be
nice, but having the plug-in directly manipulate the data
in there leads down a difficult path (see my notes further
below).

> * to add support to direct GRASS reading (possibly writing) in
> Processing, and avoid import/export whenever possible; v.external and
> v.out.external could be used for this; this is probably the thoughest part

As far as I understand, the v.out.* modules create read-only
datasets. They also create minimal topological data structures
that are not enough for many GRASS modules (correct me if any of
these statements is no longer true). Therefore, we decided against
this path and use v.in/out.ogr instead -- with all known problems.

But r.external seems to work fine, so that at least raster I/O is
efficient enough; with the one limitation being that GRASS does not
support multi-band rasters in single files (we do not have a good
solution for working around that problem yet).

> * of course modules should be upgraded anyway
> * GRASS direct digitizing can be skipped; heavy digitizer can use GRASS
> directly

(see below)

> * keep a GRASS shell?

This only works well with the original GRASS plug-in design, not
with the one derived from SEXTANTE:

Any plug-in design that allows direct manipulation of existing
GRASS data and/or runs GRASS modules on existing mapsets is
not very compatible with the SEXTANTE/Processing on-the-fly
"import/process/export/delete temp" approach. As long as the GRASS
mapset is guaranteed to be temporary, the above chain is clean
and simple. But if you give the plug-in access to existing mapset
data, then you need a nice, thick wrapper of additional safety
checks to make sure that the final "delete" step *never* deletes
any pre-existing user data! Not only would you have to keep track
of each and every bit of data that an intermediate processing step
creates (modules that call other modules!), but also make sure
that no stale data is left in the user's mapset if processing does
not complete.

This is all very, very tricky and normally the role of the GRASS user
who knows about GRASS data management and is in full control.
I.e. if you want to make this safe, then you have to expose the GRASS
mapset and management completely to the user --> and this in turn
defeats the idea of radically simplifying the use of GRASS modules.

This is the reason why in gvSIG CE we steered clear of existing
user mapsets; our conviction being that data safety is always more
important than convenience and that advanced users can/will just run
GRASS by themselves.

Best,

Ben

> * with all the above, upgrading the plugin may probably be skipped.
> 
> Any thoughts.
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

[Benjamin Ducke]

In the gvSIG CE project, we had to make the same
type of decisions and came to our own conclusions.

Allow me to summarize our reasoning, maybe it will be
useful for the QGIS project, as well:

1. The number one cause of irritations among novice
users is having to set up a GRASS mapset and having
to understand how GRASS data management works.

2. The number two cause of irritations are the effects
of importing vector data with bad topology into a
GRASS mapset.

3. The original QGIS plugin does nothing to alleviate (1).
No plug-in, however cleverly designed, can do anything
about (2): garbage in, garbage out.

4. GRASS "power users" gain very little (if anything)
from running GRASS through a host GIS, such as QGIS
or gvSIG. But they do lose functionality, such as the
d.* family of modules.

Therefore, we gave up trying to design a plug-in for
advanced users. We assume that such users will use
GRASS through its native CLI and/or native GUI.

The resulting design of the original SEXTANTE-GRASS
interface (which is now also mirrored in the Python
re-write that became QGIS' Processing) addresses users
that either don't care much for GRASS' CLI capabilities
and internal data management, or are willing to switch to
native GRASS as needed.

If you want to change this and address another type
of user, then you will need to re-examine the entire design
of the current SEXTANTE/Processing approach, which is to use
only temporary mapsets and perform data import/export every
time a GRASS module is run.

You can optimize the I/O performance of Processing by using
r.external to directly access raster input maps. But there
is little you can do about vector data with the current
design, as GRASS needs to build its own topological data
structures (and rebuild them every time you run a GRASS module
on non-topological input!).

In any case, I do not think that it is worth maintaining
the original QGIS plugin, since it is neither very well
suited for novice nor advanced users, IMHO.

Best,

Ben


On 27/03/14 14:38, Blumentrath, Stefan wrote:
> That sounds very reasonable to me.
> 
> Proper GDAL/OGR handling for GRASS 7 would be very nice in any case (see 
> http://trac.osgeo.org/gdal/ticket/2953).
> 
> As for a "GRASS data browser", I think, a plugin would be required with 
> regards to user friendliness, because one needs to know what files to access 
> from a GRASS data base when using GDAL.
> 
> I also understand that at some point in time one will have to use GRASS 
> directly in order to access full functionality (e.g. ortho-rectification, 
> nviz, mapswipe, animation and stuff), which makes the way Moritz suggests 
> maybe even more reasonable...
> 
> Cheers
> Stefan
>  
> 
> 
> 
> -Original Message-
> From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
> Sent: 27. mars 2014 13:36
> To: Blumentrath, Stefan
> Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
> Subject: Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future
> 
> I'm not much of a QGIS-as-GRASS-frontend user, either, but from a general 
> point of view I also think that duplication is a problem and that the current 
> way to go in QGIS is the processing framework. So;
> 
> On 27/03/14 12:49, Blumentrath, Stefan wrote:
>> I understand well the point; however, the plugin has additional functions, 
>> e.g.:
>> * a grass shell
> 
> couldn't this be implemented within the processing environment ?
> 
>> * a grass data browser
> 
> If we are talking about accessing GRASS data for loading into QGIS, wouldn't 
> it be a better idea to improve the GDAL/OGR handling in order to be able to 
> load GRASS data just like any other data format ?
> 
>> * a grass digitizing environment.
> 
> Maybe this could be split out into a specific plugin ?
> 
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

On 08/02/14 20:41, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
>>> The difference is that you don't "start" GRASS. You set the required
>>> environment variables from e.g. ~/.profile so that GRASS commands work
>>> in any shell (or via any other execution mechanism, e.g. M-! from
>>> within Emacs).
>>
>> This is hardly feasible for the majority of the users. Perhaps I don't
>> understand the suggestion, at least for Windows OS users (nad most
>> Linux/Mac newcomers).
> 
> It's not something users should need to concern themselves with.
> 
> Many packages require certain environment settings (which is why most
> modern Linux systems have e.g. /etc/profile.d or /etc/env.d, with each
> file belonging to a different package).
> 
> Most packages made up of command-line utilities don't require you to
> "start" the package before you can use the commands which comprise it.
> 
> It would be quite straightforward for a GRASS package to install an
> environment file which sets GISBASE and GISRC so that GRASS commands
> just work anywhere.
> 

I have been trying to wrap my head around this.
Please tell me if I still misunderstand something,
but this is what I think you are suggesting:

Instead of having to log into a GRASS session
explicitely, the GRASS environment gets configured
with the login (shell) and then the user can just run
e.g. "g.list" and it will just work.

How would users choose mapsets or create new ones in this
scenario? Wouldn't that require new user level software?

> Things get marginally more complex if you either need multiple
> versions installed concurrently, or multiple concurrent sessions.
> 
> The former is seldom supported, particularly for packages consisting
> of many distinct utilities (having python2 and python3 executables is
> one thing, versioning dozens or hundreds of distinct commands is
> another).
> 

Well, at this point I have several versions of GRASS 6.4 and
a version of GRASS 7 installed. I need them all, because they
run as testing versions or to provide processing functionality
for another "host" GIS.

How would I switch between them?

The same situation arises with different Java versions on the
same system. It is a very frequent situation and IMHO there
is no really good, convenient solution for this. Every Linux
distribution seems to use its own frontend for switching and
let's not even get started about Windows.

The alternatives here are to either manipulate PATH etc.
directly or to provide some more user-friendly software that
take care of this. I find neither ideal.

> The latter is fairly trivial to implement on Unix (just use $$ in the
> setting of GISRC), and could be implemented on Windows (which doesn't
> have the equivalent of ~/.profile etc) with fairly minor changes to
> lib/gis/env.c.
> 

But that would again require some user-friendly software, unless
people are supposed to start editing configuration files, right?

I understand the benefits of tighter system integration that (I think)
you are aiming for. It would make everything more seamless.
But there are also downsides to this: We would need to think about
different mechanisms for each supported OS; we could get tangled up in
all sorts of flawed decisions by the OS designers; we would depend on
3rd party dependencies to work with GRASS. Surely, all of these issues
could be worked around, but are the potential benefits worth it?

Whatever the decision may be: Please make sure that it will always be
possible to bundle a completely independent distribution of GRASS
with 3rd party GIS. Otherwise, this project will no longer be able to
benefit from the growing user base that projects such as QGIS have
recently attracted.

Best,

Ben

-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

On 04/02/14 16:42, Vaclav Petras wrote:
> 
> 
> 
> On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke  <mailto:bendu...@fastmail.fm>> wrote:
> 
> On 04/02/14 15:09, Vaclav Petras wrote:
> >
>     > On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke
> mailto:bendu...@fastmail.fm>
> > <mailto:bendu...@fastmail.fm <mailto:bendu...@fastmail.fm>>> wrote:
> >
> > But with the
> > latest Python developments, it will be a real challenge to
> > integrate GRASS 7 in the same way that we could integrate
> > GRASS 6 into a "host" application (i.e. without messing
> > around with any system settings).
> >
> >
> > Can you be more specific? It sounds like something we should be
> concern
> > about. We should consider how GRASS 7 will be integrated into
> other GIS
> > packages when Python scripts are called this or that way.
> 
> Sure. At this moment, we (i.e. the gvSIG CE dev team) distribute
> GRASS 6 binaries along with gvSIG CE. On Windows, we also package
> MSYS with "sh.exe" for the scripted modules.
> 
> So we can deliever gvSIG CE + GRASS as a completely self-contained
> (portable) package.
> 
> Of course, we do not ship any GRASS GUI (or any of the d.* modules).
> All GRASS modules are available seamlessly from the gvSIG CE GUI via a
> Plug-in, similar to that in QGIS.
> 
> Now, with the new Python-scripted modules in GRASS 7 this will
> become more difficult, since Python adds a more heavy dependency.
> In order to stay portable, we need to bundle a completely isolated
> Python interpreter with gvSIG CE. And then we also need to make
> sure that no GRASS Python module will call the system Python. The
> latter is something that can only be taken care of on the GRASS
> side.
> 
> 
> So, what would be the consequences for gvSIG, QGIS, OSGeo4W, ... if we
> decide to use system Python in (standalone) WinGRASS?

As far as gvSIG CE is concerned, there would be no consequences,
as long as it is possible to also make a GRASS distribution that
does not depend on system Python.

We ship our own, bundled GRASS binaries and users can just install
a WinGRASS (or any other GRASS version) in parallel. However,
in order to be able to bundle GRASS 7 in the future, none
of its modules should depend on system Python. If there were such
a dependency, then we would have to drop the Python-scripted
modules from the set of GRASS modules supported in gvSIG CE, as
we do not want to compromise our software's portability.

Best,

Ben


-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

On 04/02/14 15:09, Vaclav Petras wrote:
> 
> On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke  <mailto:bendu...@fastmail.fm>> wrote:
> 
> But with the
> latest Python developments, it will be a real challenge to
> integrate GRASS 7 in the same way that we could integrate
> GRASS 6 into a "host" application (i.e. without messing
> around with any system settings).
> 
> 
> Can you be more specific? It sounds like something we should be concern
> about. We should consider how GRASS 7 will be integrated into other GIS
> packages when Python scripts are called this or that way.

Sure. At this moment, we (i.e. the gvSIG CE dev team) distribute
GRASS 6 binaries along with gvSIG CE. On Windows, we also package
MSYS with "sh.exe" for the scripted modules.

So we can deliever gvSIG CE + GRASS as a completely self-contained
(portable) package.

Of course, we do not ship any GRASS GUI (or any of the d.* modules).
All GRASS modules are available seamlessly from the gvSIG CE GUI via a
Plug-in, similar to that in QGIS.

Now, with the new Python-scripted modules in GRASS 7 this will
become more difficult, since Python adds a more heavy dependency.
In order to stay portable, we need to bundle a completely isolated
Python interpreter with gvSIG CE. And then we also need to make
sure that no GRASS Python module will call the system Python. The
latter is something that can only be taken care of on the GRASS
side.

Years ago, when the development of the wxGUI started to get more
integrated with that of GRASS itself, it was suggested by some
to completely separate the GUI development.I still think that
would be a good idea.

Best,

Ben

-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

Hi there,

On 04/02/14 13:24, Moritz Lennert wrote:
> On 04/02/14 11:29, Glynn Clements wrote:
>>
>> Markus Metz wrote:
>>> I agree. It seems that the wxGUI always uses the bundled GRASS_PYTHON,
>>> the reason why the wxGUI works fine without a system-wide Python.
>>
>> That was done so that the system Python doesn't need to have wxPython
>> installed. Note that wxpyimgview does something similar: the top-level
>> script invokes the wxPython program via GRASS_PYTHON explicitly.
>>
>> But this only works for a closed system which knows what it is
>> executing. It doesn't help us provide a command-line environment where
>> Python scripts just work as they should.
> 
> I think this is the basis of some of the frustration in the ongoing
> discussion: different use-cases and philosophies about what GRASS is and
> should be. I understand that for many users (and I would guess for part
> of the developers), GRASS _is_ a monolithic system and Python scripts
> are only used from within, but for others the fact that it is a more
> open, modular system makes for a large part of its attractiveness. So,
> the solution we have to find has to cater to both, and unfortunately,
> embedding Python will not suffice for the second use case.
> 

That's a really important point! GRASS is an example of
the Unix tradition of modular design. It owed and continues
to owe much of its flexibility to this fact. From my
point of view, its clean, modular architecture is also what
has given GRASS its amazing lifespan and maintainability.

The GUI design should never compromise that. In fact,
I believe the GUI is a matter of choice/taste and
should be exchangeable at will. We have GRASS running
as a processing backend for WPS and for several "host"
desktop GIS (QGIS, OpenJUMP, Kosmo, uDig, gvSIG, ...).

E.g., I use GRASS exclusively either through the command
line or via the GRASS plug-in in gvSIG CE. But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
GRASS 6 into a "host" application (i.e. without messing
around with any system settings).

Best,

Ben

> I do have the feeling, though, that the python launcher is an
> interesting path to explore.
> 
> Moritz
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

Hi All,

On 28/01/14 17:05, Moritz Lennert wrote:
> On 28/01/14 12:07, Markus Metz wrote:
>> On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
>>> "Executing" a script uses the registry associations for the script's
>>> extension.
>>

This matters for using os.system("python.exe 

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

On 25/01/14 16:48, Markus Metz wrote:
> On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova  wrote:
>> Just a note, given that most of these problems were caused by conflicts with 
>> python installed by ArcGIS,
>> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 
>> which (I guess) should work with GRASS.
> 
> No, there are different versions of Python 2.7, and not all work with
> GRASS, see e.g. ticket 2015
>>
>>
>> On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:
>>
>>>
>>> Markus Metz wrote:
>>>
>>>>>> Where it gets problematic is if the user already has a Python
>>>>>> installation but it's not suitable for whatever reason. In the worst
>>>>>> case they may be faced with a choice between using GRASS or using
>>>>>> whatever the existing Python was installed for.
>>>>>

There is a tool called "Virtualenv" that seems to address exactly
this problem: https://pypi.python.org/pypi/virtualenv

See also here: http://docs.python-guide.org/en/latest/starting/install/win/

I found it via this thread:
http://stackoverflow.com/questions/1108974/switch-versions-of-python

>>>>> IMHO keeping in mind that many GIS-interested winGRASS-users may already
>>>>> have been installed other (GIS-)software including a system-wide python
>>>>> installation, that will be the demanding challenge to provide a suitable
>>>>> solution ...

I don't know in how far a pre-existing system installation of
Python would interfere with Virtualenv or similar solutions.

But I hope that the above could be a useful approach to
solving this problem.

Best,

Ben

>>>
>>> How many users will have versions which are:
>>>
>>> a) too old for GRASS to use, and
>>> b) required to be that old by the existing package?
>>>
>>> Bear in mind that GRASS won't be the only package affected by an
>>> outdated system-wide Python installation.
> 
> GRASS should not use a system-wide Python installation, or more
> precisely, should explicitly ignore any system-wide python file
> associations. Expecting system-wide python file associations is the
> cause of all the trouble.
> 
> The embedded but not installed Python version coming GRASS works fine
> and should IMHO be used for scripts via
> 
> @"%GRASS_PYTHON%" "%GISBASE%/scripts/SCRIPT_NAME" %*
> 
>>>
>>> AFAIK, the primary case where another package requires a system-wide
>>> Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
>>> is there some fundamental reason why this isn't suitable for GRASS? If
>>> so, does ArcGIS require that exact version, or can it use a later
>>> version?
> 
> We can not care for all cases of other software (versions) relying on
> a system-wide python installation.
>>
>> yes, given that most of these problems were caused by conflicts with python 
>> installed by ArcGIS,
>> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 
>> which should work with GRASS
>> (correct me if I am wrong).
>> We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a 
>> specific winpython2.5 build 212
>> to have both of them working on the same machine.
>> The test suggested by Markus in the related message would be still useful,
>> but upgrading to ArcGIS10.2 should solve the problem?
> 
> You can hardly suggest users to upgrade ArcGIS if they want to use GRASS...
> 
>>
>>>> Therefore I would suggest to keep using the embedded Python version
>>>> which is known to work
>>>
>>> Actually, it known not to work, hence this thread.
> 
> It works as long as system-wide python file associations are ignored.
> Other Python versions might not work.
> 
>>>
>>> The only way you can make execution of Python scripts seamless (i.e.
>>> works with system(), subprocess.Popen(), etc) is for the .py extension
>>> to be associated with a suitable interpreter (or launcher) in the
>>> registry.
> 
> I disagree. For example, shell scripts work just fine in GRASS 6.4,
> even though there is no associated suitable interpreter (or launcher)
> in the registry.
> 
>>>
>>> Any other approach will trap us into an endless maintenance burden,
>>> identifying cases where we have to provide special handling for Python
>>> scripts then implementing that handling.
> 
> We did so for shell scripts, AFAIK this works.
> 
> Markus M
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Why the parameters of "g.region" are defined as string?

[Benjamin Ducke]

On 08/12/2013 05:39 PM, Pietro wrote:

Hi all,

Today I've just realize that the parameter of g.region are defined as string:

http://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/main.c#L203



[snip]


Why should we not use TYPE_DOUBLE for these parameters (n,s,e,w,)? Is
it to not loose significant digits?


It needs to be a string, so that you can use
common lat/lon notations in the format "°dd'mm''ss".

Ben



Sorry if this has already been discussed, but I was not able to find
any reference in the mailing-list's archive.

Best regards

Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizon based voxel interpolation wk 7 checkin

[Benjamin Ducke]

I concur.
Please make sure that your code has been completely
uploaded to the "trunk" folder in your SVN repo.

Also, some sample input data and at least screenshots
of the output that you get would be very helpful.
Preferably, export your result (or a lower resolution
version of it) using r3.out.vtk, zip the VTK file and
upload it to the SVN.

Best,

Ben

On 08/01/2013 08:52 AM, Sören Gebbert wrote:

Hi Tim,
Can you please check your commits into your Google code repo? It seems
to me that there are some parts of your files missing? Besides of that,
can you please provide manpages for your modules so that we can see what
they are designed for?

It is important for us to be able to run your modules.

Best regards
Soeren

Am 01.08.2013 07:28 schrieb "Tim Bailey" mailto:timi...@gmail.com>>:

Hi Folks
I worked through the weekend, I am going to have limited internet
access at the end of the week, and I am working under a rather clear
mentor ultimatum, So here is my week 7 report.

This week I implemented the voronoi operator, that had confounded me
for much of July, through a two stage iterative process.  Process A
propagates identities vertically up profiles from horizon
boundaries. Process B propagates identities horizontally away from
the profiles.
I applied this to one of my experimental sandboxes that was built
for a study of late holocene co-seismic subsidence in a coastal
saltmarsh. In this circumstance coastal marshes exhibit extreme
sensitivity to their elevation above sea level.  A series of
earthquakes during the past 4500 years are recorded by the
sedimentary record at the coastal margins. These earthquakes
resulted in subsidence events of almost a meter and a half in one
episode, and notable movement in several other events. In addition
the introduction of tsunami, and mudflat deposits overlaying peat
deposits create a very appealing paleo environment to reconstruct
using voxel operators.The GRASS region was bound between the deepest
core at 6 meters below sea level and 3 meters above, which was
clearly out of the range of the modern salt marsh. On my computer
with an amd5700 processor, 12gb ram, with ssd, Ubuntu 13.04 and
GRASS7,process A takes 12 seconds per iteration,  and process B
takes 22 seconds per iteration for a 32,000,000 voxel map. From the
data that I am working with process A required 9 iterations and
process B required 50 cycles. Region anisotropy was set to 10:1,
where it could really comfortably be 100:1.  Nonetheless, this is
not that different from the computing demands of moderately large
lidar job. Also in this case iteration limits can be used to limit
the area of influence of a data point.

Next week will work on refining this weeks work and implement a
surface limit.

Tim Bailey


___
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Vector Conlation plugin Info

[Benjamin Ducke]

Hi,

You might also want to take a look at OpenJUMP,
which already has a complete set of tools for
conflation tasks:

http://openjump.org/

Also, gvSIG CE (http://gvsigce.org) has a rich
toolset for topological cleaning of shapefiles
and comes with GRASS-support built-in.

Best,

Ben

On 07/30/2013 03:37 PM, Max Demars wrote:

Good day,

I am new to this list, and I hope to get information (papers, powerpoint
presentation, etc) about an upcoming GRASS-QGIS plugin for vector
conflation.

I was searching on the net on this topic and someone fowarded me to
Tereza Fiedlerová works on this topic disscust in the  GRASS Community
Sprint Prague 2013
(http://grasswiki.osgeo.org/wiki/Talk%3aGRASS_Community_Sprint_Prague_2013#Tereza_Fiedlerov.C3.A1)

I'd like to look at, if its possible, papers, pwpt, etc, on this
upcoming plugin. I am working for the Education Ministry of
Quebec/Canada Government, and we are looking for an open-source
alternative to ESRI topology tool in order to reduce the cost of licenses.

Thank you for your support.

Max Demars,
Quebec, Canada


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizon Based Voxel Interpolation Wk 5 checkin

[Benjamin Ducke]

Hi Tim,

On 07/20/2013 01:10 AM, Tim Bailey wrote:

This week I worked on the voronoi operator. Also I have been working on
a few vector pre-processing procedures, that will end up as options for
the module. One of them extends horizon interval vectors to the limit of
the computational region to limit the influence of the highest and
lowest data.


We haven't discussed last week's thoughts and
ideas too much on this list, and the midterm report
will be due soon.

So I hope you fully realise the limitations of an
"interpolate 2D slices and stack them into a 3D
volume" approach. Its results will divert
from those of a true 3D interpolator that works
in voxel space.



Next week I will continue to work on the voronoi operator and put
examples and the workflows up on the wiki. One thing that has been
blocking me has been the visualization tools for volumes. m.nviz.image
seems to work fine but the 3d view in the Map display is not working
correctly. I did an svn update to see if that improved things.


If you have trouble with NVIZ, then you can use
r3.out.vtk to export your voxel data to VTK and
load that into a VTK-based view (e.g. ParaView).
Use r.out.vtk, v.out.vtk, accordingly.

Best,

Ben



Tim Bailey



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC wk4 checkin Horizon Based Voxel Interpolation

[Benjamin Ducke]

_
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] GSOC Horizon based stratigraphy wk3 checkin

[Benjamin Ducke]

On 07/05/2013 06:34 PM, Michael Barton wrote:

How about making the assumption that horizons sampled by a single point
are horizontal--or perhaps some other plane with dip and strike
specified by the user like in r.plane.



I suppose this is a rather philosophical question.
At least I am not aware of any established method
for answering the question whether a single piece
of evidence should be taken into account or discarded.

I would tend towards the latter (discard). My argument
would be that if a soil horizon occurs only in a
single sample, then either:
(a) the sampling strategy was flawed (perhaps the
spacing between sampling points was too wide) or
(b) there was a problem with interpreting the samples.

If you decide to discard singular evidence, then
your module should display an appropriate warning.

Best,

Ben


Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Jul 5, 2013, at 8:57 AM, Tim Bailey mailto:timi...@gmail.com>>
  wrote:


This week I worked on the voxel assignment operator for my module.  I
also explored the possibility of using a priori assigned anisotropy
with a kernal operator to populate the voxel space.One concern that I
am not sure how to manage yet are horizon instances that are only
identified in a single sample. Next week I will continue working on
these same areas.

Tim Bailey

Tim  Bailey
___
SoC mailing list
s...@lists.osgeo.org <mailto:s...@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/soc




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Status of r.cva?

[Benjamin Ducke]

Note that r.cva is really just a convenient way of
calling r.los multiple times and adding the results
for a cumulative viewshed analysis. You can get
the same net result by using r.los or r.viewshed
and r.mapcalc. As far as I recall, the earth curvature
correction is also identical across all modules.

Best,

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm

On Wed, Jul 3, 2013, at 1:51, Hamish wrote:
> Nikos wrote:
> 
> > a friend needs to use r.cva [0,1] (and r.viewshed [2]). What is the status 
> > of 
> > this add-on?  Does it also work in G7?  Only in G64 and previous releases?
> ...
> > [0] Link <https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.cva/>  
> > does not exist anymore!
> >
> > [1] only here: <http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html> ?
> 
> As I understand it, Mark's employer (university) would not let him
> release the work as GPL-compatible. Otherwise the module would have
> replaced r.los in the main GRASS source distribution years ago, and
> their institution would have been cited many many times from it, but
> oh well, he tried a number of times to convince them.
> 
> Considering universities like Johns Hopkins and Columbia literally
> generate billions of dollars licensing IP (typically bio-med), and
> how underfunded most educational institutions are, you can understand
> a bit why the suits at other universities around the world have a
> hard time seeing very far past the $ signs for anything and everything.
> :-/
> 
> Hamish
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizons and Stratigraphy

[Benjamin Ducke]

On 06/26/2013 07:00 PM, Pierre Roudier wrote:

Hi Benjamin,

As far as soils data, we would probably often mask with depths min or
max, use a plan to cut the profile collection to return points ("give
the carbon value at 13.5cm depth for this collection of profiles").



Yes, however, please keep in mind that this project
works with soil horizons, i.e. just categories, not
measurable quantities/properties.

Cutting through the interpolated voxel model to get a
2D distribution of horizons can easily be done with
the existing GRASS tools.


Alternatively, we would try to interpolate a profile collection to
harmonise soil depths: while data is usually collected on
heterogeneous depths intervals, one might want to harmonise the
collection for quantitative analysis: for example the new depth
support might be {0-5cm, 5-10cm, 10-30 cm, 30-60cm, 60-100cm}.



That should be possible by retrieving new cross-sections
from the interpolated voxel model.

Best,

Ben


Just 2 cents,

Pierre


2013/6/25 Benjamin Ducke :

On 06/25/2013 10:00 AM, Tim Bailey wrote:




Hi Ben,

All that I meant by mask is, in this case,  an r3 map that defines a
subset of space that subsequent operations are constrained to. I guess I
was just expressing worry about creating runaway data demands.The region
settings act as a three dimensional bounding cube, does not seem
adequate to constrain a tiling scheme with relatively sparse data.In the
compromise scenario that Dylan suggested with 10 meter xy and 1 cm z
resolution and 1 meter depth we would be looking at populating 1
voxels per hectare for a flat landscape. However if we were using a
simple bounding box to define the region and we had 5 meters of relief
we would end up with 5 or 6 voxels. As the area of coverage gets
bigger cost of the range in z values gets worse.



That's a good point that I hadn't thought about.
Clearly, we don't want the interpolation to go
beyond the limits of the terrain surface. It would
probably be a good idea for the user to be able to
supply an additional DEM input that could supply
upper cut-off values. A lower cut-off could simply
be defined as a constant depth value, and the same
for the extents along the X-Y plane. Apart from that,
the interpolator should use a configurable search
radius for points, so that it won't start interpolating
values in areas that have no sample data.

Ben


Tim


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

   bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev








--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizon based stratigraphy

[Benjamin Ducke]

On 06/26/2013 06:48 PM, Pierre Roudier wrote:

Hi all,



This is an excellent point. While I like the mention of AQP in this context,
I totally support a GRASS-based implementation with as few dependencies as
possible.


+1 - I think a native GRASS implementation would make a lot of sense.


Yes, the thought of such "waffel voxels" is not exactly appealing.
However, they may be a smaller problem in practice, since the voxel
models themselves are often used to derive vertical slices
("profiles"), and those might look perfectly fine, even if derived
from malformed voxels. GRASS does allow for individual X, Y and Z
dimensions of voxels, so there is no technical problem with this.
The results of the interpolation don't need to be beautiful, they
just need to be as accurate and as true to the data as possible.



That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such data.


This is a popular topic in the soils literature-- vertical anisotropy can be
an order of magnitude greater than what is found in the horizontal.
Restricted cubic splines have some desirable characteristics for dealing
with this kind of data-- however, these work best in the context of a
regression model. Also, there are the mass-preserving splines that are more
useful in the "interpolation along the soil profile" sense. For categorical
data, I would recommend the ordinal-ratio logistic regression model, which
generates class-wise probability estimates. I have found this quite useful
for generating probability depth-functions for categorical soil properties.
I can elaborate as needed.


The mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.



But is that method suitable for categorized input data?
Or does it only work for continuous soil properties?
A spline-based interpolator from 3D vector to 3D raster
already exists in GRASS (v.vol.rst).

Best,

Ben



Cheers,

P





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizons and Stratigraphy

[Benjamin Ducke]

On 06/25/2013 10:21 AM, Sören Gebbert wrote:

Hi Tim,
i am the second mentor in your SoC project, and will try to help you
with the 3D raster approach in GRASS.

The 3D raster implementation in GRASS is using a tiled based storage
approach.[1]
The tiles can be stored in compressed form (zlib in GRASS7) or
uncompressed form on the hard disk. Usually you store them in compressed
form. Hence in case you have many tiles that are empty or have equal
data, the compression is very high. GRASS can handle 3D raster maps up
to hundreds of GB in size. I tested 3D raster maps with about 12 GB in
size. The main memory is not an issue when processing 3D raster maps,
since only a limited number of tiles is read into main memory at
runtime. You can specify the tile size of each 3D raster map that you
create. Hence you can adjust it to the needs of the soil depths resolution.
In addition you can specify a 3D raster mask that works pretty the same
way as masks in the raster approach in GRASS.



Simply great! Even after having used GRASS for such a long
time, I keep being amazed by its capabilities.


Please don't bother to ask, if you have any questions about the 3D
raster implementation.



That should read: "Please don't hesitate to ask" -- I am sure ;)

Best,

Ben


Best regards
Soeren

[1] http://grass.osgeo.org/programming7/raster3dlib.html

2013/6/25 Tim Bailey mailto:timi...@gmail.com>>



Hi Ben,

All that I meant by mask is, in this case,  an r3 map that defines a
subset of space that subsequent operations are constrained to. I
guess I was just expressing worry about creating runaway data
demands.The region settings act as a three dimensional bounding
cube, does not seem adequate to constrain a tiling scheme with
relatively sparse data.In the compromise scenario that Dylan
suggested with 10 meter xy and 1 cm z resolution and 1 meter depth
we would be looking at populating 1 voxels per hectare for a
flat landscape. However if we were using a simple bounding box to
define the region and we had 5 meters of relief we would end up with
5 or 6 voxels. As the area of coverage gets bigger cost of
the range in z values gets worse.

Tim

___
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizons and Stratigraphy

[Benjamin Ducke]

On 06/25/2013 10:00 AM, Tim Bailey wrote:



Hi Ben,

All that I meant by mask is, in this case,  an r3 map that defines a
subset of space that subsequent operations are constrained to. I guess I
was just expressing worry about creating runaway data demands.The region
settings act as a three dimensional bounding cube, does not seem
adequate to constrain a tiling scheme with relatively sparse data.In the
compromise scenario that Dylan suggested with 10 meter xy and 1 cm z
resolution and 1 meter depth we would be looking at populating 1
voxels per hectare for a flat landscape. However if we were using a
simple bounding box to define the region and we had 5 meters of relief
we would end up with 5 or 6 voxels. As the area of coverage gets
bigger cost of the range in z values gets worse.



That's a good point that I hadn't thought about.
Clearly, we don't want the interpolation to go
beyond the limits of the terrain surface. It would
probably be a good idea for the user to be able to
supply an additional DEM input that could supply
upper cut-off values. A lower cut-off could simply
be defined as a constant depth value, and the same
for the extents along the X-Y plane. Apart from that,
the interpolator should use a configurable search
radius for points, so that it won't start interpolating
values in areas that have no sample data.

Ben


Tim


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC Horizon based stratigraphy

[Benjamin Ducke]

On 06/25/2013 12:24 AM, Dylan Beaudette wrote:

On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke mailto:bendu...@fastmail.fm>> wrote:

Hi All,

First of all, I am very excited to see how much interest this
project is getting, and it is great that Tim has already got the
support of so many soil science professionals. This will ensure
that the results of his work will be suitable for real-world use.




Thank you Ben for sponsoring this effort. I have tinkered with your r3*
code over the last couple of years, and have always wanted to integrate
it into my soil survey work and associated research.


I think you mean Soeren's work. He has contributed what must
be near 90% of the more recent voxel-related work to GRASS.




Hi Tim, nice to see another person from CA on the grass-dev list!




 I am just a novice with R but it occurs to me that the
soilDB and
 AQP R modules might be the best way to generate input point
 vectors.  One capability that I think is particularly
useful is the
 slicing and resampling of the vertical profile. For my current
 purposes, any attributes of interest from these databases
needs to
 be linked to a point vector as an intermediary step towards
being
 rendered by voxels.  In the specific case of categorical
data, I am
 working with the data assumption that the attributes will be
 assigned to a point vector located at the bottom of the
interval.


No doubt, those R classes are very elegant. However, Tim, introducing
R as a dependency into your project will put an additional burden
on you that you should carefully weigh against your time budget.
I think you should consider soil data representation and soil data
interpolation as two separate problems and work on the interpolation
bit first, as that is the core of your GSoC project description.

I realize that this discussion is both interesting and important.
But I also think that Tim should put priority on synthesizing a usable
3D sample dataset  first, so that he can implement a first version of
the interpolation algorithm.

Once he starts designing the algorithm, he will probably
find that it has certain requirements on the input data that are
not always met by typical soil science datasets. When he is clear
about them, he will also have a much better idea of what can and
cannot be done with typical soil science data (and geological cores,
etc.).



This is an excellent point. While I like the mention of AQP in this
context, I totally support a GRASS-based implementation with as few
dependencies as possible. Once progress has been made on the algorithm
then we can tinker with I/O. Pierre and I will likely be happy to
contribute ideas and code for going between the SoilProfileCollection
and whatever Tim implements. That would be a good time as well to
contribute some code for exporting SoilProfileCollection objects into
something that the current r3.* modules can understand.



That's exactly what's required. Cheers.


I don't have any geologic data sets, however, I have several soils data
sets that may be of general interest for algorithm development and
testing. Let me know when you are ready for those. I can imagine some
fairly interesting demos on the horizon (ha, soils-pun!) related to the
conversion of existing soil survey (polygons) into waffle-voxels.

 Historically soil inventory profiles have usually been a
bit sloppy
 with locating elevation absolutely. All of the depth
measurements
 were recorded in relative terms to the surface.  Would it be
 possible to deal with high resolution z coordinates in a
manner that
 was relational in the same way that soil profiles are
collected. The
 reason I ask is that I worry about the amount of data
required to
 tile voxels has the potential to grow inordinately. 10 cm is a
 pretty rough vertical resolution for soils purposes, but if
you have
 to populate voxels for a field area that has 100 meters of
elevation
 it could get  overwhelming.  The other route I am seeing is to
 create a mask from a digital elevation model to constrain
the region
 to voxels near the surface elevation. All of the workspaces
I am
 developing as examples for this project are areas where I
have lidar
 coverage to pin the depth intervals to a high resolution
elevation
 datum.


I have often wondered about the scale issue you bring up. 1cm
precision
in the vertical vs. 10m precision in the horizontal is often a good
compromise for soils/la

Re: [GRASS-dev] GSOC Horizon based stratigraphy

[Benjamin Ducke]

illed.  Also I hear that horizontal drilling is becoming a very
big deal in the energy sector and I can only imagine that
groundwater prospecting is going to follow.

Also during the project review period Hamish mentioned an interest
in Seismic line interpolation. At the time I worried that a
digression into applied geophysics might be a dangerous distraction
but I have subsequently worked up a workflow for the processing of
p-wave first arrivals.  I am suppressing any thought of any signal
that is not a first arrival, but I think that I can make it work
within a day.  I am going to the library this afternoon to look into
this some more.

Tim


Again, glad to see someone working on this issue and always happy to
offer insight from the soils/NRCS perspective.

Cheers,
Dylan

PS: I have cc-ed my "work" email address, as I don't always check my
gmail account.

___
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepts 22 students for Google Summer of Code 2013

[Benjamin Ducke]

Three student project for GRASS this summer.
What a great outcome! To our GSoC students:
Welcome to the team, hope this will be a
great experience for you. To those who didn't
get accepted this time around: stay with us,
GSoC is not the only way of contributing and
having fun with GRASS GIS development. And
there's always another GSoC ...

Best,

Ben

On 05/27/2013 09:16 PM, Markus Neteler wrote:

FYI - great news below...

Markus


-- Forwarded message --
From: Anne Ghisla 
Date: Mon, May 27, 2013 at 9:05 PM
Subject: [OSGeo-Discuss] OSGeo accepts 22 students for Google Summer
of Code 2013
To: OSGeo Google Summer of Code list , OSGeo
Discuss list 


Hello all,

let us warmly welcome the 22 accepted students for this round of GSoC!

We received over 30 proposals from a variety of geospatial projects,
and we accepted proposals from (in alphabetical order): GEOS, GRASS GIS,
gvSIG, istSOS, MapServer, Opticks, OSGeo4W, OpenStreetMap, OSSIM,
software packaging, pgRouting, QGIS and uDig/GeoTools.

The list includes OSGeo projects (official and incubating) and
like-minded projects such as OSM, pgRouting, uDig and istSOS - let GSoC
be a "gathering of tribes", an occasion to improve communication among
all geospatial open source initiatives.

See the full list of OSGeo students here:
http://www.google-melange.com/gsoc/org/google/gsoc2013/osgeo

We wish all students and mentors a great summer!

Anne, Hamish and Dustan
OSGeo GSoC Admins


___
Discuss mailing list
disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] reminder for potential gsoc students

[Benjamin Ducke]

Excellent, thanks Sören.
I have added your name to the wiki entry.

Best,

Ben

On 05/01/2013 10:44 PM, Sören Gebbert wrote:

Hi,
please count me in as co-mentor.

Best regards
Soeren


2013/5/1 Benjamin Ducke mailto:bendu...@fastmail.fm>>

Please note that I have added another
project proposal for the GSoC


http://grasswiki.osgeo.org/__wiki/GRASS_SoC_Ideas_2013#__Improve_GRASS.27_kriging_and___3D_interpolation_capabilities

<http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Improve_GRASS.27_kriging_and_3D_interpolation_capabilities>

We have a student (Corey Zhang), who would like
to take on this task, and I would be willing
to act as one mentor. I would really like to
have the support of at least one co-mentor
though, preferably someone with good knowledge
of the GRASS 3D API -- to help out in case
something gets seriously stuck and to advise
on good code architecture.

Best,

Ben


On 05/01/2013 10:56 AM, Martin Landa wrote:

Hi all,

just a small reminder for potential GSoC [1] students. The deadline
for submitting the application is Fri May 3: 19:00 UTC [2]. The more
proposal we will have, the better for us...

Martin

[1] http://grasswiki.osgeo.org/__wiki/GRASS_SoC_Ideas_2013
<http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013>
[2]

http://www.google-melange.com/__document/show/gsoc_program/__google/gsoc2013/help_page#2.___What_is_the_program_timeline

<http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline>

--
Martin Landa http://gmail.com>> *
http://geo.fsv.cvut.cz/~landa
_
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/grass-dev
<http://lists.osgeo.org/mailman/listinfo/grass-dev>




--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

bendu...@fastmail.fm <mailto:bendu...@fastmail.fm>

_
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/grass-dev
<http://lists.osgeo.org/mailman/listinfo/grass-dev>






--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] reminder for potential gsoc students

[Benjamin Ducke]

Please note that I have added another
project proposal for the GSoC

http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Improve_GRASS.27_kriging_and_3D_interpolation_capabilities

We have a student (Corey Zhang), who would like
to take on this task, and I would be willing
to act as one mentor. I would really like to
have the support of at least one co-mentor
though, preferably someone with good knowledge
of the GRASS 3D API -- to help out in case
something gets seriously stuck and to advise
on good code architecture.

Best,

Ben

On 05/01/2013 10:56 AM, Martin Landa wrote:

Hi all,

just a small reminder for potential GSoC [1] students. The deadline
for submitting the application is Fri May 3: 19:00 UTC [2]. The more
proposal we will have, the better for us...

Martin

[1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013
[2] 
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] introduce myself

[Benjamin Ducke]

Hi Eva --

That sounds great.
Corey: In that case, maybe you could build
on Eva's work by adding alternative 3D
interpolation algorithms? I was thinking
RBF and something suitable for interpolating
categorical data from 3D point samples, such
as transitional probabilities?

Best,

Ben

On 04/24/2013 03:48 PM, anast...@centrum.sk wrote:

Hi Corey, hi Ben,

I am new at mailing list, but I deal with 3D kriging module for GRASS
GIS as a PhD student for my dissertation thesis. The module enables
to krige 2D and also 3D data (using 3D variogram), nowadays I
continue testing and optimizing performance to make the module
appropriate for publishing for other users.

Best regards

Eva Stopkova Bratislava, Slovak republic
___ grass-dev mailing
list grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] introduce myself

[Benjamin Ducke]

Hi Corey,

Some simple and efficient algorithms for 3D
interpolation would indeed be welcome.
Currently, GRASS has 3D spline interpolation,
but RBF and kriging are still missing.
I have experience with both geostatistics and
3D interpolation and would be willing to
mentor on the design of the implementation.
But we would need someone with better know-
ledge of the GRASS 3D raster API.

Re. kriging, it will not be enough to just
implement the interpolation itself. To get
optimal 3D kriging models, it would also
be necessary to design and implement some
exploratory tools (variogram) etc. for 3D
data. Actually, my opinion is that kriging
capabilities should be provided both for
2D and 3D data, as we are missing native
GRASS modules in both cases.

Best,

Ben


On 04/24/2013 04:29 AM, 张思阳 wrote:

Hi everyone:
  I am Corey Zhang, I am a graduate student from Nanjing
Normal University China. My main research direction is 3D interpolation
with RBF(radial basis functions) and with kringing. I want to spend this
summer to make a geostatistics tool for GRASS GIS, even though I do not
see any relevant information on GRASS GIS's idea page. I want to make
sure whether a geostatistics tool is necessary for GRASS GIS or not. If
any one is interested in my idea or want to be my mentor, please contact me.

Corey
Nanjing China


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.category report area

[Benjamin Ducke]

Hi,

On 04/12/2013 03:05 PM, Martin Landa wrote:

Hi all,

`v.category` (G7) reports categories also for areas.

v.category rb opt=report
Layer: 1
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid   1  1  1
area   1  1  1
face   0  0  0
kernel 0  0  0
all1  1  1

Categories are assigned only to the centroids. Areas (topological
composition of boundaries and centroid) shouldn't  be reported by
`v.category`, I would say (?)

Martin





My understanding is the same as Martin's:
in the case of areas, categories are attached to
centroids, so the above output is a bit confusing.

However, since "areas" do not physically exist in
a GRASS map (only the centroids and boundaries do),
there is a problem here: what if some centroids are
without a category, but still part of an area?
What if there are centroids with categories that are
not placed correctly within a boundary? This
could happen in incomplete or incorrect maps.
And in these cases the difference between the
stats for "centroid" and "areas" can be important
information.

Perhaps instead of always outputting the "area" line,
the module should only output an extra line (or even
a warning) if there is a mismatch between the number
of categorized areas and centroids.

Best,

Ben


--
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.out.ascii features without category

[Benjamin Ducke]

Hi,

On 04/10/2013 11:44 AM, Martin Landa wrote:

Hi all,

`v.out.ascii` (G7) doesn't export features without categories.

v.random out=n n=10 --o
v.category in=n out=n1 opt=del cat=-1 --o
v.out.ascii n1
WARNING: No points found, nothing to be exported

Is there any reason why `v.out.ascii` ignores features without
category? I would suggest to export also features without categories.
Probably also to add new flag "Export only features with category".

What do you think?


Hmmm, difficult:
In GRASS 6.4.x, v.out.ogr also exports all features by
default, so making the suggested change would improve
consistency there.

But: in GRASS 7 the default behaviour of v.out.ogr
was reversed in this respect ...

Maybe v.out.ascii should follow the convention
of v.out.ogr in each respective GRASS version?

Cheers,

Ben



Martin

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal fp precision loss

[Benjamin Ducke]

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 also affect r.external?

Ben



thanks for noticing,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] releasing 6.4.3

[Benjamin Ducke]

On 03/10/2013 10:02 PM, Markus Neteler wrote:

On Sun, Mar 10, 2013 at 9:49 PM, Helmut Kudrnovsky  wrote:
...

if we know that installing vcredist_2010_x86.exe would be enough, it should
be doable by the nsis-wingrass-installer...


We could try... then decide. If it is not too much mess?

BTW:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
-> VSU1\vcredist_x86.exe for 2012


Unfortunately, there is no such thing as a "DLL path"
on Windows. See the treatise on confused operating
system design here:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

(enjoy "Standard Search Order for Desktop Applications"!)

This whole drama might be resolved once there is a
complete build chain based on MSYS/MinGW-64 to replace
Visual C/C++. I am working on this:

http://gvsigce.sourceforge.net/wiki/index.php/Setting_up_the_GNU_Compiler_Collection

The above includes GRASS and all of its dependencies
except for WxWidgets. However, the latter also seems
to build OK with recent versions of MinGW-64:

http://wxwidgets.blogspot.de/2011/06/choosing-gcc-for-building-wxwidgets.html

Realistically speaking, it will take a few more
weeks for me to complete and test the build chain.
We plan to release the resulting binaries with
gvSIG CE 1.0 (which will ship with GRASS 6.4.3 as
a geoprocessing backend). From that point forward,
i.e. GRASS 6.4.4, it might be feasible to base GRASS
Windows releases on the gvSIG CE build chain:
no more pesky VC runtime DLLs!

Also, in case you are not using it yet:
"Dependency Walker" is really helpful for
locating DLL-related problems.

Best,

Ben



Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS_VERSION_* hardcoded in gem/Makefile

[Benjamin Ducke]

I am sure there isn't a good reason.
GEM is no longer maintained and nobody
seems to use it. Mabye 6.4.3 would be
a chance to drop it?

Cheers,

Ben

On 01/06/2013 04:30 PM, Maciej Sieczka wrote:

What is the reason gem/Makefile has GRASS_VERSION_MAJOR and
GRASS_VERSION_MINOR hardcoded, rather than set to the make var, as in
include/Make/Grass.make.in?:

configure:GRASS_VERSION_MAJOR=`sed -n 1p "${GRASS_VERSION_FILE}"`
include/Make/Grass.make.in:GRASS_VERSION_MAJOR   = @GRASS_VERSION_MAJOR@
gem/Makefile:GRASS_VERSION_MAJOR=6

configure:GRASS_VERSION_MINOR=`sed -n 2p "${GRASS_VERSION_FILE}"`
include/Make/Grass.make.in:GRASS_VERSION_MINOR   = @GRASS_VERSION_MINOR@
gem/Makefile:GRASS_VERSION_MINOR=4

Maciek





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 6.4.3 release planning; v.external 3D

[Benjamin Ducke]

[..]



And the ability to use v.external with 3D data
sources.


Please try attached v.external64_3D.diff.



That looks good. I will try this (i.e. the
current SVN snapshot) with some 3D data and
report back.



From what I can tell, 3D vertices are read
correctly by v.external now, and the data's Z
extent is also set correctly. Great.

Would it be possible to implement the same
behaviour in v.in.ogr, i.e. have it auto-
matically read Z data from 3D sources, instead
of having to set the "-z" flag manually?

Or would that change the expected behaviour too
much for a 6.4.x release?

Cheers,

Ben


Cheers,

Ben


Markus









--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Benjamin Ducke]

On 11/30/2012 02:36 PM, Markus Neteler wrote:

On Thu, Nov 29, 2012 at 10:16 PM, Benjamin Ducke  wrote:

The "outdir=" option in r.walk.


Do you refer to this potentially missing backport?
https://trac.osgeo.org/grass/ticket/1154#comment:1



Yes, I suppose we need both "outdir=" in r.walk
and "indir=" in r.drain backported to 6.4.x.


And the ability to use v.external with 3D data
sources.


Please try attached v.external64_3D.diff.



That looks good. I will try this (i.e. the
current SVN snapshot) with some 3D data and
report back.

Cheers,

Ben


Markus





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Benjamin Ducke]

The "outdir=" option in r.walk.

And the ability to use v.external with 3D data
sources.

Best,

Ben

On 11/29/2012 09:16 PM, Markus Neteler wrote:

Hi,

which important backports are lacking for
the next release candidate?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] making GEOS as manatory dependency for grass7 ?

[Benjamin Ducke]

{snip}



Why should using the C standard lib's free() a bug?


Because just using free() on something that should be released with some
specific function assumes that that function is just a wrapper around free().
That might not be the case or might change over time.  It also ignores the fact
that there can be multiple heap managements like on windows, when multiple
compiler versions (and therefore their RTL) are used.



Right, I get that. I was unaware of the issue
with different heap managements. Thanks for
pointing that one out.

Cheers,

Ben



Jürgen





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] making GEOS as manatory dependency for grass7 ?

[Benjamin Ducke]

Jürgen --

The problems are mostly with linking compiled C++
code. Due to the different name mangling schemes,
a DLL produced by VC might not be usable by
an EXE produced with MinGW and vice versa.

There are tools to work around that:

http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

I have tried and it works -- sometimes.

Anyway, it's a wasted effort for me, as I prefer
to fix source code and configure files so that
everything compiles cleanly using MinGW.

Why should using the C standard lib's free() a bug?

Cheers,

Ben

On 11/05/2012 12:38 AM, Jürgen E. Fischer wrote:

Hi Ben,

On Sun, 04. Nov 2012 at 23:32:41 +0100, Benjamin Ducke wrote:

Indeed: MinGW and VC DLLs do not mix well,


In what way?

An important thing is to use the right function to release memory (G_free(),
GEOSFree(), CPLFree()...).  Simply using free() might crash on windows, but
that IMHO should be considered a bug anyway.


Jürgen





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] making GEOS as manatory dependency for grass7 ?

[Benjamin Ducke]

I maintain a separate set of GRASS Windows
binaries, for use from within gvSIG/SEXTANTE.
Those are compiled from scratch, using only MinGW.
I like to avoid proprietary tools.

It's pretty straight-forward these days to
get the mandatory dependencies and most
GDAL drivers compiled using MinGW and MSYS.

Indeed: MinGW and VC DLLs do not mix well, so
it's better to compile everything with either
one or the other.


Ben

On 11/04/2012 11:25 PM, Martin Landa wrote:

Hi,

2012/11/4 Benjamin Ducke :


This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.


sorry, probably I am not getting the point. Then you would need to
recompile major part of OSGeo4W packages (due to VC).

Martin

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] making GEOS as manatory dependency for grass7 ?

[Benjamin Ducke]

Thanks Martin, I shall take a look and see
if I can learn anything from their Makefiles.

However, I fear that they used VC:

http://trac.osgeo.org/osgeo4w/wiki/pkg-geos

so there might be some problems replicating this
with MinGW.

This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.

Cheers,

Ben

On 11/04/2012 10:52 PM, Martin Landa wrote:

Hi,

2012/11/4 Benjamin Ducke :

GEOS is a beast to compile on MinGW though, so creating
Windows binaries using open source tools might get
considerably harder with this added dependency.

This issue might resolve itself in the future, provided
that MinGW support improves.


note that GEOS is provided through OSGeo4W framework [1] and winGRASS
is compiled against GEOS [2].

Martin

[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-geos
[2] 
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/osgeo4w/package.sh#L131

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] making GEOS as manatory dependency for grass7 ?

[Benjamin Ducke]

GEOS is a beast to compile on MinGW though, so creating
Windows binaries using open source tools might get
considerably harder with this added dependency.

This issue might resolve itself in the future, provided
that MinGW support improves.

Ben


On 11/04/2012 10:17 PM, Moritz Lennert wrote:

Hi,

I really like the GEOS-based enhancements to v.select and in the
discussion of bug #1464 [1], it also seems that buffers only work
correctly when using the GEOS library. Both of these alone seem
sufficient to me to warrant making GEOS a mandatory dependency for GRASS.

Or at least, I would like to plead to packagers to compile with-geos.

Moritz


[1] http://trac.osgeo.org/grass/ticket/1464
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev




--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.modis in GRASS 7 trunk

[Benjamin Ducke]

I would like to express a different point of view.

One of the nice things about GRASS in its current
form is that one download will get you hundreds
of modules without having to worry about installing
add-ons.

What's the difference between having 300 or 500
modules in the base distribution? GRASS has the
file layout required to scale up to this size
easily, and each individual module is small and
lean. Even if we were to triple the number of
modules in the base distribution, the download
size would not increase significantly (and vice
versa).

On the other hand:

- Having to compile add-ons written in C/C++ is a
big obstace, g.extension or not, for many users,
especially on Windows.

- It is hard to ensure consistent quality across
external add-ons.

- Documentation for such add-ons cannot be included
in the main online index.

- There is always a risk that useful add-ons maintained
by external developers will be abandoned.

- Putting modules into extension groups will never
be free of overlap and always leave people wondering
where the wanted module is. The basic r.*, v.* etc.
and some good keywords are a much better system IMHO.

So I am not convinced about the merits of breaking
the GRASS distribution into smaller pieces and add-ons.
Instead, I would say the base distribution should grow
as required and include new, useful modules such as r.modis.

Cheers,

Ben

On 10/30/2012 11:43 AM, Yann Chemin wrote:

Hi Martin,

I have no worries, since I do load modules directly. I am worried about
the learning curve for Windows-bound students in need of MODIS images,
but not comfortable with GRASS GIS yet.

But this is an old story coming back,

I am all for reducing significantly the number of modules in GRASS, to
have a lean download.

We can indeed have groups of plugins to get through g.extension:

- Hydrologically related
- Imagery
- Temporal
- 3D
- DB (though I am not a user, so cannot be sure of how much needed)

This would keep import/export, some of the basic raster and vector ones.
Neat small download, use g.extension for anything else, by group or on
demand.

Yann

On 30 October 2012 15:08, Martin Landa mailto:landa.mar...@gmail.com>> wrote:

Hi,

2012/10/30 Yann Chemin mailto:yann.che...@gmail.com>>:
 > as a regular user of MODIS, I would like to call other MODIS users to
 > express interest to include r.modis into GRASS 7 SVN.

we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.

Do you have any problem with installing r.modis using g.extension?

Martin

--
Martin Landa http://gmail.com>> *
http://geo.fsv.cvut.cz/~landa <http://geo.fsv.cvut.cz/%7Elanda>




--
Yann Chemin



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [osgeo4w] #305: python/sqlite: "sqlite3-rtree-geometry-callback" not found in "C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll"

[Benjamin Ducke]

Windows goes by two rules (in this order, if I remember
correctly):

1. Pick up the DLL from the directory in which the
.exe that is linked against it resides.

2. Pick it up from the first directory that is one
of the system's executable directories (such as
C:\Windows\Win32), i.e. listed in the PATH env var.

There is no global directory for dynamic libraries,
such as "/usr/lib" on Linux, and no dedicated dyamic
linker path, such as "LD_LIBRARY_PATH", either.

Welcome to "DLL hell" ...

Ben

On 10/28/2012 09:04 PM, Markus Neteler wrote:

Glynn, Soeren, all:

any idea how GRASS 7 decides which sqlite3.dll to pick up?

thanks
Markus


-- Forwarded message --
From: OSGeo4W 
Date: Sun, Oct 28, 2012 at 6:03 PM
Subject: Re: [osgeo4w] #305: python/sqlite:
"sqlite3-rtree-geometry-callback" not found in
"C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll"
To:
Cc: osgeo4w-t...@lists.osgeo.org


#305: python/sqlite: "sqlite3-rtree-geometry-callback" not found in
"C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll"
-+--
Reporter:  hellik|   Owner:  brushtyler
 Type:  defect|  Status:  new
Priority:  critical  |   Component:  Package
  Version:  1.0   |Keywords:  python,sqlite
-+--

Comment(by brushtyler):

Replying to [comment:29 esseffe]:

Sorry, but I'm completely unable to understand why SpatiaLite is
  supposed to be anyway related to this topic.


  spatialite is not related at all, as well as the sqlite3 in \bin (the one
  I built).

  I'm still writing that the problem is that grass7-dev uses the wrong
  sqlite3.dll, the one shipped with python.

  We have to choose if replace (or better remove) that DLL, otherwise the
  grass7-dev code has to be changed to use the sqlite3.dll in \bin (passing
  the full path to ctypes when loading the sqlite3.dll library).

  I would prefer to remove the duplication.

  AFAICS in the .vcprops files of the python source package, the
  Python27\DLLs\sqlite3.dll is compiled using default settings (for that
  reason it doesn't contain the sqlite3_rtree_geometry_callback function).

--
Ticket URL: <https://trac.osgeo.org/osgeo4w/ticket/305#comment:30>
OSGeo4W <http://trac.osgeo.org/osgeo4w>
OSGeo4W is the Windows installer and package environment for the OSGeo stack.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev





--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.transform dysfunctional in 6.4.3.svn

[Benjamin Ducke]

On Thu, Oct 25, 2012, at 17:23, Markus Metz wrote:
> On Thu, Oct 25, 2012 at 12:06 PM, Benjamin Ducke 

{SNIP}

> 
> This table option is a bit strange. Looking at the code, it is not
> clear which column is used as key column to select the appropriate
> transformation parameters for a given point, probably a column named
> "cat". Furthermore, there are no options to define database and
> driver. In GRASS 7, I have removed the table option, the table is here
> selected through the layer option, which is also used to select the
> appropriate category for a given point, also in GRASS 6.
> 
> I have changed the behaviour of v.transform in r53553/4 such that the
> table option can be safely ignored. Individual transformation
> parameters stored in an attribute table can be used with the 'layer'
> and 'columns' option. In theory the table option is still recognized.
> Is this OK?

Sounds good to me.

Best,

Ben

> 
> Markus M
> 
> >
> > Anyhow, without the "table=" option set, v.transform crashes
> > due to this block of code on line 166 of trans_digit.c:
> >
> > if (field > 0) {
> > db_close_database_shutdown_driver(driver);
> > G_free((void *)trans_params);
> > }
> >
> > The problem here is that "driver" never gets malloc'd,
> > unless the "table=" option is given (look at lines
> > 53 and following in trans_digit.c).
> >
> > With the "table=" option given, there are still illegal
> > write operations. Valgrind points to lines 88, 126 and
> > 136 of trans_digit.c as culprits. These will make
> > v.transform crash or not -- depending on your luck.
> >
> > Cheers,
> >
> > Ben
> >
> > --
> > Benjamin Ducke
> > {*} Geospatial Consultant
> > {*} GIS Developer
> >
> >   benducke AT fastmail.fm
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.transform dysfunctional in 6.4.3.svn

[Benjamin Ducke]

Dear Devs,

it seems that some recent additions to v.transform have broken
the module. There are several places in which read or write
operations to addresses that have not been malloc'd lead to
crashes.

The problems all seem to be related to the new option "table=".
It is unclear to me what this option is intended for. Is it
an input or an output option? Maybe some information should
be added to the HTML manual page.

Anyhow, without the "table=" option set, v.transform crashes
due to this block of code on line 166 of trans_digit.c:

if (field > 0) {
db_close_database_shutdown_driver(driver);
G_free((void *)trans_params);
}

The problem here is that "driver" never gets malloc'd,
unless the "table=" option is given (look at lines
53 and following in trans_digit.c).

With the "table=" option given, there are still illegal
write operations. Valgrind points to lines 88, 126 and
136 of trans_digit.c as culprits. These will make 
v.transform crash or not -- depending on your luck.

Cheers,

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] gvSIG CE code sprint in Munich

[Benjamin Ducke]

Dear All:

There will be a gvSIG CE code sprint in Munich in just
a few weeks' time.

One of the areas we will focus on is better integration of
GRASS GIS into gvSIG CE (via SEXTANTE). 

In case you are interested in joining us in Munich or just 
curious about the progress of gvSIG CE and SEXTANTE (Java),
please see our code sprint wiki page:

http://gvsigce.sourceforge.net/wiki/index.php/GvSIG_CE_Code_Sprint_in_Munich

Best,

Ben

---

Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS and sextante

[Benjamin Ducke]

Theoretically, it wouldn't be very hard to read the labels
from the mapset in which SEXTANTE is storing the (temporary)
GRASS datasets; they are saved as plain ASCII there.

However, the host GIS for SEXTANTE must then somehow deal
with this additional data in some useful way (e.g. via a 
virtual raster attribute table).

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm


On Mon, Jun 4, 2012, at 16:45, Paolo Cavallini wrote:
> Hi all.
> Now working on sextante interface to grass. One problem I'm finding is:
> - GRASS raster can have labels (very convenient, e.g. r.param.scale saves
> feature
> names along with categories)
> - when saving to TIFF, these are stripped
> - as a consequence, the flow DTM>Features raster>Feature vector strips
> the
> categories, and data are lost.
> Any way of keeping them? Of course we can Use raster values as
> categories, but
> keeping the labels would be much better. One way would be to pipe
> directly the two
> GRASS commands, without exporting in between, but this is not implemented
> yet.
> All the best.
> -- 
> Paolo Cavallini - Faunalia
> www.faunalia.eu
> Full contact details at www.faunalia.eu/pc
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] reducing screen clutter

[Benjamin Ducke]

This sounds like a familiar problem. Most file/web
browsers let the choose whether to stay in the same
window or open a new one when browsing to a new
location.

So perhaps there should be an option in the GUI to
"allow multiple windows per module" which could be
set to "false" by default?

Ben

On 05/24/2012 05:34 PM, Paulo van Breugel wrote:

True that having the same dialogue open several times can be annoying.
But not always, it may come in handy if you want to run the same module
several times with different parameters (run at the same time, or
prepare one while the other is still running; btw, I actually never
checked how it is handled if you run the same function twice in
parallel, are they run at the same time on different cores?).




On Thu, May 24, 2012 at 4:18 PM, Michael Barton mailto:michael.bar...@asu.edu>> wrote:

This is one way, but not exactly what I was talking about. In fact,
sometimes it is very useful to keep a dialog box open to rerun the
same module repeatedly with different parameters.

What I meant is that once it is open, GRASS should not open
additional dialogs for the same module but simply reuse the one that
is open. That way you never get 5 windows for v.distance, only
1--even if you leave it open.

Michael



On May 24, 2012, at 2:26 PM, Moritz Lennert wrote:

 > On 24/05/12 12:25, Chemin, Yann (IWMI) wrote:
 >> Maybe we can modify the GUI preferences:
 >>
 >> Default: All dialog boxes close after a run is complete
 >> In Preferences: Tick this box if you want the dialog boxes to be
closed
 >> manually (i.e. stay after a run)
 >
 >
 > The tick box already exists, so you are suggesting to make
closing the dialog the default ? I find it quite useful, especially
for newbies, to have the dialog open and be able to correct wrong
input, instead of having to fill the whole dialog out again... But I
can confirm that it takes some teaching to make them aware of that
feature and avoid that they open the same command ten times. ;-)
 >
 > Moritz

_
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton
<http://www.public.asu.edu/%7Ecmbarton>, http://csdc.asu.edu





___
grass-dev mailing list
grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev




--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] disabling compression

[Benjamin Ducke]

According to the docs, GRASS_INT_ZLIB can be set to use
LZW instead of RLE compression. But as far as I can see,
there is not yet a way to completely prevent rasters from
being compressed at creation time?

Ben

On 04/25/2012 09:24 AM, Maris Nartiss wrote:

  There's already an existing GRASS_INT_ZLIB env variable. There should
be only one env variable to enable/disable raster compression.

Just my 0.002 Verizon cents.
Maris.

2012. gada 24. aprīlis 18:02 Jim Regetz  rakstīja:

Chagrined by a performance hit apparently involving zlib compression, I
patched my local GRASS 7.0 to accept an environment variable that disables
raster compression. At least for the particular DCELL rasters I've been
using, this yields a ~5x improvement in run time during write operations, at
a cost of some extra disk usage that I'm often more than happy to incur. See
sample timing outputs below my sig.

Admittedly, the speedup factor drops to ~2.5x if the timing comparisons
include a forced sync to disk, because uncompressed output means more IO.
But that's still a nice speedup, and the disk IO cost may be of little
consequence in cases where the raster can fit comfortably in the OS page
cache and is an intermediate output that gets read back in during a
subsequent step of a particular processing workflow (and perhaps then
removed before ever being flushed to disk).

My demo-purposes patch is attached. It just adds a GRASS_NO_COMPRESSION
environment variable and then injects a new conditional dispatch into each
of the three Rast_open{_,_fp_,_c_}new functions. For cleaner semantics, it
might be better to keep the original functions but rename them as
*_compressed (paralleling the existing *_uncompressed versions) for callers
who really want/need to force compression (e.g., r.compress, which my patch
in some sense "breaks" when the environment variable is set), but I didn't
do this here. And I haven't looked hard to see if other modules/etc truly
depend on the existing compression behavior.

Any chance something like this could make it into trunk?

As a real world example, I recently wrote a Python module that relies on
r.mapcalc, r.neighbors, and r.samp.stats. With GRASS_NO_COMPRESSION set,
total runtime dropped from 20 minutes to 10 minutes on a 12K by 12K input
raster, with a disk usage differential that peaked at ~4GB during
processing. Outputs were identical other than compression.

Cheers,
Jim

--
James Regetz, Ph.D.
Scientific Programmer/Analyst
National Center for Ecological Analysis&  Synthesis
735 State St, Suite 300
Santa Barbara, CA 93101


# timings performed on Ubuntu 10.04 with ample RAM and a recent
# build of GRASS 7.0-svn with the applied patch

# describe the 'test' raster used below; based on some 90m SRTM
# data coerced to double precision
GRASS 7.0.svn (tmp):~>  r.info -g test
...
rows=4801
cols=4801
cells=23049601
datatype=DCELL

GRASS 7.0.svn (tmp):~>  r.univar test
total null and non-null cells: 23049601
total null cells: 0

Of the non-null cells:
--
n: 23049601
minimum: 500
maximum: 3139
range: 2639
mean: 1445.04
mean of absolute values: 1445.04
standard deviation: 336.437
...


# using (default) zlib compression on write
GRASS 7.0.svn (tmp):~>  g.gisenv set="OVERWRITE=1"
GRASS 7.0.svn (tmp):~>  g.region rast=test
GRASS 7.0.svn (tmp):~>  unset GRASS_NO_COMPRESSION
GRASS 7.0.svn (tmp):~>  sync; echo 3>  /proc/sys/vm/drop_caches
GRASS 7.0.svn (tmp):~>  time r.mapcalc "foo = test" --quiet

real0m13.209s
user0m12.660s
sys 0m0.400s


# after disabling compression on write
GRASS 7.0.svn (tmp):~>  g.gisenv set="OVERWRITE=1"
GRASS 7.0.svn (tmp):~>  g.region rast=test
GRASS 7.0.svn (tmp):~>  export GRASS_NO_COMPRESSION=1
GRASS 7.0.svn (tmp):~>  sync; echo 3>  /proc/sys/vm/drop_caches
GRASS 7.0.svn (tmp):~>  time r.mapcalc "foo = test" --quiet

real0m2.514s
user0m2.320s
sys 0m0.170s


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev




--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PostGIS manager for GRASS GIS

[Benjamin Ducke]

On 04/02/2012 05:11 PM, Mohit Kumar wrote:

[snip]



Thanks for your reply.
Its good to know that development is ongoing for this in GRASS, I
sincerely want to work on this as my GSoc task.
I have made a brief idea for the manager. The following are the various
modules of the manager
1. Setup connection : This module will set up the connection with the
remote database. It will take the input parameters from user and pass
them to a connection string. After the connection has been established,
the user will be shown the various tables(maps) that are stored and
other information about the database and the connection
2. View and edit data : This will display the data of the table in a
window frame. One can view the map and modify the table values or the
attributes.
3. Import to GRASS Data : This gives the user an option to save the data
in Grass format for further processing/analysis of the data. This also
gives user an option to discard the data which is of no use.
4. Execute PostGis functions (geometry processing)on database and save
output in grass data format.
5. SQL interface : This provides the advanced user to modify the
database by use of direct SQL commands on the database.
6. Export GRASS data to PostGIS data : Convert the Grass Data to SQL
database. First convert the Grass data to Esri Shapefile(.shp) using OGR
and then converting that data to SQL database (shape2sql).


Since the PostGIS data model is much more flexible than a Shapefile:
Why not directly convert the GRASS data to PostGIS WKB/WKT?

Ben


7. Projection support : I was also thinking of adding projection support
to the manager.
These are the various major points for a spatial database manager I can
think of. Can you please provide me your suggestions.

Looking forward to your support as the time left to apply is very less.

Regards,
--
Mohit Kumar(mohitkharb on irc)
Lab For Spatial Informatics
International Institute of Information and Technology
Hyderabad, India
+91-970-3840-175

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev




--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Speeding up v.out.ogr (again)

[Benjamin Ducke]

>
> I think it's rather the dblib than v.out.ogr. Recently I have fixed a
> few memory leaks in dblib, but no optimizations. The dbf driver in
> particular is terribly slow. An index like for real database backends
> might help, although that would need to be created on the fly since
> dbf does not support indexes. Nevertheless, I noticed that a lot can
> be done on module level. The new v.out.ply addon for example is based
> on v.out.ascii, and v.out.ply with attribute export is magnitudes
> faster than v.out.ascii with attribute export.
> 
> Markus M
> 

OK then. For the time being, I will continue to experiment with
my own fork of v.out.ogr, and will report back if I make any
progress.

Best,

Ben

> >>
> >>
> >> >> >
> >> >> > If so, then I suggest putting in a condition, so that those
> >> >> > GRASS maps that have just one attribute table can perform
> >> >> > the SQL SELECT outside of mk_att(). Otherwise, we punish
> >> >> > all GRASS users with extremely slow export speed, even though
> >> >> > most of them might not even use multi-table attributes in
> >> >> > their projects. The difference in my test was something like
> >> >> > factor 500!
> >> >>
> >> >> Please test if attribute assignment is preserved and attributes are
> >> >> not randomly swapped. A stream vector created with r.stream.extract
> >> >> would be a good test case.
> >> >>
> >> >
> >> > Will do.
> >> >
> >> > Ben
> >> >
> >> >> Markus M
> >> >>
> >> > ___
> >> > grass-dev mailing list
> >> > grass-dev@lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Add a cost distance measure to GRASS GIS lib

[Benjamin Ducke]

> 
> Even cost along a straight line (or maybe a great circle?) is
> computationally expensive, and in the general case would require
> holding the entire cost map in memory. Less-general cases would have
> to be implemented within the module, as the libraries wouldn't know
> how the module intends to access the cost map.
> 
> Also, many algorithms which have a concept of distance require that it
> follows the conditions for a metric, i.e. for some metric d and all
> points x, y, z:
> 
>   d(x,x) = 0
>   d(x,y) >= 0
>   d(x,y) = d(y,x)
>   d(x,z) <= d(x,y) + d(y,z)
> 
> A distance calculated by integrating a cost map along a fixed path
> could violate the fourth condition (transitivity).
> 
> Other algorithms (e.g. r.grow.distance) require that distance
> increases monotonically with both delta-x and delta-y, and the
> proposed solution would violate that.
> 

Right, a general and simple solution for cost-based distance
is not as straight forward as I thought it might be.

I will think about how this could be done for individual
modules instead -- and which modules would actually
benefit significantly from cost distances.

Thanks for all the feedback.

Ben

> -- 
> Glynn Clements 
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Speeding up v.out.ogr (again)

[Benjamin Ducke]

> I think I understand your error. You confuse feature id with category
> value. The feature order in the output file depends on the feature
> order of the GRASS input vector, and the feature order of the GRASS
> input vector has absolutely nothing to do with the category order.
> There was a good reason why I wrote "the cursor really needs to be
> opened for each cat separately".
> 

I thought so. Just didn't know what that reason was. 
That's why I asked.

> You have again introduced a serious bug (the same one for the second
> time) in one of the main GRASS modules. Please revert this change
> immediately or I have to revert this change, again.
> 

I haven't touched anything, so there's nothing to revert. 
Just wanted to discuss some thoughts on this list, that's all.

But I still think that something needs to be done
to speed up v.out.ogr.

Best,

Ben

> Thanks,
> 
> Markus M
> 
> 
> >> >
> >> > If so, then I suggest putting in a condition, so that those
> >> > GRASS maps that have just one attribute table can perform
> >> > the SQL SELECT outside of mk_att(). Otherwise, we punish
> >> > all GRASS users with extremely slow export speed, even though
> >> > most of them might not even use multi-table attributes in
> >> > their projects. The difference in my test was something like
> >> > factor 500!
> >>
> >> Please test if attribute assignment is preserved and attributes are
> >> not randomly swapped. A stream vector created with r.stream.extract
> >> would be a good test case.
> >>
> >
> > Will do.
> >
> > Ben
> >
> >> Markus M
> >>
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Speeding up v.out.ogr (again)

[Benjamin Ducke]

> 
> No, this is because the i-th feature does not need to have category i,
> it can have any category and multiple categories. Selecting all
> attributes at once for all categories is also not memory-safe for
> larger vectors.
> 

Hmm, let's say we take the smallest and largest category values
in the map to export, then chop up the range of values into
reasonably sized chunks let's say max. 1000 features, and select
a chunk at a time. Shouldn't that make sure that we get all
features and also have a guaranteed maximum memory footprint?

If the category values in the GRASS map are not strictly
increasing, then the feature order will be changed in the
output file. However, I am not sure whether this would be
a problem, given that the feature<->attribute links stay
intact?

> >
> > If so, then I suggest putting in a condition, so that those
> > GRASS maps that have just one attribute table can perform
> > the SQL SELECT outside of mk_att(). Otherwise, we punish
> > all GRASS users with extremely slow export speed, even though
> > most of them might not even use multi-table attributes in
> > their projects. The difference in my test was something like
> > factor 500!
> 
> Please test if attribute assignment is preserved and attributes are
> not randomly swapped. A stream vector created with r.stream.extract
> would be a good test case.
> 

Will do.

Ben

> Markus M
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Add a cost distance measure to GRASS GIS lib

[Benjamin Ducke]

I believe we are thinking in different directions here.
My idea was not about _least_ cost paths, but about
replacing straight-line distance measurements with
cost-based distances -- for more realism when modelling
physical processes. Just like you'd use a geodetic
distance instead of eculidean in a lat/lon region.

What I was thinking about was to have just one CONST
raster that encodes the cost of moving through each
of its cells (in all directions in the simple
isotropic case).

All GRASS modules that use fixed neighborhoods or
flexible search radii would then measure the distance
between two points by accumulating the costs in the
cells on the straight line between the two points.

Suppose the user has created a COST raster with "1"
representing "no additional cost" and "2" representing
"doubled cost for crossing steep terrain". Then if
he/she specified 100 m as e.g. the search radius for
a KDE, the maximum search distance will in some
extreme cases already be reached after approximately
50 m, because those 50 cost as much as 100 m on flat
terrain. That would make the kernel's shape flexible
and adjusted to the real terrain, instead of a fixed
circle. 

The same idea translates 1:1 to IDW, r.neighbors, etc.

Ben

On Thu, Mar 1, 2012, at 17:14, Glynn Clements wrote:
> 
> Benjamin Ducke wrote:
> 
> > I have been pondering this for a while and would
> > like to know if people on this list think the
> > following would be a feasible/useful addition to
> > GRASS (7):
> > 
> > How about, in addition to the MASK raster, we'd
> > also allow the user to specify a COST raster?
> > This would allow all raster modules that currently
> > use an euclidean distance measure (KDE, IDW, ...)
> > to use a cost-based measure instead, without adding
> > more options to the individual modules.
> > 
> > In addition to the COST raster, we could modify the
> > basic distance function in the GRASS GIS lib to
> > automatically return a cost-based result if the
> > COST raster is present. This way, there would have
> > to be no or only minimal modifications to existing
> > modules.
> 
> This proposal makes no sense.
> 
> The mask raster is relatively cheap to implement, while a least-cost
> path is one of the most expensive calculations available in GRASS.
> Also, the mask raster affects every raster module which reads at least
> one input map, while very few modules calculate distances.
> 
> Being able to calculate least-cost distances between arbitrary points
> would require holding the entire cost raster in memory.
> 
> If you want least-cost distances from a fixed set of points to
> arbitrary points, it's significantly more efficient to generate
> distance rasters in advance (which requires knowing the starting
> points).
> 
> If you want multiple least-cost distances between arbitrary points,
> you would probably want to cache some intermediate results in order to
> allow an upper bound on the distance to be calculated cheaply. But you
> probably can't afford the memory to cache every intermediate result,
> and knowing which ones are worth caching is application-specific.
> 
> -- 
> Glynn Clements 
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Add a cost distance measure to GRASS GIS lib

[Benjamin Ducke]

Hi All,

I have been pondering this for a while and would
like to know if people on this list think the
following would be a feasible/useful addition to
GRASS (7):

How about, in addition to the MASK raster, we'd
also allow the user to specify a COST raster?
This would allow all raster modules that currently
use an euclidean distance measure (KDE, IDW, ...)
to use a cost-based measure instead, without adding
more options to the individual modules.

In addition to the COST raster, we could modify the
basic distance function in the GRASS GIS lib to
automatically return a cost-based result if the
COST raster is present. This way, there would have
to be no or only minimal modifications to existing
modules.

For anisotropic cost distances, we could allow a
DIRECTION raster.

Ben
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Speeding up v.out.ogr (again)

[Benjamin Ducke]

Dear Devs,

A while ago, I submitted a small patch for v.out.ogr
that moves the SQL SELECT out of the mk_att() function,
so that this costly operation does not have to be
performed multiple times:

http://lists.osgeo.org/pipermail/grass-dev/2011-January/053150.html

Looking at 6.4.2 and 6.5 SVN copies of v.out.ogr,
I see that SQL SELECT is still (again?) in mk_att(), with
this comment (line 1053):

  /* Fetch all attribute records for cat  */ 
  /* opening and closing the cursor is slow, 
   * but the cursor really needs to be opened for each cat separately */

Is this because of GRASS maps that have more than one
attribute table connection?

If so, then I suggest putting in a condition, so that those
GRASS maps that have just one attribute table can perform
the SQL SELECT outside of mk_att(). Otherwise, we punish
all GRASS users with extremely slow export speed, even though
most of them might not even use multi-table attributes in
their projects. The difference in my test was something like
factor 500!

Best,

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass toolboxes idea continued (g.extension)

[Benjamin Ducke]

I think we should separate the process from finding
common groups/labels from the GUI design. GRASS uses
pull-down menus, ArcGIS uses a foldable tree widget.
One user might prefer the first, another the second.

ArcGIS uses many levels of nesting in its toolbox,
and does not offer a way for the user to search for
a tool by keyword. SEXTANTE also uses a toolbox, but
with a flat, one-level nesting and a powerful search
widget, which makes a whole big difference.

But the point is that they all (and SAGA, QGIS,
etc.) face the same basic problem, i.e. how to sort
hundreds of tools into groups that make sense (i.e.
tools that are commonly used together are in the
same group) and how to tag/label them so it becomes 
obvious for the ("typical") user where to look for them.

This could be unified across open source GIS apps to
a large degree, boosting productivity for users that 
switch between apps and reducing learning times.

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm


On Wed, Jan 4, 2012, at 11:04, Michael Barton wrote:
> On Jan 4, 2012, at 8:45 AM, Martin Landa wrote:
> 
> >  Personally I didn't find toolbox interface
> > in ArcGIS intuitive. I guess it's not our goal.
> 
> 
> Hopefully not.
> 
> Michael
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass toolboxes idea continued (g.extension)

[Benjamin Ducke]

Since there are at least four major FOSS desktop GIS
projects (GRASS, SAGA, SEXTANTE + gvSIG, QGIS + GRASS plugin),
each of which faces the same problem of sorting geoprocessing
tools into groups, I wonder: Would it be worth the effort
to try to establish a common hierarchy/grouping standard for
for geoprocessing tools across GIS? Sort of like the LSB
(http://en.wikipedia.org/wiki/Linux_Standard_Base) for
Linux file system hierarchies?

I imagine this would make it much easier for users to work
with different FOSS GIS and always find the tools they need.

A common standard could also include labels and descriptions,
plus their translations into different languages, and of
course icons for GUIs.

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm


On Mon, Jan 2, 2012, at 17:15, Martin Landa wrote:
> Hi,
> 
> I have added (r50024) very initial support of "toolboxes idea" (see
> [1] for detailed information) to `g.extension` (see notes at wiki
> [2]). Any feedback, support, improvements welcomed.
> 
> Martin
> 
> [1] http://grass.osgeo.org/wiki/Toolboxes
> [2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes
> 
> -- 
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.out.ogr exports more features than available

[Benjamin Ducke]

Sounds like v.out.ogr includes some features in
the output that are marked "dead" but are still in the
dataset. Could you check two things, please:

1) Use another, external application (e.g. ogrinfo
or QGIS) to get an independent count of the number
of points in the output files,

2) and make a copy of the cleaned vector points map
using g.copy vect=, and use v.out.ogr to export
the copy instead of the cleaned original?

Ben


-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke AT fastmail.fm


On Tue, Dec 13, 2011, at 21:21, Maris Nartiss wrote:
> Working with today's trunk I spotted an oddity - I can export to
> shapefile not existing points.
> Work flow: v.in.ogr shapefile with 11183 points; run v.clean with
> rmdupl tool and reduce feature count to 10954; v.out.ogr exports to
> shapefile 11183 features. WTF?!?
> 
> The best one is the output of v.out.ogr:
> v.out.ogr -e input=clean_points2@geod_points type=point layer=1
> dsn=/home/maris/clean_points2.shp format=ESRI_Shapefile
> Exporting 10954 features...
> v.out.ogr izpildīts. 11183 features written to 
> (ESRI_Shapefile).
> 
> And here is metadata output for imported and for cleaned vector
> datasets (only Number of points differ):
> Dirty: Number of points:   11183
> Clean2: Number of points:   10954
> 
> Running v.build doesn't change anything.
> 
> Ideas?
> Maris.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Should v.in.ogr clean topology by default ? [was: Fwd: Re: [GRASS-user] overlapping areas seem valid to v.build: why?]

[Benjamin Ducke]

Personally,
I dislike the "non-topological data is also valid data" 
perspective. GIS and spatial analysis are inherently
topological. From my point of view, the only distinction 
that applies is whether that data contains topological 
errors in its structure, or not.

GRASS 6 has been designed as a GIS that honors topological
data structures, and by default enforces topological correctness
on the input data to ensure consistent analysis results.
This, among other design decisions, is one of the reasons why 
GRASS GIS is so wide-spread in the scientific community, 
and has acquired its reputation there.

If all you want is to map and query data, and therefore are OK 
with "garbage in, garbage out": go ahead and use "v.in.ogr -c", 
or maybe even a different GIS, such as QGIS.

But in terms of GRASS as a scientific software: Better improve 
the current topology tools to make them more flexible,
than to drop all topological constraints by default.

Cheers,

Ben

-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  bendu...@fastmail.fm


On Thursday, December 01, 2011 11:02 AM, "Moritz Lennert"
 wrote:
> I think Roger's question below merits reflection, so I forward it to the 
> developer's list.
> 
> Moritz
> 
>  Original Message 
> Subject:Re: [GRASS-user] overlapping areas seem valid to v.build:
> why?
> Date:   Wed, 30 Nov 2011 10:09:15 -0800
> From:   Roger André 
> To: Markus Metz 
> CC: Moritz Lennert ,
> grass-u...@lists.osgeo.org, "G. Allegri" 
> 
> 
> 
> By the way, it seems that the official stance is that it is preferred to
> allow the automatic cleaning of non-topological data sets when they are
> imported.  However, I do want to point out that I have seen many, many
> instances where this auto-cleaning actually causes problems, rather than
> fixes them.  As a result, I explicitly exclude cleaning on every import
> I do.  If cleaning is required, I manually clean the data with v.clean.
>In many cases only a subset of the full set of cleaning operations
> performed automatically by v.in.ogr are needed to fix the data.
>Personally, I do not think this "auto cleaning" should ever have been
> made the default operation of the import tool.
> --
> 
> 
> On Wed, Nov 30, 2011 at 9:37 AM, Markus Metz
>  <mailto:markus.metz.gisw...@googlemail.com>> wrote:
> 
>  Moritz Lennert wrote:
>   > On 30/11/11 14:38, Markus Metz wrote:
>   >>
>   >> It seems to me that the confusion arises because you made use of
>   >> features that allow you to skip topological cleaning which is
>  not the
>   >> default and not recommended.
>   >
>   >
>   > Maybe this calls for a v.check.topology module ? Or an option in
>  v.build or
>   > v.clean which does that (i.e. just check, not clean) ?
> 
>  Good idea. I would opt for a new option/flag for v.build, which can
>  already provide rather detailed diagnostics, e.g. dumping topology.
>  Something like v.build -e for extended topology checks?
> 
>  Markus M
>  ___
>  grass-user mailing list
>  grass-u...@lists.osgeo.org <mailto:grass-u...@lists.osgeo.org>
>  http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] 3D polygons and co-planarity

[Benjamin Ducke]

Does v.clean currently check and ensure that
all vertices of a polygon lie in the same plane?
Also if the vertices have Z coordinates?

Cheers,

Ben

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.walk issues for 6.4.2?

[Benjamin Ducke]

+1 for backporting the r.walk 6.5 patches
to 6.4.2. They make the module a lot more useful.

Ben

On 10/08/2011 05:29 PM, Michael Barton wrote:

One of my students was having problems with r.walk not properly
reflecting surface topography in 6.4.2 svn (from a few weeks ago).

So I checked it out today. My comparison is not quite the same as hers
as she is on Mac OS X 10.6.8 and I've tested this on 10.7.2 (Lion). But
we're using the same GRASS builds (done with 10.6.8 on my other computer).

I did not have the same problem she did. I tested with the Spearfish
demo set. She is using a DEM in a Lambert Conformal Conic projection
(which I suppose might be a problem for some reason).

However, I did turn up something of interest for the upcoming GRASS
6.4.2 release.

In 6.4.1, we did not include the new backlink map option, but I thought
it was going to be in 6.4.2. So far it has not been backported from 6.5.

Also, running r.walk without the backlink in GRASS 6.4.2 and GRASS 7
produces significantly different results. Here are the links to a couple
of outputs of a difference map between r.walk on 6.4.2 minus r.walk on
GRASS 7 using exactly the same command and files.

r.walk elevation="elevation.dem@PERMANENT" friction="flat1m@PERMANENT"
output="cost1" start_points="Elkhorn_Peak_site@G7_vector" max_cost=0
percent_memory=100 walk_coeff="0.72,6.0,1.9998,-1.9998" lambda=1.0
slope_factor=-0.2125

http://dl.dropbox.com/u/7437464/rwalk_diff.jpg
http://dl.dropbox.com/u/7437464/rwalk_diff_histogram.png

As you can see, there are very patterned differences in the behavior of
r.walk between the 2 GRASS versions. The differences are not huge (in
the range of +3 to -13 minutes), but are still notable. Beyond adding
the backlink option, do the r.walk algorithms differ significantly
between them?

Also, has anybody had any problems with r.walk in a Lambert projection?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu













___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev




--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

  bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS GIS] #1277: v.kernel - equal split on network

[Benjamin Ducke]

Really advanced stuff that gives GRASS an edge in
point pattern analysis. Thanks Radim!

Ben

- Original Message -
> #1277: v.kernel - equal split on network
> -+--
> Reporter: rblazek | Owner: grass-dev@…
> Type: enhancement | Status: new
> Priority: normal | Milestone: 6.4.1
> Component: Default | Version: 6.4.0
> Keywords: | Platform: Unspecified
> Cpu: Unspecified |
> -+--
> 
> Comment(by mmetz):
> 
> Replying to [comment:1 rblazek]:
> > Vector network library improvement was necessary, the patch includes
> cache bug fix. The patches are against 6.4.0.
> 
> Cool. Could you also provide patches against current 6.4.1? BTW, the
> cache is working in 6.4.1, but not in 6.4.0, and only patches against
> 6.4.1 can
> be included in the current release branch. I could help in forward
> porting the changes to 6.5 and 7.0.
> 
> Markus M
> 
> -- Ticket URL: 
> GRASS GIS 
> 
> 
> ___ grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r45050: v.info: -r/-m/-t -> shell param

[Benjamin Ducke]

I remember that we had a discussion a while ago on the
merits of making the GUI a separate project,
decoupled from the main GIS base.

Back then, the arguments where mostly centered on code
management and release cycles. I did not really want to
get into the discussion, as it felt a bit emotionalized.
But this sort of thing has me worried for some time.

I understand that in the starting phase of the new GUI
it was necessary to do some cleaning up of the CLI interfaces
so that the widgets would have a chance to 
interact properly with the modules. Fine; and it actually
did the old CLI interfaces a lot of good to undergo revision.

But for me, the point where we start modifying the CLI 
logics to improve the GUI appeal marks a dangerous threshold.
We should not get into a situation where we pit GUI
experience against CLI experience.

Thanks for listening. And please do not take this as
depreciative of the efforts of all those who are doing 
great work in putting together the new GUI.

Ben



- Original Message -
> Martin:
> > >> If so, why don't change some "standard" or "conventions" in
> > >> GRASS7? ;-)
> Hamish:
> > > because there's nothing really wrong with the old way?
> > > If there seem to many buttons in the GUI for a module,
> > > maybe the GUI module creation code should try for two columns
> > > or something? personally I am not too overwhelmed by the
> > > v.info and g.region 'Print' tabs, IMO they are fine and easy.
> >
> Martin:
> > well, the number of flags is the same as the number of
> > introduced options (shell parameter in v.info case), so
> > number of checkboxes in GUI dialogs is not changed.
> 
> so it has been made more logically complicated for exactly what
> gain then?
> 
> I find the "-x option does X, unless you have some modifier
> enabled, in which it does Y" a lot more confusing than "the -x
> flag does X, and the -y flag does Y". It is one less layer of
> abstraction to get your head around, which means easier to learn,
> debug, etc.
> 
> > They are just logically grouped.
> 
> they already should be, by the order they come in the code.
> just there is no visual breaks between groupings.
> 
> 
> but this gives me another idea on how we might find a solution..
> 
> so the problem you are trying to fix is not that the the user
> is presented with an overwhelming 747-cockpit's worth of options
> (such as d.vect can look like), but rather that within tabs it
> would help to group collections of similar options together?
> ?
> 
> if so perhaps we could implement a new thing in the module GUIs:
> thin 1 pixel wide light blue borders around groups of similar
> options/flags within a single tab.
> 
> this could either be with a new Option,Flag struct item like
> ->gui_group or ->gui_subsection, or perhaps it is cleaner and
> nicer to parse the existing opt->guisection like:
> _("section;subsection;subsubsection") if additional [;...] are
> present, the items get grouped.
> 
> if ->gui_group or ->gui_subsection was used any opts/flags
> within the same tab with the same group would be lumped together
> within a group box (optionally with small blue text in a gap in
> the top left border of the box with the group's name?).
> 
> I'm sure you can figure out what I mean as most gui widget kits
> support this & it is quite common, if not I can mock up a
> screenshot.
> 
> 
> > >> I remember discussion about number of flags of g.region.
> > >> There was suggestion to reduce number of flags as
> > >> I have done for v.info.
> > >
> > > it wasn't just discussion, it was committed and became a
> > > horrible mess for 2-3 months before it got partially
> > > reverted/cleaned up, and maybe now is still not as clean and
> > > clear as it once was.
> > > IIRC it was having a single -g flag which changed the behavior
> > > of all the other print flags. partly I'm trying to avoid that
> > > mess from happening again. a good idea perhaps, but it just
> > > didn't work in practice and made the entire GIS harder to use
> > > because it introduced a new paradigm.
> >
> > Probably time to make it better ;-)
> 
> as above, the modifier-flag way of doing it adds another layer of
> complication to learning the modules and in the code, which are
> both something I am not in favour of doing if we can help it.
> keep it simple.
> 
> 
> > Beside joking I would incline to keep -p/-g flag and
> > content control by the parameter.
> >
> > -p Print in human readable format
> > -g Print in shell script style
> >
> > Anyway there only few flags in g.region which could be
> > possible grouped into options of the new parameter (-e,-c,-3).
> >
> > print=basic,extent,center,3d
> >
> > What do you think about that?
> 
> as modifiers, or just to remove some flags?
> g.region is an extreme case and I'd have to eat something to get
> my blood sugar up before really being able to think about it
> clearly. :)
> 
> 
> > Speaking about v.info to add -g flag and content control by
> > print=basic,extent,topo [...]
> > S

Re: [GRASS-dev] v.surf.bspline man page - Man page improvement day

[Benjamin Ducke]

Excellent. Is it technically feasible to involve the whole
user community in this? Or would it be easier to restrict
to devs with SVN write access?

Ben

On 01/19/2011 12:42 PM, Markus Metz wrote:
> On Wed, Jan 19, 2011 at 9:14 AM, Anne Ghisla  wrote:
>> On Wed, 2011-01-19 at 08:51 +0100, Markus Neteler wrote:
>>> On Wed, Jan 19, 2011 at 12:37 AM, Dylan Beaudette
>>>  wrote:
>>>> On Tuesday, January 18, 2011, Benjamin Ducke wrote:
>>>>> That's reassuring, thanks Markus.
>>>>> Incidentally, since HTML housekeeping is such a boring
>>>>> chore but so crucial: Do you guys think it would make
>>>>> sense to have a "man page improvement day", similar to
>>>>> a code sprint, but with the whole community dedicating
>>>>> perhaps a day to finding problems in man pages and fixing
>>>>> them?
>>>>>
>>>>> I am not just talking about correcting errors, but also
>>>>> rephrasing things that are hard to understand or elaborating
>>>>> on aspects that aren't explained verbosely enough.
>>>>>
>>>>> Ben
>>>>
>>>> Excellent idea! I would participate.
>>>
>>> Me, too.
>>>
>>> Also the sphinx'ization (http://trac.osgeo.org/grass/ticket/151) comes to 
>>> mind.
>>
>> Me too!
>>
> Me too. It seems I started something here by forgetting to remove a
> paragraph. I always wanted to update the lidar tools man pages but
> never got around to do it...
>
> Markus M
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>



--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.surf.bspline man page

[Benjamin Ducke]

That's reassuring, thanks Markus.
Incidentally, since HTML housekeeping is such a boring
chore but so crucial: Do you guys think it would make
sense to have a "man page improvement day", similar to
a code sprint, but with the whole community dedicating
perhaps a day to finding problems in man pages and fixing
them?

I am not just talking about correcting errors, but also
rephrasing things that are hard to understand or elaborating
on aspects that aren't explained verbosely enough.

Ben

- Original Message -
> On Thu, Jan 13, 2011 at 10:03 PM, Benjamin Ducke
>  wrote:
> > The HTML manual page for v.surf.bspline
> > says:
> >
> > "A raster output map ("raster=") of more than 2000x2000 (4 mill)
> > cells is not allowed. If an output map would exceed this size,
> > an error message is generated."
> >
> > But there is nothing in the source code which suggests such
> > a limitation. I tried interpolating a 5000x4000 raster and it
> > worked just fine.
> >
> > Am I missing something or has this limitation fallen?
> >
> Right, this limitation has been removed, the maximum number of cells
> depends now on LFS and the amount of available system memory.
> 
> Additionally, one bug has been removed:
> 
> "At this time, sparse vector input can only be used with interpolation
> from 3D vector z-coordinates"
> 
> is no longer true, z values are collected either from 3D points or
> from the attribute table.
> 
> The manual has been updated correspondingly in all branches.
> 
> Markus M


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.external and 3D OGR datasources

[Benjamin Ducke]

Martin,

That certainly makes sense for most GRASS users and
devs. And I will develop new features in GRASS 7.

But I am in the special situation that I am developing a 
GRASS interface for gvSIG/SEXTANTE. And sometimes there are
features in GRASS 7 that would make my interface a lot
more efficient. Like v.external with 3D geometry support.
Or the v.out.ogr speed-ups I recently committed to 6.5.

I am willing to live with the risk of using less well-tested
features in exchange for more speed and elegance in my
interface.

So for me, backporting stuff in some situations makes sense.
Even if it will never go into GRASS 6.4, I can still use
it in my own little "tuned" GRASS distribution that I can bundle 
with the gvSIG binaries. Thus my question how hard it would be. 
If it would be really hard, then I won't bother and wait for 
GRASS 7.

Cheers,

Ben

- Original Message -
> Hi,
> 
> 2011/1/15 Benjamin Ducke :
> > v.external in GRASS 7 allows to link 3D OGR sources as a
> > new 3D GRASS map. In GRASS 6, only 2D links are made.
> > I tried changing the Vect_open_new() statement in
> > GRASS 6's v.external to make a 3D link, but no success.
> >
> > Is there any deeper reason, why 3D OGR links are not
> > possible in GRASS 6? I couldn't find a clue in the API,
> > and would be grateful for any info on how difficult
> > it might be to backport the 3D OGR access to GRASS 6.
> 
> personally I think it's too much work backport important changes in
> vector lib to GRASS 6. I suggest to develop new features in GRASS 7.
> 
> Martin
> 
> -- Martin Landa  *
> http://geo.fsv.cvut.cz/~landa


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.external and 3D OGR datasources

[Benjamin Ducke]

Dear list,

v.external in GRASS 7 allows to link 3D OGR sources as a
new 3D GRASS map. In GRASS 6, only 2D links are made.
I tried changing the Vect_open_new() statement in 
GRASS 6's v.external to make a 3D link, but no success.

Is there any deeper reason, why 3D OGR links are not
possible in GRASS 6? I couldn't find a clue in the API,
and would be grateful for any info on how difficult
it might be to backport the 3D OGR access to GRASS 6.

Cheers,

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-SVN] r45036 - grass/branches/develbranch_6/vector/v.out.ogr

[Benjamin Ducke]

OK, committed to and test in GRASS 7.
All seems to work smoothly as far as I can tell, but please test.
Note that I have also implemented the "-z" flag for easy
production of 3D Shapefiles. Also tested that and can see no
problems so far.

I would really like to see those changes in GRASS 6.4.2 at the
latest, though. They do make my life a lot easier.

Ben

- Original Message -
> 2011/1/14 :
> > Author: benducke
> > Date: 2011-01-14 13:04:44 -0800 (Fri, 14 Jan 2011)
> > New Revision: 45036
> >
> > Modified:
> >   grass/branches/develbranch_6/vector/v.out.ogr/main.c
> > Log: This commit contains some small bugfixes, code clean-ups and
> > two new feature for v.out.ogr.
> > 1. Fixed a but that would spawn ugly error messages in conjunction
> > with the "-s" flag
> > 2. Reduced the SQL SELECT statements to just one instead of one per
> > feature, increasing output speed by several magnitudes.
> > 3. Added a new "-z" flag, which provides a simple and robust means
> > of producing 3D ESRI Shapefiles
> > --> Please test intensively!
> 
> please, could you use trunk as development branch and optionally
> backport the changes to devbr6? Devbr6 is intended to be a test-bed
> for relbr64 backports! Go for GRASS 7!
> 
> Martin
> 
> -- Martin Landa  *
> http://geo.fsv.cvut.cz/~landa


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 CLI startup

[Benjamin Ducke]

After starting in wxGUI mode and making the basic
settings, it works fine, of course.
Just seems like .grass7/rc cannot be properly created
by "grass70 -txt".

Ben

- Original Message -
> I just installed grass7 and attempted to start it
> in CLI-only mode, never having started it before
> on my machine:
> 
> grass70 -text
> 
> The result (after the Welcome message) was:
> 
> Starting GRASS GIS...
> /home/benni///.gislock: No such file or directory
> ERROR: /usr/local/grass-7.0.svn/etc/lock:
> Unable to properly access "/home/benni///.gislock"
> Please notify system personel.
> 
> Before I file a ticket: did I overlook something?
> I'd hate to have to notify my system personel ;)
> 
> Ben
> 
> 
> -- Files attached to this email may be in ISO 26300 format (OASIS
> Open Document Format). If you have difficulty opening them, please
> visit http://iso26300.info for more information.
> 
> ___ grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 7 CLI startup

[Benjamin Ducke]

I just installed grass7 and attempted to start it
in CLI-only mode, never having started it before
on my machine:

  grass70 -text

The result (after the Welcome message) was:

Starting GRASS GIS...
/home/benni///.gislock: No such file or directory
ERROR: /usr/local/grass-7.0.svn/etc/lock:
Unable to properly access "/home/benni///.gislock"
Please notify system personel.

Before I file a ticket: did I overlook something?
I'd hate to have to notify my system personel ;)

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.out.ogr: major speed-up to go into 6.4.1?

[Benjamin Ducke]

Dear all,

I have just reviewed v.out.ogr and where it spends those
massive amounts of time it needs to export larger vector maps.
Turns out that it issues a new SQL SELECT statement for every
single attribute it wants to export.

So I rearranged the code to use only one SQL SELECT statement that
fetches all records at once (same as what v.db.select does).
Essentially, I moved the SQL SELECT out of mk_atts() and into the
calling function, where it is now executed only once.

After that fix, I was able to export a vector map with 220.000 points 
within 10 secs, instead of originally ca. 100 mins. Go figure out the
speed-up factor, it's ridulous! Granted, my data has a very simple
attribute table and for more complex table structures, the factor
may be smaller (v.out.ogr re-examines the field types for every
record, so there is still some room for optimization).

Question is: what to do with this? I would like to have it in
6.4.1 and believe that the change is actually very small, but
I understand that v.out.ogr is a very critical modules and so
every change in there needs to well-tested.

I have some resources for working on GRASS contributions next week,
but I need to plan them well. So if there is a realistic chance that 
this can go into 6.4.1, I will do some in-depth testing next week
to make sure all works well.

If not, I can check this into 6.5 and then we give it enough time
to mature for 6.4.2.

Also: I am getting really annoyed by having to supply those OGR
"lco=" (or was it "dsco="? See, that's what I mean...) 
options for creating 3D Shapefiles. How about, similar
to "-e" I add another flag "-z" which automatically creates 3D
output in case the input is a 3D GRASS map and the output are
Shapefiles? It wouldn't change anything about the default behaviour.

Cheers,

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Default removal type in g.remove

[Benjamin Ducke]

If I run g.remove with the onle the name of a non-existing 
map, I get this:

  g.remove tmp
  Removing raster 
  WARNING: Raster map  not found
  WARNING:  nothing removed

This indicates that g.remove tries to remove a raster of
name "tmp" by default. I am not sure this is good behaviour.
What if the user meant a vector map and forgot to explicitely
type "vect=tmp". In such a case, the wrong map might gets
deleted, instead of just an error message being issued.

Also, the synopsis for g.remove does not indicate that there
is a default removal type.

I am not sure if this is a bug or intended behaviour.

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Bad map deletion beahviour with external OGR sources

[Benjamin Ducke]

I Think I found a problem with OGR datasources linked
in using v.external.

If I change into a directory with shapefiles and then
issue the following to link in the data in "myShapefile.shp":

  v.external dsn=. layer=myShapefile output=linked_in

And then change into another directory and issue any command
that wants to work on "linked_in", e.g.:
  
  g.remove vect=linked_in
  v.info linked_in

I get:

  ERROR: Cannot open layer 'myShapefile'

But when I change back into the directoy where I used
to be when running the v.external command, it works.

So I think v.external should take care to always link
to the absolute location of the source in the file
system (if I specify "dsn=" as an absolute path,
things work fine).

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Two new strange behaviours in GRASS 6.4.1SVN

[Benjamin Ducke]

Dear list,

I noticed two strange new things in 6.4.1svn that may
both be related to the recent GUI changes.

1. I configured and compiled GRASS explicitely without
Tcl/Tk and without Python support. The configure script
correctly reported a "No" for both options.
Yet if I just run e.g. "r.out.gdal" (i.e. with no options
or flags), I get:

python: can't open file 
'/usr/local/grass-6.4.1svn/etc/wxpython/gui_modules/menuform.py': [Errno 2] No 
such file or directory

Whereas I would expect the synopsis to be displayed in
a CLI-only environment. And I really didn't want GRASS
to interact with my system's Python at all.

2. The --help flag is only interpreted correctly depending
on its position on the CLI. This:

  r.out.gdal --help input=aspect output=aspect.tiff

correctly displays the module synopsis, but this:

  r.out.gdal input=aspect output=aspect.tiff --help

gives:

  Sorry, <-> is not a valid flag
  Sorry,  is not a valid flag
  Sorry,  is not a valid flag
  Sorry,  is not a valid flag

which is unfortunated, because I often type a CLI up
to the point I can remember it and then add --help to
get a reminder of the rest.

Cheers,

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 6.4.1 Release notes

[Benjamin Ducke]

May I suggest that we also mention v.out.ogr's
new options to drop that annoying "cat" field
from the output file, and to determine output
geometries automatically?

Ben


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev