[Qgis-developer] NSIS installer size

[Blumentrath, Stefan]

Dear all,

With QGIS 2.18.6 I again have troubles to create a installer exe using 
creatensis.pl on Ubuntu.
The issue is likely that the installer gets to big when I include all possible 
Processing Providers (OTB,SAGA,GRASS) in one installer.
I tried all recommendations from NSIS here:
http://nsis.sourceforge.net/Failure_when_compiling_a_big_installer
But nothing had effect.
The resulting installer was earlier around 400MB and the unpacked-x86_64 dir 
has 2.2G.

Injecting a custom qgis.bat in the nsis-installer worked nicely for us, as the 
installer could be included in the Windows Software center. But maybe we have 
to move over to using OSGeo4W?

Any hint is very much appreciated.

Kind regards,
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Removal of the "Adding GRASS Tools" section in qgis.org?

[Blumentrath, Stefan]

Hi,

Technically the description of how to add GRASS modules to the GRASS plugin 
seems correct.

However, the whole thing would benefit from some updating as with the plugin 
upgrade a lot of new stuff was added and e.g. the 3 options max concept did not 
really work for e.g. the temporal modules.

With GRASS 7.2 more modules might be useful to add. Other modules might need 
updates (I did not check yet)… So, this info is IMHO relevant to keep, esp. 
cause this is a nice opportunity for non-developer to contribute…

It is naturally not “used” like e.g. Composer documentation, but one of the 
important things with documentation is that information is there when you need 
it…
I guess you would not trash your grandmothers recipe for apple-pie, just 
because you did not bake one the last two years…

Cheers
Stefan


From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of DelazJ
Sent: søndag 5. mars 2017 22.02
To: Paolo Cavallini 
Cc: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Removal of the "Adding GRASS Tools" section in 
qgis.org?

Hi,

Thanks to you.
Paolo, Do you think that it should stay there (especially if not used) and/or 
any idea where we could move it to?

Regards,
Harrissou


Le jeudi 2 mars 2017, Paolo Cavallini 
mailto:cavall...@faunalia.it>> a écrit :
> Il 02/03/2017 21:53, Tim Sutton ha scritto:
>
>>> To avoid keeping wrong/unused/useless texts while moving, I would like
>>> you to let us know if the "Adding GRASS tools" [3] section is worth
>>> keeping. Is it up to date and of use for someone? In which case is it
>>> inline with the other items of the QGIS Dev Guide? Or better moved
>>> somewhere else, e.g. in the GRASS Plugin chapter [4] of User Manual or
>>> ...? Or should we simply trash it?
>>
>> I think Paolo or Radim are best placed to answer this - perhaps email
>> them directly if they don't see this thread. And thanks for cleaning up
>> the docs so nicely!
>
> AFAIK it should still be valid info, even though I'm not sure someone is
> still working on this.
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Print one map for every category in layer with fixed extent

[Blumentrath, Stefan]

Hi again,

And thanks Alexandre for the alternative solution. Your workflow is quite 
flexible and powerful too, and seems to be a bit more simple.
Yet, I still assume (from the experience within my organization) that it is 
still a bit too complex for people who use QGIS (or GIS in general) rather 
seldom.

Thus I packed the Python script I compiled into a plugin (“SerialPrint”) for 
simplistic serial map production.

If one has a composer with a map item (and optionally a legend), the plugin 
will loop over a list of user defined layers and:

1 toogle the current layer visible,

2 insert an entry at the top of the legend,

3 export the composition to raster or PDF,

4 toogle the current layer invisible again, remove the respective 
legend entry and go to next layer in the list…

The plugin needs some cosmetics and would benefit from some enhancements I 
already have in mind, but it should be working OK.
It is available at: https://github.com/NINAnor/SerialPrint In addition, I also 
just uploaded it to the plugin repository (flagged as experimental), so testing 
becomes more easy.

I would be happy about tests and feedback!

Kind regards,
Stefan

From: Alexandre Neto [mailto:senhor.n...@gmail.com]
Sent: mandag 6. februar 2017 00.52
To: Blumentrath, Stefan ; Neumann, Andreas 

Cc: qgis-u...@lists.osgeo.org; Terje Blindheim 
Subject: Re: [Qgis-user] Print one map for every category in layer with fixed 
extent

So,

Imagining that you have layer as a regular grid. Each cell has, for different 
species, the number of individuals found stored in columns. You want to keep 
the map always with the same extent and iterate over the columns (species).
With atlas, all you need is a layer with a list of the names of all the columns 
you want to iterate. It does not have to be spatial, you can just create it as 
a simple CSV and import that in QGIS. You can also add it other columns with 
information that you want to use in the maps. Here an example:
"column_name", "common_name", "scientific_name" <-- first row can be used for 
column names
"specie_1", "specie 1 common name", "specie 1 scientific name"
"specie_2", "specie 2 common name", "specie 2 scientific name"
"specie_3", "specie 3 common name", "specie 3 scientific name"
After loading the layer and give it a name ("list_of_species" for this example) 
Use that layer atlas layer.

Let's say we want to draw the cell with some color if there are more that 0 
elements of a particular specie and white for the rest. In a rule-base 
simbology, you would need something like:
"specie_1" > 0  --> color
ELSE  --> white

Since we what to iterate the column name, we can get it from the atlas feature, 
and we can recreate a string that match the expression above. But we need to 
pass it trough the eval() function to make it work

eval('"' + attribute( @atlas_feature, 'column_name') + '" > 0')
Something similar can also be used directly in a graduated style, without the 
">0" part:

eval('"' + attribute( @atlas_feature, 'column_name') + '"')
I have planned to do a blog post about this, but it's in my long to do list.

Hope it helps.
Alexandre Neto


Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>> escreveu no dia 
domingo, 5/02/2017 às 19:41:
Hi Alexandre,

Currently I have a layer per species, but species could also be in one layer 
with names of the different species in the attribute table…

I already compiled a little Python script for my use case, however, if there is 
an existing function for that is better of course…

Thanks for helping.

Kind regards,
Stefan

From: Alexandre Neto 
[mailto:senhor.n...@gmail.com<mailto:senhor.n...@gmail.com>]
Sent: søndag 5. februar 2017 19.59
To: Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>; Neumann, 
Andreas mailto:a.neum...@carto.net>>

Cc: qgis-u...@lists.osgeo.org<mailto:qgis-u...@lists.osgeo.org>; Terje 
Blindheim mailto:te...@biofokus.no>>
Subject: Re: [Qgis-user] Print one map for every category in layer with fixed 
extent


In the layer, where is the species recorded? In Columns?

If so, I have a workflow for that.

A sáb, 4/02/2017, 08:38, Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>> escreveu:
Thanks Andreas for the excellent procedure description.

Good to know that Python is not required for that, and that there is a nice, 
flexible, and efficient solution!

For someone who uses QGIS on a regularly basis, this is actually much less work 
than it might seem at a first look.
However, I am afraid, if I imagine that I try to explain that to my colleagues, 
many would not be able or not willing to follow, I am afraid…

I found some more code snippets online, whi

Re: [Qgis-developer] Donate to QGIS badge for plugin Github repos

[Blumentrath, Stefan]

Thanks Tom,
I just added it to https://qgisnorge.github.io/blimed/ (which shall become 
qgis.no) the (under development) website for the Norwegian QGIS user group, 
that is about to be established...

Cheers
Stefan



-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Tom Chadwin
Sent: tirsdag 10. januar 2017 12.08
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Donate to QGIS badge for plugin Github repos

Hello all

I've been meaning to add a donate button to my QGIS plugin's Github repo 
README. For anyone who might want to do the same thing, and who likes the 
common shields.io style of badges, just add the following:

[![Donate to
QGIS](https://img.shields.io/badge/donate%20to-QGIS-green.svg)](http://qgis.org/en/site/getinvolved/donations.html)

You can see it in action on the qgis2web Github README.

Thanks

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Donate-to-QGIS-badge-for-plugin-Github-repos-tp5302751.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: removing support for GRASS6?

[Blumentrath, Stefan]

Hi,

The same applies probably for the GRASS-plugin.

Another related thing: a first GRASS GIS 7.2 release candidate will be tagged 
soon, which comes with a lot of new features. Once RC1 is available it might be 
worth looking at what should be changed / adopted in Processing and 
GRASS-plugin...

Kind regards,
Stefan

-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Paolo Cavallini
Sent: 26. oktober 2016 16:25
To: qgis-developer 
Subject: [Qgis-developer] Processing: removing support for GRASS6?

Hi all,
I think removing support for GRASS6 makes sense at least for QGIS 3.
This will reduce confusion among users, and will remove some bugs.
Anything against it?
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] memory-based layers and projects

[Blumentrath, Stefan]

Hei Martin,

Do you think of something like a python macro to be run at project start?

Then maybe this helps:
http://gis.stackexchange.com/questions/89903/is-there-a-way-to-run-a-python-script-on-opening-a-qgis-project

Cheers
Stefan


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Martin Landa
Sent: 10. oktober 2016 19:20
To: Chris Crook 
Cc: qgis-dev 
Subject: Re: [Qgis-developer] memory-based layers and projects

Hi,

2016-10-10 19:04 GMT+02:00 Chris Crook :
> One option you could use is to install the MemoryLayerSaver plugin.  That 
> saves the data for all memory layers in a project into a file named after the 
> project file.

thanks. But this option is something what I would like to avoid (no new files 
created, regardless format - SQLite Db or mldata). Ideally to provide to QGIS 
information how to load data (python code for running plugin reader) and from 
which file.

Anyway thanks for the feedback! Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] a graph plugin for QGIS

[Blumentrath, Stefan]

Hei Giuliano,

I would suggest also having a look at the igraph library: 
http://igraph.org/redirect.html.
Very powerful and feature rich and with Python, R, and C interface.
I used the library for network analysis in different context and can only 
recommend it...

Cheers
Stefan

-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Giuliano Curti
Sent: 13. september 2016 12:41
To: qgis-developer 
Subject: Re: [Qgis-developer] a graph plugin for QGIS

On 8/29/16, Giuliano Curti  wrote:
> On 8/29/16, Anita Graser  wrote:
>> Dear Giuliano,

Hi Anita, Hi Paolo, Hi all

I had a look at the available material on the subject of graphs / networks; I 
saw (very quickly) three products:
1) Library Network Analysis
2) the plugin Road Graph
3) the sDNAV plugin;

apart from the third product that seems to be the most complex tool and I have 
not seen well, the other two seems contain essentially the search for shortest 
paths by Dijkstra method; confirmed the great importance of the Dijkstra method 
for the graph theory, we need remember the many faces on the subject; in my 
(very
experimental) plugin I approach:
- the vertex and edge inquiry
- some (limited) editing (weight of edges)
- storage I/O
- trees (BFS, DFS)
- cycles
- minimum spanning tree (Jarnik-Prim and Boruvka-Kruskal)
- connectivity (cutpoints, bridges, vertex- and edge- connectivity)
- paths (shortest & not shortest, single & all)
- visualization with QGIS desktop
- (limited) import/export from/to SHP format;

I know, that's probably an approach more theoretic than practical oriented, but 
I think that these topics represents fundamental tools for graph analyzing; I 
will try to apply them in some actual case (the road graph on my town? :-) and 
describe it in the last part of the presentation article I uploaded at 
Slideshare;

in the topic of SHP import/export, it's very interesting the ability to build 
graphs starting from SHP files available in the Library Network Analysis, even 
though there does not convince me at all, for example, the plethora of 
generated vertices (suffices imho the end
points) and the automatic intersection of linestring with a shared vertex (I 
think might prevent the processing of not planar graphs);

so here's a first report (I took some commitment); I'll look better the classes 
of the  Network Analysis Library and I will try also to take a look at sDNAV 
plugin although I fear that now it is beyond of my potential; I repeat: I am 
not a graphs expert but a simple "mathematics" amateur, but if I can do some 
help to this part of the QGIS would gladly give a contribution;

sfmbe, thanks, bye,
giuliano
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS mapset in QGIS sample data unusable with new plugin?

[Blumentrath, Stefan]

Hei Anita,

The GRASS 7 plugin has the qgis.v.upgrade module for that purpose!

For recent GRASS sample data see:
https://grass.osgeo.org/download/sample-data/

For updating a grassdatabase from GRASS 6 to GRASS 7 see:
https://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7

Cheers
Stefan

From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Anita Graser
Sent: 28. juni 2016 21:27
To: qgis-developer 
Subject: [Qgis-developer] GRASS mapset in QGIS sample data unusable with new 
plugin?

Hi,

Just wanted to test the new GRASS plugin and noticed that the vector data in 
our Alaska sample cannot be opened and there is a note saying "topology version 
6" right next to the layer name in browser.

Is there a workaround? Can we update the QGIS sample data?

Best wishes,
Anita
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] No vector output with GRASS Processing

[Blumentrath, Stefan]

UbuntuGIS Stable ships GRASS 7 for Trusty.
https://launchpad.net/~ubuntugis/+archive/ubuntu/ppa?field.series_filter=trusty

And even plain Ubuntu ships GRASS 7 for the not LTS versions:
http://packages.ubuntu.com/search?keywords=grass

Differences in performance and functionality between GRASS 6 and GRASS 7 are 
huge!

I can only recommend switching to GRASS 7...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] No vector output with GRASS Processing

[Blumentrath, Stefan]

Hei Matteo,

Any particular reason for using GRASS GIS 6.4 instead of the latest stable 
GRASS GIS 7?
GRASS 7 will give you more functionality and much better performance! And 
probably not the same issues?

Cheers
Stefan
 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How would I get the GRASS r.in.lidar and v.in.lidar programs to show up in the Processing Toolbox?

[Blumentrath, Stefan]

Hi again,

I just saw that also the module descriptions are missing.

Try putting the attached file into:
YOUR_QGIS_INSTALLATION\apps\qgis\python\plugins\processing\algs\grass7\description

Maybe you have to remove the line containing
ParameterSelection|return_filter in the txt to make it run properly, as I do 
not know if it accepts an empty string as input... I did not test it...

In order to define the map extent you will have to inspect your las-file in 
advance (e.g. using las-tools).

Good luck.

Stefan

From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Blumentrath, Stefan
Sent: 1. juni 2016 07:45
To: Jim Bellenger ; Qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] How would I get the GRASS r.in.lidar and 
v.in.lidar programs to show up in the Processing Toolbox?

Hei Jim,

Without knowing some relevant details of your system I would guess you are 
facing this
https://trac.osgeo.org/osgeo4w/ticket/493
issue in liblas on Windows...

Cheers
Stefan

From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Jim Bellenger
Sent: 1. juni 2016 05:01
To: Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
Subject: [Qgis-developer] How would I get the GRASS r.in.lidar and v.in.lidar 
programs to show up in the Processing Toolbox?

I know that the programs are installed with the GRASS 7.0.3 of QGIS 2.14 but 
they don't show up in the Processing Toolbox.
r.in.lidar
Creates a raster map from LAS LiDAR points using univariate statistics.
Raster (r.*)
ParameterFile|input|LiDAR input files in LAS format (*.las or *.laz)|False
ParameterBoolean|-i|Import intensity values rather than z values|False
OutputRaster|output|Name for output raster map|False
ParameterSelection|method|Statistic to use for raster 
values|mean;n;min;max;range;sum;stddev;variance;coeff_var;median;percentile;skewness;trimmean|0
*ParameterSelection|return_filter|Only import points of selected return 
type|;first;last;mid|0
*ParameterSelection|type|Storage type for resultant raster 
map|FCELL;CELL;DCELL|0
*ParameterString|zrange|Filter range for z data (min,max)|
*ParameterNumber|zscale|Scale to apply to z data|None|None|1.0
*ParameterNumber|percent|Percent of map to keep in memory|1|100|100
*ParameterNumber|pth|pth percentile of the values|1|100|95
*ParameterNumber|trim|Discard  percent of the smallest and  percent 
of the largest observations|0.0|50.0|0.0
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How would I get the GRASS r.in.lidar and v.in.lidar programs to show up in the Processing Toolbox?

[Blumentrath, Stefan]

Hei Jim,

Without knowing some relevant details of your system I would guess you are 
facing this
https://trac.osgeo.org/osgeo4w/ticket/493
issue in liblas on Windows...

Cheers
Stefan

From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Jim Bellenger
Sent: 1. juni 2016 05:01
To: Qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] How would I get the GRASS r.in.lidar and v.in.lidar 
programs to show up in the Processing Toolbox?

I know that the programs are installed with the GRASS 7.0.3 of QGIS 2.14 but 
they don't show up in the Processing Toolbox.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing - current status of "in-between" layers while running models

[Blumentrath, Stefan]

Hei Paolo,

See: http://hub.qgis.org/issues/14856
Does not help for vector data, though...
Yet, there is also: https://grass.osgeo.org/grass70/manuals/v.external.out.html

Cheers,
Stefan


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Paolo Cavallini
Sent: 20. mai 2016 09:27
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Processing - current status of "in-between" 
layers while running models

Il 19/05/2016 21:53, Victor Olaya ha scritto:

> Forcing a format for all intermediate layer will have some advantages, 
> but also some drawbacks (for instance, if chaining 2 SAGA raster 
> algorithms, using any format other than the default SAGA sdat will 
> involve extra conversions)

In fact, it would be good to avoid exporting and reimporting files as much as 
possible. This is an especially serious problem for GRASS algs, where import 
can take longer than the actual analysis.

See you in Girona soon.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS Plugin missing g.copy?

[Blumentrath, Stefan]

Hi,

I just tested the Browser in QGIS. It has indeed no "Copy" in the context menu, 
just "Rename",  "Delete" or New vector layer.
However, Drag and Drop works fine. So if you want to copy a GRASS map, just 
drag it from the source to destination Mapset. Source and destination can be 
the same. If a map exists you are asked to specify a name...

Hence, g.copy is not present in the GRASS plugin in QGIS.

For me (QGIS 2.14.0, GRASS 7.0.3, OSGeo4W), g.copy starts also on the 
commandline. However, if you want to open the module GUI like that you have to 
run:
g.copy --ui

Cheers
Stefan

-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of roy roy
Sent: 10. april 2016 16:11
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] GRASS Plugin missing g.copy?



Il 10/04/2016 15:57, Blumentrath, Stefan ha scritto:
> Maybe the browser provides that functionality... I guess it does...
> Cheers
> Stefan

It does not but this is not the problem, i notice that i cannot start g.copy 
from GRASS itself using the shell, so it's not a "GRASS Plugin" issue but more 
a GRASS GIS issue,

sorry and thaks anyway, roy



> 
> Von: Qgis-developer [qgis-developer-boun...@lists.osgeo.org] im 
> Auftrag von roy roy [royr...@outlook.com]
> Gesendet: Sonntag, 10. April 2016 13:06
> An: qgis-developer@lists.osgeo.org
> Betreff: [Qgis-developer] GRASS Plugin missing g.copy?
>
> It seems that g.copy is not avalilable in GRASS Plugin, QGIS 2.14.1 is 
> this a "bug" or am i missing something?
>
> thanks, Roy.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS Plugin missing g.copy?

[Blumentrath, Stefan]

Maybe the browser provides that functionality... I guess it does...
Cheers
Stefan

Von: Qgis-developer [qgis-developer-boun...@lists.osgeo.org] im Auftrag von roy 
roy [royr...@outlook.com]
Gesendet: Sonntag, 10. April 2016 13:06
An: qgis-developer@lists.osgeo.org
Betreff: [Qgis-developer] GRASS Plugin missing g.copy?

It seems that g.copy is not avalilable in GRASS Plugin, QGIS 2.14.1
is this a "bug" or am i missing something?

thanks, Roy.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problem with GRASS Region Extent and Region Cellsize on Processing

[Blumentrath, Stefan]

Hi,

GRASS adjusts the resolution to the bounds (extent) you specified, either as n, 
s, e, w coordinates (like in Processing) or using the “vector” or “raster” 
option. This can conflicting with information provided through the user 
specified resolution; meaning that either bounds or resolution has to be 
adjusted. By default priority is given to the bounds (and resolution is 
adjusted if necessary) in GRASS, while setting the a-flag gives priority to the 
resolution (and bounds are adjusted).

However, if one wants to align the cells with a specific raster map, the 
“align” option should be used where only the resolution and placement of the 
cells (not the extent) is picked from the provided raster map. See: 
https://grass.osgeo.org/grass70/manuals/g.region.html

Personally, I would say the “align” option (e.g. as “align to input”) is more 
suitable for modules like r.aspect (and the resolution option could be removed) 
...
Specifying a resolution can make sense for modules like v.to.rast. However also 
here alignment with a specific raster (e.g. a DEM might be even more desirable).

There was another thing in Grass7Algorithm.py that surprised me: The use of 
r.out.gdal.
Using r.external.out befor running the algorithm, should be able to save you 
one read- and write step: 
https://grass.osgeo.org/grass70/manuals/r.external.out.html
Was it not applicable in Processing?

Cheers
Stefan



From: Pedro Venâncio [mailto:pedrongvenan...@gmail.com]
Sent: 13. mars 2016 17:47
To: Blumentrath, Stefan 
Cc: gene ; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Problem with GRASS Region Extent and Region 
Cellsize on Processing

Hi Martin and Stefan,

I understand, if we do not use the -a flag, we can not ensure that the 
resolution is the set.

What if there is another option, "align=", as Stefan suggested, which allows to 
choose a raster from the canvas? This would ensure that the region would be 
aligned with a selected raster?
Thank you very much!
Pedro



2016-03-12 10:44 GMT+00:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:


Von: Qgis-developer 
[qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 im Auftrag von gene [martin.lal...@gmail.com<mailto:martin.lal...@gmail.com>]
Gesendet: Samstag, 12. März 2016 10:46
An: qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Betreff: Re: [Qgis-developer] Problem with GRASS Region Extent and Region 
Cellsize on Processing

To keep the raster resolution.

In the book "OPEN SOURCE GIS A GRASS GIS Approach Third Edition",   p.57

"It may happen, that region boundaries lead to a modified, non-integer
raster resolution. If this is not desired, the -a flag can be used to align
the region to resolution. It adjusts all four boundaries to be even
multiples of the resolution by slightly enlarging the current region. To see
the effect, compare:
g.region res=15 -dp
g.region res=15 -adp"

Look also:

-  suggestion for g.region -a
<http://osgeo-org.1560.x6.nabble.com/suggestion-for-g-region-a-td4014517.html>
(Michael Barton)

"Currently, if you use the -a flag with g.region it will align the region
exactly to match the resolution of a map (e.g. g.region -a rast=myrast will
set the region to exactly the resolution of myrast regardless of the
extents) or the resolution specified in the res or ewres/nwres fields (e.g.
g.region -a n=523 s=15 res=10 will adjust the extents a little to make sure
the resolution is exactly 10)"

- or in  proposal: make -a flag the default behaviour for g.region
<https://trac.osgeo.org/grass/ticket/1745>  (Moritz Lennert)

"In my experience, when working with raster, having a precise resolution is
the most important issue, while exact extension is less important. I often
use existing vector data or bounds coordinates to determine the extent, but
then have to use the -a flag to make sure that the desired resolution is
kept.
I would like to propose that in grass7, the behaviour is switched, i.e. to
make the -a flag (Align region to resolution) the default behaviour, and
"align to bounds" the option"


I guess it depends a bit what the most suitable solution is... There is also 
the "align" option which aligns the resolution to an input raster. Personally, 
i only use tha a-flag only in combination with the res option...
Cheers,
Stefan





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Problem-with-GRASS-Region-Extent-and-Region-Cellsize-on-Processing-tp5255693p5255960.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/li

Re: [Qgis-developer] Problem with GRASS Region Extent and Region Cellsize on Processing

[Blumentrath, Stefan]

Von: Qgis-developer [qgis-developer-boun...@lists.osgeo.org] im Auftrag von 
gene [martin.lal...@gmail.com]
Gesendet: Samstag, 12. März 2016 10:46
An: qgis-developer@lists.osgeo.org
Betreff: Re: [Qgis-developer] Problem with GRASS Region Extent and Region 
Cellsize on Processing

To keep the raster resolution.

In the book "OPEN SOURCE GIS A GRASS GIS Approach Third Edition",   p.57

"It may happen, that region boundaries lead to a modified, non-integer
raster resolution. If this is not desired, the -a flag can be used to align
the region to resolution. It adjusts all four boundaries to be even
multiples of the resolution by slightly enlarging the current region. To see
the effect, compare:
g.region res=15 -dp
g.region res=15 -adp"

Look also:

-  suggestion for g.region -a

(Michael Barton)

"Currently, if you use the -a flag with g.region it will align the region
exactly to match the resolution of a map (e.g. g.region -a rast=myrast will
set the region to exactly the resolution of myrast regardless of the
extents) or the resolution specified in the res or ewres/nwres fields (e.g.
g.region -a n=523 s=15 res=10 will adjust the extents a little to make sure
the resolution is exactly 10)"

- or in  proposal: make -a flag the default behaviour for g.region
  (Moritz Lennert)

"In my experience, when working with raster, having a precise resolution is
the most important issue, while exact extension is less important. I often
use existing vector data or bounds coordinates to determine the extent, but
then have to use the -a flag to make sure that the desired resolution is
kept.
I would like to propose that in grass7, the behaviour is switched, i.e. to
make the -a flag (Align region to resolution) the default behaviour, and
"align to bounds" the option"



I guess it depends a bit what the most suitable solution is... There is also 
the "align" option which aligns the resolution to an input raster. Personally, 
i only use tha a-flag only in combination with the res option...
Cheers,
Stefan





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Problem-with-GRASS-Region-Extent-and-Region-Cellsize-on-Processing-tp5255693p5255960.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Please test length/area measurement in master

[Blumentrath, Stefan]

Hi Nyall,

Thanks for your work on this issue(s) and esp. the unit tests.

I did a swift test with a 100km vector grid using master version 5d989ab (which 
probably does not contain all your changes?).

Area measurements are consistent across field calculator and identify tool. 
However, the field calculator (using an 8 digits numeric field) shows some 
minor and probably neglectable imprecisions (e.g. compared to GRASS). GRASS 
reports exacly 100. m2, while the field calculator gives 
something like 100 +/- 0.0005 (OTF off).

With OTF on measurements differ significantly compared to GRASS and OTF off, 
due to ellipsoidal metric used with OTF on I guess. Personally, I find this 
difference confusing, but I trust the difference in behavior btw. OTF on and 
off is a deliberate choice of the more accurate area measure?!

Choosing no measurement ellipsoid in the project settings gives the same 
behavior as OTF off.

Kind regards,
Stefan





-Original Message-
From: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Nyall 
Dawson
Sent: 15. februar 2016 21:49
To: qgis-developer ; qgis-user 

Subject: [Qgis-user] Please test length/area measurement in master

Hi all,

Just putting out a call for extensive testing of length and area measurements 
in the current master version. Over the past week I've done a bunch of work 
trying to simplify the situation regarding length/area calculation and unit 
handling, with the intention of closing http://hub.qgis.org/issues/13209 and 
the other outstanding area calculation issues (plus locking all this down with 
unit tests!).

I'd really appreciate thorough testing being done by users to ensure that this 
bug is now indeed fixed prior to the 2.14 release.

Things to check:

- measured length/area is consistent across the identify tool results, field 
calculator, and measure tool. (note that there's still an open bug regarding 
virtual fields - there's a PR open to fix this but it's not merged yet). 
Testing with different combinations of geographic/non geographic CRS, OTF 
projection on/off and various ellipsoid/planimetric calculations would be 
perfect.
- test the new project properties settings for project distance/area units and 
coordinate formats
- test the reworked options for QGIS angle units and measurement of angles 
using the measure tool

Thanks in advance!

Nyall
___
Qgis-user mailing list
qgis-u...@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Why is ellipsoidal calculation tied to project OTF setting?

[Blumentrath, Stefan]

Hi Nyall,

Just as a note: The ellipsoidal measure is quite uncommon in other GIS packages.
PostGIS, SAGA, GRASS and the mayor proprietary GIS are all using a Cartesian 
measure. Deep down in the history of the several related tickets, you can see 
that users are often surprised if measures in QGIS differ from measures they 
got from other sources (including official statistics).

I am no geodesist, so I do not have the expertise to judge which type of 
measure should be favored / the default. But I would expect the other packages 
have their reasons for using Cartesian measurements... Given that the code for 
the ellipsoidal measurement is actually copied from GRASS, which mostly does 
not use it, I – as a lay person in this matter – would be a bit concerned to 
have an ellipsoidal area/distance measure as the default...

But that probably does not answer your question...

Cheers
Stefan


From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Nyall Dawson
Sent: 5. februar 2016 23:02
To: qgis-developer 
Subject: [Qgis-developer] Why is ellipsoidal calculation tied to project OTF 
setting?


Hi all,

While looking into the outstanding area/distance calculations issues there's 
something I'm struggling to understand.

In QGIS ellipsoidal distance/area calculations are ONLY enabled when the 
project has OTF crs transformation enabled. It could be because I've spent too 
long staring at this code and lost sight of the bigger picture, but why is this 
a requirement??

I can't see any reason why an ellipsoid can't be used even when layers aren't 
being reprojected on the fly. To me, it's a totally different setting without 
any relation to distance/area measurement.

If you don't want ellipsoidal calculation you could still set the ellipsoid to 
none. But you *could* potentially want ellipsoidal calculation even when OTF is 
off.

Am I missing something here?

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Improvements to the value relation widget: port to C++?

[Blumentrath, Stefan]

Hi Alessandro,

I have no particular opinion about how this is included in the fields and forms 
stuff best.
Just wanted to say thank you for this! It is really a great enhancement! 

Cheers
Stefan


> I would like to hear your thoughts about this.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing provider versions and hard coded path in settings

[Blumentrath, Stefan]

Hi again,

I tried to implement the detection of R in processing, comparable to what has 
been done for GRASS and SAGA.

This python code finds my R properly when I run it in a python shell (except 
for the isWindows() function of course):
{{{
if folder is None:
if isWindows():
if "ProgramW6432" in os.environ.keys() and 
os.path.isdir(os.path.join(os.environ["ProgramW6432"],'R')):
testfolder = os.path.join(os.environ["ProgramW6432"],'R')
elif "PROGRAMFILES(x86)" in os.environ.keys() and 
os.path.isdir(os.path.join(os.environ["PROGRAMFILES(x86)"],'R')):
testfolder = 
os.path.join(os.environ["PROGRAMFILES(x86)"],'R')
else:
testfolder = 'C:\\R'
if os.path.isdir(testfolder):
subfolders = os.listdir(testfolder)
subfolders.sort(reverse=True)
for subfolder in subfolders:
if subfolder.startswith('R-'):
folder = os.path.join(testfolder, subfolder)
break
else:
folder = ''
else:
folder = ''
}}}

However, when injected into the RFolder()-function RUtils.py it does not change 
anything and my R_FOLDER - although I deleted that entry from my QGIS.ini - is 
set to C:\OSGeo4W\bin which of course is not correct...

Any Ideas?

Thanks for helping...
Stefan

-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Blumentrath, Stefan
Sent: 25. januar 2016 15:56
To: Victor Olaya 
Cc: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Processing provider versions and hard coded path 
in settings

Hi Victor and Alex,

Thanks for your detailed replies!
That is nice, I was not aware that the paths are "auto-detected".
I now removed the respective settings from my QGIS.ini and GRASS 6 got detected 
properly.

However, when I tried GRASS 7 algorithms, I got a Python error:

TypeError: object of type 'NoneType' has no len() Traceback (most recent call 
last):
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\gui\ProcessingToolbox.py",
 line 192, in executeAlgorithm
message = alg.checkBeforeOpeningParametersDialog()
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\algs\grass7\Grass7Algorithm.py",
 line 531, in checkBeforeOpeningParametersDialog
msg = Grass7Utils.checkGrass7IsInstalled()
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\algs\grass7\Grass7Utils.py",
 line 359, in checkGrass7IsInstalled
cmdpath = os.path.join(path, 'bin', 'r.out.gdal.exe')
  File "C:\OSGeo4W\apps\Python27\lib\ntpath.py", line 96, in join
assert len(path) > 0
TypeError: object of type 'NoneType' has no len()


Python version: 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit 
(Intel)] 
QGIS version: 2.12.3-Lyon Lyon, 02885d5

So, I had a look at Grass7Utils.py and filed PR #2720.
Sorry for the conflicts in the PR (I just changed two lines). I am a 
git-beginner...
That should make path detection work for GRASS 7 again.
Yet, folder layout is OSGeo4W\apps\grass\grass-7.0.3RC2. But in 
OSGeo4W\apps\grass\, there can be also a grass-7.0.2 folder present in 
addition...

Cheers
Stefan


-Original Message-
From: Victor Olaya [mailto:vola...@gmail.com] 
Sent: 25. januar 2016 13:22
To: Blumentrath, Stefan 
Cc: Alexander Bruy ; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Processing provider versions and hard coded path 
in settings

Stefan,

here is a quick explanation

The paths are not hardcoded on the first install. Instead, Processing tries to 
find those dependencies (which usually works fine in osgeo4w distributions),or 
lets the user configure them manually. Once they are configured manually (as 
you have done), that value is stored as a setting (and written to the ini file 
for further uses). If you change your QGIS version or Processing version, the 
configuration is not changed, so it will use that value again and again (and 
since it is already configured, a new version of Processing wont try to find 
those dependencies).

The only solution to that is to have different ini files and specify which one 
to use in each case, using the --configpath option

Cheers

2016-01-25 12:54 GMT+01:00 Blumentrath, Stefan :
> Hi Alex,
>
> Thanks for your reply, and sorry if my question was a bit unclear...
>
> When I want to use e.g. GRASS 7 in Processing, I have to provide the 
> path to the "GRASS7 folder" in Processing --> Processing Options --> 
> Providers Fr

Re: [Qgis-developer] Processing provider versions and hard coded path in settings

[Blumentrath, Stefan]

Hi Victor and Alex,

Thanks for your detailed replies!
That is nice, I was not aware that the paths are "auto-detected".
I now removed the respective settings from my QGIS.ini and GRASS 6 got detected 
properly.

However, when I tried GRASS 7 algorithms, I got a Python error:

TypeError: object of type 'NoneType' has no len() 
Traceback (most recent call last):
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\gui\ProcessingToolbox.py",
 line 192, in executeAlgorithm
message = alg.checkBeforeOpeningParametersDialog()
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\algs\grass7\Grass7Algorithm.py",
 line 531, in checkBeforeOpeningParametersDialog
msg = Grass7Utils.checkGrass7IsInstalled()
  File 
"C:\Users\stefan.blumentrath\.qgis-custom/python/plugins\processing\algs\grass7\Grass7Utils.py",
 line 359, in checkGrass7IsInstalled
cmdpath = os.path.join(path, 'bin', 'r.out.gdal.exe')
  File "C:\OSGeo4W\apps\Python27\lib\ntpath.py", line 96, in join
assert len(path) > 0
TypeError: object of type 'NoneType' has no len()


Python version: 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit 
(Intel)] 
QGIS version: 2.12.3-Lyon Lyon, 02885d5

So, I had a look at Grass7Utils.py and filed PR #2720.
Sorry for the conflicts in the PR (I just changed two lines). I am a 
git-beginner...
That should make path detection work for GRASS 7 again.
Yet, folder layout is OSGeo4W\apps\grass\grass-7.0.3RC2. But in 
OSGeo4W\apps\grass\, there can be also a grass-7.0.2 folder present in 
addition...

Cheers
Stefan


-Original Message-----
From: Victor Olaya [mailto:vola...@gmail.com] 
Sent: 25. januar 2016 13:22
To: Blumentrath, Stefan 
Cc: Alexander Bruy ; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Processing provider versions and hard coded path 
in settings

Stefan,

here is a quick explanation

The paths are not hardcoded on the first install. Instead, Processing tries to 
find those dependencies (which usually works fine in osgeo4w distributions),or 
lets the user configure them manually. Once they are configured manually (as 
you have done), that value is stored as a setting (and written to the ini file 
for further uses). If you change your QGIS version or Processing version, the 
configuration is not changed, so it will use that value again and again (and 
since it is already configured, a new version of Processing wont try to find 
those dependencies).

The only solution to that is to have different ini files and specify which one 
to use in each case, using the --configpath option

Cheers

2016-01-25 12:54 GMT+01:00 Blumentrath, Stefan :
> Hi Alex,
>
> Thanks for your reply, and sorry if my question was a bit unclear...
>
> When I want to use e.g. GRASS 7 in Processing, I have to provide the 
> path to the "GRASS7 folder" in Processing --> Processing Options --> 
> Providers From there, in my case e.g. "C:\Program Files (x86)\QGIS 
> Lyon\apps\grass\grass-7.0.3RC2" has been saved as an absolute path to my 
> QGIS.ini file in my home directory.
>
> If I use different QGIS versions in parallel (e.g. latest stable and LTR) the 
> path can change. Furthermore, I have to update it manually, after each update 
> of GRASS or SAGA (because then the paths change as well...
>
> This is what I meant, not the source code...
>
> But maybe it would be better to have the paths themselves more stable...
> Recently, Helmut Kudrnovsky did some work on making RStudio available in the 
> GRASS console in OSGeo4W. Maybe something like this is needed to grab the 
> path to GRASS, SAGA or R for processing...?
>
> Cheers
> Stefan
>
>
> -Original Message-
> From: Alexander Bruy [mailto:alexander.b...@gmail.com]
> Sent: 25. januar 2016 12:13
> To: Blumentrath, Stefan 
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Processing provider versions and hard 
> coded path in settings
>
> Hi Stefan,
>
> Processing providers are just plugins, so they installed in the global QGIS 
> plugins directory. There is no hadrcoding in Processing sources related to 
> the providers.
>
> 2016-01-25 12:04 GMT+02:00 Blumentrath, Stefan :
>> Dear devs,
>>
>>
>>
>> In my QGIS.ini, the paths to the Processing providers are hard coded, 
>> which means I have to manually adjust them after every software 
>> update (Saga, GRASS, R).
>>
>> Any chance to pass the updates to the user(s)`s QGIS settings (or 
>> make QGIS recognizing the Processing providers installed together 
>> with QGIS), or is this only a limitation of the --configpath solution?.
>>
>>
>>
>> Should I extend:
>>
>> http://hub.qgis.org/issues/

Re: [Qgis-developer] Processing provider versions and hard coded path in settings

[Blumentrath, Stefan]

Hi Alex,

Thanks for your reply, and sorry if my question was a bit unclear...

When I want to use e.g. GRASS 7 in Processing, I have to provide the path to 
the "GRASS7 folder" in Processing --> Processing Options --> Providers
From there, in my case e.g. "C:\Program Files (x86)\QGIS 
Lyon\apps\grass\grass-7.0.3RC2" has been saved as an absolute path to my 
QGIS.ini file in my home directory.

If I use different QGIS versions in parallel (e.g. latest stable and LTR) the 
path can change. Furthermore, I have to update it manually, after each update 
of GRASS or SAGA (because then the paths change as well...

This is what I meant, not the source code...

But maybe it would be better to have the paths themselves more stable... 
Recently, Helmut Kudrnovsky did some work on making RStudio available in the 
GRASS console in OSGeo4W. Maybe something like this is needed to grab the path 
to GRASS, SAGA or R for processing...?  

Cheers
Stefan


-Original Message-
From: Alexander Bruy [mailto:alexander.b...@gmail.com] 
Sent: 25. januar 2016 12:13
To: Blumentrath, Stefan 
Cc: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Processing provider versions and hard coded path 
in settings

Hi Stefan,

Processing providers are just plugins, so they installed in the global QGIS 
plugins directory. There is no hadrcoding in Processing sources related to the 
providers.

2016-01-25 12:04 GMT+02:00 Blumentrath, Stefan :
> Dear devs,
>
>
>
> In my QGIS.ini, the paths to the Processing providers are hard coded, 
> which means I have to manually adjust them after every software update 
> (Saga, GRASS, R).
>
> Any chance to pass the updates to the user(s)`s QGIS settings (or make 
> QGIS recognizing the Processing providers installed together with 
> QGIS), or is this only a limitation of the --configpath solution?.
>
>
>
> Should I extend:
>
> http://hub.qgis.org/issues/12623
>
> (as it seems related) or should I open a new ticket (in case this 
> wanted and feasible of course)...
>
>
>
> Kind regards,
>
> Stefan
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Processing provider versions and hard coded path in settings

[Blumentrath, Stefan]

Dear devs,

In my QGIS.ini, the paths to the Processing providers are hard coded, which 
means I have to manually adjust them after every software update (Saga, GRASS, 
R).
Any chance to pass the updates to the user(s)`s QGIS settings (or make QGIS 
recognizing the Processing providers installed together with QGIS), or is this 
only a limitation of the --configpath solution?.

Should I extend:
http://hub.qgis.org/issues/12623
(as it seems related) or should I open a new ticket (in case this wanted and 
feasible of course)...

Kind regards,
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS and GRASS Plugin: How?

[Blumentrath, Stefan]

Hi Roy,

As for Windows: please have a look at Jürgen`s answer here:
http://osgeo-org.1560.x6.nabble.com/OSGeo4W-packages-for-GRASS-7-only-in-QGIS-tp5242272p5246651.html

Cheers
Stefan


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of m roy
Sent: 22. januar 2016 10:02
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] QGIS and GRASS Plugin: How?

Hi,

I'd like very much to use QGIS with the awesome new GRASS plugin, but lately it 
seems to be harder and harder (at least for me) to achieve this goal.
What i find really very confusing is what release (on windows) or PPA (personal 
package archive on ubuntu) we are supposed to use to have QGIS working with 
GRASS.
Now i do not have a fully working QGIS+GRASS system in windows (using
OSGEO4W)
nor in Ubuntu 14.04 because GRASS GIS in ubuntugis-unstable is no more 
compatible with QGIS or vice versa...

I think that QGIS and GRASS GIS enormously benefit each other and really hope 
someone could give advise on what package/osegeo/ppa/stable/unstable/installer
to use to simply have QGIS and GRASS run together :-)

thanks, Roy.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Trouble with creatensis.pl on Ubuntu 14.04 LTS

[Blumentrath, Stefan]

Hi,

I am trying to build a custom QGIS installer using creatensis.pl on Ubuntu 
14.04 LTS.

Unfortunately I am getting errors during unpacking:

"tar: A lone zero block at 380
tar: apps/Qt4: Cannot mkdir: Permission denied"

And apps/Qt4 indeed has unknown permissions: "d? ? ? ? ?"

After that I need sudo to remove unpacked-x86...

It happens rather randomly. Even packages which worked fine the first run throw 
errors on the next. However, it happens on every try both with master and 
release branch, and on both Ubuntu 14.04 LTS boxes I tried...

Any help would be very much appreciated...

Cheers
Stefan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] There is a way to eliminate the "Recent Projects" startup screen ?

[Blumentrath, Stefan]

Hi,

R for example does save the “workspace” for a session on request, but I am not 
sure if this is so relevant for QGIS at all. Actually, IMHO much better to 
start an empty project by default than a (probably heavy) recent project one 
does not want to continue with.

Something that might improve the situation in a simple way (though I have no 
problems with the current situation) could be to mark (e.g. grey out) projects 
that were moved (cannot be found at the specified location) or those could be 
put to the end of the list or something like that…

Cheers
Stefan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS layer history?

[Blumentrath, Stefan]

Hi Paolo,

I guess you are referring to the "command history" of your GRASS session?
It is stored in a file named ".bash_history" which is a simple text file, 
located within the folder of your mapset 
(GRASSDB/LOCATION/MAPSET/.bash_history).
You should be able to access it via browser...

Otherwise r.info and v.info should be able to show the history of a raster or 
vector map.

Hope that helps...

Cheers
Stefan


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Paolo Cavallini
Sent: 19. oktober 2015 11:38
To: qgis-developer 
Subject: [Qgis-developer] GRASS layer history?

Hi all,
I cannot find, in the current plugin, a way of recovering the history of either 
rasters or vectors: is this a known limitation, or am I missing how to get it?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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] New GRASS plugin: a test drive

[Blumentrath, Stefan]

Hi Radim,

Another issue:
The temporal maps are not listed in the input widgets. I assume that a 
"translation" for GRASS parser options 
(https://grass.osgeo.org/programming7/parser__standard__options_8c.html) to the 
QGIS GUI is missing for the temporal modules:
G_OPT_STDS_INPUT
G_OPT_STDS_INPUTS
G_OPT_STDS_OUTPUT ...

Not essential, but makes them easier to use...

Kind regards
Stefan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Radim Blazek
Sent: 6. oktober 2015 13:42
To: Paolo Cavallini 
Cc: qgis-developer 
Subject: Re: [Qgis-developer] New GRASS plugin: a test drive

On Tue, Oct 6, 2015 at 8:12 AM, Paolo Cavallini  wrote:
>>> yes - I tried, but the newly added polygon etc is not displayed once 
>>> digitized. Oh, now I see: the custom grass symbology prevents me 
>>> from seeing it. Once moved to single symbol, it is displayed.
>>
>>> I confirm an issue: I load a layer, activate editing, the layer is 
>>> no longer visible. When editing is deactivated, the layer remains invisible.
>>
>> There was a bug which I introduced on Friday, it was fixed in b09877b.
>> The style must be set (automatically) to GRASS Edit to get 
>> topological symbology.
>
> I still see the issue on current Debian sid package, just upgraded.

Which revision? Please use current master if possible.

Please start with points and lines. When you digitize a point or line, nothing 
is displayed in canvas? Do you see the elements if you switch style to default? 
Do you see the features in attribute table? Are the elements written to the map 
when you close editing?

 Note that QGIS can only display features of one type in a layer, if you add 
point layer and digitize a line, it will no show in point layer after editing 
is closed, a new layer with lines must be added to canvas.

Radim
___
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] New GRASS plugin: a test drive

[Blumentrath, Stefan]

>> Testing on windows
 GRASS LOCATION is "duplicated" displayed as a regular file system 
 folder and as GRASS LOCATION with the GRASS icon
>>> That is correct, the regular directory is left there so that is it 
>>> possible to go for example to dbf directory and load dbf files as 
>>> standard QGIS layers.
>>
>> IMHO: i find it's confusing, and GRASS 7 default database is SQLite, i 
>> think it could be smoother to expose only GRASS Locations and Mapset 
>> being evident that we're dealing with a GRASS Database, but i can live 
>> with that :-)
>
>You are not the first who is confused. Fix would be easy, so I remove regular 
>dir if it is recognized as GRASS location?

Indeed having the whole folder browseable might be confusing and users are not 
supposed to move files around in there anyway.
Yet, having the SQLite DB (or dbfs) of a mapset (if existing) available in the 
browser would be nice. That way also related / non-spatial tables in there 
could be easily added to QGIS. Probably even better if a context menu entry 
would allow to add the DB to "DB manager", so one can actually run queries 
without using db.execute or v.db.update...  But that`s for the future...

Regarding the tools-widget UI, I noticed that the "Close Mapset" butten takes 
space from the module tabs. The old "Close mapset" button was much smaller. 
Would it be possible to move that to the bottom of the GRASS module UI, where 
the Debug buttons are located (if debugging is activated)?
BTW, the tabs for the open modules can get pretty wide due to the icons (see 
e.g. v.db.join). Maybe better to use module names in the tabs?

Finally, I was wondering if it could be an idea to place all mapset related 
buttons (open / close / new / change mapset) at the bottom of the Modules 
dialogue and to add a "manage mapset access" button, which runs the mapset 
picker for modifying the search path (g.mapsets -s) there as well? One (I if 
you like) can add g.mapsets with the s-flag as a module (I tested "g.mapsets 
-s" in the QGIS-GRASS-plugin and it starts the GRASS dialogue successfully), 
but it is probably better to have this option a bit more prominent (as it might 
come in handy with the new multiple map input option)?

Anyway, great work you did and do with the plugin upgrade!

Cheers
Stefan 


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Minidump when using GDAL in plugin

[Blumentrath, Stefan]

That is most likely exactly the issue which a couple of other plugins face...

http://hub.qgis.org/issues/11901
http://hub.qgis.org/issues/10823
http://hub.qgis.org/issues/11891

Your report might be a step forward in solving this issues? Do we need a bug 
report up-streams for GDAL?

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of jawensi
Sent: 24. september 2015 12:58
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Minidump when using GDAL in plugin

Hello,

I have problems with  DEMto3D
   plugin.
Using this plugin in QGIS 2.10.1, QGIS crash on exit. Instead I test it in QGIS 
2.8.1 and works fine without minidump message on exit. 
I've tracked the problematic code and I find out that it's the use of the GDAL 
function ReadAsArray, for reading the content of a raster band.

/dem_dataset = gdal.Open(path_layer[0])
band = dem_dataset.GetRasterBand(1)
data = band.ReadAsArray(x_off, y_off, col_size, row_size)  /

The plugin works, but the problem is the crash dump on exit.

Any idea if the problem is in the plugin or in QGIS.?

Thank you



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Minidump-when-using-GDAL-in-plugin-tp5225874.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] GPS mit TAB und QGIS

[Blumentrath, Stefan]

Hi Sebastian,

We would need a bit more info.
Is your Tablet Win8 or Android?

I assume it is Win8, so have a look here: 
http://gis.stackexchange.com/questions/78857/how-to-make-work-tablet-integrated-gnss-gps-on-windows-8-with-qgis

Cheers
Stefan

From: qgis-user-boun...@lists.osgeo.org 
[mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of "Sebastian Teßmer"
Sent: 19. september 2015 13:18
To: qgis-u...@lists.osgeo.org; qgis-developer@lists.osgeo.org
Subject: [Qgis-user] GPS mit TAB und QGIS

Hi alle zusammen,

ich möchte mit meinem Tab und QGIS 2.8 in
der Natur GPS nutzen und Punkte bzw. Flächen aufzeichnen.
Leider ist in dem nutzbaren GPS Menü das "intern" als Menüpunkt
grau hinterlegt. QGIS erkennt also das interne GPS des Tabs nicht.
Kann mir vielleicht jemand sagen, was ich genau einstellen muss, um
das interne GPS nutzen zu können?

Vielen Dank!

Sebastian
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Crash on exit

[Blumentrath, Stefan]

Related tickets are here:
http://hub.qgis.org/issues/10823
http://hub.qgis.org/issues/11891
https://hub.qgis.org/issues/11901


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 18. september 2015 14:29
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Crash on exit

Il 18/09/2015 14:25, Andreas Neumann ha scritto:
> It is not a plugin from the public plugin repository, but a plugin 
> developed by ourself from the waste-water project ;-) apparently it 
> was a known-problem - but I did not know.

oh, I see, thanks. I'm asking because it happens with several plugins, and I 
believe we should make something to make QGIS more robust, and intercept these 
errors before crashing.
If your plugin crashes QGIS systematically, it could be a good test case.
All the best, and thanks.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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] plugin maintenance

[Blumentrath, Stefan]

Hi again,

Could please someone of the core devs have a look at # 11901.

According to the bug report, it appeared and disappeared although I did not 
make any changes to the plugin code. Actually, the plugin worked nicely for 
almost a year or so before the bug was reported the first time.

Furthermore, the issue seems to pop-up also with other plugins, according to 
bug reporter.

I am open for the possibility that the issue is due to this particular plugin, 
but then I would need help to identify what actually the reason is and where to 
start fixing it... Possibly GDAL related, as this was reported for Mac (which I 
have not available...).

Kind regards,
Stefan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 10. september 2015 18:56
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] plugin maintenance

Il 10/09/2015 10:44, Blumentrath, Stefan ha scritto:

> Recently, I updated the GarminCustomMap plugin which I developed a few 
> years ago, because users reported that it crashes QGIS.
> 
>  
> 
> Unfortunately, the bug reports (the plugin uses the QGIS bug tracker 
> system and repository) never were forwarded to me, so I noticed them 
> only with a significant delay...
> 
> So I was wondering if it is preferred that plugin authors use their 
> own versioning and bug tracking solution (github in my case)?

IMHO using only GitHub is the simplest option, and it works well enough.
Of course, I do not like it being proprietary software, but since QGIS code is 
already there, I think we can't complain.

> Furthermore, the plugin worked nicely with QGIS 2.0 to 2.4. While 
> problems were reported for 2.6 and later. I did not change the 
> plugin-code in that period, so issues must have been introduced by 
> external changes (likely in GDAL/OGR and their windows packages). I 
> see that it is impossible to prevent such issues, as plugins are by 
> nature not core. But how should plugin authors deal with that? Simply 
> send bug reports back to QGIS (in my case it came from there...)?

Yes, I think that's the correct approach.

Thanks for the report.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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] Lizmap Web Client - Time manager not loading

[Blumentrath, Stefan]

Thank you for looking into this!
Send me a note if I can be of help regarding testing or the like…

Cheers
Stefan

From: kimaidou [mailto:kimai...@gmail.com]
Sent: 11. september 2015 11:41
To: Blumentrath, Stefan 
Cc: Paolo Cavallini ; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Lizmap Web Client - Time manager not loading

Sorry for the late answer.

I will look at the github issue and see what is going on. I have made some 
improvements in future Lizmap release, and tested the differents demo projects 
against it, so things should be ok now.
Comparing between servers is not always possible, depending of QGIS Server 
versions.
Regards,
Michaël


2015-08-27 9:16 GMT+02:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:
OK, I opened a ticket:
https://github.com/3liz/lizmap-web-client/issues/193

Cheers
Stefan

-Original Message-
From: Paolo Cavallini 
[mailto:cavall...@faunalia.it<mailto:cavall...@faunalia.it>]
Sent: 26. august 2015 08:16
To: Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>; 
qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Subject: Re: [Qgis-developer] Lizmap Web Client - Time manager not loading
Il 25/08/2015 08:44, Blumentrath, Stefan ha scritto:

> As mentioned, the Montpellier tree demo (a bit more than 10k trees) did not 
> work either for me: 
> http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees#...

Confirmed here. Looks like a bug then.
All the best.

--
Paolo Cavallini - www.faunalia.eu<http://www.faunalia.eu>
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto: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

[Qgis-developer] plugin maintenance

[Blumentrath, Stefan]

Hi,

Recently, I updated the GarminCustomMap plugin which I developed a few years 
ago, because users reported that it crashes QGIS.

Unfortunately, the bug reports (the plugin uses the QGIS bug tracker system and 
repository) never were forwarded to me, so I noticed them only with a 
significant delay...
So I was wondering if it is preferred that plugin authors use their own 
versioning and bug tracking solution (github in my case)?

Furthermore, the plugin worked nicely with QGIS 2.0 to 2.4. While problems were 
reported for 2.6 and later. I did not change the plugin-code in that period, so 
issues must have been introduced by external changes (likely in GDAL/OGR and 
their windows packages). I see that it is impossible to prevent such issues, as 
plugins are by nature not core. But how should plugin authors deal with that? 
Simply send bug reports back to QGIS (in my case it came from there...)?

Kind regards,
Stefan

P.S.: For me it seems that it was sufficient to simply rebuild the plugin 
skeleton with latest Plugin-Builder (which was about time anyway), but 
sometimes identifying the problem can be quite time consuming and frustrating...

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Lizmap Web Client - Time manager not loading

[Blumentrath, Stefan]

OK, I opened a ticket:
https://github.com/3liz/lizmap-web-client/issues/193

Cheers
Stefan

-Original Message-
From: Paolo Cavallini [mailto:cavall...@faunalia.it] 
Sent: 26. august 2015 08:16
To: Blumentrath, Stefan ; 
qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Lizmap Web Client - Time manager not loading

Il 25/08/2015 08:44, Blumentrath, Stefan ha scritto:

> As mentioned, the Montpellier tree demo (a bit more than 10k trees) did not 
> work either for me: 
> http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees#...

Confirmed here. Looks like a bug then.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Lizmap Web Client - Time manager not loading

[Blumentrath, Stefan]

Hi Paolo,

Thanks for your reply.

My project is already quite minimalistic. It contains only one active / toogled 
layer from a Materialized View in PostGIS with ~ 650 points... (there is one 
other layer which is toogled off. I will remove for a test).
I tested both a datetime field (without timezone) and an integer field with 
different temporal granularities (1, 5, 20, and 50 years). No idea if the 
optional grouping fields might influence the situation (I did not use them so 
far...). Can it a problem if the field used in time manager contains NULL? 

As mentioned, the Montpellier tree demo (a bit more than 10k trees) did not 
work either for me: 
http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees#...

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 24. august 2015 08:46
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Lizmap Web Client - Time manager not loading

> Il 21/08/2015 21:21, Blumentrath, Stefan ha scritto:
> TM shoud work, just tested. Could you try with a very minimalistic project?
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> 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] Lizmap Web Client - Time manager not loading

[Blumentrath, Stefan]

Hi again,

I tested also Chrome Browser which seemed to be a bit faster than Firefox. Yet, 
Time manager does not load in Chrome either...
Probably related to the problem Paolo / Regis are reporting?

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Blumentrath, Stefan
Sent: 21. august 2015 12:38
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Lizmap Web Client - Time manager not loading

Hi,

I just started using Lizmap and I am very happy with it. Now I would very much 
like to use the time manager feature in Lizmap. Unfortunately it does not seem 
to work properly.

My maps do load nicely in Lizmap, but when I activate the Time Manager it does 
not go beyond "Loading map data". In other words I am facing the same problem 
like here: https://lists.osgeo.org/pipermail/qgis-user/2014-August/028981.html

I have Lizmap 2.10 on an internal server with lots of memory and ca. 650 points 
in total in a PostGIS database with single symbol (at the end I would like to 
use ca. 90k which render nicely without time manager) ...

Is that a bug or a browser (I use Mozilla Firefox) thing? 
http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees#<http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees>
 did not load with time manager either?

Thanks for helping in advance.

Kind regards
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Lizmap Web Client - Time manager not loading

[Blumentrath, Stefan]

Hi,

I just started using Lizmap and I am very happy with it. Now I would very much 
like to use the time manager feature in Lizmap. Unfortunately it does not seem 
to work properly.

My maps do load nicely in Lizmap, but when I activate the Time Manager it does 
not go beyond "Loading map data". In other words I am facing the same problem 
like here: https://lists.osgeo.org/pipermail/qgis-user/2014-August/028981.html

I have Lizmap 2.10 on an internal server with lots of memory and ca. 650 points 
in total in a PostGIS database with single symbol (at the end I would like to 
use ca. 90k which render nicely without time manager) ...

Is that a bug or a browser (I use Mozilla Firefox) thing? 
http://demo.lizmap.3liz.com/index.php/view/map/?repository=rep6&project=trees# 
did not load with time manager either?

Thanks for helping in advance.

Kind regards
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Using environment variables in path definitions in QGIS

[Blumentrath, Stefan]

See also:
http://hub.qgis.org/issues/12623

Maybe it is a bit tricky for a general solution, since variables are defined 
and named differently on the different OSes?...

As a workaround you could probably put a string replacement procedure into your 
QGIS.bat?
We used e.g. a "#USERPROFILE#" string, as a placeholder, which got replaced 
when a custom QGIS2 folder template - containing the QGIS.ini - was copied to a 
new user...

Not too trivial to replace a string in a text-file on Windows using batch (I 
understood from my colleagues)...

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Bo Victor Thomsen
Sent: 22. juni 2015 11:32
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Using environment variables in path definitions in 
QGIS

To the QGIS developers list -

I have a goal of making a fully portable Windows edition of QGIS. "Fully 
portable" means that I simply can install QGIS by copying the QGIS program 
directory to a location on the users PC and  start QGIS by double clicking on 
the QGIS.bat file in the "..\bin" directory.

I've reached 95% of my target by using the OSGeo4W installation as a template 
and making some modification the the start-up bat file. Mostly by using the 
--configpath qualifier to 1) redefine the location of the QGIS user directory 
.qgis2 and 2) not using the registry to save option values.

By using the --configpath qualifier QGIS creates and uses the 
.qgis2\QGIS\QGIS2.ini file to store option values normally located in the 
registry. Some of these values are path definitions:

example:

Configuration\SAGA_FOLDER=C:/OSGeo4W/apps\\saga
Configuration\GRASS_WIN_SHELL=C:/OSGeo4W/apps\\msys
Configuration\R_SCRIPTS_FOLDER=C:\\OSGeo4W\\.qgis2\\processing\\rscripts

I would like to use environment variables as part of the path definition in the 
ini file like this:

Configuration\SAGA_FOLDER=%OSGEO4W_HOME%/apps\\saga
Configuration\GRASS_WIN_SHELL=%OSGEO4W_HOME%/apps\\msys
Configuration\R_SCRIPTS_FOLDER=%QGIS_USERDIR%\\processing\\rscripts

(OSGEO4W_HOME and QGIS_USERDIR is environment variables, that contains the path 
for the QGIS program directory and the QGIS user directory)

The problem is, that QGIS doesn't interpret the %..% as a environment 
variable and replace it with the value of the variable but simply interprets it 
literally resulting in paths containing "%" - signs and environment variable 
names.

Is there a method to get QGIS to interpret the environment variable and replace 
it with the content of the variable ? Or should a put it on the wish list in 
the bug tracker ?

Regards
Bo Victor Thomsen
AestasGIS
Denmark



___
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] Network analysis

[Blumentrath, Stefan]

My recommendation would be igraph (http://igraph.org/).
Powerful, Open Source (https://github.com/igraph), well documented, and comes 
with Python, and C++ and R interfaces.
I used it in the r.connectivity.network addon for GRASS 6 and was quite happy 
with it!

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Andreas Neumann
Sent: 18. juni 2015 08:48
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Network analysis

This seems to be the important bit: 
https://github.com/QGEP/QGEP/blob/master/qgepplugin/tools/qgepnetwork.py

Andreas
On 18.06.2015 05:44, Nathan Woodrow wrote:
Hey all,

Has anyone done or know any good tools for doing network analysis in QGIS.  
Stuff like finding downstream nodes on pipes, turning off switches to see 
downstream effects?

I know there is a network x library for Python which might be able to do it 
however I can't seem to find it.  I thought it was uploaded to the plugin 
repository

Regards,
Nathan




___

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] QGIS as WPS server?

[Blumentrath, Stefan]

Hi Larry,

Maybe the WPS-GRASS-bridge:
https://code.google.com/p/wps-grass-bridge/wiki/PyWPS_Integration
could give some inspiration!?

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Larry Shaffer
Sent: 29. mai 2015 05:18
To: René-Luc Dhont
Cc: QGIS Developer List
Subject: Re: [Qgis-developer] QGIS as WPS server?

Hi,
I also am involved with some work that can benefit from WPS integration of 
Processing, and found René-Luc's new plugin while searching today.

What would help further in my situation is to be able to export the Processing 
model into a format that can be loaded as a backend process in another WPS 
setup, e.g. GeoServer with WPS, but configured via QGIS. René-Luc, any thoughts 
on that?

Is there a standardized definition for WPS that describing input/outputs that a 
Processing model can be exported into (assuming all dependencies would be the 
same on the remote server executing the process)? I looked in the spec and 
noticed the WPS Native Process Model [0]. Any experience with that?

[0] http://docs.opengeospatial.org/is/14-065/14-065.html#18
Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

On Mon, May 18, 2015 at 3:05 AM, René-Luc Dhont 
mailto:rldh...@gmail.com>> wrote:
Hi Paolo,

Here is a first implementation :
https://github.com/rldhont/PyWPS-QGIS-Processing

And I have to port it to QGIS-Server-Plugin.
All feedbacks are welcome.

Regards

Le 18/05/2015 11:02, Paolo Cavallini a écrit :
Hi all.
I have some interest in having a full implementation of QGIS as WPS
server. Is there anyone interested as well? Can we have a chat at the
HF, possibly joined by others on IRC?
Thanks.

___
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] QGIS master on Windows crashes on exit

[Blumentrath, Stefan]

Hi,

Confirmed also for code revision: 2ff6f72 on Win7 32bit...

Cheers,
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Andreas Neumann
Sent: 26. mai 2015 10:22
To: qgis-developer
Subject: [Qgis-developer] QGIS master on Windows crashes on exit

Hi,

It seems like a recent master version
(https://github.com/qgis/QGIS/commit/b91e43a) crashes on exit. I installed 
through OSGEO4W.

Can others confirm?

Thanks,
Andreas
___
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] Priority of Bug #12057 ?

[Blumentrath, Stefan]

Hei Matthias,

I am afraid I have to prioritize differently due to job obligations, even if 
Copenhagen is "just around the corner". I would have very much liked to join 
you. I hope to be able to attend next time...  However, if there is any means 
for me to contribute remotely (and if you consider it helpful), I will do my 
very best (I am no dev though and have only a very humble Python knowledge).

Cheers
Stefan


From: Matthias Kuhn [mailto:matth...@opengis.ch]
Sent: 11. mai 2015 15:57
To: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Priority of Bug #12057 ?

Hi Stefan,

I agree this is an important area and deserves being addressed properly.
It is also one that would be perfect for a set of unit tests.

I noticed that you started to collect issues that have been filed concerning 
this topic or related ones, I think this is a very good initiative.

A good approach to deal with this topic would be to
 * create a list of variables that influence the calculation
 * create a set of combinations of these variables (or eventually a full 
matrix) with expected results

Once this is formulated it should be straightforward to create unit tests, see 
which calculations are wrong and then fix them while being sure not to break 
others (because of the test suite).
Will you be present in Denmark?

Kind regards,
Matthias
On 05/11/2015 09:57 AM, Blumentrath, Stefan wrote:
Dear devs,
With QGIS you delivered a really excellent product with tons of useful features 
and I am very fond of it. I am aware that you get lots of user requests and 
have to prioritize according to that. Yet, my humble feeling is that there is 
one topic which did/does not receive the attention it probably deserves.
Proper area and distance calculation is a central functionality of any GIS. It 
is used by probably 97.5% of the users and should work in any case and without 
the need for the user to define some (at least for beginners) non-obvious 
settings, which in addition can get changed back by QGIS without the user`s 
notice, e.g. when loading data in different CRS (including Open Layers). 
Unfortunately, this seems to be a long open issue in QGIS (see: 
https://hub.qgis.org/issues/12057). If I may make one wish for the Hackfest 
next week, please make Bug #12057 (and related issues) a top priority of the 
event!
If such basic functionality gives wrong results, personally I would consider it 
as a risk for the good reputation of the QGIS project. Assume a user delivered 
project results to a customer, which are based on wrong area calculations (not 
unlikely that this happens), what do you think he or she feels about QGIS after 
that... And even if one discovers it beforehand. That does not exactly 
contribute to the user`s faith in the reliability of QGIS.
I dare say that this series of bugs is so severe, that if it gets fixed 
(hopefully one and for all), it would provide reason enough to justify a 2.8.3 
release (BTW. Thanks for 2.8.2).
Probably also worth writing a test for this bug, given it`s (long) history?

Kind regards,
Stefan





___

Qgis-developer mailing list

Qgis-developer@lists.osgeo.org<mailto: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

[Qgis-developer] Priority of Bug #12057 ?

[Blumentrath, Stefan]

Dear devs,
With QGIS you delivered a really excellent product with tons of useful features 
and I am very fond of it. I am aware that you get lots of user requests and 
have to prioritize according to that. Yet, my humble feeling is that there is 
one topic which did/does not receive the attention it probably deserves.
Proper area and distance calculation is a central functionality of any GIS. It 
is used by probably 97.5% of the users and should work in any case and without 
the need for the user to define some (at least for beginners) non-obvious 
settings, which in addition can get changed back by QGIS without the user`s 
notice, e.g. when loading data in different CRS (including Open Layers). 
Unfortunately, this seems to be a long open issue in QGIS (see: 
https://hub.qgis.org/issues/12057). If I may make one wish for the Hackfest 
next week, please make Bug #12057 (and related issues) a top priority of the 
event!
If such basic functionality gives wrong results, personally I would consider it 
as a risk for the good reputation of the QGIS project. Assume a user delivered 
project results to a customer, which are based on wrong area calculations (not 
unlikely that this happens), what do you think he or she feels about QGIS after 
that... And even if one discovers it beforehand. That does not exactly 
contribute to the user`s faith in the reliability of QGIS.
I dare say that this series of bugs is so severe, that if it gets fixed 
(hopefully one and for all), it would provide reason enough to justify a 2.8.3 
release (BTW. Thanks for 2.8.2).
Probably also worth writing a test for this bug, given it`s (long) history?

Kind regards,
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] information stored in a project file (2.8)

[Blumentrath, Stefan]

Hei Larissa,

Not sure how essential / relevant it is:
QGIS version and Queries stored in dbManager go also into the project file (at 
the moment).

Cheers
Stefan

-Original Message-
From: qgis-user-boun...@lists.osgeo.org 
[mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Larissa Junek
Sent: 17. april 2015 11:36
To: QGIS Mailing List; qgis-developer@lists.osgeo.org
Subject: [Qgis-user] information stored in a project file (2.8)

Hello,
I had a look at my *.qgs-files and so far I understand that there is 
information stored about
* Layers added
* Layer properties, icluding symbolisation and styles
* Projection for the map view
* Last viewed extend
* Print Composers
* Print Composer elements with settings
* Print Composer atlas settings
* Digitizing settings

Did I miss something essential? I want to insert the descriptions into the QGIS 
user manual 2.8.

Thanks in advance.

Kind regards,
Larissa
___
Qgis-user mailing list
qgis-u...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS server from ubuntugis-unstable /qgis.org/debian

[Blumentrath, Stefan]

Hi,
I am trying to install QGIS Server on UBUNTU from UBUNTU-GIS unstable 
repository.
On:
sudo apt-get install qgis-mapserver
I get the following error message:
"The following packages have unmet dependencies:
qgis-mapserver : Depends: qgis-providers (= 2.4.0-0trusty3) but 2.6.1-1trusty1 
is to be installed
E: Unable to correct problems, you have held broken packages."

Adding the QGIS repository (http://qgis.org/debian) does not help...

Any ideas how to fix it?

Thanks for helping,
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] dbManager: Store queries in QGIS profile?

[Blumentrath, Stefan]

Hi Oliver and Paolo,

Thanks for your feedback.
I see your point of project specific queries. That is probably the most common 
situation.
The use cases I had in mind were, that

a)  some queries go (with minor modifications) through several projects 
(like e.g. point-sampling layers with environmental information or overlay 
statistics with land cover data and so on), and

b)  such frequently used types of queries could also be useful to be shared 
among users of one institution.
For such queries e.g. the QGIS profile could be a nice place to store them. 
However the parallel solution (project and probably QGIS profile in future) you 
sketched, Oliver, sounds perfect. That way modifications of “template queries” 
for a specific project can be stored separately…

I shall open a ticket for that asap (at the moment redmine says it is under 
heavy load and I should try again later…).

Cheers
Stefan

From: Paolo Cavallini [mailto:cavall...@faunalia.it]
Sent: 3. februar 2015 19:53
To: Olivier Dalang; Blumentrath, Stefan
Cc: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] dbManager: Store queries in QGIS profile?

Hi Stefan,
Could you please open feature requests for these?
Thanks.
Il 03 febbraio 2015 16:17:11 WET, Olivier Dalang 
mailto:olivier.dal...@gmail.com>> ha scritto:
Hi !

Technically it's easy to store the queries globally (I did the implementation 
of the store queries feature some time ago, and guess it is around 1 hour work)

But I think we have to leave the possibility to store them in the project file 
as well, as some queries are really project-specific (actually all of them in 
my use cases).
Probably the best would be to allow both. There would be two store buttons, and 
the two categories could be listed in the same drop down box with a line 
separator.

Bests,

Olivier


2015-02-03 13:43 GMT+00:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:
Dear devs,

QGIS is an excellent frontend to PostGIS with lots of functionality.
One thing I was wondering is, why does dbManager store queries in the project 
file and not in e.g. the QGIS user profile (.qgis2) or the registry? Is that on 
purpose?

I was planning to deploy some default queries which might be used in several 
different projects or by different people via a batch file I already use for 
import of QGIS settings on new installations (along with PostGIS connections 
and so on).

I see that I can add my queries to project templates, but that would mean I 
have to maintain them at (at least) at three different places (in each 
project). For me it would be more convenient to have them separated from the 
projects. Could that be an option for the future? BTW. The Combo-box could be a 
bit longer, so that names for the queries are more readable…

Cheers
Stefan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer




Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer

--
http://faunalia.eu/
Sent from mobile, sorry for being short
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] dbManager: Store queries in QGIS profile?

[Blumentrath, Stefan]

Dear devs,

QGIS is an excellent frontend to PostGIS with lots of functionality.
One thing I was wondering is, why does dbManager store queries in the project 
file and not in e.g. the QGIS user profile (.qgis2) or the registry? Is that on 
purpose?

I was planning to deploy some default queries which might be used in several 
different projects or by different people via a batch file I already use for 
import of QGIS settings on new installations (along with PostGIS connections 
and so on).

I see that I can add my queries to project templates, but that would mean I 
have to maintain them at (at least) at three different places (in each 
project). For me it would be more convenient to have them separated from the 
projects. Could that be an option for the future? BTW. The Combo-box could be a 
bit longer, so that names for the queries are more readable...

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Attribute-table-to-CSV trouble

[Blumentrath, Stefan]

I found no related open ticket.
Opened one now. See: https://hub.qgis.org/issues/12111

-Original Message-
From: Paolo Cavallini [mailto:cavall...@faunalia.it] 
Sent: 30. januar 2015 10:43
To: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Attribute-table-to-CSV trouble

Il 30/01/2015 10:03, Blumentrath, Stefan ha scritto:
> Sounds good. Generally, it would be a significant improvement if the 
> "Export function" in DB manager could allow other formats than shape.
> Here I think esp. of SQLite-ish formats for example, since shape is 
> limited to 2GB and column names will probably have to be truncated and 
> so on...

exactly - probably good to open a ticket, if not already

> Regarding CSV-export however, I would expect that at least "copy and 
> paste" and "Save as" is something users may frequently try (as it is 
> probably also most natural to do so). So these functions should not 
> fail easily or be dependent on data source (of course millions of 
> records do not necessarily fit into memory in case of copy/paste), 
> what do you think?

copy-paste, as you noted, is fragile, and I would not particularly encourage 
its use. Save as... however should work.

> Is the OGR ID trouble a GDAL/OGR issue, or would it help if QGIS would 
> provide the -preserve_fid option?

AFAIK it's a GDAL issue - perhaps you could check if ogr2ogr works for you, and 
open the ticket where appropriate? (gdal or qgis)

> Do you want me to open ticket(s), also for the plugin issues never the 
> less? BTW, I could not find the bug tracker for mmqgis, the links in 
> the QGIS plugin homepage only lead to the plugin home page, which does 
> not seem to have a bug tracker...

This is a long standing problem. I'm gradually trying to convince new plugin 
authors to add a code repo and a bugtracker; for older plugins, we have to ask. 
Perhaps a direct email to the author could help.

All the best, and thanks for raising the issue.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Attribute-table-to-CSV trouble

[Blumentrath, Stefan]

Hei Paolo,

Sounds good. Generally, it would be a significant improvement if the "Export 
function" in DB manager could allow other formats than shape. Here I think esp. 
of SQLite-ish formats for example, since shape is limited to 2GB and column 
names will probably have to be truncated and so on...

Regarding CSV-export however, I would expect that at least "copy and paste" and 
"Save as" is something users may frequently try (as it is probably also most 
natural to do so). So these functions should not fail easily or be dependent on 
data source (of course millions of records do not necessarily fit into memory 
in case of copy/paste), what do you think?
Is the OGR ID trouble a GDAL/OGR issue, or would it help if QGIS would provide 
the -preserve_fid option?
Do you want me to open ticket(s), also for the plugin issues never the less? 
BTW, I could not find the bug tracker for mmqgis, the links in the QGIS plugin 
homepage only lead to the plugin home page, which does not seem to have a bug 
tracker...

Cheers
Stefan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 30. januar 2015 08:55
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Attribute-table-to-CSV trouble

Il 29/01/2015 23:51, Blumentrath, Stefan ha scritto:

> I was trying to export the attribute table of a set of PostGIS layers 
> from QGIS to CSV.

> At the end I used mmqgis, but for newbees this procedure (and the 
> number of non-working options) might appear a bit cumbersum...

Sure it is. IMHO this should be implemented in DB Manager; it should be rather 
easy.
All the best.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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

[Qgis-developer] Attribute-table-to-CSV trouble

[Blumentrath, Stefan]

Dear all,

I was trying to export the attribute table of a set of PostGIS layers from QGIS 
to CSV.
The tables contain a column "ID" (which was the original id) and a column "id" 
added during import to PostGIS, and a PostGIS "date" column.

I tried four different approaches for exporting the attribute table to CSV 
(copy and paste, mmqgis, Quick Export, and "Save as" CSV), in QGIS 2.6.1 none 
of them worked as expected:

-Copy and paste of the content of the attribute table worked fine for a 
layer with ca. 1800 features, but in the PostGIS layer with more than 12000 
records only the heading was copied/pasted

-mmqgis exported the "date" fields as text, "Qt.*date*(, MM, DD)", 
which is not very convenient because it requires search and replace after export

-Quick Export crashed with a Python error

-"Save as" complained about the fact that there already is a column 
named ID, so OGR was not able to name the feature ID that way in the output... 
("Error: creation of field ID failed (OGR error: Attempt to create field ID, 
but a field with this name already exists.)", and I was not able to provide the 
-preserve_fid option which might have helped here)

Are some of these known issues or is it just my data and me?
At the end I used mmqgis, but for newbees this procedure (and the number of 
non-working options) might appear a bit cumbersum...

Kind regards
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Best practice for a new Vector Data Provider

[Blumentrath, Stefan]

Hei Sverre,

Did you consider writing a GDAL/OGR driver for your format, which then could be 
used by QGIS for accessing it?
That way it could also be used in / accessed by other OSGeo tools?

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Sverre Jonassen
Sent: 28. januar 2015 13:05
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Best practice for a new Vector Data Provider

Hi everybody,

I am currently trying to make a new vector data provider with a source select 
dialog for QGIS so that QGIS can read and display data stored in a custom 
format. The format in question proprietary to software developed and maintained 
by the company I work at. I am quite new to developing for QGIS and I am 
struggling to find the best approach to do this. I hope that somebody out there 
can help me. I have not been able to find any internet resources on best 
practices for a data provider plugin.

So far, I have succeeded in creating a very simple vector data provider plugin 
and accessing it through a source select dialog (which I have added to the 
src/ui/-folder). This is, of course, not a suitable approach as it would mean 
that I have to build and deploy my own version of QGIS instead of a plugin. As 
far as I have understood it, there might be 3 possible approaches for me to 
make a new provider with a source select dialog:

1) An ordinary C++ plugin for the source select dialog containing the 
provider. Is this possible? I have tried this and so far not succeeded.

2) A provider plugin containing all necessary ui. Is this possible? And if 
so, how can I add a menu-item to activate the source select dialog?

3) A provider plugin without ui and a separate plugin with the source 
select dialog.

A fourth option would be to create a plugin for OGR. This is, however, not a 
good solution for me because I would run a high risk of data conversion errors. 
Our format is much more similar to the QGIS internal geodata model than to the 
OGR geodata model.

I am developing on the Windows platform, using Visual Studio 2010. Primarily I 
want to create a C++-plugin since the API for our proprietary format is written 
in C++, and because my daily development environment has no support for Python.

Any help would be greatly appreciated,

Best regards,

Sverre Jonassen
Senior software engineer
sverre.jonas...@norkart.no
+47 402 45 794


[cid:image001.png@01D03B1E.97F1D390]

Løkketangen 20A
Postboks 145
N- 1300 Sandvika
+47 67 55 14 00
norkart.no
__

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS web client not displaying full WMS extent

[Blumentrath, Stefan]

Hi Andreas,



Thanks for your reply, and sorry for the confusion. It is indeed a "QGIS as a 
WMS client" issue.

I now tested with different CRS which the WMS uses, namely EPSG:25833,32633,and 
4326.

I added one layer for each CRS and then stepwise changed my project CRS.



With my QGIS project in WGS84 all data of the layer WGS84 layer is displayed 
properly (however in a form which is little suitable for map production), while 
EPSG:25833 layer only showed the lower left quarter of the map and 32633 had 
the "clipped" data extent mentioned.

Then I switched to EPSG:25833. Here for the WGS84 layer and the EPSG:25833 
layer only the lower left quarter of the map is visible, and the EPSG:32633 
layer had again the clipped extent. Zoom-to-layer on the EPSG:25833 resulted in 
a 1:35Mio scale while zoom-to-layer on the EPSG:32633 layer resulted in a 
1:10Mio scale...

Switching the project to 32633 gave the same result as the project in 25833.



Here I also noticed that on-the-fly projection was activated when switchen 
forth and back between layers...



 So, it seems indeed somehow related to CRS, do you have a second or third 
thing you would check?

Does the server send different data for different CRS? Or is it something else?



Cheers

Stefan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS web client not displaying full WMS extent

[Blumentrath, Stefan]

Hi,

I am having some trouble with properly displaying a WMS in QGIS 2.5:

The web-client (http://kart.fiskeridir.no/default.aspx?gui=1&lang=1 (activate 
e.g. first layer in the "Fiskeriaktivitet"-tab) for the WMS I use displays a 
much wider data extent than the WMS in QGIS 
(http://kart.fiskeridir.no/wms.aspx? , here one may have to set tile size 
(something like 1000x1000) and choose png format in order to make it visible). 
In QGIS the WMS seems to be clipped in N,S,E, and W, while another proprietary 
GIS displays the WMS correctly (like the web-client)...

Any idea what the problem could be here?

Is it a user issue, a server issue or is it a web-client issue and probably 
related to (or a variant of):
https://hub.qgis.org/issues/10634
?
I was using QGIS 2.5 master (d833c22) through OSGeo4W.


Thanks in advance for helping.

Cheers
Stefan

P.S.: I had this posting already on the user-mailinglist, but managed to send 
it into another existing thread (and got no response), so I hope you do not 
mind that I re-send it to the devs-list...
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] MetaSearch 0.3.0 released

[Blumentrath, Stefan]

Hi Tom,

if you allow me a user-question here:

>Having said this, what about the Layer properties dialog's Metadata section? 
>There
>is almost enough there for a fulsome enough metadata record.  Adding
>a CSW publishing client ('Publish Metadata') would be straightforward.

Such a feature would be very much appreciated. Would you think of shipping a 
CSW server (e.g. pyCSW) with a QGIS installation / make that a dependency for a 
plugin or do you think of an interface to Metadata catlogue software like (from 
the group of OSGeo tools) GeoNetwork. The latter - which probably would be 
comparable with this solution in the proprietary world: 
https://www.geocat.net/bridge/ - would be nice, because it would a) improve 
interoperability between OSGeo projects, and b) help in central metadata 
management of an organisation (while the former is probably mor beneficial for 
smaler companies or single users which do not operate something like 
GeoNetwork)!
Otherwise, a way to get metadata from QGIS published (e.g. in GeoNetwork), 
would be XML-import...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] error creating QGIS package with creatensis

[Blumentrath, Stefan]

Another thing to consider in this context is that there are open issues with 
the gdal-sosi package on Windows[1].
Given that the sosi-driver-plugin works properly with GDAL, but not in QGIS it 
might be good to have it in OSGeo4W, but not necessarily in the QGIS 
stand-alone installer or as a dependency of the qgis-full-package (yet)? So, a 
workaround could be to just remove it from qgis-full dependency list...

[1] http://lists.osgeo.org/pipermail/qgis-developer/2014-June/033505.html

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] error creating QGIS package with creatensis

[Blumentrath, Stefan]

Hi Matteo,

Yes, quite sure:
http://download.osgeo.org/osgeo4w/x86_64/release/gdal/gdal-sosi/

I did not check the content of the new package though, but I guess it was 
Jürgen who created the 4.0-2 package, and I cannot imagine that he did 
something else than fixing the paths-settings...

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of matteo
Sent: 2. juli 2014 10:37
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] error creating QGIS package with creatensis

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Stefan,
are you sure that Jürgen fixed the problem yesterday?
He wrote that the problem is only for linux users because of a mix between back 
and for slashes.

I see here https://github.com/qgis/QGIS/tree/master/ms-windows/osgeo4w
that the last update is of 3 days ago...

Cheers

Matteo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTs8TGAAoJEBy7UYf0gaEOLAAH/0HDgI4h7028Bq35+D6JJuAA
VDcgltxl+bHtdvObhwOeFxAs+xbsJOAQaF9wW7n7KCNKo7nZ1oiafKMNCSQfAZ0y
F0zpxMI2apGSGWkxuGH9moHZQlKskbYJGL2gC8yv9xAN7+KlVbbncsHbkdnnhKH0
5e4MhbqTky+1lBt5OPO7xe9LfN/TY7BJfEJe3BIpao3z8imuiQ4XpxCatmA5uvdm
XnNcTL1EMiSS/S5KZc6gwvS25PM48ml9mVdjBUNoWT5b3myNxg2el50bj+UdnpV0
zlhM0qCbTdgMWwRdlcW3+IJ/eErcx+iU1LyoxH4CvGb98r74YhlWdsz9OFWiCRk=
=YZ1G
-END PGP SIGNATURE-
___
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] error creating QGIS package with creatensis

[Blumentrath, Stefan]

Hi,

I just checked the repository, and it looks like Jürgen updated the package 
already yesterday. So the problem is probably located somewhere else than in 
the path settings if the problem still occures.

It is furthermore probably worth adding the some info to the OSGeo4W-packaging 
instructions (so they are more specific about how to tar packages), if Unix 
path delimiters are required for OSGeo4W (which is not quite obvious I think).

Cheers
Stefan



-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 2. juli 2014 10:12
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] error creating QGIS package with creatensis

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 02/07/2014 09:55, matteo ha scritto:
> Hi Jürgen,
> I didn't understand if the problem is fixed now or if I have to do 
> something.
> I have updated the repository right now but I'm facing the same error.

you can run NSIS on Windows, in the meantime, waiting for the paths to be fixed.
All the best.
- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlOzvtwACgkQ/NedwLUzIr4EhwCfcGfYRcUQI8vme19uZ/LBf6FV
4fgAn3S8p5kctL+rX/USmyF/tZYs8l0Y
=RuLO
-END PGP SIGNATURE-
___
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] SOSI support in QGIS

[Blumentrath, Stefan]

Hi Etienne,

Thanks for having a look at this issue too.

The thing is that GDAL (or more precise OGR) opens SOSI files properly but QGIS 
from OSGeo4W does not (this issue does not occur on Mac and Linux).
In QGIS the contained layers (points, lines, polygons) can be identified (we 
get the dialog to choose a layer), so also QGIS can access the SOSI file in 
principle. But these layers themselves are rejected as “Invalid data source” 
(tested with different SOSI files). OGR converts all layers from the file QGIS 
rejects e.g. to SQLite correctly.

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SOSI support in QGIS

[Blumentrath, Stefan]

Hi Larry,

Thanks for your efforts. I understand that you are especially busy right now…

I checked GDAL_DRIVER_PATH  and it was - just as you suspected for OSGeo4W – 
set properly to “C:\OSGeo4W\bin\gdalplugins”.
Just like in James case, SOSI is listed in the combo-box in QGIS and I get the 
dialog for selecting among the three layers in the file. When I try to load one 
of them I get the “Invalid data source” error message.

GDAL in the same OSGeo4W installation reads and converts the SOSI file without 
any issues. However, I noticed that GDAL was also less picky with the versions. 
While the SOSI plugin compiled against GDAL 1.10 does not show up in QGIS 2.3 
(build against GDAL 1.11), GDAL 1.11 itself has no problems with that plugin 
either.

Maybe some subtle differences in compiler settings between Jürgens build of 
GDAL and my build of the SOSI-plugin may cause the problems here? I assume you 
use same compiler for GDAL and QGIS on Mac (like I do on Ubuntu)…
When I built the SOSI plugin I tried to follow packaging instructions closely. 
I used MS Visual Studio Express 2010 (compiler toolset v100) for the 32bit 
build (SDK 7.1 for the 64bit build), set MSVC_VER=1600 in GDALs nmake.opt, 
added SOSI support and kept default settings in the other cases.

Cheers
Stefan



From: la...@shafferinteractive.com [mailto:la...@shafferinteractive.com] On 
Behalf Of Larry Shaffer
Sent: 27. juni 2014 13:02
To: Blumentrath, Stefan
Cc: Stott, James; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] SOSI support in QGIS

Hi,
Hmm. I had no issues opening that file up on Mac [0]. The only other thing I 
can think of is to ensure the GDAL_DRIVER_PATH is set in the environment, so 
the plugins can be found at run-time by QGIS/GDAL. I don't think that should be 
an issue for an OSGeo4W install, though. To be sure, you can try setting it in 
Options -> System -> Environment and see if that helps.
If the plugin wasn't found by GDAL, then the file filter for SOSI would not 
show up in QGIS's file browse dialog's combobox for opening a vector layer. If 
you choose *.* (all files) and try to load a .sos file, then it will throw the 
invalid source error in the message bar, because GDAL never loaded the plugin.

Sorry, won't have time to test on any other platforms for a couple of days.

[0] http://drive.dakotacarto.com/qgis/sosi-file-load.png
Regards,

Larry

On Fri, Jun 27, 2014 at 3:50 AM, Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>> wrote:
Hi Larry,

Tanks for having a look at this.

I shall send you the file off-list…

Cheers
Stefan


From: la...@shafferinteractive.com<mailto:la...@shafferinteractive.com> 
[mailto:la...@shafferinteractive.com<mailto:la...@shafferinteractive.com>] On 
Behalf Of Larry Shaffer
Sent: 27. juni 2014 11:37
To: Blumentrath, Stefan
Cc: Stott, James; 
qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Subject: Re: [Qgis-developer] SOSI support in QGIS

Hi James,
Can you share the dataset from Miljødirektoratet that you are testing? I can't 
get Google to translate the pages to English.

Regards,

Larry

On Fri, Jun 27, 2014 at 2:43 AM, Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>> wrote:
>So it Works for Mac and Linux users?
Yes, seems to work there.

>Does this work with the installer download of QGIS for Windows? I havent 
>actually tried that.
I doubt it, since the installer is also built based on OSGeo4W, if I am not 
mistaken.

>Is it possible to drop it for just Windows users?
No idea. Any developer / packager who would be willing to help us tracing down 
the problem on Win? Since a fix would be the best solution...

>I just think we will end up with a lot of users (especially as Windows will 
>possbily be the most used platform) who will get frustrated that they cant 
>open these files despite it looking like they should be able to. Better to 
>wait until 2.6 in my opinion.
>This is a shame as we now have a nearly complete Norwegian translation in 
>place for 2.4, so SOSI support and a translation are two very good arguements 
>for adopting QGIS here.
I see your point...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto: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] SOSI support in QGIS

[Blumentrath, Stefan]

Hi Larry,

Tanks for having a look at this.

I shall send you the file off-list…

Cheers
Stefan


From: la...@shafferinteractive.com [mailto:la...@shafferinteractive.com] On 
Behalf Of Larry Shaffer
Sent: 27. juni 2014 11:37
To: Blumentrath, Stefan
Cc: Stott, James; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] SOSI support in QGIS

Hi James,
Can you share the dataset from Miljødirektoratet that you are testing? I can't 
get Google to translate the pages to English.

Regards,

Larry

On Fri, Jun 27, 2014 at 2:43 AM, Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>> wrote:
>So it Works for Mac and Linux users?
Yes, seems to work there.

>Does this work with the installer download of QGIS for Windows? I havent 
>actually tried that.
I doubt it, since the installer is also built based on OSGeo4W, if I am not 
mistaken.

>Is it possible to drop it for just Windows users?
No idea. Any developer / packager who would be willing to help us tracing down 
the problem on Win? Since a fix would be the best solution...

>I just think we will end up with a lot of users (especially as Windows will 
>possbily be the most used platform) who will get frustrated that they cant 
>open these files despite it looking like they should be able to. Better to 
>wait until 2.6 in my opinion.
>This is a shame as we now have a nearly complete Norwegian translation in 
>place for 2.4, so SOSI support and a translation are two very good arguements 
>for adopting QGIS here.
I see your point...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto: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] SOSI support in QGIS

[Blumentrath, Stefan]

>So it Works for Mac and Linux users?
Yes, seems to work there.

>Does this work with the installer download of QGIS for Windows? I havent 
>actually tried that.
I doubt it, since the installer is also built based on OSGeo4W, if I am not 
mistaken.

>Is it possible to drop it for just Windows users?
No idea. Any developer / packager who would be willing to help us tracing down 
the problem on Win? Since a fix would be the best solution...

>I just think we will end up with a lot of users (especially as Windows will 
>possbily be the most used platform) who will get frustrated that they cant 
>open these files despite it looking like they should be able to. Better to 
>wait until 2.6 in my opinion.
>This is a shame as we now have a nearly complete Norwegian translation in 
>place for 2.4, so SOSI support and a translation are two very good arguements 
>for adopting QGIS here.
I see your point...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SOSI support in QGIS

[Blumentrath, Stefan]

Hi James,

-Original Message-
From: Stott, James 

>I still do not get the option for SOSI files in 32 bit QGIS in the files of 
>type drop down menu in the open file dialog window. The SOSI option is 
>avaiable in 64 bit.
That is because the gdal-sosi plugin in 32bit OSGeo4W was built against GDAL 
1.10 (and not the 1.11 version QGIS 2.3 / 2.4 is (will be) using. I shall 
update the package based on GDAL 1.11 asap.


>The 64 bit version still gives the invalid data source error after trying to 
>open the SOSI file.
>The SOSI file I have tested with is the naturvernområde dataset from 
>Miljødirektoratet (I have downloaded only data for Rogaland fylke - data 
>available from >here http://karteksport.miljodirektoratet.no/#page=tab1). 
>ogrinfo reports correctly on both 32 and 64 bit versions and ogr2ogr will 
>convert sosi files to shapefiles in my test. 

I can confirm the behavior you describe on Windows (both 32 and 64bit). Given 
that GDAL (using the gdal-sosi plugin from OSGeo4W) handles SOSI files without 
problems, the issue must be somewhere in the QGIS-GDAL interface. No idea what 
the reason might be...

Meanwhile I also tested on Ubuntu 12.04 LTS (where I compiled GDAL 1.11 with 
SOSI support and then the latest QGIS master). On Ubuntu I can open SOSI files 
in QGIS without any problems... So this is a Windows specific issue, which 
makes me think that dropping the option to open SOSI from QGIS completely would 
be a bit too radical...

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SOSI support in QGIS

[Blumentrath, Stefan]

Hi again,

Now I rebuilt the 32-bit package based on GDAL 1.11.0 which is the GDAL version 
QGIS is build against (the old package on OSGeo4W was built against GDAL 1.10) 
and tested in QGIS 2.3 (QGIS code revision  39eaff9).
The problem is now the same, James described for the 64bit version. However, 
ogrinfo gives no error messages and displays the content of the SOSI file and 
all layers just fine. So maybe it is not only a packaging issue?

James, what does your 64bit ogrinfo say when run with your SOSI file? And does 
ogr2ogr work for you in 64bit?

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Stott, James
Sent: 26. juni 2014 11:14
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] SOSI support in QGIS

Hi all,

Just wondered if anything more has happened with this?

As it stands, I get an option for SOSI files in the file open dialog of 64 bit 
master, but not 32 bit. (SOSI is the data standard in Norway for those that 
don't know).

In 64 bit, when I select a file for opening, it comes up with another dialog 
(similar to when you open up a gpx file) where you choose the geometry you want 
to load from the file. After I have selected what I want and push ok, I just 
get an error message saying that the data is not a valid data source.

This happens on both mine and a colleagues machine. Does this affect others too?

I have also installed the gdal-sosi package in osgeo4w. I am using Windows 7 64 
Bit, osgeo4w for install. Current QGIS version is d4b07a.

If SOSI files do not open in QGIS, we should remove the option from the open 
file dialog window. Otherwise I think people here in Norway will have a bad 
experience with QGIS and SOSI.

Regards,

James Stott
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SOSI support in QGIS

[Blumentrath, Stefan]

Hi James,

and sorry for not having answered your earlier email on that issue.

On Windows I can reproduce your issue too. However, given that it worked on 
Mac, I suspect this is a packaging problem...
In other words my fault. I shall try to fix it with an update of the gdal-sosi 
package asap.
Yet, the Norwegian mapping authority mentioned that a 64bit build of the 
OpenFYBA library would be very much experimental... So no success guaranteed.
If we do not get it workin,g we would probably have to remove the gdal-sosi 
package (until it works properly).

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GDAL 1.11 new formats

[Blumentrath, Stefan]

Hi Larry,

I tried now with QGIS 2.3 nightly build (2.3.0-81) in OSGeo4W.
When I try to open a SOSI file in QGIS I still get the “Invalid Source” error 
message.
The gdal-sosi-plugin package in OSGeo4W is built against GDAL 1.10. Can that be 
a problem? Will I have to rebuild the plugin against GDAL 1.11 in order to make 
it accessible for QGIS (ogrinfo --format lists SOSI).
Or is the solution to install OSGeo4W from scratch?

Any other ideas?

Cheers
Stefan

From: la...@shafferinteractive.com [mailto:la...@shafferinteractive.com] On 
Behalf Of Larry Shaffer
Sent: 14. mai 2014 02:56
To: Stott, James
Cc: Blumentrath, Stefan; Jeff McKenna; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

Hi,

On Thu, May 8, 2014 at 12:03 AM, Stott, James 
mailto:fmro...@fylkesmannen.no>> wrote:
I second Stefan's comments. Having direct SOSI support will really strengthen 
the position of QGIS here in Norway.

We do a lot of work with SOSI, and it would be great to open (and eventually 
edit) SOSI files directly rather than having to convert them first.

I added an extension filter for SOSI to QGIS master [0].

Also, for Mac, I added Homebrew formulae for the OpenFYBA lib (fyba) [1] and a 
GDAL/OGR shared plugin (gdal-sosi) [2]. The SOSI support was recently added to 
the base GDAL formula (gdal) [3], so recompiling it after installation of fyba 
will also work, e.g.:
$ brew tap osgeo/osgeo4mac
$ brew update
Then...

$ brew upgrade gdal   <-- this will install 1.11.0 'bottle,' if not already done
$ brew install fyba
$ brew install gdal-sosi  <-- installs ogr_SOSI.dylib plugin in 
HOMEBREW_PREFIX/lib/gdalplugins/

Or...
$ brew install fyba
$ brew reinstall gdal --build-from-source --enable-unsupported
QGIS built against GDAL/OGR 1.11 with the sample .sos file loaded [4].
Please submit any issues with fyba or gdal-sosi formulae to OSGeo4Mac tracker 
[5].

[0] https://github.com/qgis/QGIS/commit/9804d17
[1] https://github.com/OSGeo/homebrew-osgeo4mac/commit/c93a2cf
[2] https://github.com/OSGeo/homebrew-osgeo4mac/commit/0db85d8
[3] 
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/gdal.rb#L187
[4] http://trac.osgeo.org/gdal/wiki/SOSI#TestingtheSOSIdriver ,
 http://drive.dakotacarto.com/qgis/sosi.png
[5] https://github.com/OSGeo/homebrew-osgeo4mac/issues

Regards,
Larry


James

-Opprinnelig melding-
Fra: 
qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>
 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 På vegne av Blumentrath, Stefan
Sendt: 7. mai 2014 23:36
Til: Jeff McKenna; 
qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Emne: Re: [Qgis-developer] GDAL 1.11 new formats

Yes, though I have to admit that I have no experience with building GDAL with 
SOSI support on Mac, but I know that the underling OpenFYBA lib has been 
successfully build on Mac, so I assume the Unix build hints should apply for 
Mac also  for GDAL/OGR.

Probably I should note, that the free map data of the Norwegian Mapping 
Authority (http://data.kartverket.no/download/) also come in SOSI format 
(vector)...

Cheers
Stefan

-Original Message-
From: 
qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>
 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 On Behalf Of Jeff McKenna
Sent: 7. mai 2014 22:56
To: qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

On 2014-05-07, 5:31 PM, Blumentrath, Stefan wrote:
> The Norwegian SOSI format (Vector) is also "new" - or more precise
> improved - in terms of build process in GDAL 1.11.
>
>
>
> On windows, it is now supported as a GDAL plugin and available in
> OSGeo4W. On Linux / Mac it still has to be built from source with an
> external library dependency (https://github.com/kartverket/fyba).
>
> SOSI is a bit peculiar, but it is the format of the official map data
> in Norway, used by public authorities.  The driver says it is
> Read/Write but writing is not fully implemented (yet).
>
>
>
> It would be splendid to be able to open SOSI files directly in QGIS
> (see also http://hub.qgis.org/issues/3708) and also write it once the
> public mapping authority fully implements the driver...
>

Hello Stefan,

That is very interesting.  Are all of your notes included on the GDAL 
Buildhints page, for Windows and Linux/Mac?
http://trac.osgeo.org/gdal/wiki/SOSI

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services http://www.gatewaygeomatics.com/



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-de

Re: [Qgis-developer] GDAL 1.11 new formats

[Blumentrath, Stefan]

Hi Larry,

That is great news! Many, many thanks!
I shall test immediately (on Windows) and report back in case of issues!

Cheers
Stefan

From: la...@shafferinteractive.com [mailto:la...@shafferinteractive.com] On 
Behalf Of Larry Shaffer
Sent: 14. mai 2014 02:56
To: Stott, James
Cc: Blumentrath, Stefan; Jeff McKenna; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

Hi,

On Thu, May 8, 2014 at 12:03 AM, Stott, James 
mailto:fmro...@fylkesmannen.no>> wrote:
I second Stefan's comments. Having direct SOSI support will really strengthen 
the position of QGIS here in Norway.

We do a lot of work with SOSI, and it would be great to open (and eventually 
edit) SOSI files directly rather than having to convert them first.

I added an extension filter for SOSI to QGIS master [0].

Also, for Mac, I added Homebrew formulae for the OpenFYBA lib (fyba) [1] and a 
GDAL/OGR shared plugin (gdal-sosi) [2]. The SOSI support was recently added to 
the base GDAL formula (gdal) [3], so recompiling it after installation of fyba 
will also work, e.g.:
$ brew tap osgeo/osgeo4mac
$ brew update
Then...

$ brew upgrade gdal   <-- this will install 1.11.0 'bottle,' if not already done
$ brew install fyba
$ brew install gdal-sosi  <-- installs ogr_SOSI.dylib plugin in 
HOMEBREW_PREFIX/lib/gdalplugins/

Or...
$ brew install fyba
$ brew reinstall gdal --build-from-source --enable-unsupported
QGIS built against GDAL/OGR 1.11 with the sample .sos file loaded [4].
Please submit any issues with fyba or gdal-sosi formulae to OSGeo4Mac tracker 
[5].

[0] https://github.com/qgis/QGIS/commit/9804d17
[1] https://github.com/OSGeo/homebrew-osgeo4mac/commit/c93a2cf
[2] https://github.com/OSGeo/homebrew-osgeo4mac/commit/0db85d8
[3] 
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/gdal.rb#L187
[4] http://trac.osgeo.org/gdal/wiki/SOSI#TestingtheSOSIdriver ,
 http://drive.dakotacarto.com/qgis/sosi.png
[5] https://github.com/OSGeo/homebrew-osgeo4mac/issues

Regards,
Larry


James

-Opprinnelig melding-
Fra: 
qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>
 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 På vegne av Blumentrath, Stefan
Sendt: 7. mai 2014 23:36
Til: Jeff McKenna; 
qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Emne: Re: [Qgis-developer] GDAL 1.11 new formats

Yes, though I have to admit that I have no experience with building GDAL with 
SOSI support on Mac, but I know that the underling OpenFYBA lib has been 
successfully build on Mac, so I assume the Unix build hints should apply for 
Mac also  for GDAL/OGR.

Probably I should note, that the free map data of the Norwegian Mapping 
Authority (http://data.kartverket.no/download/) also come in SOSI format 
(vector)...

Cheers
Stefan

-Original Message-
From: 
qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>
 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 On Behalf Of Jeff McKenna
Sent: 7. mai 2014 22:56
To: qgis-developer@lists.osgeo.org<mailto:qgis-developer@lists.osgeo.org>
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

On 2014-05-07, 5:31 PM, Blumentrath, Stefan wrote:
> The Norwegian SOSI format (Vector) is also "new" - or more precise
> improved - in terms of build process in GDAL 1.11.
>
>
>
> On windows, it is now supported as a GDAL plugin and available in
> OSGeo4W. On Linux / Mac it still has to be built from source with an
> external library dependency (https://github.com/kartverket/fyba).
>
> SOSI is a bit peculiar, but it is the format of the official map data
> in Norway, used by public authorities.  The driver says it is
> Read/Write but writing is not fully implemented (yet).
>
>
>
> It would be splendid to be able to open SOSI files directly in QGIS
> (see also http://hub.qgis.org/issues/3708) and also write it once the
> public mapping authority fully implements the driver...
>

Hello Stefan,

That is very interesting.  Are all of your notes included on the GDAL 
Buildhints page, for Windows and Linux/Mac?
http://trac.osgeo.org/gdal/wiki/SOSI

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services http://www.gatewaygeomatics.com/



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org<mailto:Qgis-

Re: [Qgis-developer] GDAL 1.11 new formats

[Blumentrath, Stefan]

Yes, though I have to admit that I have no experience with building GDAL with 
SOSI support on Mac, but I know that the underling OpenFYBA lib has been 
successfully build on Mac, so I assume the Unix build hints should apply for 
Mac also  for GDAL/OGR.

Probably I should note, that the free map data of the Norwegian Mapping 
Authority (http://data.kartverket.no/download/) also come in SOSI format 
(vector)... 

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Jeff McKenna
Sent: 7. mai 2014 22:56
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

On 2014-05-07, 5:31 PM, Blumentrath, Stefan wrote:
> The Norwegian SOSI format (Vector) is also "new" - or more precise 
> improved - in terms of build process in GDAL 1.11.
> 
>  
> 
> On windows, it is now supported as a GDAL plugin and available in 
> OSGeo4W. On Linux / Mac it still has to be built from source with an 
> external library dependency (https://github.com/kartverket/fyba).
> 
> SOSI is a bit peculiar, but it is the format of the official map data 
> in Norway, used by public authorities.  The driver says it is 
> Read/Write but writing is not fully implemented (yet).
> 
>  
> 
> It would be splendid to be able to open SOSI files directly in QGIS 
> (see also http://hub.qgis.org/issues/3708) and also write it once the 
> public mapping authority fully implements the driver...
> 

Hello Stefan,

That is very interesting.  Are all of your notes included on the GDAL 
Buildhints page, for Windows and Linux/Mac?
http://trac.osgeo.org/gdal/wiki/SOSI

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services http://www.gatewaygeomatics.com/



___
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] GDAL 1.11 new formats

[Blumentrath, Stefan]

The Norwegian SOSI format (Vector) is also “new” - or more precise improved - 
in terms of build process in GDAL 1.11.

On windows, it is now supported as a GDAL plugin and available in OSGeo4W. On 
Linux / Mac it still has to be built from source with an external library 
dependency (https://github.com/kartverket/fyba).
SOSI is a bit peculiar, but it is the format of the official map data in 
Norway, used by public authorities.  The driver says it is Read/Write but 
writing is not fully implemented (yet).

It would be splendid to be able to open SOSI files directly in QGIS (see also 
http://hub.qgis.org/issues/3708) and also write it once the public mapping 
authority fully implements the driver…

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Etienne Tourigny
Sent: 7. mai 2014 21:42
To: Even Rouault
Cc: qgis-developer
Subject: Re: [Qgis-developer] GDAL 1.11 new formats

There is also one new raster format (KRO).

To whoever adds support for these, it would be nice to test that they it works 
in file open dialogs as well as the browser dock and app.  Should work 
automatically once the ogr and gdal drivers are updated.

Looks like there is no support for  network-based gdal/ogr drivers in the 
browser -  that would be nice to have. It could take the form of a new 
top-level item, and a "New connection" dialog similar to the one used in the 
"new vector" database widget.

Etienne

On Wed, May 7, 2014 at 4:21 PM, Even Rouault 
mailto:even.roua...@mines-paris.org>> wrote:
Le mercredi 07 mai 2014 20:51:53, Larry Shaffer a écrit :
> Hi,
>
> GDAL/OGR 1.11 offers several new OGR formats [0] that need support added in
> QGIS's source. I have added the OpenFileGDB format (because it was simple
> to do) [1], but don't have enough experience with the other database
> formats to add their support.
>
> * CartoDB : read/write support
--> Not file based, but remote database. Should be dealt like others
myDatabaseDrivers cases

> * GME (Google Map Engine) : read/write support
--> Remote database too.

> * GPKG (GeoPackage): read-write support (vector part of the spec.)
--> File-based (similar to CSV) Extension is .gpkg

> * SXF: read-only support

--> File-based. Extension is SXF

> * WALK : read-only support

--> Similar to PGEO. It is a MDB database

> * WAsP .map : read-write support
--> File-based. Extension is .map

>
> Would anyone be willing to help add support for those? Looks like in
> addition to qgsogrprovider.cpp's createFilters( QString type ) that
> QgsVectorFileWriter::initMetaData() also needs updated.
>
> IMO, it would be good to then backport these to release-2.2 branch as well,
> so current users may benefit from the new formats. I could add my commit,
> but seems like it would be better to add full GDAL/OGR 1.11 support at once
> to that branch, excepting some formats if they will need more extensive
> support added first.
>
> [0] http://trac.osgeo.org/gdal/wiki/Release/1.11.0-News
> [1] https://github.com/qgis/QGIS/commit/a096cf4
>
> Regards,
>
> Larry
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
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

[Qgis-developer] Problems with Garmin Custom Map plugin on Mac

[Blumentrath, Stefan]

Dear devs,

For the Garmin Custom Map plugin 
(http://plugins.qgis.org/plugins/GarminCustomMap/) I got repeatedly bug reports 
from Mac users, by email in addition to bug tracer: 
http://hub.qgis.org/issues/9276.
E.g. on OSX 10.8.5 one user reported:

"This plugin is broken
numpy.core.multiarray failed to import"

Yet import of numpy, is not part of the plugin code itself, so I suspect 
problems located in some underlying components on Mac (plugin uses e.g. GDALs 
python API)

I do not know of problems on LINUX or Windows. Unfortunately, I have no Mac 
available, so I cannot investigate myself. Anyone with Mac experience who is 
willing to help?

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Problems building branch 2.2 on Ubuntu 12.04

[Blumentrath, Stefan]

Hi,

I am trying to build QGIS from source on Ubuntu 12.04 LTS because I have a 
custom GDAL and GRASS installation, and I want to build QGIS against those.

I downloaded the code yesterday evening from https://github.com/qgis/QGIS.git 
(branch release-2_2).
It configures fine using ccmake, but on "make" I get the following error 
message (at ca. 20%):
src/providers/ogr/qgsogrgeometrysimplifier.cpp:255:69: error: âOGR_G_SetPointsâ 
was not declared in this scope

Any hints? Thanks for helping.

Cheers
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Luciene
Sent: 2. april 2014 20:51
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Ranking GSoC proposals

Hi,
Sorry for the late response, but I am out of the office today and tomorrow.
The idea of the plugin is to develop some functions for schematization.
Suchith and Mark Ware have a previous research and they established some 
constraints that we can use as a starting point. Also the work of Piotr is 
important since he developed a line simplification algorithm.
We (Piort and I) were in contact with the student during the application 
process and he seems very interest.
regards
Luciene



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Ranking-GSoC-proposals-tp5132433p5132709.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [GRASS-dev] GRASS & QGIS: the future

[Blumentrath, Stefan]

That sounds very reasonable to me.

Proper GDAL/OGR handling for GRASS 7 would be very nice in any case (see 
http://trac.osgeo.org/gdal/ticket/2953).

As for a "GRASS data browser", I think, a plugin would be required with regards 
to user friendliness, because one needs to know what files to access from a 
GRASS data base when using GDAL.

I also understand that at some point in time one will have to use GRASS 
directly in order to access full functionality (e.g. ortho-rectification, nviz, 
mapswipe, animation and stuff), which makes the way Moritz suggests maybe even 
more reasonable...

Cheers
Stefan
 



-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: 27. mars 2014 13:36
To: Blumentrath, Stefan
Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

I'm not much of a QGIS-as-GRASS-frontend user, either, but from a general point 
of view I also think that duplication is a problem and that the current way to 
go in QGIS is the processing framework. So;

On 27/03/14 12:49, Blumentrath, Stefan wrote:
> I understand well the point; however, the plugin has additional functions, 
> e.g.:
> * a grass shell

couldn't this be implemented within the processing environment ?

> * a grass data browser

If we are talking about accessing GRASS data for loading into QGIS, wouldn't it 
be a better idea to improve the GDAL/OGR handling in order to be able to load 
GRASS data just like any other data format ?

> * a grass digitizing environment.

Maybe this could be split out into a specific plugin ?

Moritz
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS & QGIS: the future

[Blumentrath, Stefan]

Dear all,

>From my user perspective (I am using both GRASS and QGIS, or the other way 
>around, depends on topic), processing is not really a replacement for the 
>GRASS plugin.
It is handy and probably better for those who do not use GRASS but are 
interested in single functions / modules.

Yet, once you have a GRASS database with a considerable amount of data, the 
GRASS plugin is very valuable for accessing those data in QGIS (e.g. for 
cartography). Also users with no or little GRASS experience benefit from the 
GRASS plugin in cases where they have access to a GRASS database.
That way they can work on it without acquainting themselves with a "new" GIS in 
depth...

Concluding, if you have the possibility to maintain it, keep the GRASS plugin 
in QGIS!

Cheers
Stefan




-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini
Sent: 27. mars 2014 12:41
To: Nathan Woodrow
Cc: qgis-developer; grass-dev
Subject: Re: [Qgis-developer] GRASS & QGIS: the future

Il 27/03/2014 12:33, Nathan Woodrow ha scritto:
> I would vote for dropping the plugin and just updating the processing 
> plugin.  Having both ways is bad for us and bad for users, even worse 
> when some functions are missing from one but not in the other.

I understand well the point; however, the plugin has additional functions, e.g.:
* a grass shell
* a grass data browser
* a grass digitizing environment.
Whether these are important or not, it's a matter of users.
All the best.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
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] Backport necessary fixes to release-2_2 branch?

[Blumentrath, Stefan]

Hi Giovanni,

Thanks for that one. I did not know about the GPX-bug. Would have been 
expensive to discover that bug first during field work...
So, I second Giovanni`s wish. Otherwise going back to 2.0 would be the only 
alternative...

Cheers
Stefan 

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Giovanni Manghi
Sent: 10. mars 2014 21:16
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Backport necessary fixes to release-2_2 branch?

>2. Backport necessary fixes to release-2_2 branch? (Larry Shaffer)

I would really like to ask if it possible consider a point release in the next 
weeks, we have a nasty regression that was not spotted before the release (kml 
and gpx attributes tables are empty), one that was already fixed in master (the 
identify and feature form that show at the same time)  and unresolved issues 
when computing areas and perimeters when otrf in on.

cheers!
___
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] Common QGIS Plugin configuration accross multiple Linux users

[Blumentrath, Stefan]

Hi Richard,

A platform independent solution would be an elegant solution.

What we do (on Windows) is having a folder on a server containing QGIS default 
settings (e.g. reg-files for DB-connections, Connections for web services, but 
also, most popular plugins, map and print composer templates). These default 
settings can be imported by the users by executing a simple batch-script we 
produced for that purpose. If that is of interest for somebody I could post the 
content of the .bat file...

>From that starting point, colleagues can adjust the default settings to their 
>personal needs and preferences...

Cheers
Stefan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Richard 
Duivenvoorde
Sent: 9. mars 2014 20:28
To: Tim Sutton; Zoltan Szecsei
Cc: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Common QGIS Plugin configuration accross multiple 
Linux users


> ~/.qgis2
> and
> ~/.config/QGIS
> 
> You could e.g. rsync the user plugin dirs from a central one, or put 
> them in an nfs mount (read only might have issues as plugins try to 
> write .pyc files or even write data to the plugin dir).
> 
> The ~/.config/QGIS/QGIS2.conf is a standard ini style config file so 
> you should be able to pick through it and awk/sed/bash your way to 
> nirvana :-)

I'm actually thinking about to make this OS independent, by creating a 'save 
QSettings' as file option. Then with a command line option you would be able to 
(just before reading the QSettings) actually read/write this settings file back 
into user settings. Thereby making it possible to for example transfer a 
certain setup across a class room (as long as the plugins are available in 
.qgis2 off cours).

Would this work? Or do I miss something?

Regards,

Richard Duivenvoorde



___
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] QGIS MetaSearch Catalogue Client 0.1.0 released

[Blumentrath, Stefan]

Hi Tom,

I see you started collecting Meta Data Catalogues (at least on national scale) 
for the default services in the plugin.

I like the idea very much. What about asking (QGIS) users explicitly to provide 
addresses for their countries? Such a collection would be really valuable 
(especially for people working across borders) and maybe also of interest for 
other projects as there are already comparable initiatives on collecting 
information on available data:
http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group
http://grasswiki.osgeo.org/wiki/Global_datasets

What do you think?

Cheers,
Stefan
 

-Original Message-
From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis
Sent: 19. februar 2014 13:00
To: Blumentrath, Stefan
Cc: qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released


Hi Stefan: thanks for the info.  This is the dreaded metadata "link types" 
issue.

If possible, can you open an issue on this so we can discuss this in the ticket?

Thanks

..Tom

On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:

> Date: Wed, 19 Feb 2014 11:54:04 +0000
> From: "Blumentrath, Stefan" 
> To: Tom Kralidis 
> Cc: "qgis-developer@lists.osgeo.org" 
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
> 
> Done.
>
> BTW, the problem that I could not add WMS / WFS is likely to be on the CSW 
> side and not the client side, cause it worked for some WMS...
>
> I was using the CSW for "official" map data in Norway provided by geonorge:
> http://www.geonorge.no/geonetwork/srv/no/csw?
>
> There are several / many WMS listed which cannot be added... Would you mind 
> double checking if this is a server-side problem?
>
> Cheers
> Stefan
>
> -Original Message-
> From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom 
> Kralidis
> Sent: 19. februar 2014 12:32
> To: Blumentrath, Stefan
> Cc: qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
>
>
> Hi Stefan: thanks for the info/kind words.  Yes, can you file a ticket at 
> https://github.com/geopython/MetaSearch/issues/new with the steps taken, so 
> we can reproduce and fix the issue.
>
> Thanks
>
> ..Tom
>
>
> On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:
>
>> Date: Wed, 19 Feb 2014 08:06:59 +
>> From: "Blumentrath, Stefan" 
>> To: Tom Kralidis ,
>> "qgis-developer@lists.osgeo.org" 
>> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
>> released
>>
>> Hi Tom,
>>
>> Thank you (and your team) very much for this excellent plugin! Very valuable!
>>
>> I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already.
>>
>> Adding WMS/WCS/WFS however does not seem to be active yet, and using the 
>> "back" arrows throws an error:
>> Traceback (most recent call last):
>>  File 
>> "C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py", 
>> line 572, in navigate
>>if res == QMessageBox.Ok:
>> UnboundLocalError: local variable 'res' referenced before assignment
>>
>> Should I file a ticket?
>>
>> Still the plugin is already very useful and personally I think it should 
>> make it to QGIS core in the long run!
>>
>> So, thanks again,
>> Stefan
>>
>> -Original Message-
>> From: qgis-developer-boun...@lists.osgeo.org
>> [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom 
>> Kralidis
>> Sent: 18. februar 2014 21:16
>> To: qgis-developer@lists.osgeo.org
>> Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
>> released
>>
>>
>> The MetaSearch team announces the release of MetaSearch 0.1.0.
>>
>> The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, 
>> with significant features to enable plug and play interoperability with OGC 
>> CSW services.
>>
>> - find and bind functionality allowing users to discover and add 
>> layers from WMS, WFS, WCS, or WMTS services dynamically to the map
>> - template-based service and record metadata view, allowing for 
>> custom templating of responses
>> - visual footprint of CSW results
>> - display of all metadata access links, allowing users to 
>> click/download data to add to QGIS
>> - spatial and aspatial querying of CSW services
>>
>> Version 0.1.0 represents a significant engineering effort to bring CSW 
>> support for QGIS 2, make the codebase sustainable/extensible and easy for 
>> d

Re: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released

[Blumentrath, Stefan]

Done.

BTW, the problem that I could not add WMS / WFS is likely to be on the CSW side 
and not the client side, cause it worked for some WMS...

I was using the CSW for "official" map data in Norway provided by geonorge:
http://www.geonorge.no/geonetwork/srv/no/csw?

There are several / many WMS listed which cannot be added... Would you mind 
double checking if this is a server-side problem?

Cheers
Stefan

-Original Message-
From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis
Sent: 19. februar 2014 12:32
To: Blumentrath, Stefan
Cc: qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released


Hi Stefan: thanks for the info/kind words.  Yes, can you file a ticket at 
https://github.com/geopython/MetaSearch/issues/new with the steps taken, so we 
can reproduce and fix the issue.

Thanks

..Tom


On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:

> Date: Wed, 19 Feb 2014 08:06:59 +0000
> From: "Blumentrath, Stefan" 
> To: Tom Kralidis ,
> "qgis-developer@lists.osgeo.org" 
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
> 
> Hi Tom,
>
> Thank you (and your team) very much for this excellent plugin! Very valuable!
>
> I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already.
>
> Adding WMS/WCS/WFS however does not seem to be active yet, and using the 
> "back" arrows throws an error:
> Traceback (most recent call last):
>  File 
> "C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py", 
> line 572, in navigate
>if res == QMessageBox.Ok:
> UnboundLocalError: local variable 'res' referenced before assignment
>
> Should I file a ticket?
>
> Still the plugin is already very useful and personally I think it should make 
> it to QGIS core in the long run!
>
> So, thanks again,
> Stefan
>
> -Original Message-
> From: qgis-developer-boun...@lists.osgeo.org 
> [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom 
> Kralidis
> Sent: 18. februar 2014 21:16
> To: qgis-developer@lists.osgeo.org
> Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
>
>
> The MetaSearch team announces the release of MetaSearch 0.1.0.
>
> The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, with 
> significant features to enable plug and play interoperability with OGC CSW 
> services.
>
> - find and bind functionality allowing users to discover and add 
> layers from WMS, WFS, WCS, or WMTS services dynamically to the map
> - template-based service and record metadata view, allowing for custom 
> templating of responses
> - visual footprint of CSW results
> - display of all metadata access links, allowing users to 
> click/download data to add to QGIS
> - spatial and aspatial querying of CSW services
>
> Version 0.1.0 represents a significant engineering effort to bring CSW 
> support for QGIS 2, make the codebase sustainable/extensible and easy for 
> developers and documentation teams to make contributions.  Longer term plans 
> include:
>
> - supporting other catalog APIs (CKAN, etc.)
> - making MetaSearch part of QGIS core
> - transifex localization
> - display thumbnail/browse images
>
> We are looking for feedback and testers for the plugin.  Comments, bugs, 
> features/enhancements are welcome (IRC, GitHub issue tracker, etc.).
>
> The full list of enhancements and bug fixes is available at 
> https://github.com/geopython/MetaSearch/issues?milestone=1&page=1&stat
> e=closed
>
> The plugin is available from the QGIS Plugins Repository at 
> http://plugins.qgis.org/plugins/MetaSearch
>
> Testers and developers are welcome.
>
> The MetaSearch team.
>
> http://geopython.github.io/MetaSearch
> ___
> 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] QGIS MetaSearch Catalogue Client 0.1.0 released

[Blumentrath, Stefan]

Hi Tom,

Thank you (and your team) very much for this excellent plugin! Very valuable!

I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already.

Adding WMS/WCS/WFS however does not seem to be active yet, and using the "back" 
arrows throws an error:
Traceback (most recent call last):
  File 
"C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py", line 
572, in navigate
if res == QMessageBox.Ok:
UnboundLocalError: local variable 'res' referenced before assignment

Should I file a ticket?

Still the plugin is already very useful and personally I think it should make 
it to QGIS core in the long run!

So, thanks again,
Stefan

-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom Kralidis
Sent: 18. februar 2014 21:16
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released


The MetaSearch team announces the release of MetaSearch 0.1.0.

The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, with 
significant features to enable plug and play interoperability with OGC CSW 
services.

- find and bind functionality allowing users to discover and add layers from 
WMS, WFS, WCS, or WMTS services dynamically to the map
- template-based service and record metadata view, allowing for custom 
templating of responses
- visual footprint of CSW results
- display of all metadata access links, allowing users to click/download data 
to add to QGIS
- spatial and aspatial querying of CSW services

Version 0.1.0 represents a significant engineering effort to bring CSW support 
for QGIS 2, make the codebase sustainable/extensible and easy for developers 
and documentation teams to make contributions.  Longer term plans include:

- supporting other catalog APIs (CKAN, etc.)
- making MetaSearch part of QGIS core
- transifex localization
- display thumbnail/browse images

We are looking for feedback and testers for the plugin.  Comments, bugs, 
features/enhancements are welcome (IRC, GitHub issue tracker, etc.).

The full list of enhancements and bug fixes is available at 
https://github.com/geopython/MetaSearch/issues?milestone=1&page=1&state=closed

The plugin is available from the QGIS Plugins Repository at 
http://plugins.qgis.org/plugins/MetaSearch

Testers and developers are welcome.

The MetaSearch team.

http://geopython.github.io/MetaSearch
___
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] qgis 2.2: removing spit and disabling "avoid intersection of new polygons"

[Blumentrath, Stefan]

Hi,

Regarding the "avoid intersection" problem: I agree with Giovanni, that this is 
one of the (or maybe even the major) strength of digitising functionality in 
QGIS, making it the probably most userfriendly and efficient GIS for digitising 
available.

>From my point of view proper digitising is a very important GIS feature for 
>"basic" (and potential new QGIS) users. So, the topology imprecision is 
>definitely a reasonable disadvantage in this regards, and personally I would 
>give a high priority to fixing this.

However, I would not deactivate "avoid intersection" (but maybe make users 
aware of this issue (e.g. by adding a hint in the UI-lable)). Because, the 
(possibly) incorrect topology (with very small errors) can in many cases be 
fixed e.g. using GRASS`s v.clean through processing. I know that this is not 
elegant, but better than not havind this option at all...

Cheers
Stefan


Von: qgis-developer-boun...@lists.osgeo.org 
[qgis-developer-boun...@lists.osgeo.org]" im Auftrag von "Paolo 
Cavallini [cavall...@faunalia.it]
Gesendet: Samstag, 25. Januar 2014 09:22
An: qgis-developer@lists.osgeo.org
Betreff: Re: [Qgis-developer] qgis 2.2: removing spit and disabling "avoid 
intersection of new polygons"

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 24/01/2014 18:30, Giovanni Manghi ha scritto:

> a while ago I proposed to get rid of SPIT as it is unmaintained and
> now redundant with a similar tool in the processing toolbox. This will
> happen for 2.2?

+1. I think this will solve also some long standing ticket.

> More serious is the issue with the "avoid intersection" option in the
> snapping dialog:
>
> the functionality is broken as it often does not remove all the
> overlapped parts, leaving behind (very) small areas and creating
> multipart polygons when it is supposed to not happen.
>
> There have been some discussion (and even a fix funding proposal) but
> afaik no work has been done.
>
> As this tool does not work as advertised and creates a lot of issues
> when digitizing maps than need to be topologically correct, then I
> propose to disable it until fixed (and this is a pity, as is one of
> the most powerful options in qgis regarding dizigiting).
>
> What is your opinion?

we still have several bugfixing weeks left, and some resources to fix them.
It would be useful to agree on a prioritization.

Thanks.

- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlLjdFwACgkQ/NedwLUzIr5PVwCbBAJRywDBaD2a1Mr1qc5Yyctk
mYMAnicdM5I291N6unb9xApjan51WriL
=iJXK
-END PGP SIGNATURE-
___
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] [Qgis-user] GarminCustomMap-plugin version update to 1.0

[Blumentrath, Stefan]

Hi

Good to hear that the plugin is of use.
I am not sure if I understood what you want to achieve.
In general it should be possible to remove the lower limit of the zoom-factor.
However, zooming out and then exporting the Garmin Custom Map / KMZ would give 
the same result.

Btw, the zoom-factor does not affect the possibility to zoom on your Garmin 
unit.

Or did you mean something else?

Cheers
Stefan


From: Harish [mailto:harry.om2...@gmail.com]
Sent: 6. desember 2013 14:21
To: Blumentrath, Stefan
Cc: rich...@duif.net; qgis-developer@lists.osgeo.org; qgis-u...@lists.osgeo.org
Subject: Re: [Qgis-user] GarminCustomMap-plugin version update to 1.0

Great plugin! thanks!
Can the Zoom factor be less than 1.0 so that the map can be viewed on lesser 
scales also?
Regards
Harish
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] GarminCustomMap-plugin version update to 1.0

[Blumentrath, Stefan]

Hi again

I just reversioned the GarminCustomMap plugin to 1.0, removed the experimental 
flag and uploaded the new version to the repository.
If somebody with approval rights would be so kind to approve...
It should now work properly with QGIS 2.0.
In case of issues: the plugin has a bugtracker 
(http://hub.qgis.org/projects/garmincustommap/issues)...

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Please approve GarminCustomMap-plugin version 0.100

[Blumentrath, Stefan]

Hi again

And Thanks for approving and the hint with the version number.

I was not aware that the loogics change from 0.99 to 0.100.
I shall keep that in mind for the future...

I thought I make it 1.0 (and non experimental) when people out there confirm 
the plugin works properly on their (probably different systems)...

Cheers
Stefan

-Original Message-
From: Richard Duivenvoorde [mailto:rdmaili...@duif.net] 
Sent: 26. november 2013 22:58
To: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Please approve GarminCustomMap-plugin version 
0.100

On 26-11-13 22:16, Blumentrath, Stefan wrote:
> Hi
> 
> It would be great if someone with approval rights could approve the latest 
> version (0.100) of the GarminCustomMap plugin.
> The earlier version did not geo-reference the jpgs properly in the kml/kmz, 
> in other words: output from version 0.99 will be useless...

Hi Stefan,

just did. BUT first could not find it, while it is sorted on version number in 
the list.

it is because you went from 0.99 to 0.100 == 0.1 So in normal versioning scheme 
you DOWNgraded your plugin.
So also for the pluginmanager I think your latest version is 0.99

Please version this version as either 0.991 or 0.99.1 or so if you really want 
to stay away from the magic one :-)

Regards,

Richard Duivenvoorde

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Please approve GarminCustomMap-plugin version 0.100

[Blumentrath, Stefan]

Hi

It would be great if someone with approval rights could approve the latest 
version (0.100) of the GarminCustomMap plugin.
The earlier version did not geo-reference the jpgs properly in the kml/kmz, in 
other words: output from version 0.99 will be useless...

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Multi threading and background processing

[Blumentrath, Stefan]

Hi Tom

Besides the technical aspects, just in case you do not know them yet, you may 
probably get some scientific inspirations from e.g. r.los (and related modules) 
in GRASS (see http://grass.osgeo.org/grass64/manuals/r.ros.html) which 
represent existing GIS models for wildfire spread. Maybe something to build 
on...?

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GarminCustomMap-plugin updated for QGIS 2.0

[Blumentrath, Stefan]

Hi again

Version 0.99 did not georeference images correctly.
Should be fixed in new version (0.100) which I uploaded a couple of minutes ago.
Furthermore, the new version has an improved dialog (fewer clicks).

Feedback very welcome...

Cheers
Stefan

-Original Message-
From: Richard Duivenvoorde [mailto:rdmaili...@duif.net] 
Sent: 16. november 2013 09:20
To: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] GarminCustomMap-plugin updated for QGIS 2.0

On 15-11-13 23:41, Blumentrath, Stefan wrote:
> Hi
> Finally, I managed to update the GarminCustomMap plugin for QGIS 2. The 
> updated version is experimental and feedback would be very much appreciated.
> Cheers
> Stefan

Hi Stefan,

just approved the plugin.

Can you please make some docs more visible for new users. As in the 
metadata.txt or so. (I finally found some when I actually started it in step 
2...). It would be nice if potential users also could see what possibilities 
there are. And for me personally: which kind of garmins can handle this custom 
maps (as I have two older types lying around somewhere :-) ).

This link in the info page:
http://www.garminonline.de/karten/outdoor/custommaps/ is a dead link.

Thanks for your work!

Regards,

Richard Duivenvoorde

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GarminCustomMap-plugin updated for QGIS 2.0

[Blumentrath, Stefan]

Hi Richard

I shall add more documentation to the next (then hopefully stable) version. 

However I am not sure where that would be most suitable...
For the time being, I think an "about-dialog" (like e.g. in MergeShapes) would 
be best.

I do like the idea to include a more comprehensive description in the 
metadata.txt very much, but it would be too much text for the bold letters the 
text from the description-entry has in the plugin installer. Here I noticed 
quite different usage among plugin-devs. Compare for example, "MultiEdit" and 
"New Memory Layer".

For adding more documentation in the metadata.txt it would be really nice to 
have a "short_description" and a "long_description" which can be shown in bold 
or normal type in the excellent new plugin-installer...

Best regards
Stefan 


Von: Richard Duivenvoorde [rdmaili...@duif.net]
Gesendet: Samstag, 16. November 2013 09:19
An: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Betreff: Re: [Qgis-developer] GarminCustomMap-plugin updated for QGIS 2.0

On 15-11-13 23:41, Blumentrath, Stefan wrote:
> Hi
> Finally, I managed to update the GarminCustomMap plugin for QGIS 2. The 
> updated version is experimental and feedback would be very much appreciated.
> Cheers
> Stefan

Hi Stefan,

just approved the plugin.

Can you please make some docs more visible for new users. As in the
metadata.txt or so. (I finally found some when I actually started it in
step 2...). It would be nice if potential users also could see what
possibilities there are. And for me personally: which kind of garmins
can handle this custom maps (as I have two older types lying around
somewhere :-) ).

This link in the info page:
http://www.garminonline.de/karten/outdoor/custommaps/ is a dead link.

Thanks for your work!

Regards,

Richard Duivenvoorde

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] GarminCustomMap-plugin updated for QGIS 2.0

[Blumentrath, Stefan]

Hi
Finally, I managed to update the GarminCustomMap plugin for QGIS 2. The updated 
version is experimental and feedback would be very much appreciated.
Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Bug with avoid intersection - willing to fund fix

[Blumentrath, Stefan]

Hi Andreas

Of course I fully understand your point about the need for financing, and 
hopefully George`s offer will change things for topological correct editing.

However, there could be several reasons for a lack of funding until now:
Probably, many users are not really aware of the bug(s)? Back in 1.7.4 editing 
was no longer possible once invalid geometries were produced by "Avoid 
intersection" and users got an error message. Nowadays, you can continue 
digitizing without noticing that geometries are not topologically correct. The 
result looks good and you have to actively search (or check) for such 
digitization errors. I guess, not everybody does that, so I assume also a lack 
of awareness could be a reason for the lack of funding...

Furthermore, some users who are aware may prefer such (of course not too 
convenient) workarounds over trying to raise some money for funding a proper 
fix.
And finally, as it is unfortunately the case for me - for example -, even if I 
am seriously affected by the bug it is really very difficult (for not to say 
impossible) to raise a reasonable amount of money to get this (or another bugs) 
fixed, because:
In my Institute ArcGIS is the "Standard" GIS application, and I am one of few 
"nerds" (that is at least how I feel I am sometimes being looked at) who use 
OSGeo products. I was and am actively promoting (amongst other OSGeo 
applications) QGIS in my institute because I am convinced that QGIS is in many 
cases much more suitable for our purposes than ArcGIS. One very important 
activity is mapping (and digitizing) habitat types for public authorities, who 
request data with proper topology.
So, the topology problems are definitely an obstacle regarding promoting QGIS 
here. And since my bosses already paid for ArcGIS licenses (which does not have 
these problems) and a wider introduction of QGIS will also cause some extra 
transaction costs (e.g. learning) in short term, the consequence is that my 
institute will stick to ArcGIS. This makes it extremely difficult to convince 
my bosses to donate some money for bug fixing, even though QGIS offers (from my 
point of view) superior solutions for our problems and we will benefit from 
using QGIS in the long run... It is a bit of a witches circle in a way, and the 
only alternative would be to use private money...

Cheers
Stefan


-Original Message-
From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Andreas Neumann
Sent: 14. november 2013 10:54
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Bug with avoid intersection - willing to fund fix

Hi,

So if there is so much interest in having this issue fixed I assume that there 
would be plenty out there who would fund the fix!

The fix won't happen if noone pays for it - just complaining about this does 
not help.

Get an estimate from some developer (e.g. Sandro Santilli oder
Sourcepole) to know how much it would cost to fix.

As much as I like GRASS - and it is very good to know that this workaround 
exists (thanks Stefan for mentioning it!) - I don't think it is reasonable to 
ask people to go through GRASS to get proper data out of their QGIS digitized 
data set.

Who will take the lead to ask a developer?

Andreas

Am 14.11.2013 10:40, schrieb Blumentrath, Stefan:
> Hi George
> 
> I had a lot of trouble with those issues too, and I would really love to see 
> them fixed. In other words, I agree with Giovanni that these are pretty 
> important bugs for many and not really uncommon digitization use-cases and 
> would support his categorization as blocker...
> 
> However, my current workaround is to ignore the untidiness in the topology at 
> first and then send the vector dataset through GRASS which is (at least for 
> not too big datasets) quite convenient using the Sextante/Processing 
> framework (see also discussion here):
> http://osgeo-org.1560.x6.nabble.com/Running-v-clean-on-a-QGIS-vector-l
> ayer-Polygon-through-Sextante-td5050418.html
> 
> Cheers
> Stefan
> 
> 
> 
> ___
> 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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Bug with avoid intersection - willing to fund fix

[Blumentrath, Stefan]

Hi George

I had a lot of trouble with those issues too, and I would really love to see 
them fixed. In other words, I agree with Giovanni that these are pretty 
important bugs for many and not really uncommon digitization use-cases and 
would support his categorization as blocker...

However, my current workaround is to ignore the untidiness in the topology at 
first and then send the vector dataset through GRASS which is (at least for not 
too big datasets) quite convenient using the Sextante/Processing framework (see 
also discussion here):
http://osgeo-org.1560.x6.nabble.com/Running-v-clean-on-a-QGIS-vector-layer-Polygon-through-Sextante-td5050418.html

Cheers
Stefan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How to get project's CRS in Python

[Blumentrath, Stefan]

Hi

canvas = self.iface.mapCanvas()
mapRenderer = canvas.mapRenderer()
srs=mapRenderer.destinationCrs()

Then for example
str(srs.authid())
would return for a project in WGS84:
‘EPSG:4326’

Cheers
Stefan

From: qgis-developer-boun...@lists.osgeo.org 
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Ricardo Filipe 
Soares Garcia da
Sent: 29. mai 2013 12:02
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] How to get project's CRS in Python

Hi list
How could I extract the current project's CRS from python?
I've tried looking for it in QSettings but came up short. Mybe somewhere in 
QgsProject? I can't figure out how to use the readListEntry() method though.
Thanks

--
___ ___ __
Ricardo Garcia Silva
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer