hi list
would like to know, why such an awful performance while opening a shpefile
(with just 800 polygon features)
in v1.7.4, the file opens just like that.
in v1.8.0, it takes few seconds to render the file, this is bad because if
I have 20 layers enabled, then ever time I move a it takes
Il 11/06/2012 09:01, Ted ha scritto:
hi list
would like to know, why such an awful performance while opening a shpefile
(with just
800 polygon features)
Could you please share it, so we can do more testing?
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details
Adding further; this is my qgis version
QGIS version
1.8.0-Lisboa
QGIS code revision
d77ce93
Compiled against Qt
4.7.1
Running against Qt
4.7.1
Compiled against GDAL/OGR
1.9.1
Running against GDAL/OGR
1.9.1
GEOS Version
3.2.2
PostgreSQL Client Version
8.3.10
SpatiaLite Version
3.0.1
QWT Version
Hi all.
We have severla patches pending. Could we examine and apply them if appropriate
before releasing?
All the best, and thanks.
Messaggio originale
Oggetto: [Quantum-GIS] Fixes for issues #5753 and #5754 (#165)
Data: Sun, 10 Jun 2012 15:24:27 -0700
Mittente: dakcarto
Hi Ted!
QGIS 1.8.0 is still not officially released, but thanks for taking the
time and testing it ..
It would help a lot if you could provide the slow shape file to
developers and testers to confirm the issue you have and probably
solve them BEFORE the official 1.8 release ..
Regarding the
Hi Werner
since the earlier post with zip file is blocked, let me put it in youtube
for reference.
http://www.youtube.com/watch?v=olLjxPjLNyM
this show the sluggishness.
if required, let me know whom to send the file to;
Yes, want the issue (if there is) to be fixed before the release. I'm
Hi Paolo,
On Mon, Jun 11, 2012 at 1:12 AM, Paolo Cavallini cavall...@faunalia.it wrote:
Hi all.
We have severla patches pending. Could we examine and apply them if
appropriate
before releasing?
All the best, and thanks.
Messaggio originale
Oggetto: [Quantum-GIS] Fixes
Hi friends,
I have found that QGIS is not choosing proper 'gid serial' primary key
column when integer column with unique constraint exists in table.
Example:
I have following table called 'vranov.v_budovy':
- gid serial PRIMARY KEY,
- id_cis_supisne_cisla integer REFERENCES
Hi Ivan,
On Mon, 11. Jun 2012 at 11:37:05 +0200, Ivan Mincik wrote:
I have found that QGIS is not choosing proper 'gid serial' primary key
column when integer column with unique constraint exists in table.
That's removed in 1.8. You have to choose the column there. Having a unique
constraint
On 06/11/2012 11:41 AM, Jürgen E. Fischer wrote:
Hi Ivan,
On Mon, 11. Jun 2012 at 11:37:05 +0200, Ivan Mincik wrote:
I have found that QGIS is not choosing proper 'gid serial' primary key
column when integer column with unique constraint exists in table.
That's removed in 1.8. You have
Do I have any chance to force 1.7 to choose correct column in this case?
--
Ivan Mincik
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Hi Giovanni
I think this is a precision problem (client side). At 1:50:000, the
GetPrint request looks like that:
That's removed in 1.8.
I am thinking about 1.7 fix to update column query
(QgsPostgresProvider::getPrimaryKey) to return primary key column first
by adding ordering by 'indisprimary' column:
select indkey from pg_index where indisunique and
indrelid=regclass('vranov.v_budovy')::oid and indpred
Hi All
As many of you have probably seen there are no blockers left in the
queue. Any objects to going ahead with the release now?
Regards
Tim
--
Tim Sutton - QGIS Project Steering Committee Member (Release Manager)
==
Please do not email me
On Mon, 2012-06-11 at 12:54 +0200, Tim Sutton wrote:
Any objects to going ahead with the release now?
go ahead! :)
cheers
-- Giovanni --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
Il 11/06/2012 12:54, Tim Sutton ha scritto:
Hi All
As many of you have probably seen there are no blockers left in the
queue. Any objects to going ahead with the release now?
No objections from our side.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at
On Mon, Jun 11, 2012 at 8:54 PM, Tim Sutton li...@linfiniti.com wrote:
Hi All
As many of you have probably seen there are no blockers left in the
queue. Any objects to going ahead with the release now?
Lets get it out the door so I can start working on all the cool new
things I want in 2.0
Hi Marco,
On Mon, 2012-06-11 at 12:07 +0200, Marco Hugentobler wrote:
Hi Giovanni
I think this is a precision problem (client side). At 1:50:000, the
GetPrint request looks like that:
Hi Giovanni
It's something for the qgis-web-client bug tracker. The client needs to use
more precise floats for the GetPrint request.
Regards, Marco
Von Samsung Galaxy Note gesendet
Original message
Subject: Re: [Qgis-developer] [QGIS Server] print layout
From: Giovanni
Hi Tim
+1 for going ahead with the release. It is one of the rare moments
without blockers now :-) .
Marco
Am 11.06.2012 12:54, schrieb Tim Sutton: Hi All As many of you
have probably seen there are no blockers left in the queue. Any
objects to
Hi All
OK than we will stop accepting blockers for 1.8 and get on with it.
Regards
Tim
On Mon, Jun 11, 2012 at 2:13 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Tim
+1 for going ahead with the release. It is one of the rare moments without
blockers now :-) .
I agree - this has to be fixed in the client. We should add a global
option for that.
The original version was only done for meters, so we did not use more
than one digit after the comma for specifying the print extent.
Can you please open a ticket in the qgis-web-client section?
Thanks,
Il 11/06/2012 14:54, Tim Sutton ha scritto:
Hi All
OK than we will stop accepting blockers for 1.8 and get on with it.
I think we should keep on accepting them: if it is possible we can always
(working in
master) issue a last minute fix, or schedule a bugfix release for later).
All the best.
On 06/11/2012 12:39 PM, Ivan Mincik wrote:
That's removed in 1.8.
I am thinking about 1.7 fix to update column query
(QgsPostgresProvider::getPrimaryKey) to return primary key column first
by adding ordering by 'indisprimary' column:
select indkey from pg_index where indisunique and
1.8 is due for release very soon, soon as in tonight if everything goes
to plan. I very much dout there will ever be a 1.7.5 as we don't have
the man power. Sorry about that.
- Nathan
From: Ivan Mincik
Sent: 12/06/2012 12:05 AM
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] QGIS
Hi all,
I'd prefer to wait few days (e.g. 3 days) before releasing 1.8
to be sure the latest fixes haven't generated new issues.
After the 1.7.x series with a lot of problems just after the releases,
we should release a stable version of QGis.
Regards
On Mon, Jun 11, 2012 at 2:29 PM, Paolo
Hi
I will wait till tomorrow night and then go ahead and tag branch if there
are no new blockers reported.
Regards
Tim
On Jun 11, 2012 5:47 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote:
Hi all,
I'd prefer to wait few days (e.g. 3 days) before releasing 1.8
to be sure the latest fixes
27 matches
Mail list logo
