[GRASS-dev] d.mon segfaulting on debian/ubuntu custom/docker

[Jachym Cepicky]

Hi,

running

d.mon start=cairo
d.mon stop=cairo

will lead to Segmentation fault.

same for

d.mon start=wx0
or

d.mon start=png

I'm using GRASS 7.8.2, official packages from Ubuntu 20.04, nothing fancy.

When tried docker image

docker run --rm -ti -v $(pwd):/data/ -v $(pwd)/grassdata:/grassdata
mundialis/grass-py3-pdal:stable-ubuntu

it was segfaulting too! so was debian

when trying -alpine , no problem (or did not seem to be)

Any hint, what could be the reason?

Jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r72590 - grass/trunk/general/g.region

[Jachym Cepicky]

Hi,

sorry for too rush approach, you can certainly revert the commit

Jachym

čt 5. 4. 2018 v 13:01 odesílatel Martin Landa 
napsal:

> Hi,
>
> 2018-04-05 12:16 GMT+02:00  :
> > Author: jachym
> > Date: 2018-04-05 03:16:14 -0700 (Thu, 05 Apr 2018)
> > New Revision: 72590
> >
> > Modified:
> >grass/trunk/general/g.region/local_proto.h
> >grass/trunk/general/g.region/main.c
> > Log:
> > Adding -L flag to g.region for getting list of regions
>
> 1) upper-case flags should not be used
> 2) this functionality is already available as `g.list type=region` if
> I understand well
> 3) I would prefer to see ticket with related discussion before
> committing change into trunk
>
> Consider reverting this change. g.list functionality is not suitable
> for your need?
>
> Thanks for clarification, Martin
>
> >
> > Modified: grass/trunk/general/g.region/local_proto.h
> > ===
> > --- grass/trunk/general/g.region/local_proto.h  2018-04-03 10:43:37 UTC
> (rev 72589)
> > +++ grass/trunk/general/g.region/local_proto.h  2018-04-05 10:16:14 UTC
> (rev 72590)
> > @@ -12,6 +12,7 @@
> >  #define PRINT_NANGLE 0x100
> >  #define PRINT_GMT0x200
> >  #define PRINT_WMS0x400
> > +#define PRINT_WF 0x800
> >
> >  /* zoom.c */
> >  int zoom(struct Cell_head *, const char *, const char *);
> >
> > Modified: grass/trunk/general/g.region/main.c
> > ===
> > --- grass/trunk/general/g.region/main.c 2018-04-03 10:43:37 UTC (rev
> 72589)
> > +++ grass/trunk/general/g.region/main.c 2018-04-05 10:16:14 UTC (rev
> 72590)
> > @@ -13,6 +13,7 @@
> >   * Read the file COPYING that comes with GRASS for details.
> >
>  /
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -39,8 +40,11 @@
> >  const char *value;
> >  const char *name;
> >  const char *mapset;
> > +char *windows_path = G_malloc(1024);
> >  char **rast_ptr, **vect_ptr;
> >  int pix;
> > +DIR *d;
> > +struct dirent *dir;
> >
> >  struct GModule *module;
> >  struct
> > @@ -48,7 +52,7 @@
> > struct Flag
> > *update, *print, *gprint, *flprint, *lprint, *eprint,
> *nangle,
> > *center, *res_set, *dist_res, *dflt, *z, *savedefault,
> > -   *bbox, *gmt_style, *wms_style;
> > +   *bbox, *gmt_style, *wms_style, *list;
> >  } flag;
> >  struct
> >  {
> > @@ -165,6 +169,11 @@
> >  flag.update->description = _("Do not update the current region");
> >  flag.update->guisection = _("Effects");
> >
> > +flag.list = G_define_flag();
> > +flag.list->key = 'L';
> > +flag.list->description = _("List available regions");
> > +flag.list->guisection = _("Print");
> > +
> >  /* parameters */
> >
> >  parm.region = G_define_standard_option(G_OPT_M_REGION);
> > @@ -362,7 +371,7 @@
> >  G_option_required(flag.dflt, flag.savedefault, flag.print,
> flag.lprint,
> >flag.eprint, flag.center, flag.gmt_style,
> flag.wms_style,
> >flag.dist_res, flag.nangle, flag. z, flag.bbox,
> flag.gprint,
> > -  flag.res_set, flag.update, parm.region,
> parm.raster,
> > +  flag.res_set, flag.update, flag.list,
> parm.region, parm.raster,
> >parm.raster3d, parm.vect, parm.north, parm.south,
> parm.east,
> >parm.west, parm.top, parm.bottom, parm.rows,
> parm.cols,
> >parm.res, parm.res3, parm.nsres, parm.ewres,
> parm.tbres,
> > @@ -850,6 +859,21 @@
> >  if (print_flag)
> > print_window(, print_flag, flat_flag);
> >
> > +if (flag.list->answer) {
> > +  mapset = G_mapset_path();
> > +  sprintf(windows_path, "%s/%s", mapset, "windows");
> > +  d = opendir(windows_path);
> > +
> > +  if (d) {
> > +while ((dir = readdir(d)) != NULL) {
> > +  if (dir->d_type == DT_REG) {
> > +printf("%s\n", dir->d_name);
> > +  }
> > +}
> > +closedir(d);
> > +  }
> > +}
> > +
> >  exit(EXIT_SUCCESS);
> >  }
> >
> >
> > ___
> > grass-commit mailing list
> > grass-com...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-commit
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Open Source GIS software developer in Bonn/Germany

[Jachym Cepicky]

ich schreibe dir antwort seit einer woche g


čt 23. 11. 2017 v 12:40 odesílatel Markus Neteler 
napsal:

> FYI :-)
>
>
> -- Forwarded message --
> From: Markus Neteler 
> Date: Tue, Nov 21, 2017 at 6:04 PM
> Subject: Open Source GIS software developer in Bonn/Germany
> To: OSGeo-Jobs 
>
>
> Dear OSGeo community,
>
> mundialis is looking for a software developer with focus on geodata
> processing and developmemt of free and open source software (GRASS
> GIS, QGIS, GDAL, related tools).
>
> For more information on required skills, see
> https://www.mundialis.de/de/softwareentwicklerin/
>
> About mundialis:
> mundialis (https://www.mundialis.de) specializes in the evaluation of
> remote sensing data and the processing of voluminous geodata with the
> help of powerful computing centers. Based on satellite data mundialis
> offers scalable products for agriculture and forestry, space agencies,
> research institutes, international organizations, as well as the
> private sector in the fields of telecommunications, logistics and
> health.
>
>
> Best regards,
> Markus
>
> --
> =
>
> mundialis GmbH & Co. KG
> Kölnstraße 99, 53111 Bonn, Germany
> 
> Registergericht: Amtsgericht Bonn, HRA 8528
>
> vertreten durch: mundialis Verwaltungsgesellschaft mbH
> Geschäftsführer:
> Dr. rer.nat. Markus Neteler
> Dipl.-Geogr. Hinrich Paulsen
> Dipl.-Geogr. Till Adams
>
> Tel. +49 (0)228 - 387 580 80 <+49%20228%2038758080>
> Fax. +49 (0)228 - 962 899 57 <+49%20228%2096289957>
> info [at] mundialis [dot] de
>
> Internet: www.mundialis.de
> EO-me = Sentinel-2 metadata - visit eome.mundialis.de
> ___
> 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

Re: [GRASS-dev] prefer GeoPackage over Shapefile

[Jachym Cepicky]

Hi,

https://trac.osgeo.org/grass/ticket/3428

J

st 18. 10. 2017 v 16:30 odesílatel Markus Neteler 
napsal:

> On Oct 18, 2017 4:25 PM, "Martin Landa"  wrote:
> >
> > Hi,
> >
> > please create a valid ticket on Trac for this issue. Thanks. Ma
>
> Yes please.
> And only for trunk (future 7.4) since we cannot touch default settings in
> released versions.
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] prefer GeoPackage over Shapefile

[Jachym Cepicky]

Thanks again :-|

This is not a good day for pushing for such complex changes for me. It
would be safer, not to get out of the bed today.

switchfromshapefile.org is the page

J

st 18. 10. 2017 v 15:27 odesílatel Vincent Bain <b...@toraval.fr> napsal:

> Hi Jachym : devil is in the details, ah, ah !
>
> Le mercredi 18 octobre 2017 à 12:28 +, Jachym Cepicky a
> écrit :
>
> > Reasoning: all is written at http://switchtoshapefile.org
>
>
> You probably meant switchfromshapefile.org ?
>
>
> Thanks for all; here in France students massively still use shapefiles,
> and worse! dumb tiff+tfw rasters. As though they had lived 30 years
> sooner and would refuse improvements...
>
>
> Vincent
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] prefer GeoPackage over Shapefile

[Jachym Cepicky]

Hi Evan,
oh, thanks for the typo, fixed in my code ;-)

There is driver check in the code

https://svn.osgeo.org/grass/grass/trunk/vector/v.out.ogr/main.c

line 457

for (i = 0; i < OGRGetDriverCount(); i++) {
...

I could probably commit, but before I do, I would like to get confirmed by
PSC, this is OK to GRASS community.

Jachym

P.S. I've prepared similar patch for QGIS for those, who are interested
https://github.com/qgis/QGIS/pull/5385


st 18. 10. 2017 v 14:36 odesílatel Even Rouault <even.roua...@spatialys.com>
napsal:

> On mercredi 18 octobre 2017 12:28:36 CEST Jachym Cepicky wrote:
> > Hi,
> >
> > I would like to submit following commit to GRASS GIS - master
> >
> > Index: vector/v.out.ogr/args.c
> > ===
> > --- vector/v.out.ogr/args.c (revision 71566)
> > +++ vector/v.out.ogr/args.c (working copy)
> > @@ -32,7 +32,7 @@
> >  options->format->type = TYPE_STRING;
> >  options->format->required = YES;
> >  options->format->multiple = NO;
> > -options->format->answer = "ESRI_Shapefile";
> > +options->format->answer = "DPKG";
> >  options->format->options = OGR_list_write_drivers();
> >  options->format->description = _("Data format to write");
> >
> >
> >
> > any objections?
> >
>
> I'm not a GRASS dev, but do I have a major objection... There's a typo in
> your
> patch ;-) Should be GPKG
>
> Joke aside, the SQLite dependency in GDAL builds is optional, so in theory
> you
> could have a GDAL build without SQLite/GPKG support. But this is really
> unlikely in practice as no sane packager would do that.  Perhaps checking
> if
> the GPKG driver is there would be safer, and if not fallback to good old
> shapefile.
>
> Even
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] prefer GeoPackage over Shapefile

[Jachym Cepicky]

Hi,

I would like to submit following commit to GRASS GIS - master

Index: vector/v.out.ogr/args.c
===
--- vector/v.out.ogr/args.c (revision 71566)
+++ vector/v.out.ogr/args.c (working copy)
@@ -32,7 +32,7 @@
 options->format->type = TYPE_STRING;
 options->format->required = YES;
 options->format->multiple = NO;
-options->format->answer = "ESRI_Shapefile";
+options->format->answer = "DPKG";
 options->format->options = OGR_list_write_drivers();
 options->format->description = _("Data format to write");



any objections?

Reasoning: all is written at http://switchtoshapefile.org

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

Re: [GRASS-dev] g.search.module: shell style output

[Jachym Cepicky]

Vasku,

IIRC, "-g" flag was introduced first time in 2007 for g.region module and
only reason for taking "g" letter was, that "s" for "shell script" was
taken (or some similar reason). AFAIK there was never defined official
GRASS rule for using -g flag for parsable output as well as how the output
should look like - people simple started to adopt it (like usually in
GRASS).

Putting rule to developer guidelines for parsable output as well as
promoting the "-g" flag for all modules would certainly be an option

Jachym

po 22. 8. 2016 v 4:39 odesílatel Vaclav Petras <wenzesl...@gmail.com>
napsal:

> On Fri, Aug 19, 2016 at 2:15 AM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>> Hi,
>>
>> no special reason for not listing the module description too, just did
>> not came to my mind
>>
>
> Thanks. Good to know.
>
>
>>
>> Just do it [1]
>>
>
> While using the modified version, I actually realized that "shell script
> style" usually produces key-value pairs which can which can be evaluated by
> shell's eval or grass.script.parse_command. Not all modules comply with
> this, e.g. `g.extension -g` produces multiple key-values with same keys and
> order matters, so this must be parsed in a special way. The result is
> actually exactly the information g.search.modules is producing:
>
> $ g.extension -g
> ...
> name=v.habitat.dem
> description=Calculates DEM derived characteristics of habitats.
> keywords=vector,raster,terrain,statistics,sun,zonal statistics
> name=v.in.gbif
> description=importing of GBIF species distribution data
> keywords=vector,geometry
>
> `g.extension -l` produces list of modules in the same way as currently
> `g.search.modules -g` produces:
>
> $ g.extension -l
>
> v.habitat.dem
> v.in.gbif
>
> As a result, I don't know what to do with -g, at this point I would just
> replace the letter by -n (names only) or -s (short output with names only)
> and add -t for table output (that's in the attached patch). -g can go to
> renamed options for compatibility reasons for now.
>
> For the future, we should try to keep in mind that g.extension and
> g.search.module should have unified interfaces and/or outputs. And more
> generally, we should define what -g "shell script style" means.
>
>
>>
>> J
>>
>> [1] https://www.youtube.com/watch?v=ZXsQAXx_ao0
>>
>> čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras <wenzesl...@gmail.com>
>> napsal:
>>
>>> Hi Jachym,
>>>
>>> the g.search.module -g flag (shell style output) outputs just names. Do
>>> you have a particular reason for it? My use case is something like that:
>>>
>>> g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e
>>> "s/|/\t/g"
>>>
>>> with the following desired output (name + keywords, description removed
>>> by sed):
>>>
>>> g.versiongeneral,support,citing,copyright,version,license
>>> t.supporttemporal,metadata,time
>>> r.supportraster,metadata
>>> r.support.statsraster,statistics
>>> r.out.gdalraster,export
>>> v.out.ogrvector,export,OGR
>>> r3.supportraster3d,metadata,voxel
>>> g.findetcgeneral,map management,scripts
>>> v.externalvector,import,external,OGR,PostGIS
>>> g.messagegeneral,support,scripts
>>> g.tempfilegeneral,support,scripts
>>> v.supportvector,metadata
>>> r.externalraster,import,external
>>>
>>> I can actually see that outputting just module names can be advantageous
>>> in some cases. But I want to get something like, so I can throw sed and
>>> grep on it:
>>>
>>> v.support|vector,metadata|Updates vector map metadata.
>>>
>>> If we permit change of the interface, I think -g could do the output
>>> above. This would make the -g output more like the others: same information
>>> as by default and with -j, so we can even consider it fixing a bug.
>>>
>>> The current output with -g can be generated with some other flag. -n*
>>> for "names only" perhaps?
>>>
>>> Best,
>>> Vaclav
>>>
>>> * https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.search.module: shell style output

[Jachym Cepicky]

Hi,

no special reason for not listing the module description too, just did not
came to my mind

Just do it [1]

J

[1] https://www.youtube.com/watch?v=ZXsQAXx_ao0

čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras 
napsal:

> Hi Jachym,
>
> the g.search.module -g flag (shell style output) outputs just names. Do
> you have a particular reason for it? My use case is something like that:
>
> g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e
> "s/|/\t/g"
>
> with the following desired output (name + keywords, description removed by
> sed):
>
> g.versiongeneral,support,citing,copyright,version,license
> t.supporttemporal,metadata,time
> r.supportraster,metadata
> r.support.statsraster,statistics
> r.out.gdalraster,export
> v.out.ogrvector,export,OGR
> r3.supportraster3d,metadata,voxel
> g.findetcgeneral,map management,scripts
> v.externalvector,import,external,OGR,PostGIS
> g.messagegeneral,support,scripts
> g.tempfilegeneral,support,scripts
> v.supportvector,metadata
> r.externalraster,import,external
>
> I can actually see that outputting just module names can be advantageous
> in some cases. But I want to get something like, so I can throw sed and
> grep on it:
>
> v.support|vector,metadata|Updates vector map metadata.
>
> If we permit change of the interface, I think -g could do the output
> above. This would make the -g output more like the others: same information
> as by default and with -j, so we can even consider it fixing a bug.
>
> The current output with -g can be generated with some other flag. -n* for
> "names only" perhaps?
>
> Best,
> Vaclav
>
> * https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Towards SVN - git integration

[Jachym Cepicky]

Hi,

(after a while)

I agree with Rainer - and I understand the conservative point of view - and
still remember last change from cvs to svn. Meanwhile, couple of you might
have custom scripts which do enable similar magic in svn, which are natural
to git (without any need for hacking). Git really makes it *very* easy to
merge code and solve conflicts, not to mention possibility of forking and
pulling from various repos (more organised way of accepting someone's
code). I think, it's possible to have the main repo in Git and access it
with svn client, if I'm not mistaken. But moving to git as main repo would
be wise option IMHO.

Github certainly is great service. Custom GitLab instance on (OSGeo?)
server should certainly be considered. But what is the difference between
GitHub and Intevation (for those, who remember)? Just the scale business
model IMHO, but the principal is the same - private companies hosting
infrastructure for open source projects.

Just my 2 cents

J

čt 9. 6. 2016 v 11:37 odesílatel Rainer M Krug  napsal:

> Markus Neteler  writes:
>
> > Hi devs,
> >
> > at time I am aware of two GRASS GIS related git instances:
> >
> > * https://github.com/GRASS-GIS  (used for Travis CI, in sync)
> > * https://git.osgeo.org/gogs/grass/grassgis (slighly outdated)
> >
> > It would be nice to go towards a bidirectional SVN <--> git(hub)
> > integration in order to collect easily contributions.
> >
> > Any suggestions how to proceed?
>
> I know there are many who prefer svn to git, but the question is if the
> main repo should migrate from svn to git.
>
> If the decision is to have a git(hub) repo, I would suggest completely
> moving to git.
>
> I don't think one can reliably and automatically keep two repos in sync.
>
> As it looks now, grass-ci seems to be updated automatically.
>
>
> Cheers,
>
> Rainer
>
>
> >
> > Markus
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982
> ___
> 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 and vagrant

[Jachym Cepicky]

Rainer,

afaik it does not make sense to combine vagrant and docker - there are here
for different use cases

http://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment

@martin good work btw

J

út 16. 2. 2016 v 12:39 odesílatel Rainer M Krug  napsal:

> Martin Landa  writes:
>
> > Hi,
> >
> > recently I have added Vagrantfile [1] to trunk which enables you
> > easily create a new virtual machine using vagrant, and compile/install
> > GRASS on that machine. Detailed description is available on wiki [2].
> > Enjoy! Martin
>
> Thanks - this sounds very interesting. If my googling gave the right
> answers, one can use Vagrant together with docker, which would make the
> resulting instance much more lightweight than a full blown VM (e.g
> Virtual Box).
>
> Has anyone tried this?
>
> Rainer
>
> >
> > [1] https://trac.osgeo.org/grass/browser/grass/trunk/Vagrantfile
> > [2] https://grasswiki.osgeo.org/wiki/Vagrant
>
> --
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982
> ___
> 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] Travis CI

[Jachym Cepicky]

wow

On Tue, Jul 21, 2015, 11:53 Ivan Minčík  wrote:

> Hi all,
> we have just integrated Travis Continuous Integration system [1] to the
> GRASS source code. Every commit is now build in Travis [2] using gcc and
> clang. In case the build fails, error message should go to GRASS-dev list.
>
>
> 1 - https://trac.osgeo.org/grass/browser/grass/trunk/.travis.yml
> 2 - https://travis-ci.org/GRASS-GIS/grass-ci
>
> --
> Ivan Minčík
> ivan.min...@gmail.com  GPG: 0x79529A1E
> http://imincik.github.io/0x79529A1E.key
> ivan.min...@gista.sk GPG: 0xD714B02C
> http://imincik.github.io/0xD714B02C.key
>
> ___
> 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] proposal for g.search module

[Jachym Cepicky]

renamed g.search.module -> g.search.modules



po 30. 11. 2015 v 22:33 odesílatel Vaclav Petras 
napsal:

>
> On Mon, Nov 30, 2015 at 4:22 PM, Markus Neteler  wrote:
>
>> > Considering the fact that an important/main use case is interactive
>> usage in
>> > the command line, I now lean towards:
>> >
>> > g.search.module aspect
>>
>> I would suggest to not use the singular "module" but plural "modules"
>> which would better explain itself.
>> We are searching in multiple modules, aren't we?
>>
>> So my suggestion:
>> g.search.modules
>
>
> Right! We are also getting multiple modules as a result. The GUI tab is
> called Search modules, I've mentioned here myself but then forgot about it.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66990 - in grass/trunk/scripts: . g.search.module g.search.module/testsuite

[Jachym Cepicky]

renamed

po 30. 11. 2015 v 22:18 odesílatel Markus Neteler 
napsal:

> On Mon, Nov 30, 2015 at 10:15 PM, Martin Landa 
> wrote:
> > Hi Markus,
> >
> > 2015-11-30 22:12 GMT+01:00 Markus Neteler :
> >
> >> while I like all this very much, I would prefer to remove this
> >> ".module" from the name and the directory name.
> >> We do not use .module anywhere since it is redundant.
> >> Or is there a particular reason for this?
> >
> > see relevant discussion at
> > https://lists.osgeo.org/pipermail/grass-dev/2015-November/077524.html
>
> ah I see! I guess my confusion arises from the fact that the singular
> "module" is used and not "modules" which would better explain itself.
>
> I'll write in the other thread.
>
> Markus
> ___
> 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] proposal for g.search module

[Jachym Cepicky]

OK guys,

the script called g.search.module is now in trunk, I've added tests (Vašek:
they seem to be far too verbose to me, anything I could do about that?)

I've left the colorize and print_output functions in the file, reason:
better code structure would have to be implemented (read: IMHO decorator at
least for colorize should be used and I'm to doubt for now to get working)

still hope, it's ok for you as it is now, if not, just let me know

cheers and thanks for help

Jachym

po 30. 11. 2015 v 16:19 odesílatel Vaclav Petras <wenzesl...@gmail.com>
napsal:

> On Mon, Nov 30, 2015 at 3:27 AM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>> about the tests - generally yes, I'm writing it. Are you referring to
>> r3.info or to g.search.* modules?  I could not found any example to
>> r3.info tests
>>
>
> I meant r3.info as it is more critical but g.search.* is similar just not
> critical.
>
>
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules
>
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite/test_r_mapcalc.py#L80
>
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/testsuite/test_assertions.py
>
>
>>
>> I've rewritten r3.info so that the code is the same, as r.info (with -e
>> flag) - but I can not tell, I'm satisfied with the result
>>
>
> I also cannot tell.
>
> https://trac.osgeo.org/grass/changeset/66983
> https://trac.osgeo.org/grass/changeset/66984
>
>
>> (there are line breaks and quotes in the strings, what IMHO is really not
>> good)
>>
>
> The comments, history or whatever it is is written as shell command for r
> and r3, so the strings are in quotes (to be general) and long lines are
> broken and continuation is done by backslash. With r3.info I now get:
>
> comments="r3.flow input="test1" flowaccumulation="test2" unit="cell"
> step=0.25\ limit=2000 max_error=1e-5 direction="down""
>
> I'm not sure how exactly this compares to r.info. Vectors have this in
> some better way but it's part of the format and I'm not familiar with it.
>
>
>> My time resources allocatable to this task are slowly reaching to their
>> end. I would need clear decision from you guys (since you are in charge to
>> mess around GRASS code base):
>>
>> Where to put print_output & supporting functions?
>>
>
> print_output can go to lib/python/script/utils.py (grass.script.utils).
> The others probably too, although I would mark them as experimental (not
> guaranteed API).
>
>
>> Where to write tests for them?
>>
>
> In a file in the testsuite directory at the level of the tested file, i.e.
> lib/python/script/testsuite for lib/python/script/utils.py.
>
> (I assume standard unittest package is being used)
>>
>
> unittest and grass.gnunittest, please see
>
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
>
>
>> Can I omit g.search.data for now? (I would like to put some better code
>> structure, as I can see it more clear now) - so I would put only
>> g.search.module for now to GRASS trunk?
>>
>
> Sure.
>
> Thanks! I'm looking forward to it.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Well,

