[GRASS-dev] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

[Helmut Kudrnovsky]

Hi,

if the location is created by an epsg code, is the epsg code stored anywhere
in the location?

if yes can be the epsg-code-representation of the projection used by
v.out.ogr/r.out.gdal instead of the grass gis representation of the
projection?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/epsg-code-stored-anywhere-and-used-by-v-out-ogr-r-out-gdal-tp5173171.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] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

[Markus Neteler]

On Nov 16, 2014 9:37 AM, "Helmut Kudrnovsky"  wrote:
>
> Hi,
>
> if the location is created by an epsg code, is the epsg code stored
anywhere
> in the location?

It is sometimes stored in the PROJ_INFO file.

> if yes can be the epsg-code-representation of the projection used by
> v.out.ogr/r.out.gdal instead of the grass gis representation of the
> projection?

Often not since it may lack datum parameters.

Markus

>
>
> -
> best regards
> Helmut
> --
> View this message in context:
http://osgeo-org.1560.x6.nabble.com/epsg-code-stored-anywhere-and-used-by-v-out-ogr-r-out-gdal-tp5173171.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] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

[Martin Landa]

Hi,

2014-11-16 9:58 GMT+01:00 Markus Neteler :
> It is sometimes stored in the PROJ_INFO file.

in the recent versions of GRASS 7 it should be stored in PROJ_EPSG
file. If not than it's a bug.

Martin

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

Re: [GRASS-dev] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2014-11-16 9:58 GMT+01:00 Markus Neteler <

> neteler@

> >:
>> It is sometimes stored in the PROJ_INFO file.
> 
> in the recent versions of GRASS 7 it should be stored in PROJ_EPSG
> file. If not than it's a bug.
> 
> Martin

tested with

GRASS Version: 7.1.svn  
GRASS SVN Revision: 62712   
Erstellungsdatum: 2014-11-12
Build Platform: i686-pc-mingw32 
GDAL/OGR: 1.11.0
PROJ.4: 4.8.0   
GEOS: 3.4.2 
SQLite: 3.7.17  
Python: 2.7.4   
wxPython: 2.8.12.1  
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W) 

location created with EPSG:31254

C:\grassdata\testepsg31254\PERMANENT
DEFAULT_WIND
MYNAME
PROJ_INFO
PROJ_UNITS
WIND

so it seems PROJ_EPSG is missing.








-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/epsg-code-stored-anywhere-and-used-by-v-out-ogr-r-out-gdal-tp5173171p5173181.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] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

[Helmut Kudrnovsky]

>> if yes can be the epsg-code-representation of the projection used by
>> v.out.ogr/r.out.gdal instead of the grass gis representation of the
>> projection?
>
>Often not since it may lack datum parameters.

a quick test case:

data available at
https://www.tirol.gv.at/data/datenkatalog/umwelt/gewaessernetz/ is in
EPSG:8.2:31254

the prj-file of this dataset says:

Gesamtgewaessernetz_v10_1_Tirol.prj:

PROJCS["MGI_Austria_GK_West",
   GEOGCS["GCS_MGI",
   DATUM["D_MGI",
   SPHEROID["Bessel_1841",6377397.155,299.1528128]],
   PRIMEM["Greenwich",0.0],
   UNIT["Degree",0.0174532925199433]],
   PROJECTION["Transverse_Mercator"],
   PARAMETER["False_Easting",0.0],
   PARAMETER["False_Northing",-500.0],
   PARAMETER["Central_Meridian",10.33],
   PARAMETER["Scale_Factor",1.0],
   PARAMETER["Latitude_Of_Origin",0.0],
   UNIT["Meter",1.0]]

http://epsg.io/31254 says

OGC WKT

PROJCS["MGI / Austria GK West",
GEOGCS["MGI",DATUM["Militar_Geographische_Institute",
SPHEROID["Bessel 1841",6377397.155,299.1528128,
AUTHORITY["EPSG","7004"]],
TOWGS84[577.326,90.129,463.919,5.137,1.474,5.297,2.4232],
AUTHORITY["EPSG","6312"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4312"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",10.33],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",-500],
UNIT["metre",1,AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","31254"]]

ESRI WKT

PROJCS["MGI_Austria_GK_West",
GEOGCS["GCS_MGI",DATUM["D_MGI",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",10.33],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",-500],
UNIT["Meter",1]]

creating a grass location with EPSG:31254, import the shapefile above and
export it by v.out.ogr with/without option -e

v.out.ogr with/without option -e

voutogr.prj:

PROJCS["Transverse_Mercator",
GEOGCS["GCS_bessel",
DATUM["D_Militar_Geographische_Institut",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",10.33],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",-500],
UNIT["Meter",1]]

voutogr_option_e.prj:

PROJCS["Transverse_Mercator",
GEOGCS["GCS_bessel",
DATUM["D_Militar_Geographische_Institut",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",10.33],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",-500],
UNIT["Meter",1]]

I know that all these several projection representations are correct and
define all the same projection.

IMHO at least a v.out.ogr option, which considers the EPSG representation
(e.g. PROJCS["MGI_Austria_GK_West", ... or PROJCS["MGI / Austria GK West",
...), would be nice.

any opinion?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/epsg-code-stored-anywhere-and-used-by-v-out-ogr-r-out-gdal-tp5173171p5173184.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] [GRASS GIS] #2490: EPSG code not saved in PROJ_EPSG

[GRASS GIS]

#2490: EPSG code not saved in PROJ_EPSG
-+--
 Reporter:  hellik   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--
 from the ML

 http://lists.osgeo.org/pipermail/grass-dev/2014-November/071807.html

 {{{
 > It is sometimes stored in the PROJ_INFO file.

 in the recent versions of GRASS 7 it should be stored in PROJ_EPSG
 file. If not than it's a bug.
 }}}

 tested here with

 {{{
 GRASS Version: 7.1.svn
 GRASS SVN Revision: 62754
 Erstellungsdatum: 2014-11-16
 Build Platform: i686-pc-mingw32
 GDAL/OGR: 1.11.0
 PROJ.4: 4.8.0
 GEOS: 3.4.2
 SQLite: 3.7.17
 Python: 2.7.4
 wxPython: 2.8.12.1
 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
 }}}

 location wizard -> create location by epsg code (e.g. 4326)

 EPSG code is not saved in PROJ_EPSG

-- 
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] #2490: EPSG code not saved in PROJ_EPSG

[GRASS GIS]

#2490: EPSG code not saved in PROJ_EPSG
-+--
 Reporter:  hellik   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--

Comment(by hellik):

 Changeset 49298:

 Message:

 Retain EPSG code, if available, into a metadata file.

 https://trac.osgeo.org/grass/changeset/49298

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] v.select overlap vs overlaps

[Martin Landa]

Hi all,

I wonder if it would make sense to rename native GRASS operator
'overlap' to something less conflicting with GEOS SF-based 'overlaps'
?

Martin

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

Re: [GRASS-dev] grass7 addon python script - finishes in normal and --verbose mode, but not in --quiet mode

[Vaclav Petras]

On Fri, Nov 14, 2014 at 10:05 AM, Anna Petrášová 
wrote:

> It's because of the header line:
> cat|length
> 1|572.767146965659
>
> but in quiet mode you get:
>
> 1|572.767146965659
>
> so I would suggest set quiet=True for v.to.db and change the code for
> parsing to expect just one line.
>

--quiet and --verbose should change the level of verbosity of messages
(additional info and/or diagnostic). However, if header is included or not
is question of the (output) format which should be same unless explicitly
changed. A flag should be there to include or not include the header. I
think there is a bug in v.to.db.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2488: v.neighbors: "No points found" error while using points map

[GRASS GIS]

#2488: v.neighbors: "No points found" error while using points map
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-releasebranch70  
 Keywords:  v.neighbors  |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [comment:10 neteler]:
 > Replying to [comment:9 mmetz]:
 > > Replying to [comment:8 neteler]:
 > > > Warnings/error code hopefully improved in r62745
 > >
 > > Changed in r62746.
 >
 > Thanks, backported in r62749.
 >
 > Yet to find: a reasonable example for the manual page (ideally based on
 the NC dataset).

 The example looks reasonable to me. It gives for each grid cell the number
 of points (here: schools) not farther than 1500 meter away from the cell
 center.

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 #2136 is solved but the new approach was not applied everywhere yet. I
 went through the following list (from comment:5:ticket:2136) for
 standardization of basename (formerly prefix) options and changed things
 from `input_prefix` and `input_prefix` to `input` and `output` while using
 the standard options for base name (patch attached). I also updated the
 documentation and made some fixes related to earlier changes in
 prefix->basename transition.

 {{{
 g.extension => prefix: Prefix where to install extension (ignored when
 flag -s is given)
 i.cca => output: Output raster map prefix name
 i.landsat.acca => input_prefix: Example: 'B.' for B.1, B.2, ...
 i.landsat.toar => input_prefix: Example: 'B.' for B.1, B.2, ...
 i.landsat.toar => output_prefix: Example: 'B.toar.' generates
 B.toar.1, B.toar.2, ...
 i.pansharpen => output_prefix: Prefix for output raster maps
 i.pca => output_prefix: A numerical suffix will be added for each
 component map
 i.tasscap => output_prefix: Prefix for output raster maps
 i.topo.corr => output: Name (flag -i) or prefix for output raster maps
 m.nviz.script => name: Prefix of output images (default = NVIZ)
 r.blend => output_prefix: Prefix for red, green and blue output raster
 maps containing
 r.rgb => output_prefix: Prefix for output raster maps (default: input)
 r.ros => output: Prefix for output raster maps (.base, .max, .maxdir,
 .spotdist)
 r.texture => prefix: Prefix for output raster map(s)
 v.out.postgis => dsn: Starts with 'PG' prefix, eg. 'PG:dbname=grass'
 v.rast.stats => column_prefix: Column prefix for new attribute columns
 }}}

 It seems to me that `input` and `output` should be used instead of other
 options (i.e. including `basename` in the option name). This also mean
 that I think that the standard option definition should be changed
 accordingly.

 There are still some unresolved issues. As noted on [http://osgeo-
 org.1560.x6.nabble.com/Fwd-QGIS-Processing-amp-GRASS-td5155460.html
 mailing list] and in comment:13, there are issues with base names in QGIS
 processing. Basically the issue is that things are not explicit and
 actually being explicit might be better for GRASS itself regardless what
 QGIS can handle or not.

 It seems to me that base names on input should be avoided most of the
 time. Imagery modules can use imagery groups, other modules can use
 explicit list. There is a lot of modules which use one or the other.

 With outputs, the situation is more complicated. I can distinguish four
 different cases.

 Case one, the module produces just few maps and there is not many reasons
 to not provide them as separate output options. Example is G7:r.rgb
 suffixing `.r`, `.g` and `.b` versus with red, green and blue options (the
 change is in the diff). Another example of this is G7:r.ros which outputs
 base, max and dir ROS and optionally spotting distance. Now they are all
 specified using basename but G7:r.spread accepts them as separate maps
 anyway and there needs to be `-s` to activate spotting (while with
 separate options, it is enough just to check if option was provided). This
 option is OK for scripting, it is not much work to fill manually and both
 QGIS and wxGUI can handle it well (just using the standard means).

 Example of case two is G7:r.neighbors, the module can generate several
 statistics and you have to provide as many names for option output as is
 the number of requested statistics. This might be challenging when done
 manually since you must match the order but is is fine for scripting, QGIS
 and wxGUI.

 Example of case three is G7:r.texture where just base name is provided and
 module itself adds suffixes according to selected methods. When used
 manually, it is quite convenient because you don't have to care about the
 names, you just have to find them afterwards. The issue for scripting is
 that you don't have any idea what the suffixes are and they are indeed
 different than the option values. QGIS and wxGUI which don't know the
 details about the called module are completely lost. This case can be
 avoided using the approach taken by G7:r.neighbors.

 The last case are modules which produce (large) number of numbered maps,
 these are the reason why standard base name option was created. With these
 there is no other ch

[GRASS-dev] Tests down to 65% (from 86%)

[Vaclav Petras]

Hi all,

something happened between r62745 (Saturday) and r62754 (Sunday) because
tests are failing. Here are the changes in trunk:

http://trac.osgeo.org/grass/log/grass/trunk?action=stop_on_copy&mode=stop_on_copy&rev=62754&stop_rev=62746&limit=100&verbose=on

MarkusM, I'm not sure what was the actual change but it seems that
G_tokenize() is the only related change. From the tests it seems that
something in parser is failing.

I've also noticed that the documentation on server does not contain
generated/standard flags (--), the flags are included when there is a short
flag (-). I get the flags on my local machine with recent version. Was this
changed somehow lately?

Vaclav


http://grass.osgeo.org/grass71/manuals/r.rgb.html
http://grass.osgeo.org/grass71/manuals/r.blend.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev