Re: [QGIS-Developer] Woohoo! Interactive Travis debugging

[Alessandro Pasotti]

Hi Nyall,

thanks for this useful information!

Do we have a place to store it? Developer docs maybe?



On Fri, Oct 12, 2018 at 1:20 AM Nyall Dawson  wrote:

> On Tue, 9 Oct 2018 at 19:18, Nyall Dawson  wrote:
> >
> > Hey all,
>
> >
> > #! /usr/bin/env bash
> >   curl -s -X POST \
> >-H "Content-Type: application/json" \
> >-H "Accept: application/json" \
> >-H "Travis-API-Version: 3" \
> >-H "Authorization: token " \
> >-d '{ "quiet": true }' \
> >https://api.travis-ci.org/job//debug
> >
>
>
> Just a follow up here. Turns out the default configuration (shown
> above) is limited to a 30 minute timeout, which isn't enough to get
> all the dependencies installed and QGIS built, let alone leaving time
> for debugging ;)
>
> After some discussion with Travis staff (who have been fantastic, I've
> got to say!), there's a workaround. By changing "quiet": true to
> "quiet": false, the interactive session is subject to the normal 90(+)
> minute timeout. The side effect is that all the commands entered are
> visible to anyone looking at the Travis log, so be careful not to do
> this with any sensitive information.
>
> The command is full is:
>
> #! /usr/bin/env bash
>   curl -s -X POST \
>-H "Content-Type: application/json" \
>-H "Accept: application/json" \
>-H "Travis-API-Version: 3" \
>-H "Authorization: token " \
>-d '{ "quiet": false }' \
>https://api.travis-ci.org/job//debug
>
>
> Nyall
>
>
> > The Job ID is displayed in the build log after expanding "Build system
> > information".
> >
> > 2. Head back to the web UI and in the log of your job. There you
> > should see the following lines to connect to the VM:
> >
> > Setting up debug tools.
> > Preparing debug sessions.
> > Use the following SSH command to access the interactive debugging
> environment:
> > ssh ukjiucekxbbnrae32y8xch...@ny2.tmate.io
> >
> > 3. Connect from your computer using SSH into the interactive session,
> > and once you're done, just type exit and your build will terminate.
> >
> > Once in the SSH session, these bash functions will come in handy to
> > run the different phases in your build:
> >
> https://docs.travis-ci.com/user/running-build-in-debug-mode/#Things-to-do-once-you-are-inside-the-debug-VM
> ___
> 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



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] open atlas layout, using python

[Nyall Dawson]

On Fri, 12 Oct 2018 at 02:22, Raymond Nijssen  wrote:
>
> By the way, the fragile code solution does not work for me. It does
> toggle the button but it does not activate the atlas preview.

Ok - I've done the proper approach in
https://github.com/qgis/QGIS/pull/8170/files

(I've also exposed an API call to show the item properties for a
particular item)

Let me know if there's anything else you think should be exposed from
the designer to the designer API.


Nyall

>
> # open layout
> designer = iface.openLayoutDesigner(layout)
>
> # turn on atlas preview mode
> lo_view = designer.view()
> lo_window = lo_view.window()
> action = lo_window.findChild(QAction, 'mActionAtlasPreview')
> action.toggle()
>
>
> On 11-10-18 16:51, Raymond Nijssen wrote:
> > Hi Nyall,
> >
> > It sounded great and I spent some hours on that better approach, but I
> > didn't succeed. So maybe 3.6 will have it...
> >
> > Tnx!
> > Raymond
> >
> >
> > On 25-09-18 23:57, Nyall Dawson wrote:
> >> On Tue, 25 Sep 2018 at 22:36, Raymond Nijssen 
> >> wrote:
> >>>
> >>> 1. Can I open a layout window with a python command?
> >>
> >> designer = iface.openLayoutDesigner( layout )
> >>
> >>> 2. Can I turn on "atlas preview" with a python command?
> >>
> >> You'd have to do some fragile code to do this. Basically:
> >>
> >> - get designer window from designer.view()'s parent window
> >> - find the mActionAtlasPreview child action in the window
> >> - manually toggle it on
> >>
> >> This should work, but isn't stable API - so is likely to break ;)
> >>
> >> A better approach is to (quickly, before 3.4 final!) file a PR
> >> exposing the toggle atlas preview behavior to
> >> QgsLayoutDesignerInterface. Then you'll be able to just do:
> >>
> >> designer = iface.openLayoutDesigner( layout )
> >> designer.toggleAtlasPreview( True )
> >>
> >> Nyall
> >>
> >>
> >> Hope anyone knows!
> >>>
> >>> Kind regards,
> >>> Raymond
> >>>
> >>> ___
> >>> 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] Woohoo! Interactive Travis debugging

