Re: [Qgis-developer] qgis2threejs issue
Hi Paolo, 2014-10-28 3:45 GMT+09:00 Paolo Cavallini cavall...@faunalia.it: -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
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 rldh...@gmail.com 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] 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] 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 madman...@gmail.com 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] 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 madman...@gmail.com 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
[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] PyQGIS standalone without x server
2014-10-28 11:47 GMT+01:00 Ziegler Stefan stefan.zieg...@bd.so.ch: 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
Re: [Qgis-developer] PyQGIS standalone without x server
Hi Stefan On Tue, Oct 28, 2014 at 5:47 PM, Ziegler Stefan stefan.zieg...@bd.so.ch 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 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 the syntax of the
original query and translate it into the desired
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 *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.
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 stefan.zieg...@bd.so.ch 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
[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] 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
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
