Re: [QGIS-Developer] QGIS 2.18.x Attribute Table Performance

[Ted]

Hi Giovanni

Yes, confirm that it is working well now
https://www.youtube.com/watch?v=qBh0pzI2A5c

from over 2 min to 4 seconds to load the same table.

BIG thanks for everyone behind the scene. I believe the fix is done by
Nyall, so a spacial thanks to him.

read over and understand that this issue was in discussion for quite some
time. Glad its fixed now.

Cheers
ted


On Fri, May 26, 2017 at 4:59 PM, Giovanni Manghi <giovanni.man...@gmail.com>
wrote:

> Hi, know issue,
>
> already lengthly analyzed and already fixed, just wait for the next
> builds (2.18.9).
>
>
> cheers
>
> -- G --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS 2.18.x Attribute Table Performance

[Ted]

Hi,

I'm facing a HIGHLY DEGRADED performance with attribute table opening with
version 2.18.x (2.18.8 and 2.18.7) when we have more than 100K rows. (in
this case 161K)

I'm looking at an OLD application done 5 years back with a custom QGIS 1.7,
PostgreSQL 9.0 and PostGIS.

The performance at that time was high commendable and it worked very well.
See the video here;
https://www.youtube.com/watch?v=3rjeqgFK5GA
(this video was taken on a Virtual Machine)

Recently we stepped into upgrade the technology stack and to my surprise,
the current version of QGIS 2.18.8 is way TOO slow and this goes all
against the QGIS in the Government environment.

While keeping the DB on the VM environment, we tested it on different
platform and version;

QGIS 2.18.8 (latest) ruining on Windows 10 environment
https://www.youtube.com/watch?v=k19tEqSK-1Y=64s
Took nearly 2 minutes to open !!!

QGIS 2.18.7 ruining on MacOS environment
https://www.youtube.com/watch?v=S1eg2K17Z1E=15s
Again took more than 2 minutes to open !!!

QGIS 2.14.14 (LTR) ruining on MacOS environment
https://www.youtube.com/watch?v=Sv-qklLFCHA
Took only 5 seconds to open :)


So, it appears that something has gone SERIOUSLY WRONG between the version
2.14.x and 2.18.x

Since 2.18.x is marked as LTR version, I really hope this issue is fixed
since most of the government environments adopt only the LTR version and
with such performance it goes against QGIS.

The next LTR is 3.2 which is more than a year later. Can you please look
into this issue?

Thanks and Cheers !


Ted
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] SAGA GIS 3.0

[Ted]

The current QGIS ships with SAGA-GIS 2.1.2.

There are many version since 2.1.2 and the latest version of SAGA-GIS is 3.0

Wonder if QGIS 3.0 will use SAGA-GIS 3.0.

http://www.saga-gis.org/saga_tool_doc/index.html


Thanks

ted
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Download of QGIS 2.18 Windows 64 bit does not work ?

[Ted]

try this for now, till they fix it

http://www.norbit.de/~jef/QGIS-OSGeo4W-2.18.0-1-Setup-x86_64.exe


On Mon, Oct 24, 2016 at 4:57 PM, Geo DrinX  wrote:

> also 32 bit does not work.
>
> 2016-10-24 10:56 GMT+02:00 Geo DrinX :
>
>> Not Found
>>
>> The requested URL /downloads/QGIS-OSGeo4W-2.18.0-1-Setup-x86_64.exe was
>> not found on this server.
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

[Ted]

Hi Richard, Matthias, All

Yes, the crash problem is gone in master (nightly built) version. Thanks a
lot for the fix.  Tested it on Win 7 x64 and also Win XP x32.

Just for note, that issue is reported in v2.0.1 and v2.2 releases.

Will wait for the v2.4 release in July.


Regards
Ted





On Wed, Jun 25, 2014 at 5:02 PM, Bernhard Ströbl bernhard.stro...@jena.de
wrote:

 Hi Nyall,

 thanks for clarification!
 However I would say that even if using a projected coordinate system (map
 units m) scalebars are not neccessarily accurate all over the map: if your
 map covers a small area this may hold true but not if you look at
 continents.

 Bernhard

 Am 25.06.2014 00:13, schrieb Nyall Dawson:

  On 25 June 2014 01:20, Bernhard Ströbl bernhard.stro...@jena.de wrote:

  It does also matter in degrees, depending on the projection. same in
 meters: 1 cm on the map represents always a certain distance in
 reality (though this distance varies troughout the map depending on
 the projection and the area covered). If you look at the Lambert map,
 you realize that the distance between two parallels (10 degrees!)
 increases towards the pole, although in reality it is always (10*110km
 =) 1100 km. In the WGS84 map the distance between the parallels is
 constant but so is the distance between the meridians, but this is
 false as the distance gets less towards the pole in reality. So a
 scalebar (in m) being accurate in the middle of the map becomes less
 accurate towards the edges. Hence my question on which base the
 scalebar is calculated.



 The question absolutely makes sense but I don't know the answer :)



 Could you check? or whom would we have to ask?


 It's calculated this way:

 If you're working in a projected coordinate system (ie, map units are
 metres):

 - Take the current extent of the map, calculate the width (x max - x
 min), divide this by the width on paper of the map

 If you're working in a geographic coordinate system (ie, map units are
 degrees):

 - Convert the width of the map (map's extent x max - x min) from
 degrees to metres, using a variant of the Haversine formula, and
 treating the current latitude as the MIDDLE LATITUDE from the map's
 extent
 - Convert this distance to a scale by dividing by the width on paper of
 the map

 So, yes, scalebars using m/km/miles/etc are only an approximation when
 map units are degrees, and are very inaccurate when used with maps
 covering a large area or for areas far from the equator.

 Nyall




 __ Information from ESET Mail Security, version of virus signature
 database 9997 (20140625) __


 The message was checked by ESET Mail Security.
 http://www.eset.com


 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

[Ted]

Hi Jorge Tornero, Bernhard, Matthias, Nyall, All

Thanks for taking up the scalebar issue.

I agree that in most cases, the scalebar is more of an academic /
customary. It hardly gives a true measurement.

Users generally use that as means of comparison and not to measure the
exact distance.

IMO, the scalebar makes sense when you have maps in large scales like 1:100
better. Otherwise, its just an estimation.

Hope QGIS can provide a solution.

Regards
Ted


On Fri, Jun 27, 2014 at 1:27 PM, Ted tiruchirapa...@gmail.com wrote:

 Hi Richard, Matthias, All

 Yes, the crash problem is gone in master (nightly built) version. Thanks a
 lot for the fix.  Tested it on Win 7 x64 and also Win XP x32.

 Just for note, that issue is reported in v2.0.1 and v2.2 releases.

 Will wait for the v2.4 release in July.


 Regards
 Ted





 On Wed, Jun 25, 2014 at 5:02 PM, Bernhard Ströbl bernhard.stro...@jena.de
  wrote:

 Hi Nyall,

 thanks for clarification!
 However I would say that even if using a projected coordinate system (map
 units m) scalebars are not neccessarily accurate all over the map: if your
 map covers a small area this may hold true but not if you look at
 continents.

 Bernhard

 Am 25.06.2014 00:13, schrieb Nyall Dawson:

  On 25 June 2014 01:20, Bernhard Ströbl bernhard.stro...@jena.de wrote:

  It does also matter in degrees, depending on the projection. same in
 meters: 1 cm on the map represents always a certain distance in
 reality (though this distance varies troughout the map depending on
 the projection and the area covered). If you look at the Lambert map,
 you realize that the distance between two parallels (10 degrees!)
 increases towards the pole, although in reality it is always (10*110km
 =) 1100 km. In the WGS84 map the distance between the parallels is
 constant but so is the distance between the meridians, but this is
 false as the distance gets less towards the pole in reality. So a
 scalebar (in m) being accurate in the middle of the map becomes less
 accurate towards the edges. Hence my question on which base the
 scalebar is calculated.



 The question absolutely makes sense but I don't know the answer :)



 Could you check? or whom would we have to ask?


 It's calculated this way:

 If you're working in a projected coordinate system (ie, map units are
 metres):

 - Take the current extent of the map, calculate the width (x max - x
 min), divide this by the width on paper of the map

 If you're working in a geographic coordinate system (ie, map units are
 degrees):

 - Convert the width of the map (map's extent x max - x min) from
 degrees to metres, using a variant of the Haversine formula, and
 treating the current latitude as the MIDDLE LATITUDE from the map's
 extent
 - Convert this distance to a scale by dividing by the width on paper of
 the map

 So, yes, scalebars using m/km/miles/etc are only an approximation when
 map units are degrees, and are very inaccurate when used with maps
 covering a large area or for areas far from the equator.

 Nyall




 __ Information from ESET Mail Security, version of virus
 signature database 9997 (20140625) __


 The message was checked by ESET Mail Security.
 http://www.eset.com


 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS Crash - Serious problem in 2x

[Ted]

Hi Developers

Encountered a very serious problem, looks like this issue is there in 2.x

Ways to reproduce;

1. Add a world boundary shp file in wgs84 (you can use other files too)
http://thematicmapping.org/downloads/world_borders.php

2. Open the print composer, add a new map

3. add scale bar

4. close the composer, return back

5 remove the layer from layer list

6. boom, qgis crash


hope you can fix this soon, thanks


The scale bar issue

1. When a file is degree (wgs84), the scale-bar in print composer is
useless since its trying to use the map unit.

2. Its logical that, in map composer its always linear map unit as in
meter, feet, km, etc

3. using qgis in schools and this pose a serious issue, since the users
dont understand projection etc.

4. the expected behavior is, immaterial of underlying projection the
scale-bar should have the option to use linear map unit, specially meters,
km, mile

5. read in stackexchange, this is a known issue. hope the dev community can
help to fix this one.


thanks a lot.

hurt my fingers, not able to type proper :(


cheers
ted
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

[Ted]

forgot,

using Windows OS

Win 7 Professional x64


Thanks

Ted




On Tue, Jun 24, 2014 at 7:27 AM, Ted tiruchirapa...@gmail.com wrote:

 Hi Developers

 Encountered a very serious problem, looks like this issue is there in 2.x

 Ways to reproduce;

 1. Add a world boundary shp file in wgs84 (you can use other files too)
 http://thematicmapping.org/downloads/world_borders.php

 2. Open the print composer, add a new map

 3. add scale bar

 4. close the composer, return back

 5 remove the layer from layer list

 6. boom, qgis crash


 hope you can fix this soon, thanks


 The scale bar issue

 1. When a file is degree (wgs84), the scale-bar in print composer is
 useless since its trying to use the map unit.

 2. Its logical that, in map composer its always linear map unit as in
 meter, feet, km, etc

 3. using qgis in schools and this pose a serious issue, since the users
 dont understand projection etc.

 4. the expected behavior is, immaterial of underlying projection the
 scale-bar should have the option to use linear map unit, specially meters,
 km, mile

 5. read in stackexchange, this is a known issue. hope the dev community
 can help to fix this one.


 thanks a lot.

 hurt my fingers, not able to type proper :(


 cheers
 ted







___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Master branch splash screen

[Ted]

Think the issue is dragged for no reason. We have a dev / master branch
splash screen that says 1.9 alpha while we debate on leaf ...

its important to have a splash screen that's relevant. So, high time that
we change that.

The debate can go on after that.

My 2 cents


Ted




On Sun, Sep 8, 2013 at 4:56 PM, Anita Graser anitagra...@gmx.at wrote:

 Hi Larry,

 Am 07.09.2013, 19:29 Uhr, schrieb Larry Shaffer lar...@dakotacarto.com:

 On Sat, Sep 7, 2013 at 2:26 AM, Anita Graser anitagra...@gmx.at wrote:

 next try: https://dl.dropboxusercontent.com/u/42637169/qgis21_**
 1generic.pnghttps://dl.**dropboxusercontent.com/u/**
 42637169/qgis21_1generic.pnghttps://dl.dropboxusercontent.com/u/42637169/qgis21_1generic.png
 

 now in green with dev instead of 2.1 :)


 I like the layout and color selection. Not sure I understand the leaf (?)
 background, though QGIS is used quite a bit for forestry and bio-sciences.


 I just like the colors. It will only be used for a couple of days, and
 there are a lot of other things that still requrire attention before the
 Hackfest and FOSS4G, so I think I'll leave it.


  Just a thought: maybe instead try a bunch of translucent icons (new icons
 for add layers?) floating/swirling around. I realize this is just an
 interim splash, but could be something like that might make a good graphic
 for the web site as well. That really is one of QGIS strongest core
 features: its ability to work with so many providers, both open and
 proprietary. Plus those new layer icons look good.


 Sorry, I don't think I can pull that off.


  If the new group photo is similar to the last two (a row or two of faces),
 then the use of both dev and master words in the layout means dev may
 cover
 some faces. 'Master' is really from git nomenclature, while dev is
 probably
 more commonly understood. So, I suggest just removing master and lowering
 dev to make more room for the photo. Maybe try dev in the master's yellow,
 then.


 Once we have some photos to chose from, I'm sure we'll find a way to make
 a decent splash. I'm not emotionally invested in either master or dev
 use. If we need the space, I'll happily get rid of master.

 Best wishes,
 Anita






 Regards,

 Larry



  Best wishes,
 Anita


 Am 07.09.2013, 10:05 Uhr, schrieb Nathan Woodrow madman...@gmail.com:

  Yes which is why I would rather not give the dev builds numbers apart
 from

 a commit ID and how far pass the last git tag it was.
 http://stackoverflow.com/questions/3300746/deriving-**http://stackoverflow.com/**questions/3300746/deriving-**
 application-build-version-from-git-describe-how-to-get-***
 *a-relativelyhttp://**stackoverflow.com/questions/**
 3300746/deriving-application-**build-version-from-git-**
 describe-how-to-get-a-**relativelyhttp://stackoverflow.com/questions/3300746/deriving-application-build-version-from-git-describe-how-to-get-a-relatively
 


 - Nathan


 On Sat, Sep 7, 2013 at 5:53 PM, Ramon Andiñach cust...@westnet.com.au
 wrote:

  Just for curiosity, did anyone have that problem with 1.9?


 -ramon.

 On 07/09/2013, at 15:40 , Nathan Woodrow wrote:

  Hey Anita,
 
  I would just remove the 2.1 number as people might thing it's a
 released
 version. Maybe replace it with Dev
 
  - Nathan
 
 
  On Sat, Sep 7, 2013 at 5:34 PM, Anita Graser anitagra...@gmx.at
 wrote:
  Hi Larry,
 
  Here's a generic 2.1 splash
  https://dl.dropboxusercontent.com/u/42637169/qgis21_
 0generic.pnghttps://dl.**dropboxusercontent.com/u/**
 42637169/qgis21_0generic.pnghttps://dl.dropboxusercontent.com/u/42637169/qgis21_0generic.png
 

 
  Best wishes,
  Anita
 
 
 
  Am 06.09.2013, 21:20 Uhr, schrieb Larry Shaffer 
 lar...@dakotacarto.com
 :
 
 
  Hi Anita,
 
  On Fri, Sep 6, 2013 at 12:33 PM, Anita Graser anitagra...@gmx.at
 wrote:
 
  Is it ok if we take a pic in Brighton?
 
 
  +1 from me. I think that's an excellent choice of photo.
 
 
  It could be something generic until then. If you want, I  can whip
  something up.
 
 
  Right now, any users checking out the latest nightly are presented
 with a
  splash that denotes 1.9 (assuming they have the splash turned on)
 instead
  of 2.1. Not a big deal, but could confuse some users.
 
  Maybe replace that with a new layout that will basically be the same
 as
  when the Brighton photo is included? May be good to have the layout's
 style
  be similar to the new stable version's splash, e.g. square corners
 and
  choice of font; but, not too similar, so it is easy to see at a
 glance
  which version you have launched.
 
  Regards,
 
  Larry
 
 
  Best wishes
  Anita
 
  On Fri, Sep 6, 2013 at 7:49 PM, Larry Shaffer 
 lar...@dakotacarto.com
  wrote:
   Hi,
  
   Does anyone have an idea for what the splash screen of the master
 branch
   builds should be?
  
   Regards,
  
   Larry
  
   ___
   Qgis-developer mailing list
   Qgis-developer@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/qgis

Re: [Qgis-developer] QGIS 2.0 Release Date

[Ted]

Hi Tim

Thank you for the information.

Looking forward to this great release. Agree, better late than a buggy
release.


Regards
ted






On Fri, Jun 7, 2013 at 10:48 PM, Tim Sutton li...@linfiniti.com wrote:

 Hi Ted

 At the moment the release looks like it will be delayed by at least
 3-4 weeks - there are still around 80 blocker tickets and we had some
 last minute changes we wanted to incorporate into the 2.0 relelase. I
 will be posting a new release timeline early next week.

 Regards

 Tim

 On Fri, Jun 7, 2013 at 6:08 AM, Ted tiruchirapa...@gmail.com wrote:
  Hi,
 
  Its 7th June today and the (original) scheduled release date for QGIS v
 2.0
 
  We are aware that, its been postponed due to multiples issues.
 
  Can you please define a new release date ?
 
 
  Thanks
 
  ted
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 



 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Visit http://linfiniti.com to find out about:
  * QGIS programming and support services
  * Mapserver and PostGIS based hosting plans
  * FOSS Consulting Services
 Skype: timlinux
 Irc: timlinux on #qgis at freenode.net
 ==

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Geopackage, Spatialite v4.1 QGIS v2.0

[Ted]

All,

Spatialite 4.1 released recently. As far as I understand, the proposed
OGC's GeoPackage is based on spatialite.

For long time, I notice that spatiliate is kind of ignored (may be due to
interest level) and never got the full attention of the developer. Even
today, the only version supported is sptialite 3.8 in spite of v4.0 having
some great features.

Is it possible to have a full support for spatialite in upcoming releases,
if not v2.0. This will give put QGIS in ahead in race. Really like to see
v4.1 supported out of the box in QGIS 2.0 is possible.

Then, when GeoPakage nears approval, QGIS can become a reference
implementation (with modification)

Cross fingers :)


regards
ted
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 1.8 Windows Standalone is not OK with spatialite versions

[Ted]

the direct link for download

http://download.intergraph.com/software/2011/ECWJP2K_4_3_6_25/ECWJP2SDKSetup_RO.exe



On Tue, Jan 15, 2013 at 6:57 AM, Ted tiruchirapa...@gmail.com wrote:

 Ramon

 the current product manage for ECW is Chris Tweedie,
 chris.twee...@intergraph.com  and for your good, he is based out of oz.
 so can you please get in touch with him and help us clear this doubt?

 the current version is 4.3 and the installer is password protected. You
 can download it freely from intergraph site.

 http://geospatial.intergraph.com/products/other/ecw/erdasecwjpeg2000sdk/downloads/ERDAS_ECW_JP2_SDK_Desktop_Read-Only_Version_4_3.aspx


 the licensing agreement and the rest of the literature are here

 http://geospatial.intergraph.com/products/other/ecw/erdasecwjpeg2000sdk/ProductLiterature.aspx

 I really hope to get the ECW support back in GDAL and QGIS before v2
 release.


 Cheers

 Ted





 On Mon, Nov 19, 2012 at 1:11 PM, Ramon Andiñach cust...@westnet.com.auwrote:


 On 18/11/2012, at 15:10 , Paolo Cavallini wrote:

  Il 15/11/2012 21:52, haubourg ha scritto:
 
  Is there anything I can do (paying someone to spend a few days
 clarifying
  ECW situation) or are we trapped by ERDAS??
 
  Hi all.
  I understand the problem. I asked directly ERDAS a few years ago, so we
 had precise
  guidelines. Now things have changed, so I'd suggest to:
  - ask again the proprietary of the ECW software and patents about what
 we can and
  what we can't do
  - if they come out with reasonable requests, we can follow them
  - if not, I guess the only option for corporate users is to prepare ad
 hoc packages
  for redistribution within the company, as this might be allowed by the
 licence.
  All the best.

 Is this possible?
 or has the horse bolted?

 I'd volunteer to send the letter, but it should probably come from higher
 up the food chain than me :)
 However, I'd be willing to reframe the letter so that they were made
 aware that there were users that they'd miss out on if they didn't give you
 reasonable guidelines.
 (and send it on a regular basis until you got an answer)

 -ramon.

 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Announcing the release of QGIS 1.8

