[GRASS-dev] Broken: GRASS-GIS/grass-ci#2063 (master - d1513fe)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #2063
Status: Broken

Duration: 5 minutes and 16 seconds
Commit: d1513fe (master)
Author: Markus Metz
Message: vectorlib: enhance numerical stability for segment intersections

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70780 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/0821b82cfe23...d1513fe22542

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/213573800

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by mmetz):

 Replying to [comment:37 hcho]:
 > Yes, that's what I found too. Vect_line_intersection2 doesn't have this
 issue, but it still creates a single point intersection at the first
 vertex of the second new line (line ID 3) in the geojson example.
 >
 > Line ID 1: original unbroken line
 >
 > 1st iteration
 > Line ID 2-4: new broken lines
 >
 > 2nd iteration
 > Line ID 5: identical to line 3
 > Line ID 6: start node of line 3
 >
 > Lines 5 & 6 shouldn't be returned at all from the intersection routine,
 I think. The patch fixes this.

 Such an infinite loop in Vect_break_lines() has been observed previously
 and fixed back then in trunk r55796, r55813, r55848. Apparently, these
 commits did not solve all issues. It is most important that the
 intersection point of the same two segments is always the same, no matter
 which segment is a and which is b.

 Your patch might cause problems in special cases when an intersection
 point is not added to a line even if there are no vertices identical with
 the intersection point. That is, the line was not broken if it should have
 been. Therefore I would rather not apply your patch.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by neteler):

 Replying to [comment:35 hcho]:
 > Markus, you mean it does not hang with or without my patch?

 Due to lack of time I tried without your patch so far.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by mmetz):

 Replying to [comment:37 hcho]:
 > Yes, that's what I found too. Vect_line_intersection2 doesn't have this
 issue, but it still creates a single point intersection at the first
 vertex of the second new line (line ID 3) in the geojson example.
 >
 > Line ID 1: original unbroken line
 >
 > 1st iteration
 > Line ID 2-4: new broken lines
 >
 > 2nd iteration
 > Line ID 5: identical to line 3
 > Line ID 6: start node of line 3
 >
 > Lines 5 & 6 shouldn't be returned at all from the intersection routine,
 I think. The patch fixes this.

 I found another issue in Vect_segment_intersection(): the order of the
 segments matters, i.e. the intersection point of a with b can be slightly
 different from the intersection point of b with a. The second attached
 patch fixes that and also avoids that infinite loop. I opt to apply both
 patches.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Introduction for GSoC 2017

[Blumentrath, Stefan]

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] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+
Changes (by mmetz):

 * Attachment "intersect.c.patch2" added.

 patch for Vect_segment_intersection()

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by hcho):

 Yes, that's what I found too. Vect_line_intersection2 doesn't have this
 issue, but it still creates a single point intersection at the first
 vertex of the second new line (line ID 3) in the geojson example.

 Line ID 1: original unbroken line

 1st iteration
 Line ID 2-4: new broken lines

 2nd iteration
 Line ID 5: identical to line 3
 Line ID 6: start node of line 3

 Lines 5 & 6 shouldn't be returned at all from the intersection routine, I
 think. The patch fixes this.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by mmetz):

 Replying to [comment:34 neteler]:
 > Wow. After full recompilation, with gcc it does  NOT "hang":
 [...]
 >
 > So, unfortunate clang compiler settings before or gcc-is-better-than-
 clang here?

 No, the difference is -O2 which you used with gcc but not with clang. I
 could reproduce the problem by not using any optimization.

 The problem is that Vect_break_lines() enters an infinite loop because it
 continuously generates two new lines that are again intersecting each
 other, always at the same locations.

 The attached patch ([comment:31 hcho]) helps, but as mentioned in
 comment:31 there are more comparisons and it does not seem to be a good
 idea to allow tolerance at some places but not at other places when
 comparing a cross with a vertex.

 What also helps is using Vect_line_intersection2() instead of
 Vect_line_intersection(). Interestingly, Vect_line_intersection2() does
 not need the patch, even though that part of the code is identical.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by hcho):

 Markus, you mean it does not hang with or without my patch?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] new addon: i.variance

[Moritz Lennert]

Hi all,

FYI, I uploaded a simple new addon, i.variance [1], which calculates 
local variance in an image for successively degraded resolution in order 
to detect whether there are certain scales corresponding to specific, 
well-represented objects in that image. It is based on [2].


Enjoy !

Moritz

[1] https://grass.osgeo.org/grass72/manuals/addons/i.variance.html
[2] Curtis E. Woodcock, Alan H. Strahler, The factor of scale in remote 
sensing, Remote Sensing of Environment, Volume 21, Issue 3, April 1987, 
Pages 311-332, ISSN 0034-4257, 
http://dx.doi.org/10.1016/0034-4257(87)90015-0.



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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by neteler):

 Wow. After full recompilation, with gcc it does "hang":

 {{{
 ## gcc production
 INTEL="-march=native"
 MYGCC="-fdiagnostics-color"
 MYCFLAGS="-O2 $INTEL $MYGCC"
 MYCXXFLAGS="-O2"
 MYLDFLAGS="-Wl,--no-undefined"
 MYLDFLAGS="-s $MYLDFLAGS"

 # clang
 #CC=clang CXX=clang++ CFLAGS="-O2" CXXFLAGS="-O2" LDFLAGS="-s" ./configure
 \

 # gcc
 LDFLAGS="$MYLDFLAGS" CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS" ./configure
 \
   --with-cxx \
   --enable-largefile \
 ...
 }}}

 Now:

 {{{
 GRASS 7.2.1svn (latlong_wgs84):~ > time -p v.in.ogr
 in=world_AOI_latlong.geojson out=world_AOI_latlong --o
 ...
 -
 1 input polygons
 Total area: 2.37675E+13 (2 areas)
 Area without category: 2.04916E+11 (1 areas)
 -
 Copying features...
  100%
 Building topology for vector map ...
 Registering primitives...
 3 primitives registered
 19 vertices registered
 Building areas...
  100%
 2 areas built
 One isle built
 Attaching islands...
  100%
 Attaching centroids...
  100%
 Number of nodes: 1
 Number of primitives: 3
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 2
 Number of centroids: 1
 Number of areas: 2
 Number of isles: 1
 real 0.09
 user 0.04
 sys 0.01
 }}}

 So, unfortunate clang compiler settings before or gcc-is-better-than-clang
 here?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by neteler):

 In addition, here my compiler settings, maybe that makes a difference?

 {{{
 sh -x conf_grass7.sh
 + INTEL='-march=native -std=gnu99 -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
 -fstack-protector -m64'
 + MYGCC=-fdiagnostics-color
 + MYCFLAGS='-Wall -fopenmp -lgomp -Ofast -fno-fast-math -march=core-avx-i
 -fno-common -fexceptions -march=native -std=gnu99 -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector -m64 MYGCC'
 + MYLDFLAGS='-Wl,--no-undefined -fopenmp -lgomp'
 + MYCXXFLAGS=-Ofast
 + CC=clang
 + CXX=clang++
 + CFLAGS=-O2
 + CXXFLAGS=-O2
 + LDFLAGS=-s
 + ./configure --with-cxx --enable-largefile --with-proj --with-proj-
 share=/usr/share/proj --with-gdal=/usr/bin/gdal-config --with-python
 --with-geos --with-liblas --with-sqlite --with-nls --with-blas --with-
 blas-includes=/usr/include/atlas-x86_64-base/ --with-lapack --with-lapack-
 includes=/usr/include/atlas-x86_64-base/ --with-cairo --with-cairo-
 ldflags=-lfontconfig --with-freetype --with-freetype-
 includes=/usr/include/freetype2 --with-wxwidgets=/usr/bin/wx-config
 --with-fftw --with-motif --with-postgres --with-netcdf --without-mysql
 --without-odbc --without-openmp --without-ffmpeg
 + tee config_log.txt
 checking host system type... x86_64-pc-linux-gnu
 checking for gcc... clang
 checking whether the C compiler (clang -O2 -s) works... yes
 checking whether the C compiler (clang -O2 -s) is a cross-compiler... no
 checking whether we are using GNU C... yes
 ...

 # CPU:
 cat /proc/cpuinfo | grep 'model name'
 model name  : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
 ...
 }}}

 I'll switch to gcc and test again.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by hcho):

 Not sure if this patch would address the original issue though.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by hcho):

 Can you try this patch? The issue was that Vect_line_intersection would
 create breaks on first and last line vertices because there was no
 tolerance for comparing points. There are more such comparisons (potential
 issue?)...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+
Changes (by hcho):

 * Attachment "intersect.c.patch" added.

 lib/vector/Vlib/intersect.c.patch

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Fwd: GSoC : Students application period has started!

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo 
Date: Tue, Mar 21, 2017 at 8:56 AM
Subject: GSoC : Students application period has started!
To: OSGeo-SoC , OSGeo Discussions <
disc...@lists.osgeo.org>, geofor...@lists.osgeo.org


Dear All,

Yesterday students application period has started. We seek motivated
proactive students!

@Students: Start browsing the ideas page at [1] and carefully read the
recommendation for students, particularly the application instructions at
[2].
Quoting verbatim from Google Admins: "Historically, the students with the
best proposals reach out to the orgs early to receive feedback before
submitting their final proposal. " So don't wait until it is to late to
give you feedback, but instead join the communication channels of your
chosen software community and discuss over the proposal.

@Mentors: I see that there are still proposals with only 1 mentors. There
is still time to subscribe as a co-mentor, remember that we need at least 2
mentors otherwise the proposal will be discarded, no matter how good is the
student that applied for it. Furthermore, remember to offer small code
challenges to your would-be students, possibly in line with the purpose of
the gsoc proposal.

Let's rock!

*Please forward this email to your software communities*


[1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2017_Ideas
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_
Recommendations_for_Students#Application_instructions


-- 
Margherita Di Leo



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

Re: [GRASS-dev] [GRASS GIS] #2185: Painfully Slow 'v.in.ogr' Vector Import

[GRASS GIS]

#2185: Painfully Slow 'v.in.ogr' Vector Import
-+
  Reporter:  justinzane  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.6
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  import, OGR, performance, v.in.ogr
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by pvanbosgeo):

 Takes a long time on my computer as well, gets stuck at breaking
 boundaries. I am running 7.3.svn r70733 on Ubuntu 16.04. I don't normally
 have problems with importing much larger shapefiles.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Introduction for GSoC 2017

[Yann]

Hi Stefan,

please also launch the main menu: i.ortho.photo at the command line, it 
tends to be erratic.


(careful the i.photo.2target is not yet existing)

Ciao,
Yann



On 21/03/2017 08:04, Blumentrath, Stefan wrote:

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] Introduction for GSoC 2017

[Yann Chemin]

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