[Qgis-developer] zoom to best scale is broken
Hi, I have a raster that is georeferenced. When I try to zoom to native pixel resolution it zooms but definitely it is not native pixel resolution. Can anyone confirm this? This works fine if I have just an unreferenced raster. Is there any place to upload sample data? Thanks -Lauri ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Benchmarking QgsExpression against V8
Il 10/01/2012 04:05, Alister Hood ha scritto: I think the language for expressions should be considered carefully. It can have a fairly big impact on user experience, particularly for people who aren't programmers. Agreed, ease of use is more important than sheer performance. However, I do not find the V8 syntax particularly obscure, at least in the examples Pirmin sent us. In any case, this could be solved with a proper interface, wizard-style (anything ready for V8?). Thanks Pirmin. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
RE: [Qgis-developer] Benchmarking QgsExpression against V8
Hi,
I think the language for expressions should be considered carefully. It
can have a fairly big impact on user experience, particularly for people
who aren't programmers.
What other candidates might there be? How do they compare in terms of
intuitiveness? The less time people need to spend reading the help
every time they build an expression, the better.
Alister
> Date: Tue, 10 Jan 2012 01:00:11 +0100
> From: Pirmin Kalberer
> Subject: [Qgis-developer] Benchmarking QgsExpression against V8
> To: qgis-developer@lists.osgeo.org
> Message-ID: <2052129.lmK783bSmN@polarwind2>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> Following the recent enhancements of QGsExpression, I was wondering
> whether it
> wouldn't make sense to integrate a language intepreter instead of
> creating
> another language.
> One candidate would be Google's V8 JavaScript engine
> (http://code.google.com/p/v8/). Since embedding this C++ library is
> easy, I've
> conducted a few quick benchmarks against QgsExpression. Code is
> attached.
>
> Test 1:
> Qgs: '1' || '2' || '3' || '4' || '5' || '6' || '7' || '8' || '9' ||
'0'
> total_avg: 3.380211
> V8: '1' + '2' + '3' + '4' + '5' + '6' + '7' + '8' + '9' + '0'
> total_avg: 0.556035
> Fact: 6.0791335
>
> Test 2:
> Qgs: 1+1=2 AND 5>1
> total_avg: 4.072254
> V8: 1+1==2 && 5>4
> total_avg: 0.864054
> Fact: 4.7129624
>
> Test 3:
> Qgs: replace(lower( 'AAxx'), 'xx', 'BB')
> total_avg: 3.480217
> V8: 'AAxx'.toLowerCase().replace('xx', 'BB')
> total_avg: 0.856053
> Fact: 4.0654224
>
> Test 4:
> Qgs: regexp_replace( 'AAxx', 'x+', 'b')
> total_avg: 2.952184
> V8: 'AAxx'.replace(/x+/, 'b')
> total_avg: 0.668042
> Fact: 4.4191593
>
> Test 5:
> Qgs: CASE WHEN (15 = 11 or 15 = 13 or 15 = 15 or 15 = 21) THEN 15 END
> total_avg: 1.4664916
> V8: if ([11,13,15,21].indexOf(15)>=0) { 15 }
> total_avg: 0.2672168
> Fact: 5.4880217
>
> This benchmarks show that QgsExpression evaluation is between 4 to 6
> times
> slower than V8. This is much better than I expected, but it's still
> factor 4
> to 6...
> So I think it's worth discussing pros and cons of using V8 as an
> expression
> engine. I see the following points:
>
> Pros:
> -Better performance
> -Full Javascript language set included
> -Possibility for writing custum functions
>
> Cons:
> -New language for expressions
> -More fat (3.7MB for libv8.so)
>
> V8 would be a new runtime dependency but would replace the flex and
> yacc build
> dependencies.
>
> Any other points?
>
> Regards
> Pirmin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Benchmarking QgsExpression against V8
Hi all,
Following the recent enhancements of QGsExpression, I was wondering whether it
wouldn't make sense to integrate a language intepreter instead of creating
another language.
One candidate would be Google's V8 JavaScript engine
(http://code.google.com/p/v8/). Since embedding this C++ library is easy, I've
conducted a few quick benchmarks against QgsExpression. Code is attached.
Test 1:
Qgs: '1' || '2' || '3' || '4' || '5' || '6' || '7' || '8' || '9' || '0'
total_avg: 3.380211
V8: '1' + '2' + '3' + '4' + '5' + '6' + '7' + '8' + '9' + '0'
total_avg: 0.556035
Fact: 6.0791335
Test 2:
Qgs: 1+1=2 AND 5>1
total_avg: 4.072254
V8: 1+1==2 && 5>4
total_avg: 0.864054
Fact: 4.7129624
Test 3:
Qgs: replace(lower( 'AAxx'), 'xx', 'BB')
total_avg: 3.480217
V8: 'AAxx'.toLowerCase().replace('xx', 'BB')
total_avg: 0.856053
Fact: 4.0654224
Test 4:
Qgs: regexp_replace( 'AAxx', 'x+', 'b')
total_avg: 2.952184
V8: 'AAxx'.replace(/x+/, 'b')
total_avg: 0.668042
Fact: 4.4191593
Test 5:
Qgs: CASE WHEN (15 = 11 or 15 = 13 or 15 = 15 or 15 = 21) THEN 15 END
total_avg: 1.4664916
V8: if ([11,13,15,21].indexOf(15)>=0) { 15 }
total_avg: 0.2672168
Fact: 5.4880217
This benchmarks show that QgsExpression evaluation is between 4 to 6 times
slower than V8. This is much better than I expected, but it's still factor 4
to 6...
So I think it's worth discussing pros and cons of using V8 as an expression
engine. I see the following points:
Pros:
-Better performance
-Full Javascript language set included
-Possibility for writing custum functions
Cons:
-New language for expressions
-More fat (3.7MB for libv8.so)
V8 would be a new runtime dependency but would replace the flex and yacc build
dependencies.
Any other points?
Regards
Pirmin
--
Pirmin Kalberer
Sourcepole - Linux & Open Source Solutions
http://www.sourcepole.com>From 9d75ebf5c8f09de66b580f3b14ed9becf627f85b Mon Sep 17 00:00:00 2001
From: Pirmin Kalberer
Date: Tue, 10 Jan 2012 00:55:08 +0100
Subject: [PATCH] V8 benchmark
---
CMakeLists.txt |4 ++
cmake/FindV8.cmake | 46 ++
tests/bench/CMakeLists.txt |3 +-
tests/bench/main.cpp | 23 ++-
tests/bench/qgsbench.cpp | 67
tests/bench/qgsbench.h |6
6 files changed, 147 insertions(+), 2 deletions(-)
create mode 100644 cmake/FindV8.cmake
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 67b686b..e82f373 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -117,6 +117,10 @@ IF (NOT BISON_EXECUTABLE)
ENDIF (NOT BISON_EXECUTABLE)
#
+
+FIND_PACKAGE(V8)
+
+#
# search for dependencies
IF(NOT WIN32 AND NOT ANDROID)
diff --git a/cmake/FindV8.cmake b/cmake/FindV8.cmake
new file mode 100644
index 000..e8038ba
--- /dev/null
+++ b/cmake/FindV8.cmake
@@ -0,0 +1,46 @@
+# Locate V8
+# This module defines
+# V8_LIBRARY
+# V8_FOUND, if false, do not try to link to V8
+# V8_INCLUDE_DIR, where to find the headers
+
+FIND_PATH(V8_INCLUDE_DIR v8.h
+${V8_DIR}/include
+$ENV{V8_DIR}/include
+$ENV{V8_DIR}
+~/Library/Frameworks
+/Library/Frameworks
+/usr/local/include
+/usr/include
+/sw/include # Fink
+/opt/local/include # DarwinPorts
+/opt/csw/include # Blastwave
+/opt/include
+/usr/freeware/include
+/devel
+)
+
+FIND_LIBRARY(V8_LIBRARY
+NAMES v8 libv8
+PATHS
+${V8_DIR}
+${V8_DIR}/lib
+$ENV{V8_DIR}
+$ENV{V8_DIR}/lib
+~/Library/Frameworks
+/Library/Frameworks
+/usr/local/lib
+/usr/lib
+/sw/lib
+/opt/local/lib
+/opt/csw/lib
+/opt/lib
+/usr/freeware/lib64
+)
+
+SET(V8_FOUND "NO")
+IF(V8_LIBRARY AND V8_INCLUDE_DIR)
+SET(V8_FOUND "YES")
+ENDIF(V8_LIBRARY AND V8_INCLUDE_DIR)
+
+
diff --git a/tests/bench/CMakeLists.txt b/tests/bench/CMakeLists.txt
index e505533..70f9db6 100644
--- a/tests/bench/CMakeLists.txt
+++ b/tests/bench/CMakeLists.txt
@@ -22,6 +22,7 @@ INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/../../src/core/raster
${CMAKE_CURRENT_BINARY_DIR}
# ${GDAL_INCLUDE_DIR} # remove once raster layer is cleaned up
+ ${V8_INCLUDE_DIR}
)
IF (WITH_INTERNAL_SPATIALITE)
@@ -44,6 +45,7 @@ TARGET_LINK_LIBRARIES(qgis_bench
${QT_QTWEBKIT_LIBRARY}
${QT_QTMAIN_LIBRARY}
${QT_QTTEST_LIBRARY}
+ ${V8_LIBRARY}
)
SET_TARGET_PROPERTIES(qgis_bench PROPERTIES
@@ -61,4 +63,3 @@ INSTALL (TARGETS qgis_bench
IF (APPLE)
INSTALL (CODE "EXECUTE_PROCESS(COMMAND ln -sfh ../../../${QGIS_FW_SUBDIR} \"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/${QGIS_BIN_DIR}/qgis_bench.app/Contents/Frameworks\")")
ENDIF (APPLE)
-
diff --git a/tests/bench/main.cpp b/tests/bench/main.cpp
index 2f50a6b..fc9ce3b 100644
--- a/tests/bench/main.cpp
+++ b/tests/bench/main.cpp
@@ -531,7 +531,28 @@ int main
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Le lundi 9 janvier 2012 22:27:46, Ivan Mincik a écrit : > On Mon, Jan 9, 2012 at 7:59 PM, Yves Jacolin (free) wrote: > > Hello, > > > > As I said before, I can help to migrate documentation to rst. I am using > > rst frequently for all the documentation so it is not a problem for me. > > > > The only issue I see is to create nice PDF documentation. I tested > > rst2odt which could help with pdf generator inside OOo but the rst2odt > > writer in sphonx does'nt exist. So we need to find a good solution. I > > tested one with my gdal documentation but this is not the way I will > > use. > > > > Sphinx can create PDF files but this is **really** difficult to change > > the design. > > > > If any Python guru can add rst2odt writer to sphinx it will really help! > > Maybe I do not understand your post correctly, what about to use rst2pdf ? > Ivan, Sphinx use rst2pdf to create pdf file, as said before, this is really a pain to customize design. Y. -- Yves Jacolin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
On Mon, Jan 9, 2012 at 7:59 PM, Yves Jacolin (free) wrote: > Hello, > > As I said before, I can help to migrate documentation to rst. I am using rst > frequently for all the documentation so it is not a problem for me. > > The only issue I see is to create nice PDF documentation. I tested rst2odt > which could help with pdf generator inside OOo but the rst2odt writer in > sphonx does'nt exist. So we need to find a good solution. I tested one with my > gdal documentation but this is not the way I will use. > > Sphinx can create PDF files but this is **really** difficult to change the > design. > > If any Python guru can add rst2odt writer to sphinx it will really help! Maybe I do not understand your post correctly, what about to use rst2pdf ? Ivan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Hello, As I said before, I can help to migrate documentation to rst. I am using rst frequently for all the documentation so it is not a problem for me. The only issue I see is to create nice PDF documentation. I tested rst2odt which could help with pdf generator inside OOo but the rst2odt writer in sphonx does'nt exist. So we need to find a good solution. I tested one with my gdal documentation but this is not the way I will use. Sphinx can create PDF files but this is **really** difficult to change the design. If any Python guru can add rst2odt writer to sphinx it will really help! Y. Le lundi 9 janvier 2012 18:36:16, Otto Dassau a écrit : > Am Mon, 09 Jan 2012 18:23:14 +0100 > > schrieb Paolo Cavallini : > > Il 09/01/2012 18:08, Otto Dassau ha scritto: > > > Migration is one thing and the other is that we are on the one hand > > > lucky to have so many people who help us translating the manual but on > > > the other hand only a few people are interested in updating the > > > englisch master document. So before people can start to translate, we > > > need to update the manual. > > > > Oh, I see. But this does not affect migration, I guess. On the contrary, > > if there is little activity in writing it, we'll have more time for > > migration. And I'm sure a nice web interface for writing will make it > > life easier for doc writers too. All the best. > > It affects migration, if the people writing and migrating are the same ;). > But anyway, it would be very helpful and a great step forward, to have a > more intuitive online tool for the documentation update/translation/... So > we should and will definitely go for it. > > Regards > Otto > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Yves Jacolin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Am Mon, 09 Jan 2012 18:23:14 +0100 schrieb Paolo Cavallini : > Il 09/01/2012 18:08, Otto Dassau ha scritto: > > > Migration is one thing and the other is that we are on the one hand > > lucky to have so many people who help us translating the manual but on > > the other hand only a few people are interested in updating the englisch > > master document. So before people can start to translate, we need to > > update the manual. > > Oh, I see. But this does not affect migration, I guess. On the contrary, > if there is little activity in writing it, we'll have more time for > migration. And I'm sure a nice web interface for writing will make it life > easier for doc writers too. All the best. It affects migration, if the people writing and migrating are the same ;). But anyway, it would be very helpful and a great step forward, to have a more intuitive online tool for the documentation update/translation/... So we should and will definitely go for it. Regards Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Il 09/01/2012 18:08, Otto Dassau ha scritto: Migration is one thing and the other is that we are on the one hand lucky to have so many people who help us translating the manual but on the other hand only a few people are interested in updating the englisch master document. So before people can start to translate, we need to update the manual. Oh, I see. But this does not affect migration, I guess. On the contrary, if there is little activity in writing it, we'll have more time for migration. And I'm sure a nice web interface for writing will make it life easier for doc writers too. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Am Mon, 09 Jan 2012 17:55:39 +0100 schrieb Paolo Cavallini : > Il 09/01/2012 17:53, Otto Dassau ha scritto: > > > I guess 2.0 is more realistic. There is some convert tools, but it will > > still be much work to migrate all styles or if that is not possible, to > > create a new nice looking manual. The speed depends on the number of > > people working on it. At the moment we don't have too many people > > writing or working on the documentation, that's why I think it will take > > a little longer. > > Understood. I'm pretty sure is we'll have a nice interface, without the > need to learn new tools (latex etc.) many more people will be available to > help. At least our Italian community is ready. That's why I was suggesting > to migrate ASAP, and put in place simpler tools for translators. > Of course if the migration itself is very heavy, this is a real problem. > Could we start from simpler pieces? > All the best, and thanks a lot. Migration is one thing and the other is that we are on the one hand lucky to have so many people who help us translating the manual but on the other hand only a few people are interested in updating the englisch master document. So before people can start to translate, we need to update the manual. Maybe we can encourage more people to update the manual. now that we have the latex sources in git, if they can use the online tools via github. I hope I will soon have some time to help and work on this topic/problem. Regards Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Il 09/01/2012 17:53, Otto Dassau ha scritto: I guess 2.0 is more realistic. There is some convert tools, but it will still be much work to migrate all styles or if that is not possible, to create a new nice looking manual. The speed depends on the number of people working on it. At the moment we don't have too many people writing or working on the documentation, that's why I think it will take a little longer. Understood. I'm pretty sure is we'll have a nice interface, without the need to learn new tools (latex etc.) many more people will be available to help. At least our Italian community is ready. That's why I was suggesting to migrate ASAP, and put in place simpler tools for translators. Of course if the migration itself is very heavy, this is a real problem. Could we start from simpler pieces? All the best, and thanks a lot. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Am Mon, 09 Jan 2012 17:41:22 +0100 schrieb Paolo Cavallini : > Il 09/01/2012 17:36, Otto Dassau ha scritto: > > > we started to work on a solution for the documentation and we decided to > > migrate the docs from latex to rst - but this has not happened yet. At > > this point we have the docs in git and we plan to start using the online > > tools provided by github to work on the englisch manual (latex) for the > > next release. > > Hi Otto. > You mean 1.7.4, or major release (2.0)? Why not moving to rst sooner? Will > it be a manual process, or there are efficient tools for migration? > All the best. Hi Paolo, I guess 2.0 is more realistic. There is some convert tools, but it will still be much work to migrate all styles or if that is not possible, to create a new nice looking manual. The speed depends on the number of people working on it. At the moment we don't have too many people writing or working on the documentation, that's why I think it will take a little longer. Regards Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Il 09/01/2012 17:36, Otto Dassau ha scritto: we started to work on a solution for the documentation and we decided to migrate the docs from latex to rst - but this has not happened yet. At this point we have the docs in git and we plan to start using the online tools provided by github to work on the englisch manual (latex) for the next release. Hi Otto. You mean 1.7.4, or major release (2.0)? Why not moving to rst sooner? Will it be a manual process, or there are efficient tools for migration? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Hi, we started to work on a solution for the documentation and we decided to migrate the docs from latex to rst - but this has not happened yet. At this point we have the docs in git and we plan to start using the online tools provided by github to work on the englisch manual (latex) for the next release. For the future we will convert the latex sources to rst and we are still open and thinking about an optimal solution for the translation process. Help and ideas is always welcome. That's what I can say for the manual/documentation. I remember I had a look at Sphinx some time ago. I liked it but haven't seen a solution for the manual translations with it - maybe that has changed. I guess, Werner can say more about the GUI and its translation. Regards Otto Am Mon, 9 Jan 2012 16:10:56 +0100 schrieb Marco Bernasocchi : > Hi all, I m not shure, but hasn't somebody already done sth in that > direction? Maybe was it Yves. I remember sth from the hackfest in Zh > Ciao > On Jan 9, 2012 4:02 PM, "Paolo Corti" wrote: > > > Hi Alessandro! > > > > > > > > We've also shortly talked about automatically build language-specific > > > snapshots of the QGIS GUI with a custom sphinx directive. > > > > > > > Yes, latest Sphinx version has a first class support for > > internationalization [1], so it should not be too hard to build an > > optimal solution for QGIS out of the box. > > We could then make the .po files editable by the Pootle web > > application [2], so every translator would have a pleasant editing > > experience and we could implement desired workflows. > > > > > Great to know you're willing to help, certainly you already know that > > > the new plugins web infrastructure is built upon our beloved Django :) > > > > > > > Oh yes, nice app! I have seen that, and I think you will be happy to > > know that Pootle is developed in Django as well :) > > So please let me know if I may go further with those experiments and > > design a more detailed proposal > > > > ciao > > P > > > > [1] http://sphinx.pocoo.org/intl.html > > [2] http://translate.sourceforge.net/wiki/pootle/index?redirect=1 > > > > -- > > Paolo Corti > > Geospatial software developer > > web: http://www.paolocorti.net > > twitter: @capooti > > skype: capooti > > ___ > > 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] WCS-T server
Hi John Does the WCS-T service need functionality from the QGIS API (raster layer, raster provider, ...)? If not, it could also be an option to build the WCS service directly on top of the GDAL library. QGIS (wms) server could certainly serve as an inspiration on how to implement other geospatial web services on top of the QGIS API. Code-wise, I don't think the WCS server can use many parts of the wms server. It would probably go into its own executable (qgis_wcs.fcgi or similar), be linked to qgis_core and use functions from libfcgi for communication with the webserver. Regards, Marco On 09.01.2012 11:59, John Donovan wrote: It's early days yet, but there might be a requirement for me to develop a Web Coverage Service server with transaction support. I thought about developing one from scratch, then I remembered QGIS's WMS server, and I thought I could build on that. Does anyone have any thoughts/experience/words of encouragement? The only WCS-T server out there that I can find is Rasdaman which is the reference implementation. -John -- Dr. Marco Hugentobler Sourcepole - Linux& Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WCS-T server
Il 09/01/2012 14:49, Andreas Neumann ha scritto: However, personally, I would first be interested in WFS(-T) rather than WCS-T. But this is just my own personal preference. I think the TinyOWS approach is quite efficient, and we could avoid reimplementing it here. It should be suffcient to do some lighter integration between TOWS and QGIS. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Hi all, I m not shure, but hasn't somebody already done sth in that direction? Maybe was it Yves. I remember sth from the hackfest in Zh Ciao On Jan 9, 2012 4:02 PM, "Paolo Corti" wrote: > Hi Alessandro! > > > > > We've also shortly talked about automatically build language-specific > > snapshots of the QGIS GUI with a custom sphinx directive. > > > > Yes, latest Sphinx version has a first class support for > internationalization [1], so it should not be too hard to build an > optimal solution for QGIS out of the box. > We could then make the .po files editable by the Pootle web > application [2], so every translator would have a pleasant editing > experience and we could implement desired workflows. > > > Great to know you're willing to help, certainly you already know that > > the new plugins web infrastructure is built upon our beloved Django :) > > > > Oh yes, nice app! I have seen that, and I think you will be happy to > know that Pootle is developed in Django as well :) > So please let me know if I may go further with those experiments and > design a more detailed proposal > > ciao > P > > [1] http://sphinx.pocoo.org/intl.html > [2] http://translate.sourceforge.net/wiki/pootle/index?redirect=1 > > -- > Paolo Corti > Geospatial software developer > web: http://www.paolocorti.net > twitter: @capooti > skype: capooti > ___ > 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] proposal for migrating QGIS documentation to reST/Sphinx
Hi Alessandro! > > We've also shortly talked about automatically build language-specific > snapshots of the QGIS GUI with a custom sphinx directive. > Yes, latest Sphinx version has a first class support for internationalization [1], so it should not be too hard to build an optimal solution for QGIS out of the box. We could then make the .po files editable by the Pootle web application [2], so every translator would have a pleasant editing experience and we could implement desired workflows. > Great to know you're willing to help, certainly you already know that > the new plugins web infrastructure is built upon our beloved Django :) > Oh yes, nice app! I have seen that, and I think you will be happy to know that Pootle is developed in Django as well :) So please let me know if I may go further with those experiments and design a more detailed proposal ciao P [1] http://sphinx.pocoo.org/intl.html [2] http://translate.sourceforge.net/wiki/pootle/index?redirect=1 -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti skype: capooti ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Fwd: Re: [Qgis-developer] WCS-T server
forwarding this to the list. I don't have a personal answer to this. Andreas Original Message Subject: Re: [Qgis-developer] WCS-T server Date: Mon, 9 Jan 2012 14:53:53 + From: John Donovan To: Andreas Neumann Well this is a client request, so I don't have a choice. But from what I can tell, transactions in both WCS and WFS are very similar, so I could certainly develop it with that in mind. So far, there's no requirement for a specific version of WCS, so what's the general idea when implementing such specifications? Because there is a pretty big difference between WCS 1.1.2 and WCS 2.0.0, the latter using GML coverages as its basis, and is more modular in its approach. Additionally, there's no specified support for WCS-T in 2.0.0 yet; Rasdaman seems to shoehorn 1.1.2 WFS-T into the 2.0.0 model. -John On 9 January 2012 13:49, Andreas Neumann wrote: Hi, I would also welcome it if we could have other OGC Server standards implemented in QGIS Server. However, personally, I would first be interested in WFS(-T) rather than WCS-T. But this is just my own personal preference. Andreas On Mon, 09 Jan 2012 14:03:37 +0100, Paolo Cavallini wrote: Il 09/01/2012 11:59, John Donovan ha scritto: It's early days yet, but there might be a requirement for me to develop a Web Coverage Service server with transaction support. I thought about developing one from scratch, then I remembered QGIS's WMS server, and I thought I could build on that. Does anyone have any thoughts/experience/words of encouragement? The plenty of encouragement from here. I do not have (yet) any direct interest on it, but I'm sure it will be a great addition, and IMHO QGIS is one of the nicest environments to work in. Looking forward to see it. BTW: wouldn't it be better to develop QGIS as a server *and* as a client? All the best. -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- One of the advantages of being disorderly is that one is constantly making exciting discoveries. - AA Milne -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: WFS feature IDs: when required, when not?
Hi Bill, I guess perhaps you could calculate the PointOnSurface (don't the centroids) for every single feature received. The PointOnSurface (available on spatialite for example) Will Allow you to understand if a new Features received is the same or is another. Another technics should be calculate the UUID of every feautre received. I guess this technics should allow to understand almost pretty well if a feature is repeated or not. Regards, Andrea. Il 09/01/2012 15:29, Bill Clay ha scritto: > All, > > Thanks to Andrea Peri, I have just discovered that WFS 1.0.0 apparently > does NOT require a WFS server to report a unique feature ID with every > feature it transmits (a typical newbie misconception?). > > The OGC specs are so nested and versioned, it's hard to be certain I've > understood them correctly. Could someone be kind enough to enlighten me > on the following? > > 1. Can you confirm or correct the following understandings: > > a. Every WFS server (versions 1.0.0 and 1.1.0) must have a permanent > unique identifier for every feature. > > b. WFS GetFeature responses version 1.0.0 may or may NOT provide a > unique "fid" attribute with each element, provided the layer > is not editable (WFS-T). > > c. WFS GetFeature responses version 1.1.0 MUST provide a unique "fid" > attribute with each element. > > 2. Are you aware of any common implementation of WFS 1.0.0 that does NOT > always report a "fid" attribute with every element? (I > understand TinyOFS can be configured not to do so.) > > 3. Do you believe that WFS services that do not always provide a "fid" > with every feature are unusual enough that the QGIS WFS client can > simply disable all feature caching for such servers? > > The proposal at item 3 would require GetFeatures to be requested for the > entire canvas extent every time any previously un-fetched area is > exposed on the canvas. Practically speaking, this means potentially long > delays on every pan and zoom-out on maps containing WFS layers with many > features that are hosted by such servers. > > Doubtless this is old news to everyone but me. Sorry for the static. > > Bill Clay > > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] WFS feature IDs: when required, when not?
All, Thanks to Andrea Peri, I have just discovered that WFS 1.0.0 apparently does NOT require a WFS server to report a unique feature ID with every feature it transmits (a typical newbie misconception?). The OGC specs are so nested and versioned, it's hard to be certain I've understood them correctly. Could someone be kind enough to enlighten me on the following? 1. Can you confirm or correct the following understandings: a. Every WFS server (versions 1.0.0 and 1.1.0) must have a permanent unique identifier for every feature. b. WFS GetFeature responses version 1.0.0 may or may NOT provide a unique "fid" attribute with each element, provided the layer is not editable (WFS-T). c. WFS GetFeature responses version 1.1.0 MUST provide a unique "fid" attribute with each element. 2. Are you aware of any common implementation of WFS 1.0.0 that does NOT always report a "fid" attribute with every element? (I understand TinyOFS can be configured not to do so.) 3. Do you believe that WFS services that do not always provide a "fid" with every feature are unusual enough that the QGIS WFS client can simply disable all feature caching for such servers? The proposal at item 3 would require GetFeatures to be requested for the entire canvas extent every time any previously un-fetched area is exposed on the canvas. Practically speaking, this means potentially long delays on every pan and zoom-out on maps containing WFS layers with many features that are hosted by such servers. Doubtless this is old news to everyone but me. Sorry for the static. Bill Clay ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] qgis-providers
Hello, Hope to be asking in the right place.. Just trying to find out if anyone knows what happened to the package "qgis-providers" that is now marked as "brocken" (version 1.9.90+git20120104+d04bc8f~oneiric1) on repository http://qgis.org/debian-nightly? I'm using Ubuntu 11.10, 64 bit. Thanks, Rui Pedro Henriques. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WCS-T server
Hi, I would also welcome it if we could have other OGC Server standards implemented in QGIS Server. However, personally, I would first be interested in WFS(-T) rather than WCS-T. But this is just my own personal preference. Andreas On Mon, 09 Jan 2012 14:03:37 +0100, Paolo Cavallini wrote: Il 09/01/2012 11:59, John Donovan ha scritto: It's early days yet, but there might be a requirement for me to develop a Web Coverage Service server with transaction support. I thought about developing one from scratch, then I remembered QGIS's WMS server, and I thought I could build on that. Does anyone have any thoughts/experience/words of encouragement? The plenty of encouragement from here. I do not have (yet) any direct interest on it, but I'm sure it will be a great addition, and IMHO QGIS is one of the nicest environments to work in. Looking forward to see it. BTW: wouldn't it be better to develop QGIS as a server *and* as a client? All the best. -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
Il 09/01/2012 11:30, Paolo Corti ha scritto: I would like to hear your opinion about eventually migrating the whole QGIS project docs to Sphinx. I am ready to contribute to this, if this idea is well receipt from all of you :) I think the barrier for new doc translators is currently rather high, and this approach seems to me quite productive. Any thoughts? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] postgres provider refactoring
Hi there, I just commited a larger change to the postgres provider. Mostly it's refactoring, but it also contains some features. You should now be able to use primary keys that are not numeric and even primary keys with more that one column should work (not sure how well the latter performs). The handling of the GEOMETRY type was also changed - the geometry type is now specified in the layer uri and therefore the automatically generated subset string is not necessary anymore. For empty tables you can select with geometry type to use. Views still need numeric primary keys and those need to be selected when adding. Please test and report. Author: Juergen E. Fischer Date: Thu Dec 29 00:02:47 2011 +0100 [FEATURE][API] postgres provider refactoring: - use m prefix for member variables and s prefix for class variables - refactor QgsPostgresProvider::Conn and QgsPostgresConnection to QgsPostgresConn - put QgsColumnTypeThread into separate file - use QgsPostgresConn in QgsPgSourceSelect - cleaner abort of column type thread (e.g. remove unfinished columns from selection list) - [API] move QgsDbTableModel as QgsPgTableModel to provider - [FEATURE] support for arbitrary key (including non-numeric and multi column) - [FEATURE][API] support for requesting a certain geometry type and/or srid in QgsDataSourceURI * no more explicit filter strings * support for empty tables without gemetry_columns entry or GEOMETRY type. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WCS-T server
Il 09/01/2012 11:59, John Donovan ha scritto: It's early days yet, but there might be a requirement for me to develop a Web Coverage Service server with transaction support. I thought about developing one from scratch, then I remembered QGIS's WMS server, and I thought I could build on that. Does anyone have any thoughts/experience/words of encouragement? The plenty of encouragement from here. I do not have (yet) any direct interest on it, but I'm sure it will be a great addition, and IMHO QGIS is one of the nicest environments to work in. Looking forward to see it. BTW: wouldn't it be better to develop QGIS as a server *and* as a client? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] More bounties
Hi all. One QGIS user has added a small bounty to two tickets: Bug #4583 Bug #3099 Anyone fixing it is entitled to claim it from Bill. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] WCS-T server
It's early days yet, but there might be a requirement for me to develop a Web Coverage Service server with transaction support. I thought about developing one from scratch, then I remembered QGIS's WMS server, and I thought I could build on that. Does anyone have any thoughts/experience/words of encouragement? The only WCS-T server out there that I can find is Rasdaman which is the reference implementation. -John -- One of the advantages of being disorderly is that one is constantly making exciting discoveries. - AA Milne ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] proposal for migrating QGIS documentation to reST/Sphinx
2012/1/9 Paolo Corti : > Hi all > > I am new to this list, as I am new to the QGIS development workflows, > but I am generally very interested in best practices for keeping > documentation. > > Together with Paolo Cavallini, we have been considering which best > practices could be considered for keeping the QGIS documentation. > You may probably already be aware that a wide spread approach for > keeping software documentation nowadays is to keep the documentation > in reStructuredText format, using Sphinx for rendering it and managing > multiple languages versions (via the Pootle web application, if we > expect a large numbers of users is willing to contribute). > > Documentation tied to specific release can just live in the source > tree, tagged together with sofware release and eventually rendered on > software web site pulling it from the source. > This is the same approach that has been used for other popular OSGeo > projects like MapServer and GeoServer. > I have tried to summarize the approach in this blog post [0] > > I would like to hear your opinion about eventually migrating the whole > QGIS project docs to Sphinx. I am ready to contribute to this, if this > idea is well receipt from all of you :) Hi Paolo, I've also had some conversations with both Tim Sutton and Paolo Cavallini on this topic, I also think that moving to reStructuredText would be beneficial. We've also shortly talked about automatically build language-specific snapshots of the QGIS GUI with a custom sphinx directive. Great to know you're willing to help, certainly you already know that the new plugins web infrastructure is built upon our beloved Django :) -- 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] proposal for migrating QGIS documentation to reST/Sphinx
Hi all I am new to this list, as I am new to the QGIS development workflows, but I am generally very interested in best practices for keeping documentation. Together with Paolo Cavallini, we have been considering which best practices could be considered for keeping the QGIS documentation. You may probably already be aware that a wide spread approach for keeping software documentation nowadays is to keep the documentation in reStructuredText format, using Sphinx for rendering it and managing multiple languages versions (via the Pootle web application, if we expect a large numbers of users is willing to contribute). Documentation tied to specific release can just live in the source tree, tagged together with sofware release and eventually rendered on software web site pulling it from the source. This is the same approach that has been used for other popular OSGeo projects like MapServer and GeoServer. I have tried to summarize the approach in this blog post [0] I would like to hear your opinion about eventually migrating the whole QGIS project docs to Sphinx. I am ready to contribute to this, if this idea is well receipt from all of you :) kind regards P [0] http://paolocorti.net/2012/01/05/managing_documentation_translations_with_open_source_tools/ -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti skype: capooti ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
