Re: [GRASS-dev] [GRASS GIS] #3226: v.select: how to handle situation where no features are found

[GRASS GIS]

#3226: v.select: how to handle situation where no features are found
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.select
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by lucadelu):

 Replying to [comment:1 mmetz]:

 >
 > I agree. If no features are selected, there should be no output map.
 This is particularly useful for automated processing, otherwise you would
 need to check if the output map contains any features at al. It is much
 simpler to check if the expected output map exists, granted that v.select
 finished successfully.

 +1

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Moritz Lennert]

Le 20 décembre 2016 23:39:09 GMT+01:00, Markus Metz 
 a écrit :
>On Tue, Dec 20, 2016 at 11:09 PM, Martin Landa 
>wrote:
>>
>> Hi,
>>
>> 2016-12-20 22:17 GMT+01:00 Markus Metz
>:
>> > I think the module is automatically compiled only if it is added to
>> > grass-addons/grass7/imagery/Makefile which it is not yet.
>>
>> no it's compiled automatically, see [1].
>
>OK. Then what is the reason for the existence of
>grass-addons/grass7/imagery/Makefile?
>
>> There is an compilation error. Ma
>>
>> [1]
>https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/i.superpixels.slic.log
>
>fmin needs to be replaced with a macro MIN as used by many other
>modules,
>maybe with a test for nan.

Simply using fmin (from math.h IIRC), does the job for me. Any reason not to 
use it ?

Moritz

>
>Markus M

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Markus Neteler]

On Dec 20, 2016 11:39 PM, "Markus Metz" 
wrote:
> On Tue, Dec 20, 2016 at 11:09 PM, Martin Landa 
wrote:
> > 2016-12-20 22:17 GMT+01:00 Markus Metz :
> > > I think the module is automatically compiled only if it is added to
> > > grass-addons/grass7/imagery/Makefile which it is not yet.
> >
> > no it's compiled automatically, see [1].

...automatically on windows which ignores the Makefile AFAIK.

> OK. Then what is the reason for the existence of
grass-addons/grass7/imagery/Makefile?

That's needed for the manual pages which are generated on the Linux based
Web server.

markusN

> > [1]
https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/i.superpixels.slic.log
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Markus Metz]

On Tue, Dec 20, 2016 at 11:09 PM, Martin Landa 
wrote:
>
> Hi,
>
> 2016-12-20 22:17 GMT+01:00 Markus Metz :
> > I think the module is automatically compiled only if it is added to
> > grass-addons/grass7/imagery/Makefile which it is not yet.
>
> no it's compiled automatically, see [1].

OK. Then what is the reason for the existence of
grass-addons/grass7/imagery/Makefile?

> There is an compilation error. Ma
>
> [1]
https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/i.superpixels.slic.log

fmin needs to be replaced with a macro MIN as used by many other modules,
maybe with a test for nan.

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:39 martinl]:
 > Replying to [comment:38 martinl]:
 >
 > > > Answer: msvcp100.dll is part of msvcrt package. Anyway executing of
 vcredist exe files need to silently fail also in 32bit platforms since
 these files are part of msvcrt2008 and msvcrt2010 packages which are not
 downloaded by the installer.
 > >
 > > Ah, I see. It's because msvcrt-12 (32bit) package contained also these
 binaries which is wrong. We need to fix this issue in the installer.
 >
 > First attempt done in r70106. The question is if we really need all of
 vcredist exe files. Till now no such file has been launched by 64bit
 installer. We appearently need vcredist2013 for las issue but do we really
 need other (2008,2010)? And what about 32bit platform?

 AFAIR some time ago there was a change by Microsoft how they distribute
 their runtimes. at some stage only the exe were available, thus the exec
 in the installer.

 AFAIU we haven't sync'ed the nsis installer with the upstream osgeo4w
 changes regarding MS runtimes.

 which vcredist.exe-versions are needed depends upon the dependencies built
 upon.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Martin Landa]

Hi,

2016-12-20 22:17 GMT+01:00 Markus Metz :
> I think the module is automatically compiled only if it is added to
> grass-addons/grass7/imagery/Makefile which it is not yet.

no it's compiled automatically, see [1]. There is an compilation error. Ma

[1] 
https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/i.superpixels.slic.log

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

Re: [GRASS-dev] v.cluster

[Markus Metz]

On Tue, Dec 6, 2016 at 10:07 PM, Paulo van Breugel 
wrote:
>
>
> On 06-12-16 20:01, Anna Petrášová wrote:
>>
>> On Tue, Dec 6, 2016 at 7:40 AM, Paulo van Breugel
>>  wrote:
>>>
>>> Hi devs,
>>>
>>> I am running GRASS 7.3 (R69890), and it seems the module v.cluster is
not
>>> available from the menu nor the Modules tab. Typing v.cluster on the
command
>>> line or in the Console will run the function fine though.
>>>
>>> One can still find it on
https://grass.osgeo.org/grass73/manuals/vector.html
>>> but it would be nice if it is at least discoverable from the Modules
tab. Or
>>> is this a problem with my install?
>>
>> no, nobody has put it there yet. What would be a good place? Vector -
>> Develop vector map? Or in the main vector menu?
>
> Good question, not sure. What about a separate category with modules for
point analysis? This category could include v.kcv and v.perturb (both do
not really generate new points, they are both about modifying existing
point) and perhaps v.distance and v.qcount? In any case, I don't think
'Develop vector map' is the right place, and perhaps good to avoid, where
possible, to have single items in the main menu?

I have added a new entry named "Point analysis" in the vector menu with
v.outlier, v.cluster, v.perturb, v.kcv in trunk and relbr72 (r70105,7).

Markus M

>
>
>>
>> Anna
>>
>>> Cheers,
>>>
>>> Paulo
>>>
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:38 martinl]:

 > > Answer: msvcp100.dll is part of msvcrt package. Anyway executing of
 vcredist exe files need to silently fail also in 32bit platforms since
 these files are part of msvcrt2008 and msvcrt2010 packages which are not
 downloaded by the installer.
 >
 > Ah, I see. It's because msvcrt-12 (32bit) package contained also these
 binaries which is wrong. We need to fix this issue in the installer.

 First attempt done in r70106. The question is if we really need all of
 vcredist exe files. Till now no such file has been launched by 64bit
 installer. We appearently need vcredist2013 for las issue but do we really
 need other (2008,2010)? And what about 32bit platform?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:37 martinl]:

 > Answer: msvcp100.dll is part of msvcrt package. Anyway executing of
 vcredist exe files need to silently fail also in 32bit platforms since
 these files are part of msvcrt2008 and msvcrt2010 packages which are not
 downloaded by the installer.

 Ah, I see. It's because msvcrt-12 (32bit) package contained also these
 binaries which is wrong. We need to fix this issue in the installer.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:36 martinl]:

 > Ah, I see, they are hardcoded for 32bit platform. The 64bit packages
 contains another files. I wonder how it could work till now for 64bit
 platform.

 Answer: msvcp100.dll is part of msvcrt package. Anyway executing of
 vcredist exe files need to silently fail also in 32bit platforms since
 these files are part of msvcrt2008 and msvcrt2010 packages which are not
 downloaded by the installer.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:35 martinl]:

 > They are not part of msvcrt, msvcrt2008 or msvcrt2010 packages (they
 contains similar files but with another name)

 Ah, I see, they are hardcoded for 32bit platform. The 64bit packages
 contains another files. I wonder how it could work till now for 64bit
 platform.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 I just wonder where these files come from

 {{{
 DetailPrint "Installing vcredist_2005_x86.exe ..."
 ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2005_x86.exe"
 /q'
 DetailPrint "Installing vcredist_2008_x86.exe ..."
 ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2008_x86.exe"
 /q'
 DetailPrint "Installing vcredist_2010_x86.exe ..."
 }}}

 They are not part of msvcrt, msvcrt2008 or msvcrt2010 packages (they
 contains similar files but with another name)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3226: v.select: how to handle situation where no features are found

[GRASS GIS]

#3226: v.select: how to handle situation where no features are found
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.select
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3226 mlennert]:
 > [...] In r70103 a patch was applied to trunk to count the number of
 features found and if that number = 0 then the user is informed and  no
 output map is created.
 >
 > However, Vaclav remarks:
 >
 > > Isn't an empty vector map an expected result in this case? What
 happens
 > > when you do this in GUI (where output is added automatically to Map
 > > Display)?
 >
 > I don't think that a module should output an empty map. But if you think
 that it should than we can change the patch.
 >
 > And yes, the output is automatically added even if it doesn't exist, but
 I would actually consider this a bug in the GUI, not of the module.

 I agree. If no features are selected, there should be no output map. This
 is particularly useful for automated processing, otherwise you would need
 to check if the output map contains any features at al. It is much simpler
 to check if the expected output map exists, granted that v.select finished
 successfully.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:32 martinl]:
 > Replying to [comment:30 martinl]:
 >
 > > Update: `las` package (64bit) has now new dependency - msvcrt2013. It
 means that this issue is fixed in OSGeo4W installer. It also means that we
 need to modify standalone installer to download msvcrt2013 manually.
 >
 > What be nice to modify installer to download and install both packages
 together.

 in https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-
 Installer.nsi.tmpl#L826

 {{{
 826 untar_ok:
 827 DetailPrint "Archive successfully unzipped."
 828 DetailPrint "Installing vcredist_2005_x86.exe ..."
 829 ExecWait
 '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2005_x86.exe" /q'
 830 DetailPrint "Installing vcredist_2008_x86.exe ..."
 831 ExecWait
 '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2008_x86.exe" /q'
 832 DetailPrint "Installing vcredist_2010_x86.exe ..."
 833 ExecWait
 '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2010_x86.exe" /q'
 834 DetailPrint "Copying runtime files ..."
 835 CopyFiles "$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\*.dll"
 "$INSTALL_DIR\extrabin"
 836 DetailPrint "MS runtime files installed."
 837 Goto end
 }}}

 does it mean that standalone installer should download

 {{{
 
http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/msvcrt2013/msvcrt2013-1.0.0-1.tar.bz2
 }}}

 unzip and untar it and then run

 {{{
 ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist-2013-x64.exe" /q'
 }}}

 ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Markus Metz]

On Tue, Dec 20, 2016 at 12:06 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> On 20/12/16 10:04, Markus Metz wrote:
>>
>> Thanks a lot for the implementation! Since this is work in progress, the
>> module could be moved from grass-addons to sandbox until the name and
>> options are fixed?
>
>
> I had suggested addons since this allows Windows users who do not have
the compilation chain installed to install it via g.extension for testing,
as addons are automatically compiled for Windows.

I think the module is automatically compiled only if it is added to
grass-addons/grass7/imagery/Makefile which it is not yet.
>
> But we can move it to sandbox if you think it is better, and teach the
windows users how to install the necessary tools for compilation...

OK, leave it where it is. Testing can begin once the module produces output
with superpixel (region) IDs for each pixel.

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:28 martinl]:
 > Replying to [comment:25 hellik]:
 >
 > > but it seems, it isn't downloaded by the standalone:
 >
 > standalone installer seems to be right, it downloads the metapackage.

 {{{
 852 !if ${PLATFORM} == "x86_64"
 853 StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-8.tar.bz2"
 854 !else
 855 StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-12.tar.bz2"
 856 !endif
 }}}

 at least for x86 we should pump up the version, see:

 {{{
 http://download.osgeo.org/osgeo4w/x86/release/msvcrt/msvcrt-1.0.1-13.tar.bz2
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:30 martinl]:

 > Update: `las` package (64bit) has now new dependency - msvcrt2013. It
 means that this issue is fixed in OSGeo4W installer. It also means that we
 need to modify standalone installer to download msvcrt2013 manually.

 What be nice to modify installer to download and install both packages
 together.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-
Changes (by martinl):

 * priority:  critical => blocker
 * milestone:  7.0.6 => 7.2.0


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:29 martinl]:

 > report in upstream, https://trac.osgeo.org/osgeo4w/ticket/520

 Update: `las` package (64bit) has now new dependency - msvcrt2013. It
 means that this issue is fixed in OSGeo4W installer. It also means that we
 need to modify standalone installer to download msvcrt2013 manually.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:28 martinl]:
 > standalone installer seems to be right, it downloads the metapackage.
 Problem is that this metapackage depends only on 2008 and 2010, see
 http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/setup.hint

 report on upstream, https://trac.osgeo.org/osgeo4w/ticket/520

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:25 hellik]:

 > but it seems, it isn't downloaded by the standalone:

 standalone installer seems to be right, it downloads the metapackage.
 Problem is that this metapackage depends only on 2008 and 2010, see
 http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/setup.hint

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:26 annakrat]:
 >
 > Regarding this second problem I described (which seems to be unrelated
 to the first one), I tested a different Windows machine and it worked
 there. So it's not easily reproducible,

 it seems to be related to an installed ​Visual C++ Redistributable
 Packages for Visual Studio 2013.

 it may or may not be installed on some computers, thus maybe the
 difference.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by annakrat):

 Replying to [comment:18 annakrat]:
 > Then I tested an older computer. Here nothing works, but it behaves
 differently. r.in.lidar starts, but then it says GRASS7 has stopped
 working. Copying those dlls does not help. I tested different grass
 versions, nothing works.

 Regarding this second problem I described (which seems to be unrelated to
 the first one), I tested a different Windows machine and it worked there.
 So it's not easily reproducible, but there is still some problem.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:24 hellik]:
 > Replying to [comment:23 hellik]:
 > > Replying to [comment:22 martinl]:
 > > > Replying to [comment:19 martinl]:
 > > > > Replying to [comment:18 annakrat]:
 > > > > > I tested on 2 machines. First one is freshly installed Windows
 10 and r.in.lidar does not even start. Here it seems some of the needed
 dlls are missing. When running r.in.lidar from terminal, it says
 msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure
 system directory and copied them to extrabin and then everything works.
 > > > >
 > > > > standalone or osgeo4w installer. If standalone did you installed
 Microsoft Runtime Libs? Ma
 > > >
 > > > I tried to install fresh Windows 8.1 and install winGRASS720svn. I
 can confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.
 > >
 > > AFAIK it's Visual C++ 2013 Redistributable
 >
 > [https://www.microsoft.com/en-US/download/details.aspx?id=40784 Visual
 C++ Redistributable Packages for Visual Studio 2013 ]

 it's on the download server:

 [http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/msvcrt2013/
 /osgeo4w/x86_64/release/msvcrt/msvcrt2013]

 but it seems, it isn't downloaded by the standalone:

 see https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-
 Installer.nsi.tmpl#L843

 {{{
 843 Section "Important Microsoft Runtime DLLs" SecMSRuntime
 844
 845 ;Set the size (in KB)  of the archive file
 846 StrCpy $ARCHIVE_SIZE_KB 12521
 847
 848 ;Set the size (in KB) of the unpacked archive file
 849 AddSize 13500
 850
 851 StrCpy $HTTP_PATH
 "http://download.osgeo.org/osgeo4w/${PLATFORM}/release/msvcrt/;
 852 !if ${PLATFORM} == "x86_64"
 853 StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-8.tar.bz2"
 854 !else
 855 StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-12.tar.bz2"
 856 !endif
 857 StrCpy $EXTENDED_ARCHIVE_NAME "Microsoft Visual C++
 Redistributable Packages"
 858 StrCpy $ORIGINAL_UNTAR_FOLDER "install_msruntime"
 859
 860 Call DownloadInstallMSRuntime
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:23 hellik]:
 > Replying to [comment:22 martinl]:
 > > Replying to [comment:19 martinl]:
 > > > Replying to [comment:18 annakrat]:
 > > > > I tested on 2 machines. First one is freshly installed Windows 10
 and r.in.lidar does not even start. Here it seems some of the needed dlls
 are missing. When running r.in.lidar from terminal, it says msvcp120.dll
 and msvcr120.dll are missing. So I found them in some obscure system
 directory and copied them to extrabin and then everything works.
 > > >
 > > > standalone or osgeo4w installer. If standalone did you installed
 Microsoft Runtime Libs? Ma
 > >
 > > I tried to install fresh Windows 8.1 and install winGRASS720svn. I can
 confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.
 >
 > AFAIK it's Visual C++ 2013 Redistributable

 [https://www.microsoft.com/en-US/download/details.aspx?id=40784 Visual C++
 Redistributable Packages for Visual Studio 2013 ]

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:19 martinl]:
 > Replying to [comment:18 annakrat]:
 > > I tested on 2 machines. First one is freshly installed Windows 10 and
 r.in.lidar does not even start. Here it seems some of the needed dlls are
 missing. When running r.in.lidar from terminal, it says msvcp120.dll and
 msvcr120.dll are missing. So I found them in some obscure system directory
 and copied them to extrabin and then everything works.
 >
 > standalone or osgeo4w installer. If standalone did you installed
 Microsoft Runtime Libs? Ma

 I tried to install fresh Windows 8.1 and install winGRASS720svn. I can
 confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by hellik):

 Replying to [comment:18 annakrat]:
 > I tested on 2 machines. First one is freshly installed Windows 10 and
 r.in.lidar does not even start. Here it seems some of the needed dlls are
 missing. When running r.in.lidar from terminal, it says msvcp120.dll and
 msvcr120.dll are missing. So I found them in some obscure system directory
 and copied them to extrabin and then everything works.
 >
 > Then I tested an older computer. Here nothing works, but it behaves
 differently. r.in.lidar starts, but then it says GRASS7 has stopped
 working. Copying those dlls does not help. I tested different grass
 versions, nothing works.

 I've tested it on several windows boxes (7, 8,10); it works everywhere.

 could it be some kind of security issue by windows defender / av sw.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.select features without category skipped

[Moritz Lennert]

On 20/12/16 17:14, Vaclav Petras wrote:


On Tue, Dec 20, 2016 at 10:36 AM, Moritz Lennert
> wrote:

On 20/12/16 16:18, Luca Delucchi wrote:

On 20 December 2016 at 16:08, Moritz Lennert
> wrote:


You can go ahead and commit to trunk, unless someone
objects. At least this
way it gets some testing.


are you sure? you should submit it :-/


I had hoped to put the work on you... ;-)

But it's done: r70103.

But we should keep this in mind and observe whether this does not
cause any issues. Maybe open a ticket ?



Isn't an empty vector map an expected result in this case? What happens
when you do this in GUI (where output is added automatically to Map
Display)? Ticket might be appropriate.


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

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

[GRASS-dev] [GRASS GIS] #3226: v.select: how to handle situation where no features are found

[GRASS GIS]

#3226: v.select: how to handle situation where no features are found
-+-
 Reporter:  mlennert |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.1
Component:  Vector   |Version:  svn-trunk
 Keywords:  v.select |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Luca described the following scenario [https://lists.osgeo.org/pipermail
 /grass-dev/2016-November/083116.html [1]]:

 {{{
 g.region vect=zipcodes -ap

 v.mkgrid map=zipcodes_grid box=1,1

 v.category zipcodes_grid opt=report
 Layer/table: 1/zipcodes_grid
 type   countminmax
 point  0  0  0
 line   0  0  0
 boundary   0  0  0
 centroid  42  1 42
 area   0  0  0
 face   0  0  0
 kernel 0  0  0
 all   42  1 42

 v.select ain=zipcodes_grid bin=zipcodes operator=touches
 out=zipcodes_grid_final --o
 WARNING: Vector map  already exists and will be
  overwritten
 Processing features...
  100%
 Processing areas...
  100%
 Writing selected features...
  100%
 Writing attributes...
 WARNING: Array of values to select from column  is empty
 WARNING: Unable to copy table for layer 1
 DBMI-SQLite driver error:
 Unable to create index:
 create unique index  if not exists zipcodes_grid_final_cat on
 zipcodes_grid_final ( cat )
 no such table: main.zipcodes_grid_final

 DBMI-SQLite driver error:
 Unable to create index:
 create unique index  if not exists zipcodes_grid_final_cat on
 zipcodes_grid_final ( cat )
 no such table: main.zipcodes_grid_final

 WARNING: Unable to create index
 WARNING: 97 features from  without category skipped
 Building topology for vector map ...
 Registering primitives...
 0 primitives registered
 0 vertices registered
 Building areas...
  100%
 0 areas built
 0 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 0
 Number of primitives: 0
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 0
 Number of centroids: 0
 Number of areas: 0
 Number of isles: 0
 v.select complete. 0 features written to output.
 }}}

 I explained that with the operator 'touches', it is normal that no
 features were found. However, the error message was awkward. In r70103 a
 patch was applied to trunk to count the number of features found and if
 that number = 0 then the user is informed and  no output map is created.

 However, Vaclav remarks:

 > Isn't an empty vector map an expected result in this case? What happens
 > when you do this in GUI (where output is added automatically to Map
 > Display)?

 I don't think that a module should output an empty map. But if you think
 that it should than we can change the patch.

 And yes, the output is automatically added even if it doesn't exist, but I
 would actually consider this a bug in the GUI, not of the module.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.select features without category skipped

[Vaclav Petras]

On Tue, Dec 20, 2016 at 10:36 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/12/16 16:18, Luca Delucchi wrote:
>
>> On 20 December 2016 at 16:08, Moritz Lennert
>>  wrote:
>>
>>
>>> You can go ahead and commit to trunk, unless someone objects. At least
>>> this
>>> way it gets some testing.
>>>
>>>
>> are you sure? you should submit it :-/
>>
>
> I had hoped to put the work on you... ;-)
>
> But it's done: r70103.
>
> But we should keep this in mind and observe whether this does not cause
> any issues. Maybe open a ticket ?



Isn't an empty vector map an expected result in this case? What happens
when you do this in GUI (where output is added automatically to Map
Display)? Ticket might be appropriate.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by annakrat):

 Replying to [comment:19 martinl]:
 > Replying to [comment:18 annakrat]:
 > > I tested on 2 machines. First one is freshly installed Windows 10 and
 r.in.lidar does not even start. Here it seems some of the needed dlls are
 missing. When running r.in.lidar from terminal, it says msvcp120.dll and
 msvcr120.dll are missing. So I found them in some obscure system directory
 and copied them to extrabin and then everything works.
 >
 > standalone or osgeo4w installer. If standalone did you installed
 Microsoft Runtime Libs? Ma

 both, yes I did

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 Replying to [comment:18 annakrat]:
 > I tested on 2 machines. First one is freshly installed Windows 10 and
 r.in.lidar does not even start. Here it seems some of the needed dlls are
 missing. When running r.in.lidar from terminal, it says msvcp120.dll and
 msvcr120.dll are missing. So I found them in some obscure system directory
 and copied them to extrabin and then everything works.

 standalone or osgeo4w installer. If standalone did you installed Microsoft
 Runtime Libs? Ma

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  critical|  Milestone:  7.0.6
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by annakrat):

 I tested on 2 machines. First one is freshly installed Windows 10 and
 r.in.lidar does not even start. Here it seems some of the needed dlls are
 missing. When running r.in.lidar from terminal, it says msvcp120.dll and
 msvcr120.dll are missing. So I found them in some obscure system directory
 and copied them to extrabin and then everything works.

 Then I tested an older computer. Here nothing works, but it behaves
 differently. r.in.lidar starts, but then it says GRASS7 has stopped
 working. Copying those dlls does not help. I tested different grass
 versions, nothing works.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.select features without category skipped

[Moritz Lennert]

On 20/12/16 16:18, Luca Delucchi wrote:

On 20 December 2016 at 16:08, Moritz Lennert
 wrote:



You can go ahead and commit to trunk, unless someone objects. At least this
way it gets some testing.



are you sure? you should submit it :-/


I had hoped to put the work on you... ;-)

But it's done: r70103.

But we should keep this in mind and observe whether this does not cause 
any issues. Maybe open a ticket ?


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

Re: [GRASS-dev] v.select features without category skipped

[Luca Delucchi]

On 20 December 2016 at 16:08, Moritz Lennert
 wrote:

>
> You can go ahead and commit to trunk, unless someone objects. At least this
> way it gets some testing.
>

are you sure? you should submit it :-/

> Moritz



-- 
ciao
Luca

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

Re: [GRASS-dev] v.select features without category skipped

[Luca Delucchi]

On 17 November 2016 at 18:38, Moritz Lennert
 wrote:
>
>
> Try the attached patch. Not very elegant and not well tested, but seems to
> work for me.
>

It work also for me (I tested in trunk) and I like it

> Moritz

-- 
ciao
Luca

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

Re: [GRASS-dev] v.select features without category skipped

[Moritz Lennert]

On 20/12/16 16:03, Luca Delucchi wrote:

On 17 November 2016 at 18:38, Moritz Lennert
 wrote:



Try the attached patch. Not very elegant and not well tested, but seems to
work for me.



It work also for me (I tested in trunk) and I like it


You can go ahead and commit to trunk, unless someone objects. At least 
this way it gets some testing.


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

Re: [GRASS-dev] v.select features without category skipped

[Luca Delucchi]

On 17 November 2016 at 18:06, Moritz Lennert
 wrote:
>
>
> i.e. no features found which is logical, as there are no zipcode areas that
> touch a grid area. 'touches' is normally defined as [1]
>
> "a touches b: they have at least one boundary point in common, but no
> interior points."
>
> Try with intersects, overlaps, etc.
>

yes with intersects it work as expected...

>
> Moritz
>


-- 
ciao
Luca

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Moritz Lennert]

On 20/12/16 10:04, Markus Metz wrote:

Thanks a lot for the implementation! Since this is work in progress, the
module could be moved from grass-addons to sandbox until the name and
options are fixed?


I had suggested addons since this allows Windows users who do not have 
the compilation chain installed to install it via g.extension for 
testing, as addons are automatically compiled for Windows.


But we can move it to sandbox if you think it is better, and teach the 
windows users how to install the necessary tools for compilation...


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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Rashad Kanavath]

On Tue, Dec 20, 2016 at 10:04 AM, Markus Metz  wrote:

>
>
> On Mon, Dec 19, 2016 at 6:02 PM, Rashad Kanavath <
> mohammedrasha...@gmail.com> wrote:
> >
> > Hello
> >
> > On Mon, Dec 19, 2016 at 5:30 PM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
> >>
> >> Hi Rashad,
> >>
> >> Another reflection: IIUC, in the current implementation all pixel
> values from all bands are read into memory. This can quickly become a
> limiting factor when working with very large images.
> >>
> >> For now we can work this way until the general algorithm is clear, but
> in the long run, I imagine that the segment library should be used to only
> load parts of the data at a time.
> >
> > I had asked this question myself :-).
> >  But then I don't know how to deal with large datasets in grass. I
> Couldn't find any method to allow streaming/tiled processing. That would be
> awesome!
> >
> > I look forward reply from MarkusM for this.
>
> We can use some methods from i.segment to handle large datasets, i.e.
> using the segment library, adding a memory option etc. Also keeping track
> of superpixel characteristics can be adopted from keeping track of region
> properties in the region growing algorithm.
>
> About RGB or LAB, I agree with Moritz that this does not matter, instead
> it is more important that any number of bands can be used as input, and any
> kind of data, e.g. mixing vegetation indices with spectral bands.
>


>
> Thanks a lot for the implementation! Since this is work in progress, the
> module could be moved from grass-addons to sandbox until the name and
> options are fixed?
>

How do I move the code to sandbox.?

