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 long
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 deta
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
5.
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
A: Paol
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 Pos
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 jus
Hi Paolo,
On Mon, Jun 11, 2012 at 1:12 AM, Paolo Cavallini 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 for issues #575
Hi Ted!
Tested your files with 3 persons on 5 different computers .. no
performance problem so far ..
Maybe you should just wait for 1.8 final ..
As far as I can see the problem is not a QGIS one .. probably it's on
your side? (computer?)
Sorry to not confirm your problems here ..
kind regards
W
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
gisdata.t_cis_supi
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
constrain
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. Yo
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:
http://mapserver.uevora.pt/cgi-bin/qgis_mapserv.fcgi?map=/var/www/qgis-web-client/projects/helloworld.qgs&SERVICE=WMS&VERSION=1.3&REQUEST=GetPrint&FORMAT=pdf&EXCEPTIONS=application
> 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 indp
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 off-lis
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
http://lists.osgeo.org/mailman/listinfo/qgis-de
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 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 ;)
- Nathan
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:
>
> http://mapserver.uevora.pt/cgi-bin/qgis_mapserv.fcgi?map=/var/www/qgis-web-client/projects/helloworl
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 Man
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
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
> bloc
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,
And
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 bes
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 an
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 Cava
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" wrote:
> 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 genera
28 matches
Mail list logo
