Re: [GRASS-dev] [GRASS GIS] #2457: DBF driver: stub functions for SQL TRANSACTION

2014-12-18 Thread GRASS GIS 
#2457: DBF driver: stub functions for SQL TRANSACTION
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Database | Version:  svn-releasebranch64  
 Keywords:  dbf, sql |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by renatomichel):

 Hello,

 I copied the file v.rast.stats Version 6.4.3 in the
 apps/grass/grass-6.4.4/scripts successfully, I no longer have the error
 message. These scipts are different with quotes usage ?

 my system (windows, qgis 2.6.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] [GRASS GIS] #2403: cairo driver fails to create surface

2014-12-18 Thread GRASS GIS 
#2403: cairo driver fails to create surface
+---
 Reporter:  martinl |   Owner:  martinl
 Type:  defect  |  Status:  assigned   
 Priority:  major   |   Milestone:  7.0.0  
Component:  Display | Version:  unspecified
 Keywords:  cairo, resolution, surface  |Platform:  Linux  
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:8 martinl]:

 > Could you please review attachment:cairo_down_sampling.diff which do
 down-sampling for Cairo in similar as already does PNG driver?

 The main issue was that it neglected the inner Y loop when up-scaling.

 r63582 makes the cairo driver behave almost identically to the PNG driver.

 For reasons which I've been unable to determine so far, the result is one
 destination pixel wider than with the PNG driver.

 Ultimately, the code should be modified to use an intermediate surface
 which has the same dimensions as the destination rectangle, to avoid the
 overhead of copying the (empty) borders.

-- 
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

2014-12-18 Thread 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 glynn):

 Replying to [comment:131 hcho]:

 > * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
 >
 > * modules with parameters `raster_map=` and `raster_map2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
 >
 > I'm not sure if I was clear enough here.

 You're suggesting that the abbreviation must include some part of the last
 word of the option name? Or that it must include the last character? I.e.
 is rm= ambiguous?

 The main problems I foresee with that are

  * The last word (or an abbreviation of it) might match some earlier
 portion of the option name, meaning that the user intended to specify
 (part of) the last word but the characters were matched against an earlier
 portion.

  * It's possible for a string to match the last word of multiple options.
 E.g. given options raster_map and raster_2_map, rmap would match both
 equally.

-- 
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

2014-12-18 Thread 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 martinl):

 Replying to [comment:132 cmbarton]:
 > Replying to [comment:127 mlennert]:
 > > +1 for raster_3d.
 > >
 > > Moritz
 >
 > +1 for me

 `raster_3d` introduced in r63584.

-- 
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

2014-12-18 Thread 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 martinl):

 Replying to [comment:134 martinl]:

 > `raster_3d` introduced in r63584.

 If no objections I will backport modified element names including
 `raster_3d` to relbr70.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7: v.in.ascii problem with broken lines: Busy SQLITE db

2014-12-18 Thread Markus Neteler 
On Wed, Nov 5, 2014 at 6:14 PM, Markus Neteler  wrote:
> Hi
>
> when importing a (big) file into GRASS GIS 7 with some broken lines in
> it, the import gets stuck at some point:
...
>
> While at it:
> I have started to implement a -i "ignore" flag to simply skip broken
> lines. This doesn't fully work yet: "category out of range" but I am
> not vector C expert enough to complete that.
> We have 180 million lines to import and some are broken, so a -i flag
> would be quite handy rather than manually identifying those lines.
>
> Anyone able to help to solve both issues?


for the record, Markus Metz implemented it all in trunk and relbranch70.
Works nicely, thanks.

Markus
___
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

2014-12-18 Thread 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 hcho):

 Replying to [comment:133 glynn]:
 > Replying to [comment:131 hcho]:
 >
 > > * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
 > >
 > > * modules with parameters `raster_map=` and `raster_map2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
 > >
 > > I'm not sure if I was clear enough here.
 >
 > You're suggesting that the abbreviation must include some part of the
 last word of the option name? Or that it must include the last character?
 I.e. is rm= ambiguous?

 No, not the last word of the option name. You cannot skip any words
 separated by an underscore. rm= is not ambiguous in this case because the
 shortest option name that matches rm= is raster_map=. If one wants
 raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word).

 >
 > The main problems I foresee with that are
 >
 >  * The last word (or an abbreviation of it) might match some earlier
 portion of the option name, meaning that the user intended to specify
 (part of) the last word but the characters were matched against an earlier
 portion.
 >

 I'm not talking about skipping words and using the last word, so this is
 not the case.

 >  * It's possible for a string to match the last word of multiple
 options. E.g. given options raster_map and raster_2_map, rmap would match
 both equally.

 rmap= would match raster_map= "only" because you cannot skip 2.

 Hope I'm clearer now.

-- 
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

2014-12-18 Thread 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 hcho):

 Replying to [comment:136 hcho]:
 > Replying to [comment:133 glynn]:
 > > Replying to [comment:131 hcho]:
 > >
 > > > * modules with parameters `raster_map=` and `raster_map_2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map_2=`
 > > >
 > > > * modules with parameters `raster_map=` and `raster_map2=`: `rast`
 ambiguous, `rmap` for `raster_map=` and `rmap2` for `raster_map2=`
 > > >
 > > > I'm not sure if I was clear enough here.
 > >
 > > You're suggesting that the abbreviation must include some part of the
 last word of the option name? Or that it must include the last character?
 I.e. is rm= ambiguous?
 >
 > No, not the last word of the option name. You cannot skip any words
 separated by an underscore. rm= is not ambiguous in this case because the
 shortest option name that matches rm= is raster_map=. If one wants
 raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word).
 >

 I mean the shortest option name with no more following underscores. 'r'
 for raster, 'm' for map, and no more underscores after 'raster_map'.

 If you have `raster_map_1=` and `raster_map_2=`, `rm=` would be ambiguous
 because `raster_map` is still ambiguous. If you have `raster_map=` and
 `raster_map_2=`, `rm=` expands to `raster_map=` and it's not ambiguous.

 > >
 > > The main problems I foresee with that are
 > >
 > >  * The last word (or an abbreviation of it) might match some earlier
 portion of the option name, meaning that the user intended to specify
 (part of) the last word but the characters were matched against an earlier
 portion.
 > >
 >
 > I'm not talking about skipping words and using the last word, so this is
 not the case.
 >
 > >  * It's possible for a string to match the last word of multiple
 options. E.g. given options raster_map and raster_2_map, rmap would match
 both equally.
 >
 > rmap= would match raster_map= "only" because you cannot skip 2.
 >
 > Hope I'm clearer now.

-- 
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] #2403: cairo driver fails to create surface

2014-12-18 Thread GRASS GIS 
#2403: cairo driver fails to create surface
--+-
  Reporter:  martinl  |   Owner:  martinl   
  Type:  defect   |  Status:  closed
  Priority:  major|   Milestone:  7.0.0 
 Component:  Display  | Version:  unspecified   
Resolution:  fixed|Keywords:  cairo, resolution, surface
  Platform:  Linux| Cpu:  x86-64
--+-
Changes (by martinl):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:9 glynn]:

 > r63582 makes the cairo driver behave almost identically to the PNG
 driver.

 I took liberty to backport it in r63595.

 > For reasons which I've been unable to determine so far, the result is
 one destination pixel wider than with the PNG driver.
 >
 > Ultimately, the code should be modified to use an intermediate surface
 which has the same dimensions as the destination rectangle, to avoid the
 overhead of copying the (empty) borders.

 Since the originally reported issue has been fixed, I took liberty to
 close this ticket.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Invitation to submit an abstract to EGU 2015 session on FOSS for GeoInformatics and Geosciences

2014-12-18 Thread Vaclav Petras 
On Thu, Dec 18, 2014 at 2:12 AM, Yann Chemin  wrote:
>
> Hi all,
>
> Anybody interested to submit some new development,
> please submit an abstract there:
> http://www.egu2015.eu/abstract_management/how_to_submit_an_abstract.html
>
> The Session is:
> --
> ESSI2.13/SSS1.8
> Free and Open Source Software (FOSS) for Geoinformatics and Geosciences
> (co-organized)
>
>
I'm not going there but we (grass users and devs) should definitively do
again a GRASS-focused poster. So far we have the general GRASS poster,
imagery and vector. I though we have also some raster poster but I don't
see it in SVN [1], is it somewhere else? Testing framework now also have a
poster [2]. As I see it, the possible topics are:

Temporal framework
basic concepts, API overview and use cases
There is a lot of people who already use it. If we list our use cases, it
could be pretty good and very different from the original TGRASS paper.

GRASS and Python
This would cover PyGRASS but also grass.script, .temporal, and .gunittest
A lot of people didn't notice that it is possible to use Python until
PyGRASS and Python API is considered experimental in G64, so it make sense
to do an overview.

There are other topics I would like to see but I'm not able to contribute
to them much. Topics which would be more about the usage of GRASS, but
would feature it, could be even better. However, this should be in
different session and it is really up to the concrete scientists rather
than general community.

By the way, are the posters and other material from grass-promo somewhere?
I'm wondering if it would be better to have these things on GitHub or
something similar. It is a bit more flexible considering access rights and
you get (possibility of) web pages automatically.

Vaclav

PS: I haven't mentioned authors but I think it's clear how it should work
whoever wants to join can join and authors of the code are included or will
be attributed in the poster.

[1] http://trac.osgeo.org/grass/browser/grass-promo/grassposter
[2]
http://grasswiki.osgeo.org/wiki/AGU_Fall_Meeting_2014:_GRASS_related_presentations_and_posters
(I will post announcement on G+ soon.)


> Hope we can meet around some excellent fresh beer...
> Cheers,
> Yann
>
> --
> 
>
> ___
> 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] group does not update REF file upon g.remove raster file

2014-12-18 Thread Huidae Cho 
Yann,

Please be more specific. What is the group REF file and how can I replicate
your issue? And what do you expect to happen?

Regards,
Huidae

-- 
Sent from my phone
On Dec 15, 2014 3:49 AM, "Yann Chemin"  wrote:

> Hi,
>
> did g.remove a raster, and the group REF file referencing the raster did
> not update accordingly.
>
> Is this a known behaviour?
> Yann
>
> --
> 
>
> ___
> 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] Invitation to submit an abstract to EGU 2015 session on FOSS for GeoInformatics and Geosciences

2014-12-18 Thread Yann Chemin 
About poster, I am happy to print it and carry it to Vienna, anyone who
contributes should be named as author explicitly, and we can add to the
authors list 'grass development team and grass users'

About poster topic, raster is not there yet to my knowledge. Temporal and
pygrass are also good. Maybe a version 7 poster could be fun too.
On Dec 19, 2014 3:34 AM, "Vaclav Petras"  wrote:

>
>
>
>
> On Thu, Dec 18, 2014 at 2:12 AM, Yann Chemin  wrote:
>>
>> Hi all,
>>
>> Anybody interested to submit some new development,
>> please submit an abstract there:
>> http://www.egu2015.eu/abstract_management/how_to_submit_an_abstract.html
>>
>> The Session is:
>> --
>> ESSI2.13/SSS1.8
>> Free and Open Source Software (FOSS) for Geoinformatics and Geosciences
>> (co-organized)
>>
>>
> I'm not going there but we (grass users and devs) should definitively do
> again a GRASS-focused poster. So far we have the general GRASS poster,
> imagery and vector. I though we have also some raster poster but I don't
> see it in SVN [1], is it somewhere else? Testing framework now also have a
> poster [2]. As I see it, the possible topics are:
>
> Temporal framework
> basic concepts, API overview and use cases
> There is a lot of people who already use it. If we list our use cases, it
> could be pretty good and very different from the original TGRASS paper.
>
> GRASS and Python
> This would cover PyGRASS but also grass.script, .temporal, and .gunittest
> A lot of people didn't notice that it is possible to use Python until
> PyGRASS and Python API is considered experimental in G64, so it make sense
> to do an overview.
>
> There are other topics I would like to see but I'm not able to contribute
> to them much. Topics which would be more about the usage of GRASS, but
> would feature it, could be even better. However, this should be in
> different session and it is really up to the concrete scientists rather
> than general community.
>
> By the way, are the posters and other material from grass-promo somewhere?
> I'm wondering if it would be better to have these things on GitHub or
> something similar. It is a bit more flexible considering access rights and
> you get (possibility of) web pages automatically.
>
> Vaclav
>
> PS: I haven't mentioned authors but I think it's clear how it should work
> whoever wants to join can join and authors of the code are included or will
> be attributed in the poster.
>
> [1] http://trac.osgeo.org/grass/browser/grass-promo/grassposter
> [2]
> http://grasswiki.osgeo.org/wiki/AGU_Fall_Meeting_2014:_GRASS_related_presentations_and_posters
> (I will post announcement on G+ soon.)
>
>
>> Hope we can meet around some excellent fresh beer...
>> Cheers,
>> Yann
>>
>> --
>> 
>>
>> ___
>> 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] group does not update REF file upon g.remove raster file

2014-12-18 Thread Yann Chemin 
Hi,

1 create group
2 g.remove one map listed in the group
3 check the REF file list to see if the map name is still there.
On Dec 19, 2014 5:09 AM, "Huidae Cho"  wrote:

> Yann,
>
> Please be more specific. What is the group REF file and how can I
> replicate your issue? And what do you expect to happen?
>
> Regards,
> Huidae
>
> --
> Sent from my phone
> On Dec 15, 2014 3:49 AM, "Yann Chemin"  wrote:
>
>> Hi,
>>
>> did g.remove a raster, and the group REF file referencing the raster did
>> not update accordingly.
>>
>> Is this a known behaviour?
>> Yann
>>
>> --
>> 
>>
>> ___
>> 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] group does not update REF file upon g.remove raster file

2014-12-18 Thread Vaclav Petras 
On Dec 18, 2014 6:27 PM, "Yann Chemin"  wrote:
>
> Hi,
>
> 1 create group
> 2 g.remove one map listed in the group
> 3 check the REF file list to see if the map name is still there.
>
The ideal approach is to write a test, preferably using Python and
gunittest, which fails showing whats wrong and how to find it out.

> On Dec 19, 2014 5:09 AM, "Huidae Cho"  wrote:
>>
>> Yann,
>>
>> Please be more specific. What is the group REF file and how can I
replicate your issue? And what do you expect to happen?
>>
>> Regards,
>> Huidae
>>
>> --
>> Sent from my phone
>>
>> On Dec 15, 2014 3:49 AM, "Yann Chemin"  wrote:
>>>
>>> Hi,
>>>
>>> did g.remove a raster, and the group REF file referencing the raster
did not update accordingly.
>>>
>>> Is this a known behaviour?
>>> Yann
>>>
>>> --
>>> 
>>>
>>> ___
>>> 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