Re: [QGIS-Developer] QGIS 3D and Graphics Card Requirements

[Bernd Vogelgesang via QGIS-Developer]

Hi,

my 2 cents from a 3D-interested (not yet experienced) user:
1. doing GIS-stuff on a notebook, no matter how performant it is, for me
is a PITA.
Clumsy keyboards, overpriced hardware. GIS-work without a large or 2
screens is useless -> so whats the point of a mobile computer then?

2. Had a 10 year old mid-range gaming computer so far (i7 4770k, 16GGB
RAM, 2GB Graphics card).
For any usage in 2D this was still more than sufficient.
Native QGIS 3D crashed.
Sniffed a bit into Blender, which had much better performance, but the
workflow to use it efficiently with real world data is still unclear to me.

3. As my pockets are full, I am in the process to order a NVIDIA RTX
4090 and will be reporting back about the finding.

4. What I would wish for the 3D-future of QGIS: Somehow wire into the
Blender 3D capabilities.
Usecase: For planning processes of construction (Windmills, solar farms,
Buildings, bridges etc.):
(Semi-)realistic landscapes based on geodata and aerial images, but
pimped up with 3D-model bushes, trees etc based on semi-automatic
classification of aerial images and underlying geodata.

Seeing such processes in "reality" will bring much better understand for
planners, authorities, population etc. than the best crafted 2D maps
ever will.

Cheers,
Bernd

Am 15.10.23 um 13:08 schrieb Martin Dobias via QGIS-Developer:

Hi Hannes


__

the two ridiculously expensive and high-end graphics cards mentioned
by Luke sound like complete overkill. Surely reading and preparing
the geodata for 3D display (from data providers, via storage, on the
CPU?) would be the bigger performance/usability issue of the 3D
views, right? I am sure that for reasonable reasons QGIS would choke
wy earlier than what those cards would be capable of. The
potential benefit of those cards for QGIS 3D definitely is not worth
paying *1200-2500€* extra.

I have not had a chance to try QGIS 3D with such high-end cards yet, but
you're right, users would be probably hitting performance issues
elsewhere when working with large amounts of data (but this also depends
on data types, formats, styling etc.)

Martin/Jean, is there any change that you could provide a more
detailed specification of the hardware and software requirements for
QGIS 3D? It comes up again and again and I've just been searching
again without success. I step up to add it to the QGIS documentation
in early November.

Okay, great, let me try... there are very few firm requirements for QGIS
3D, so it's hard to answer some of the questions exactly.

Esri provides for example infos on the required OpenGL version and
extensions on

https://pro.arcgis.com/en/pro-app/latest/get-started/arcgis-pro-system-requirements.htm
 


E.g.: What is the minimum amount of GPU RAM necessary? How does it
scale with more complex 3D scenes and what happens if there is not
enough RAM?

There's no strict minimum really, but I would say 1 GB GPU memory should
be enough for many use cases. When dealing with large amounts of 3D data
- e.g. point clouds or tiled scenes (3D tiles), it won't hurt to have
more memory, although with default settings QGIS probably would not go
over 2 GB GPU memory usage. All layers use tiling, so with increased
distance of 3D data from camera, there's less detail displayed, which
limits GPU memory usage and GPU processing power needed.

Each map layer gets up 500 MB GPU memory, but only few that are memory
intense (like point clouds or tiled scene) would normally use all of it.
When a map layer gets to the limit, it will unload data (that are
currently not being displayed) from GPU memory to get under the 500 MB
limit. In the QGIS release 3.34 it will be possible to configure the
per-layer limit (and QGIS 3D views will show a warning if the limit has
been reached and none of the tiles can be unloaded).

Does it get slow (maybe with a message) or does it crash?

Any slowness should be caused by displaying too many triangles/points in
the 3D view (or possibly there could be something in QGIS code that runs
on CPU that is slow and affecting 3D performance for example when the 3D
scene is getting updated as the camera moves, scheduling loads of tiles).

To be honest I don't really know what happens if there's not enough GPU
memory - in theory there could be crashes, or the scene would be just
missing some data - or maybe something else, like freeze. It is worth
trying - it may depend on the operating system and the graphical drivers
as well.

Which renderer does it use on which platforms (I guess always
OpenGL?). Which OpenGL version is needed?

Yes it is always using OpenGL. Our 3D window requests OpenGL 4.3 core
profile. Shaders of materials that we use only need OpenGL 3.2 or 3.3.

I am not 100% sure how things are on Windows and macOS. Apparently,
Windows by default only provides very 

Re: [QGIS-Developer] Lazy question about using views in GeoPackages

[Bernd Vogelgesang via QGIS-Developer]

Hi,

no first-hand experiences myself, but a friend once tried to do those
views with Geopackage.
Coming from views with Spatialite, it felt like a pita for him, so he
reverted to Spatialite and can not recommend a Geopackage approach.
So, seems you will indeed have to reinvent the wheel.

Cheers,
Bernd

Am 26.05.23 um 12:52 schrieb Bo Victor Thomsen via QGIS-Developer:

Hi list -

Recently, I've begun experimenting with creating spatial view's of
base-tables inside GeoPackages. A Geopackage is basically a SQLite file
containing  spatial data- and meta-tables with specific structures of
information about the spatial tables.

So it's possible to create a permanent view of a table (or tables) in
the GeoPackage by making a functioning SQL select statement and
prefixing it with "CREATE VIEW /view_name/ AS .. /the select statement/
.. (This is database 101 knowledge)

However, if you want to expose those views as "read-only" tables/layers
for "non-sql-using" QGIS users  you have to update several meta-tables
in the GeoPackage: /gpkg_contents/, /gpkg_geometry_columns/ and maybe
/gpkg_ogr_contents/.

I'm brainstorming with myself about making some kind of automated
updating of the meta-tables with information about the views created.
Maybe some python code and maybe creating triggers for the base table to
handle data changes regarding the extend of the data.

And now (at last !!) my question: I haven't been able to find very much
information about this subject using Google or StackExchange. So.. Is
there some existing code / plugin / information so I don't have to
"reinvent the wheel" ?


--
Med venlig hilsen / Best regards

Bo Victor Thomsen


___
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-psc] QGIS budget 2023 RFC

[Bernd Vogelgesang via QGIS-Developer]

sneaking in from the ouside ...

Hey guys and girls,

you are providing the world (including million-$€-companies) with an
awesome "product" with a budget worth maybe 50 ESRI-licenses!!!

There has to be a way to grab those big players by the balls! THEN such
discussions about payment rates would start to make sens.

Maybe investing some money in marketing psychologists who can help
developing a campaign for that? Obviously different abilities apart from
software development are needed for this.

Just my two micro-cents
Bernd



Am 24.11.22 um 16:09 schrieb Andreas Neumann via QGIS-Developer:

Hi Vincent,

Thank you for joining the discussion.

We did not really discuss the hourly rates at the budget meeting. From
2021 to 2022 we raised the hourly dev rates from 100 to 110 - and the
hourly documentation rates from 40 to 44. I know that both rates are
low. We can discuss raising them again.

The plan for the two positions was not to have direct employees of
QGIS.ORG , but to use a proxy company, in our case
Kartoza, to act as the employer. Also - our budget does not allow
regular European or North-American salaries. With these limitations at
hand, we can use Kartoza as a proxy to hire employees in certain parts
of the world where the salaries we can offer can be attractive - and
where they have talented people to work on some of our issues
(sysadmin, documentation, etc.)

For the documentation part: Tim and Harrissou are involved in the
selection process of the candidates.

I agree that the grant budget with 10k is not very attractive. We also
discussed skipping it for one year. Not sure what is better ...

BTW: you can all help to find new sustaining members ... that would
increase our budget and would allow us to pay better hourly rates ...

I wish we had a larger budget at hand than the +/- 200k € we seem to
be able to attract each year. From certain countries where we know we
have a lot of QGIS users (France, Italy - just to name two of them)
there are not a lot of sustaining members or donations other than from
a few private persons and very small companies. Maybe companies like
yours could help us to get in touch with the larger companies with a
lot of QGIS users that could become new sustaining members ... Do you
think that would be possible?

Andreas

On Thu, 24 Nov 2022 at 15:05, Vincent Picavet (ml) via QGIS-Developer
 wrote:

Hello,

Thanks for sharing the budget with the community.

A few questions / remarks :
- in most countries, we can see a general inflation, having
consequences on every kind of costs ( hosting, salaries…). Did you
take this context into account when preparing the budget,
especially when basing planned 2023 costs on actual 2022 costs ?
- the cut on Grant budget is really hard. With a "reasonable" mean
budget of 5K per grant, this would mean 2 grants only this year.
It sounds more or less like the end of the grant program. Who
would candidate if chances to be selected are really low ?
Wouldn't there be a way to mitigate it a bit, through various
smaller budget reductions to other budget lines ? The increase in
documentation contribution is huge compared to the grant decrease.
I fear that we loose grants as a mean to attract new core developers.

My most important remark is about "allow for a regular small
salary .. for one person on each item". Disclaimer : I am quite
strongly against QGIS.org having employees. If we are in the
process of having "regular workers" for qgis.org
, then we really have to work hard on :
- having a clear, written and transparent process for how to
select these people
- .. process including a fair way for anyone to candidate
I may have missed some communications, but I have not seen this in
place up to now. This is definitely something we have to put in
place before having some internal troubles.

Best regards,
Vincent

On 24/11/2022 12:07, Marco Bernasocchi wrote:
> Hi all, we prepared the QGIS budget for 2023 and would like to have
> feedback before submitting it to the voting members for
approval. You
> can directly leave comments in the file [1].
>
> Please let us have any Feedback until December 4th. On december 7th
> we'll send the budget for vote.
>
> Cheers Marco
>
> [1]
>

https://docs.google.com/spreadsheets/d/1WyoZCKOehNhU5YB4pFPOuiJbie1mUmMPiq8YW7qyez0/edit?usp=sharing
>


>
>  -- Marco Bernasocchi
>
> QGIS.org Chair OPENGIS.ch CEO http://berna.io 
>
> ___ Qgis-psc mailing
> list qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

___
QGIS-Developer mailing list
 

Re: [QGIS-Developer] [Qgis-user] 3.20.1 fails on Linux Mint

[Bernd Vogelgesang]

On 21.07.21 16:37, Fernando M. Roxo da Motta wrote:

On Wed, 21 Jul 2021 07:02:37 -0600, Richard Greenwood
 wrote:



I just upgraded from 3.20.0 to 3.20.1 on Linux Mint 20.1. Qgis doesn't
start, or more accurately, I don't get a GUI interface. I can see the
qgis.bin process running and using 100% of one core, so I guess it's
hung. I uninstalled, reinstalled, rebooted, same result. Suggestions?



   I have just upgraded Qgis in my Ubuntu 20.04.2 LTS and got the same
result, no GUI.

   There are many messages like:

(qgis.bin:62147): Gtk-WARNING **: 11:17:36.524: Theme parsing error:
gtk.css:28:35: Junk at end of value for background-color

or

(qgis.bin:62147): Gtk-WARNING **: 11:17:36.546: Theme parsing error:
gtk-widgets-assets.css:108:32: The style property
GtkWidget:separator-width is deprecated and shouldn't be used anymore.
It will be removed in a future version

But I think that is not the problem here.

   I am still struggling trying to get some clue.




   Roxo


Thanks for the warnings!

I forward it to the developer list.

Cheers,

Bernd

___
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] Filter by expression in Report(s)

[Bernd Vogelgesang]

Hi Matteo,

there is already a "whishlist" from Nyall concerning Reports:

** Reports **
- Expression based filters for sections
- Expression based custom sort order for field groups
- Relation based sections (repeat section for all related features)
- Support “aggregated” geometries for headers/footers in sections
- Support for non-full page repeating sections
- Support for "expanding" content (.e.g label items which grow to fit
the available text, causing the section's size to vary
feature-by-feature) (this one continues on from the previous point)
- Reorder report sections via drag and drop
- Add user-defined notes to sections describing the logic (not
included in the outputs, only visible while designing the report)
- Copy/paste groups and sections between different reports (or for
duplicating within the same report)

(from conversation on september 16 on qgis-user) and this query on
github:
https://github.com/qgis/QGIS/issues?q=is%3Aopen+is%3Aissue+label%3AReports

Have not checked yet if there was already progress on this.

Cheers,

Bernd



On 03.03.21 17:16, matteo wrote:

Hi devs,

I think this is a feature request, but I'm unsure. In the Report
Layout when adding a layer in a "Field Group Sections" within another
"Field Group Sections", the layers must have a field in common that is
used to filter the features.

If not, one can use the "join attributes by location" or create a
virtual field with an aggregate expression.

Is there any interest to add a Expression Combobox instead of a Field
Combobox in the Report Layout to filter the features "live"?

Or is there a simpler way I'm missing? :)

Cheers and thanks

Matteo
___
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] Processing: sort algorithm not working?

[Bernd Vogelgesang]

Hi Andreas,

have a look at my last years issue on this

https://github.com/qgis/QGIS/issues/29794

maybe it's the same

Cheers,

Bernd

On 19.11.20 14:16, Andreas Neumann wrote:

Hi,

I have a model where at the very end before adding it to the project I was
trying to sort the result with an expression.

But: the sorting doesn't work. In the help there is the cryptic hint at
https://docs.qgis.org/3.10/de/docs/user_manual/processing_algs/qgis/vectorgeneral.html#qgisorderbyexpression
that "Be careful, it might not work as expected with some providers, the
order might not be kept every time."

Does someone know more about it? Which providers specifically do not
support sorting?

Does this statement apply to the reading provider or the writing provider?

In my case, I never got any correct sorting ...

Thanks,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)


___
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, DateTime and TimeZones

[Bernd Vogelgesang]

I recently had some issues concerning datetimes.
Like in real life, I had to merge data from different sources, csv and
gpx, with some duplicate entries.
After a while I wondered why I couldn't find those duplicates. For some
reasons, the time values where interpreted differently while merging,
depending on the source and formatting, so I got an offset of 2 hours
for values which should have been identical.

So there seems to be some black magic going on under the hood which I
can't influence when I would not want to change all entries by hand to
make them behave consistently.

Just my 2 cents

Bernd



On 08.09.20 15:40, Richard Duivenvoorde wrote:

Hi Devs,

I was hitting some timezone issues when I received some csv data in which there 
are timestamps like:
"2020-07-25 20:21:38 UTC"
Apparently if you read this into QGIS, the UTC IS interpreted, and you get a 
DateTime in your data which is (in my case) -2 hours(CET) off (well in some 
parts of QGIS)

This plays havoc if you for example are going to use this data in the 
timecontroller or expressions, see
https://github.com/qgis/QGIS/issues/38647

So I think that now the TimeController is part of QGIS, and people will start 
to play with Time-based data more and more (from TimeZone aware datasets like 
csv and postgres) we will run into issues like above.

Is there something we can do to make QGIS timezone aware?
OR should we stay far away from it (timezones are hell)...
OR should we wait with it after QGIS 4

Regards,

Richard Duivenvoorde



___
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] Develop of o speak spanish

[Bernd Vogelgesang]

On 30.08.20 17:22, Jose Mercedes Venegas Acevedo wrote:

Buen dia

Alguien que pueda cotizarme el desarrollo de dos plugins
1.- Uno para el inicio de sesión en un servidor web para usar esos
datos en los orígenes de datos

2.- Un Plugin para soportar otros resultados además del número de
objetos en la capa así como la actualización de este valor en lugar de
mantenerse fijo a pesar de que ya cambio la BD en este caso lo
requerimos para Postgres

Alguien por aquí que entienda español que pueda cotizarme estos dos
plugins?

Saludos a todos

Good day

Someone who can quote me the development of two plugins
1.- One for logging into a web server to use that data in the data sources

2.- A Plugin to support other results besides the number of objects in
the layer as well as the update of this value instead of keeping it
fixed even though we already changed the DB in this case we require it
for Postgres

Anyone around here who understands Spanish who can quote me these two
plugins?

Greetings to all

Translated with www.DeepL.com/Translator (free version)
___
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] How to get animation_datetime()

[Bernd Vogelgesang]

Still not clear. Do you mean the timer running in the lower right?
If so, see https://www.youtube.com/watch?v=vgDg5cRwPRw starting at 54:40
for the formula



On 13.07.20 23:14, Andreas Neumann wrote:

By "current time of an animation" I mean the current time represented
in the time slider control as a function or variable.

Thanks,

Andreas

Am 13.07.20 um 23:08 schrieb Andreas Neumann:

Hi,

In an animation (QGIS 3.14) - how do I get the current time of an
animation?

In https://www.youtube.com/watch?v=8R0TQlhdc1U=youtu.be at
minute 6:26, it shows a formula involving the "animation_datetime()"
function.

But my expression editor complains, that this function is not available.

Thanks for your hints,

Andreas


___
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

___
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] plugin approval request

[Bernd Vogelgesang]

Just a general request to those request:

Would it be possible to "guide" plugin authors, when creating specific
plugins for specific countries, to maybe use their country code in the
repo name?
By this, it would maybe be much easier not to get confused, when one day
there are e.g. 180 open-data loaders around ;)

opendata_loader is a huge title for such a tiny potential audience (no
disrespect!)

opendata_loader_il vs. opendata_loader_us vs. opendata_loader_fr ...
would look much better to me than having dozens of differentiating
names, trying to describe the same function but with other words.

I do not mean this plugin specifically, cause it has at least "Israel"
in it's name on the plugin page. But with a lot others, you'll even have
to dig into the description to find out that it's of no use for you.
Or even add country code tags in the meta-data for filtering
country-specific plugin?

Just my two offtopic cents

Bernd

On 17.06.20 18:00, Richard Duivenvoorde wrote:

Hi,

This plugin author requested on a Telegram group channel to be approved:

https://plugins.qgis.org/plugins/opendata_loader/

I found the plugin but there was an error in the repo/issue metadata
(the author apparently renamed the repo), so created an issue now:

https://github.com/KaplanOpenSource/qgis-open-data/issues/2

Regards,

Richard Duivenvoorde

PS what about creating an email group for 'plugin-approvers'? If
somebody sents me all mail addresses I can create one group (if others
agree)
___
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] Linux users: wanna flatpak?

[Bernd Vogelgesang]

Really great!

Worked liked a charm.

Beginning to like Flatpak :)

So, more or less, sorry for the noise. The solution was right there, it
would have only taken to read it ;)

Cheers,

Bernd

On 28.05.20 14:22, Richard Duivenvoorde wrote:

On 5/28/20 2:18 PM, Bernd Vogelgesang wrote:

Wow,

thanx a lot!

Umh, just reading https://github.com/flathub/org.qgis.qgis
Seems I can just reinstall the flatpak with the needed module

|flatpak run --command=pip3 org.qgis.qgis install scipy --user Will give
it a try! Cheers, Bernd |

Ah, YES, that is it. Apparently without the --user it flatpak will try
to install it in the non-user space of it's environment.
So THAT works:

flatpak run --command=pip3 org.qgis.qgis install urllib3 --user

Then I was able to download "Distant measurement styles" successfully!

Thanks! Will add it to the docs

Regards,

Richard Duivenvoorde

___
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] Linux users: wanna flatpak?

[Bernd Vogelgesang]

Wow,

thanx a lot!

Umh, just reading https://github.com/flathub/org.qgis.qgis
Seems I can just reinstall the flatpak with the needed module

|flatpak run --command=pip3 org.qgis.qgis install scipy --user Will give
it a try! Cheers, Bernd |

On 28.05.20 14:12, Richard Duivenvoorde wrote:

FYI:

https://github.com/flathub/org.qgis.qgis/issues/59

As I reckon there are not too many flatpak users around here in qgis dev

Regards,

Richard Duivenvoorde

On 5/28/20 1:27 PM, Bernd Vogelgesang wrote:

On 28.05.20 12:48, Richard Duivenvoorde wrote:

Hi Bernd,

I do not know how to fix this, but I would create an issue at the
flatpak repo:

https://github.com/flathub/org.qgis.qgis/issues

They are rather responsive.
In here:
https://github.com/flathub/org.qgis.qgis/issues/28#issuecomment-587224383
It looks like you can run python (so pip?) command within your flatpak
environment (which is different then your default qgis profile
envirnoment).

If you find out, please report back so we can update the flatpak
instructions on the download page.

Regards,

Richard Duivenvoorde


Hi Richard,

actually, I do not intend to fumble myself deeper in this stuff, but
have the hope that some more enlightened people could give some more
detailed instructions how to proceed the before-mentioned workaround.
So, maybe 5 sentences on the matter might be better than only the one
given so far.

Cheers,

Bernd


On 5/28/20 12:22 PM, Bernd Vogelgesang wrote:

On 30.09.18 11:39, Daniele Viganò wrote:

Thanks Aleix and the other devs for the excellent work!

I confirm that it's working well, at least on my Fedora 28 and 29beta.

I had only issues with plugins that are requiring extra Python
dependencies which are not available in the flatpak image (like scipy
and matplotlib).
I was able to find a workaround which is to extract the corresponding
python wheels (for the proper python version, cp35) in the python
folder under the application user storage (which is located under
$HOME/.var/); that path is already part of sys.path.

There's any better way to address that?

Cheers,
Daniele


Sorry for digging up this old thread, but as after upgrading QGIS, my
normal install on Linux Mint is (again) gone, so a I fell back on the
flatpak version which I installed recently to try.

Now I luckily found this thread dealing with missing python modules in
flatpak.
I tried to install "Distant measurement styles" via the Resource Sharing
plugin.

This did not work, cause "urlib3" is missing.

Could someone elaborate more on that python wheels stuff and where to
install what (exactly) to add missing python dependencies to the
flatpak?
  From what I read, I only understood half and I would like to keep at
least one functional QGIS version.

Cheers,

Bernd





---
Daniele Viganò
http://daniele.vigano.me

On mobile, please excuse my brevity.

On Sat, Sep 29, 2018, 18:12 Richard Duivenvoorde mailto:rdmaili...@duif.net>> wrote:

  Hi,

  Thanks to some devs and Aleix Pol @aleixpol in particular,
there is a
  (for me working!) flatpak available for QGIS 3.2.x on flathub:

  https://flathub.org/apps/details/org.qgis.qgis

  Short intro:
  https://qgis.org/en/site/forusers/alldownloads.html#flatpak

  Try test and create issues here
  https://github.com/flathub/org.qgis.qgis
  if you encounter some flathub related issues..

  I think it is a nice addition for fresh Linux users to easily
install
  and try out QGIS, independent of lib/qt/gdal/whatever versions

  Regards,

  Richard Duivenvoorde
  ___
  QGIS-Developer mailing list
  QGIS-Developer@lists.osgeo.org
<mailto: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

___
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] Linux users: wanna flatpak?

[Bernd Vogelgesang]

On 28.05.20 12:48, Richard Duivenvoorde wrote:

Hi Bernd,

I do not know how to fix this, but I would create an issue at the
flatpak repo:

https://github.com/flathub/org.qgis.qgis/issues

They are rather responsive.
In here:
https://github.com/flathub/org.qgis.qgis/issues/28#issuecomment-587224383
It looks like you can run python (so pip?) command within your flatpak
environment (which is different then your default qgis profile envirnoment).

If you find out, please report back so we can update the flatpak
instructions on the download page.

Regards,

Richard Duivenvoorde


Hi Richard,

actually, I do not intend to fumble myself deeper in this stuff, but
have the hope that some more enlightened people could give some more
detailed instructions how to proceed the before-mentioned workaround.
So, maybe 5 sentences on the matter might be better than only the one
given so far.

Cheers,

Bernd



On 5/28/20 12:22 PM, Bernd Vogelgesang wrote:

On 30.09.18 11:39, Daniele Viganò wrote:

Thanks Aleix and the other devs for the excellent work!

I confirm that it's working well, at least on my Fedora 28 and 29beta.

I had only issues with plugins that are requiring extra Python
dependencies which are not available in the flatpak image (like scipy
and matplotlib).
I was able to find a workaround which is to extract the corresponding
python wheels (for the proper python version, cp35) in the python
folder under the application user storage (which is located under
$HOME/.var/); that path is already part of sys.path.

There's any better way to address that?

Cheers,
Daniele


Sorry for digging up this old thread, but as after upgrading QGIS, my
normal install on Linux Mint is (again) gone, so a I fell back on the
flatpak version which I installed recently to try.

Now I luckily found this thread dealing with missing python modules in
flatpak.
I tried to install "Distant measurement styles" via the Resource Sharing
plugin.

This did not work, cause "urlib3" is missing.

Could someone elaborate more on that python wheels stuff and where to
install what (exactly) to add missing python dependencies to the flatpak?
 From what I read, I only understood half and I would like to keep at
least one functional QGIS version.

Cheers,

Bernd





---
Daniele Viganò
http://daniele.vigano.me

On mobile, please excuse my brevity.

On Sat, Sep 29, 2018, 18:12 Richard Duivenvoorde mailto:rdmaili...@duif.net>> wrote:

 Hi,

 Thanks to some devs and Aleix Pol @aleixpol in particular, there is a
 (for me working!) flatpak available for QGIS 3.2.x on flathub:

 https://flathub.org/apps/details/org.qgis.qgis

 Short intro:
 https://qgis.org/en/site/forusers/alldownloads.html#flatpak

 Try test and create issues here
 https://github.com/flathub/org.qgis.qgis
 if you encounter some flathub related issues..

 I think it is a nice addition for fresh Linux users to easily install
 and try out QGIS, independent of lib/qt/gdal/whatever versions

 Regards,

 Richard Duivenvoorde
 ___
 QGIS-Developer mailing list
 QGIS-Developer@lists.osgeo.org <mailto: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

___
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] Linux users: wanna flatpak?

[Bernd Vogelgesang]

On 30.09.18 11:39, Daniele Viganò wrote:

Thanks Aleix and the other devs for the excellent work!

I confirm that it's working well, at least on my Fedora 28 and 29beta.

I had only issues with plugins that are requiring extra Python
dependencies which are not available in the flatpak image (like scipy
and matplotlib).
I was able to find a workaround which is to extract the corresponding
python wheels (for the proper python version, cp35) in the python
folder under the application user storage (which is located under
$HOME/.var/); that path is already part of sys.path.

There's any better way to address that?

Cheers,
Daniele


Sorry for digging up this old thread, but as after upgrading QGIS, my
normal install on Linux Mint is (again) gone, so a I fell back on the
flatpak version which I installed recently to try.

Now I luckily found this thread dealing with missing python modules in
flatpak.
I tried to install "Distant measurement styles" via the Resource Sharing
plugin.

This did not work, cause "urlib3" is missing.

Could someone elaborate more on that python wheels stuff and where to
install what (exactly) to add missing python dependencies to the flatpak?
From what I read, I only understood half and I would like to keep at
least one functional QGIS version.

Cheers,

Bernd





---
Daniele Viganò
http://daniele.vigano.me

On mobile, please excuse my brevity.

On Sat, Sep 29, 2018, 18:12 Richard Duivenvoorde mailto:rdmaili...@duif.net>> wrote:

Hi,

Thanks to some devs and Aleix Pol @aleixpol in particular, there is a
(for me working!) flatpak available for QGIS 3.2.x on flathub:

https://flathub.org/apps/details/org.qgis.qgis

Short intro:
https://qgis.org/en/site/forusers/alldownloads.html#flatpak

Try test and create issues here
https://github.com/flathub/org.qgis.qgis
if you encounter some flathub related issues..

I think it is a nice addition for fresh Linux users to easily install
and try out QGIS, independent of lib/qt/gdal/whatever versions

Regards,

Richard Duivenvoorde
___
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
___
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 packages build against ubuntugis-unstable dependencies

[Bernd Vogelgesang]

Hi,

the problem with ubuntugis and QGIS being out of sync is a frequent one.
I promised myself a dozen times not to update, but I also stepped into
this trap again.
Had to switch to normal ubuntu release.

See https://www.qgis.org/en/site/getinvolved/development/roadmap.html
for the next point release which should solve the issue.
This should have been today, but as far as I understood the threads on
the developers list, this will be postponed for a week or so to solve
other issues.

Cheers,
Bernd

Am 06.12.19 um 07:41 schrieb Ben Hur Pintor:

Hi all,

I install QGIS on my Ubuntu 18.04 machine with ubuntugis-unstable
dependencies. A few days ago, the ubuntugis-unstable repo updated it's
packages for Bionic (GDAL 3, PROJ 6, etc). After upgrading some libraries
from ubuntugis-unstable, QGIS disappeared from my machine. Other libraries
like qgis-common, etc were still there but qgis itself wasn't. I tried to
reinstall qgis but I always end up with missing/broken package error
(mostly with python-gdal). Looking at the recent update to
ubuntugis-unstable, it seems the python3-gdal lib (with GDAL 3) breaks
python-gdal < 2.5.

Am I correct in thinking that rebuilding QGIS against the
ubuntugis-unstable dependencies would solve this issue?

P.S. It's been a day since I last checked if I could reinstall QGIS with
ubuntugis-unstable dependencies so please disregard this message if it has
been resolved already.

Thanks!

Sincerely,
Ben Hur


___
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] v.net.centrality: Sorry, is not a valid parameter

[Bernd Vogelgesang]

According to https://gis.stackexchange.com/a/309445 this warning is
raised by default it seems.

So, no ideas where your problem comes from. Over here the function works
and produces a result.

Bernd

Am 31.10.19 um 09:57 schrieb magerlin:

Yes you need to chose an output type yourself, but nomatter what I choose I
get the same error message.

I am running on windows and no matter what Grass procedure I run I get this
warning:
WARNING: Concurrent mapset locking is not supported on Windows.
Do not know what it means or whether it is relevant in this case?


Error message from v.centrality.net:

QGIS version: 3.10.0-A Coruña
QGIS code revision: 6c816b4204
Qt version: 5.11.2
GDAL version: 2.4.1
GEOS version: 3.8.0-CAPI-1.13.1
PROJ version: Rel. 5.2.0, September 15th, 2018
Processing algorithm…
Algorithm 'v.net.centrality' starting…
Input parameters:
{ '-a' : True, '-g' : False, 'GRASS_MIN_AREA_PARAMETER' : 0.0001,
'GRASS_OUTPUT_TYPE_PARAMETER' : 0, 'GRASS_REGION_PARAMETER' : None,
'GRASS_SNAP_TOLERANCE_PARAMETER' : -1, 'GRASS_VECTOR_DSCO' : '',
'GRASS_VECTOR_EXPORT_NOCAT' : False, 'GRASS_VECTOR_LCO' : '',
'arc_backward_column' : None, 'arc_column' : None, 'betweenness' : '',
'cats' : '', 'closeness' : 'closeness', 'degree' : 'degree', 'eigenvector' :
'', 'error' : 0.1, 'input' : 'C:\\@Temp\\net.shp|layername=net',
'iterations' : 1000, 'node_column' : None, 'output' :
'C:/@Temp/central.shp', 'points' : 'C:\\@Temp\\Poi.shp|layername=Poi',
'threshold' : 50, 'where' : '' }

Attempting to use v.external for direct layer read
Attempting to use v.external for direct layer read
g.proj -c proj4="+proj=longlat +datum=WGS84 +no_defs"
v.external input="C:\@Temp\net.shp" layer="net"
output="vector_5dba985f06fbb16" --overwrite -o
v.external input="C:\@Temp\Poi.shp" layer="Poi"
output="vector_5dba985f09e9b17" --overwrite -o
g.region n=9.327649580604518 s=9.271627488192191 e=38.7617967871377
w=38.74138436843244
v.net -s input=vector_5dba985f06fbb16 points=vector_5dba985f09e9b17
output=net5dba985f0b22318 operation=connect threshold=50.0
v.db.connect -o map=net5dba985f0b22318 table=vector_5dba985f09e9b17 layer=2
v.net.centrality input=net5dba985f0b22318 degree="degree"
closeness="closeness" iterations=1000 error=0.1 -a
output=output94c0c01b65de4586878116ac9fa984ae --overwrite
v.out.ogr type="point" input="output94c0c01b65de4586878116ac9fa984ae"
output="C:/@Temp/central.shp" format="ESRI_Shapefile" layer=1 --overwrite
Cleaning up temporary files...
Starting GRASS GIS...
WARNING: Concurrent mapset locking is not supported on Windows
Executing

...
C:\Users\map\Documents>chcp 1252 1>NUL
C:\Users\map\Documents>g.proj -c proj4="+proj=longlat +datum=WGS84 +no_defs"
Default region was updated to the new projection, but if you have multiple
mapsets `g.region -d` should be run in each to update the region from the
default
Projection information updated
C:\Users\map\Documents>v.external input="C:\@Temp\net.shp" layer="net"
output="vector_5dba985f06fbb16" --overwrite -o
Over-riding projection check
Building topology for vector map ...
Using external data format 'ESRI Shapefile' (feature type 'linestring')
Registering primitives...
One primitive registered
43 vertices registered
v.external complete. Link to vector map  created.
C:\Users\map\Documents>v.external input="C:\@Temp\Poi.shp" layer="Poi"
output="vector_5dba985f09e9b17" --overwrite -o
Over-riding projection check
Building topology for vector map ...
Using external data format 'ESRI Shapefile' (feature type 'point')
Registering primitives...
334 primitives registered
334 vertices registered
v.external complete. Link to vector map  created.
C:\Users\map\Documents>g.region n=9.327649580604518 s=9.271627488192191
e=38.7617967871377 w=38.74138436843244
C:\Users\map\Documents>v.net -s input=vector_5dba985f06fbb16
points=vector_5dba985f09e9b17 output=net5dba985f0b22318 operation=connect
threshold=50.0
Copying features...
100
Building topology for vector map ...
Registering primitives...
Copying attributes...
WARNING: Unable to create index
WARNING: Unable to copy table  for layer 1 from
 to 
WARNING: Failed to copy attribute table to output map
Building topology for vector map ...
Registering primitives...
v.net complete. 9 lines (network arcs) written to output.
C:\Users\map\Documents>v.db.connect -o map=net5dba985f0b22318
table=vector_5dba985f09e9b17 layer=2
WARNING: Table  does not exist in database
<$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db>
The table  is now part of vector map
 and may be deleted or overwritten by GRASS modules
WARNING: Cannot create index
Select privileges were granted on the table
C:\Users\map\Documents>v.net.centrality input=net5dba985f0b22318
degree="degree" closeness="closeness" iterations=1000 error=0.1 -a
output=output94c0c01b65de4586878116ac9fa984ae --overwrite
Building graph...
Registering arcs...

Re: [QGIS-Developer] v.net.centrality: Sorry, is not a valid parameter

[Bernd Vogelgesang]

I have no idea what this function does, but when trying with your data
on 3.10 on Linux without any default parameter changes, it first
complains about a wrong output type, because in the advanced parameters,
there is no output type selected by default. Switching this to auto
gives a resulting point layer.

Cheers,
Bernd

Am 31.10.19 um 09:13 schrieb magerlin:

In trying to use v.net.centrality I get the error "Sorry,  is not a
valid parameter"

I have tried several settings when running but keep on getting this error -
cannot figure out from where the word  origins - it must be
something internal in the script as I am not using this word.

Data sample is here:  Poi.zip







-
Regards Morten

Currently using Qgis 2.18.23 (OSGeo4) and Qgis 3.10.0 in parallel
Windows 7, 64bit
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] saving a layer with the world_map.shp

[Bernd Vogelgesang]

This is a really nice easter egg and could be of great use for quickly
showing new users the differences of different crs in a course, if the
shape wastn't that full of topology errors :(

Isn't there maybe a less buggy shape available?

Bernd


___
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] Dealing with datum shift grids in QGIS

[Bernd Vogelgesang]

Am 11.10.18 um 20:31 schrieb Kristian Evers:



On 11 Oct 2018, at 18:55, Martin Dobias > wrote:

...


This would compliment or perhaps even replace the current
proj-datumgrid packages that we maintain at the moment. It would
still be based on a curated set of grids making sure that they are
free to distribute. For the ones that are not available for 
redistribution,

well… I guess the makers of those grids don’t really want you to use
them in the first place :-) In all seriousness though, there’s not much
we can do. They are quite often behind a login so direct links can’t
be offered. We do keep a non-exhaustive list of non-free grids here:

https://proj4.org/resource_files.html#non-free-grids


I saw the German grid in the list of non-free grids. I already contacted 
the responsible administration in 2015 and they told me that the 
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsb is 
definately free to be distributed with any kind of software.





If a feature like this  is something that might be useful to users of
PROJ I we should look into this more closely.

/Kristian

___
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] R provider for QGIS 3 - any interest?

[Bernd Vogelgesang]

I'm sure sf is the future for spatial objects. There are not too many  
examples and resources to be found on the web still, but I ported one of  
my (poor scripts) from sp to sf. It's now maybe 25% of code and maybe 10  
times faster.
Though there are numerous packages with dependencies for sp, which will  
not change for a long time.
I have to admit, I never managed to get R code work properly in QGIS  
(documentation?) but stuck to R studio and just did the post-processing  
within QGIS. Having the ability to work properly within QGIS would maybe  
boost the efficiency to a new level.



Am 02.05.2018, 07:57 Uhr, schrieb Howard Frederick <simbama...@gmail.com>:

Having an R console within QGIS would be incredibly useful! I've been  
copying and pasting between R and QGIS (keeping the WKT field >correctly  
formatted) using read.table, which works well, too. W.r.t. sp vs. sf,  
seems like sf is the future for R spatial objects? >Any thoughts on this?


Crowdfunding definitely seems like the way forward - which platforms  
have been used for this kind of project in the past?
On Fri, 27 Apr 2018 at 03:10, Nyall Dawson <nyall.daw...@gmail.com>  
wrote:

On 26 April 2018 at 22:10, Barry Rowlingson
<b.rowling...@lancaster.ac.uk> wrote:
As a long-time R spatial developer and QGIS user I'll be glad to help  
out -

but time-poor at work for now. "Helping out" may be more  like "making
unreasonable suggestions" and "finding annoying bugs".


Don't undersell yourself... these would be very valuable contributions!

For example, can we find a more efficient way to transfer data from  
QGIS to
R? Can the new `sf` packages in R work with the data straight out of  
QGIS'
memory? I *think* the `sf` package stores vector data in GDALs native  
C++
objects, and if QGIS is doing that too then we *might* be able to get  
access
from QGIS and R if we write the R plugin as a C/C++ module that  
dynamically

links with the shareable libR.so.


I've (very roughly) looked into this, and I also believe it should be
possible to directly create R data frames from QGIS layers. Then we'd
just need to add a "R console" to QGIS, and boom! Awesome spatial
statistical analysis tool directly within QGIS!

Nyall



The current R processing plugin  converts QGIS layers to shapefiles,  
reads

them into a new R process. On occasion I've hit problems with shapefile
limitations (field name length, usually) that make my scripts fail.  
Maybe it

should go via geopackage instead.

Should it create `sp` objects on the R side or `sf` objects? This  
could be

controllable in the R processing script headers, so it can be set on a
per-script basis.

I'll stop now...

Barry






On Thu, Apr 26, 2018 at 9:42 AM, Aurelio Pires <anvpi...@gmail.com>  
wrote:


+1

Thanks,


On 2018-04-26 07:40, Paolo Cavallini wrote:
> Hi all,
>
> Il 26/04/2018 05:08, Nyall Dawson ha scritto:
>> I'm VERY interested in seeing this resurrected. I'm available to
>> mentor this task if someone else wants to take ownership of the  
plugin

>> and do the port, OR alternatively I'd be happy for North Road to do
>> the porting ourselves and take over maintenance if someone can fund
>> this work.
> that's good news. So starting a crowdfunding campaign seems a good  
way

> to go, unless there is a bigger sponsor; do you agree?
> All the best, and thanks.
>

___
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

___
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




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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] Analytics on plugin downloads

[Bernd Vogelgesang]

Hi Pedro,
can't you just put a link to the plugin description directing to a simple  
survey users might fill in?
This kind of data would be of much more use than mere download numbers and  
it would be completely voluntary.


Just an idea,
Bernd


Am 09.02.2018, 08:44 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Hola Pedro,
Il 09/02/2018 02:23, Pedro Camargo ha scritto:

 As I continue the development of AequilibraE (a plugin focused
on tools for transportation modelling), I wish I had access to
statistics on who has downloaded the plugin (e.g. Google Analytics). 
That would help me see what the audience is and, hopefully, gauge better

where to put efforts on.

Is that something that other people also see as useful?  If so, is that
technically possible? Is that planned in any ways?


while I understand it is useful to know our user better, I'm not sure we
want to allow collecting data on them; previous discussions on this
subject resulted in a clear "no" from most if not all parties involved.
All the best.



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] QGIS3: reminder of an annoying bug

[Bernd Vogelgesang]

Am 14.01.2018, 15:09 Uhr, schrieb Tobias Wendorff  
<tobias.wendo...@tu-dortmund.de>:



Dear developers!

...


Possible workaround:
We should check all SRS/CRS, where the parameters overlap. Then we
should order those "duplicates" by the frequency of use (for exaple
official projections first, follwed by historical projections).
Maybe  there's only a handful of projections that are affected.


Sounds as a really good idea (for me). Especially in the processing  
toolbox, some algos silently change the CRS, so you have to check the  
outcome each and every time, cause you never know when this bug will hit  
you. I'm giving a course in some days, and having to teach such a  
behaviour in a course feels somehow awkward, leaving a bad taste.


Cheers
Bernd



Best regards,
Tobias

___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Last call for switching to github issue tracker

[Bernd Vogelgesang]

For me as a simple user, the main obstacle of posting issues in redmine  
is, that I fear to produce a duplicate, cause I didn't even learn over the  
years how to efficiently track an issue down if it already exists.

No idea if github or any other solution is better, but redmine just sucks.

My 2 cents,
Bernd

Am 12.01.2018, 16:30 Uhr, schrieb Régis Haubourg  
<regis.haubo...@gmail.com>:


Hi all,+1 too.My main concern is that I now fail to search efficiently  
for redmine issues, because there are so many now. And this leads to  
>duplicates, or even worst, no declaring the issue because the process  
is too long.Github issues are very well indexed by google, which doesn't  
seem to be the case for redmine. (but this probably can be improved -  
>not sure how)


Régis

2018-01-12 16:06 GMT+01:00 Jorge Gustavo Rocha <j...@di.uminho.pt>:

Hi,

Good point, Denis!

Mathias already have done a lot to support the migration.
I volunteer to help on this task.

Regards,

Jorge Gustavo

On 12-01-2018 14:49, Matthias Kuhn wrote:

On 01/12/2018 03:31 PM, Andreas Neumann wrote:


Hi,

I think the biggest question: who does all the work to migrate from
Redmine to Github while not loosing all our history?



I started working on it some time ago and thought it looked quite
promising. I stopped the work because of lack of conviction that  
there's

a perspective for this.


And I don't think that Redmine is so bad usability wise. I agree, the
UI is not as sexy as Github, but it does its job well. It is much more
powerful for finding and filtering. The issues we had with the slow
performance was fixed when moving to a new Machine at Hetzner. The
main argument for github is in my opinion not ease of use - but the
integration with the code base - that is definitely a strength of
github issue reporting.


Agreed, it's better than before.
Because no more mantra, usable performance.
On the other hand I don't prefer it's search and filtering options.


To undermine that github is not easy to use for non-dev users: last
Wednesday at the Swiss QGIS user meeting I was in the meeting for
QWC2. Users had no idea at all how Github works and could be used for
issue reporting. One had to explain it to them and teach them how to
use it. To assume that using github is self-explanatory for non-tech
users is a wrong assumption.



I wouldn't claim that for either of the two platforms. There's a
learning curve for both. Myself, I happen to meanwhile embrace markdown
but struggle with the redmine syntax. Not because it's worse, just
because I am too lazy to learn another one.

Matthias

___
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



J. Gustavo
--
Jorge Gustavo Rocha
Departamento de Informática
Universidade do Minho
4710-057 Braga
Tel: +351 253604480
Fax: +351 253604471
Móvel: +351 910333888
skype: nabocudnosor
___
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






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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 3.0 Soft Feature Freeze

[Bernd Vogelgesang]

Am 02.01.2018, 23:39 Uhr, schrieb Nyall Dawson <nyall.daw...@gmail.com>:




I think on balance I prefer option #2 as it will get more people using  
QGIS 3 - we must just be careful to tell people that it is ‘next-gen’  
and that the LTR is still 2.18….


Ok, let me re-word option 2 as:

"2. Carefully manage release expectations, with detailed explanations
of known issues and regressions in the release notes. Stress in press
releases/release notes that 3.0 is a new major release and that the
QGIS team do not consider it a suitable replacement for the current
stable LTR release, and that it is highly recommended that
organisations do not replace their existing QGIS 2.x installations
before careful in-house testing and evaluation of its suitability for
their workplace. The next stable LTR QGIS release will be QGIS 3.2."

Nyall




I like all your elaborated wordings, but couldn't you just brand 3.0 with  
a huge red BETA mark, and nearly everyone should know what this means:  
Evaluation: Yes!, Production: Maybe, on yout own risk.





___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] No more "rasmover" plugin

[Bernd Vogelgesang]

Merry Christmas and a happy new year ... also to our friends with  
narcissistic personality disorder ;)





Am 22.12.2017, 07:35 Uhr, schrieb <geodr...@gmail.com>:


Ciao Giovanni,

Simply, I want to be free to develop and share my ideas without having  
to seek someone's approval.


this left me curious, as there is no code revision for 3rd party  
plugins, what is this about?


False.  And you know.Example ?  This:
https://github.com/geodrinx/gearthview/issues/11

So, for what reason you tell something you know is not true ?  This is  
not a code revision ?  What is the name for this ?



and why about this specific plugin and
not others from you?


False.  My develops continue outside qgis official repository.Also for  
gearthview.



thanks for the clarification


You are welcome.




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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 in Ubuntu 16.04

[Bernd Vogelgesang]

yep,
thanx for the fast fix!

Cheers
Bernd

Am 30.03.2017, 09:28 Uhr, schrieb roy roy <royr...@outlook.com>:


It's already fixed, i'm sticking with Ubuntu then.

Thanks to maintainers for the great work!!



QGIS and GRASS GIS installed on Ubuntu, the

QGIS packages with "ubuntugis" dependencies are now broken:

http://hub.qgis.org/issues/16386

"Yesterday, UbuntuGIS got a GDAL 2.1.3 update, so QGIS need to be  
rebuilt

against that version."

Is it possible for QGIS to be rebuilt with the updated libraries?

I know QGIS is rebuild every month but will it be now?

You guys want to force me to use windows, you have to admit that! :-)

given that I (of course) appreciate the effort of maintainers,

thanks, Roy.
___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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 remote control API

[Bernd Vogelgesang]

Hi Barry,
sounds great for me! (simple users opinion)

Cheers
Bernd

Am 14.03.2017, 18:51 Uhr, schrieb Barry Rowlingson  
<b.rowling...@lancaster.ac.uk>:



I'm doing some spatial analysis with R. I've read in a shapefile:

 > data = shapefile("input.shp")

then I've done some analysis:

 > data$stats = something(data)

Now I want to map it. I can use R's plot function, but that's not
interactive, hard to add background layers and style, no labelling,
cartography etc. I could use leaflet, but that requires JS code to get
anything custom. So I write a shapefile:

 > shapefile(data, "output.shp")

Start QGIS, load the shapefile, realise all my column names have been
mashed to 12 characters (or whatever), style it. Go "huh" and think.
Back to R. Repeat.

With a QGIS remote control API I could do something like:

 > addQgisLayer(data)

and *bang* there it is in Qgis. With data flow in that direction, Qgis
is a cartographic display for R's spatial data. But data flow could go
the other way - so that Qgis layers could be easily read back into R
spatial data.

 In theory you could wrap the entire Python API to the remote control
API. At that point the use cases are almost like any Python QGIS use
cases, except expanded to any language or system that can send a web
request. R, Matlab,  JS, perl, ruby.. even Python if you want to be
slightly perverse and can't run from the python interpreter.

Barry












On Tue, Mar 14, 2017 at 3:35 PM, Tom Chadwin <tom.chad...@nnpa.org.uk>  
wrote:

What are some example use cases?

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
--
View this message in context:  
http://osgeo-org.1560.x6.nabble.com/QGIS-remote-control-API-tp5312091p5312279.html

Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] GRASS missing from Processing?

[Bernd Vogelgesang]

Am 13.01.2017, 11:25 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Hi all,
Processing stopped finding my GRASS7 install:

This algorithm cannot be run :-(
It seems that GRASS GIS 7 is not correctly installed and configured in
your system. Please install it before running GRASS GIS 7 algorithms.

while I do have it installed:

i  grass - Geographic Resources Analysis Support System (GRASS GIS)
i A grass-core - componenti principali di GRASS GIS
i  grass-dev - file di sviluppo per GRASS GIS
i A grass-doc - documentazione utente per GRASS GIS
i A grass-gui - interfacce utente grafiche di GRASS GIS
i A libqgisgrass7-2.14.10 - QGIS - libreria grass condivisa
i A qgis-plugin-grass - plugin GRASS per QGIS
i A qgis-plugin-grass-common - plugin GRASS per QGIS - dati indipendenti
dall'architettura
i A qgis-provider-grass - provider GRASS per QGIS

Could it be due to an upgrade? Im on Debian Sid, and I have grass 7.2.0-1
All the best.


Hi,
I see an update for my Linux Mint to grass 7.2.0-1 hanging around in the  
update manager for a week or so, and this time I was so wise to ignore it  
;)

With currently installed 7.0.5-1 it works (am on 2.14.10).

In general, how can we avoid getting in trouble with those updates?

Cheers
Bernd

--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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, Shapefiles, default encoding

[Bernd Vogelgesang]

Am 20.12.2016, 11:05 Uhr, schrieb Drexel Peter  
<peter.dre...@vorarlberg.at>:




Hi,

please, can anyone tell me what default encoding QGIS uses when loading  
a Shapefile?


In my QGIS 2.14.7 on Windows 7 64bit  „Ignore shapefile encoding  
declaration“ is checked,


so if I load a Shapefile with a corresponding utf-8-cpg-file using “drag  
and drop” it is encoded as >‘system’ and the encoding is wrong (what  
encoding is ‘system’?).


If I load a Shapefile with a corresponding utf-8-cpg-file using “Add  
Vector Layer” it is encoded as >‘utf-8’ and the encoding is fine.


In both cases I can change the data source encoding in the properties  
dialog.



Is it possible to change the behavior of drag and drop to use utf-8


If I uncheck „Ignore shapefile encoding declaration“

and load the shapefile either using “Add Vector Layer” or drag and drop  
the cpg-file is interpreted >correctly and the encoding is set to utf-8.


But now I cannot change the data source encoding in the properties  
dialog anymore.


I think it should still be possible to change the encoding in the  
properties dialog.



Peter




Hi Peter,
welcome to the Babylon of computer stone age ;)

I think a lot of people share your confusion with codepages.
Your "system" encoding is that of your Windows, so presumably (in Western  
Europe) windows-1252 or CP1252 or ISO 8859-15.

On a Linux system, it is normally UTF-8.

I often run into problems with the encoding on my Linux system when  
dealing with files from Windows systems and vice versa.

Having files of mixed encodings in a project is a nightmare.
Those problems also seem to derive from files like gpx, kml etc. which  
always seem to be generated using UTF-8.
So even when I decide to handle everthing in Windows-style and convert  
files to windows-1252, those UTF-8 files bring in problems.
Same with the processing toolbox, where some algos happily switch the  
output encoding.


When unchecking „Ignore shapefile encoding declaration“, UTF-8 seems to be  
used internally (see https://hub.qgis.org/issues/11019).
But I have problems understanding all this, and worse, QGIS seems to not  
understand all this as well all the time.


P.s. Haven't touched ArcGIS for years. How does this handle different code  
pages in a project?


















--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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] Reporting an issue at http://hub.qgis.org/

[Bernd Vogelgesang]

Hi,

Am 27.11.2016, 11:50 Uhr, schrieb Richard Duivenvoorde  
<rdmaili...@duif.net>:



On 27-11-16 09:01, Lene Fischer wrote:

Hi,

I want to report issues at http://hub.qgis.org/ - but I have forgot my
username/password.

So now I´m in a catch22 – There is no way to get a new password – I
can´t find a way to create a new login –

Do we want users to report issues – yes/no ?

If yes – it must be much easier to access a platform. Right now it is
only for hardcore users who are really good at remembering passwords….


Hi Lene,

Short story: see below to reset your password:
https://wiki.osgeo.org/wiki/Osgeo_Userid_Help

Long story: we use osgeo-user id's (and ldap for it) because then you do  
not need to remember even more passwords :-)
We could have easier QGIS password infrastructure but in my view we  
shouldn't want this: it is better if we unite as geoFOSS community in  
both infrastructure and use of standards.


I understand that it is very efficient and clever to use an existing  
infrastructure. But this infrastructure is set up in a typical "nerdish"  
way, so we have quite some barriers for non-nerds.


Besides this, you need some determination to create an issue anyway as  
it is best if the issuer keeps monitoring the issue and reacts on  
questions from devs...




There is really the danger that the issues are misused as a helpdesk by  
users for minor stuff if it is better accessible.
But when you do not use the issues regularly, it is hard and time  
consuming filing a new one. The search for already existing issues is not  
easy. Obviously the default settings when filing a issue is, that you do  
NOT get a message when someone replies on the issue, which makes the tool  
quite useless for the lots of people who naturally expect to be subscribed  
to the thread automatically.


I rarely file bugs, though I now subscribed to all issues to at least have  
a chance to get an overview. There is huge discrepancy between what I can  
read in the mailing lists and in the reported issues. So e.g. I was really  
surprised by Giovannis yesterdays issues about regressions of OGR in the  
toolbox for LTR but haven't read anything about this somewhere before.
People already seem to accept that things are broken and silently search  
for alternatives and workarounds.


As long as the developers are happy with the tools, I don't care, but  
assistance from ordinary users in some form is not so likely as well.



 > Let me know if you have a problem resetting your password (though I
cannot reset it for you either...), then we figure out another way to  
issue your problem.


Regards,

Richard Duivenvoorde



Cheers
Bernd




___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Any UI/UX plans for QGIS3?

[Bernd Vogelgesang]

I also wondered that there was no discussion about those topic for QGIS 3  
so far, so I dare to throw into the collection a topic that a while ago  
was raised somewhere:


Ribbon based menues/menue groups

This is definately a love/hate topic, but as I got used to the ribbons in  
MS-Software, I really see them now as a way to partially reduce the  
clutter, though I have no real idea how to intelligently group the stuff  
(but I'm sure enough brilliant people around here could have good ideas)

And this would really give QGIS3 a maximum of a "fresh" look.

Cheers
Bernd

Am 25.11.2016, 12:44 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Il 25/11/2016 12:37, Richard Duivenvoorde ha scritto:


Would be good if somebody collects these idea's, and (given we can come
to some consensus...) maybe try to do a special 'UIX'-funding round
somewhere later in the QGIS-3 process (when api etc etc are settled)?


agreed, a targeted funding could be started. I think most of the stuff
is rather independent from API changes, so probably the two initiatives
could go largely in parallel (March is very close, as other have pointed
out).
All the best, and thanks.




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Table Manager discontinuation and missing French translator

[Bernd Vogelgesang]

Just a note on usability:
Though even the Table Manager was not the obvious tool to manipulate  
attribute tables, cause it wasn't even installed by default, now the  
Refactor Fields function in Processing is even less visible to people.


It would be great if this function could be kind of hard-wired to the  
attribute table with a button (like the field calculator, formatting  
etc.). I think especially ArcMap-users (but not only) will struggle to  
find that function.


Cheers
Bernd



Am 22.09.2016, 14:16 Uhr, schrieb Borys Jurgiel <li...@borysjurgiel.pl>:


Hi folks!

I'm going to discontinue the Table Manager. It was always a dirty  
workaround,
and nowadays (with recent QGIS versions and GDAL 2) numerous data  
corruptions
are reported. As QGIS finally contains the Refactor Fields tool and  
doesn't

need any external plugins, I believe it's the high time to kill the Table
Manager. I'm going to release the final version that displays a farewell
message pointing users to the Refactor Fields (and still works, beside  
that
message). Of course if someone is willing to take the development and  
keep it

up to date with the changing GDAL‚ I can abstain :)

Table Manager was translated into French, Russian and Ukrainian, so I'd  
like
to ask the translators for help with that message. However... I can't  
remember
who was the original translator. A massive shame on me, as it seems I  
didn't

put any credentials anywhere! I don't know how could I overlook it :(( I
apologize and promise to fix it as soon as we find the right persons.

I believe it was Maxim for Russian and Alex for Ukrainian, were you? But  
who
made the French translation? Régis, maybe it was you or do you have any  
ideas?


Best regards

Borys

___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] OpenLayers Plugin - feature request

[Bernd Vogelgesang]

Hi Arne,
adding Stamen terrain background will not take months but a few minutes.

You can either use the Add\Edit\Remove tab under settings, or just copy a  
Stamen folder in qgis2/QuickMapServices/Contribute/data_sources and put it  
into /.qgis2/QuickMapServices/User/data_sources and then adjust the naming  
of the folder and of the settings in the metadata.ini


which looks like this then:

[general]
id = stamen_terrain_background
type = TMS

[ui]
group = stamen
alias = Stamen Terrain Background
icon = stamen.png

[license]
name = CC-BY 3.0
link = http://creativecommons.org/licenses/by/3.0/
copyright_text = Map tiles by Stamen Design, under CC BY 3.0. Data by  
OpenStreetMap, under ODbL

copyright_link = http://maps.stamen.com/
terms_of_use = http://maps.stamen.com/
[tms]
url = http://tile.stamen.com/terrain-background/{z}/{x}/{y}.png
zmin = 0
zmax = 19
y_origin_top = 1

This works quite well, but the service itself is somehow buggy. Lots of  
tiles are missing in deeper zoom levels, both in the browser-based version  
and in QGIS, so the problem is not from QuickMapServices but from the  
service itself.


Hope this helps
Bernd




Am 13.08.2016, 12:11 Uhr, schrieb Arne Wichmann <a...@saar.de>:

begin  quotation  from Bernd Vogelgesang (in  
<op.yltvgnk0l2i25i@vogelbe-esprimo-p2560>):

have a look at the QuickMapServices-plugin.
There are already some Stamen backgrounds available.
Maybe the one you look for is there too. Have also a look at  
Settings/More

services/Get contributed pack

As far as I know, OpenLayers will be replaced by QuickMapServices


Thanks, it helped a bit - it still does not have Stamen  
terrain-background
or something comparable, but it has two other maps I might use  
eventually.


I might try to add Stamen terrain-background when I get around to it -=  
but

I expect this will take some months.

cu

AW



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] OpenLayers Plugin - feature request

[Bernd Vogelgesang]

Hi Arne,
have a look at the QuickMapServices-plugin.
There are already some Stamen backgrounds available.
Maybe the one you look for is there too. Have also a look at Settings/More  
services/Get contributed pack


As far as I know, OpenLayers will be replaced by QuickMapServices

Chhers
Bernd

Am 07.08.2016, 14:39 Uhr, schrieb Arne Wichmann <a...@saar.de>:


Hi,

for my own private anjoyment (role playing) I hacked the OpenLayers  
Plugin

to work with Stamen terrain-background. As I think having a background
which _only_ consists of physical features might be interesting for other
uses, too, I suggest to you to add this to the OpenLayers Plugin.

(I would have sent you a patch, but my abilities to hack python are very
rudimentary...)

cu

AW



--
Dipl-Geogr. Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf
Tel.: 09133-825374
___
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] Future of OpenLayers plugin - time to deprecate?

[Bernd Vogelgesang]

Am 14.06.2016, 22:25 Uhr, schrieb Anita Graser <anitagra...@gmx.at>:




On Tue, Jun 14, 2016 at 9:57 PM, Nyall Dawson <nyall.daw...@gmail.com>  
wrote:




On 31 Dec 2015 7:33 AM, "Nyall Dawson" <nyall.daw...@gmail.com> wrote:


Hi all,

The email chain below is just one example of a user who has issues
with QGIS after installing the OpenLayers plugin. Stackexchange is
filled with similar examples (See
http://gis.stackexchange.com/questions/tagged/qgis-openlayers-plugin).

I'm wondering if it's time we discussed the future of this plugin. Now
that we have a viable replacement (Quick Map Services) which doesn't
demonstrate these issues, should we deprecate the OpenLayers plugin
and remove it from the plugin repo?


Can we revisit this discussion again?

I'm very much in favour of:
1. Removing openlayers plugin from the repo asap. This plugin is broken  
and unfortunately is harming the reputation of the >>project, as many  
users cannot distinguish the difference between the plugin's issues and  
problems with QGIS itself (eg see  
>>https://twitter.com/thatkindofplace/status/742543174573260800?s=03 )


2. Rename QuickMapServices as "QuickMapServices (OpenLayers  
replacement)" on the plugin repo, so users looking for openlayers >>are  
nicely directed to the new plugin
I would propose to rename it to "Basemaps (OpenLayers replacement)".  
QuickMapServices is one of the most unintuitive names for such a basic  
need ... a basemap ;)


My 2 cents
Bernd


​+1 for all the reasons above.

Thanks for reviving this Nyall!

Best wishes,
Anita​






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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] Moving styles from and to db and shp

[Bernd Vogelgesang]

Am 04.03.2016, 10:03 Uhr, schrieb Paolo Cavallini :


Hi all,
we designed a project based on a db, then saved all layers to shp. In
the process, the names of the columns were obviously truncated, so the
styles are no longer working, and have to be fixed by hand.
I do not see an automated way to solve this - am I missing something? A
possible longer term solution could be to use column aliases to define a
style: could this be a reasonable enhancement?
All the best.
IMHO the only reasonable enhancement would be to get rid of shp as default  
intermediate working format within QGIS, but discussions about possible  
candidates still end nowhere.


Sorry for advocating this this again ;)
Bernd
___
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] Future of OpenLayers plugin - time to deprecate?

[Bernd Vogelgesang]

+1 for deprecating.
I think the "popularity" of OpenLayers only derives from the fact that it  
was the only plugin available serving basemaps for a long time and that it  
is mentioned all around the web in tutorials etc.
Most of my collegues with less experience frequently step into the traps  
and digitize stuff only to find later that the result is shifted or the  
map is not printable.


I skipped it already a long time ago and tried to compensate it by finding  
other sources like WMS etc which is not so easy over here in Germany  
(especially since the built-in WMS Server Search results are completely  
outdated for a long time).


Since the QuickMapServices plugin is there, I always recommend that.
If this plugin would become the "successor" of OpenLayers, it would be  
nice to know why those most popular sources like Bing etc are "hidden" in  
the contributed services. Legal issues?


I already proposed to the developers to rename their plugin to "Basemaps",  
cause thats what it is actually about and which is a lot easier to  
understand and memorize.


Cheers
Bernd


Am 31.12.2015, 07:17 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:

Deprecating it makes sense to me, unless authors plan to fix the long  
standing issues.

Thanks for raising this.
All the best.

Il 31 dicembre 2015 06:47:08 CET, h <hdi...@bigpond.net.au> ha scritto:

On Wed, 30 Dec 2015 22:42:27 -0500
Randal Hale <rjh...@northrivergeographic.com> wrote:

As a non-developer if I can chip in my .02 cents worth - I think 
deprecating it might be a good thing. To me it was always a plugin

that received a lot of applause - but the one that would cause the
most questions ("why can't I use this imagery in map composer").
While I liked having access to google/bing imagery - it always made
me more uncomfortable having it there because of the terms of service.
I didn't know that QuickMapServices was a plugin - and after looking
at it I think most people will have a problem because there is no 
google/bing imagery in that one. In the US I have enough choices for 
imagery - and that might not be the case everywhere else. I'm unsure


how up to date MapQuest Aerial is - but better than nothing.



I got caught on that one.
In QuickMapServices>Settings there is a "Contributed Services" tile.
Select "Get Contributed Services" and a whole lot of stuff, including
Bing and Google are provided.

To me QMS makes "Open layers" obsolete - but it needs a bit more
documentation on how to get Bing etc!!!

On principle I am against retirement, but am not aware of a strong
argument against it for Open Layers.  (Something I have used and valued
for quite some time..)
H


Possibly add a pop-up/warning on the open layers plugin since it is 
popular - "We are in the process of deprecating this plugin".

Other than that - +1 for retirement.
Randy
On 12/30/2015 09:42 PM, Nyall Dawson wrote:

On 31 December 2015 at 13:29, Joshua Quesenberry
<engn...@gmail.com> wrote:

If the plugin is deprecated, what is replacing it? I find the
plugin to be very useful.

QuickMapServices. It's got numerous improvements over OpenLayers,
including reprojection support and not breaking the map composer.

Nyall




-Original Message-
From: Qgis-developer
[mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom
Chadwin Sent: Wednesday, December 30, 2015 5:46 PM To:

qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer]
Future of OpenLayers plugin - time to deprecate?

I think deprecation and removal would be good, but for a
tangential reason: the name conflicts with OpenLayers the web
mapping library. A trivial reason at best, but probably irritating
to many, and potentially confusing to users.



--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Future-of-OpenLayers-plugin-time-to-deprecate-tp5243358p5243372.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


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


--Paolo Cavallini
http://www.faunalia.eu




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___

Re: [Qgis-developer] Table Manager and Refactor Fields (was Re: Re: Featured plugins)

[Bernd Vogelgesang]

Is there any way to make Refactor Field more prominent to the users?  I  
have to admit, I already tried it once and immediately forgot about again.


And the major drawback: There seems to be no way to change the current  
layer, but you have to produce a new one (temporary or new).

This is not very comfortable, compared to Table Manager.

Cheers
Bernd




, or Am 04.12.2015, 14:42 Uhr, schrieb Borys Jurgiel  
<li...@borysjurgiel.pl>:



Why e.g. is the Table Manager not installed and available by default?


Sorry for a little off-topic answer, but -1 for making Table Manager a  
core
plugin. Please note we have much more advanced tool in the Processing  
tree:

Refactor Fields (only available in the advanced mode I guess).

Table Manager was developed as a temporary workaround and despite all the
effort we put in its safety I never felt comfortable with the  
responsibility
for users' data ;) So since we have Refactor Field, I don't have any  
plans for

further development and I strongly encourage everyone to use the Refactor
Field instead.

Best regards,

Borys


___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Featured plugins

[Bernd Vogelgesang]

Am 03.12.2015, 20:14 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Hi all,
I wonder what is the criterion to mark a plugin as featured. There is
even one featured plugin which is now deprecated.
Perhaps we should have clear criteria for inclusion, and keep the list
updated?
All the best.


With new users in mind, I wonder if the plugins page is really the  
resource for picking a plugin, or if they just search through the plugin  
manager for things they might need, cause it does provide the exact same  
informations as the website (minus those tags).


More important for me would be the question, which plugins are installed  
and enabled by default. And I ask the question again (I never got an  
answer on that before): Why e.g. is the Table Manager not installed and  
available by default? As ESRI shape is the major output format, a novice  
starting to use QGIS has no tool to alter the attribute table, which is  
IMHO an unnecessary obstacle.
I bet there are not few people fumbling around in the dbf before realizing  
that there is a plugin available.


Just my two cents
Bernd


--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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] Featured plugins

[Bernd Vogelgesang]

Am 03.12.2015, 23:10 Uhr, schrieb Andreas Neumann <a.neum...@carto.net>:


But why?

Most of the table manager functions are already in Core. It is perfectly  
possible to add and remove columns without the table >manager.


If some of the table manager functions are still missing in core, it is  
better to bring the missing functionality into core, >rather than  
enabling Table manager by default.


I am not a fan of having many Python plugins enabled by default, because  
they slow down the loading of QGIS. Also, Python plugins >are a major  
source of additional bugs ...


Andreas
Yep, MOST is in. But for example not moving order or renaming columns. How  
stupid is that, to rename a columns by creating a new one, copying the  
data and then deleting the old one, just to find it then in the end of all  
columns without the possibility to change that?
And to newbies it is NOT obvious by any means that they have to install  
the Table Manager to be able to do so.


Sure there must be good reasons why those functions didn't make it into  
core so far (maybe also the long existence of the Table Manager plugin?)


Sorry, didn't want to high jack this thread for my personal favourite ;)

Over and out
Bernd



On 03.12.2015 23:02, DelazJ wrote:
Agree with you, Bernd, that features like the ones provided by "Table  
Manager" plugin should be in QGIS by default. >>However, installing  
(and enabling) by default other dev's plugins mean that QGIS dev team  
should somehow be responsible >>of its stability; there are already  
Core plugins (Processing, DBManager...) and I'm not sure they should  
have to do >>this with other plugins.
+1 to have "Table Manager" features in Core but not really in favour of  
activating plugins unless they integrate the >>Core plugins schema.


2015-12-03 20:59 GMT+01:00 Bernd Vogelgesang <bernd.vogelges...@gmx.de>:
Am 03.12.2015, 20:14 Uhr, schrieb Paolo Cavallini  
<cavall...@faunalia.it>:



Hi all,
I wonder what is the criterion to mark a plugin as featured. There is
even one featured plugin which is now deprecated.
Perhaps we should have clear criteria for inclusion, and keep the list
updated?
All the best.


With new users in mind, I wonder if the plugins page is really the  
resource for picking a plugin, or if they just >>>search through the  
plugin manager for things they might need, cause it does provide the  
exact same informations as >>>the website (minus those tags).


More important for me would be the question, which plugins are  
installed and enabled by default. And I ask the >>>question again (I  
never got an answer on that before): Why e.g. is the Table Manager not  
installed and available by >>>default? As ESRI shape is the major  
output format, a novice starting to use QGIS has no tool to alter the  
attribute >>>table, which is IMHO an unnecessary obstacle.
I bet there are not few people fumbling around in the dbf before  
realizing that there is a plugin available.


Just my two cents
Bernd


--Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
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] Improving ftools geoprocessing tools

[Bernd Vogelgesang]

Am 22.10.2015, 13:30 Uhr, schrieb João Gaspar <joao.f.r.gas...@gmail.com>:


Dear QGIS Developers,

I'm writing on behalf of my employer, a company that has mixed,
proprietary and open source (especially QGIS of course) gis
infrastructure, with qgis being adopted each day a little more.
Actually in our migration path we have found a road blocker: the very
bad performances (and sometimes results) of most of geoprocessing
tools in the vector menu. Yes I know that there are alternatives in
the Processing toolbox, but that is not an option for most of our very
basic users: they need to do simple operations (clips, unions,
intersections, etc.) with usually very large/detailed vectors (usually
shapefiles). In this scenario QGIS usually chokes or is at best very
slow (compared to other gis packages, the ones we are trying to get
rid of).

What can be done to improve this tools? Rewriting the tools to improve
efficiency and accuracy?

We available some funds: this is the first time I convince people
above me to put some money in QGIS development, and a decision would
need to me made until the end of November tops, otherwise money will
be used otherwise.

Please leave advice and feedback.


Regards
João Gaspar





Hi,
I'm not a developer, but a simple user following this list.

My point of view is, that the ftools are just a relict from the past since  
the processing toolbox was introduced.
I'm glad that people step up for funding QGIS, but in this particular  
case, you would better invest your money and time in lifting your "basic"  
users to a little more advanced users and show them how to use the  
processing toolbox properly.


As far as I know, the toolbox is nearly feature complete with the ftools  
functions, and most of them are so much faster and/or versatile, that I  
did not touch the ftools for ages.
Prepare some centrally stored models for reoccuring use cases, and have  
happy users ;)


Just my two cents
Bernd



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Improving ftools geoprocessing tools

[Bernd Vogelgesang]

Am 22.10.2015, 16:14 Uhr, schrieb Victor Olaya <vola...@gmail.com>:


shp is the default format for temp files, and as such it is used in
the modeler for intermediate results. That is, however, very easy to
change, so if we agree on any other format, it can be changed and set
as the default for Processing


+1000 Yes, please, get rid of this pain in the a.. as soon as possible and  
use SpatiaLite e.g..
Creating these files might take considerably longer and they consume more  
space, but compared to the time I spend refactoring column names all the  
time and finding workarounds, this is nothing.

It's also one of the reasons why I do my heavy lifting work in R nowadays.

Cheers
Bernd


2015-10-22 16:08 GMT+02:00 Bernhard Ströbl <bernhard.stro...@jena.de>:

Hi Andreas,

AFAIK processing uses shp for in between results in a model, too. So if  
you

build a model you loose your fields, no matter which output format you
choose. IMHO it should therefore be considered to change processing's  
data

source. Maybe SpatialLite is an option? Users can still export to shp if
needed.

Bernhard



Am 22.10.2015 um 15:48 schrieb Andreas Neumann:


Bernhard,

I agree that these tools should be QGIS algorithms - maybe even ported
from another GIS (if feasible).

One major annoyance with fTools and some processing algorithms is that
reliance on ESRI shapefile as output. That way I always loose my  
columns
- or they are truncated to be meaningless. For that reason I often  
don't

use QGIS, but FME for analysis. Or try to do the processing with SQL in
Postgis.

If we renovate these algorithms in the vector menu we'd have to make
sure that the output could be any chosen vector format, or at least
supports geopackage/spatialite/postgres as output.

Andreas

On 22.10.2015 15:26, Bernhard Ströbl wrote:


IMHO all ftools should be replaced by native QGIS processing
algorithms. For "simple" users it may be not feasible (or not allowed)
to install additional software. Therefore native QGIS algorithms
should be improved to be fast, robust and offering choices the users
need (see recent discussion on dissolve)

Bernhard

Am 22.10.2015 um 15:13 schrieb Andreas Neumann:


If we'd replace the ftools (vector and raster menu) through  
processing.

What would replace them? Would we do research and see which of the
alternative processing providers provides best speed/reliability - if
there are multiple versions? It may be, that for Algorithm A, Saga  
works
best, whereas for algorithm B GRASS is better and for C GDAL or the  
QGIS

builtin in mechanism.

Andreas

On 22.10.2015 14:59, Victor Olaya wrote:


  * Why is the processing toolbox not an option for your users? (Do
you
require shortcuts (menu entries) to the tools? Is it the parameter
interface which is more fine-tuned? Missing functionality?)



If what you need is to have the tools in a menu, we have been
discussing that before, and the idea is to mantain the same menu
structure if the users wants that, but have the algorithms based on
Processing to avoid redundant (and more difficult to mantain) code.  
As

I said, this has already been discussed, but it is not yet
implemented. Maybe your funding could help us do it?

And if algorithms are not performant enough, it's clearly better to
put your effort in the Processing ones (which, in general, are just  
a
copy of the ftools ones), and have them exposed through the menus,  
as

explained above.

Regards




__ Information from ESET Mail Security, version of virus  
signature

database 12448 (20151022) __

The message was checked by ESET Mail Security.
http://www.eset.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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [QGIS-UX] Composer Legend items: what are the differences between "auto-update" and "update all" options?

[Bernd Vogelgesang]

Hi,
I'm more missing a discussion about why in fact all loaded layers are  
displayed in the legend, and not only those activated in the canvas.
There is a reason why a deactivate layers: I want to produce a map only  
with those active ones = shown in the map.
So why do I have to manually remove unneeded (in my cases often dozens of  
layers) from the legend, or, even worse, delete them from the project just  
to re-add them when I produce the next map?


It would be much smarter to add just those active in the moment of  
creating the legend. In case I forgot one I need, I will be happy to add  
this one manually.


Or did I miss sth obvious?

Cheers
Bernd

Am 14.10.2015, 20:29 Uhr, schrieb Anita Graser <anitagra...@gmx.at>:




On Wed, Oct 14, 2015 at 2:20 PM, Andreas Neumann <a.neum...@carto.net>  
wrote:

Hi,

I am adding the UX (user interface) list about this legend discussion.

The whole situation about legend updates and the current legend GUI in  
composer is indeed a bit confusing and changed quite a bit >>in the  
last one (or two? releases). I also think that the "Auto update"  
checkbox and the "Update all" button next to it are almost >>redundant.


​Do we have a ticket for this issue yet?I'm afraid I haven't had time  
yet to look into this and form an opinion or even a suggestion for how  
the UI should >be improved.
It would be great if the users interested in enhancing this part of QGIS  
could come up with a draft and open a >ticket where it can be discussed  
in detail and with images :)

Thanks a lot!
Best wishes,
Anita​






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Release schedule discussion - again

[Bernd Vogelgesang]

Am 13.10.2015, 10:00 Uhr, schrieb Wolfgang Stemberger  
<wolfgang.stember...@hotmail.com>:




Dear all,imagine yourself being a new QGIS user. Go on the qgis-website  
and you see immediately the download option >for version 2.10. Click on  
"documentation" and you realise it refers to 2.8. This situation was  
even worse in the >past (I think 2.8 versus 2.2). The first impression  
you get, is that the software is not properly documented and >this is  
definitely not a good argument especially for newbies (who we should  
convince of using qgis).  There is >already a lack on people  
contributing to the documentation, but the short release cycle makes it  
even more >difficult to have up-to-date software help.
As several others have also mentioned, QGIS has very good functionality  
now and a slow-down would help to >make the software more stable and to  
improve issues like documentation. Such a stable and well documented  
>version could be promoted on the main page of qgis, while rather  
unstable versions with more functionality >should be rather "hidden" for  
those who would like to test.

+1

I can imagine that the developers are proud of their product and want to  
promote it (2.10 vs. 2.8.3).
And in the past, it was really essential to migrate to the next version  
asap to get needed/missing features.


But even me, who likes to be on the edge and who is not afraid to test new  
things (which most people I know wont), I now stick to the LTR cause the  
advantages to switch the version compared to the hassle to update the  
system (and other peoples systems I would like to share projects with) are  
tending to zero or even minus.


Having to wait for 2 years for another version (and its nice new  
functions) on the other hand seems a little long to me.
A yearly base for a main version of QGIS would be fine. Documentation  
would have time to keep pace, bugs could be eliminated with point releases.


Sponsors who want their paid core features delivered asap should then have  
to take the "risk" and use intermediated releases, at the price of less  
documentation and maybe more bugs.


But the majority of users would benefit from that (which hopefully would  
result in more donations).


Just my 2 cents from my naive user perspective.
Bernd

p.s.
It would also be nice for me as a Linux user to have an easy possibility  
to run the master-version alongside LTR without compiling and stuff (like  
Windows user can).




Wolfgang



Date: Tue, 13 Oct 2015 09:32:28 +0200
From: j...@norbit.de
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Release schedule discussion - again

Hi Lauri,
On Tue, 13. Oct 2015 at 10:27:57 +0300, Lauri Kajan wrote:

What if we don't introduce any new features in LTR releases?
Huh?  That's what we do.   And the LTR package repositories are fed with  
the
new LTR release only after it has been regular release for four month.   
So you

would probably never see a .0 there.
Jürgen
--Jürgen E. Fischer   norBIT GmbH Tel.  
+49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax.  
+49-4931-918175-50
Software Engineer   D-26506 Norden  
http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on  
FreeNode 
___ Qgis-developer mailing  
list Qgis-developer@lists.osgeo.org  
http://>lists.osgeo.org/mailman/listinfo/qgis-developer




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS missing from Processing?

[Bernd Vogelgesang]

Hi folks,
though there was an update of Processing to 2.10.2, my GRASS7 still won't  
work in QGIS 2.8.3 (LTR and ubuntu-unstable dependencies repositories)
Returning to Processing 2.9.3 (which now permanently resides as a zip in  
my plugins folder, so I only have to uncompress it and have GRASS running  
again after an update)


Anyone experiencing the same?

Cheers
Bernd


Am 18.09.2015, 12:31 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Il 18/09/2015 11:58, Bernd Vogelgesang ha scritto:


Strange. Processing is my work horse from the moment on it was
published, and I will never want to miss it again. I wonder how and what
other users do, when not using processing? This is an outstanding
innovation


Agreed. The main point here is very few people invest in it, so
stabilization and innovation is slower than we would like.
All the best.



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS missing from Processing?

[Bernd Vogelgesang]

Am 03.10.2015, 17:37 Uhr, schrieb Andrew <amcani...@gmail.com>:


Hi Bernd,

Did editing(processing version 2.10.1) grass7algortihm.py work for you?   
I noticed yesterday that with processing 2.10.2 GRASS7 >doesnt work but  
reverting to the edited version of 2.10.1 fixed that.


Andrew
No, I didn't try this cause actually I have no clue how to patch this  
without breaking it (sorry just dumb user) and 2.9.3 worked for me.


Thought that waiting a while will cure this magically, but obviously  
things run out of control will all those different versions.
And I also thought that staying with the LTR, I will be on the save side  
... mhm.


I could patch this if I had a patch file (I really do NOT understand  
github)


Bernd









--

Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problems installing nigthlies (2.11) for testing on Ubuntu/Mint with ubuntugis dependencies

[Bernd Vogelgesang]

Am 02.10.2015, 14:42 Uhr, schrieb Jürgen E. Fischer <j...@norbit.de>:


Hi Bernd,

On Fri, 02. Oct 2015 at 14:24:33 +0200, Bernd Vogelgesang wrote:

Has anyone a clue whats going wrong?


Should also be fixes with
https://github.com/qgis/QGIS/commit/e263e9ecbffa87af7f000b7530a93eca5b0a0935#diff-3a8967c9c7449446ddcdc76faa20bfafL293

But the nightlies are still underway...



Thank you Jürgen,
I try to be patient ;)

Bernd



Jürgen




--
Erstellt mit Operas E-Mail-Modul: http://www.opera.com/mail/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problems installing nigthlies (2.11) for testing on Ubuntu/Mint with ubuntugis dependencies

[Bernd Vogelgesang]

Am 28.09.2015, 15:26 Uhr, schrieb Bernd Vogelgesang  
<bernd.vogelges...@gmx.de>:



Hi,
after a long time, I wanted to help testing, so I try to install the  
nightlies in Linux Mint.


Following qgis.org, I added http://qgis.org/ubuntugis-nightly and   
http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu for trusty  
on a fresh VM install.


When I do: sudo apt-get install qgis python-qgis qgis-plugin-grass
it complains (in german)
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
  qgis-plugin-grass : Hängt ab von: grass-core (< 7) aber  
7.0.1-1~exp1~trusty soll installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene  
defekte Pakete.


So, it seems that nothing has changed so far.
Still the same error when trying to  install strictly following the  
details on qgis.org.


I see no point in trying to tweak sth to get this running. I would rather  
prefer testing with my normal work environment, which is "unfortunately"  
Ubuntu/Mint with ubuntu-unstable dependencies.


Has anyone a clue whats going wrong?

Cheers
Bernd





so I tried just installing without qgis-plugin-grass, which ran through.
Though starting QGIS from shell:

qgis: error while loading shared libraries: libqgis_app.so: cannot open  
shared object file: No such file or directory


No idea what to do.
Any hints?

Bernd

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

Re: [Qgis-developer] GRASS missing from Processing?

[Bernd Vogelgesang]

Am 18.09.2015, 11:26 Uhr, schrieb Filipe Dias <filipesd...@gmail.com>:


Hi

This is indeed annoying. I'm using GRASS 7 directly as a result.
As Paolo mentioned recently, Processing doesn't seem to be extremely  
popular amongst QGIS users and it is understaffed at the >moment.




Strange. Processing is my work horse from the moment on it was published,  
and I will never want to miss it again. I wonder how and what other users  
do, when not using processing? This is an outstanding innovation, but  
obviously too much hidden (simplified interface, duplications with vector  
and raster menu), so ppl have no idea what it is good for?


Using the GRASS GUI is only sth for people with no tendencies to nervous  
breakdowns ;)


Cheers
Bernd




Cheers

On Fri, Sep 18, 2015 at 10:19 AM, Bernd Vogelgesang  
<bernd.vogelges...@gmx.de> wrote:
Am 18.09.2015, 09:30 Uhr, schrieb Paolo Cavallini  
<cavall...@faunalia.it>:



Il 18/09/2015 08:58, Paolo Cavallini ha scritto:


I'm referring to this:
https://lists.osgeo.org/pipermail/qgis-developer/2015-August/038772.html
If I inderstand it correctly, a commit and a new package is much  
needed.


I confirm once more that the simple fix in:
https://github.com/qgis/QGIS/commit/2a14ffd281d0a0e99a0a899622a29ca0efdb0852
works. Could please someone release a new Processing package?
It's pretty important, as GRASS is broken without it.
Thanks.


I was already wondering why nothing happened for such a long time.  
https://hub.qgis.org/issues/13072 is closed.
My GRASS (on QGIS 2.8.3) was only working cause I fiddled around for  
hours and then downloaded processing 2.9.3 manually and >>refused to  
update it to 2.10.1. Since then, no new processing plugin was shipped.
I wonder how many people have no GRASS support for months now, don't  
they dare or are there only so few Linux users who try to >>use LTR but  
always compile latest versions?


Cheers
Bernd

--Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] GRASS missing from Processing?

[Bernd Vogelgesang]

Am 18.09.2015, 09:30 Uhr, schrieb Paolo Cavallini <cavall...@faunalia.it>:


Il 18/09/2015 08:58, Paolo Cavallini ha scritto:


I'm referring to this:
https://lists.osgeo.org/pipermail/qgis-developer/2015-August/038772.html
If I inderstand it correctly, a commit and a new package is much needed.


I confirm once more that the simple fix in:
https://github.com/qgis/QGIS/commit/2a14ffd281d0a0e99a0a899622a29ca0efdb0852
works. Could please someone release a new Processing package?
It's pretty important, as GRASS is broken without it.
Thanks.


I was already wondering why nothing happened for such a long time.  
https://hub.qgis.org/issues/13072 is closed.
My GRASS (on QGIS 2.8.3) was only working cause I fiddled around for hours  
and then downloaded processing 2.9.3 manually and refused to update it to  
2.10.1. Since then, no new processing plugin was shipped.
I wonder how many people have no GRASS support for months now, don't they  
dare or are there only so few Linux users who try to use LTR but always  
compile latest versions?


Cheers
Bernd

--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing Modeler regression Unable to open datasource of intermediate results

[Bernd Vogelgesang]

Am 26.08.2015, 09:08 Uhr, schrieb Anita Graser anitagra...@gmx.at:


Hi,

There seems to be a regression between Processing 2.9 and 2.10 where  
2.10 fails to run models because it cannot find the intermediate  
results it produced in a previous step. The model runs perfectly in 2.9.  
Bellow you can see an example to reproduce: just chain QGIS buffer and  
OGR dissolve and it fails because it's looking for a file  
:\Users\agraser\AppData\Local\Temp\processing\7f77fa47bcec4799818d1f5ea41cc8a9\OUTPUT.sh  
(without C: and .sh instead of .shp)


Are you already aware of this or should I open a ticket.

Best wishes,
Anita


Hi,
I reported this already some weeks ago: https://hub.qgis.org/issues/13174
My suspicion was, that this is related to GDAL processes, cause all others  
seem to run fine.







Algorithm dissolve starting...

Prepare algorithm: QGISFIXEDDISTANCEBUFFER_1

Running Fixed distance buffer [1/2]

Parameters: INPUT  
=C:/Users/agraser/Downloads/qgis_sample_data/shapefiles/popp.shp,  
DISTANCE =1, SEGMENTS =5, DISSOLVE =True


Converting outputs

OK. Execution took 67.825 ms (1 outputs).

Prepare algorithm: GDALOGRDISSOLVEPOLYGONS_1

Running Dissolve polygons [2/2]

Parameters: INPUT_LAYER  
=C:\Users\agraser\AppData\Local\Temp\processing\7f77fa47bcec4799818d1f5ea41cc8a9\OUTPUT.shp,  
GEOMETRY =geometry, FIELD =TYPE, MULTI =False, FIELDS =False, COUNT  
=False, AREA =False, STATS =False, STATSATT =TYPE, OPTIONS =


GDAL command:

cmd.exe /C ogr2ogr.exe  
C:\Users\agraser\AppData\Local\Temp\processing\a44629a1c1f34bc4bf9d26ed974f2bb6\OUTPUTLAYERALGGDALOGRDISSOLVEPOLYGONS1.shp  
:\Users\agraser\AppData\Local\Temp\processing\7f77fa47bcec4799818d1f5ea41cc8a9\OUTPUT.sh  
OUTPUT -dialect sqlite -sql SELECT ST_Union(geometry),TYPE FROM  
'OUTPUT' GROUP BY TYPE -explodecollections

GDAL command output:

FAILURE:
Unable to open datasource  
`:\Users\agraser\AppData\Local\Temp\processing\7f77fa47bcec4799818d1f5ea41cc8a9\OUTPUT.sh'  
with the following drivers.

- ESRI Shapefile
- MapInfo File
- UK .NTF
- SDTS
- TIGER
- S57
- DGN
- VRT
- REC
- Memory
- BNA
- CSV
- NAS
- GML
- GPX
- KML
- GeoJSON
- Interlis 1
- Interlis 2
- GMT
- GPKG
- SQLite
- ODBC
- WAsP
- PGeo
- MSSQLSpatial
- OGDI
- PostgreSQL
- MySQL
- PCIDSK
- OpenFileGDB
- XPlane
- AVCBin
- AVCE00
- DXF
- Geoconcept
- GeoRSS
- GPSTrackMaker
- VFK
- PGDump
- OSM
- GPSBabel
- SUA
- OpenAir
- PDS
- WFS
- HTF
- AeronavFAA
- Geomedia
- EDIGEO
- GFT
- GME
- SVG
- CouchDB
- Idrisi
- ARCGEN
- SEGUKOOA
- SEGY
- XLS
- ODS
- XLSX
- ElasticSearch
- PDF
- Walk
- CartoDB
- SXF
Converting outputs

OK. Execution took 0.125 ms (1 outputs).

Model processed ok. Executed 2 algorithms total

Converting outputs

Loading resulting layers




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Any working GRASS in QGIS available? - Processing Bug?

[Bernd Vogelgesang]

Hi Andrew


Am 06.08.2015, 19:20 Uhr, schrieb Andrew amcani...@gmail.com:


Victor,

I edited the version of the processing plugin that i have installed  
(QGIS 2.8.3, processing 2.10.1) with the changes you made and now  
GRASS7 tools work as they should, thanks!


Andrew


Could you maybe describe a little bit what you have changed and how ?

Bernd




On Thu, Aug 6, 2015 at 5:59 AM, Victor Olaya vola...@gmail.com wrote:

A quick (but very relevant) note about GRASS7:

It seems that, in one of the latest changes, I unintentionally left
out a code line where GRASS was actually being called. I was getting a
bit crazy wondering where the error might be and why GRASS7 was not
working in the latest releaseand finally found out that the reason
was that. So, in short, Processing was not running grass when running
a grass7 algorithm.

I have added that line back and it should be fine now.

If you can install the current master version, please test and let me
know if there are any issues or it is working correctly as before.

Regards



2015-08-03 1:37 GMT+02:00 Bernd Vogelgesang bernd.vogelges...@gmx.de:

Hi Alex

Am 03.08.2015, 01:20 Uhr, schrieb Alex Mandel  
tech_...@wildintellect.com:


Ah but we're closer to finding a solution with all those details. It  
may

be fixable in Processing, which can be pushed to the plugin repo for
update any time.

Passing this along to devs who might have enough information now.

Thanks,
Alex




Thanks for taking care,

by the way: by copying the gdal algorithms from processing 2.10.1 to  
the
2.9.3 folder (.qgis2/python/plugins/processing/algs/gdal), I gained  
access

to the new GDAL dissolve polygons :)

Unfortunately, the model from before (GRASS6) didn't work anymore, and  
all
attempts to adjust it via diff of a test model failed. So reworking my  
model
(for the 10th time or so) in Ubuntu 2.8.3 from ubuntugis-ltr with  
working

GRASS7, SAGA and everything and a partially upgraded Processing 2.9.3

I'm on my way ... finally .. hopefully ...

Bernd




On 08/02/2015 03:07 PM, Bernd Vogelgesang wrote:


Am 02.08.2015, 22:44 Uhr, schrieb Alex Mandel
tech_...@wildintellect.com:


After some brief testing, my OSGeoLive 8.5 VM with QGIS 2.6 and
Processing 2.9.3, GRASS 7 works.

My QGIS 2.8, GRASS 6/7, Processing 2.10.1 does not.



Gave Windows another try: Removed everything, and installed the  
simple

install OSGEO4W setup.
QGIS 2.10.1 with Processing 2.10.1 and GRASS 6 working.

switched back to Ubuntu, cause of a bug in the modeler version of  
GDAL

Dissolve Polygons (which is crucial for me).
https://hub.qgis.org/issues/13174

Ubuntu: Now that I installed 2.8 with the debian repository only (so
without ubuntis depencies), my GRASS 6 works (sorted out another  
error,

that GRASS takes a column name OR from shape as an sql-command or
sth), update to Processing 2.10.1 worked as well.

The drawback, no SAGA, which might come handy cause the now available
algos do not really do what I expect ;)

I think the problem is within Processing in combination with the
packaging:
When e.g. I install QGIS 2.8 with ubuntugis-ltr dependencies (where
nobody on the install page claims I shouldn't do), GRASS7 and the
modeler are working, but Processing version is 2.6. Updating  
Processing

to current Processing 2.10.1 (as recommended) seems to work.
(Besides that v.clean in the modeler only returns a polygon layer  
from

an polygon input, if I also set an output name for the error layer,
otherwise I get an empty line shape)

But: The next time I run QGIS and want to run an GRASS algo: Missing
depencies

I can now replace Processing 2.10.1 with the second latest 2.9.3 from
https://plugins.qgis.org/plugins/processing/version/2.9.3/
and there v.clean does what it should in Processing AND modeler.

But: Now I do not have GDAL Dissolve polygons which is in Processing
2.10.1. Well, I could switch back to Windows QGIS 2.10, but, grr,  
there

is the bug in this algo ...

You see, I'm trapped.

Thanx for you attention
Bernd





Both are Ubuntu 14.04 based.

I'm not sure if this is a bug in Processing, or in packaging. I  
recall
in OSGeoLive 8.5 that we had custom packages with a patch. Note,  
you can

get those versions for your Ubuntu system from
https://launchpad.net/~osgeolive/+archive/ubuntu/release-8.5

We freeze a copy of the working versions in our own ppa for long  
term

history.

Thanks,
Alex


On 2015-08-02 03:32, Bernd Vogelgesang wrote:


Hi Alex,

Am 02.08.2015, 01:22 Uhr, schrieb Alex Mandel
tech_...@wildintellect.com:

It's not a Windows/Ubuntu/Mac/OS thing, it's a QGIS + GRASS  
version

change thing.

Please indicate which version of QGIS and GRASS you are trying to  
get

working.



Actually I do not mind any more what version I would like to get
working. I would have preferred the 2.8-LTR branch with  
no-matter-what

GRASS version.

I just would like to be able to finish my project, and there is
unfortunately no alternative to the GRASS algos in my model.

QGIS

Re: [Qgis-developer] [Qgis-user] Any working GRASS in QGIS available? - Processing Bug?

[Bernd Vogelgesang]

Hi Alex

Am 03.08.2015, 01:20 Uhr, schrieb Alex Mandel tech_...@wildintellect.com:


Ah but we're closer to finding a solution with all those details. It may
be fixable in Processing, which can be pushed to the plugin repo for
update any time.

Passing this along to devs who might have enough information now.

Thanks,
Alex



Thanks for taking care,

by the way: by copying the gdal algorithms from processing 2.10.1 to the  
2.9.3 folder (.qgis2/python/plugins/processing/algs/gdal), I gained access  
to the new GDAL dissolve polygons :)


Unfortunately, the model from before (GRASS6) didn't work anymore, and all  
attempts to adjust it via diff of a test model failed. So reworking my  
model (for the 10th time or so) in Ubuntu 2.8.3 from ubuntugis-ltr with  
working GRASS7, SAGA and everything and a partially upgraded Processing  
2.9.3


I'm on my way ... finally .. hopefully ...

Bernd




On 08/02/2015 03:07 PM, Bernd Vogelgesang wrote:
Am 02.08.2015, 22:44 Uhr, schrieb Alex Mandel  
tech_...@wildintellect.com:



After some brief testing, my OSGeoLive 8.5 VM with QGIS 2.6 and
Processing 2.9.3, GRASS 7 works.

My QGIS 2.8, GRASS 6/7, Processing 2.10.1 does not.


Gave Windows another try: Removed everything, and installed the simple
install OSGEO4W setup.
QGIS 2.10.1 with Processing 2.10.1 and GRASS 6 working.

switched back to Ubuntu, cause of a bug in the modeler version of GDAL
Dissolve Polygons (which is crucial for me).
https://hub.qgis.org/issues/13174

Ubuntu: Now that I installed 2.8 with the debian repository only (so
without ubuntis depencies), my GRASS 6 works (sorted out another error,
that GRASS takes a column name OR from shape as an sql-command or
sth), update to Processing 2.10.1 worked as well.

The drawback, no SAGA, which might come handy cause the now available
algos do not really do what I expect ;)

I think the problem is within Processing in combination with the  
packaging:

When e.g. I install QGIS 2.8 with ubuntugis-ltr dependencies (where
nobody on the install page claims I shouldn't do), GRASS7 and the
modeler are working, but Processing version is 2.6. Updating Processing
to current Processing 2.10.1 (as recommended) seems to work.
(Besides that v.clean in the modeler only returns a polygon layer from
an polygon input, if I also set an output name for the error layer,
otherwise I get an empty line shape)

But: The next time I run QGIS and want to run an GRASS algo: Missing
depencies

I can now replace Processing 2.10.1 with the second latest 2.9.3 from
https://plugins.qgis.org/plugins/processing/version/2.9.3/
and there v.clean does what it should in Processing AND modeler.

But: Now I do not have GDAL Dissolve polygons which is in Processing
2.10.1. Well, I could switch back to Windows QGIS 2.10, but, grr, there
is the bug in this algo ...

You see, I'm trapped.

Thanx for you attention
Bernd





Both are Ubuntu 14.04 based.

I'm not sure if this is a bug in Processing, or in packaging. I recall
in OSGeoLive 8.5 that we had custom packages with a patch. Note, you  
can

get those versions for your Ubuntu system from
https://launchpad.net/~osgeolive/+archive/ubuntu/release-8.5

We freeze a copy of the working versions in our own ppa for long term
history.

Thanks,
Alex


On 2015-08-02 03:32, Bernd Vogelgesang wrote:

Hi Alex,

Am 02.08.2015, 01:22 Uhr, schrieb Alex Mandel
tech_...@wildintellect.com:


It's not a Windows/Ubuntu/Mac/OS thing, it's a QGIS + GRASS version
change thing.

Please indicate which version of QGIS and GRASS you are trying to get
working.


Actually I do not mind any more what version I would like to get
working. I would have preferred the 2.8-LTR branch with no-matter-what
GRASS version.

I just would like to be able to finish my project, and there is
unfortunately no alternative to the GRASS algos in my model.

QGIS 2.6 and older works with GRASS 6, 2.8+ sometimes is built to  
work

with GRASS 7 (though possibly also with GRASS 6).


Mhm, reverting to 2.6 ... Lets see if this still possible at all ...


If you want a guaranteed working setup ASAP download a copy of OSGeo
Live Virtual Machine, we made sure that it works in that.
http://live.osgeo.org


Will give it a try. Download will take another 1.5 hours ...

So does that mean that even your do not have a working GRASS in a  
recent

QGIS by normal means but the osgeo VM?




Thanks,
Alex


Cheers
Bernd



On 2015-08-01 14:41, Bernd Vogelgesang wrote:

Hi guys,
is it just bad karma, that I seem not to able to get a working
GRASS in
QGIS? Or did I miss the big advertisement GRASS out of order
somewhere.

For nearly 2 weeks, I tried to get things to work in Ubuntu/Mint,  
and

tried every possible/impossible repository, but always GRASS has
missing
dependencies, the forms open in Processing, but the algos don't run
through, or the functions are working in Processing, but failing in
the
modeller.

As I really got to finish a model in the Modeller including some  
GRASS

algos, I finally turned

Re: [Qgis-developer] Thoughts about multi-type tables in QGIS

[Bernd Vogelgesang]

Hi,

While reading this thread, I again stumbled upon the topic that QGIS is  
not able to handle arcs so far. Is that topic somehow also connect to the  
fact that each layer can only hold one type of geometry?


Cheers
Bernd



Am 04.04.2015, 10:28 Uhr, schrieb Marco Hugentobler  
marco.hugentob...@sourcepole.ch:



Hi

Yes, the implicit assumption that each layer has one geometry type  
probably goes back to the shapefile. I agree it is a wrong design from  
QGIS to assume that and it is not in line with the logic of many  
important datasources (Postgres, Oracle, MS SQL, WFS and also some OGR  
formats like dxf), therefore causing workarounds on the dataprovider  
level to seperate db tables into several layers. I think it is best (at  
least in the long term) to have a logic compatible to the datasources  
instead of doing workarounds at provider and gui level.


There are many places where this has an impact (e.g. symbology system,  
editing). Therefore it will be good to break the 'one geometry type'  
assumption not before version 3. A first step could be to identify the  
places in core/gui/app where changes would be needed.


@Nathan and Victor: I don't have experience with MapInfo. What is the  
exact reason why multi-geometries have been user-unfriendly there?


Regards,
Marco



On 02.04.2015 13:52, Olivier Dalang wrote:

Hi,

In some projects of mine, I work with multiple geometry types in one  
postgis table, using a column of type geometry(Geometry,4326).

This is very well supported by postgis.

It is possible to load such a table in QGIS by manually selecting the  
geometry type you want to load. This means that to display all the  
features, you need to add the table three times, one for each feature  
type.


This works more or less. There are a few bugs though :
- http://hub.qgis.org/issues/12499 (you can edit other type's node with  
the node tool)
- http://hub.qgis.org/issues/12500 (other type's records are shown in  
the attribute table)


This also has some limitations. When having such a setup, it's pretty  
sure you'll want to have the same edit forms for all the layers.  
You'll also probably want the same filter, the same labels, the same  
actions, etc...
The only thing you'd want to be able to define on a geometry type basis  
are the symbol (well, even the classification/colors/etc could be  
shared) and the label placement.
For now, you must do all settings three times, because of this  
bug/feature request :
- http://hub.qgis.org/issues/12303 (copy/paste style from one geometry  
type to another)



As you see, support multiple geometry types in QGIS is not perfect.

Of course it's possible to fix the bugs/pr, and there are some  
workarounds (postgis view instead of tables) but maybe it's also  
worth thinking a bit more in depth about this.


We could consider point/line/polygons as subcategories/sublayers of a  
layer. A shapefile or a mono-typed table would have only one of those  
sublayer, but a postgis table could perfectly have the three. Most of  
the settings would be defined at the layer level, while only some  
settings would be defined at the subcategory level.


This is probably especially relevant when thinking long term (the day  
we support 3D, curves, etc...).



What do you think ?
Do you think the relation 1 layer = 1 geometry type will hold ?

I think we inherited this from the old shapefile format, but most data  
sources QGIS handles don't have this limitation. I also think it does  
not hold with quite a lot of modern GIS uses (especially web related,  
think of openstreetmaps for instance).


There's this feature request (6th oldest open issue on the tracker)  
about postgis geometry collections  : http://hub.qgis.org/issues/167



Best,

Olivier



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



--Dr. Marco Hugentobler
Sourcepole -  Linux  Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Transformation using NTv2 grids

[Bernd Vogelgesang]

Hi Giovanni,

thanx for your answer.

Just contacted the organization which might be in charge to answer the  
question about the circumstances to redistribute that file.


I hope we are talking of the same stuff: I mean this one  
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsb or  
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsa


Sorry, this topic is quite new for me, so I do not really know what I am  
talking about ;)


But do I see it correctly, that the normal way to reproject a layer with  
Save as ... will produce quite inaccurate results, and that the users  
have to be aware that they could/should use a plugin?
So there will be two ways to reproject the data,the default one (not so  
accurat) and a plugin version (more accurate)?


Cheers
Bernd

Am 17.02.2015, 16:13 Uhr, schrieb Giovanni Manghi  
giovanni.man...@gmail.com:



Hi Bernd



Hi there,
reactivating this thread and also pushing it to the dev list to maybe
receive a statement:

Is it somehow planned to include the BETA2007.gsb and the resulting
changes into QGIS for 2.8 by default?

I received already some questions, cause now even german bureaucracy is
waking up and tell users to switch to ETRS and transform the data from
Gauss-Krueger.
But for the majority of QGIS users, this will be rocket science if they
even learn THAT they have to create custom CRS, change srs.db entries  
and

do other wizardry.

So far, googling QGIS and BETA2007 yields no results on any moves  
into

this direction.
But without, QGIS users in Germany will likely produce tons of trash  
data

in the near future or already do so without knowing (me included till
today).

Also see https://hub.qgis.org/issues/11347

... or is is not that critical as I believe it is?



exactly because ntv2 transformations should not be rocket sciemce for
the users, we (Portuguese qgis user group, with the initial help of
Alexander Bruy) created this plugin

http://www.qgis.pt/plugins/plugins.xml

Given that you can redistribute the gsb files (and for Portugal this
is possible) then the ntv2 transformations become trivial.

I had already had a thought of expanding this plugin and adding the
transfomations for countries that have available gsb grids and allow
them to redistribute.

If someone is interested or need it just let me know.

Cheers


--
Giovanni Manghi
http://www.naturalgis.pt/
* QGIS Desktop development
* WebGIS development
* QGIS and PostGIS Training
---



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Transformation using NTv2 grids

[Bernd Vogelgesang]

Hi there,
reactivating this thread and also pushing it to the dev list to maybe  
receive a statement:


Is it somehow planned to include the BETA2007.gsb and the resulting  
changes into QGIS for 2.8 by default?


I received already some questions, cause now even german bureaucracy is  
waking up and tell users to switch to ETRS and transform the data from  
Gauss-Krueger.
But for the majority of QGIS users, this will be rocket science if they  
even learn THAT they have to create custom CRS, change srs.db entries and  
do other wizardry.


So far, googling QGIS and BETA2007 yields no results on any moves into  
this direction.
But without, QGIS users in Germany will likely produce tons of trash data  
in the near future or already do so without knowing (me included till  
today).


Also see https://hub.qgis.org/issues/11347

... or is is not that critical as I believe it is?

Cheers
Bernd


Am 05.02.2014, 16:13 Uhr, schrieb Marco Hugentobler  
marco.hugentob...@sourcepole.ch:



Hi

Would it be possible to define a Custom CRS for the source CRS  
containing the

nadgrids-stuff for doing ntv2 transformation in QGIS 2.0.1?



Yes, it is possible to work with custom CRS (although it is not so  
convenient).



Is this already in 2.1?
If yes, where could one find it?



There is a dialog showing the available datum transformations. This  
dialog shows up as soon as a layer needs a datum transformation (e.g. if  
on-the-fly reprojection is toggled or when doing save as'). However, the  
ntv2 transformation info has to be inserted into srs.db / table  
datum_transform first.


Regards,
Marco

On 05.02.2014 15:42, Robert Nuske wrote:

Hi Marco,


QGIS 2.2 will have support for NTv2 datum transformations as a core
function.

Is this already in 2.1?
If yes, where could one find it?


Would it be possible to define a Custom CRS for the source CRS  
containing the

nadgrids-stuff for doing ntv2 transformation in QGIS 2.0.1?

For example GK3:
+proj=tmerc +lat_0=0 +lon_0=9 +k=1.00 +x_0=350 +y_0=0  
+ellps=bessel

+units=m +nadgrids=BETA2007.gsb +wktext


cheers,
   robert



On 05.02.2014 13:34, Burgstaller Stefan wrote:

Hi,

is it already possible to reproject shape-files using NTv2 grids? I
was looking for appropriate plugins, help documents and already
available tools but I have not found anything. Since the federal
states in Germany start to convert their geospatial data from
Gauss-Kruger to ETRS89 with NTv2 grids this topic becomes more and
more urgent.

Greetings,

Stefan Burgstaller



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

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






--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing disappeared from QGIS master?

[Bernd Vogelgesang]

Am 21.01.2015, 13:59 Uhr, schrieb Pedro Venâncio  
pedrongvenan...@gmail.com:



Hi,

I don't know what is your opinion, but perhaps the best solution would  
be to make a fork of SAGA within QGIS, so could standardize the version  
for all platforms and for all users. Otherwise it is impossible to  
create multiplatform Processing Models... Since QGIS has this quick  
releases cycle, it was a question of updating SAGA to the latest  
version, in each new QGIS version.


In my case (Ubuntu 12.04), SAGA tools does not appear, because I have  
SAGA 2.1.1 installed from ubuntugis-unstable, which is no longer  
supported in QGIS Master:


https://github.com/qgis/QGIS/commit/b0291985ac16a1f2809979257ffc12d84004e897

supportedVersions = {2.1.2: (2.1.2, SagaAlgorithm212),
2.1.3: (2.1.3, SagaAlgorithm213),
2.1.4: (2.1.3, SagaAlgorithm214)}

This way will emerge a problem, since in ubuntugis-unstable, SAGA has  
only been updated for versions of Ubuntu 14.XX (the rest have 2.1.1 or  
earlier). When QGIS 2.8 will be released, it will arise many complaints  
because the SAGA disappears. I'm pretty sure that most users of  
ubuntu-like-systems use ubuntugis-unstable to install these packages and  
dependencie


What do you think?


I as a user have a lot of trouble with SAGA every while end then,  
especially like you mentioned with models I built to run on Win and Linux  
Mint/Ubuntu.
Even though I have an updated Linux Mint 17.1 = Ubuntu 14.04 with  
ubuntu-unstable, SAGA only works partially. Seems like most vector related  
function still work, but all raster related functions fail, so my models  
are working only under Windows now.


There might be other reasons for that than only SAGA, but for the average  
Linux user, this is hard to solve.
So any ideas how to make the integration of SAGA more stable would be much  
appreciated.


Just my 2 cents
Bernd







Thank you very much!

Best regards,
Pedro Venâncio




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Crowdfunding for a Christmas gift to QGIS - live layer effects!

[Bernd Vogelgesang]

Hi Nyall,
I tried to donate, but my credit card was refused without any hints why.  
Its still valid till 08/15. Any experience with that already or other ways  
to contribute?


Cheers
Bernd


Am 25.12.2014, 10:54 Uhr, schrieb Nyall Dawson nyall.daw...@gmail.com:


Hey all,

Just letting everyone know about a new crowdfunding project I've just  
launched:


https://www.kickstarter.com/projects/41633306/a-christmas-gift-for-qgis-live-layer-effects-for-q

This project aims to add live layer effects to QGIS which can be
applied to symbols. Some examples include live blur effects, drop
shadows, and outer glows. Think Photoshop style layer effects but
available directly within QGIS.

Initially this will be just for symbol layers, but the code will be
flexible enough to allow these effects to apply to composer items,
labelling, etc. Effects will also be stackable, eg, you can apply a
blur to a symbol and then a subsequent drop shadow effect.

Why crowdfund? Well, there's a lot of work left to get this to a
mergeable stage. It's not a sponsored project, and will take a lot of
time to complete. I think crowdfunding will be the best way of raising
the amount to fund my development time on this valuable feature.

So, please share the word!

Merry Christmas to all,
Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geometry type conversion of 2.6

[Bernd Vogelgesang]

Hi,

I just wanted to write also to the list because of a similar issue, but  
here it happens when using processing.
I created a regular point grid over a polygon. As I just wanted to have  
the points inside the polygon and not the bounding box, I clipped it with  
the processing version of ftools clip.
The readOGR in my R script I wanted to use the points with then complained  
about the layer being multipoint. Multipart to single part fortunately did  
the trick.

The original ftools clip did deliver a normal point layer though.

Cheers
Bernd

Am 11.11.2014, 09:28 Uhr, schrieb Minoru Akagi akagi...@gmail.com:


Hi,

I just found size of .shp file increases more than twice (2900 bytes
- 6500 bytes when it has 100 points) when I saved a point layer as a
shapefile. I didn't edit the layer anything, but the geometry type was
converted from Point to Multipoint.

Maybe this must not expected behavior. Is this a big bug of 2.6? See
also #11542 and #11597.


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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] *** GMX Spamverdacht *** WMS Search results

[Bernd Vogelgesang]

Hi Susann,

i was wondering about that too, so I had a look:
Under Options - Network: General there is the field WMS search address  
http://geopole.org/wms/search?search=%1type=rss


On http://geopole.org/about, you can find in the last line Copyright (c)  
2008-2010 by Sourcepole AG with a link to http://www.sourcepole.com/


Obviously this service is not really maintained (2008-2010) and indeed  
there hasn't been a lot of changes for a long time.

So maybe you can contact the guys and ask them what to do to get listed.

Cheers
Bernd

Am 01.10.2014, 12:45 Uhr, schrieb sschm...@gfi-gis.de:



Hi all,
don't know if the question is right placed here.In QGIS in the Add WMS  
dialog on tab Search for Server you can put in some keywords and get  
a list of WMS matching this topic. How could a WMS becomes a member of  
this resultlist?

Freundliche Grüße aus Leipzig
Susann Schmidt
Softwareentwicklung
**

GFI - Gesellschaft für Informationstechnologie mbH
Philipp-Rosenthal-Straße 9
D-04103 Leipzig
Geschäftsführer: Andreas Richter
Amtsgericht Leipzig HRB 12054
USt.-IdNr.: DE179049354 Steuer-Nr.: 231/109/06412
ESRI Solution Partner  und   ER Mapper Reseller
Tel. 0341 961 3310Fax 0341 961 3311   Mail i...@gfi-gis.de
Web  www.gfi-gis.de  und  www.themenbrowser.de




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Run stable and master versions of QGIS on Ubuntu

[Bernd Vogelgesang]

Hi Josef,yes, I do want to have "stable" qgis with fdgb (+mrsid) support AND master for testing/new features, and yes, I already found your blog and also managed to build gdal on a virtual machine. But as with all those blogs, there is the "glue" missing.For example I never found a text describing building gdal AND using the rest from the repositories. Normally, they only cover building everything and only latest versions and master and other cutting edge stuff, but simple how-tos how to set-up an easy to maintain system comparable what you get on windows out of the box with osgeo4w seem not to exist.Fortunately, Alex and Eric already gave some very important hints.  Assuming that worked, you would then probably want to put a hold on gdal so it doesn't get updated and lose your customizations. I assume that too, but how would I do "put a hold on gdal"?It's called Pinning in the debian world. In synaptic you highlight thepackage in the list, then to Package - Lock Version The command line fu way is to edit an apt file like this example (justchange the package names)http://askubuntu.com/questions/23578/how-do-i-pin-a-particular-mysql-version-to-avoid-unnecessary-upgradesThis was completely new for me and I would never ever have managed to find out on myself just through googling cause for that you need to know the terms to search for.Ok, at the moment I have no time for the experimenting, but at least I know how to "pin" this thread in my mail-client for later use ;)CheersBerndAm 12.03.2014, 20:44 Uhr, schrieb josef k groundwater...@gmail.com:Bernd,I recently installed gdal with filegdb on ubuntu 13.10. My notes-to-self about the installation procedure are found here: http://hydrogeotools.blogspot.se/2013/07/install-gdal-with-file-gdb-and.html
Then I installed qgis 2.2 from ubuntugis-unstable. And now I do have qgis with filegdb-support.Is this what you were trying to achieve? ( I have to admit I did not read the full thread.)
/Josef
-- Vidarebefordrat meddelande --From:"Bernd Vogelgesang" bernd.vogelges...@gmx.deTo:"Eric Goddard" egoddard1...@gmail.com
Cc:qgis-developer@lists.osgeo.orgDate:Tue, 11 Mar 2014 21:10:12 +0100Subject:Re: [Qgis-developer] Run stable and master versions of QGIS on UbuntuAm 11.03.2014, 20:35 Uhr, schrieb Eric Goddard egoddard1...@gmail.com:


What I still do not get is, why my requirements seem to be so "exotic", that there is no easier way for all this. But maybe I manage to solve all this and maybe post it somewhere.
Lots of googling ahead ... after already googling a lot.
-- Bernd VogelgesangSiedlerstraße 291083 Baiersdorf/IgelsdorfTel: 09133-825374___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Run stable and master versions of QGIS on Ubuntu

[Bernd Vogelgesang]

Thanx Remi for bringing this up ... I didn't dare to ...

The problem with compiling the dev version imho is, that you will have 
to recompile it permanently if you are trying to be of any help with bug 
tracking, am I right? (Haven't compiled anything yet, cause I don't get 
rid of the knots in my brain)


On the other hand, to use QGIS professionaly, I need GDAL with FGDB 
and MrSID support, so I will have to compile GDAL myself beforehand.
But wanting to use it for work, I better not use the master version but 
the stable.


So, as I see it, it would be much better to compile the stable version 
and then get the master version for the candies and the testing from 
debian-nightly.
But all guidelines propose it the other way round, which I do not really 
understand ...


Said this, when I want to compile the stable version instead of the 
master, but with a handmade GDAL, is there any way to take benefit 
from the ubuntugis-unstable repository (things I can install beforehand 
and then disabling the repository again)?


As I said, I have knots in my brain on this and never managed to have a 
nice and easy environment on Ubuntu as I have with Windows (which is 
sd)

Can someone help me with the surgery?

Cheers
Bernd



Am 11.03.2014 17:59, schrieb Alex Mandel:

The only non-compile way I can think of on an Ubuntu box would be to run
a virtual machine. Otherwise you have to compile to avoid package
manager conflicts.

So up to you which is more time/hassle to setup.

Enjoy,
Alex

On 03/10/2014 01:26 PM, Etienne Tourigny wrote:

AFAIK, you have to build your own version (preferrably master) with a
different install prefix (e.g. /home/softdev/), and when you want to use
that version you need to add relevant paths to PATH and LD_LIBRARY_PATH.

I have a shell function that sets this up on demand:

setup_softdev()
{
export SOFT_PREFIX=/home/softdev
export LD_LIBRARY_PATH=/home/softdev/lib
export LIBRARY_PATH=/home/softdev/lib
export LD_RUN_PATH=/home/softdev/lib
export PATH=/home/softdev/bin:$PATH
export CPLUS_INCLUDE_PATH=/home/softdev/include
export C_INCLUDE_PATH=/home/softdev/include
export CPPFLAGS=-I/home/softdev/include
export PYTHONPATH=/home/softdev/lib/python2.7/site-packages/
export GDAL_DATA=/home/softdev/share/gdal
}
export -f setup_softdev



On Mon, Mar 10, 2014 at 5:19 PM, Rémi Bovard remi.bov...@gmail.com 
wrote:



Hi list,

I'm wondering if there is there a simple way to run stable and master
versions of QGIS on Ubuntu? By simple, I mean - if possible - without
compile QGIS from source.

For now, as described in doc [1], I edit /etc/apt/sources.list to 
define

which repository to use : http://qgis.org/debian or
http://qgis.org/debian-nightly. But doing like this, I cannot run 
the two

versions at the same time.

Thank you in advance for your answers.

Rémi

[1] http://qgis.org/en/site/forusers/alldownloads.html#ubuntu


___
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] Run stable and master versions of QGIS on Ubuntu

[Bernd Vogelgesang]

Am 11.03.2014, 20:35 Uhr, schrieb Eric Goddard egoddard1...@gmail.com:


You could try downloading the source package for gdal and modifying
the debian/rules file to add the necessary --with-FileGDB and
--with-MRSID=... lines. Installing the modified gdal with the package
manager should allow it to be used with the stable QGIS from the
ubuntuGIS repo and the development version from debian-nightly. I've
never actually done this with ubuntu/debian but I do the equivalent on
Arch Linux. For ubuntu you would do something like:

mkdir ~/build
cd ~/build
sudo apt-get build-dep gdal
apt-get source gdal
cd gdal-1.10.0 # or whatever directory it unpacks...
nano debian/rules
##edit file to include the necessary --with-FileGDB and --with-MrSID
lines and cd back to the main package directory and build the package:
cd ..
dpkg-buildpackage -us -uc -nc

install the packages with something along the lines of
sudo dpkg -i gdal*

Assuming that worked, you would then probably want to put a hold on
gdal so it doesn't get updated and lose your customizations.

disclaimer: I have never tried this with ubuntu, but that appears to
be the general flow from a little bit of googling.

Eric


Hi Eric,
thanx a ton for your input.
I'm still quite unfamiliar with building from source and how all these  
things play together.


What I still do not get is, why my requirements seem to be so exotic,  
that there is no easier way for all this. But maybe I manage to solve all  
this and maybe post it somewhere.

Lots of googling ahead ... after already googling a lot.


Assuming that worked, you would then probably want to put a hold on
gdal so it doesn't get updated and lose your customizations.

I assume that too, but how would I do put a hold on gdal?


Cheers
Bernd




On Tue, Mar 11, 2014 at 12:45 PM, Bernd Vogelgesang
bernd.vogelges...@gmx.de wrote:

Thanx Remi for bringing this up ... I didn't dare to ...

The problem with compiling the dev version imho is, that you will have  
to

recompile it permanently if you are trying to be of any help with bug
tracking, am I right? (Haven't compiled anything yet, cause I don't get  
rid

of the knots in my brain)

On the other hand, to use QGIS professionaly, I need GDAL with FGDB  
and

MrSID support, so I will have to compile GDAL myself beforehand.
But wanting to use it for work, I better not use the master version but  
the

stable.

So, as I see it, it would be much better to compile the stable version  
and

then get the master version for the candies and the testing from
debian-nightly.
But all guidelines propose it the other way round, which I do not really
understand ...

Said this, when I want to compile the stable version instead of the  
master,

but with a handmade GDAL, is there any way to take benefit from the
ubuntugis-unstable repository (things I can install beforehand and then
disabling the repository again)?

As I said, I have knots in my brain on this and never managed to have a  
nice
and easy environment on Ubuntu as I have with Windows (which is  
sd)

Can someone help me with the surgery?

Cheers
Bernd



Am 11.03.2014 17:59, schrieb Alex Mandel:

The only non-compile way I can think of on an Ubuntu box would be to run
a virtual machine. Otherwise you have to compile to avoid package
manager conflicts.

So up to you which is more time/hassle to setup.

Enjoy,
Alex

On 03/10/2014 01:26 PM, Etienne Tourigny wrote:

AFAIK, you have to build your own version (preferrably master) with a
different install prefix (e.g. /home/softdev/), and when you want to use
that version you need to add relevant paths to PATH and LD_LIBRARY_PATH.

I have a shell function that sets this up on demand:

setup_softdev()
{
export SOFT_PREFIX=/home/softdev
export LD_LIBRARY_PATH=/home/softdev/lib
export LIBRARY_PATH=/home/softdev/lib
export LD_RUN_PATH=/home/softdev/lib
export PATH=/home/softdev/bin:$PATH
export CPLUS_INCLUDE_PATH=/home/softdev/include
export C_INCLUDE_PATH=/home/softdev/include
export CPPFLAGS=-I/home/softdev/include
export PYTHONPATH=/home/softdev/lib/python2.7/site-packages/
export GDAL_DATA=/home/softdev/share/gdal
}
export -f setup_softdev



On Mon, Mar 10, 2014 at 5:19 PM, Rémi Bovard remi.bov...@gmail.com  
wrote:


Hi list,

I'm wondering if there is there a simple way to run stable and master
versions of QGIS on Ubuntu? By simple, I mean - if possible - without
compile QGIS from source.

For now, as described in doc [1], I edit /etc/apt/sources.list to define
which repository to use : http://qgis.org/debian or
http://qgis.org/debian-nightly. But doing like this, I cannot run the  
two

versions at the same time.

Thank you in advance for your answers.

Rémi

[1] http://qgis.org/en/site/forusers/alldownloads.html#ubuntu


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



___
Qgis-developer mailing list

Re: [Qgis-developer] INSTALL.txt

[Bernd Vogelgesang]

Am 23.02.2014, 04:12 Uhr, schrieb Robert Szczepanek rob...@szczepanek.pl:


Hi Bernd,

(...) Finding all these infos (and sometimes not very congruentt ones)  
in

different blogs and forums is ridiculously time-consuming. (...)


Several people invested time [1] to create QGIS.
You are welcome to be part of the project and improve build description.
After that read your e-mail once again...
Robert Szczepanek

[1] http://www.ohloh.net/p/3663/estimated_cost


Hi Robert,
sorry for the wrong wording again. Of course I appreciate all your efforts  
in developing QGIS and I'm a QGIS-evangelist.
I donate as often as I can, and that's all i can contribute, cause I am  
even not able (yet) to build that stuff myself.


This message was written to show a really minor mistake in the install  
text on github, and further on I (humbly) remarked that it would be nice  
to have a central place for the install instruction for the other parts  
needed as well. And contributing to that would of course not be the  
developers job, but maybe thinking about the possibility to offer a wiki  
for that.
QPA-Platforms like stackexchange are not really suitable for that, and  
searching the mailing lists will not lead anywhere in a lot of cases as  
well.


And it is really time consuming to gather all the tips and tricks from  
those different resources, and I'm always a friend of streamlining  
processes, not only for me but also for lots of others who fail in  
building that stuff, or even finding proper instructions.


If I were able to build QGIS and related stuff myself, I would be able to  
run the stable and the master versions alongside and could work and test.
And when I finally successfully built everything, I would be happy to  
publish my findings .. but where? Just on an other blog or in another  
blogs comments, which will be outdated soon?


But I do not intend to lead a discussion here.
Just my 2 cents
Bernd





W dniu 22.02.2014 21:32, Bernd Vogelgesang napisał(a):

HI,
In my struggle to manage to build QGIS from source, I finally found
the  INSTALL-file on github. (No link to this from the website! At
least I  couldn't find anything)
 I just want to remark, that under
 Optional dependencies:
...
- for georeferencer - GSL = 1.8
 the version number can't be correct, cause there is no such high
version  available.
This might be no big problem for most people, but for a noob like me,
this  is causing hysteria and increasing blood pressure.
 I think it came into existence from an old version i found here
http://osgeo-org.1560.x6.nabble.com/Minimal-requirements-td4157264.html
where it sais:
 - for georeferencer - GSL = ? (works with 1.8)
   In general, I would also like to remark, that it would be very nice  
to

 have kind of a wiki for build instructions for the different
platforms and  versions and the different related resources like GDAL,
spatialite etc. as  well, cause I have to build GDAL myself for MrSID
and FGDB-support (and  without that, QGIS on Linux is quite useless
for me, at least not for  productive work).
Finding all these infos (and sometimes not very congruentt ones) in
different blogs and forums is ridiculously time-consuming. And when I
already invest so much time in fiddling out this, I would like to have
the  other parts state of the art as well, but there is unfortunately
no common  place for instructions on the related items.
 Cheers
Bernd

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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] INSTALL.txt

[Bernd Vogelgesang]

HI,
In my struggle to manage to build QGIS from source, I finally found the  
INSTALL-file on github. (No link to this from the website! At least I  
couldn't find anything)


I just want to remark, that under

Optional dependencies:
...
- for georeferencer - GSL = 1.8

the version number can't be correct, cause there is no such high version  
available.
This might be no big problem for most people, but for a noob like me, this  
is causing hysteria and increasing blood pressure.


I think it came into existence from an old version i found here
http://osgeo-org.1560.x6.nabble.com/Minimal-requirements-td4157264.html
where it sais:

- for georeferencer - GSL = ? (works with 1.8)



In general, I would also like to remark, that it would be very nice to  
have kind of a wiki for build instructions for the different platforms and  
versions and the different related resources like GDAL, spatialite etc. as  
well, cause I have to build GDAL myself for MrSID and FGDB-support (and  
without that, QGIS on Linux is quite useless for me, at least not for  
productive work).
Finding all these infos (and sometimes not very congruentt ones) in  
different blogs and forums is ridiculously time-consuming. And when I  
already invest so much time in fiddling out this, I would like to have the  
other parts state of the art as well, but there is unfortunately no common  
place for instructions on the related items.


Cheers
Bernd

--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Shortcut changes in QGIS; call for opinions

[Bernd Vogelgesang]

Instead of a confirmation when deleting a layer, an Undo-action for  
already deleted layers would be much more helpful.
Cause you can happily confirm to delete sth, but figure out you were wrong  
just a minute later ...


Cheers
Bernd

Am 29.11.2013, 00:18 Uhr, schrieb A Huarte ahuart...@yahoo.es:


I agree with Nathan.

I think that 'D' should ask confirmation, we can imagine the reaction of  
a user removing accidentaly a configured layer.

'Ctrl+D' could remove layers without confirmation.

Alvaro




De: Nathan Woodrow madman...@gmail.com
Para: Borys Jurgiel li...@borysjurgiel.pl
CC: qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org;  
A Huarte ahuart...@yahoo.es; qgis-u...@lists.osgeo.org  
qgis-u...@lists.osgeo.org

Enviado: Jueves 28 de noviembre de 2013 23:19
Asunto: Re: [Qgis-user] [Qgis-developer] Shortcut changes in QGIS; call  
for opinions




Given that adding/removing a complex layer can be expensive and there  
is no undo I would suggest to have a single key shortcut (D) with  
confirm and a modified one without (Ctrl-D).  You want to avoid the  
user doing something dangerous and in this case that is removing a  
layer layer without undo.



- Nathan



On Fri, Nov 29, 2013 at 3:11 AM, Borys Jurgiel li...@borysjurgiel.pl  
wrote:


Dnia czwartek, 28 listopada 2013 15:11:30 A Huarte pisze:




+ Remove layer from legend - Ctrl+D with ask for confirmation.
   Now QGIS does not ask for confirmation.


What about leaving the possibibility to remove the layer without  
confirmation

with a separate shortcut?

Actually the first what I do after a fresh install is changing  
Ctrl-D to
simple D, as I couldn't imagine myself using two fingers for such  
basic

action like layer removing ;)) The same with a dozen of other Ctrl-*
shortcuts. And I believe I'm not the only one.

Regards,
B.

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







--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS inconsistency

[Bernd Vogelgesang]

Hi Steven,

just having a quick look at the data you provided:
- your Munros.shp doesn't have 27700 projection, but some user defined and  
only becomes visible when setting to 27700 manually.
- the geojson and the shape file have quite some offset. (75 whatsoevers,  
meteres, miles ??)


Apart from the fact that there might  be a bug, your data seems to me more  
buggy ;)

Besides that, i never dare to do any spatial analysis within epsg 4326.



Greetz
Bernd

Am 18.10.2013, 21:13 Uhr, schrieb Steven Horner ste...@stevenhorner.com:


Hello,

I have been doing a project to calculate mountain viewsheds, basically
where a mountain summits can be seen from.

I have calculated the viewsheds and polygonized to Vector. So far so  
good,
but then I wanted to show which mountains could be seen from the summit  
of

other mountains I appear to have 2 problems.

1. I ran a spacial query to show how many mountains (Munros) are Within  
my

polgonized viewshed. This returns the Munros. Unfortunately I get a
different number in QGIS 1.8 to QGIS 2.0.1, I don't know which is true

2. I had saved my Viewshed originally as a shapefile with a CRS of 27700
(British National Grid), I saved a version as GeoJSON with CRS of 4326.  
If

I run the same spacial query on this file I get a different number of
Munros again.

So I now have 4 different figures from what I would have expected to be
identical.

Is data lost when a shapefile is saved as a GeoJSON file in a different  
CRS?

and which should I beleive 1.8 or 2.0.1 or neither?

If anyone wants to test this you can download the files here:
Viewshed  
Shapefilehttps://dl.dropboxusercontent.com/u/2657852/AmBodach_shp.zip-

CRS of 27700
Viewshed  
GeoJSONhttps://dl.dropboxusercontent.com/u/2657852/AmBodach_geojson.zip-

Converted fromthe above but with CRS of 4326
Munros Shapefile  
https://dl.dropboxusercontent.com/u/2657852/Munros.zip -

CRS of 27700

Wish I had realised there was something wrong before I had calculated 200
of these.

Thanks,
Steven



--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] error on start up

[Bernd Vogelgesang]

Same error here on 2.1 from ubuntu-unstable.

But it's not only throwing an error, but Processing is also marked as  
invalid and therefore unusable.


Cheers
Bernd

Am 25.09.2013, 14:59 Uhr, schrieb Tim Sutton li...@linfiniti.com:


HI

I get the same here too...

Regards

Tim


On Wed, Sep 25, 2013 at 10:10 AM, Ziegler Stefan  
stefan.zieg...@bd.so.chwrote:



Hi

With today's master I get some errors when starting QGIS:

from processing.lidar.lastools.LAStoolsAlgorithm import
LAStoolsAlgorithm
  File /home/stefan/Apps/qgis_master/share/qgis/python/qgis/utils.py,
line 453, in _import
mod = _builtin_import(name, globals, locals, fromlist, level)
ImportError: No module named LAStoolsAlgorithm

Python-Version:
2.7.4 (default, Apr 19 2013, 18:30:41)
[GCC 4.7.3]


QGIS-Version:
2.1.0-Master Master, bb63eb1

Same with LAStoolsUtils.

I'm on Ubuntu 13.04.

Regards
Stefan

Freundliche Grüsse
Stefan Ziegler
Leiter amtliche Vermessung

Amt für Geoinformation
Amtliche Vermessung
Rötistrasse 4
4500 Solothurn

Telefon +41 32 627 75 96
Telefax +41 32 627 75 98
stefan.zieg...@bd.so.ch
http://www.so.ch


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








--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How to install properly Processing Plugin QGIS 2.0.1 in Ubuntu?

[Bernd Vogelgesang]

Had the same problem with Linux Mint 14.
Your .qgis2 folder is owned by root after installation, so you have to  
give ownership back to your user for the folder/subfolders and files.




Am 24.09.2013, 10:58 Uhr, schrieb Noli Sicad nsi...@gmail.com:


I got this error in Opening QGIS 2.0.1 in Ubuntu (13,04) raring.

[ERROR] Can not make qgis.db private copy

How do you fix this error?

Thanks, Noli


On 9/24/13, Noli Sicad nsi...@gmail.com wrote:

Hi Victor,

I got a red letter in Processing Plugin in Ubuntu (13.04) raring
(external hard drive in Macbookpro Retina).

How do I install Processing Plugin properly in Ubuntu?

What packages needed for this Processing Plugin to work in Ubuntu?

Thanks.

Regards, Noli


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



--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New website

[Bernd Vogelgesang]

I can only confirm Alexandres opinion.
In fact, i gave up using qgis.org as a starting point for anything, but  
directly use google search for navigation cause i will get lost anyway.  
And i think i'm already quite experienced within the qgis ecosystem ...  
but newbies?



I think we should have a website as lean and clean as possible,
leaving more dynamic stuff to other media, and making it easier to
translate and maintain it.
This is a proposal.


What is more dynamic stuff? An example for me would be announcements on  
news or changes from core developers or plugin authors. And only a per  
mille of the user subscribe to or read the mailing lists where those infos  
could be available. Would love to see such things on the start page and  
not buried within any outsourced system. I bet this would downsize a lot  
of user requests.


Am 11.04.2013, 12:50 Uhr, schrieb Alexandre Neto senhor.n...@gmail.com:

Not being a developer, and not being able to help that much, please  
forgive

my intrusion, But I would like to give my opinion regarding the Website.

I might be also late to this discussion, but, As a user, one thing I find
quite disconcerting in qgis.org page is the fact that almost every menu
item send you to different site\page, breaking with the original layout  
and

making it difficult to navigate in the site.

Therefore, IMHO, I think outside links should open a new browser tab
instead of redirect the user to a new site.

Alexandre Neto


On Thu, Apr 11, 2013 at 9:07 AM, Paolo Cavallini  
cavall...@faunalia.itwrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.
I think we should have a website as lean and clean as possible,
leaving more dynamic stuff to other media, and making it easier to
translate and maintain it.
This is a proposal.

===
Home page
[add main features, qgis server, web clients]
===
* Download
* Plugins
* Manuals
* Sponsorship
* Case studies
* Commercial support
* Planet
* Bugtracker
* Contacts [includes Community]
   * Mailing lists
   * Chat
   * Stackexchange
   * local user groups (list, with links to their pages)
   * user meetings
   * developer meetings
   * conferences (upcoming events)
   * polls (probably we cannot do it in our new structure, and we'll
have to use an external resource)
-  
-


This have been discussed several times, and I think we all agreed on it.
So if there is no further objection, let's start.
I'd appreciate if someone could take the responsibility for one or
more pages.
I'm going to work on git.

Thanks.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFmby4ACgkQ/NedwLUzIr6i8QCgu6Lq4rcviSMw+M6myBp9iONa
S6kAnA3UhwmJF+4kghsk180m+AmBkYd+
=/+Oj
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer




--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Get rid of Shapefiles ! Go SpatiaLite !

[Bernd Vogelgesang]

Am 27.11.2012, 08:20 Uhr, schrieb Paolo Cavallini cavall...@faunalia.it:


On Mon, 26 Nov 2012 23:56:30 +0100, Bernd Vogelgesang
bernd.vogelges...@gmx.de wrote:


You just should not use Qspatialite to import shapes. I nearly gave up
upon spatialite, when i figured out that i had to use the Spatialite GUI



instead and this was fast as hell.


Why not using DB Manager?


Well, i can't figure out for what i can use it in my workflow other than  
loading a layer into Qgis.





So at the moment, you have to work with Spatialite GUI to import shapes,



I do not think users like to switch between different programs.


Indeed! I do not like it either, but this gives the best results so far  
(and the only results when i work with bigger datasets). Thats why  
improved spatialite support (in whatever way) would be really much  
appreciated.


greetz
Bernd



All the best.



--
Bernd Vogelgesang * Siedlerstrasse 2 * 91083 Baiersdorf * +49-9133-825374
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer