Re: [QGIS-Developer] [Qgis-developer] Adding default OSM backround maps

[Richard Duivenvoorde]

On 20-06-17 23:14, Stéphane Henriod wrote:
> Hi all
> 
> in the last 3 weeks there hasn't been any contribution on this QEP or in
> the Google Doc. Should I assume that it hasn't raised lots attention
> because it is not seen as a priority feature? In this case, I guess we
> can remove the QEP (or change its status to "Postponed")
> 
> Or is it just that everybody is overloaded with other tasks but still
> thinks this feature would be pretty damn cool? :-)

Hi,

just my 2 ct (and talking about myself: yep, busy too).

It is a LOT of work, both styling and running an open server hosting
world data in a custom style. You need also quite a lot
cpu/disk/connection resources for it to perform well.

So somebody needs to put time/resources in it, AND take responsibility
to keep it run smoothly...

So I would stick with OSM tiles for now (or some other local/open tile
servers), and maybe start yourself with the styling/hosting of a smaller
part of the world, share that map and see if that makes people eager to
see more :-)

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] [Qgis-developer] Adding default OSM backround maps

[Nathan Woodrow]

Hey,

I think most of us are pretty busy just with the ramp up to 3.0. The idea
is fine however the proposal requires hosting map tiles, which may come at
a large cost if hit hard.  I think your best bet is to follow leads on that
front first, if you can get someone to step up to host the tiles then maybe
we can get it off the ground, I suspect we don't have the server capcatity
at qgis.org (could be wrong).  I'm also not sure we want to turn into a
tile provider yet given we already have enough on.

Regards,
Nathan

On Wed, Jun 21, 2017 at 7:14 AM, Stéphane Henriod 
wrote:

> Hi all
>
> in the last 3 weeks there hasn't been any contribution on this QEP or in
> the Google Doc. Should I assume that it hasn't raised lots attention
> because it is not seen as a priority feature? In this case, I guess we can
> remove the QEP (or change its status to "Postponed")
>
> Or is it just that everybody is overloaded with other tasks but still
> thinks this feature would be pretty damn cool? :-)
>
> Thanks and cheers
> Stéphane
>
>
> Le mardi 6 juin 2017, Stéphane Henriod  a écrit :
>
>> As recommended by Jorge, I just opened a QEP: https://github.com/qgis/Q
>> GIS-Enhancement-Proposals/issues/94
>>
>> But I would still suggest to keep the discussion on the Gdoc. I think
>> it's a more flexible place for brainstorming. If we get some kind of
>> consensus there, then I will fill up the QEP with more detailed info.
>>
>> Would that be ok? (first time I open a QEP, so not quite sure about the
>> usual procedures and etiquette)
>>
>> Cheers
>> Stéphane
>>
>> Le mardi 6 juin 2017, Stéphane Henriod  a écrit :
>>
>>> Hi again
>>>
>>> if some are with me on this, let's try to work first on general
>>> requirements. Then we can assess, I guess, relatively soon if this is
>>> realistic or not.
>>>
>>> I started to brainstorm here: https://docs.google.com/
>>> document/d/1f1OJtshHCPcLVEVqZjTEgI47zn61Plv5I-Yc68d2b64/edit?usp=sharing
>>>
>>> Thanks and cheers
>>> Stéphane
>>>
>>>
>>> Le mardi 6 juin 2017, Jorge Gustavo Rocha  a écrit :
>>>
 Hi Stéphane,

 Your suggestion may complement or be an alternative to the default OSM
 background maps.

 Regarding the implementation of the initial proposal, it is not
 difficult and have been done in PR#4352. It is basically one button to
 add another layer to the map.

 Creating a new vector tile service, provided by QGIS, seems quite more
 difficult to me. We need to maintain a mirror of the planet. This means
 a lot of resources (hw and ops).

 Developing one style is not difficult but one that everybody likes is
 much more difficult. We would end up as OSM did, with several styles,
 for different users. But if the render is on the client side, there is
 no problem to maintain more than one style.

 In summary, providing the tile service seems more complicated to me, but
 this can be further explored. If you would like to try it, I can help.

 Regards,

 Jorge Gustavo


 Às 10:57 de 06-06-2017, Stéphane Henriod escreveu:
 > Hi all
 >
 > jumping (a bit late) on this...
 >
 > I realize that this would be much heavier and much more expensive to
 > implement but what about developing a "QGIS style" for OSM-based tiles
 > (that could, e.g., be hosted on QGIS.org)? That would take care of 3
 issues:
 >
 >   * "Quality of the cartography": if we are not 100% happy with the
 > default OSM style as a background map, we could come up with a
 more
 > appropriate style
 >   * "Quality of the service":  there is a risk that OSMF once shuts
 down
 > the service because we generate too much traffic. If "we" host the
 > tiles ourselves, the risks and associated decisions remain in
 "our"
 > hands
 >   * "Frequency of updates": same, if it lies in "our" hands, we can
 > define ourselves what frequency would be appropriate
 >
 > I assume that developing a new style is not a huge task (there are
 > probably enough people around with the necessary skills) and could be
 > achieved either with a "small" budget or with sufficient participation
 > of the community. But the long-term maintenance and hosting / serving
 of
 > the tiles is probably an issue of a different magnitude...
 >
 > Would that idea be worth exploring further? Or do you think it is
 > completely not realistic ?
 >
 > Thanks and cheers
 > Stéphane
 >
 > Le lundi 1 mai 2017, Paolo Cavallini  > a écrit :
 >
 > Il 30/04/2017 19:28, Jorge Gustavo Rocha ha scritto:
 >
 > > I did a PR [1], very simple. This discussion is now about the
 best
 > > approach to handle all settings, in all platforms. I'm 

Re: [QGIS-Developer] Problem with "no Data value" with rasters when using the Layer Styling panel?

[Stéphane Henriod]

Hi all

Apparently, this has been confirmed as a bug. Is anyone willing / able to
take care of it?

Thanks a lot and cheers

Stéphane (who really feels sorry to raise such questions, while not being
able himself to actively contribute to the resolution of such bugs)


Le jeudi 1 juin 2017, Stéphane Henriod  a écrit :

> Hi again
>
> in doubt, I have opened a ticket here: https://issues.qgis.org/
> issues/16649
>
> Cheers
> Stéphane
>
>
> Le mardi 30 mai 2017, Stéphane Henriod  > a écrit :
>
>> PS: screencast to better explain the issue: https://vimeo.com/219467091
>>
>> Le mardi 30 mai 2017, Stéphane Henriod  a écrit :
>>
>>> Hi
>>>
>>> I am testing the layer styling panel (shortcut F7) with the latest
>>> Nightly build on the Ubuntu repositories.
>>>
>>> By default, the NoData value is -. If I add "10" as additional
>>> NoData value, nothing happens.
>>>
>>> If I do the same in the layer properties, then the expected behavior
>>> happens: all pixels with value "10" are not rendered.
>>>
>>> So it seems that the manually added NoData values in the Layer Styling
>>> Panel are not considered.
>>>
>>> Can someone else replicate this problem? Should I open a ticket?
>>>
>>> Cheers
>>> Stéphane
>>>
>>>
>>> --
>>>
>>> “When you travel, remember that a foreign country is not designed to
>>> make you comfortable. It is designed to make its own people comfortable."
>>> -- Clifton Fadiman
>>>
>>>
>>
>> --
>>
>> “When you travel, remember that a foreign country is not designed to make
>> you comfortable. It is designed to make its own people comfortable." --
>> Clifton Fadiman
>>
>>
>
> --
>
> “When you travel, remember that a foreign country is not designed to make
> you comfortable. It is designed to make its own people comfortable." --
> Clifton Fadiman
>
>

-- 

“When you travel, remember that a foreign country is not designed to make
you comfortable. It is designed to make its own people comfortable." --
Clifton Fadiman
___
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-developer] Adding default OSM backround maps

[Stéphane Henriod]

Hi all

in the last 3 weeks there hasn't been any contribution on this QEP or in
the Google Doc. Should I assume that it hasn't raised lots attention
because it is not seen as a priority feature? In this case, I guess we can
remove the QEP (or change its status to "Postponed")