about the tests - generally yes, I'm writing it. Are you referring to
r3.info or to g.search.* modules?  I could not found any example to r3.info
tests

I've rewritten r3.info so that the code is the same, as r.info (with -e
flag) - but I can not tell, I'm satisfied with the result (there are line
breaks and quotes in the strings, what IMHO is really not good)

My time resources allocatable to this task are slowly reaching to their
end. I would need clear decision from you guys (since you are in charge to
mess around GRASS code base):

Where to put print_output & supporting functions?
Where to write tests for them? (I assume standard unittest package is being
used)
Can I omit g.search.data for now? (I would like to put some better code
structure, as I can see it more clear now) - so I would put only
g.search.module for now to GRASS trunk?

Thanks

Jachym

po 30. 11. 2015 v 5:10 odesílatel Vaclav Petras <wenzesl...@gmail.com>
napsal:

>
> On Sun, Nov 29, 2015 at 7:06 AM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>> the code is in the same repository but packed in the g.search.module
>> directory now, not sure, if the g.extension will work again
>
>
> g.extension supports only directories which have Makefile, i.e. Makefile
> must be in the root directory of the repository. See r.modis (it might be
> more complicated then you need):
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.modis
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.green
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>> I've patched r3.info a bit (not sure, whether it's ok)
>> https://trac.osgeo.org/grass/changeset/66983/ for potential better
>> g.search.data output
>>
>
> Not really looked to the source code but with the commands:
>
> r3.mapcalc "test1 = rand(0, 1)" -s
> r3.flow in=test1 flowaccumulation=test2
> r3.info test2 -gh
>
> I get:
>
> ...
> description="generated by r3.flow"
> comments_0=comments_1=""
>
> (comments at the same row)
>
> BTW, have you considered writing a test? :)
>
> On Sun, Nov 29, 2015 at 4:06 PM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>>
>> i would like to move colorize, print_results from g.search.module to some
>> reachable place within existing grass python code base - any hint?
>>
>
> There are three options, not sure now what is better:
>
> grass.script.utils (scripting related, grass specific)
> grass.utils (more general functions, to be created)
> grass.tools (compilation, html related, to be created)
>
> We will need grass.tools at some point anyway to organize the code which
> now spreads over several files in tools and man directories.
>
> Not that you can also keep some functions in a "package directory" inside
> the addon like in r.modis but at least print_results looks like it should
> go to trunk.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Guys,

I've patched r3.info a bit (not sure, whether it's ok)
https://trac.osgeo.org/grass/changeset/66983/ for potential better
g.search.data output

i would like to move colorize, print_results from g.search.module to some
reachable place within existing grass python code base - any hint?

Jachym

ne 29. 11. 2015 v 13:06 odesílatel Jachym Cepicky <jachym.cepi...@gmail.com>
napsal:

> Guys,
>
> I would like to declare g.search.module "done" - I've introduced some more
> functions (reusable for other g.search.* modules), colorized terminal
> output (-c), shell script (-g) and json (-j) output, added sniffing in
> manual pages too (-m), better terminal output (line width <= 79 characters)
>
> please let me know, how you feel about it
>
> the code is in the same repository but packed in the g.search.module
> directory now, not sure, if the g.extension will work again
>
> thanks for feedback
>
> jachym
>
> ne 29. 11. 2015 v 1:19 odesílatel Luca Delucchi <lucadel...@gmail.com>
> napsal:
>
>> On 29 November 2015 at 00:04, Markus Neteler <nete...@osgeo.org> wrote:
>> > Hi Jachym,
>> >
>>
>> Hi Jachym,
>>
>> >
>> > So cool!!! Thank you,
>> >
>>
>> +1, really cool
>>
>> > Markus
>> >
>>
>> --
>> ciao
>> Luca
>>
>> http://gis.cri.fmach.it/delucchi/
>> www.lucadelu.org
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Guys,

I would like to declare g.search.module "done" - I've introduced some more
functions (reusable for other g.search.* modules), colorized terminal
output (-c), shell script (-g) and json (-j) output, added sniffing in
manual pages too (-m), better terminal output (line width <= 79 characters)

please let me know, how you feel about it

the code is in the same repository but packed in the g.search.module
directory now, not sure, if the g.extension will work again

thanks for feedback

jachym

ne 29. 11. 2015 v 1:19 odesílatel Luca Delucchi 
napsal:

> On 29 November 2015 at 00:04, Markus Neteler  wrote:
> > Hi Jachym,
> >
>
> Hi Jachym,
>
> >
> > So cool!!! Thank you,
> >
>
> +1, really cool
>
> > Markus
> >
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Vašku, if we agree on adding more search engines to g.search, I suggest to
define the features and interface (--help output) now and I can start think
about more generic concept of the code

modules
maps, groups
mapsets
locations?
regions
...

OR and AND flag

terminal output, shell script output, json output

this starts to be pretty heavy module :-)


On Sat, Nov 28, 2015, 02:25 Vaclav Petras <wenzesl...@gmail.com> wrote:

> On Fri, Nov 27, 2015 at 6:06 PM, Jachym Cepicky <jachym.cepi...@gmail.com>
> wrote:
>
>> ahoj Vašku,
>>
>> not sure about the maps. wouldn't be better to extend g.list?
>>
> Perhaps, the search could include title names as well - this would be the
> extension to g.list. This makes sense as you usually know if you are
> searching maps/groups/... or modules.
>
> On the other hand, g.search could provide unified simple search interface
> for searching/listing maps and modules - a simple "fulltext" search for
> word. This would wrap more general g.list pattern search interface. There
> is few other things we could search: Mapsets, Locations, and color tables.
> But let's ignore this for now.
>
>> about the name: g.module.search?
>>
> g.search aspect
> g.module.search aspect
> g.search.module aspect
>
> g.module.search sounds good. In GUI the tree and search tab is called
> Search modules, renamed from ambiguous Module search. Your original
> g.search is shorter and since it will be used in the command line, we
> should probably keep it short. So, at the end, I would keep g.search unless
> somebody is against that.
>
>> need to work on the output a bit more...
>>
> Also, keep in mind that the XML may change at one point. See explanations
> in:
>
> [GRASS-dev] wxgui_items.xml: outdated
> https://lists.osgeo.org/pipermail/grass-dev/2015-October/077137.html
>
>> would -g flag be useful as well?
>>
> Certainly, although not for me now.
>
>> glad you like it
>>
> I suggest to put it to trunk as soon as you are comfortable with the code
> and basic features.
>
>> jachym
>>
>> On Fri, Nov 27, 2015, 17:13 Vaclav Petras <wenzesl...@gmail.com> wrote:
>>
>>> On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <
>>> jachym.cepi...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've tried to implement command line alternative to module search based
>>>> on keywords, which is available in the gui - it's called g.search
>>>>
>>>> Any chance, you might find this useful ? Any comment to the source code
>>>> and outputs?
>>>>
>>>> https://github.com/jachym/g.search
>>>>
>>>
>>> I think it is awesome:
>>>
>>> $ g.extension extension=g.search url=https://github.com/jachym/g.search
>>> $ g.search MLC
>>>
>>> i.gensig
>>> Description: Generates statistics for i.maxlik from raster map.
>>> Keywords: imagery,classification,supervised classification,Maximum
>>> Likelihood Classification,MLC,signatures
>>>
>>> i.maxlik
>>> Description: Classifies the cell spectral reflectances in imagery
>>> data. Classification is based on the spectral signature information
>>> generated by either i.cluster, g.gui.iclass, or i.gensig.
>>> Keywords: imagery,classification,Maximum Likelihood
>>> Classification,MLC
>>>
>>> The code is minimalistic, so the duplication with GUI code is minimal or
>>> none.
>>>
>>> I suggest to put it to trunk, but to consider the name first. g.search
>>> sounds good but does it search modules or maps or both? Are the maps a
>>> possible extension of the current functionality?
>>>
>>> Vaclav
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

OK guys,

if nobody protests, I'll prepare basic framework for g.search.* modules and
let you know, once it's about to be ready

Jachym

so 28. 11. 2015 v 15:52 odesílatel Yann <yche...@gmail.com> napsal:

> +1 awesomeness
> +1 for trunk
>
> On 27/11/2015 17:12, Vaclav Petras wrote:
> > On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <
> jachym.cepi...@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> I've tried to implement command line alternative to module search based
> on
> >> keywords, which is available in the gui - it's called g.search
> >>
> >> Any chance, you might find this useful ? Any comment to the source code
> >> and outputs?
> >>
> >> https://github.com/jachym/g.search
> >>
> > I think it is awesome:
> >
> > $ g.extension extension=g.search url=https://github.com/jachym/g.search
> > $ g.search MLC
> >
> > i.gensig
> >  Description: Generates statistics for i.maxlik from raster map.
> >  Keywords: imagery,classification,supervised classification,Maximum
> > Likelihood Classification,MLC,signatures
> >
> > i.maxlik
> >  Description: Classifies the cell spectral reflectances in imagery
> data.
> > Classification is based on the spectral signature information generated
> by
> > either i.cluster, g.gui.iclass, or i.gensig.
> >  Keywords: imagery,classification,Maximum Likelihood
> Classification,MLC
> >
> > The code is minimalistic, so the duplication with GUI code is minimal or
> > none.
> >
> > I suggest to put it to trunk, but to consider the name first. g.search
> > sounds good but does it search modules or maps or both? Are the maps a
> > possible extension of the current functionality?
> >
> > Vaclav
> >
> >
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
> -
> Yann Chemin
> Address: 3 Toul Melin, 56400 Plumergat
> Mobile: +33 (0)7 83 85 52 34
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] proposal for g.search module

[Jachym Cepicky]

Hi all,

I've tried to implement command line alternative to module search based on
keywords, which is available in the gui - it's called g.search

Any chance, you might find this useful ? Any comment to the source code and
outputs?

https://github.com/jachym/g.search

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

Re: [GRASS-dev] proposal for g.search module

[Jachym Cepicky]

ahoj Vašku,

not sure about the maps. wouldn't be better to extend g.list?

about the name: g.module.search?

need to work on the output a bit more...

would -g flag be useful as well?

glad you like it

jachym

On Fri, Nov 27, 2015, 17:13 Vaclav Petras <wenzesl...@gmail.com> wrote:

> On Fri, Nov 27, 2015 at 10:51 AM, Jachym Cepicky <jachym.cepi...@gmail.com
> > wrote:
>
>> Hi all,
>>
>> I've tried to implement command line alternative to module search based
>> on keywords, which is available in the gui - it's called g.search
>>
>> Any chance, you might find this useful ? Any comment to the source code
>> and outputs?
>>
>> https://github.com/jachym/g.search
>>
>
> I think it is awesome:
>
> $ g.extension extension=g.search url=https://github.com/jachym/g.search
> $ g.search MLC
>
> i.gensig
> Description: Generates statistics for i.maxlik from raster map.
> Keywords: imagery,classification,supervised classification,Maximum
> Likelihood Classification,MLC,signatures
>
> i.maxlik
> Description: Classifies the cell spectral reflectances in imagery
> data. Classification is based on the spectral signature information
> generated by either i.cluster, g.gui.iclass, or i.gensig.
> Keywords: imagery,classification,Maximum Likelihood Classification,MLC
>
> The code is minimalistic, so the duplication with GUI code is minimal or
> none.
>
> I suggest to put it to trunk, but to consider the name first. g.search
> sounds good but does it search modules or maps or both? Are the maps a
> possible extension of the current functionality?
>
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] measuring cpu time for each module and estimating modules scalability

[Jachym Cepicky]

Hi all,

just some intellectual thoughts for the weekend (I'm off for a
weekend, so no need to rush with the answer). I started to write some
script  [1], which tries to estimate CPU time, needed for each GRASS
module (currently, I have about 4-5 raster modules). Target is to
create suit (rather then simple script), which could estimate how each
process scales (based on number of features or raster cells, which
need to be processed) and put GRASS modules into row. Also estimate
rawly CPU time, which is consumed by each module.

Any thoughts to this?

I started with the dataset from Martin [2], but I thing, I'll switch
over to spearfish, one resolution for now. I did not figure out yet,
how to implement equivalent of unix time [3] program in Python

Thanks

Jachym

[1] https://github.com/jachym/grass-performace
[2] http://geo.fsv.cvut.cz/data/grasswikicz/freegeodatacz/aktualni/
[3] https://github.com/jachym/grass-performace

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

Give your code freedom with PyWPS - http://pywps.wald.intevation.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass71 and GDAL read

[Jachym Cepicky]

Worked, but had to add -I/usr/include/postgresql/ to CPPFLAGS

seems to be compiled and in gdal

thank you

2014-06-27 12:13 GMT+02:00 Huidae Cho gras...@gmail.com:
 Try the attached patches. The GRASS plugin works for me.

 ./configure --with-autoload=/usr/lib/gdalplugins
 --with-grass=/your/grass/path

 Huidae


 On Fri, Jun 27, 2014 at 3:11 AM, Jachym Cepicky jachym.cepi...@gmail.com
 wrote:

 Hi Martin,

 ok, sorry, but I'm a bit confused from amount of patches, which are
 attached to the ticket and none of them seems to be working on
 gdal-grass-1.4.3.

 I'm using GRASS 7.1 btw, so I hope, that is ok in general.

 Could you point me please to patches, which should work with
 http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz ?

 Thanks

 2014-06-24 22:27 GMT+02:00 Martin Landa landa.mar...@gmail.com:
  Hi,
 
  2014-06-24 22:09 GMT+02:00 Jachym Cepicky jachym.cepi...@gmail.com:
 
  I wanted to publish some maps via MapServer, using GDAL, like the old
  days. But I did not succeed to get it compiled with GRASS (at first
  try). What is the best way you would propose to approach?
 
  1 - compile gdal withnout grass
  2 - compile grass 7.1 with gdal support
  3 - compile gdal again with grass support?
 
  It worked some years back, but does it still apply?
 
  best is to compile GRASS driver as a plugin, anyway GRASS 7 support in
  GDAL is still open issue [1].
 
  Martin
 
  [1] http://trac.osgeo.org/gdal/ticket/2953
 
  --
  Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa



 --
 Jachym Cepicky
 e-mail: jachym.cepicky gmail com
 URL: http://les-ejk.cz
 GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev





-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass71 and GDAL read

[Jachym Cepicky]

Hi Martin,

ok, sorry, but I'm a bit confused from amount of patches, which are
attached to the ticket and none of them seems to be working on
gdal-grass-1.4.3.

I'm using GRASS 7.1 btw, so I hope, that is ok in general.

Could you point me please to patches, which should work with
http://download.osgeo.org/gdal/gdal-grass-1.4.3.tar.gz ?

Thanks

2014-06-24 22:27 GMT+02:00 Martin Landa landa.mar...@gmail.com:
 Hi,

 2014-06-24 22:09 GMT+02:00 Jachym Cepicky jachym.cepi...@gmail.com:

 I wanted to publish some maps via MapServer, using GDAL, like the old
 days. But I did not succeed to get it compiled with GRASS (at first
 try). What is the best way you would propose to approach?

 1 - compile gdal withnout grass
 2 - compile grass 7.1 with gdal support
 3 - compile gdal again with grass support?

 It worked some years back, but does it still apply?

 best is to compile GRASS driver as a plugin, anyway GRASS 7 support in
 GDAL is still open issue [1].

 Martin

 [1] http://trac.osgeo.org/gdal/ticket/2953

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



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 release planning

[Jachym Cepicky]

Just noting, that I like Martin's analogy to GRASS 5.0 versus 5.1 some
time ago. History is repeating.

2014-06-23 17:35 GMT+02:00 Martin Landa landa.mar...@gmail.com:
 Hi,

 2014-06-23 10:56 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:

 ... so, getting out 7.0 seems to be endless...

 A radical solution might be to change trunk into GRASS GIS 8. Then we
 do not need to wait in 7 for API stabilization and can release it as
 is and go ahead with the planned massive improvements.

 I think that there is no need for GRASS 8 at this moment, it's not
 related to GRASS 7 release management. The real problem is that we
 don't have clear list of desired features for GRASS 7. Once we start
 with RC stage we need to be sure that we are close to the final
 release - to avoid RC for months or even several months like happen in
 the past. We should also vote about RFC4 before we start with RC
 stage. Personally I would start with GRASS 8 when there will be a
 clear reason for that.

 This sound ok to me. So, ideally, at all times we should have one release
 branch and one development branch. Releases can then just be tagged from the
 release branch which gets only selected, well-tested, not to invasive
 backports from the dev branch.

 That is also reason why I would keep trunk as 7.1 before we start with
 tagging 7.0.0RC1.

 Once we decide that the dev branch is sufficiently different from release
 that backports become unfeasible, and sufficiently stabilised that we can
 branch a release branch out of it, we declare the previous release branch a
 legacy maintenance branch (with only limited bug fixing from that point on),
 and branch a new release branch.

 I would prefer to create just release branches. E.g.

 * We start with tagging 7.0.0RC1.
 * We create releasebranch_7_1 from trunk
 * Trunk becomes 7.2 or GRASS 8
 * We continue with backports only in releasebranch_7_0 towards final release
 * Development will continue in trunk and releasebranch_7_1
 * After some period we freeze releasebranch_7_1 and create
 releasebrach_7_2 from trunk/releasebranch_7_1.
 * We start RC stage in releasebranch_7_1
 * Development will continue in trunk a releasebranch_7_2.

 [...]

 But, even though, I know you are in a hurry to get a grass7 release out of
 the door, don't you think that we should finish 6.4.4 first ?

 To be honest I think we will have to accept shipping OSGEOLive with 6.4.4...

 Right, as far as I know Markus is off-line since 27/6. So let's start
 with idea to mark RC2 as a final and release it _this_week_! I don't
 know about any blockers. Any opinion? If you know about blockers let
 us know about that ASAP!

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



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass71 and GDAL read

[Jachym Cepicky]

hi all,

I wanted to publish some maps via MapServer, using GDAL, like the old
days. But I did not succeed to get it compiled with GRASS (at first
try). What is the best way you would propose to approach?

1 - compile gdal withnout grass
2 - compile grass 7.1 with gdal support
3 - compile gdal again with grass support?

It worked some years back, but does it still apply?

Thank you

Jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.surf.idw broken

[Jachym Cepicky]

Thanks

I can confirm, that using -n flag works

Jachym

2010/4/13 Paul Kelly paul-gr...@stjohnspoint.co.uk:
 On Tue, 13 Apr 2010, Jachym Cepicky wrote:

 Hi,
 I can not get reasonable result (compared with v.surf.rst) from
 v.surf.idw using attached input vector points

 is it possible, that v.surf.idw is kind of broken?

 Hello,
 I can confirm that I can reproduce the strangeness, that it only happens
 when *not* using the -n flag (i.e. when indexing points) and that it happens
 when interpolating a relatively small number of points into a region with a
 relatively high resolution. E.g. for the given data I observe strangeness
 for a resolution of 10, but it goes away either by specifying the -n flag or
 decreasing the resolution to 15.

 It does indeed look to be caused by my buggy code from 2003, or (perhaps
 less likely; I'm not sure) some later change to it - specifcally something
 to do with the shortlist method of avoiding an intensive search for nearby
 sites/points when the number of points is relatively small compared to the
 region size.

 I can't see anything obviously wrong but I'll look into it over the next few
 days...

 Paul




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] vector libs: file based spatial index

[Jachym Cepicky]

Nice work. 

What about make it scalable? In case, the vector library would take more
then GRASS_VECTOR_MEMORY_MAX (or similar), make it file-based. Keep it
in memory otherwise.

j

On Tue, Jun 23, 2009 at 08:28:49PM +0200, Markus GRASS wrote:
 Paolo Cavallini wrote:
  Markus GRASS ha scritto:

  What to do now? Leave it all in memory as in grass6, build in memory
  then write out (risk of running out of memory on massive datasets), or
  keep it always in file? I'll not commit any time soon (also waiting for
  the lib/raster commotion to settle down), I need feedback on how to
  proceed or if I should forget about it.
  
 
  I think advice from Radim would be very useful here.
  All the best.

 OK, let me rephrase. I think I have two alternatives to the current
 implementation of the vector spatial index and would like to know if
 grass7 should get 1) faster vector display and lower memory consumption
 at the cost of (sometimes) slower vector processing [1], 2) faster
 vector display, a similar speed in vector processing but keep the risk
 of running out of memory when processing large datasets, or 3) no
 changes to the spatial index. IMHO this should be a general decision of
 the GRASS community, not of one or two developers.
 
 The actual implementation is not easy and advice from Radim and other
 developers would really be very useful.
 
 Markus M
 
 [1] the sometimes slow speed of v.lidar.edgedetection is caused by the
 module not the vector libs, as is probably true for other modules e.g.
 v.extract (I remember a remark earlier this year, haven't searched the MLs)
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp
Key fingerprint: 0C6D 0EAE 76BD 506C F299  ED8A C8AB 74B8 08D4 E08F


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

Re: [GRASS-dev] call for volunteers - urgent need for Windows Vista binaries

[Jachym Cepicky]

hi, just small note:

On Thu, Mar 26, 2009 at 12:21:55PM -0700, Michael Barton wrote:
 Marco Pasetti made a very nice Windows installer for 6.3 last year, but 
 is unable to continue this work.

 Other folks in OSGEO have created OSGEO4W with a number of packages.  
 However, GRASS is in the 'advanced' section--and it is not clear what  
 libraries need to be downloaded with it--and it cannot be installed  
 stand-alone.


the osgeo4w installer is just fine, only thing is missing is, that GRASS
should appear in the 'basic' section as well (should not be that
complicated) and all depandances are fixed. than the installation is IMHO 
enough straight forward and easy.

jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/JachymCepicky.pgp
Key fingerprint: 0C6D 0EAE 76BD 506C F299  ED8A C8AB 74B8 08D4 E08F


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

Re: [GRASS-dev] GRASS 6.4 for Windows?

[Jachym Cepicky]

GRASS 6.4 is in the osgeo4w[1] package - it works, but wxpython gui
does not work yet [2]

jachym


[1] http://trac.osgeo.org/osgeo4w/
[2] http://trac.osgeo.org/osgeo4w/ticket/37

2009/2/3 Michael Barton michael.bar...@asu.edu:
 I've had a few people ask about GRASS 6.4 for Windows. Has anyone managed to
 create a binary yet? GRASS 6.5? GRASS 7?
 Michael
 
 C. Michael Barton, Professor of Anthropology
 Director of Graduate Studies
 School of Human Evolution  Social Change
 Center for Social Dynamics  Complexity
 Arizona State University
 Phone: 480-965-6262
 Fax: 480-965-7671
 www: www.public.asu.edu/~cmbarton



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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.0 release branch created

[Jachym Cepicky]

ubuntu works

j

2008/12/19 William Kyngesburye wokl...@kyngchaos.com:
 Simple test run OK here on OSX.

 On Dec 19, 2008, at 2:39 PM, Markus Neteler wrote:

 Today the GRASS 6.4.0 release branch has been created-
 Please check it out and test it (now) before we tag RC1:

 svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4

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

 -
 William Kyngesburye kyngchaos*at*kyngchaos*dot*com
 http://www.kyngchaos.com/

 Those people who most want to rule people are, ipso-facto, those least
 suited to do it.

 - A rule of the universe, from the HitchHiker's Guide to the Galaxy


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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS GIS] #402: v.in.ogr buffer overflow

[Jachym Cepicky]

 (Hi,

(http://trac.osgeo.org/grass/ticket/402 returns 500 Internal Server
Error, so I'm replying via mailing list)

same problem here:

Ubuntu 8.10:

ii  gdal-bin  1.5.2-4.1~intrepid
ii  libgdal1-1.5.01.5.2-4.1~intrepid
ii  libgdal1-1.5.0-grass  1.5.2-1
ii  libgdal1-dev  1.5.2-4.1~intrepid

applyes for GRASS 6.3 (les-ejk ubuntu package) and 6.4 (fresh source
compilation)

the problem seems to be in ubuntu gdal package

$ ogrinfo /home/jachym/usr/src/thuban/thuban_trunk/Data/iceland/roads-line.shp
INFO: Open of 
`/home/jachym/usr/src/thuban/thuban_trunk/Data/iceland/roads-line.shp'
  using driver `ESRI Shapefile' successful.
1: roads-line (Line String)

$ ogrinfo /home/jachym/usr/src/thuban/thuban_trunk/Data/iceland/roads-line.shp
 roads-line

INFO: Open of 
`/home/jachym/usr/src/thuban/thuban_trunk/Data/iceland/roads-line.shp'
  using driver `ESRI Shapefile' successful.

Layer name: roads-line
Geometry: Line String
Feature Count: 839
Extent: (-24.450359, 63.426830) - (-13.556688, 66.520111)
Layer SRS WKT:
(unknown)
FNODE_: Real (11.0)
TNODE_: Real (11.0)
LPOLY_: Real (11.0)
RPOLY_: Real (11.0)
LENGTH: Real (12.3)
RDLINE_: Real (11.0)
RDLINE_ID: Real (11.0)
RDLNTYPE: Integer (2.0)
RDLNSTAT: Integer (2.0)
OGRFeature(roads-line):0
*** buffer overflow detected ***: ogrinfo terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb6979558]
/lib/tls/i686/cmov/libc.so.6[0xb6977680]
/lib/tls/i686/cmov/libc.so.6[0xb6976f87]
/lib/tls/i686/cmov/libc.so.6(__snprintf_chk+0x34)[0xb6976e74]
/usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature16GetFieldAsStringEi+0x36f)[0xb7d5641f]
/usr/lib/libgdal1.5.0.so.1(_ZN10OGRFeature12DumpReadableEP8_IO_FILE+0x92)[0xb7d57012]
ogrinfo[0x8049380]
ogrinfo[0x8049cd2]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb6895685]
ogrinfo[0x80491e1]
=== Memory map: 
08048000-0804b000 r-xp  08:01 241275 /usr/bin/ogrinfo
0804b000-0804c000 r--p 2000 08:01 241275 /usr/bin/ogrinfo
0804c000-0804d000 rw-p 3000 08:01 241275 /usr/bin/ogrinfo
097df000-0980 rw-p 097df000 00:00 0  [heap]
[.]

so, we have to dig in this direction

jachym


2008/12/16 GRASS GIS t...@osgeo.org:
 #402: v.in.ogr buffer overflow
 --+-
  Reporter:  epatton  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0
  Component:  Vector   | Version:  svn-develbranch6
 Resolution:   |Keywords:  buffer overflow, vector, shapefile, 
 import
  Platform:  Linux| Cpu:  x86-64
 --+-
 Comment (by mmetz):

  Replying to [comment:4 epatton]:

   Can anyone with a 64-bit system test importing shapefiles with v.in.ogr?
  
  No problems on GNU/Linux 64 bit, gcc 4.1.2, gdal 1.5.2, grass64 and
  grass70. Maybe this is specific to your particular platform? Compile and
  install gdal anew?

  Markus M

 --
 Ticket URL: http://trac.osgeo.org/grass/ticket/402#comment:5
 GRASS GIS http://grass.osgeo.org

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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Buffer overflow GRASS GIS 6.3.0

[Jachym Cepicky]

For those, who are impatient, because of I do not have access to
Les-ejk right now, fresh packages for Ubuntu 8.10 with GRASS 6.3, with
working WxGUI are located at

deb http://sandbox.cz/~jachym/ubuntu intrepid multiverse

this repository is only temporary, I'll upload the packages to Les-ejk
during next week.

Jachym

2008/11/14 Markus Neteler [EMAIL PROTECTED]:
 2008/11/14 Glynn Clements [EMAIL PROTECTED]:

 Jáchym Čepický wrote:

 I already reported problem with g.parsr in GRASS 6.3 on Ubuntu 8.10

 here is another message, maybe it could help (?)

 I believe that this has been fixed by r34172 (7.0) and r34173 (6.4),
 with the following change:

 --- general/g.parser/main.c (revision 34171)
 +++ general/g.parser/main.c (revision 34172)
 @@ -358,7 +358,7 @@
  * to uppercase it was necessary to use uppercase variables.
  * Set both until all scripts are updated */
 for (flag = ctx.first_flag; flag; flag = flag-next_flag) {
 -   char buff[12];
 +   char buff[16];

sprintf(buff, GIS_FLAG_%c=%d, flag-key, flag-answer ? 1 : 0);
putenv(G_store(buff));


 Backported to 6.3.svn, too.

 Markus




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 6.3 for Ubuntu 8.10 - Intrepid Ibex

[Jachym Cepicky]

Hi,

first version of the GRASS 6.3.0 package for Ubuntu 8.10 can be
apt-geted from http://les-ejk.cz/ubuntu

There is one problem with new wxPython-based GUI, but overall, the
package seems to be working.

Please, let me know, in case, it does not work for you.

Jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] ubuntu 8.10, grass 6.3, r.fill.dir|r.drain

[Jachym Cepicky]

Hi,

I try to package grass 6.3 for ubuntu 8.10 and it failes on r.fill.dir
and r.drain moduels (both do use same type of open function and do
fail on the same issue, as it seems to me):

cd r.fill.dir  make
[...]
main.c:273: warning: ignoring return value of 'read', declared with
attribute warn_unused_result
In function 'open',
inlined from 'main' at main.c:199:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode'
declared with attribute error: open with O_CREAT in second argument
needs 3 arguments
In function 'open',
inlined from 'main' at main.c:200:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode'
declared with attribute error: open with O_CREAT in second argument
needs 3 arguments
In function 'open',
inlined from 'main' at main.c:201:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode'
declared with attribute error: open with O_CREAT in second argument
needs 3 arguments
make: *** [OBJ.i486-pc-linux-gnu/main.o] Error 1


in r.fill.dir/main.c, lines 199-201:


   fe=open(tempfile1,O_RDWR|O_CREAT); /* elev */
   fd=open(tempfile2,O_RDWR|O_CREAT); /* dirn */
   fm=open(tempfile3,O_RDWR|O_CREAT); /* problems */

What do do?

Thanks

Jachym



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: GUI splash heritige

[Jachym Cepicky]

Hi,
one profesor told me, he new the name of the author. The map is pretty
old, with north on the bottom. I'll ask and let you know.

Jachym

2008/10/21 Hamish [EMAIL PROTECTED]:
 Hi,

 I am looking to document the heritage of the GUI startup splash screen.

 Anybody know?  The Polonia in the bottom left indicates Poland, but as
 it came from Radim I thought perhaps the area is part of Czech now, or...?


 thanks,
 Hamish




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: GUI splash heritige

[Jachym Cepicky]

http://mapserver.fsv.cvut.cz/antos/zoomify/helwig.html
http://mapserver.fsv.cvut.cz/antos/slezsko_en.html

Could it be?

jachym

2008/10/21 Jachym Cepicky [EMAIL PROTECTED]:
 Hi,
 one profesor told me, he new the name of the author. The map is pretty
 old, with north on the bottom. I'll ask and let you know.

 Jachym

 2008/10/21 Hamish [EMAIL PROTECTED]:
 Hi,

 I am looking to document the heritage of the GUI startup splash screen.

 Anybody know?  The Polonia in the bottom left indicates Poland, but as
 it came from Radim I thought perhaps the area is part of Czech now, or...?


 thanks,
 Hamish




 --
 Jachym Cepicky
 e-mail: jachym.cepicky gmail com
 URL: http://les-ejk.cz
 GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.mapcalc changed to use G_parser()

[Jachym Cepicky]

wow!

j

2008/8/6 Glynn Clements [EMAIL PROTECTED]:

 I have changed r.mapcalc in 7.x to use G_parser():

$ r.mapcalc --help

Description:
 Raster map calculator.

Keywords:
 raster

Usage:
 r.mapcalc [expression=string] [input=name] [--overwrite] [--verbose]
   [--quiet]

Flags:
 --o   Allow output files to overwrite existing files
 --v   Verbose module output
 --q   Quiet module output

Parameters:
  expression   Expression to evaluate
   input   File containing expression to evaluate

 Note that, as expression= is the first option, it is the default. This
 means that passing an expression on the command line is compatible
 with both the old and new interfaces, so long as you:

 a) quote the expression, and
 b) include a space before the first = sign.

 E.g.:
r.mapcalc foo = 1
 or:
r.mapcalc 'foo = 1'

 An unquoted expression (i.e. split over multiple arguments) won't
 work, nor will omitting the space before the = sign:

$ r.mapcalc 'foo=1'
Sorry, foo is not a valid parameter

 If no options are given, it manufactures input=- (which reads from
 stdin), so you can continue to use e.g.:

r.mapcalc  file
 or:
r.mapcalc EOF
foo = 1
EOF

 But unless you need compatibility with previous versions, use input=
 explicitly, e.g.:

r.mapcalc input=file
 or:
r.mapcalc input=- EOF
foo = 1
EOF

 Also, it now recognises --o[verwrite] and $GRASS_OVERWRITE, so you
 will get an error if you try to overwrite an existing map without one
 of those.

 Note that older versions don't understand --o, so if you want to write
 a shell script which is compatible with both versions, and which will
 overwrite existing maps, use e.g.:

GRASS_OVERWRITE=1 r.mapcalc 'foo = 1'

 Python scripts only need to work with 7.x, so you can just use --o (or
 overwrite=True with grass.run_command etc).

 --
 Glynn Clements [EMAIL PROTECTED]
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] importing raster using r.in. *

[Jachym Cepicky]

try r.in.gdal

r.in.tiff has been removed in grass 6.x

jachym

