Re: [GRASS-dev] Introduction for GSoC 2017

[Yann Chemin]

thanks for the constant feed back Zofie, was not possible to make it work
without you guys testing it.
yann

On Aug 6, 2017 12:40 PM, "Stefan Blumentrath" 
wrote:

> Hi again,
>
>
>
> Zofie tested the orthorectification suite in GRASS 7 and just confirmed
> that it works as expected!
>
> Thanks so much, Yann! For me this was the last missing feature for
> completely moving to GRASS 7!
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
> *From:* grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] *On Behalf
> Of *Blumentrath, Stefan
> *Sent:* tirsdag 21. mars 2017 08.05
> *To:* Yann Chemin ; Luca Delucchi <
> lucadel...@gmail.com>
> *Cc:* GRASS-dev ; Manan Singh <
> mananpa...@gmail.com>
> *Subject:* Re: [GRASS-dev] Introduction for GSoC 2017
>
>
>
> Hi Yann,
>
>
>
> Thanks so much! Very cool!
>
> I will test the photo2image GUI tool ASAP!
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Yann Chemin [mailto:dr.yann.che...@gmail.com
> ]
> *Sent:* tirsdag 21. mars 2017 07.56
> *To:* Luca Delucchi 
> *Cc:* GRASS-dev ; Manan Singh <
> mananpa...@gmail.com>; Blumentrath, Stefan 
> *Subject:* Re: [GRASS-dev] Introduction for GSoC 2017
>
>
>
> Hi all,
>
> I have added to SVN trunk one of the two missing gui modules of
> i.ortho.photo recently: g.gui.iphoto2image at the command line launches it.
> All other modules but one are operational (still not fully tested though),
> I have already started working on the last one, which is also GUI based.
>
> Cheers,
> Yann
>
>
>
> On Mar 20, 2017 5:25 PM, "Luca Delucchi"  wrote:
>
> On 18 March 2017 at 08:30, Blumentrath, Stefan
>  wrote:
> > Hi,
> >
>
> Hi,
>
> >
> > Could also porting (competition) of the i.ortho.photo modules (and here
> > especially the missing GUI modules around it) to GRASS 7 become scope of
> > this GSoC idea?
> >
>
> I fully support this idea, GUI for i.ortho.photo is the most important
> loss from GRASS 6
>
> >
> >
> > Cheers,
> >
> > Stefan
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 10 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the tenth report of my GSoC project - SOS tools in GRASS GIS. You
can see my project at wiki at [1]

What did you get done this week?

r.in.sos
* flag for deleting vector maps created as intermediates
   main commits: [2]
* importing vectors and values in one step
   main commits: [3]
v.in.sos
* importing vectors and values in one step
   main commits: [4]
All modules
* not stop when using just -g flag
   main commits: [5]
* code cleaning and manuals updates
A little pull request for istSOS
* allow user to define offering in csv2istsos
   main commits: [6]

What do you plan on doing next week?

* I hope that me, Luca and Pietro will solve somehow a problem with layers
in pygrass (if possible, I would like to rewrite t.vect.in.sos and v.in.sos
to support layers)
* t.rast.in.sos

Are you blocked on anything?

* Yes. I am blocked on an unexpected behaviour of Vector and VectorTopo
classes in pyGRASS. We are trying to solve it and we have contacted also
Pietro Zambelli, so I hope in a good ending. Due to this I am little bit in
delay, but I have a little buffer in my timeline and I have some sketches
of future code for t.rast.in.sos, so I hope that it will be quick after
solving those problems.

Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/ed75568b96dc85c7938828dbfb21ff01e478ddcc
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/9cad14e47a827f2dbf3cf2212fc56fc595695c09
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/2505c2a50f0e0aefa2e5252c112a91ace629246e
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/5f4edf66341714225bd91c7df6810c1a9412fc59
[6] https://github.com/istSOS/istsos2/pull/19
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

[Michael Barton]

Fixed the nviz/3D issue by resetting GRASS_PYTHON to 
/Applications/anaconda/bin/pythonw

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















On Aug 6, 2017, at 2:02 PM, Michael Barton 
> wrote:

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the following message:

/Applications/anaconda/bin/pythonw: line 3: 13209 Segmentation fault: 11  
/Applications/anaconda/python.app/Contents/MacOS/python "$@"


Michael


C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















On Aug 5, 2017, at 8:25 PM, Michael Barton 
> wrote:

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).


But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"


It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael


 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no
checking for f2c.h... no
checking for g2c.h... no
checking for sys/ioctl.h... yes
checking for sys/mtio.h... no
checking for sys/resource.h... yes
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for sys/types.h... yes
checking for sys/utsname.h... yes
checking for libintl.h... yes
checking for iconv.h... yes
checking for langinfo.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for off_t... yes
checking for uid_t in sys/types.h... yes
checking return type of signal handlers... void
checking for Cygwin environment... no
checking for ftime... yes
checking for gethostname... yes
checking 

Re: [GRASS-dev] New attempt to update GRASS for Mac

[Michael Barton]

I have built both GRASS 7.3 and 7.2svn without errors using Anaconda 
dependencies if I configure --without-cairo and --without-freetype.

When I install GRASS and launch it, first it hangs and time outs at

Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...

Then the GUI crashes badly (with most GRASS functions unavailable from the 
command line also). However, I discovered that if I manually set

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH"

in the GRASS terminal, and relaunch the GUI, it works--although without Cairo 
and Freetype. Also, 3D crashes with the following message:

/Applications/anaconda/bin/pythonw: line 3: 13209 Segmentation fault: 11  
/Applications/anaconda/python.app/Contents/MacOS/python "$@"


Michael


C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















On Aug 5, 2017, at 8:25 PM, Michael Barton 
> wrote:

To GRASS devs:

When I configure with paths to anaconda cairo and freetype dependencies, I get 
no errors (see below).


But when I check the configure.log, I see the same error I'm getting at the end 
of a failed build:

Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _main in conftest-6b4e8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4775 "configure"


It seems that configure output is not correct?

Indeed the checking for iconv begins at line 4775. Unfortunately, I cannot 
decipher what it is doing or which version of iconv it is checking (the Mac 
system one in /usr/lib or the one in anaconda).

Additionally, AFAICT, both versions of iconv that I have are 64bit. How can I 
"use -v to see invocation"?

Thanks
Michael


 configure output to shell ==

checking host system type... x86_64-apple-darwin16.7.0
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking for full floating-point support... yes
checking for pwd... /bin/pwd
checking for source directory... /Users/cmbarton/grass_source/trunk
checking for build directory... /Users/cmbarton/grass_source/trunk
checking for svnversion... /opt/subversion/bin/svnversion
checking for MacOSX App... yes
checking for MacOSX architectures... no
checking for MacOSX SDK... checking for 
/Developer/SDKs/MacOSX10.8.sdk/SDKSettings.plist... yes
checking how to build libraries... shared
checking for additional include dirs...
checking for additional library dirs...
checking for a BSD compatible install... /usr/bin/install -c
checking for flex... flex
checking for yywrap in -lfl... no
checking for bison... bison -y
checking for ranlib... ranlib
checking for ar... ar
checking for env... env
checking for perl... /usr/bin/perl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for limits.h... yes
checking for termio.h... no
checking for termios.h... yes
checking for unistd.h... yes
checking for values.h... no
checking for f2c.h... no
checking for g2c.h... no
checking for sys/ioctl.h... yes
checking for sys/mtio.h... no
checking for sys/resource.h... yes
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for sys/types.h... yes
checking for sys/utsname.h... yes
checking for libintl.h... yes
checking for iconv.h... yes
checking for langinfo.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for off_t... yes
checking for uid_t in sys/types.h... yes
checking return type of signal handlers... void
checking for Cygwin environment... no
checking for ftime... yes
checking for gethostname... yes
checking for gettimeofday... yes
checking for lseek... yes
checking for nice... yes
checking for time... yes
checking for uname... yes
checking for seteuid... yes
checking for setpriority... yes
checking for setreuid... yes
checking for setruid... yes
checking for drand48... yes
checking for putenv... yes
checking for setenv... yes
checking for nanosleep... yes
checking whether setpgrp takes no argument... yes
checking for long long int... yes
checking for W11... no
checking for X... no
checking for library containing cuserid... no
checking for asprintf... yes
checking for atan... yes
checking for dlsym... yes
checking for iconv... no
checking for iconv in 

Re: [GRASS-dev] Introduction for GSoC 2017

[Stefan Blumentrath]

Hi again,

Zofie tested the orthorectification suite in GRASS 7 and just confirmed that it 
works as expected!
Thanks so much, Yann! For me this was the last missing feature for completely 
moving to GRASS 7!

Cheers
Stefan


From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: tirsdag 21. mars 2017 08.05
To: Yann Chemin ; Luca Delucchi 
Cc: GRASS-dev ; Manan Singh 
Subject: Re: [GRASS-dev] Introduction for GSoC 2017

Hi Yann,

Thanks so much! Very cool!
I will test the photo2image GUI tool ASAP!

Cheers
Stefan

From: Yann Chemin [mailto:dr.yann.che...@gmail.com]
Sent: tirsdag 21. mars 2017 07.56
To: Luca Delucchi >
Cc: GRASS-dev >; 
Manan Singh >; Blumentrath, 
Stefan >
Subject: Re: [GRASS-dev] Introduction for GSoC 2017


Hi all,

I have added to SVN trunk one of the two missing gui modules of i.ortho.photo 
recently: g.gui.iphoto2image at the command line launches it. All other modules 
but one are operational (still not fully tested though), I have already started 
working on the last one, which is also GUI based.

Cheers,
Yann

On Mar 20, 2017 5:25 PM, "Luca Delucchi" 
> wrote:
On 18 March 2017 at 08:30, Blumentrath, Stefan
> wrote:
> Hi,
>

Hi,

>
> Could also porting (competition) of the i.ortho.photo modules (and here
> especially the missing GUI modules around it) to GRASS 7 become scope of
> this GSoC idea?
>

I fully support this idea, GUI for i.ortho.photo is the most important
loss from GRASS 6

>
>
> Cheers,
>
> Stefan
>


--
ciao
Luca

www.lucadelu.org
___
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] Extract vector features from external PostGIS layer without building topology

[nik]

À Dimanche 6 août 2017, Martin Landa a écrit :
> Hi,
> 
> 2017-08-06 8:38 GMT+02:00 Nikos Alexandris :
> > I am looking for a confirmation that the following is _not_ possible:
> >
> > v.external -b input="PG:host=somehost user=someuser dbname=somepgdb"
> > layer=somemaplayer
> >
> > then
> > v.extract input=somemaplayer output=somemaplayer_extract where="some sql
> > query"
> 
> currently `v.extract` requires topology [1]. It would be possible to
> modify it in order to operate also on level 1 (no topology). At least
> for points it would make sense. For areas you always need topology
> built. Ma
> 
> [1] 
> https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.extract/main.c#L188
>

Than you Martin,
N
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Extract vector features from external PostGIS layer without building topology

[Martin Landa]

Hi,

2017-08-06 8:38 GMT+02:00 Nikos Alexandris :
> I am looking for a confirmation that the following is _not_ possible:
>
> v.external -b input="PG:host=somehost user=someuser dbname=somepgdb"
> layer=somemaplayer
>
> then
> v.extract input=somemaplayer output=somemaplayer_extract where="some sql
> query"

currently `v.extract` requires topology [1]. It would be possible to
modify it in order to operate also on level 1 (no topology). At least
for points it would make sense. For areas you always need topology
built. Ma

[1] 
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.extract/main.c#L188
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

[Helmut Kudrnovsky]

>checking for cairo.h... yes
>Package cairo was not found in the pkg-config search path.
>Perhaps you should add the directory containing `cairo.pc'
>to the PKG_CONFIG_PATH environment variable
>No package 'cairo' found
>checking for location of cairo library..

Does the suggestion? 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/New-attempt-to-update-GRASS-for-Mac-tp5328294p5330603.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Extract vector features from external PostGIS layer without building topology

[Nikos Alexandris]

Dear devs,

I am looking for a confirmation that the following is _not_ possible:

v.external -b input="PG:host=somehost user=someuser dbname=somepgdb" 
layer=somemaplayer

then 


v.extract input=somemaplayer output=somemaplayer_extract where="some sql query"

?

Building topology is required, here. Right?

Thank you, Nikos


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