Or is it just that everybody is overloaded with other tasks but still
thinks this feature would be pretty damn cool? :-)

Thanks and cheers
Stéphane


Le mardi 6 juin 2017, Stéphane Henriod  a écrit :

> As recommended by Jorge, I just opened a QEP: https://github.com/qgis/
> QGIS-Enhancement-Proposals/issues/94
>
> But I would still suggest to keep the discussion on the Gdoc. I think it's
> a more flexible place for brainstorming. If we get some kind of consensus
> there, then I will fill up the QEP with more detailed info.
>
> Would that be ok? (first time I open a QEP, so not quite sure about the
> usual procedures and etiquette)
>
> Cheers
> Stéphane
>
> Le mardi 6 juin 2017, Stéphane Henriod  > a écrit :
>
>> Hi again
>>
>> if some are with me on this, let's try to work first on general
>> requirements. Then we can assess, I guess, relatively soon if this is
>> realistic or not.
>>
>> I started to brainstorm here: https://docs.google.com/
>> document/d/1f1OJtshHCPcLVEVqZjTEgI47zn61Plv5I-Yc68d2b64/edit?usp=sharing
>>
>> Thanks and cheers
>> Stéphane
>>
>>
>> Le mardi 6 juin 2017, Jorge Gustavo Rocha  a écrit :
>>
>>> Hi Stéphane,
>>>
>>> Your suggestion may complement or be an alternative to the default OSM
>>> background maps.
>>>
>>> Regarding the implementation of the initial proposal, it is not
>>> difficult and have been done in PR#4352. It is basically one button to
>>> add another layer to the map.
>>>
>>> Creating a new vector tile service, provided by QGIS, seems quite more
>>> difficult to me. We need to maintain a mirror of the planet. This means
>>> a lot of resources (hw and ops).
>>>
>>> Developing one style is not difficult but one that everybody likes is
>>> much more difficult. We would end up as OSM did, with several styles,
>>> for different users. But if the render is on the client side, there is
>>> no problem to maintain more than one style.
>>>
>>> In summary, providing the tile service seems more complicated to me, but
>>> this can be further explored. If you would like to try it, I can help.
>>>
>>> Regards,
>>>
>>> Jorge Gustavo
>>>
>>>
>>> Às 10:57 de 06-06-2017, Stéphane Henriod escreveu:
>>> > Hi all
>>> >
>>> > jumping (a bit late) on this...
>>> >
>>> > I realize that this would be much heavier and much more expensive to
>>> > implement but what about developing a "QGIS style" for OSM-based tiles
>>> > (that could, e.g., be hosted on QGIS.org)? That would take care of 3
>>> issues:
>>> >
>>> >   * "Quality of the cartography": if we are not 100% happy with the
>>> > default OSM style as a background map, we could come up with a more
>>> > appropriate style
>>> >   * "Quality of the service":  there is a risk that OSMF once shuts
>>> down
>>> > the service because we generate too much traffic. If "we" host the
>>> > tiles ourselves, the risks and associated decisions remain in "our"
>>> > hands
>>> >   * "Frequency of updates": same, if it lies in "our" hands, we can
>>> > define ourselves what frequency would be appropriate
>>> >
>>> > I assume that developing a new style is not a huge task (there are
>>> > probably enough people around with the necessary skills) and could be
>>> > achieved either with a "small" budget or with sufficient participation
>>> > of the community. But the long-term maintenance and hosting / serving
>>> of
>>> > the tiles is probably an issue of a different magnitude...
>>> >
>>> > Would that idea be worth exploring further? Or do you think it is
>>> > completely not realistic ?
>>> >
>>> > Thanks and cheers
>>> > Stéphane
>>> >
>>> > Le lundi 1 mai 2017, Paolo Cavallini >> > > a écrit :
>>> >
>>> > Il 30/04/2017 19:28, Jorge Gustavo Rocha ha scritto:
>>> >
>>> > > I did a PR [1], very simple. This discussion is now about the
>>> best
>>> > > approach to handle all settings, in all platforms. I'm working on
>>> > that.
>>> >
>>> > FYI, summarized here:
>>> > https://issues.qgis.org/issues/16493
>>> > 
>>> > Please add what is missing.
>>> > Thanks.
>>> > --
>>> > Paolo Cavallini - www.faunalia.eu 
>>> > QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> > 
>>> > https://www.google.com/trends/explore?date=all=IT=
>>> qgis,arcgis
>>> > >> is,arcgis>
>>> > ___
>>> > Qgis-developer mailing list
>>> > 

[QGIS-Developer] Plugin [1205] Polygon Divider approval notification.

[noreply]

Plugin Polygon Divider approval by pcav.
The plugin version "[1205] Polygon Divider 0.2" is now approved
Link: http://plugins.qgis.org/plugins/Submission/
___
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] Split parts tool - invalid output

[Bernhard Ströbl]

Hi Giovanni

Am 20.06.2017 um 14:18 schrieb Giovanni Manghi:

Hi,



Hi,

I would like to raise attention for an issue which was discussed in
length in the qgis-users list [1]

You can ignore the beginning of the discussion where I mixed up "Split
parts" and "Split features".

The split features tool does not produce valid geometries. This can be
easily reproduced by splitting one part of a multipart feature and
then try to split that part again (or save and check the feature with
e.g. postgis' st_isvalid()). This goes hand-in-hand with the comments
in a related, older issue [2].

This makes the workflow much more complex [see 3], if you want to have
a valid output at the end.

The discussion ended in a new Tool in the DigitizingTools (0.11.0)
plugin (thank you Bernhard), which acts much more intuitive from a
users' perspective.
- singlepart features are split and one half inserted as a new feature
- multipart features are split and the user has to choose which part
gets inserted as a new feature, while the other half stays a multipart
feature with all other parts still connected

This raises the question if and how to get that to replace the core tools.

Happy for any input :)




is strange this thread is seemingly not getting much traction at least
in the dev list. Having a core digitizing tool that cripples
geometries do not look good to me, and apparently a good solution has
been implemented (or had to) in a plugin. Isn't worth having core
doing it the right way?


cheers

-- G --


I would definitely wish to have proper tools in core but as I am not a 
C++ guy all I can do is implement things in a Python plugin :-( 
DigitizingTools is an effort to provide missing tools until there is a 
solution in core (I just abandoned a tool whose functionality has been 
implemented). I welcome any C++ dev going ahead and copying (and 
improving) the tools I provide.

You may have seen that I commented on [1]

Bernhard

[1] https://issues.qgis.org/issues/12754


__ Information from ESET Mail Security, version of virus signature 
database 15614 (20170620) __

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

[Yves Jacolin]

On mardi 20 juin 2017 13:28:08 CEST Even Rouault wrote:
> On mardi 20 juin 2017 13:09:00 CEST Yves Jacolin wrote:
> > Hello,
> > 
> > I built QGIS with gdal-ogr version 2.2 but I get a crash with this
> > message:
> > symbol lookup error: /home/yjacolin/Documents/Developpement/
> > qgis_install_stable/lib/libqgis_core.so.2.18.9: undefined symbol:
> > OGR_F_IsFieldSetAndNotNull
> > 
> > Does QGIS 2.18.9 supports gdal 2.2?
> 
> Yves,
> 
> The fact that you get this error message is a proof that latest QGIS 2.18
> supports GDAL 2.2 ;-)
> 
> What likely happens here is that you have built QGIS against GDAL 2.2 header
> files, but at runtime an older libgdal is found. Check your PATH /
> LD_LIBRARY_PATH.
> 
Even, Jürgen,

Shame on me, I renamed the path to GDAL in the past and my QGIS script was not 
uptodate :/

Many thanks to both of you,

Y.



signature.asc
Description: This is a digitally signed message part.
___
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 > Processing: some test

[Nyall Dawson]

On 20 June 2017 at 22:03, Giovanni Manghi  wrote:
> Hi Nyall,
>
>
>>> and dissolving by "distrito" the ogr2ogr based tool is 2/3 seconds
>>> faster than the new native one.
>>
>> For comparison, how long did each take in total?
>
> about ~28/29 seconds ogr and ~ 31/32 native (on a testing VM with
> limited resources).

I'm happy with that :D

>> Hmm - works fine here. Can you try turning off the invalid geometry
>> checking in processing options? That's a little broken at the moment
>> (with the error you've noted below)
>
> if I turn off that option then it works, both dissolving by attribute
> and a full dissolve.
> The speed difference is not much (ogr always a bit faster in my
> testing environment).

Also that :)

I'd love to see some tests using non-ogr sources (e.g. dissolve a
postgres layer or memory layer). I think in this case QGIS native may
be able to shave off this couple of seconds lead the OGR variant has.
(Although that's not really that important - if we can get the speed
comparable, with stable invalid geometry handling, then I'll be
satisfied).

>> That should be really straightforward to add to the feature iterators
>> now. But alternatively there's a processing alg which repairs
>> geometries too (not in master yet, but in earlier 3.0 builds).
>
>
> both very good news! but don't forget that in the economy of a work
> day of a person that do all day this kind of operations, having an
> option to fix geometries on the fly while clipping/intersecting/etc is
> very important and save a lot of time. Of course having the same
> functionality as separate tool is as much as important.

Agreed.

Thanks for this testing - it's very valuable!

Nyall
___
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] Split parts tool - invalid output

[Giovanni Manghi]

Hi,


> Hi,
>
> I would like to raise attention for an issue which was discussed in
> length in the qgis-users list [1]
>
> You can ignore the beginning of the discussion where I mixed up "Split
> parts" and "Split features".
>
> The split features tool does not produce valid geometries. This can be
> easily reproduced by splitting one part of a multipart feature and
> then try to split that part again (or save and check the feature with
> e.g. postgis' st_isvalid()). This goes hand-in-hand with the comments
> in a related, older issue [2].
>
> This makes the workflow much more complex [see 3], if you want to have
> a valid output at the end.
>
> The discussion ended in a new Tool in the DigitizingTools (0.11.0)
> plugin (thank you Bernhard), which acts much more intuitive from a
> users' perspective.
> - singlepart features are split and one half inserted as a new feature
> - multipart features are split and the user has to choose which part
> gets inserted as a new feature, while the other half stays a multipart
> feature with all other parts still connected
>
> This raises the question if and how to get that to replace the core tools.
>
> Happy for any input :)



is strange this thread is seemingly not getting much traction at least
in the dev list. Having a core digitizing tool that cripples
geometries do not look good to me, and apparently a good solution has
been implemented (or had to) in a plugin. Isn't worth having core
doing it the right way?


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] QGIS 3 > Processing: some test

[Giovanni Manghi]

Hi Nyall,


>> and dissolving by "distrito" the ogr2ogr based tool is 2/3 seconds
>> faster than the new native one.
>
> For comparison, how long did each take in total?

about ~28/29 seconds ogr and ~ 31/32 native (on a testing VM with
limited resources).



> Hmm - works fine here. Can you try turning off the invalid geometry
> checking in processing options? That's a little broken at the moment
> (with the error you've noted below)

if I turn off that option then it works, both dissolving by attribute
and a full dissolve.
The speed difference is not much (ogr always a bit faster in my
testing environment).





> Outdated message ;) It's refering to the option in processing settings.

yes, i realized it later.


> That should be really straightforward to add to the feature iterators
> now. But alternatively there's a processing alg which repairs
> geometries too (not in master yet, but in earlier 3.0 builds).


both very good news! but don't forget that in the economy of a work
day of a person that do all day this kind of operations, having an
option to fix geometries on the fly while clipping/intersecting/etc is
very important and save a lot of time. Of course having the same
functionality as separate tool is as much as important.

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] GDAL-OGR version

[Jürgen E . Fischer]

Hi Yves,

On Tue, 20. Jun 2017 at 13:09:00 +0200, Yves Jacolin wrote:
> I built QGIS with gdal-ogr version 2.2 but I get a crash with this message:
> symbol lookup error: /home/yjacolin/Documents/Developpement/
> qgis_install_stable/lib/libqgis_core.so.2.18.9: undefined symbol: 
> OGR_F_IsFieldSetAndNotNull

Are you sure you are trying with the GDAL 2.2 shared library?


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


signature.asc
Description: PGP signature
___
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] GDAL-OGR version

[Even Rouault]

On mardi 20 juin 2017 13:09:00 CEST Yves Jacolin wrote:
> Hello,
> 
> I built QGIS with gdal-ogr version 2.2 but I get a crash with this message:
> symbol lookup error: /home/yjacolin/Documents/Developpement/
> qgis_install_stable/lib/libqgis_core.so.2.18.9: undefined symbol:
> OGR_F_IsFieldSetAndNotNull
> 
> Does QGIS 2.18.9 supports gdal 2.2?

Yves,

The fact that you get this error message is a proof that latest QGIS 2.18 
supports GDAL 2.2 ;-)

What likely happens here is that you have built QGIS against GDAL 2.2 header 
files, but at 
runtime an older libgdal is found. Check your PATH / LD_LIBRARY_PATH.

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] GDAL-OGR version

[Yves Jacolin]

Hello,

I built QGIS with gdal-ogr version 2.2 but I get a crash with this message:
symbol lookup error: /home/yjacolin/Documents/Developpement/
qgis_install_stable/lib/libqgis_core.so.2.18.9: undefined symbol: 
OGR_F_IsFieldSetAndNotNull

Does QGIS 2.18.9 supports gdal 2.2?

Thanks,

Y.

signature.asc
Description: This is a digitally signed message part.
___
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 > Processing: some test

[Nyall Dawson]

On 19 June 2017 at 19:19, Giovanni Manghi  wrote:

> I waited a Windows osgeor4w master build that included your new native
> c++ dissolve tool.
>
> I tested it (on the same platform and conditions) against qgis 2.18.9
> nightly, that also write debug output.
>
> Using
> https://www.dropbox.com/s/ncj4ysh15xrnm45/caop.zip?dl=0
>
> and dissolving by "distrito" the ogr2ogr based tool is 2/3 seconds
> faster than the new native one.

For comparison, how long did each take in total?

> Using:
> https://www.dropbox.com/s/qr8md49cy5u8vrf/clip.zip?dl=0
>
> which is a clip of a much larger and complex layer, and dissolving by
> "a" (sorry for the column name), the ogr 2ogr based tool does the
> job in about 20 seconds.
>
> The new native dissolve tool runs for a split second and outputs a few
> polygons in vastly incomplete result.

Hmm - works fine here. Can you try turning off the invalid geometry
checking in processing options? That's a little broken at the moment
(with the error you've noted below)

> Trying to dissolve all polygons (and operation that the ogr2ogr based
> tool does with no issues) with the native tool it results in a python
> error and and infinite running hourglass.

Same as above - can you switch off the processing geometry check
option and retest?

> Traceback (most recent call last):
>   File 
> "C:/OSGEO4~1/apps/qgis-dev/./python/plugins\processing\gui\AlgorithmDialog.py",
> line 246, in accept
> result = executeAlgorithm(self.alg, parameters, context, feedback)
>   File 
> "C:/OSGEO4~1/apps/qgis-dev/./python/plugins\processing\core\GeoAlgorithm.py",
> line 338, in executeAlgorithm
> result = alg.run(parameters, context, feedback)
> SystemError:  returned a result with an error set

Yes - this error is on my list. There's a python exception being
thrown which messes with some c++ code.

> "Features with invalid geometries found. Please fix these geometries
> or specify the "Ignore invalid input features" flag"
>
> because the option is not available in the tool.

Outdated message ;) It's refering to the option in processing settings.

> I still strongly
> argue that anyway -if it is really a problem of bad geometries- we
> miss a clear suggestion and workflow to allow the user solve this
> situation. In my point of view the option in such tools should not be
> "skip the invalid geometries" but to *fix* them.

That should be really straightforward to add to the feature iterators
now. But alternatively there's a processing alg which repairs
geometries too (not in master yet, but in earlier 3.0 builds).

Nyall
___
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 [970] TUFLOW approval notification.

[noreply]

Plugin TUFLOW approval by pcav.
The plugin version "[970] TUFLOW 1.3.1" is now approved
Link: http://plugins.qgis.org/plugins/tuflow/
___
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] Problem with QGIS from OSGeo4W and gdal 2.2.0-5

[Pedro Venâncio]

Hi,

I opened a ticket here: https://trac.osgeo.org/osgeo4w/ticket/535

Best regards,
Pedro



2017-06-19 17:46 GMT+01:00 Pedro Venâncio :

> Hi,
>
> I've updated today QGIS from OSGeo4W64bits and it updated also gdal to
> version 2.2.0-5.
>
> It lead to a constant and inconsistent QGIS crash, sometimes at the start,
> other times when openning some saved projects, and other times, with new
> projects, when editing data, or simply zooming in and out.
>
> Tested with QGIS 2.18.9-14 and 2.14.15-5, with and without GRASS plugin.
> Also starting with --noplugins, I get the crash.
>
> Then I did the downgrade of gdal to 2.2.0-3, and everything seems to work
> again.
>
> To confirm, I've installed again gdal 2.2.0-5, tested, and get the crash
> right at the QGIS start. Downgraded again to gdal 2.2.0-3 and I get
> everything great again.
>
> So, seems to be something wrong with QGIS and gdal 2.2.0-5.
>
> Anyone confirms? Should I open a ticket?
>
> Thanks!
>
> Best regards,
> Pedro Venâncio
>
___
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 [1050] LM Open Data WMTS approval notification.

[noreply]

Plugin LM Open Data WMTS approval by pcav.
The plugin version "[1050] LM Open Data WMTS 0.4.1" is now approved
Link: http://plugins.qgis.org/plugins/LmOpenData/
___
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 [1102] AequilibraE approval notification.

[noreply]

Plugin AequilibraE approval by pcav.
The plugin version "[1102] AequilibraE 0.3.5.2" is now approved
Link: http://plugins.qgis.org/plugins/AequilibraE/
___
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] Drag and drop to PostGIS crash

[Radim Blazek]

On Fri, Jun 2, 2017 at 11:02 AM, Radim Blazek  wrote:
> On Fri, Jun 2, 2017 at 10:48 AM, Nyall Dawson  wrote:
>> QgsBrowserItem::handleDrop just gets a layer URI in the mime data -
>> that's enough for the other providers to be able to open a new copy of
>> the layer to grab the features from, but the for the memory provider
>> the uri only gives the table structure there's no features in the
>> newly created layer.
>
> It should be possible to pass the layer id and open an iterator on it?

I have implemented DD for memory layer using layer id passed in mime
data, but it is crashing in
QgsVectorLayerExporter::exportLayer()
on
QgsFeatureIterator fit = layer->getFeatures( req );

#0  0x03abf980 in ?? ()
#1  0x7fd5bd913d7d in QgsVectorLayerExporter::exportLayer
(layer=0x37f78a0, uri=..., providerKey=..., destCRS=...,
onlySelected=false, errorMessage=0x34a5d68, options=0x34a5d50,
feedback=0x34a7f00)
at /home/radim/devel/qgis/src/core/qgsvectorlayerexporter.cpp:332
#2  0x7fd5bd9155e1 in QgsVectorLayerExporterTask::run (this=0x34a5cd0)
at /home/radim/devel/qgis/src/core/qgsvectorlayerexporter.cpp:493
#3  0x7fd5bd82e08d in QgsTask::start (this=0x34a5cd0) at
/home/radim/devel/qgis/src/core/qgstaskmanager.cpp:66
#4  0x7fd5bd83a92c in QgsTaskRunnableWrapper::run (this=0x3793c00)
at /home/radim/devel/qgis/src/core/qgstaskmanager.cpp:335

Could it be a problem that feature iterator on memory layer is opened
from QgsVectorLayerExporterTask? Renderer also reads memory layer
features in thread.

Radim
___
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