2008/8/1 aschley nod [EMAIL PROTECTED]:
 i'm a beginner in GRASS. I have read in the tutorial that r.in.* is the
 command to import a raster.So, i tried the following command:

 r.in.tiff input=phil.tiff output = samplephil
  and this thing appeared...
 bash: r.in.tiff: command not found
  what am i supposed to do?
 i'm using grass6.3

 hope someone can help me.

 Send instant messages to your online friends http://uk.messenger.yahoo.com
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Python Scripting

[Jachym Cepicky]

I have something similar in PyWPS code [1], but this looks much nicer
to me. Looking forward to adopt this.

Jachym

[1] 
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/pywps/Process/Process.py?rev=541root=pywpsview=markup
look after def cmd

2008/7/18 Glynn Clements [EMAIL PROTECTED]:

 Glynn Clements wrote:

  As to existing modules, what about a helper function to access then?
 
  module.executeModule( name=r.stats, options={ input:
  elevation.dem,slope,aspect, fs: ,, output: elev.csv},
  flags=[q, 1, n, g] )

 This idea has occurred to me. Some comments:

 Pass argument values as Python values, e.g. passing multiple values as
 lists, passing numeric types directly, etc, and have the interface
 convert them to strings. Pass the flags as a single string.

 module.execute( r.stats,
 options = { input: [elevation.dem, slope, aspect],
 fs: ,,
 output: elev.csv },
 flags = q1ng )

 Provide a lower-level function which simply generates the command to
 pass to Popen(), for cases where you want to interact with the child
 process.

 I have attached a first draft of such a module, which also includes a
 wrapper function for g.parser (for which an example script is also
 attached).

 --
 Glynn Clements [EMAIL PROTECTED]


 import os
 import os.path
 import sys
 import types
 import subprocess

 def _make_val(val):
if isinstance(val, types.StringType):
return val
if isinstance(val, types.ListType):
return ,.join(map(_make_val, val))
if isinstance(val, types.TupleType):
return _make_val(list(val))
return str(val)

 def make_command(prog, options = [], flags = , overwrite = False, quiet = 
 False, verbose = False):
args = [prog]
if overwrite:
args.append(--o)
if quiet:
args.append(--q)
if verbose:
args.append(--v)
if flags:
args.append(-%s % flags)
for opt, val in options.iteritems():
args.append(%s=%s % (opt, _make_val(val)))
return args

 def start_command(prog, options = [], flags = , overwrite = False, quiet = 
 False, verbose = False, **kwargs):
args = make_command(prog, options, flags, overwrite, quiet, verbose)
return subprocess.Popen(args, **kwargs)

 def run_command(*args, **kwargs):
ps = start_command(*args, **kwargs)
return ps.wait()

 def _parse_env():
options = {}
flags = {}
for var, val in os.environ.iteritems():
if var.startswith(GIS_OPT_):
opt = var.replace(GIS_OPT_, , 1).lower()
options[opt] = val;
if var.startswith(GIS_FLAG_):
flg = var.replace(GIS_FLAG_, , 1).lower()
flags[flg] = bool(int(val));
return (options, flags)

 def parser():
if not os.getenv(GISBASE):
print  sys.stderr, You must be in GRASS GIS to run this program.
sys.exit(1)

if len(sys.argv)  1 and sys.argv[1] == @ARGS_PARSED@:
return _parse_env()

argv = sys.argv[:]
name = argv[0]
if not os.path.isabs(name):
argv[0] = os.path.normpath(os.path.join(sys.path[0], name))

os.execvp(g.parser, [name] + argv)
raise OSError(error executing g.parser)

 #!/usr/bin/env python

 # g.parser demo script for python programing

 import grass

 #%Module
 #%  description: g.parser test script (python)
 #%End
 #%flag
 #%  key: f
 #%  description: a flag
 #%END
 #%option
 #% key: raster
 #% type: string
 #% gisprompt: old,cell,raster
 #% description: raster input map
 #% required : yes
 #%end
 #%option
 #% key: vector
 #% type: string
 #% gisprompt: old,vector,vector
 #% description: vector input map
 #% required : yes
 #%end
 #%option
 #% key: option1
 #% type: string
 #% description: an option
 #% required : no
 #%end

 if __name__ == __main__:
(options, flags) = grass.parser()

print 
if flags['f']:
print Flag -f set
else:
print Flag -f not set

#test if parameter present:
if options['option1']:
print Value of option1: '%s' % options['option1']

print Value of raster= option: '%s' % options['raster']
print Value of vector= option: '%s' % options['vector']

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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] problems with vector file import

[Jachym Cepicky]

hi,

on grass 6.3, gdal 1.5.1 I can not import one vector file, nomatter,
if it is shapefile or GML (converted using ogr2ogr). I tested another
vector file with over 10 000 polygons, no problem

I get bunch of messeges like

[]
WARNING: Area size [1.6e-05], area not imported
WARNING: Area size [2.5e-07], area not imported
WARNING: Area size [3.8e-05], area not imported
WARNING: Area size [3.0e-05], area not imported
WARNING: Area size [9.0e-06], area not imported
WARNING: Area size [1.6e-05], area not imported
WARNING: Area size [1.5e-05], area not imported
WARNING: Area size [5.1e-06], area not imported
WARNING: Area size [6.2e-06], area not imported
WARNING: Area size [8.6e-05], area not imported
[...]

and at the end, only four polygons are created (out of cca 60).

if I do display the file in qgis, everything looks all right


sample file can be downloaded from
(GML) http://les-ejk.cz/tmp/pole2009.gml
(SHP) http://les-ejk.cz/tmp/pole2009.tgz

what should I do?

thanks

jachym
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: R: [GRASS-dev] WinGRASS Plans

[Jachym Cepicky]

hi,
strange, when we started to develop the wx-gui, I just used my old
laptop. it was celeron with 600 MHz and I had 192 MB RAM. It was
usable

j

2008/6/10 Marco Pasetti [EMAIL PROTECTED]:
 Hy Glynn,

 did you ever estimated the speed of the Python GUI Vs a generic compiled
 GUI?

 On my old Notebook (AMD Athlon64 3000+, 1.25 GB RAM DDR, integrated NVIDIA
 GPU with shared 64 MB VRAM) I noticed that, very often, just opening a
 module GUI or a dialoge window caused the system to freeze for a while (XP
 Pro SP2, 32bit, very well maintained). This said, all the other GUI parts,
 such as the GIS Layer Manager and the Map Display, always worked very well,
 and never (maybe rarely) freezed.

 Is that because the GUI is interpreted or is it only a Windows problem?
 actually, many Windows native application GUIs frequently freeze, even if
 they are compiled and not interpreted GUIs...

 Thanks for your precious explanations, as always.. :-)

 Marco

 - Original Message - From: Glynn Clements
 [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: Michael Barton [EMAIL PROTECTED]; grass-dev@lists.osgeo.org
 Sent: Friday, June 06, 2008 6:37 PM
 Subject: Re: R: [GRASS-dev] WinGRASS Plans



 [EMAIL PROTECTED] wrote:

 Since we are talking about, why an interpretated language for the GUI

 It makes it easier for the user to customise the code, and to apply
 updates.

 --
 Glynn Clements [EMAIL PROTECTED]

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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.overaly - slow

[jachym . cepicky]

hi hamish,

thanks for the hint with v.select

the data was generated in GRASS, so v.in.ogr would not help

thanks

jachym

2008/5/24, Hamish [EMAIL PROTECTED]:
 Jachym:
 so, my question: is there such script already (maybe
 something in GDAL/OGR package, which I missed)? Isn't there
 any big mistake in my script?


 to speed it up use v.in.region+v.select before v.overlay, so expensive
 overlay is only performed on relevant features.

 during import you can replicate that with v.in.ogr's -r or spatial= options.



 Hamish










-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.overaly - slow

[Jachym Cepicky]

Hi,

I need to split one big vector file (200MB Shapefile) to several
smaler tiles , so it is more usable for mapserver, and I wrote a small
script v.mktiles, which should split big vector file into several
tiles (attached):

Description:
 Splits large vector map into several tiles with associated attribute table

Keywords:
 vector, tiles

Usage:
 v.mktiles [-c] input=name [type=string] prefix=name columns=value
   rows=value [--overwrite] [--verbose] [--quiet]

Flags:
  -c   Make a copy for attribute table for each tile
 --o   Allow output files to overwrite existing files
 --v   Verbose module output
 --q   Quiet module output

Parameters:
input   Name of input vector map
 type   Input map type
options: line,area
default: line
   prefix   Prefix for output vector maps
  columns   Resulting number of columns
default: 2
 rows   Resulting number of rows
default: 2


When the input file is relatively small (spearfish roads), it works fine:

GRASS v.mktiles in=roads pref=cest columns=2 rows=2 type=line --o

but when I try to run it on file with 155754 isolines, it took an
hour, and even the first tile was not generated

so, my question: is there such script already (maybe something in
GDAL/OGR package, which I missed)? Isn't there any big mistake in my
script?

If desired, in the future the script should take output from v.mkgrid as well

Thanks

Jachym
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


v.mktiles
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] (d.region.box)

[Jachym Cepicky]

added

j

2008/5/17 Hamish [EMAIL PROTECTED]:
 Jachym:
  I created new script, absed on d.region.box from
  Hamish. It has few more options.
 
  I think, script like this should go to GRASS (and not
  to live only as addon)

 until that is decided feel free to checkin your improvements in the addon 
 svn. (me: I don't mind either way if it is in main grass or not; let the 
 users decide! :)


 Michael:
 Does this drawing only work on an xmon?

 it will work with any display driver. (it is a wrapper for drawing a polygon 
 with d.graph)


 Hamish







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




-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] d.region

[Jachym Cepicky]

hi,

I created new script, absed on d.region.box from Hamish. It has few
more options.

I think, script like this should go to GRASS (and not to live only as addon)

I called it d.region, here is it's help:


Description:
 Draw desired region into current display

Keywords:
 display, region

Usage:
 d.region [-dcf] [name=string] [color=string] [width=value]
   [rast=string] [rast3d=string] [vect=string] [3dview=string] [n=value]
   [s=value] [e=value] [w=value] [--verbose] [--quiet]

Flags:
  -d   Draw default region
  -c   Draw current region
  -f   Non-persistant box (doesn't survive redraw or zoom)
 --v   Verbose module output
 --q   Quiet module output

Parameters:
name   Region name
   color   Color to draw with, either a standard GRASS color or R:G:B triplet
   default: black
   width   Line width
   default: 1
rast   Draw region to match this raster map
  rast3d   Draw region to match this 3D raster map
vect   Draw region to match this vector map
  3dview   Draw region to match this 3dview file
   n   Value for the northern edge
   s   Value for the southern edge
   e   Value for the eastern edge
   w   Value for the western edge

The script is attached to this e-mail.

What do you think: Is it worth to put in trunk/grass/display/ ? should
the name be d.region or d.region.box or different ?

Jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


d.region
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxgui digitizer

[Jachym Cepicky]

hi,
I tried compile the grass63 on amd64 and I get following error, while
running digitizer:


Unable to initialize display driver, see README file for more information.

Details: 'NoneType' object has no attribute 'OpenMap'
(/usr/local/lib/libgdi.so: undefined symbol: Py_InitModule4)

I created /usr/local/libgdi like follows:
sudo ln -s /usr/lib/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so
/usr/local/lib/libgdi.so

where could the problem be?

thanks

j
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: GRASS et al packages for Hardy Heron ?

[Jachym Cepicky]

HI Moritz,


Moritz Lennert píše v Út 22. 04. 2008 v 10:03 +0200:
 Hello Jachym,
 
 I just learned last night that the computers I will use for a training 
 course on FOSS-GIS are running Hardy Heron and Gutsy Gibbon as I was 
 told before. 


 Are you planning to update your packages to Hardy Heron in 
 a very near future ? 

Depends on the definition of near. It will probably take me another
month: I have tons of work now and I would like to try out amd64
version. 

 Does someone else have packages of GRASS + QGIS + 
 Dependencies for that platform ?

Afaik no :-(

 
 Moritz

Sorry, 

Jachym

-- 
Jachym Cepicky
e-mail:jachym les-ejk cz
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS et al packages for Hardy Heron ?

[Jachym Cepicky]

Hi,

Depends on the definition of near. It will probably take me another
month: I have tons of work now and I would like to try out amd64
version. 

J

Hamish píše v Út 22. 04. 2008 v 01:34 -0700:
 Moritz Lennert wrote:
  I just learned last night that the computers I will use for a training 
  course on FOSS-GIS are running Hardy Heron and Gutsy Gibbon as I was 
  told before. Are you planning to update your packages to Hardy Heron in
  a very near future ? Does someone else have packages of GRASS + QGIS + 
  Dependencies for that platform ?
 
 maybe try:   https://wiki.ubuntu.com/UbuntuGIS
 
 
 or packages for an older version of Ubuntu might still work if the
 library and package names haven't changed (?).
 
 
 
 Hamish
 
 
 
   
 
 Be a better friend, newshound, and 
 know-it-all with Yahoo! Mobile.  Try it now.  
 http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] opening any RS/GIS file in their original format directly in GRASS...

[Jachym Cepicky]

Hi,
Yann Chemin píše v Pá 14. 03. 2008 v 09:38 +0700:
 Hello list,
 
 many first time users get a little bit estranged by the
 scientifically robust way of starting GRASS by setting up a
 DB/location/mapset.
 
 While the create location from georeferenced file button in TCLTK
 gui (not yet in wxpython it seems) is an very nice step,
 I would like your ideas about the feasibility of a CLI command similar
 to grass63 rs_image.tif or grass63 shapfile.shp possibly having a
 right-click option: open with... = Grass63 like you can see in many
 OSes these days.
 
 The idea would be to create a temporary location (if not already there
 and compatible) from this image/GIS_cover data,  import it , load
 layer(s), and display it(them). 

Great idea! And, if the user would exit GRASS, dialog could appear, with
Save current session  [Yes/No], which would create something like
GRASS Project File (project_name.grs), which could start GRASS by
double click (and point GRASS to the right location/mapset and start the
GUI etc.) In the same time, the new created mapset/location would be
moved from /tmp to some other chosen directory.

?

Jachym


 
 One more step could be creating a png out of it, with title, arrow,
 scale etc... as a thumbnail view of the dataset. 
 Don't know, the extents and date/time (if any) could be added in a
 kind of default location holding footprints of already opened data
 with standard grass metadata (r.info) available on click over a given
 footprint... Of course with the thumbnail available somehow directly
 in the footprint as hyperlink, or as display option (visible/hidden),
 or just a hyperlink in the metadata, or if metadata can be reformatted
 (automatically) to html, then embed the thumbnail it...
 
 Many people face a large amount of datasets these days, and knowing
 where/when/what is each is a challenge.
 
 sorry, started as a simple idea, ended in a kind of cataloging
 project...
 
 Have a nice day,
 Yann
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: Re[GRASS-dev] ady to help with GRASS graphics

[Jachym Cepicky]

Hi,
Robert Szczepanek píše v Čt 13. 03. 2008 v 10:41 -0700:

 
 First draft is on my web page
 http://www.szczepanek.pl/icons.grass/
 I have only TclTk interface at the moment to check how it works.
 

I like it - nice work

I have problem with the first Display active layers icon. Together
with Refresh button it is confusing. I would prefer:

1) Redrawing display automatically, when new layer is added in the gis
manager

2) one Refresh button for the case, the user wants to see something
new in her maps

Jachym
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: GUI support for TclTk 8.5

[Jachym Cepicky]

Maybe this would help on windows as well? Currently, you have to install
tcltk 8.4, to get nviz working

jachym

William Kyngesburye píše v Ne 09. 03. 2008 v 19:52 -0500:
 Ah, it looks like --enable-xft is a new option in Tk 8.5, and is  
 enabled by default.  In the working Tiger TclTk 8.5 GUI, the menu  
 fonts look nice, compared to the 8.4 GUI.
 
 So, disabled xft and now TclTk 8.5 GUI works on Leopard.  NVIZ also  
 works.  NVIZ still won't run on Tiger though.
 
 On Mar 9, 2008, at 6:01 PM, William Kyngesburye wrote:
 
  Some initial tests for TclTk 8.5.1 on OSX.
 
  10.4/Tiger: the GUI runs and seems to work properly.  NVIZ won't run  
  - with Spearfish:
 
  
  nviz elev=elevation.10m
 
  alloc: invalid block: 0x5202b4: 61 0 0
 
  [2]+ Abort trap
  
 
  Even just nviz --help gives that alloc error.
 
 
  10.5/Leopard: won't run at all.  There appears to be some problem  
  between Leopard's fontconfig/freetype and TclTk 8.5 (TclTk 8.4 works).
 
  Thread 0 Crashed:
  0   libfontconfig.1.dylib   0x004a620a FcConfigAddCache + 149
  1   libfontconfig.1.dylib   0x004a63b8 FcConfigAddDirList + 157
  2   libfontconfig.1.dylib   0x004a6471 FcConfigBuildFonts + 123
  3   libfontconfig.1.dylib   0x004b1dc0  
  FcInitLoadConfigAndFonts + 45
  4   libfontconfig.1.dylib   0x004b1e0c FcInit + 41
  5   libfontconfig.1.dylib   0x004a650a FcConfigGetCurrent + 30
  6   libfontconfig.1.dylib   0x004a8302  
  FcConfigSubstituteWithPat + 25
  7   libfontconfig.1.dylib   0x004a8a07 FcConfigSubstitute + 39
  8   libtk8.5.dylib  0x001c3613 InitFont + 72
  ...
 
  (This is 32bit mode.  In 64bit mode it made it into freetype before  
  crashing.)
 
  Unfortunately, I think tcltk/X11 on OSX is forced to used the X11  
  freetype/fontconfig build, instead of the one I configure for GRASS  
  (my freetype framework).
 
  -
  William Kyngesburye kyngchaos*at*kyngchaos*dot*com
  http://www.kyngchaos.com/
 
  Theory of the Universe
 
  There is a theory which states that if ever anyone discovers exactly  
  what the universe is for and why it is here, it will instantly  
  disappear and be replaced by something even more bizarrely  
  inexplicable.  There is another theory which states that this has  
  already happened.
 
  -Hitchhiker's Guide to the Galaxy 2nd season intro
 
 
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-dev
 
 -
 William Kyngesburye kyngchaos*at*kyngchaos*dot*com
 http://www.kyngchaos.com/
 
 History is an illusion caused by the passage of time, and time is an  
 illusion caused by the passage of history.
 
 - Hitchhiker's Guide to the Galaxy
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Porting d.* to native Win32

[Jachym Cepicky]

Hi,

imho the best way would be, to connect new WX monitors, so they work via
command line interface. Some proposal interface was there (see p.mon 
friends in wxgui source) - using temporary files for the communication

jachym
 
[EMAIL PROTECTED] píše v Ne 09. 03. 2008 v 12:32 +0100:
 Dear all,
 
 I would like to look into supporting d.mon and friends under native Win.
 
 As far as I understand, we need two things:
 
 
 1. A native Windows graphics device, so we won't need an X Server
 for the graphics output.
 
 2. A BSD style sockets interface, so the d.* commands can communicate
 with the graphics device.
 
 Now, as far as I understand, point (1) has been taken care of via the W11
 driver which is already in the current GRASS code base (?)
 
 That would leave the sockets problem.
 
 I am not 100% sure about this, but it seems all we need is to adapt the
 code for native win, so that the Windows sockets interface will be used for
 that platform?
 Its specifications seem to indicate that WinSocks can handle BSD style
 sockets as well: http://tangentsoft.net/wskfaq/general.html.
 
 Or do we need a more complex compatibility layer, such as provided by
 the Mozilla cross platform SDK:
 http://www.xulplanet.com/tutorials/mozsdk/sockets.php ???
 
 If anyone could cut out the work that needs to be done more precisely
 for me, I would like to give it a try ...
 
 Best,
 
 Benjamin
 
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Manpage HTML markup consistency

[Jachym Cepicky]

Hi,

I do not know, if anybody already excluded LaTeX for better
documentation output, but this format has it's potential as well...


Jachym

Helena Mitasova píše v Út 26. 02. 2008 v 12:54 -0500:
 DocBook has been considered for OSGeo edu material so there has been 
 quite a bit of discussion on that - this is what Frank had to say:
 
 On the whole DocBook issue - we tried using DocBook for a while for
 MapServer
 docs and ended up abandoning it because installing and getting to understand
 DocBook tools was too hard for many potential contributors.  It also turned
 out to be a clumsy format to work in.  Perhaps things have improved, or
 we mapserverites were particularly dumb - but take that at least as a mild
 cautionary tale.  We ended up with documents written in html, and restructured
 text in plone though we aren't so thrilled with that either.  There is
 some consideration being given to just moving to a Trac wiki (though Trac
 wiki is particular weak as a wiki in my opinion).
 
 here is the discussion:
 http://lists.osgeo.org/pipermail/edu_discuss/2008-January/thread.html
 
 I tried DocBook and you just have to learn and get used to a new thing
 and it has its own complexities and I am not sure it is worth it.
  
 And BTW I am one those people who find having the old fashioned man pages
 on hand useful - I work a lot from home and it was much faster to view
 the simwe man pages that I was modifying using the old format than waiting
 for them to pop-up in remotely run web browser or move them around.
 I would also like to suggest keeping the man pages simple and easy to 
 maintain,
 the more complex it gets, the fewer people will be able to maintain it and
 the more complex the task will become.
 
 Helena
 
 
 On Tue, 2008-02-26 at 09:31 -0800, Dylan Beaudette wrote:
  On Monday 25 February 2008, Glynn Clements wrote:
   Dylan Beaudette wrote:
I wonder if now would be a good time to investgate the use of CSS in the
man pages. If we define a couple types of container objects (div,
span, etc) we can use a single style file to later manipulate the look
and feel of the manual pages.
  
   If you're going to overhaul the documentation, I suggest going all the
   way and using something which is intended to be used as a source for
   multiple formats (at least HTML and nroff, with one or more of TeX,
   PDF and PostScript as options), e.g. DocBook.
  
  Right-- this was the thought, although block-level CSS seemed like a middle 
  ground. 
  
  I am not familiar with DocBook, but here is a good start:
  http://en.wikipedia.org/wiki/DocBook
  
  There is a Debian package called 'docbook-defguide' which looks like it 
  contains much good information, saved (on my system) here:
  /usr/share/doc/docbook-defguide/html/docbook.html
  
  It would be nice to have the option of converting the base manual into 
  one's 
  favorite format: Man pages, HTML, LateX, PDF, etc.
  
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Python Tcl/Tk

[Jachym Cepicky]

Hi,

it should be enough.

Try to adjust GRASS_WISH environment variable in grass63.bat

jachym

Marco Pasetti píše v Po 25. 02. 2008 v 22:42 +0100:
 Hi all,
 
 I just installed Python 2.51 for Windows, and I noticed that it contains
 Tcl/Tk... Is it all we need for GRASS or do I need to install also
 Activestate Tcl?
 
 Thanks
 
 Marco
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS-user] V.extrude... confused

[Jachym Cepicky]

Hi,

some examples are there, only thing, which is missing is link to nviz
manual page.

the entire chain consist out of two commands:

v.extrude ... out=buildings
nviz elev=dem vect=buildings

jachym

Moritz Lennert píše v Čt 21. 02. 2008 v 13:39 +0100:
 On 13/02/08 22:31, Markus Neteler wrote:
  On Feb 13, 2008 10:06 PM, Michael Barton [EMAIL PROTECTED] wrote:
  On Feb 13, 2008, at 1:45 PM, Sampson, David wrote:
  ...
  I guess I was expecting to see a 3D object afterwords. I have to
  turn on faces to see anything and still I only see lines.
 
  Do I have to view this in nVIZ?
  
  Yes. In the GRASS monitor you only see (naturally) 2D.
  
  I used 30 and 300 for the height values but I still see nothing.
 
  Does anyone have more experience using the v.extrude?
  AFAIK, you need to use NVIZ to see 2.5/3D.
  
  Yes. For example:
  http://grass.osgeo.org/screenshots/vector.php
 
 
 Would it be possible to add the recipes for some of these screenshots, 
 i.e. the entire chain of commands from v.extrude to the final 
 3D-Display, either to the screenshots page or for one example to the 
 v.extrude page ?
 
 Moritz
 ___
 grass-user mailing list
 [EMAIL PROTECTED]
 http://lists.osgeo.org/mailman/listinfo/grass-user
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-user] Re: [GRASS-dev] GRASS 6.3.0RC5 released

[Jachym Cepicky]

Hi,

Moritz Lennert píše v Čt 21. 02. 2008 v 00:25 +0100:
 On Tue, February 19, 2008 22:23, Markus Neteler wrote:
   A fifth release candidate of GRASS 6.3.0 is now available:
 
 I have just uploaded the windows port of RC5 to the usual place [1].
 
 I have also updated the wingrass status page [2] of the wiki to add some
 Todo's. Anyone willing to help, especially for creating the necessary
 libraries to allow compiling GRASS with some additional features (tiff
 support, internationalisation, etc) is more than welcome, as my time for
 GRASS is currently quite limited, unfortunately.

I have tested it a bit, worked with Tcl 8.5 like a charm  - great work!
This was mi first time, to see GRASS running at MS Windows - Wow ;-)

Jachym

 
 Moritz
 
 [1] http://geog-pc40.ulb.ac.be/grass/wingrass/
 [2] http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status
 
 ___
 grass-user mailing list
 [EMAIL PROTECTED]
 http://lists.osgeo.org/mailman/listinfo/grass-user
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] V.extrude... confused

[Jachym Cepicky]

Hi,

strange, I just tried out under Linux, works fine :-/ The vector map you
want to produce seems to be created anyway.

Maybe adding  

G_percent(nelements, nelements, 1);

at the end of the module would help?

Jachym

Sampson, David píše v Út 12. 02. 2008 v 15:57 -0500:
 Hey folks.
 
 I want to make a 3d map of canada where each province is extruded base
 don certain values.  My provinces shape looked like it was being
 hassled so I thought ok, keep it simple.
 
 1. created a small shape in the digitizer 
 2. v.extrude the vector with a single element 
 3. used 30 as my height
 
 v.extrude [EMAIL PROTECTED] output=Ontario3D zshift=0 height=30
 type=point,line,boundary,area layer=1
 
 And it just hangs (output bellow).
 
 The green bar does not complete.
 
 I am using wingrass 6.3 cvs
 
 And as I'm in windows the v.extrude process is still running. When I
 kill the single process the whole GRASS session dies
 
 
 
 
 This is the output: 
 - 
 0 areas built  
 0 isles built 
 Attaching islands: 
 Attaching centroids: 
 
 Topology was built. 
 Number of nodes :   19790 
 Number of primitives:   20075 
 Number of points:   0 
 Number of lines :   0 
 Number of boundaries:   0
 
 Building topology ... 
 Registering lines:1000   2000   3000
 4000   5000   6000   7000   8000
 9000  1  11000  12000  13000
 14000  15000  16000  17000  18000
 19000  2
 
 20075 primitives registered  
 Building areas: 
 Number of centroids :   0 
 Number of faces :   20017 
 Number of kernels   :   58 
 Number of areas :   0 
 Number of isles :   0
 
 ___
 grass-user mailing list
 [EMAIL PROTECTED]
 http://lists.osgeo.org/mailman/listinfo/grass-user


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.los diff between grass 6.2 and 6.3

[Jachym Cepicky]

Hi,

is it possible, that r.los returns different outputs in GRASS 6.2(.3)
and 6.3 ? Which one is the right one? 

Sample data: 
http://www.bnhelp.cz//cgi-bin/mapserv?map=/var/www/projects/sazp/mapserv/sazp.mapamp;service=WCSamp;request=getCoverageamp;crs=epsg:102067amp;coverage=demamp;resx=80amp;resy=80amp;width=500amp;height=500amp;format=image/tiff16amp;bbox=-360301.0595739889,-1208912.828415709,-320301.0595739889,-1168912.828415709

r.los in=dem out=vis2 coordi=-340301.0595739889,-1188912.828415709
obs=1.5

produced outputs: 
GRASS 6.2 http://les-ejk.cz/tmp/vis1.png
GRASS 6.3 http://les-ejk.cz/tmp/vis1.png

jachym

-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://www.bnhelp.cz http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
 _  _ ___ ___  ___ 
| || / __|___| _ \/ __|
| __ \__ \___|   /\__ \
|_||_|___/   |_|_\|___/


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new digitization tool compilation

[Jachym Cepicky]

Hi,

I try to compile new wx v.digit, however without success:

make
[...]
c++ -c -c -fpic
-I/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include
-I/usr/include/python2.5 `wx-config --cxxflags`
grass6_wxvdigit_wrap.cxx -o OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o
In file included
from 
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,

from 
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
 from grass6_wxvdigit_wrap.cxx:2579:
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:22:21:
 error: ogr_api.h: No such file or directory
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:170:
 error: ‘OGRDataSourceH’ does not name a type
[...]

the ogr_api.h is in /usr/include/gdal/ 

what to do?

thanks

jachym
-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://www.bnhelp.cz http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
 _  _ ___ ___  ___ 
| || / __|___| _ \/ __|
| __ \__ \___|   /\__ \
|_||_|___/   |_|_\|___/


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new digitization tool compilation

[Jachym Cepicky]

Hi,

I try to compile new wx v.digit, however without success:

make
[...]
c++ -c -c -fpic
-I/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include
-I/usr/include/python2.5 `wx-config --cxxflags`
grass6_wxvdigit_wrap.cxx -o OBJ.i686-pc-linux-gnu/grass6_wxvdigit_wrap.o
In file included
from 
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,

from 
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
 from grass6_wxvdigit_wrap.cxx:2579:
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:22:21:
 error: ogr_api.h: No such file or directory
/home/jachym/src/grass/grass_trunk/dist.i686-pc-linux-gnu/include/grass/vect/dig_structs.h:170:
 error: ‘OGRDataSourceH’ does not name a type
[...]

the ogr_api.h is in /usr/include/gdal/ 

what to do?

thanks

jachym
-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Scripting programming: directory structure of GRASS

[Jachym Cepicky]

Hi,

http://grass.osgeo.org/grass63/manuals/html63_user/variables.html#enviro

GRASS_ADDON_PATH 
[grass startup script] 
  allows to specify additional paths to local GRASS modules extra to
standard distribution.

so, if you set $GRASS_ADDON_PATH (e.g. in ~/.grass.bashrc) and put your
program there, it should work

jachym

roberto.marzocchi píše v Pá 01. 02. 2008 v 16:30 +0100:
 Hi,
 I'm writing a script for Grass.
 I've a problem with the directory structure of GRASS.
 
 I know where is the place of script: ($GISBASE/scripts).
 But my script  use some fortran-codes, I compile
 this codes with gfortran, and I don't know where's the correct directory
 for the executable compiled.
 
 Thank in advanced!
 
 Roberto
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] v.coordinate.sh - improve this script?

[Jachym Cepicky]

Hi,

Luca Casagrande píše v Pá 25. 01. 2008 v 13:34 +0100:

 Hi Michael,
 
 I have started studying python more deeper for using it in pyWPS 

cool, we need more people :-) We have to move to WPS 1.0.0, so I'm
looking forward to see your code ;-)

 and
 for creating new Qgis modules (with QT).
 Just for knowing, is there any reason for using wxWindow instead of Qt
 for the new GUI?
 is it a matter of license?
 
 Thank you very much
 
 Luca

As others were mentioning before me, it was discussed several times ago.
When I started to experiment with Python GUI in GRASS, I took Gtk,
because of I simply liked it. Then Michael started to experiment, mainly
on Mac OS and wxWidgets seemed the best choice for him. Others were not
complaining. When we asked around, how the best approach should be, we
were told to use Java :-(

Maybe next GRASS GUI will be Qt :-) But the current (wxWidgets-based)
should be here at least as long, as the Tcl/Tk was.

Just my 2 cents

Jachym

-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.los segfaulting x86_64

[Jachym Cepicky]

Hi, I just compiled grass 63-cvs and tried to run r.los module only
think I get is 

GRASS 6.3.cvs (spearfish60):~  r.los input=elevation.dem out=tmp
coordinate=603336,4925505.75 obs_elev=1.8
WARNING: Segment_format: Illegal seek
Segmentation fault
GRASS 6.3.cvs (spearfish60):~  


When I try the debugger (not sure, what I'm doing), I get:

Starting program: /usr/local/grass-6.3.cvs/bin/r.los input=elevation.dem
out=tmp coordinate=603336,4925505.75 obs_elev=1.8
WARNING: Segment_format: Illegal seek

Program received signal SIGSEGV, Segmentation fault.
0x2b71ce0c034a in segment_pagein (SEG=0x7fffdcb00080, n=0) at
pagein.c:46
46  if (n == SEG-scb[SEG-cur].n)
(gdb) bt
#0  0x2b71ce0c034a in segment_pagein (SEG=0x7fffdcb00080, n=0)
at pagein.c:46
#1  0x2b71ce0c05cd in segment_put (SEG=0x7fffdcb00080,
buf=0x7fffdcafe9a4, 
row=value optimized out, col=value optimized out) at put.c:48
#2  0x00401c8e in delete (PT_TO_DELETE=0x5e07a0, head=0x507790, 
seg_out_p=0x0, row_viewpt=0, col_viewpt=-592451212) at delete.c:32
#3  0x0040304f in hidden_point_elimination (head=0x507790, 
viewpt_elev=1329, seg_in_p=0x7fffdcb000c0,
seg_out_p=0x7fffdcb00080, 
seg_patt_p=0x7fffdcb00040, quadrant=1, sign_on_y=1, sign_on_x=1, 
row_viewpt=83, col_viewpt=445, patt_flag=0) at pts_elim.c:189
#4  0x0040243f in main (argc=value optimized out, 
argv=value optimized out) at main.c:322


any hint what to do?

Thanks

jachym
-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: new screenshots of wxPython GUI

[Jachym Cepicky]

Hi,
the screenshots are cool! Thanks for the great work!

Jachym

Michael Barton píše v So 01. 12. 2007 v 13:23 -0700:
 Hamish,
 
 
 I just posted a series of new screenshots for the new wxPython GUI to 
 
 
 http://www.public.asu.edu/~cmbarton/files/grass_screenshots/wxGUI_screenshots_2007-12-1.zip
 
 
 You might find a few worth putting in your new, nice screenshot pages.
 
 
 Michael
 
 
 
 C. Michael Barton, Professor of Anthropology
 
 Director of Graduate Studies
 
 School of Human Evolution  Social Change
 
 Center for Social Dynamics  Complexity
 
 Arizona State University
 
 
 Phone: 480-965-6262
 
 Fax: 480-965-7671
 
 www: www.public.asu.edu/~cmbarton
 
 
 
 
 
-- 
Jachym Cepicky
e-mail: [EMAIL PROTECTED]
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev