Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

[Blumentrath, Stefan]

Thanks Helmut, Vaclav, Markus for your support.

Should be fixed now (by moving the import to "dev main()").
I would have liked to do it earlier but we had a failure on the server where I 
had the code...

Kind regards,
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Helmut 
Kudrnovsky
Sent: 13. september 2016 17:21
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Markus Neteler wrote
> On Tue, Sep 13, 2016 at 4:52 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
>>>Thanks for your swift reply!
>>>
>>>In v.in.pygbif the import of pygbif is also done in a try-except
statement.
>>>
>>>Maybe the difference is that pyspatialite is installed on the build
system,
>> while pygbif is (naturally) not >(yet)?
> 
> Exactly...
> 
> root@osgeo6:/home/neteler# pip install pygbif
> bash: pip: command not found
> 
> How to get pip into this Debian box? (keeping the other 10 virtual 
> sites on the system intact) Will be easy but I am more RPM oriented...

apt-get install python-pip?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285594.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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3161: different results by v.in.ogr --ui and vector import wizzard (data shift)

[GRASS GIS]

#3161: different results by v.in.ogr --ui and vector import wizzard (data shift)
--+---
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  vector import
   CPU:  x86-64   |   Platform:  MSWindows 7
--+---

Comment (by hellik):

 Replying to [comment:1 mmetz]:
 > In the end, the user has to decide if reprojection is needed or if the
 source srs and the location srs are similar enough to allow for using
 v.in.ogr -o (override projection check). After investigating the input
 data with g.proj georef= and ogrinfo/gdalinfo.

 as mentioned before, there is no ''override projection check'' needed by
 import via v.in.ogr --ui.

 if you want to try

 - data can be downloaded
 [https://www.tirol.gv.at/data/datenkatalog/umwelt/gewaessernetz/ river
 net];

 - then ogr2ogr -s_srs EPSG:31254 -t_srs EPSG:31287

 - create location by EPSG:31287 and datum_trans 2

 - then import ''GUI -> import common formats''

--
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_COMPRESSOR=BZIP2 in winGRASS

[Martin Landa]

Hi,

2016-09-18 20:04 GMT+02:00 Markus Neteler :
>> "GRASS needs to be compiled with BZIP2 for BZIP2 compression"
>> ?
>
> I checked
> https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r69510-8/
>   BZIP2 support:  no
>
> That's why it is at time not included in winGRASS...

bzlib2 support activated in trunk (r69517). Let's check the next
WinGRASS build. Martin

-- 
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] [GRASS GIS] #3161: different results by v.in.ogr --ui and vector import wizzard (data shift)

[GRASS GIS]

#3161: different results by v.in.ogr --ui and vector import wizzard (data shift)
--+---
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  vector import
   CPU:  x86-64   |   Platform:  MSWindows 7
--+---

Comment (by hellik):

 Replying to [comment:1 mmetz]:
 >
 > In this case the datum transformation parameters selected by GDAL are
 > {{{
 > towgs : 577.326,90.129,463.919,5.137,1.474,5.297,2.4232
 > }}}
 > which is similar but not equal to those used in your location
 > {{{
 > towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 > }}}


 {{{
 g.proj epsg=31287 datum_trans=-1
 ---
 1
 Used in whole hermannskogel region
 towgs84=653.000,-212.000,449.000
 Default 3-Parameter Transformation (May not be optimum for older datums;
 use this only if no more appropriate options are available.)
 ---
 2
 Used in Austria
 towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 Accuracy approx. 1.5m
 ---
 3
 Used in Czech Republic
 towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56

 ---
 4
 Used in Slovakia
 towgs84=485.021,169.465,483.839,7.786342,4.397554,4.102655,0

 ---
 5
 Used in Slovenia
 towgs84=426.9,142.6,460.1,4.91,4.49,-12.42,17.1
 }}}

 mmhh, g.proj gives slightly different +towgs84 parameters as you mention
 it for GDAL/OGR.

 {{{
 System Info
 GRASS Version: 7.3.svn
 GRASS SVN revision: r69510
 Build date: 2016-09-17
 Build platform: x86_64-w64-mingw32
 GDAL: 2.1.1
 PROJ.4: 4.9.3
 GEOS: 3.5.0
 SQLite: 3.14.1
 Python: 2.7.5
 wxPython: 2.8.12.1
 Platform: Windows-8-6.2.9200 (OSGeo4W)
 }}}

--
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] #3161: different results by v.in.ogr --ui and vector import wizzard (data shift)

[GRASS GIS]

#3161: different results by v.in.ogr --ui and vector import wizzard (data shift)
--+---
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  vector import
   CPU:  x86-64   |   Platform:  MSWindows 7
--+---

Comment (by hellik):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:3161 hellik]:
 > > follwoing location
 > >
 > > {{{
 > > g.proj -p
 > > -PROJ_INFO-
 > > name   : MGI / Austria Lambert
 > > datum  : hermannskogel
 > > ellps  : bessel
 > > proj   : lcc
 > > lat_1  : 49
 > > lat_2  : 46
 > > lat_0  : 47.5
 > > lon_0  : 13.33
 > > x_0: 40
 > > y_0: 40
 > > no_defs: defined
 > > towgs84: 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 > > -PROJ_EPSG-
 > > epsg   : 31287
 > > -PROJ_UNITS
 > > unit   : meter
 > > units  : meters
 > > meters : 1
 > > }}}
 > >
 > The towgs84 parameters could be a problem. GDAL uses similar towgs84
 parameters as default while GRASS uses as default
 > {{{
 > towgs84 : 653,-212,449,0,0,0,0
 > }}}

 the location was created by the location wizzard by EPSG:31287 and then
 the transformation for the region of Austria was used.

 trying

 {{{
 g.proj -p epsg=31287
 }}}


 in a EPSG:4326 and a EPSG:31287 location (both locations are created by
 the EPSG code, I get

 {{{
 g.proj -p epsg=31287
 -PROJ_INFO-
 name   : MGI / Austria Lambert
 datum  : hermannskogel
 ellps  : bessel
 proj   : lcc
 lat_1  : 49
 lat_2  : 46
 lat_0  : 47.5
 lon_0  : 13.33
 x_0: 40
 y_0: 40
 towgs84: 577.326,90.129,463.919,5.137,1.474,5.297,2.4232
 no_defs: defined
 -PROJ_EPSG-
 epsg   : 31287
 -PROJ_UNITS
 unit   : meter
 units  : meters
 meters : 1
 }}}

 so GRASS seems to choose the same +towgs84 parameter as the underlying
 gdal/ogr.

 > Since
 >
 > > and vector data (shapefile to import):
 > >
 > > {{{
 > > INFO: Open of `Gesamtgewaessernetz_v11_Tirol_epsg31287.shp'
 > >   using driver `ESRI Shapefile' successful.
 > >
 > > Layer name: Gesamtgewaessernetz_v11_Tirol_epsg31287
 > > Metadata:
 > >   DBF_DATE_LAST_UPDATE=2016-09-16
 > > Geometry: Measured Line String
 > > Feature Count: 5095
 > > Extent: (118287.824753, 197521.746410) - (833235.119008,
 544697.312403)
 > > Layer SRS WKT:
 > > PROJCS["MGI_Austria_Lambert",
 > > GEOGCS["GCS_MGI",
 > > DATUM["Militar_Geographische_Institute",
 > > SPHEROID["Bessel_1841",6377397.155,299.1528128]],
 > > PRIMEM["Greenwich",0],
 > > UNIT["Degree",0.017453292519943295]],
 > > PROJECTION["Lambert_Conformal_Conic_2SP"],
 > > PARAMETER["standard_parallel_1",49],
 > > PARAMETER["standard_parallel_2",46],
 > > PARAMETER["latitude_of_origin",47.5],
 > > PARAMETER["central_meridian",13.33],
 > > PARAMETER["false_easting",40],
 > > PARAMETER["false_northing",40],
 > > UNIT["Meter",1]]
 > > }}}
 > does not report towgs84 parameters, GRASS might decide that
 >
 > > srs of location and data for import are matching.
 >
 > srs of location and data for import are '''not''' matching.
 >
 > Is the output of
 > {{{
 > g.proj -p
 > }}}

 {{{
 g.proj -p
 -PROJ_INFO-
 name   : MGI / Austria Lambert
 datum  : hermannskogel
 ellps  : bessel
 proj   : lcc
 lat_1  : 49
 lat_2  : 46
 lat_0  : 47.5
 lon_0  : 13.33
 x_0: 40
 y_0: 40
 no_defs: defined
 towgs84: 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 -PROJ_EPSG-
 epsg   : 31287
 -PROJ_UNITS
 unit   : meter
 units  : meters
 meters : 1
 }}}

 the location was created by the location wizzard by EPSG:31287 and then
 the transformation for the region of Austria was used.

 > and
 > {{{
 > g.proj -p
 
georef="D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp"
 > }}}
 > identical?
 >

 in an EPSG:4326 location I get:

 {{{
 g.proj -p
 
georef=D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp
 Versuche mit OGR zu öffnen...
 ...erfolgreich beendet.
 -PROJ_INFO-
 name   : MGI_Austria_Lambert
 datum  : hermannskogel
 ellps  : bessel
 proj   : lcc
 lat_1  : 

Re: [GRASS-dev] [GRASS GIS] #3161: different results by v.in.ogr --ui and vector import wizzard (data shift)

[GRASS GIS]

#3161: different results by v.in.ogr --ui and vector import wizzard (data shift)
--+---
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  vector import
   CPU:  x86-64   |   Platform:  MSWindows 7
--+---

Comment (by mmetz):

 Replying to [ticket:3161 hellik]:
 > follwoing location
 >
 > {{{
 > g.proj -p
 > -PROJ_INFO-
 > name   : MGI / Austria Lambert
 > datum  : hermannskogel
 > ellps  : bessel
 > proj   : lcc
 > lat_1  : 49
 > lat_2  : 46
 > lat_0  : 47.5
 > lon_0  : 13.33
 > x_0: 40
 > y_0: 40
 > no_defs: defined
 > towgs84: 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 > -PROJ_EPSG-
 > epsg   : 31287
 > -PROJ_UNITS
 > unit   : meter
 > units  : meters
 > meters : 1
 > }}}
 >
 The towgs84 parameters could be a problem. GDAL uses similar towgs84
 parameters as default while GRASS uses as default
 {{{
 towgs84 : 653,-212,449,0,0,0,0
 }}}

 Since

 > and vector data (shapefile to import):
 >
 > {{{
 > INFO: Open of `Gesamtgewaessernetz_v11_Tirol_epsg31287.shp'
 >   using driver `ESRI Shapefile' successful.
 >
 > Layer name: Gesamtgewaessernetz_v11_Tirol_epsg31287
 > Metadata:
 >   DBF_DATE_LAST_UPDATE=2016-09-16
 > Geometry: Measured Line String
 > Feature Count: 5095
 > Extent: (118287.824753, 197521.746410) - (833235.119008, 544697.312403)
 > Layer SRS WKT:
 > PROJCS["MGI_Austria_Lambert",
 > GEOGCS["GCS_MGI",
 > DATUM["Militar_Geographische_Institute",
 > SPHEROID["Bessel_1841",6377397.155,299.1528128]],
 > PRIMEM["Greenwich",0],
 > UNIT["Degree",0.017453292519943295]],
 > PROJECTION["Lambert_Conformal_Conic_2SP"],
 > PARAMETER["standard_parallel_1",49],
 > PARAMETER["standard_parallel_2",46],
 > PARAMETER["latitude_of_origin",47.5],
 > PARAMETER["central_meridian",13.33],
 > PARAMETER["false_easting",40],
 > PARAMETER["false_northing",40],
 > UNIT["Meter",1]]
 > }}}
 does not report towgs84 parameters, GRASS might decide that

 > srs of location and data for import are matching.

 srs of location and data for import are '''not''' matching.

 Is the output of
 {{{
 g.proj -p
 }}}
 and
 {{{
 g.proj -p
 
georef="D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp"
 }}}
 identical?

 If not, as v.import assumes, you might need to provide the EPSG code and
 the datum transformation parameters as input to v.import (which makes
 v.import more complicated as it was intended to be).

 If the towgs84 parameters as reported by g.proj for the current location
 and for the input shapefile are not identical, this could be regarded as a
 bug in GRASS since the vast majority of GIS data is imported via
 r.in.gdal/v.in.ogr and GDAL/OGR automatically picks a preferred set of
 datum transformation parameters which GRASS should detect.

 In this case the datum transformation parameters selected by GDAL are
 {{{
 towgs : 577.326,90.129,463.919,5.137,1.474,5.297,2.4232
 }}}
 which is similar but not equal to those used in your location
 {{{
 towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
 }}}

 In the end, the user has to decide if reprojection is needed or if the
 source srs and the location srs are similar enough to allow for using
 v.in.ogr -o (override projection check). After investigating the input
 data with g.proj georef= and ogrinfo/gdalinfo.

--
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_COMPRESSOR=BZIP2 in winGRASS

[Markus Neteler]

On Sun, Sep 18, 2016 at 7:53 PM, Markus Neteler  wrote:
> On Sun, Sep 18, 2016 at 7:41 PM, Helmut Kudrnovsky  wrote:
>> Hi,
>>
>> experimentally I've tried set GRASS_COMPRESSOR=BZIP2 in today's
>> OSGeo4W-wingrass7.3 (trunk).
>>
>> By writing a raster map, I got the message, that BZIP2 grass compresser
>> isn't implemented in this grass version.
>
> What is the exact error message? This one:
>
> "GRASS needs to be compiled with BZIP2 for BZIP2 compression"
> ?

I checked
https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r69510-8/
  BZIP2 support:  no

That's why it is at time not included in winGRASS...

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

Re: [GRASS-dev] GRASS_COMPRESSOR=BZIP2 in winGRASS

[Markus Neteler]

On Sun, Sep 18, 2016 at 7:41 PM, Helmut Kudrnovsky  wrote:
> Hi,
>
> experimentally I've tried set GRASS_COMPRESSOR=BZIP2 in today's
> OSGeo4W-wingrass7.3 (trunk).
>
> By writing a raster map, I got the message, that BZIP2 grass compresser
> isn't implemented in this grass version.

What is the exact error message? This one:

"GRASS needs to be compiled with BZIP2 for BZIP2 compression"
?

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

[GRASS-dev] GRASS_COMPRESSOR=BZIP2 in winGRASS

[Helmut Kudrnovsky]

Hi, 

experimentally I've tried set GRASS_COMPRESSOR=BZIP2 in today's
OSGeo4W-wingrass7.3 (trunk). 

By writing a raster map, I got the message, that BZIP2 grass compresser
isn't implemented in this grass version. 

any idea?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GRASS-COMPRESSOR-BZIP2-in-winGRASS-tp5286534.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] 7.0.5 release planning

[Martin Landa]

Hi,

2016-09-18 16:19 GMT+02:00 Markus Neteler :
>> So, yes, RC2 is due.
>
> I'll do that tonight.

cool, count with my support please. Ma

-- 
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] 7.0.5 release planning

[Markus Neteler]

On Sep 13, 2016 8:29 PM, "Markus Neteler"  wrote:
>
> On Tue, Sep 13, 2016 at 8:27 PM, Martin Landa 
wrote:
> > 44 days are counted from soft freeze, RC2 comes 14 days after RC1, so
> >
> > date -d '2016-08-27 +14 days' +"%Y-%m-%d"
> > 2016-09-10
>
> After re-reading the docs twice I also arrived there :)
>
> So, yes, RC2 is due.

I'll do that tonight.

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

[GRASS-dev] [GRASS GIS] #3162: Quote script module path when calling its gui from parser

[GRASS GIS]

#3162: Quote script module path when calling its gui from parser
-+-
 Reporter:  marisn   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.4.0
Component:  Parser   |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Currently parser will fail if a script module path contains spaces:
 {{{
 grass_trunk > python /home/maris/nezinatniskie_projekti/Zinatnes\ nakts\
 2016/gol.py
 Traceback (most recent call last):
   File "/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gui_core/forms.py", line 2962, in 
 task.set_options(cmd[1:])
   File "/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/etc/python/grass/script/task.py", line 299, in set_options
 key, value = opt.split('=', 1)
 ValueError: need more than 1 value to unpack
 }}}

 The problem comes from recreate_command in lib/gis/parser.c invoking
 forms.py and passing all args as a single string. Forms.py expect each
 space to be an argument separator thus causing failure in option parsing.
 Easiest workaround is to quote module path and name while calling
 forms.py.

 I'm attaching patch that provides required quoting and thus allows to have
 script modules to be located in a path with spaces. As parser is quite
 sensitive thing (too easy to break something by accident), I haven't it
 applied to svn myself to get some feedback first. If it will be considered
 to be safe, backport to all 7.x is needed.

--
Ticket URL: 
GRASS GIS 

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