[Nyall Dawson]

On Tue, 9 Oct 2018 at 19:18, Nyall Dawson  wrote:
>
> Hey all,

>
> #! /usr/bin/env bash
>   curl -s -X POST \
>-H "Content-Type: application/json" \
>-H "Accept: application/json" \
>-H "Travis-API-Version: 3" \
>-H "Authorization: token " \
>-d '{ "quiet": true }' \
>https://api.travis-ci.org/job//debug
>


Just a follow up here. Turns out the default configuration (shown
above) is limited to a 30 minute timeout, which isn't enough to get
all the dependencies installed and QGIS built, let alone leaving time
for debugging ;)

After some discussion with Travis staff (who have been fantastic, I've
got to say!), there's a workaround. By changing "quiet": true to
"quiet": false, the interactive session is subject to the normal 90(+)
minute timeout. The side effect is that all the commands entered are
visible to anyone looking at the Travis log, so be careful not to do
this with any sensitive information.

The command is full is:

#! /usr/bin/env bash
  curl -s -X POST \
   -H "Content-Type: application/json" \
   -H "Accept: application/json" \
   -H "Travis-API-Version: 3" \
   -H "Authorization: token " \
   -d '{ "quiet": false }' \
   https://api.travis-ci.org/job//debug


Nyall


> The Job ID is displayed in the build log after expanding "Build system
> information".
>
> 2. Head back to the web UI and in the log of your job. There you
> should see the following lines to connect to the VM:
>
> Setting up debug tools.
> Preparing debug sessions.
> Use the following SSH command to access the interactive debugging environment:
> ssh ukjiucekxbbnrae32y8xch...@ny2.tmate.io
>
> 3. Connect from your computer using SSH into the interactive session,
> and once you're done, just type exit and your build will terminate.
>
> Once in the SSH session, these bash functions will come in handy to
> run the different phases in your build:
> https://docs.travis-ci.com/user/running-build-in-debug-mode/#Things-to-do-once-you-are-inside-the-debug-VM
___
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] Plugin [1412] GeoDataFarm approval notification.

[noreply]

Plugin GeoDataFarm approval by pcav.
The plugin version "[1412] GeoDataFarm 2.0.0" is now approved
Link: http://plugins.qgis.org/plugins/geodatafarm/
___
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

[Even Rouault]

> This makes me wonder when we could start using this in QGIS - I am
> afraid we will have to wait for some time until it is all out in a
> stable Proj release and adopted by major distributions, which may take
> quite some time... (a year?)

Yes, likely. PROJ 6 is scheduled for February 2019. GDAL 2.4 for May

> Pretty much. Looking at the grid support, I see that the OSTN15
> transformation is listed there in the grid_transformation table, but
> we would also need an entry in grid_alternatives table for it +
> include it in a future release of proj-datumgrid-europe package (that
> particular grid is BSD licensed, so it should be fine).

Yes, https://github.com/OSGeo/proj-datumgrid/issues/21

> 
> Regarding contents of proj.db table, will it be acceptable for apps
> like QGIS to browse its contents or should it be considered as Proj
> library's implementation detail and any queries to it should go
> through Proj API?

Well QGIS could do it, but there's the risk that the DB structure might change 
at some point.

> I am thinking it would be nice to automatically
> determine grid packages for missing grid files and to download them in
> QGIS if the users wants. 

I've anticipated that need.

In the PROJ API, there will be a function to list all potential 
transformations from CRS A to CRS B, independently of the availability of 
grids

PJ_OPERATION_RESULT PROJ_DLL *proj_obj_create_operations(
PJ_OBJ* source_crs,
PJ_OBJ* target_crs,
PJ_OPERATION_FACTORY_CONTEXT* operationContext);

and then you can iterate over the potential operations returned, and ask for 
each operation, which grids are needed, and if they are available, and if not, 
where you can find them:

int PROJ_DLL proj_coordoperation_get_grid_used_count(PJ_OBJ* coordoperation);

int PROJ_DLL proj_coordoperation_get_grid_used(PJ_OBJ* coordoperation,
   int index,
   const char** pShortName,
   const char** pFullName,
   const char** pPackageName,
   const char** pPackageURL,
   int* pAvailable);


> Another question is what to do with grids
> with license that does not allow redistribution - should we have
> entries with URL in grid_transformation table for such grid files as
> well? (maybe with a flag that it is not direct link to a package, just
> a web page about that grid)

I guess grid_alternatives could receive additional columns, which would be 
used if package_name is NULL, perhaps something like:

open_license BOOLEAN
download_url TEXT
direct_download BOOLEAN

Putting that in my TODO list

> 
> One final thought - how about customization of proj.db by ordinary
> users? In QGIS users are allowed to define their custom CRS based on
> Proj string - is something like that going to be supported?

The issue is that a PROJ string is a rather low expressive way of defining a 
CRS, but yes that something I've in a corner of my mind, to allow defining 
custom CRS entries by PROJ strings or WKT strings, without going to the full 
relational structure.

> E.g. to
> have system proj.db and user proj.db with customizations?

That's another issue. An easy solution would be to copy the system proj.db in 
a editable location and point PROJ_LIB to it

Having both at the same time is more tricky. For example if you add custom 
transformations in the user proj.db between official CRS of the system 
proj.db, you'd have an issue with broken foreign keys, so the user proj.db 
shouldn't enforce foreign keys.
and then PROJ could potentially create a in-memory database, that would ATTACH 
DATABASE the official and custom one, and for every table, create a temporary 
view that UNION ALL the tables of both dbs. Then that would be transparent for 
the rest of the code that does database queries.
I might consider doing this, but this is not a top priority for now.


Thanks for your valuable feedback on this !


Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.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

Re: [QGIS-Developer] Dealing with datum shift grids in QGIS

[Kristian Evers]

On 11 Oct 2018, at 18:55, Martin Dobias 
mailto:wonder...@gmail.com>> wrote:

Regarding contents of proj.db table, will it be acceptable for apps
like QGIS to browse its contents or should it be considered as Proj
library's implementation detail and any queries to it should go
through Proj API? I am thinking it would be nice to automatically
determine grid packages for missing grid files and to download them in
QGIS if the users wants. Another question is what to do with grids
with license that does not allow redistribution - should we have
entries with URL in grid_transformation table for such grid files as
well? (maybe with a flag that it is not direct link to a package, just
a web page about that grid)

Some time ago Even and I briefly discussed the possibility of having
PROJ offer a direct link to grids that are needed for a transformation
but not available on the system. This should let apps like QGIS deal
with grids quite smoothly I think.

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

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

Re: [QGIS-Developer] Dealing with datum shift grids in QGIS

[Martin Dobias]

Hi Even

On Thu, Oct 11, 2018 at 5:31 PM Even Rouault  wrote:
>
> It seems you want to have a read at my yesterday-written RFC:
> https://github.com/OSGeo/proj.4/pull/1149
>
> Particularly the part concerning the database:
> http://even.rouault.free.fr/proj_cpp_api/rfc-2.html#database
>
> and the data/sql/ files mentionne at
>
> http://even.rouault.free.fr/proj_cpp_api/rfc-2.html#impacted-files

Just read through all that. Amazing work.

This makes me wonder when we could start using this in QGIS - I am
afraid we will have to wait for some time until it is all out in a
stable Proj release and adopted by major distributions, which may take
quite some time... (a year?)


> > My suggestions for Proj:
> > 1. it should be possible to specify multiple data directories with
> > PROJ_LIB env variable, so that it is possible to use grids also from
> > user's home directory (not just the read-only system directory)
>
> That's an interesting idea. Could you file a ticket to
> https://github.com/OSGeo/proj.4/issues about that ?

Done: https://github.com/OSGeo/proj.4/issues/1150


> > 2. there could be a database similar to datum_shift.csv [2] that would
> > list well known datum shift grid files, so that QGIS does not need to
> > maintain its database and just pull that information out of Proj -
> > other projects could benefit from that as well.
>
> Sounds very much like:
>
> https://github.com/rouault/proj.4/blob/iso19111/data/sql/grid_alternatives.sql

Pretty much. Looking at the grid support, I see that the OSTN15
transformation is listed there in the grid_transformation table, but
we would also need an entry in grid_alternatives table for it +
include it in a future release of proj-datumgrid-europe package (that
particular grid is BSD licensed, so it should be fine).

Regarding contents of proj.db table, will it be acceptable for apps
like QGIS to browse its contents or should it be considered as Proj
library's implementation detail and any queries to it should go
through Proj API? I am thinking it would be nice to automatically
determine grid packages for missing grid files and to download them in
QGIS if the users wants. Another question is what to do with grids
with license that does not allow redistribution - should we have
entries with URL in grid_transformation table for such grid files as
well? (maybe with a flag that it is not direct link to a package, just
a web page about that grid)

One final thought - how about customization of proj.db by ordinary
users? In QGIS users are allowed to define their custom CRS based on
Proj string - is something like that going to be supported? E.g. to
have system proj.db and user proj.db with customizations?


> It would be good if we could utlimately get rid of QGIS srs.db and just use
> the future PROJ proj.db that could be used by the whole PROJ/GDAL/QGIS stack

That would be absolutely wonderful and I am looking forward to that day :-)

Cheers
Martin
___
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] open atlas layout, using python

[Raymond Nijssen]

By the way, the fragile code solution does not work for me. It does 
toggle the button but it does not activate the atlas preview.


# open layout
designer = iface.openLayoutDesigner(layout)

# turn on atlas preview mode
lo_view = designer.view()
lo_window = lo_view.window()
action = lo_window.findChild(QAction, 'mActionAtlasPreview')
action.toggle()


On 11-10-18 16:51, Raymond Nijssen wrote:

Hi Nyall,

It sounded great and I spent some hours on that better approach, but I 
didn't succeed. So maybe 3.6 will have it...


Tnx!
Raymond


On 25-09-18 23:57, Nyall Dawson wrote:
On Tue, 25 Sep 2018 at 22:36, Raymond Nijssen  
wrote:


1. Can I open a layout window with a python command?


designer = iface.openLayoutDesigner( layout )


2. Can I turn on "atlas preview" with a python command?


You'd have to do some fragile code to do this. Basically:

- get designer window from designer.view()'s parent window
- find the mActionAtlasPreview child action in the window
- manually toggle it on

This should work, but isn't stable API - so is likely to break ;)

A better approach is to (quickly, before 3.4 final!) file a PR
exposing the toggle atlas preview behavior to
QgsLayoutDesignerInterface. Then you'll be able to just do:

designer = iface.openLayoutDesigner( layout )
designer.toggleAtlasPreview( True )

Nyall


Hope anyone knows!


Kind regards,
Raymond

___
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

[Giovanni Manghi]

Hi Martin,

> I understand that it is hard to ship datum shift grids with QGIS due
> to various issues (their size and amount, sometimes licensing) and
> that's fine. But we should think about how to make it easier to use
> them. There is a QGIS plugin [1] that provides a set of algs for
> Processing that call ogr2ogr with the right grid files and download
> them if they are not yet available - however there is no integration
> with QGIS CRS database, so any other transforms inside QGIS can't make
> use of that.

I will personally port the plugin to QGIS 3 as soon as I can and
continue to make it available (I could even make a PR and propose it
as a tool that comes out of the box with Processing), this because
anyway has proven a valuable tool for less advanced users that are in
the situation to create copies of their data with a new CRS and with a
datum transformation involved.

Other than this anything that makes easier handling datum
transformations in QGIS is welcome.

Cheers!

-- G --
___
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 [1546] imajnet-qgis-plugin approval notification.

[Paolo Cavallini]

Fixed now.

Thanks again.

===

They have been changed after approval.

Unapproved now.

Thanks for letting me know.


Il 10/11/2018 04:47 PM, Etienne Trimaille ha scritto:
> Hi,
>
> Both the code repository link and the bug tracker link are good. They
> redirect to the main compagny website. Is the code available
> somewhere? Where is the bug tracker?
>
> Le mer. 10 oct. 2018 à 04:13,  > a écrit :
>
>
> Plugin imajnet-qgis-plugin approval by pcav.
> The plugin version "[1546] imajnet-qgis-plugin 1.0.0 Experimental"
> is now approved
> Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
> ___
> 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

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/

___
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] Plugin [1546] Imajnet QGIS Plugin approval notification.

[noreply]

Plugin Imajnet QGIS Plugin approval by pcav.
The plugin version "[1546] Imajnet QGIS Plugin 1.0.0 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
___
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] Plugin [1546] Imajnet QGIS Plugin approval notification.

[noreply]

Plugin Imajnet QGIS Plugin approval by pcav.
The plugin version "[1546] Imajnet QGIS Plugin 1.0.1" is now approved
Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
___
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

[Even Rouault]

Martin,

It seems you want to have a read at my yesterday-written RFC:
https://github.com/OSGeo/proj.4/pull/1149