[Ted]

A Big Congratulation to the QGIS Team and Tim

Well done and go go go ...


Cheers
Ted





On Thu, Jun 21, 2012 at 5:25 PM, Ivan Mincik ivan.min...@gmail.com wrote:

 Thanks a lot for your work.

 --
 Ivan Mincik
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] awful shapfile performance in v1.8

[Ted]

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 longer time to
render the files.


i'm using Windows 7 Pro x64 with 8Gb RAM.
latest v1.8.0 - QGIS code revision d77ce93 (26 may)

installed using osgeo4w installer.


thanks

Ted
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] awful shapfile performance in v1.8

[Ted]

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.2.1
This copy of QGIS writes debugging output.


why is the postgresql client version staill at 8.3, while we have
postgresql at 9.1 and soon 9.2


Thanks
Ted





On Mon, Jun 11, 2012 at 3:01 PM, Ted tiruchirapa...@gmail.com wrote:

 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 longer time to
 render the files.


 i'm using Windows 7 Pro x64 with 8Gb RAM.
 latest v1.8.0 - QGIS code revision d77ce93 (26 may)

 installed using osgeo4w installer.


 thanks

 Ted



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] awful shapfile performance in v1.8

[Ted]

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 just
a tester.


Thanks

Ted



On Mon, Jun 11, 2012 at 3:35 PM, Werner Macho werner.ma...@gmail.comwrote:

 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 Postgresql Provider .. Well I think there will also be
 some changes in 1.8.0 so just be patient ..
 And remember .. solving problems without knowing the problem (at my
 computer everything is fast - even with a 3000 polygon shapefile) is
 hard ..

 kind regards
 Werner


 On Mon, Jun 11, 2012 at 9:05 AM, Ted tiruchirapa...@gmail.com wrote:
  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.2.1
  This copy of QGIS writes debugging output.
 
 
  why is the postgresql client version staill at 8.3, while we have
 postgresql
  at 9.1 and soon 9.2
 
 
  Thanks
  Ted
 
 
 
 
 
  On Mon, Jun 11, 2012 at 3:01 PM, Ted tiruchirapa...@gmail.com wrote:
 
  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 longer time
 to
  render the files.
 
 
  i'm using Windows 7 Pro x64 with 8Gb RAM.
  latest v1.8.0 - QGIS code revision d77ce93 (26 may)
 
  installed using osgeo4w installer.
 
 
  thanks
 
  Ted
 
 
 
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer