Re: [GRASS-dev] Making sense of packages for Ubuntu

2015-06-22 Thread Martin Landa
Hi,

2015-06-22 17:44 GMT+02:00 Vaclav Petras wenzesl...@gmail.com:
 According to what was said it seems to me that we should change:

 sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
 sudo add-apt-repository ppa:grass/grass-stable
 sudo apt-get update
 sudo apt-get install grass7

 to:

 sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
 sudo apt-get update
 sudo apt-get install grass

probably yes, packages from `ppa:grass/grass-stable` should be moved
to `ppa:ubuntugis/ubuntugis-unstable`. GRASS PPA should be used for
daily builds. 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] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Vincent Bain
Thank you Moritz for your reply,
not the most elegant but surely the quickest way :
here you can download a full test directory [27MB] (db links were
removed because initial data is stored in a postgres db).

http://www.toraval.fr/telec/L3.tar.gz

Open workspace_L3z.gxw, and try to edit any vector map the way I
described in my previous post. Let me know if you have the same issue.

V.

Le lundi 22 juin 2015 à 16:05 +0200, Moritz Lennert a écrit :
 Can you give us data and a procedure to make this reproducible ?
 
 Moritz





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

[GRASS-dev] Slow insert to GRASS SQLite db from QGIS

2015-06-22 Thread Radim Blazek
Vector import to GRASS in QGIS browser is very slow when using SQLite
database, about 6s/1000 features. It takes less than 1s with dbf
driver or if v.in.ogr + sqlite is used (even if run from GRASS tools).

The chain is: qgis.exe - thread - qgis.v.in.exe - sqlite.exe

Could it be some SQLite db locking? Somehow switched on when
sqlite.exe driver is started from multi thread app? qgis.v.in.exe is
C++ MSVC. Any idea?

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


Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Margherita Di Leo
On Mon, Jun 22, 2015 at 4:35 PM, Martin Landa landa.mar...@gmail.com
wrote:

 Hi,

 2015-06-22 16:32 GMT+02:00 Margherita Di Leo direg...@gmail.com:
  (known)
  https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS

 probably should be moved (merged) to

 https://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

  http://gismentors.cz/mentors/landa

I would keep the two pages separated for historical reasons (two GSoC
projects in two different years) but I suggest to cross link the two pages
and move the todo list to the new one. Maybe also to file a bug request for
each task?


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Margherita Di Leo
On Mon, Jun 22, 2015 at 4:44 PM, Margherita Di Leo direg...@gmail.com
wrote:



 On Mon, Jun 22, 2015 at 4:35 PM, Martin Landa landa.mar...@gmail.com
 wrote:

 Hi,

 2015-06-22 16:32 GMT+02:00 Margherita Di Leo direg...@gmail.com:
  (known)
  https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS

 probably should be moved (merged) to

 https://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

  http://gismentors.cz/mentors/landa

 I would keep the two pages separated for historical reasons (two GSoC
 projects in two different years) but I suggest to cross link the two pages
 and move the todo list to the new one. Maybe also to file a bug request for
 each task?

 whereas I suppose the stable documentation should eventually land on the
(same as last year project) wiki page
http://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2699: g.gui.iclass doesn't run after selecting training areas

2015-06-22 Thread GRASS GIS
#2699: g.gui.iclass doesn't run after selecting training areas
-+-
  Reporter:  ThayseNery  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.1
 Component:  wxGUI   |Version:  7.0.0
Resolution:  |   Keywords:  g.gui.iclass, digitizer
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by annakrat):

 r65506 backported in r65517.

--
Ticket URL: http://trac.osgeo.org/grass/ticket/2699#comment:6
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #2700: scatterplots in g.gui.iclass don't work on Windows

2015-06-22 Thread GRASS GIS
#2700: scatterplots in g.gui.iclass don't work on Windows
---+-
 Reporter:  annakrat   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.0.1
Component:  wxGUI  |Version:  svn-releasebranch70
 Keywords:  g.gui.iclass, scatterplot  |CPU:  All
 Platform:  MSWindows 8|
---+-
 The plot canvas and axes are visible, but there are no points inside. I am
 getting only warning (not sure if related):


 {{{
 C:\Program Files (x86)\GRASS GIS 7.1.svn\Python27\lib\site-
 packages\numpy\ma\core.py:3791:
 UserWarning: Warning: converting a masked element to nan.
  warnings.warn(Warning: converting a masked element to nan.)
 }}}

 Works on Ubuntu.

--
Ticket URL: http://trac.osgeo.org/grass/ticket/2700
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Debugging QGIS with GRASS provider on Windows

2015-06-22 Thread Radim Blazek
On Sun, Jun 21, 2015 at 4:32 AM, Glynn Clements
gl...@gclements.plus.com wrote:

 Helmut Kudrnovsky wrote:

 Finally I found it, it is similar story like with FILE.

 The provider (MSVC) calls Vect__open_old with struct Map_info variable
 allocated in the provider where sizeof(struct Map_info) = 1408.
 Vect__open_old (MinGW) calls G_zero on that variable, where
 sizeof(struct Map_info) = 1520.

 It means that all structures used in GRASS libs must be also allocated
 in GRASS. New functions like Vect_alloc_map have to be added to GRASS
 and until it gets to GRASS and to OSGeo4w, the the structures must be
 be allocated in the provider with enough space.

 Strange thing that it came up only now with GRASS 7 and threads.

 You need to get both compilers to use the same ABI.

 The alternative is to treat all structures as opaque, which isn't
 going to happen. It isn't sufficient to have GRASS allocate and free
 everything, you also can't access any fields directly, you'd need
 setters and getters for everything.

The problem was with Map_info structure which is accessed only through
GRASS lib. The structures accessed directly (line_pnts,line_cats) have
only int or double or pointers to them. In theory the size of int may
be different for different compilers, but in this case it is the same
and it is quite rare to have GRASS and QGIS compiled by two compilers
with different size of int.

I could not find a function for Map_info allocation, I am missing
Vect_new_map_struct and Vect_destroy_map_struct.

 Given the numbers, my first guess is that MinGW is using 8 bytes for
 off_t versus 4 bytes for MSVC. Yep; the bottom of config.h.in has:

 #if defined(__MINGW32__)

 /* add/remove as needed */
 /* redefine off_t */
 #include sys/types.h
 #define off_t off64_t

 And that's unaffected by --disable-largefile.

 This specific issue may just need changing __MINGW32__ to WIN32 (or
 _WIN32 or _WINNT, all of which are defined by MinGW) so that MSVC gets
 the same treatment. Failing that, some way to disable LFS (e.g. making
 MinGW builds honour --disable-largefile) is needed.

 The FILE issues are presumably due to mismatches between different
 versions of the MSVCRT library.

 malloc() and free() have the same
 issue: heap data must be freed by the same version of MSVCRT which
 allocated it (NVIZ originally had issues with passing Tcl_Alloc()d
 pointers directly to free() instead of Tcl_Free(), which fails if Tcl
 uses a different version of MSVCRT to GRASS).

 I don't know whether it's possible to change the version of MSVCRT
 which MinGW uses. If not, then we'll need to look at why files opened
 by lib/gis functions are being read/written by user code. But it would
 be preferable if FILE* could be passed around.

The problem with FILE (in my case - QGIS) was false alarm, it happened
when I mixed GRASS gis lib compiled by MinGW and vector lib compiled
by MSVC to be able to debug vect lib.

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


Re: [GRASS-dev] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Markus Neteler
On Mon, Jun 22, 2015 at 12:14 PM, Martin Landa landa.mar...@gmail.com wrote:
 2015-06-22 9:42 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
 Where are we at with 6.4.5. Can we just release as is, possibly citing known
 bugs ?

 +1 for release as it is. Martin

First time ever after RC1 :-) Yes, also much in favor!

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


Re: [GRASS-dev] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Moritz Lennert

On 29/05/15 22:23, Anna Petrášová wrote:



On Tue, May 26, 2015 at 9:32 AM, Moritz Lennert
mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote:

On 25/05/15 14:58, Markus Neteler wrote:


On May 2, 2015 10:41 PM, Markus Neteler nete...@osgeo.org
mailto:nete...@osgeo.org
mailto:nete...@osgeo.org mailto:nete...@osgeo.org wrote:
  
   On Mon, Apr 6, 2015 at 6:17 PM, Markus Neteler
nete...@osgeo.org mailto:nete...@osgeo.org
mailto:nete...@osgeo.org mailto:nete...@osgeo.org wrote:
On Tue, Mar 24, 2015 at 10:25 PM, Markus Neteler
nete...@osgeo.org mailto:nete...@osgeo.org
mailto:nete...@osgeo.org mailto:nete...@osgeo.org wrote:
Current state is at
http://trac.osgeo.org/grass/wiki/Grass6Planning
   
I'll package RC1 tonight.
  
   Done on that day and announced:
   http://grass.osgeo.org/news/43/15/GRASS-GIS-6-4-5RC1-released/
  
   Since then no special feedback occured. Time to get out the
final
   release? Did anyone test RC1? :-)

Any feedback?


I checked a bit and didn't find any serious issues. The only issues
I came across are already known [1, 2], and I'm not sure that we
have the resources to spend time fixing them for grass6...

For the rest, everything seems to work fine here.

Moritz

[1] https://trac.osgeo.org/grass/ticket/2120#comment:14

No idea and no time to look at it.

[2] https://trac.osgeo.org/grass/ticket/2026#comment:5


Backported.


Where are we at with 6.4.5. Can we just release as is, possibly citing 
known bugs ?


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

Re: [GRASS-dev] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Martin Landa
Hi,

2015-06-22 9:42 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
 Where are we at with 6.4.5. Can we just release as is, possibly citing known
 bugs ?

+1 for release as it is. 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


[GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Moritz Lennert

Hi Matej,

Thank you for the updates.

I have one question concerning the metadata templates: do I understand 
correctly that by default, neither the basic, nor the inspire template 
contain a reference to the projection system ?


IIUC, INSPIRE currently does not impose this, but I don't really 
understand how such basic information can be missing from the metadata. 
What help is the bounding box info, if we don't know in which CRS it is ?


But maybe I'm just missing something...

Moritz

On 21/06/15 21:04, Matej Krejci wrote:

Hi,
below is my report for Improved metadata for GRASS GIS project.

1) What do I have completed this week?

  * I have finished support of metada for temporal framework.

2) What am I going to achieve for next week?

  * Testing, debugging temporal metadata management
  * To make smome improvements for temporal metadata management
  * Main plan for next week is to start with designing pycsw catalogue
browser

3) Is there any blocking issue?

  * I spent more time than I expected with ISO 19108 documentation



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


Re: [GRASS-dev] Slow insert to GRASS SQLite db from QGIS

2015-06-22 Thread Radim Blazek
Solved. I forgot db_begin_transaction.
Sorry for noise.

Radim

On Mon, Jun 22, 2015 at 9:18 PM, Radim Blazek radim.bla...@gmail.com wrote:
 Vector import to GRASS in QGIS browser is very slow when using SQLite
 database, about 6s/1000 features. It takes less than 1s with dbf
 driver or if v.in.ogr + sqlite is used (even if run from GRASS tools).

 The chain is: qgis.exe - thread - qgis.v.in.exe - sqlite.exe

 Could it be some SQLite db locking? Somehow switched on when
 sqlite.exe driver is started from multi thread app? qgis.v.in.exe is
 C++ MSVC. Any idea?

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


Re: [GRASS-dev] r.sample.category

2015-06-22 Thread Anna Petrášová
Hi Paulo,

On Tue, Jun 16, 2015 at 5:38 AM, Paulo van Breugel p.vanbreu...@gmail.com
wrote:

 I am having a look at the new r.sample.category addon. Great idea. I would
 like to make a suggestion; to allow the user to define the number of points
 as a percentage, similar to r.random.


do you mean number of points should be based on percentage of cells in each
category or the entire raster? There are some other TODOs in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sample.category/r.sample.category.py#L47

Best,

Anna


 Rgds,

 Paulo

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

Re: [GRASS-dev] Weekly snapshot - link with non-changing name?

2015-06-22 Thread Rainer M Krug
Markus Neteler nete...@osgeo.org writes:

 On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote:

 Vaclav Petras wenzesl...@gmail.com writes:

 It is really just a automatic snapshot, not a tested
  release.

 Thanks - so I will then use HEAD of the svn - easier to do in homebrew,
 as no sha hash is needed of the downloaded file.

 You want me to generate that?

No - no need. I just tell homebrew to download head from svn and than to
compile it - it works.

I will post a link to the recipe later this week. This will make testing
of GRASS 7.1 easy on OS X.

Thanks a lot,

Rainer


 Markus

 Thanks,

 Rainer

 
  Vaclav
 
  Thanks,
 
  Rainer
 
  
   Rainer
  
  
   Markus
 
  --
  Rainer M. Krug
  email: Raineratkrugsdotde
  PGP: 0x0F52F982
 
  ___
  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

 --
 Rainer M. Krug
 email: Raineratkrugsdotde
 PGP: 0x0F52F982

 ___
 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

-- 
Rainer M. Krug
email: Raineratkrugsdotde
PGP: 0x0F52F982


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

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Margherita Di Leo
Hi,

On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I understand
 correctly that by default, neither the basic, nor the inspire template
 contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the metadata.
 What help is the bounding box info, if we don't know in which CRS it is ?


I agree that it sounds strange, however the bounding box is given in
geographic (unprojected) coordinates, and the ISO 19115:2003, where the
GeographicBoundingBox comes from, reads (B.3.2.1): geographic position of
the dataset NOTE This is only an approximate reference so specifying the
coordinate reference system is unnecessary 


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Newcomb, Doug
Most of the local implementations of best practices for metadata that I
have seen include projection information.  Where I work, there are 6
possible projections that are commonly used.

Doug

On Mon, Jun 22, 2015 at 4:18 AM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I understand
 correctly that by default, neither the basic, nor the inspire template
 contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the metadata.
 What help is the bounding box info, if we don't know in which CRS it is ?

 But maybe I'm just missing something...

 Moritz

 On 21/06/15 21:04, Matej Krejci wrote:

 Hi,
 below is my report for Improved metadata for GRASS GIS project.

 1) What do I have completed this week?

   * I have finished support of metada for temporal framework.

 2) What am I going to achieve for next week?

   * Testing, debugging temporal metadata management
   * To make smome improvements for temporal metadata management
   * Main plan for next week is to start with designing pycsw catalogue
 browser

 3) Is there any blocking issue?

   * I spent more time than I expected with ISO 19108 documentation



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




-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Vincent Bain
Hi,
sorry for the following confused remark : using 6.4.5 (right now rev.
65516) on a daily basis I sometimes (rarely) have an issue with wxGUI,
but can't foresee when it happens :
consider a workspace composed of several quite big vector maps. Select
Digitize from the pull-down menu in the map display window. Then
select the name of the vector map to edit : sometimes the current edited
map will not be the one I choosed but another one in the layer tree, and
this particular map is impossible to select from the list... Digitizing
the map can always be performed the right way by selecting Start
editing from the right-click menu in the layer tree. 

I did not find a particular situation when it occurs, except that :
-it's always concerning big vector files (i.e. contour maps),
-it does not happen if the layer tree contains only one vector map (the
one I want to edit).

Sorry again for the lack of formal clues but perhaps this point should
be considered blocking for a stable release. Hope some of you can
reproduce this bug or have some idea about what can be wrong there.

Vincent.


Le lundi 22 juin 2015 à 13:35 +0200, Markus Neteler a écrit :
 On Mon, Jun 22, 2015 at 12:14 PM, Martin Landa landa.mar...@gmail.com wrote:
  2015-06-22 9:42 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
  Where are we at with 6.4.5. Can we just release as is, possibly citing 
  known
  bugs ?
 
  +1 for release as it is. Martin
 
 First time ever after RC1 :-) Yes, also much in favor!
 
 Markus
 ___
 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] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Martin Landa
Hi,

2015-06-22 16:32 GMT+02:00 Margherita Di Leo direg...@gmail.com:
 (known)
 https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS

probably should be moved (merged) to

https://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

?

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] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Margherita Di Leo
On Mon, Jun 22, 2015 at 4:02 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 On 22/06/15 15:40, Margherita Di Leo wrote:

 Hi,

 On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert
 mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be
 wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I
 understand correctly that by default, neither the basic, nor the
 inspire template contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the
 metadata. What help is the bounding box info, if we don't know in
 which CRS it is ?


 I agree that it sounds strange, however the bounding box is given in
 geographic (unprojected) coordinates, and the ISO 19115:2003, where the
 GeographicBoundingBox comes from, reads (B.3.2.1): geographic position
 of the dataset NOTE This is only an approximate reference so specifying
 the coordinate reference system is unnecessary 


 Using g.gui.metadata on the hospitals map in nc_spm_08, I get:

   gmd:extent
 gmd:EX_Extent
 gmd:geographicElement
 gmd:EX_GeographicBoundingBox
 gmd:westBoundLongitude
 gco:Decimal308097.937400562/gco:Decimal
 /gmd:westBoundLongitude
 gmd:eastBoundLongitude
 gco:Decimal20235.5644005626/gco:Decimal
 /gmd:eastBoundLongitude
 gmd:southBoundLatitude
 gco:Decimal914347.8748615/gco:Decimal
 /gmd:southBoundLatitude
 gmd:northBoundLatitude
 gco:Decimal156998.1718615/gco:Decimal
 /gmd:northBoundLatitude
 /gmd:EX_GeographicBoundingBox
 /gmd:geographicElement
 /gmd:EX_Extent
 /gmd:extent

 Looks like projected coordinates to me...


I would say this is a bug.



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Margherita Di Leo
On Mon, Jun 22, 2015 at 4:12 PM, Margherita Di Leo direg...@gmail.com
wrote:



 On Mon, Jun 22, 2015 at 4:02 PM, Moritz Lennert 
 mlenn...@club.worldonline.be wrote:

 On 22/06/15 15:40, Margherita Di Leo wrote:

 Hi,

 On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert
 mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be
 wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I
 understand correctly that by default, neither the basic, nor the
 inspire template contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the
 metadata. What help is the bounding box info, if we don't know in
 which CRS it is ?


 I agree that it sounds strange, however the bounding box is given in
 geographic (unprojected) coordinates, and the ISO 19115:2003, where the
 GeographicBoundingBox comes from, reads (B.3.2.1): geographic position
 of the dataset NOTE This is only an approximate reference so specifying
 the coordinate reference system is unnecessary 


 Using g.gui.metadata on the hospitals map in nc_spm_08, I get:

   gmd:extent
 gmd:EX_Extent
 gmd:geographicElement
 gmd:EX_GeographicBoundingBox
 gmd:westBoundLongitude

 gco:Decimal308097.937400562/gco:Decimal
 /gmd:westBoundLongitude
 gmd:eastBoundLongitude

 gco:Decimal20235.5644005626/gco:Decimal
 /gmd:eastBoundLongitude
 gmd:southBoundLatitude
 gco:Decimal914347.8748615/gco:Decimal
 /gmd:southBoundLatitude
 gmd:northBoundLatitude
 gco:Decimal156998.1718615/gco:Decimal
 /gmd:northBoundLatitude
 /gmd:EX_GeographicBoundingBox
 /gmd:geographicElement
 /gmd:EX_Extent
 /gmd:extent

 Looks like projected coordinates to me...


 I would say this is a bug.


(known)
https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

2015-06-22 Thread Moritz Lennert

On 22/06/15 15:40, Margherita Di Leo wrote:

Hi,

On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert
mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote:

Hi Matej,

Thank you for the updates.

I have one question concerning the metadata templates: do I
understand correctly that by default, neither the basic, nor the
inspire template contain a reference to the projection system ?

IIUC, INSPIRE currently does not impose this, but I don't really
understand how such basic information can be missing from the
metadata. What help is the bounding box info, if we don't know in
which CRS it is ?


I agree that it sounds strange, however the bounding box is given in
geographic (unprojected) coordinates, and the ISO 19115:2003, where the
GeographicBoundingBox comes from, reads (B.3.2.1): geographic position
of the dataset NOTE This is only an approximate reference so specifying
the coordinate reference system is unnecessary 


Using g.gui.metadata on the hospitals map in nc_spm_08, I get:

  gmd:extent
gmd:EX_Extent
gmd:geographicElement
gmd:EX_GeographicBoundingBox
gmd:westBoundLongitude
gco:Decimal308097.937400562/gco:Decimal
/gmd:westBoundLongitude
gmd:eastBoundLongitude
gco:Decimal20235.5644005626/gco:Decimal
/gmd:eastBoundLongitude
gmd:southBoundLatitude
gco:Decimal914347.8748615/gco:Decimal
/gmd:southBoundLatitude
gmd:northBoundLatitude
gco:Decimal156998.1718615/gco:Decimal
/gmd:northBoundLatitude
/gmd:EX_GeographicBoundingBox
/gmd:geographicElement
/gmd:EX_Extent
/gmd:extent

Looks like projected coordinates to me...

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


Re: [GRASS-dev] Planning GRASS GIS 6.4.5 release

2015-06-22 Thread Moritz Lennert

On 22/06/15 14:50, Vincent Bain wrote:

Hi,
sorry for the following confused remark : using 6.4.5 (right now rev.
65516) on a daily basis I sometimes (rarely) have an issue with wxGUI,
but can't foresee when it happens :
consider a workspace composed of several quite big vector maps. Select
Digitize from the pull-down menu in the map display window. Then
select the name of the vector map to edit : sometimes the current edited
map will not be the one I choosed but another one in the layer tree, and
this particular map is impossible to select from the list... Digitizing
the map can always be performed the right way by selecting Start
editing from the right-click menu in the layer tree.

I did not find a particular situation when it occurs, except that :
-it's always concerning big vector files (i.e. contour maps),
-it does not happen if the layer tree contains only one vector map (the
one I want to edit).

Sorry again for the lack of formal clues but perhaps this point should
be considered blocking for a stable release. Hope some of you can
reproduce this bug or have some idea about what can be wrong there.


Can you give us data and a procedure to make this reproducible ?

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


Re: [GRASS-dev] Weekly snapshot - link with non-changing name?

2015-06-22 Thread Vaclav Petras
On Mon, Jun 22, 2015 at 9:40 AM, Rainer M Krug rai...@krugs.de wrote:

 Markus Neteler nete...@osgeo.org writes:

  On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote:
 
  Vaclav Petras wenzesl...@gmail.com writes:
 
  It is really just a automatic snapshot, not a tested
   release.
 
  Thanks - so I will then use HEAD of the svn - easier to do in homebrew,
  as no sha hash is needed of the downloaded file.
 
  You want me to generate that?

 No - no need. I just tell homebrew to download head from svn and than to
 compile it - it works.

 I will post a link to the recipe later this week. This will make testing
 of GRASS 7.1 easy on OS X.


And it can be combined with:

cd /grass/source/code/root
./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ \
--exec python -m grass.gunittest.main \
--location nc_spm_08 --location-type nc

Thanks a lot,

 Rainer

 
  Markus
 
  Thanks,
 
  Rainer
 
  
   Vaclav
  
   Thanks,
  
   Rainer
  
   
Rainer
   
   
Markus
  
   --
   Rainer M. Krug
   email: Raineratkrugsdotde
   PGP: 0x0F52F982
  
   ___
   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
 
  --
  Rainer M. Krug
  email: Raineratkrugsdotde
  PGP: 0x0F52F982
 
  ___
  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

 --
 Rainer M. Krug
 email: Raineratkrugsdotde
 PGP: 0x0F52F982

 ___
 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