Re: [Qgis-developer] QGIS 2.0 and PyQT v2 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/04/2013 19:57, Gary Sherman ha scritto: At the outset, this will render almost all third party plugins inoperable. If this change is to be made, we need to widely publicize the fact to users that some or perhaps all of their favorite plugins may be broken at the release of 2.0. Hi all. Do you have an idea of how much work is this? Could this be fixed more efficiently in a cooperative fashion, iterating the same changes over all the plugins, or does it require a lot of ad hoc adaptations? All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF8xK8ACgkQ/NedwLUzIr4IUgCgo5sT9hfpOtX9NQVCr2XCaHZm VcwAniQkd+iqKVUNK9zYCQgsaSm2DTy/ =VIkH -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS 2.0 and PyQT v2 update
Matthias Kuhn wrote We have already rendered many plugins inoperable by changing the vector api (and some other API's) so lots of plugins will need some love to get ready for 2.0. Then there is the PyQt API V2 change which will render some more plugins useless. And I was just remembering, that I've heard, that the upgrade to PyQt API V2 is done to be ready for Python 3. So it's probably also worth considering, if the PyQt version changes and python upgrade should happen at the same point in time. I have never upgraded code from Python 2 to Python 3 myself, but there seem to be some differences which require work to migrate. In order to be able to plan the plugin development. Is the upgrade to Python 3 something which is really considered to happen in the next couple of years? Would it not scare too many plugin developers and users away, because it will require once more a considerable effort to update? If Python 3 is not an option for the next couple of years, is it worth upgrading the PyQt API now? Would it be better to upgrade to Python 3 right now! Because this will require plugin developers to go over all their code now. Once only. I know it's quite late (with respect to the 2.0 roadmap) to bring this up, but I haven't really thought of it earlier and I think it's a very important decision. http://lists.osgeo.org/mailman/listinfo/qgis-developer +1 with Matthias, we should plan pyqt2 and python 3 for a future release. I see major risks in migrating now when we are in feature freeze with so many blockers to solve in 2 months. We have very few users and developpers that did real test to migrate to pyqt2 and python 3 , so we might have major issues hidden in there. We users really need 2.0 to happen this year in a stable state and I guess this is already a great challenge. My two cents. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-2-0-and-PyQT-v2-update-tp5049723p5050042.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Is Print Composer Atlas broken?
Hi, I just wanted to test Atlas using lakes.shp from our sample data. The resulting PDF has 15 pages but every page displays the same lake. Can you confirm? Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Vector buffer commitChanges (was Interaction between QGis and ArcGis)
On Fri, Apr 26, 2013 at 10:09 AM, Martin Dobias wonder...@gmail.com wrote: On Wed, Apr 24, 2013 at 12:20 PM, Radim Blazek radim.bla...@gmail.com wrote: Maybe better, but we are already using startEditing() and commitChanges() in vector layer so I would prefer to use the same. I added to QgsVectorDataProvider: virtual bool startEditing(); virtual bool rollBack(); virtual bool commitChanges(); virtual bool isEdited(); signals: void editingStarted(); void editingStopped(); As I said, to keep names consistent with vector layer. Currently not implemented nor used. It would be useful to have it implemented for 2.0 at least in ogr provider to resolve #6448 at least for reading. If the startEditing() and commitChanges() are going to be called within QgsVectorLayer::commitChanges(), then I find the names confusing and begin/commit/rollback-Transaction() would be IMHO better. They do different things, so they should have different names. And while using startEditing() and commitChanges() is necessary for editing within QgsVectorLayer, calling those functions in QgsVectorDataProvider should be optional (edit functions should automatically open a transaction and then close it afterwards). The original motivation for that methods was to reopen files in r+ mode, not to start transaction in DB provider. It is not possible to reopen files in each provider edit method and startEditing() would have to be obligatory. However, as I am thinking about it more, it seems that reopening files could cause more troubles than keeping them always in r+ mode. Until now, it does not appear to be a problem to open files in r+ mode, apart the slowness on Windows which is only a side effect. The suggested read only mode + VSI cache was only a workaround, not resolution of the problem which is in OGR. I'll probably remove those new methods. If we find it necessary to use read only mode for files, we can reopen them in r+ first time a provider edit method is called. That should isolate the problem in OGR provider. Begin/commit/rollback-Transaction() may be added later, it should not break the API. Currently all editing methods in postgres provider do changes in transactions. If we implement QgsPostgresProvider::startEditing() it should start new transaction and all changes should be done within that transaction. Are there any potential problems? I do not see any right now. Should the startEditing() / commitChanges() close all iterators? Good question: this needs more thoughts. Closing them makes sense because with some providers the iterators would not return correct results. However that would mean that some code will stop working. The same question probably applies to all provider edit methods. Radim Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transformation labeling bug
Am 27.04.2013 16:14, schrieb Anita Graser: Hi, I get nasty forward transformation errors with today's nightly when using a predefined road style and labels: forward transform of (12557.230023, 71897.228375) PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=aea +lat_1=55 +lat_2=65 +lat_0=50 +lon_0=-154 +x_0=0 +y_0=0 +datum=NAD27 +units=us-ft +no_defs Error: latitude or longitude exceeded limits (afterwards QGIS hangs) Data is Natural Earth's road shapefile in WGS84. (http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_roads.zip) The layer extent is: xMin,yMin -166.532;-55.1121 : xMax,yMax 178.372;71.1777 so I don't know what coordinates are to be forward transformed in your error message. Has your road style and labelling any coordinate information? It works for me on QGIS Lisboa and without styles, but looks a bit weird in the middle of Africa. Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On-The-Fly CRS Transformation Does Not Apply +no_off Parameter
Am 28.04.2013 07:21, schrieb Hilmy Hashim: Hello all, This query is about a discrepancy between projection results using the *Custom CRS Test* and *on-the-fly* transformation, and not about RSO per se. The Proj4 parameters for GDM2000 / Peninsula RSO (EPSG:3375) as given by epsg_tr.py (GDAL 1.9.2) are: +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.025796466 +k=0.99984 +x_0=804671 +y_0=0 +gamma=323.130102361 +ellps=GRS80 +units=m +no_defs This Malaysian projection requires the +no_off or *+no_uoff* flag (both works) for rotation at the natural origin as of proj 4.8. To test, I created a custom CRS based on GDM2000 / Peninsula RSO adding this flag. However, there seems to be some discrepancy between the on-the-fly derived results and the Test in the Custom CRS definition dialog. I set the project CRS as the custom CRS I created and added the test point in WGS84. Test points: *1.827764875* deg N, *103.64025987* deg E (WGS84 EPSG:4326) Expected results: Northing *202,122.062* m, Easting *627,096.132* m (EPSG:3375) *The test points and projected coordinates are taken from the GDM2000 Technical Manual published by the Department of Survey and Mapping Malaysia. * *Test results (standard EPSG:3375)*: cs2cs — -240332.04, 958936.71 QGIS Master (13d35ac) On-the-fly derived: Y = -240,332.0326, X = 958,936.7057 QGIS Master (13d35ac) Custom CRS Test:* -240,332.0326* N, *958,936.7057* E QGIS 1.8 On-the-fly: projected coordinates not derived QGIS 1.8 Custom CRS Test: -240,332.0326 N, 958,936.7057 E *Test results (with +no_off flag)*: cs2cs — 202122.06, 627096.13 QGIS Master (13d35ac) On-the-fly derived: Y =* -240,332.0326*, X = * 958,936.7057* QGIS Master (13d35ac) Custom CRS Test: *202,122.0625* N, *627,096.1317* E QGIS 1.8 On-the-fly: projected coordinates not derived QGIS 1.8 Custom CRS Test: 202,122.0625 N, 627,096.1317 E It looks like the Custom CRS Definition Test dialog is giving the correct result, but the on-the-fly transformation is ignoring the +no_off flag. Is the on-the-fly transformation using a different transformation process and reading the proj4 parameters differently, or am I going about this wrongly? I made some tests with the similar Michigan omerc projections and ran into the same problem: http://trac.osgeo.org/gdal/ticket/4910 It looks like it is a GDAL problem. HTH, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] On-The-Fly CRS Transformation Does Not Apply +no_off Parameter
Ah, so on-the-fly is using ogr2ogr and the custom crs test is just using cs2cs. On Mon, Apr 29, 2013 at 12:05 AM, Andre Joost andre+jo...@nurfuerspam.dewrote: Am 28.04.2013 07:21, schrieb Hilmy Hashim: Hello all, This query is about a discrepancy between projection results using the *Custom CRS Test* and *on-the-fly* transformation, and not about RSO per se. The Proj4 parameters for GDM2000 / Peninsula RSO (EPSG:3375) as given by epsg_tr.py (GDAL 1.9.2) are: +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.025796466 +k=0.99984 +x_0=804671 +y_0=0 +gamma=323.130102361 +ellps=GRS80 +units=m +no_defs This Malaysian projection requires the +no_off or *+no_uoff* flag (both works) for rotation at the natural origin as of proj 4.8. To test, I created a custom CRS based on GDM2000 / Peninsula RSO adding this flag. However, there seems to be some discrepancy between the on-the-fly derived results and the Test in the Custom CRS definition dialog. I set the project CRS as the custom CRS I created and added the test point in WGS84. Test points: *1.827764875* deg N, *103.64025987* deg E (WGS84 EPSG:4326) Expected results: Northing *202,122.062* m, Easting *627,096.132* m (EPSG:3375) *The test points and projected coordinates are taken from the GDM2000 Technical Manual published by the Department of Survey and Mapping Malaysia. * *Test results (standard EPSG:3375)*: cs2cs — -240332.04, 958936.71 QGIS Master (13d35ac) On-the-fly derived: Y = -240,332.0326, X = 958,936.7057 QGIS Master (13d35ac) Custom CRS Test:* -240,332.0326* N, *958,936.7057* E QGIS 1.8 On-the-fly: projected coordinates not derived QGIS 1.8 Custom CRS Test: -240,332.0326 N, 958,936.7057 E *Test results (with +no_off flag)*: cs2cs — 202122.06, 627096.13 QGIS Master (13d35ac) On-the-fly derived: Y =* -240,332.0326*, X = * 958,936.7057* QGIS Master (13d35ac) Custom CRS Test: *202,122.0625* N, *627,096.1317* E QGIS 1.8 On-the-fly: projected coordinates not derived QGIS 1.8 Custom CRS Test: 202,122.0625 N, 627,096.1317 E It looks like the Custom CRS Definition Test dialog is giving the correct result, but the on-the-fly transformation is ignoring the +no_off flag. Is the on-the-fly transformation using a different transformation process and reading the proj4 parameters differently, or am I going about this wrongly? I made some tests with the similar Michigan omerc projections and ran into the same problem: http://trac.osgeo.org/gdal/**ticket/4910http://trac.osgeo.org/gdal/ticket/4910 It looks like it is a GDAL problem. HTH, André Joost __**_ 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] Transformation labeling bug
Am 28.04.2013, 18:01 Uhr, schrieb Andre Joost andre+jo...@nurfuerspam.de: Am 27.04.2013 16:14, schrieb Anita Graser: Hi, I get nasty forward transformation errors with today's nightly when using a predefined road style and labels: forward transform of (12557.230023, 71897.228375) PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=aea +lat_1=55 +lat_2=65 +lat_0=50 +lon_0=-154 +x_0=0 +y_0=0 +datum=NAD27 +units=us-ft +no_defs Error: latitude or longitude exceeded limits (afterwards QGIS hangs) Data is Natural Earth's road shapefile in WGS84. (http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_roads.zip) The layer extent is: xMin,yMin -166.532;-55.1121 : xMax,yMax 178.372;71.1777 so I don't know what coordinates are to be forward transformed in your error message. Has your road style and labelling any coordinate information? I'm using the Primary road style which comes with nightly by default. The style alone seems to work. Once I enable labeling using street name, the forward transform error pops up. Earlier today I used a different style and no error happened so you might be on to something with your theory that the road style contains coordinate information. Thanks and best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transformation labeling bug
Hi Anita, On Sun, Apr 28, 2013 at 1:27 PM, Anita Graser anitagra...@gmx.at wrote: Am 28.04.2013, 18:01 Uhr, schrieb Andre Joost andre+jo...@nurfuerspam.de : Am 27.04.2013 16:14, schrieb Anita Graser: Hi, I get nasty forward transformation errors with today's nightly when using a predefined road style and labels: forward transform of (12557.230023, 71897.228375) PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=aea +lat_1=55 +lat_2=65 +lat_0=50 +lon_0=-154 +x_0=0 +y_0=0 +datum=NAD27 +units=us-ft +no_defs Error: latitude or longitude exceeded limits (afterwards QGIS hangs) Data is Natural Earth's road shapefile in WGS84. (http://www.naturalearthdata.**com/http//www.** naturalearthdata.com/download/**10m/cultural/ne_10m_roads.ziphttp://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_roads.zip ) The layer extent is: xMin,yMin -166.532;-55.1121 : xMax,yMax 178.372;71.1777 so I don't know what coordinates are to be forward transformed in your error message. Has your road style and labelling any coordinate information? I'm using the Primary road style which comes with nightly by default. The style alone seems to work. Once I enable labeling using street name, the forward transform error pops up. I can confirm this on Mac. However, it doesn't happen when labeling is turned on, but when symbol levels are set (and labeling is on). Symbol levels and labels work individually, but if either is turned on when the other is on the error occurs and force quitting becomes the only option. I get the following (note it is being on-the-fly transformed to UTM here): Debug: src/core/qgspallabeling.cpp: 1305: (registerFeature) Ignoring feature 1893 due PAL exception: Geometry Type is unknown Debug: src/core/qgscoordinatetransform.cpp: 623: (transformCoords) Projection failed emitting invalid transform signal: forward transform of (25075.946436, 81366.459079) PROJ.4: +proj=longlat +datum=WGS84 +no_defs +to +proj=utm +zone=13 +datum=WGS84 +units=m +no_defs Error: latitude or longitude exceeded limits I've traced it to line 1057 in qgspallabeling.cpp [0]. Just guessing, but it looks like something is different between how the features are sent to QgsPalLayerSettings::registerFeature from QgsVectorLayer::drawRendererV2Levels as opposed to QgsVectorLayer::drawRendererV2, which works fine. Please create a ticket if you have the time. [0] https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgspallabeling.cpp#L1056 Regards, Larry Earlier today I used a different style and no error happened so you might be on to something with your theory that the road style contains coordinate information. Thanks and best wishes, Anita __**_ 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
