Re: [Qgis-developer] 1.7.1 Branch created
It would be great if folks would test it compiles on their platform and generally behaves ok. I have configured our Pbuilder for daily builds for Debian Squeeze. Until now it builds fine. -- Ivan Mincik, Gista s.r.o. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Georeferencing headeaches
Hi Alister I find that before I define any points with a BMP loaded the georeferencer window coordinates have no relationship to the pixel position. So it doesn't work with zero points! I then save the BMP as a TIFF and try again. This time the georeferencer window coordinates are displayed in pixels as expected and the image can be georeferenced as expected. Can anyone else reproduce this behaviour? Andrew Chapman Hi Andrew. I think I have always got stupid results like that when trying to use more than two control points with the linear transformation. Does it work if you only use two points? I did think there was a bug report for this, but I can't see it now. Alister ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] API 2.0
Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType(). I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: API 2.0
Also QgsRasterLayer::usesProvider() should be deprecated because file-based rasters use gdal provider now. On Mon, Sep 12, 2011 at 1:39 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType(). I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: API 2.0
Hi Giuseppe feel free to mark the such methods as deprecated - when we start cleaning the API it will be handy. Martin On Mon, Sep 12, 2011 at 2:22 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Also QgsRasterLayer::usesProvider() should be deprecated because file-based rasters use gdal provider now. On Mon, Sep 12, 2011 at 1:39 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType(). I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli -- Giuseppe Sucameli ___ 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] Re: API 2.0
Hi! Probably a WIKI page with proposed API updates/cleanings? Could be handy for Documentation afterwards too regards Werner Am 12.09.2011 14:28, schrieb Martin Dobias: Hi Giuseppe feel free to mark the such methods as deprecated - when we start cleaning the API it will be handy. Martin On Mon, Sep 12, 2011 at 2:22 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Also QgsRasterLayer::usesProvider() should be deprecated because file-based rasters use gdal provider now. On Mon, Sep 12, 2011 at 1:39 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType(). I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli -- Giuseppe Sucameli ___ 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: API 2.0
FYI http://stackoverflow.com/questions/6596364/tracking-c-lib-public-api-changes I asked a question on there on how we can generate a report with API changes. If we could weave this into the build process it would be even better. - Nathan On Mon, Sep 12, 2011 at 10:30 PM, Werner Macho werner.ma...@gmail.comwrote: Hi! Probably a WIKI page with proposed API updates/cleanings? Could be handy for Documentation afterwards too regards Werner Am 12.09.2011 14:28, schrieb Martin Dobias: Hi Giuseppe feel free to mark the such methods as deprecated - when we start cleaning the API it will be handy. Martin On Mon, Sep 12, 2011 at 2:22 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Also QgsRasterLayer::usesProvider() should be deprecated because file-based rasters use gdal provider now. On Mon, Sep 12, 2011 at 1:39 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType()**. I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli -- Giuseppe Sucameli __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] Re: API 2.0
Another useful method: QgsDataProvider.searchForFeatures ( fieldIndex, searchString, searchMethod = 0 ) fieldIndex: search on idx-th field; searchString: search terms; searchMethod: 0x1 = match whole searchString 0x2 = search inside values; it returns an array of found features. qgis-developer-boun...@lists.osgeo.org scritti il 12/09/2011 14.30.59 Hi! Probably a WIKI page with proposed API updates/cleanings? Could be handy for Documentation afterwards too regards Werner Am 12.09.2011 14:28, schrieb Martin Dobias: Hi Giuseppe feel free to mark the such methods as deprecated - when we start cleaning the API it will be handy. Martin On Mon, Sep 12, 2011 at 2:22 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Also QgsRasterLayer::usesProvider() should be deprecated because file-based rasters use gdal provider now. On Mon, Sep 12, 2011 at 1:39 PM, Giuseppe Sucameli brush.ty...@gmail.com wrote: Hi devs, thinking to 2.0, we should uniform API by using the same name for these methods QgsRasterLayer::providerKey() and QgsVectorLayer::providerType(). I think is better to use providerType() for both them. Cheers. -- Giuseppe Sucameli -- Giuseppe Sucameli ___ 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 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] 1.7.1 Branch created
Le 11/09/2011 21:19, Tim Sutton a écrit : Hi On Sun, Sep 11, 2011 at 8:48 PM, MORREALE Jean Roc jr.morre...@enoreth.net wrote: Le 08/09/2011 00:14, Tim Sutton a écrit : Hi Folks I have created a branch for 1.7.1. git branch --track release-1_7_1 origin/release-1_7_1 Origin being the main git repo. It would be great if folks would test it compiles on their platform and generally behaves ok. I have a few more things to change before we tag it for the 1.7.1 release. Please consider the old 1_7_0 branch permanently frozen and apply any backports to the 1.7.1 branch. After the release, I will immediately branch 1.7.2 so that it is a bit more obvious which branch should be on the receiving end of your backports. Best regards Hi Tim, Could you tell me how to correctly add this branch to my local repo ? I've been trying checkout/fetch/pull release-1_7_1 from origin or upstream but it always gets ugly when merging. git branch --track release-1_7_1 origin/release-1_7_1 Above should do it for you then after that: git checkout release-1_7_1 git pull origin release-1_7_1 The changes I would like to make are already in master but as I didn't use properly the BACKPORT tag they're not in this branch, one could be directly merged from master (doc/TRANSLATORS). If you can identify the commit id of your original commit, you can simply use cherry-pick to apply it (while inside the release branch): git cherry-pickhash Then push it up to the release branch: git push origin release-1_7_1 Hope that helps! Regards Tim it worked, thanks :) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Wroclaw taking several minutes to load a single postgis polygon
The table has only a single row. Normally it loads instantly. Suddenly
its taking a very long time. Here's the output from postgres:
2011-09-12 19:50:26 CDT STATEMENT: select
estimated_extent('public','region_boundary','the_geom')
2011-09-12 19:50:26 CDT LOG: statement: select extent(the_geom)
from public.region_boundary
2011-09-12 19:50:26 CDT LOG: duration: 0.519 ms
2011-09-12 19:54:07 CDT LOG: duration: 228246.691 ms
2011-09-12 19:54:07 CDT LOG: statement: BEGIN READ ONLY
2011-09-12 19:54:07 CDT LOG: duration: 0.145 ms
2011-09-12 19:54:07 CDT LOG: statement: declare qgisf0 binary cursor
for select gid,asbinary(the_geom,'NDR') from
public.region_boundary where the_geom
setsrid('BOX3D(-5826044.8984273653477430 -6024214.2690353775396943,
7145528.0523074865341187 3985583.1240626471117139)'::box3d,900914)
2011-09-12 19:54:08 CDT LOG: duration: 73.467 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 8.667 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.107 ms
2011-09-12 19:54:08 CDT LOG: statement: CLOSE qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.050 ms
2011-09-12 19:54:08 CDT LOG: statement: COMMIT
2011-09-12 19:54:08 CDT LOG: duration: 0.057 ms
Anybody have an idea about this one?
THK
--
Timothy H. Keitt
http://www.keittlab.org/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Wroclaw taking several minutes to load a single postgis polygon
Yes. Loading one postgis table causes a scan of data related to all
other tables in the database. The query below appears in the
postgresql log, but it is not the table loaded into qgis. The query
took more than 6 minutes.
THK
2011-09-12 21:09:34 CDT LOG: duration: 394152.953 ms statement:
select distinct case when geometrytype(the_geom) IN
('POINT','MULTIPOINT') THEN 'POINT' when geometrytype(the_geom) IN
('LINESTRING','MULTILINESTRING') THEN 'LINESTRING' when
geometrytype(the_geom) IN ('POLYGON','MULTIPOLYGON') THEN 'POLYGON'
end from public.dual_cmtc_geom
On Mon, Sep 12, 2011 at 9:00 PM, Tim Keitt tke...@gmail.com wrote:
I see that the output is not so helpful below because the log is not
serialized.
Anyway, I think I have an answer. There is a table in the database
with 1.2 billion rows. Somehow loading any table from that database
is triggering a scan of the very large table, perhaps all tables in
the database. I dumped the smaller tables and made a new database and
it is quick again.
I will see if I can serialize the log output and report back.
THK
On Mon, Sep 12, 2011 at 7:59 PM, Tim Keitt tke...@gmail.com wrote:
The table has only a single row. Normally it loads instantly. Suddenly
its taking a very long time. Here's the output from postgres:
2011-09-12 19:50:26 CDT STATEMENT: select
estimated_extent('public','region_boundary','the_geom')
2011-09-12 19:50:26 CDT LOG: statement: select extent(the_geom)
from public.region_boundary
2011-09-12 19:50:26 CDT LOG: duration: 0.519 ms
2011-09-12 19:54:07 CDT LOG: duration: 228246.691 ms
2011-09-12 19:54:07 CDT LOG: statement: BEGIN READ ONLY
2011-09-12 19:54:07 CDT LOG: duration: 0.145 ms
2011-09-12 19:54:07 CDT LOG: statement: declare qgisf0 binary cursor
for select gid,asbinary(the_geom,'NDR') from
public.region_boundary where the_geom
setsrid('BOX3D(-5826044.8984273653477430 -6024214.2690353775396943,
7145528.0523074865341187 3985583.1240626471117139)'::box3d,900914)
2011-09-12 19:54:08 CDT LOG: duration: 73.467 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 8.667 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.107 ms
2011-09-12 19:54:08 CDT LOG: statement: CLOSE qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.050 ms
2011-09-12 19:54:08 CDT LOG: statement: COMMIT
2011-09-12 19:54:08 CDT LOG: duration: 0.057 ms
Anybody have an idea about this one?
THK
--
Timothy H. Keitt
http://www.keittlab.org/
--
Timothy H. Keitt
http://www.keittlab.org/
--
Timothy H. Keitt
http://www.keittlab.org/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: Wroclaw taking several minutes to load a single postgis polygon
Hi Tim,
It sounds to me like it is trying to determine the primary key.
Does it load quicker if you manually specify the primary key column?
It sounds strange to me though that a scan is already happening on the
other tables, unless they are connected (say through a join or foreign
key or something else).
Andreas
On 09/13/2011 04:15 AM, Tim Keitt wrote:
Yes. Loading one postgis table causes a scan of data related to all
other tables in the database. The query below appears in the
postgresql log, but it is not the table loaded into qgis. The query
took more than 6 minutes.
THK
2011-09-12 21:09:34 CDT LOG: duration: 394152.953 ms statement:
select distinct case when geometrytype(the_geom) IN
('POINT','MULTIPOINT') THEN 'POINT' when geometrytype(the_geom) IN
('LINESTRING','MULTILINESTRING') THEN 'LINESTRING' when
geometrytype(the_geom) IN ('POLYGON','MULTIPOLYGON') THEN 'POLYGON'
end from public.dual_cmtc_geom
On Mon, Sep 12, 2011 at 9:00 PM, Tim Keitt tke...@gmail.com wrote:
I see that the output is not so helpful below because the log is not
serialized.
Anyway, I think I have an answer. There is a table in the database
with 1.2 billion rows. Somehow loading any table from that database
is triggering a scan of the very large table, perhaps all tables in
the database. I dumped the smaller tables and made a new database and
it is quick again.
I will see if I can serialize the log output and report back.
THK
On Mon, Sep 12, 2011 at 7:59 PM, Tim Keitt tke...@gmail.com wrote:
The table has only a single row. Normally it loads instantly. Suddenly
its taking a very long time. Here's the output from postgres:
2011-09-12 19:50:26 CDT STATEMENT: select
estimated_extent('public','region_boundary','the_geom')
2011-09-12 19:50:26 CDT LOG: statement: select extent(the_geom)
from public.region_boundary
2011-09-12 19:50:26 CDT LOG: duration: 0.519 ms
2011-09-12 19:54:07 CDT LOG: duration: 228246.691 ms
2011-09-12 19:54:07 CDT LOG: statement: BEGIN READ ONLY
2011-09-12 19:54:07 CDT LOG: duration: 0.145 ms
2011-09-12 19:54:07 CDT LOG: statement: declare qgisf0 binary cursor
for select gid,asbinary(the_geom,'NDR') from
public.region_boundary where the_geom
setsrid('BOX3D(-5826044.8984273653477430 -6024214.2690353775396943,
7145528.0523074865341187 3985583.1240626471117139)'::box3d,900914)
2011-09-12 19:54:08 CDT LOG: duration: 73.467 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 8.667 ms
2011-09-12 19:54:08 CDT LOG: statement: fetch forward 200 from qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.107 ms
2011-09-12 19:54:08 CDT LOG: statement: CLOSE qgisf0
2011-09-12 19:54:08 CDT LOG: duration: 0.050 ms
2011-09-12 19:54:08 CDT LOG: statement: COMMIT
2011-09-12 19:54:08 CDT LOG: duration: 0.057 ms
Anybody have an idea about this one?
THK
--
Timothy H. Keitt
http://www.keittlab.org/
--
Timothy H. Keitt
http://www.keittlab.org/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