>
> Markus M
>
>
> >
> > Thanks again.
> >
> >>
> >> Maybe MarkusM help us with that ?
> >>
> >> Moritz
> >>
> >>
> >> On 19/12/16 16:05, Moritz Lennert wrote:
> >>>
> >>> On 19/12/16 09:38, Rashad Kanavath wrote:
> 
> 
> 
>  On Sun, Dec 18, 2016 at 2:53 PM, Moritz Lennert
>  >
> wrote:
> 
>  On 18/12/16 14:01, Rashad Kanavath wrote:
> 
>  Hello,
> 
>  As promised, I had pushed code to G7 addons repo
> 
>  https://trac.osgeo.org/grass/browser/grass-addons/grass7/ima
> gery/i.superpixels.slic
>   agery/i.superpixels.slic>
>   agery/i.superpixels.slic
>   agery/i.superpixels.slic>>
> 
> 
>  Great job, thanks a lot !
> 
> 
>  I had tested with some small datasets and is working.
> 
>  More testing welcome :)
> 
> 
>  I get the following warning during installation:
> 
>  main.c: In function ‘main’:
>  main.c:514:13: warning: implicit declaration of function ‘min’
>  [-Wimplicit-function-declaration]
>   seedx = min(g_width-1,seedx);
>   ^~~
> 
>  I think you have to explicitely define min() through a macro, or
>  AFAIK you can use fmin() as elsewhere in the code.
> 
> 
>  I will push a fix for that.
> >>>
> >>>
> >>> Thanks, but your fix creates another error:
> >>>
> >>> main.c: In function ‘main’:
> >>> main.c:514:18: error: expected expression before ‘double’
> >>>   seedx = fmin(double (g_width-1), seedx);
> >>>^~
> >>> main.c:514:13: error: too few arguments to function ‘fmin’
> >>>   seedx = fmin(double (g_width-1), seedx);
> >>>   ^~~~
> >>> In file included from /usr/include/features.h:364:0,
> >>>   from /usr/include/stdio.h:27,
> >>>   from main.c:21:
> >>> /usr/include/x86_64-linux-gnu/bits/mathcalls.h:360:1: note: declared
> here
> >>>   __MATHCALLX (fmin,, (_Mdouble_ __x, _Mdouble_ __y), (__const__));
> >>>   ^
> >>> make: *** [OBJ.x86_64-pc-linux-gnu/main.o] Erreur 1
> >>>
> >>> as 'double' is not a function, so double(g_width-1)) doesn't make
> sense.
> >>>
> >>> If you want to cast g_width-1 to double before submitting it to fmin(),
> >>> then AFAIK this would have to be:
> >>>
> >>> seedx = fmin ((double) (g_width-1), seedx)
> >>>
> >>> However, again AFAIK, this type conversion is done implicitely anyhow,
> >>> so you can just write:
> >>>
> >>> seedx = fmin (g_width-1, seedx)
> >>>
> >>>
> 
> 
>  Also:
> 
>  - The output as it is now is not very useful. What we would need
> is
>  a map with each pixel containing the label of the superpixel it
>  belongs to. In the original code, there are both outputs: i) an
>  image of the superpixel limits overlayed over the original image,
>  ii) the labeled pixels
> 
> 
>  you need contour segments as seperate output and also the current one.
> 

Re: [GRASS-dev] [release planning] 7.2.0

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Sun, Dec 18, 2016 at 9:39 PM, Anna Petrášová 

> kratochanna@

>  wrote:
>> On Sat, Dec 17, 2016 at 9:59 AM, Martin Landa 

> landa.martin@

>  wrote:
>>> Hi,
>>>
>>> 2016-12-10 20:00 GMT+01:00 Vaclav Petras 

> wenzeslaus@

> :

 Yes, that's it. Do you know how/where to push it upstream/downstream,
 so
 that the right people look at it? It seemed that it is fixed at one
 point,
 but the same behavior is back now.
>>>
>>> I tested various winGRASS versions on my Windows machine and most of
>>> them worked [1]. I lost track what version of GRASS is not working
>>> you? Ma
>>>
>>
>> No version was working for me. The weird thing is it worked for one
>> student (I tested it myself on his computer), but for many other
>> students it failed. So I tested different versions on freshly
>> installed Windows 10 in Virtual Box on linux and nothing worked. This
>> was couple weeks back, I can test again this week.
> 
> Shall I wait with the release or just get it out?
> 
> Markus
> 
>> Anna
>>
>>> [1] https://trac.osgeo.org/grass/ticket/2996#comment:17
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

tested here on some windows boxes; it works for me.

I may opt for release. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/release-planning-7-2-0-tp5298469p5300596.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3213: v.net.iso - Segmentation fault

[GRASS GIS]

#3213: v.net.iso - Segmentation fault
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.2.0
 Component:  LibVector|Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mmetz):

 Replying to [comment:4 sebastic]:
 > Confirmed fixed with the changes from r69951 which have been included as
 a patch in the Debian package.

 For the record: the exact same segfault happens with Fedora 25 and with
 RHEL 7 + devtoolset-6. All use gcc-6.2.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

[Markus Metz]

On Mon, Dec 19, 2016 at 6:02 PM, Rashad Kanavath 
wrote:
>
> Hello
>
> On Mon, Dec 19, 2016 at 5:30 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>> Hi Rashad,
>>
>> Another reflection: IIUC, in the current implementation all pixel values
from all bands are read into memory. This can quickly become a limiting
factor when working with very large images.
>>
>> For now we can work this way until the general algorithm is clear, but
in the long run, I imagine that the segment library should be used to only
load parts of the data at a time.
>
> I had asked this question myself :-).
>  But then I don't know how to deal with large datasets in grass. I
Couldn't find any method to allow streaming/tiled processing. That would be
awesome!
>
> I look forward reply from MarkusM for this.

We can use some methods from i.segment to handle large datasets, i.e. using
the segment library, adding a memory option etc. Also keeping track of
superpixel characteristics can be adopted from keeping track of region
properties in the region growing algorithm.

About RGB or LAB, I agree with Moritz that this does not matter, instead it
is more important that any number of bands can be used as input, and any
kind of data, e.g. mixing vegetation indices with spectral bands.

Thanks a lot for the implementation! Since this is work in progress, the
module could be moved from grass-addons to sandbox until the name and
options are fixed?

Markus M

>
> Thanks again.
>
>>
>> Maybe MarkusM help us with that ?
>>
>> Moritz
>>
>>
>> On 19/12/16 16:05, Moritz Lennert wrote:
>>>
>>> On 19/12/16 09:38, Rashad Kanavath wrote:



 On Sun, Dec 18, 2016 at 2:53 PM, Moritz Lennert
 >
wrote:

 On 18/12/16 14:01, Rashad Kanavath wrote:

 Hello,

 As promised, I had pushed code to G7 addons repo


https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic
 <
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic
>
 <
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic
 <
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic
>>


 Great job, thanks a lot !


 I had tested with some small datasets and is working.

 More testing welcome :)


 I get the following warning during installation:

 main.c: In function ‘main’:
 main.c:514:13: warning: implicit declaration of function ‘min’
 [-Wimplicit-function-declaration]
  seedx = min(g_width-1,seedx);
  ^~~

 I think you have to explicitely define min() through a macro, or
 AFAIK you can use fmin() as elsewhere in the code.


 I will push a fix for that.
>>>
>>>
>>> Thanks, but your fix creates another error:
>>>
>>> main.c: In function ‘main’:
>>> main.c:514:18: error: expected expression before ‘double’
>>>   seedx = fmin(double (g_width-1), seedx);
>>>^~
>>> main.c:514:13: error: too few arguments to function ‘fmin’
>>>   seedx = fmin(double (g_width-1), seedx);
>>>   ^~~~
>>> In file included from /usr/include/features.h:364:0,
>>>   from /usr/include/stdio.h:27,
>>>   from main.c:21:
>>> /usr/include/x86_64-linux-gnu/bits/mathcalls.h:360:1: note: declared
here
>>>   __MATHCALLX (fmin,, (_Mdouble_ __x, _Mdouble_ __y), (__const__));
>>>   ^
>>> make: *** [OBJ.x86_64-pc-linux-gnu/main.o] Erreur 1
>>>
>>> as 'double' is not a function, so double(g_width-1)) doesn't make sense.
>>>
>>> If you want to cast g_width-1 to double before submitting it to fmin(),
>>> then AFAIK this would have to be:
>>>
>>> seedx = fmin ((double) (g_width-1), seedx)
>>>
>>> However, again AFAIK, this type conversion is done implicitely anyhow,
>>> so you can just write:
>>>
>>> seedx = fmin (g_width-1, seedx)
>>>
>>>


 Also:

 - The output as it is now is not very useful. What we would need is
 a map with each pixel containing the label of the superpixel it
 belongs to. In the original code, there are both outputs: i) an
 image of the superpixel limits overlayed over the original image,
 ii) the labeled pixels


 you need contour segments as seperate output and also the current one.
 right?
>>>
>>>
>>> I don't know what you understand by 'contour segments'. What we would
>>> need would be an output similar to that of i.segment, i.e. each pixel
>>> having the id of the superpixel it belongs to (and there would be no
>>> specific boundary pixels).
>>>
>>> The current output is actually not useful at all for us, I think. It is
>>> used for visualisation purposes in the original software, but in GRASS

Re: [GRASS-dev] [release planning] 7.2.0

[Markus Neteler]

On Sun, Dec 18, 2016 at 9:39 PM, Anna Petrášová  wrote:
> On Sat, Dec 17, 2016 at 9:59 AM, Martin Landa  wrote:
>> Hi,
>>
>> 2016-12-10 20:00 GMT+01:00 Vaclav Petras :
>>>
>>> Yes, that's it. Do you know how/where to push it upstream/downstream, so
>>> that the right people look at it? It seemed that it is fixed at one point,
>>> but the same behavior is back now.
>>
>> I tested various winGRASS versions on my Windows machine and most of
>> them worked [1]. I lost track what version of GRASS is not working
>> you? Ma
>>
>
> No version was working for me. The weird thing is it worked for one
> student (I tested it myself on his computer), but for many other
> students it failed. So I tested different versions on freshly
> installed Windows 10 in Virtual Box on linux and nothing worked. This
> was couple weeks back, I can test again this week.

Shall I wait with the release or just get it out?

Markus

> Anna
>
>> [1] https://trac.osgeo.org/grass/ticket/2996#comment:17
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev