Hi Jürgen
Is that really significant? I suppose using the same connection as syncDb()
would help (just because it does it's thing in a transaction).
That was it, I moved everything into a transaction and it is super fast now.
Who's bad idea was it to call that thing tr()? ;) transformation() is
probably better for a public method.
He, he. At least it saved a few bytes on the development machines :-)
Why is it in a separate branch?
Ok, I'll merge it into master. Hopefully it does not cause too much
damage...
Regards,
Marco
On 07.11.2013 17:21, Jürgen E. Fischer wrote:
Hi Marco,
On Thu, 07. Nov 2013 at 16:39:35 +0100, Marco Hugentobler wrote:
- The dialogs asking for datum transform could be annoying. Does it need
an option to suppress it (and should it be enabled / disabled by
default)?
Or the OTFR dialog could already produce a list of available transforms for
each CRS used in layers - maybe with the last used transform for each
combination preselected.
- The synchronisation of srs.db with datum_shift.csv makes the install time
longer (maybe it can be solved more efficiently?)
Is that really significant? I suppose using the same connection as syncDb()
would help (just because it does it's thing in a transaction).
- To receive the current QgsCoordinateTransformation for a layer, tools
may query QgsMapRenderer::tr (or QgsMapRenderer::mapToLayerCoordinates
etc.). Creating a new QgsCoordinateTransform from layerCRS and mapCRS is
not correct in all cases any more.
Who's bad idea was it to call that thing tr()? ;) transformation() is
probably better for a public method.
What are your opinions / suggestions?
Why is it in a separate branch?
Jürgen
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
