I can do backports when I receive any feedback. These backports are
long-standing issue (since beginning of April). My suggestion is to
mark RC1 tomorrow if possible...
I don't see how this can create any problems, and it does solve the one of having a link to a non-existing table, so I would say +1 for backport.
r62091 - vector/v.select: speed up OP_OVERLAP - Author: mmetz 2014-09-26
I've only tested this very briefly, but results seem identical and the speedup is very significant, so I would plead for backport, but MarkusM should have the last word on this.
No idea on this particular fix, but I have the feeling that the whole encoding handling could need a serious overall reflection with a clear definition of coding rules. AFAIU, at this stage we have different "solutions" across the code and that none are really satisfactory, especially as none is really implemented in a global and unified way.
I don't see how this can create any problems, and it does solve the one of
having a link to a non-existing table, so I would say +1 for backport.
+1 also here
r62091 - vector/v.select: speed up OP_OVERLAP - Author: mmetz 2014-09-26
I've only tested this very briefly, but results seem identical and the
speedup is very significant, so I would plead for backport, but MarkusM
should have the last word on this.
No idea on this particular fix, but I have the feeling that the whole
encoding handling could need a serious overall reflection with a clear
definition of coding rules. AFAIU, at this stage we have different
"solutions" across the code and that none are really satisfactory,
especially as none is really implemented in a global and unified way.
On Mon, Jun 8, 2015 at 8:51 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 07/06/15 23:10, Markus Neteler wrote:
r62091 - vector/v.select: speed up OP_OVERLAP - Author: mmetz 2014-09-26
I've only tested this very briefly, but results seem identical and the
speedup is very significant, so I would plead for backport, but MarkusM
should have the last word on this.
On Mon, Jun 8, 2015 at 3:05 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 08/06/15 14:27, Markus Neteler wrote:
On Mon, Jun 8, 2015 at 8:51 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 07/06/15 23:10, Markus Neteler wrote:
r62091 - vector/v.select: speed up OP_OVERLAP - Author: mmetz 2014-09-26
I've only tested this very briefly, but results seem identical and the
speedup is very significant, so I would plead for backport, but MarkusM
should have the last word on this.
Ah, this does look quite heavy, indeed. Has anyone else had time to test ?
Yes, I am testing (and it has been in place since Sept 2014).
Here the comparison, in GRASS 7.0.1svn (nc_spm_08_grass7):~ >
# old version:
v.buffer input=railroads output=railroads_buf20m distance=20
time -p v.select ainput=zipcodes_wake binput=railroads_buf20m
output=zipcodes_wake_railroads operator=overlap
v.select complete. 171 features written to output.
real 125.23
user 82.05
sys 42.61
time -p v.select ainput=zipcodes_wake binput=railroads_buf20m
output=zipcodes_wake_railroads operator=overlap
v.select complete. 171 features written to output.
real 6.72
user 4.42
sys 2.03
On Mon, Jun 8, 2015 at 11:50 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2015-06-08 23:37 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl Date:
Feb 2, 2015
then we should also backport r64406 and probably others, it's seems to
me that it's not necessary to backport these changes.
ok - I cannot judge and GUI is always a weak thing with all the Python
portability issues...
I earlier just skimmed through my list of flagged commits.
2015-06-08 23:52 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
then we should also backport r64406 and probably others, it's seems to
me that it's not necessary to backport these changes.
ok - I cannot judge and GUI is always a weak thing with all the Python
portability issues...
I earlier just skimmed through my list of flagged commits.
my suggestion is to backport it immediately after we release 7.0.1
[1], to have time to do more tests. I will do it. Martin
In 70 release branch, I’m not able to use PostgreSQL attribute table but it works in trunk. I think that this is thanks to r65057. The bug was probably also reason for encountering #2626.
In 70 release branch, I'm not able to use PostgreSQL attribute table but it
works in trunk. I think that this is thanks to r65057. The bug was probably
also reason for encountering #2626.