Particularly the part concerning the database:
http://even.rouault.free.fr/proj_cpp_api/rfc-2.html#database

and the data/sql/ files mentionne at

http://even.rouault.free.fr/proj_cpp_api/rfc-2.html#impacted-files

> 
> My suggestions for Proj:
> 1. it should be possible to specify multiple data directories with
> PROJ_LIB env variable, so that it is possible to use grids also from
> user's home directory (not just the read-only system directory)

That's an interesting idea. Could you file a ticket to
https://github.com/OSGeo/proj.4/issues about that ?


> 2. there could be a database similar to datum_shift.csv [2] that would
> list well known datum shift grid files, so that QGIS does not need to
> maintain its database and just pull that information out of Proj -
> other projects could benefit from that as well.

Sounds very much like:

https://github.com/rouault/proj.4/blob/iso19111/data/sql/grid_alternatives.sql


It would be good if we could utlimately get rid of QGIS srs.db and just use 
the future PROJ proj.db that could be used by the whole PROJ/GDAL/QGIS stack


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.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] Dealing with datum shift grids in QGIS

[Martin Dobias]

Hi all

Recently I needed transformation between points from high-accuracy GPS
to British National Grid (EPSG:27700) which involves datum shift (WGS
84 to OSGB 1936) using OSTN15 grid.

The process to do that with QGIS is currently... well... really
clumsy. One needs to:
1. manually download grids from the web and extract .gsb file to Proj
data directory
2. manually add an entry to tbl_datum_transform table in srs.db in
QGIS installation

There are two main problems with that:
- both steps need adjustment of QGIS installation - not everyone has
admin privileges
- doing manual changes to srs.db is just too much to ask from ordinary user

I understand that it is hard to ship datum shift grids with QGIS due
to various issues (their size and amount, sometimes licensing) and
that's fine. But we should think about how to make it easier to use
them. There is a QGIS plugin [1] that provides a set of algs for
Processing that call ogr2ogr with the right grid files and download
them if they are not yet available - however there is no integration
with QGIS CRS database, so any other transforms inside QGIS can't make
use of that.

Note for those not familiar with srs.db: it is a sqlite3 db living in
QGIS source code which has been generated at some point from GDAL data
files. Over time it has gathered some manual ad-hoc updates of
parameters. Then upon QGIS build/installation we run "crssync" utility
to parse current GDAL data files again and update/insert CRS and datum
shift parameters (see QgsCoordinateReferenceSystem::syncDatabase()).

My suggestions for QGIS:
1. any manual additions to srs.db should be listed as SQL commands
because it is difficult to track changes to srs.db which is a binary
blob (sqlite db). During the build of QGIS we would create final
srs.db
2. rather than manually adding entries about datum shift grids to
tbl_datum_transform table (which is generated from GDAL's
datum_shift.csv [2]) and contains parameters of 3/7 parameter
transform between datums, there should be a new table just for grid
files, ideally with links where they can be downloaded. (fun fact:
names of grid files in tbl_datum_transform table are stored in a
numeric column but because this is sqlite it just works)
3. it should be possible to add custom entries about datum shift grids
by users (just like it is possible to add custom CRS) - that is, such
table should be also in user's profile (in qgis.db)

My suggestions for Proj:
1. it should be possible to specify multiple data directories with
PROJ_LIB env variable, so that it is possible to use grids also from
user's home directory (not just the read-only system directory)
2. there could be a database similar to datum_shift.csv [2] that would
list well known datum shift grid files, so that QGIS does not need to
maintain its database and just pull that information out of Proj -
other projects could benefit from that as well.

I am aware of the fact that there is a big refactoring in Proj going
on [3] but I am not sure if any of the above suggestions are also in
the plans...

I would be happy to help implementing some of the above, but I would
like to first hear opinion of others - maybe I got something wrong and
maybe there are better ways to move forward. I hope gurus like
Kristian or Even read this and can offer some of their wisdom too :-)

Cheers
Martin

[1] https://github.com/NaturalGIS/naturalgis_ntv2_transformations
[2] https://github.com/OSGeo/gdal/blob/master/gdal/data/datum_shift.csv
[3] https://gdalbarn.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

Re: [QGIS-Developer] Plugin [1546] imajnet-qgis-plugin approval notification.

[Paolo Cavallini]

They have been changed after approval.

Unapproved now.

Thanks for letting me know.


Il 10/11/2018 04:47 PM, Etienne Trimaille ha scritto:
> Hi,
>
> Both the code repository link and the bug tracker link are good. They
> redirect to the main compagny website. Is the code available
> somewhere? Where is the bug tracker?
>
> Le mer. 10 oct. 2018 à 04:13,  > a écrit :
>
>
> Plugin imajnet-qgis-plugin approval by pcav.
> The plugin version "[1546] imajnet-qgis-plugin 1.0.0 Experimental"
> is now approved
> Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
> ___
> 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

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/

___
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] open atlas layout, using python

[Raymond Nijssen]

Hi Nyall,

It sounded great and I spent some hours on that better approach, but I 
didn't succeed. So maybe 3.6 will have it...


Tnx!
Raymond


On 25-09-18 23:57, Nyall Dawson wrote:

On Tue, 25 Sep 2018 at 22:36, Raymond Nijssen  wrote:


1. Can I open a layout window with a python command?


designer = iface.openLayoutDesigner( layout )


2. Can I turn on "atlas preview" with a python command?


You'd have to do some fragile code to do this. Basically:

- get designer window from designer.view()'s parent window
- find the mActionAtlasPreview child action in the window
- manually toggle it on

This should work, but isn't stable API - so is likely to break ;)

A better approach is to (quickly, before 3.4 final!) file a PR
exposing the toggle atlas preview behavior to
QgsLayoutDesignerInterface. Then you'll be able to just do:

designer = iface.openLayoutDesigner( layout )
designer.toggleAtlasPreview( True )

Nyall


Hope anyone knows!


Kind regards,
Raymond

___
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




--
Terglobo
Fahrenheitstraat 1
5223 BJ 's-Hertogenbosch
The Netherlands
+31 (0) 6 25 31 49 83
___
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] Plugin [1546] Imajnet QGIS Plugin unapproval notification.

[noreply]

Plugin Imajnet QGIS Plugin unapproval by pcav.
The plugin version "[1546] Imajnet QGIS Plugin 1.0.0 Experimental" is now 
unapproved
Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
___
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] Plugin [1546] Imajnet QGIS Plugin approval notification.

[noreply]

Plugin Imajnet QGIS Plugin approval by pcav.
The plugin version "[1546] Imajnet QGIS Plugin 1.0.1" is now unapproved
Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
___
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 [1546] imajnet-qgis-plugin approval notification.

[Etienne Trimaille]

Hi,

Both the code repository link and the bug tracker link are good. They
redirect to the main compagny website. Is the code available somewhere?
Where is the bug tracker?

Le mer. 10 oct. 2018 à 04:13,  a écrit :

>
> Plugin imajnet-qgis-plugin approval by pcav.
> The plugin version "[1546] imajnet-qgis-plugin 1.0.0 Experimental" is now
> approved
> Link: http://plugins.qgis.org/plugins/imajnet-qgis-plugin/
> ___
> 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] Error with hdf5.dll on Windows build.

[Jürgen E . Fischer]

Hi Nathan,

On Mon, 01. Oct 2018 at 20:23:42 +1000, Nathan Woodrow wrote:
> This is on 32bit but really I should setup a 64bit build and that might fix
> the issue, plus I really should do that anyway.
 
> For now I will just override the path in cmake like Martin said just so I
> can finish this task off while I setup my 64bit build.

I've just hit this on an old vm that still had CMake 3.7.1 - upgrading to 3.12
fixed this (but I guess 3.8 would also have been new enough).


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


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] Vocabulary learning: Dissolve vs Merge

[domlysz]

Also there is the new aggregate processing tool that do exactly the same task
than dissolve but with much more powerfull options !

Regards

Dominique



--
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] Vocabulary learning: Dissolve vs Merge

[DelazJ]

Hi,

In QGIS, there's the "Dissolve" algorithm [1] and in the advanced
digitizing tools, there's the "Merge selected features" [2]. Both afaics do
the same thing: replace input features by a single one whose geometry
represents the combination of their geometries. No statistics is performed
by default though the digitizing tool gives these options.

Questions:
* Why using two different words, making it hard for those not getting the
subtleties either to describe these features (trying to avoid the reuse of
the other word) and to translate them?
* Are there differences between these terms (and their effects) I'd have
missed?
* Any chance of homogenisation?

[1]
https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/vectorgeometry.html#dissolve
[2]
https://docs.qgis.org/testing/en/docs/user_manual/working_with_vector/editing_geometry_attributes.html#merge-selected-features

Regards,
Harrissou
___
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