Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi all, this is a very high level topic for me. I will just point out some user/funder needs, and maybe try to describe other strategies exist in GIS softs. As a user coming from both ESRI and Mapinfo world: - The main (and last?) real advantage of MI was its native pseudo-SQL capabilities (with many limitations). Users really often now have a centralized spatialDB, where the administrator can do many things (almost everything in fact), but the classical user has only two possibilies for relation Db treatments: algorithms or duplicate data in sqlite and learn spatial sql (unless their DBA grant them to Postgres... ). Power users are very happy, ex MI users are not in QGIS. - Arcgis have no agregate capabilities over its relations.. Joins are more developped and allow summarize algoithms. To go further, It requires using an external DB system, and it's a pain (they all have limitations, in term of cost or learning curve..). Postgis/sqlite is far away in terms of accessibility Having virtual sqlite tables would allow some MI-like behaviour. Users here would appreciate that a lot (I will still be using postgres underneath for perfs). For more simple use cases, some only want to improve joins by being able to join and output agregate values if multiples tuples join, for simple mapping purposes. I think UI needs boths things, a SQL dialog to create queries - Qspatialite-like - on every table, and some agregate capabilities over joins. What we must avoid is having two different implementations, with differents limitations. Only power users knowing what is really happening underneath will know what function to use, which is bad in UX terms. A comparison is OGR CSV driver versus CSV plugin... User has to know that both tools are differents, behaves differently with a different providers. Nothing in the GUI let you know that except try-fail approach. BTW, I have the feeling you don't disagree at all but that we are digging one of the harder features of a GIS tool. IMHO, that really desserves discussions, prooves of concept. Any other opinions in dev's? Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QEP-RFC-sqlite-virtual-tables-tp5168850p5170009.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
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Le 28/10/2014 13:21, Matthias Kuhn a écrit : > Hi Hugo > >> The optimization plan could be: don't try to optimize in the general >> case (premature optimization ...), only optimize specific >> well-identified cases. >> For now the only simple case I can see is when a join is done on tables >> from the same database (and the user don't know or can't do a join on >> the remote database > ... or a developer wants to develop a provider-independent plugin/core > functionality that has a good cross-table performance. Do you have something in mind ? >> ), then yes we would have to know the syntax of the >> original query and translate it into the desired SQL dialect. >> And yes it would be better to have it from SQLite. It would require >> either to work with the developers, to patch it or to somehow include >> the parsing part of SQLite (we already ship sqlite / spatialite with >> QGIS right ?). But I really don't see it as a blocker. > > I don't think we do ship it but I may be wrong? > Please don't get me wrong, I didn't say it's a blocker. The original > discussion started from Régis statement "there's a QEP taking care of > relational queries, is there a need to duplicate functionality?" and my > response "I am not sure if sqlite virtual tables will be able to satisfy > all our needs". I was just wondering about the limitations of this > approach and I am still very open to hear about any experiences you had > with sqlite developers (I have none) because that is what counts when it > comes to working with upstream as you proposed. Indeed, I don't know well the sqlite dev community. I will try to know a bit more about exposure of internal SQLite data structures. In the worst case we could decide to fork or include parts of the code the license is very permissive. Btw, there is a spatialite / sqlite source distribution in src/spatialite (probably only used when WITH_INTERNAL_SPATIALITE is enabled) > >> >> I really think using SQLite as our database engine has a good potential. >> It could extend the abilities and expressivity of QGIS. And it could >> also allow to use *less* code in QGIS (seeing every provider as a >> virtual layer). And it could also paves the way for a native QGIS file >> format (this is another discussion, but somehow related). >> >> But whatever the implementation is, trying to be (automatically) as >> performant as a well-designed query on a well-designed db is a waste of >> energy. > Yes, we cannot do that. But we can try to find a way that allows > developers to develop and users to create projects independent of > providers while still providing good performance on a capable backend. > >> >> On a more pragmatic side, people are already interested and might pay >> for db-oriented functionalities in QGIS (the very first need is to be >> able to filter joined tables). It does not have to be the only incentive >> for design choices, but this is a good opportunity. Then a decision has >> to be taken. >> >> So, if it is hard for you and me to agree :), are there other opinions ? >> Other arguments for one or the other side ? > > I don't want to disagree, I just wanted to raise questions / to > understand the limitations. I see the demand for this functionality and > I see the potential that sqlite virtual tables have to offer. I just > wonder what the performance will be like in a scenario where there's a > network (with latency for every request) involved. And what it would > require to overcome this issue (if there is any). Ok, but this performance issue is not related to the backend choice (SQLite or our own), right ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] LizMap plugin: filter layer by user impossible to remove?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. Here, once set, the option reappears when closing and reopening LizMap plugin: does anybody confirm? Thanks. - -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRPsJAACgkQ/NedwLUzIr4gPQCcCwC1niwpkaaEyp/YsoFLdFEG wmAAn3uuivEFzst1CHkyb+IbbpUr5VnK =jTqc -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PyQGIS standalone without x server
Thanks! Regards Stefan > -Ursprüngliche Nachricht- > Von: Martin Dobias [mailto:wonder...@gmail.com] > Gesendet: Dienstag, 28. Oktober 2014 11:56 > An: Ziegler Stefan > Cc: qgis-developer@lists.osgeo.org > Betreff: Re: [Qgis-developer] PyQGIS standalone without x server > > Hi Stefan > > On Tue, Oct 28, 2014 at 5:47 PM, Ziegler Stefan > wrote: > > > > Since I do not have access to a server w/o x server I cannot test it by > > myself. Does > anybody know if a running x server is required to run pyqgis standalone apps? > E.g. > something like this: > > > > app = QApplication(sys.argv) > > The X server is required here. QApplication will try to make a connection to > it. > QCoreApplication does not - but it brings other limitations. > > Actually there is an easy way to try it out - just set DISPLAY env variable > to nothing: > > martin@zenbook:~$ DISPLAY="" python > Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type > "help", > "copyright", "credits" or "license" for more information. > >>> from PyQt4 import QtGui > >>> app = QtGui.QApplication([]) > : cannot connect to X server > > (the process is aborted) > > Cheers > Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi Hugo
On 28.10.2014 12:15, Hugo Mercier wrote:
> Hi Matthias,
>
> Le 28/10/2014 09:46, Matthias Kuhn a écrit :
>> Hi Hugo,
>>
>> Sorry for my slow response, I was quite busy the last days.
> With the 2.6 coming I know this is not the best time for this kind of
> discussion :( So thanks for your time.
>
>> I'll try to explain a bit more what I have in mind.
>>
>> For example there is the new expression function "getFeature()" which is
>> an ad-hoc replacement for a join. I have been told that the performance
>> for rendering is not very good, I assume this is caused by a lot of
>> requests performed in the background. It would be great to be able to
>> join this on the server side.
> I agree. This getFeature() is a symptom that we need more advanced
> relational-oriented functionalities.
>
>> I would be very happy to see more of this introduced. For example I
>> could well imagine a new Expression (Syntax just made up, that can still
>> be designed in a more appropriate way)
>>
>> avg( c.population ) { LEFT JOIN cities c ON c.country_code =
>> $thistable.code }
>>
>> This should then be locally evaluated (for shapefiles et al) but
>> forwarded to the server for database services (postgres and the like).
> How would it be "forwarded" for database services ? If the two tables
> are from the same db, then ok, we are in the "simple optimization" case
> that I was talking about previously : more or less a translation between
> SQL dialects.
> But what if the current table is a local file (shapefile) and cities is
> a postgis table ?
In this case I think the sqlite virtual table approach (or any other
local filtering method) should be preferred. That would involve too much
black magic.
There may be some cases where we can mix things (e.g. two parts of a
where clause combined with "AND" where only for one of the two WHERE
clauses a native SQL translation can be found could be performed as a
two-step filter, but that's really not the main point)
> You would then need a magical optimization engine that will say you need
> to send the list of local country codes to a remote query like :
>
> SELECT avg(population)
> FROM cities
> WHERE country_code IN ( $local_country_code_array )
> GROUP BY country_code
>
> But actually, the best optimization depends in the general case on the
> actual data stored in tables. If the bandwith required to send the IN
> part to PostGIS is too important, there may be cases where it is better
> to fetch everything remotely and sort and group by locally or they may
> be cases where another query would be better.
>
> This is why writing an optimal SQL query is hard and why database
> planners do lots of work, rely on lots of heuristics and statistics and
> are hard to implement.
>
>> Now, as we have different backends and their syntax does not always
>> match (most do standard sql, but there are extensions, think of ST_* in
>> postgis, SDO_* in oracle spatial etc, and there is no guarantee, that a
>> dataprovider supports standard SQL) we need an abstraction layer and
>> cannot just assume that every dataprovider will understand the same thing.
> Yes, exactly, and this was to whole point of relying on SQLite and
> Spatialite as an abstraction layer.
>
>> I am planning to implement this abstraction layer for ordinary
>> expressions in the near future. And I would be very happy to see that
>> there is a way to extend this with aggregate functions. This will all
>> require a fallback level (if the server does not support a given
>> functionality, for shapefiles, to be sure that the result is the very
>> same regardless of server function implementation details...). We
>> already have this for ordinary expressions as we can just use the
>> QgsExpression implementation.
>>
>> I can only repeat, that I will be more than happy to see this fallback
>> level implemented by means of sqlite virtual tables. But in my humble
>> opinion it would be very unfortunate if there would be no way to
>> optimize this tomorrow or the day after tomorrow. That's why I am asking
>> if sqlite developers are open to collaborate because if the will to
>> collaborate there is missing we will end up having to reimplement this
>> functionality.
>>
>> I totally agree with your statement "A general cross-database SQL
>> optimizer would need lots of work (in QGIS and/or SQLite) and may come
>> later (if really needed).", but would append "and will require either a
>> re-implementation in QGIS, ending up in duplicated functionality"
>> (that's what Régis was worried about in the original mail) "or will need
>> the possibility to get deeper access to sqlite's internal data
>> structures or callbacks to optimize where required. This will require
>> cooperation from SQLite developer's side or forking sqlite.".
>>
> I really don't think the difficulty is here. Even if we have access to
> the parsed SQL and even to the result of the SQLite planner, splitting
> the execution plan in optimal local and remote operations is *ve
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi Matthias,
Le 28/10/2014 09:46, Matthias Kuhn a écrit :
> Hi Hugo,
>
> Sorry for my slow response, I was quite busy the last days.
With the 2.6 coming I know this is not the best time for this kind of
discussion :( So thanks for your time.
>
> I'll try to explain a bit more what I have in mind.
>
> For example there is the new expression function "getFeature()" which is
> an ad-hoc replacement for a join. I have been told that the performance
> for rendering is not very good, I assume this is caused by a lot of
> requests performed in the background. It would be great to be able to
> join this on the server side.
I agree. This getFeature() is a symptom that we need more advanced
relational-oriented functionalities.
>
> I would be very happy to see more of this introduced. For example I
> could well imagine a new Expression (Syntax just made up, that can still
> be designed in a more appropriate way)
>
> avg( c.population ) { LEFT JOIN cities c ON c.country_code =
> $thistable.code }
>
> This should then be locally evaluated (for shapefiles et al) but
> forwarded to the server for database services (postgres and the like).
How would it be "forwarded" for database services ? If the two tables
are from the same db, then ok, we are in the "simple optimization" case
that I was talking about previously : more or less a translation between
SQL dialects.
But what if the current table is a local file (shapefile) and cities is
a postgis table ?
You would then need a magical optimization engine that will say you need
to send the list of local country codes to a remote query like :
SELECT avg(population)
FROM cities
WHERE country_code IN ( $local_country_code_array )
GROUP BY country_code
But actually, the best optimization depends in the general case on the
actual data stored in tables. If the bandwith required to send the IN
part to PostGIS is too important, there may be cases where it is better
to fetch everything remotely and sort and group by locally or they may
be cases where another query would be better.
This is why writing an optimal SQL query is hard and why database
planners do lots of work, rely on lots of heuristics and statistics and
are hard to implement.
>
> Now, as we have different backends and their syntax does not always
> match (most do standard sql, but there are extensions, think of ST_* in
> postgis, SDO_* in oracle spatial etc, and there is no guarantee, that a
> dataprovider supports standard SQL) we need an abstraction layer and
> cannot just assume that every dataprovider will understand the same thing.
Yes, exactly, and this was to whole point of relying on SQLite and
Spatialite as an abstraction layer.
>
> I am planning to implement this abstraction layer for ordinary
> expressions in the near future. And I would be very happy to see that
> there is a way to extend this with aggregate functions. This will all
> require a fallback level (if the server does not support a given
> functionality, for shapefiles, to be sure that the result is the very
> same regardless of server function implementation details...). We
> already have this for ordinary expressions as we can just use the
> QgsExpression implementation.
>
> I can only repeat, that I will be more than happy to see this fallback
> level implemented by means of sqlite virtual tables. But in my humble
> opinion it would be very unfortunate if there would be no way to
> optimize this tomorrow or the day after tomorrow. That's why I am asking
> if sqlite developers are open to collaborate because if the will to
> collaborate there is missing we will end up having to reimplement this
> functionality.
>
> I totally agree with your statement "A general cross-database SQL
> optimizer would need lots of work (in QGIS and/or SQLite) and may come
> later (if really needed).", but would append "and will require either a
> re-implementation in QGIS, ending up in duplicated functionality"
> (that's what Régis was worried about in the original mail) "or will need
> the possibility to get deeper access to sqlite's internal data
> structures or callbacks to optimize where required. This will require
> cooperation from SQLite developer's side or forking sqlite.".
>
I really don't think the difficulty is here. Even if we have access to
the parsed SQL and even to the result of the SQLite planner, splitting
the execution plan in optimal local and remote operations is *very hard*
in the general case. And we would have to do it whatever the abstraction
layer we choose : SQLite or our own QgsExpression-based solution.
And I really don't think that would be a good idea to do this in QGIS.
The optimization plan could be: don't try to optimize in the general
case (premature optimization ...), only optimize specific
well-identified cases.
For now the only simple case I can see is when a join is done on tables
from the same database (and the user don't know or can't do a join on
the remote database), then yes we would have to know t
Re: [Qgis-developer] PyQGIS standalone without x server
Hi Stefan On Tue, Oct 28, 2014 at 5:47 PM, Ziegler Stefan wrote: > > Since I do not have access to a server w/o x server I cannot test it by > myself. Does anybody know if a running x server is required to run pyqgis > standalone apps? E.g. something like this: > > app = QApplication(sys.argv) The X server is required here. QApplication will try to make a connection to it. QCoreApplication does not - but it brings other limitations. Actually there is an easy way to try it out - just set DISPLAY env variable to nothing: martin@zenbook:~$ DISPLAY="" python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from PyQt4 import QtGui >>> app = QtGui.QApplication([]) : cannot connect to X server (the process is aborted) Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PyQGIS standalone without x server
2014-10-28 11:47 GMT+01:00 Ziegler Stefan :
> Hi
>
> Since I do not have access to a server w/o x server I cannot test it by
> myself. Does anybody know if a running x server is required to run pyqgis
> standalone apps? E.g. something like this:
>
> app = QApplication(sys.argv)
> QgsApplication.setPrefixPath("/home/stefan/Apps/qgis_master", True)
> QgsApplication.initQgis()
>
> QgsProject.instance().setFileName(os.path.join(current_dir,
> "bpav5000sw.qgs"))
> QgsProject.instance().read():
>
> QgsApplication.exitQgis()
>
> Best regards
> Stefan
>
>
I'm not sure if an X server is *always* required, what I know for sure
is that if you are going to use any SVG symbol or HTML formatted text
in a widget, then your script will crash with an ugly segfault if X
(or fake X) is not running.
--
Alessandro Pasotti
w3: www.itopen.it
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] PyQGIS standalone without x server
Hi
Since I do not have access to a server w/o x server I cannot test it by myself.
Does anybody know if a running x server is required to run pyqgis standalone
apps? E.g. something like this:
app = QApplication(sys.argv)
QgsApplication.setPrefixPath("/home/stefan/Apps/qgis_master", True)
QgsApplication.initQgis()
QgsProject.instance().setFileName(os.path.join(current_dir, "bpav5000sw.qgs"))
QgsProject.instance().read():
QgsApplication.exitQgis()
Best regards
Stefan
Freundliche Grüsse
Stefan Ziegler
Kantonsgeometer
Amt für Geoinformation
Amtliche Vermessung
Rötistrasse 4
4500 Solothurn
Telefon +41 32 627 75 96
Telefax +41 32 627 75 98
stefan.zieg...@bd.so.ch
http://www.so.ch
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Delay 2.6 release?..
On 10/28/2014 10:50 AM, Sandro Santilli wrote: On Sun, Oct 26, 2014 at 12:09:55PM +0100, Luca Manganelli wrote: On Sun, Oct 26, 2014 at 11:16 AM, Nathan Woodrow wrote: I think it makes sense to keep up with the funded bug fixing if we have the money Maybe the QGIS testing funding would fix all these probelms? Now it's funded! http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing That project is about making current tests pass and keeping them passing for the future. Very important, glad it made it ! It won't be matter of a few days, nor it will involve fixing bugs that do not have a test. But if bugfixes funded for 2.6 will come with a testcase guarding for them not to come back again it'll be great. Thank you for the clarification Sandro, this mail has escaped my notice. I am also glad that this campaign made it. I will make sure that I will work on this in the upcoming weeks (not only) to ensure that new test cases being written now are taken into consideration. -- Matthias -- Please help taking QGIS to the next level of quality. Before November 15 ! http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Delay 2.6 release?..
On Sun, Oct 26, 2014 at 12:09:55PM +0100, Luca Manganelli wrote: > On Sun, Oct 26, 2014 at 11:16 AM, Nathan Woodrow > wrote: > > > I think it makes sense to keep up with the funded bug fixing if we have > > the money > > > > Maybe the QGIS testing funding would fix all these probelms? Now it's > funded! > http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing That project is about making current tests pass and keeping them passing for the future. Very important, glad it made it ! It won't be matter of a few days, nor it will involve fixing bugs that do not have a test. But if bugfixes funded for 2.6 will come with a testcase guarding for them not to come back again it'll be great. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi Hugo,
Sorry for my slow response, I was quite busy the last days.
I'll try to explain a bit more what I have in mind.
For example there is the new expression function "getFeature()" which is
an ad-hoc replacement for a join. I have been told that the performance
for rendering is not very good, I assume this is caused by a lot of
requests performed in the background. It would be great to be able to
join this on the server side.
I would be very happy to see more of this introduced. For example I
could well imagine a new Expression (Syntax just made up, that can still
be designed in a more appropriate way)
avg( c.population ) { LEFT JOIN cities c ON c.country_code =
$thistable.code }
This should then be locally evaluated (for shapefiles et al) but
forwarded to the server for database services (postgres and the like).
Now, as we have different backends and their syntax does not always
match (most do standard sql, but there are extensions, think of ST_* in
postgis, SDO_* in oracle spatial etc, and there is no guarantee, that a
dataprovider supports standard SQL) we need an abstraction layer and
cannot just assume that every dataprovider will understand the same thing.
I am planning to implement this abstraction layer for ordinary
expressions in the near future. And I would be very happy to see that
there is a way to extend this with aggregate functions. This will all
require a fallback level (if the server does not support a given
functionality, for shapefiles, to be sure that the result is the very
same regardless of server function implementation details...). We
already have this for ordinary expressions as we can just use the
QgsExpression implementation.
I can only repeat, that I will be more than happy to see this fallback
level implemented by means of sqlite virtual tables. But in my humble
opinion it would be very unfortunate if there would be no way to
optimize this tomorrow or the day after tomorrow. That's why I am asking
if sqlite developers are open to collaborate because if the will to
collaborate there is missing we will end up having to reimplement this
functionality.
I totally agree with your statement "A general cross-database SQL
optimizer would need lots of work (in QGIS and/or SQLite) and may come
later (if really needed).", but would append "and will require either a
re-implementation in QGIS, ending up in duplicated functionality"
(that's what Régis was worried about in the original mail) "or will need
the possibility to get deeper access to sqlite's internal data
structures or callbacks to optimize where required. This will require
cooperation from SQLite developer's side or forking sqlite.".
Best regards,
Matthias
--
Please help taking QGIS to the next level of quality. Before November 15 !
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] error when saving modified features via wfs-t/qgis server
> Message: 3 > Date: Mon, 27 Oct 2014 09:46:54 +0100 > From: Ren?-Luc Dhont > To: qgis-developer@lists.osgeo.org > Subject: Re: [Qgis-developer] error when saving modified features via > wfs-t/qgis server > Message-ID: <544e067e.9000...@gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Giovanni, > > If tinyows and QGIS-Server can't save feature through WFS-T, it's > probably an issue in the QGIS WFS Client, isn't it ? HI René-Luc, thanks for the answer. The tiny-ows issue seems to be isolated to the server side (or how I configured it), as I can't find a client that works. On the other hand I think there is an issue with qgis-server: qgis as client can edit/modify with no issues certain features (ex: polygons) published on geoserver, but the same features published with qgis server return the error I posted in my first message. If the feature is generalized, at some point the error when saving does not show anymore. cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis2threejs issue
Hi Paolo, 2014-10-28 3:45 GMT+09:00 Paolo Cavallini : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Il 27/10/2014 19:24, doktoreas ha scritto: > >> you need to set control to OrbitControls. > > Oh, I see, thanks. > Why it is not the default? Since the last used control is saved, I did not consider it carefully. Now it's ok to change the default controls to OrbitControls, which has more functions (e.g. arrow-key control and auto-rotation) and is probably suitable for flat earth. Regards, Minoru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
