Re: [QGIS-Developer] Suggestion for changelog entry about default values

[Daan Goedkoop]

Hello Richard,

Yes, I am logged in. I still cannot see the entry (nr. 736: "Improved
handling of defaults").

Regards,
Daan

2018-02-22 9:25 GMT+01:00 Richard Duivenvoorde <rdmaili...@duif.net>:
> On 22-02-18 07:42, Daan Goedkoop wrote:
>> Hello Etienne,
>>
>> I've tried it now, but after clicking Submit I got an error about "too
>> many redirects" and now I can't see the entry anymore at all. Strange.
>
> Hi Daan,
>
> I see that dgoedkoop as a valid user.
>
> Are you logged in?
>
> Can you try again and report back?
>
> 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] Suggestion for changelog entry about default values

[Daan Goedkoop]

Hello Etienne,

I've tried it now, but after clicking Submit I got an error about "too
many redirects" and now I can't see the entry anymore at all. Strange.

Regards,
Daan

2018-02-22 7:52 GMT+01:00 Etienne Trimaille <etienne.trimai...@gmail.com>:
> Hi Daan,
>
> You should be able to create an account on changelog.qgis.org and then edit
> the entry. Then it will go in the pending queue for a review.
>
> Contributions on the changelog are more than welcome, there is a lot of work
> to do ;-)
> Thanks for your contribution.
>
> Regards,
> Etienne
>
> 2018-02-22 9:47 GMT+03:00 Daan Goedkoop <dgoedk...@gmx.net>:
>>
>> Hello,
>>
>> As per the discussion of this bug report:
>> https://issues.qgis.org/issues/17990, could a text be added to this
>> changelog entry:
>>
>> http://changelog.qgis.org/en/qgis/version/3.0.0/#improved-handling-of-defaults
>> ?
>>
>> For example: "This also means that, after certain editing operations
>> (e.g. copy-paste, split features etc.) attributes will now be set to
>> their default value, if applicable."
>>
>> Kind regards,
>>
>> Daan Goedkoop
>> ___
>> 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] Suggestion for changelog entry about default values

[Daan Goedkoop]

Hello,

As per the discussion of this bug report:
https://issues.qgis.org/issues/17990, could a text be added to this
changelog entry:
http://changelog.qgis.org/en/qgis/version/3.0.0/#improved-handling-of-defaults
?

For example: "This also means that, after certain editing operations
(e.g. copy-paste, split features etc.) attributes will now be set to
their default value, if applicable."

Kind regards,

Daan Goedkoop
___
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] Bringing back a *highly curated* blocker tag on redmine?

[Daan Goedkoop]

Hello Jürgen,

apparently the open bugs which are regressions and cause data
corruption or crashes are only 10 in number at the moment (of which I
reported one). I think they are important because they can catch you
by surprise in tested and established workflows. New things will
probably only be used heavily in serious contexts after some testing,
so I feel that problems there are not quite as important.

Kind regards,

Daan

2018-01-30 11:09 GMT+01:00 Jürgen E. Fischer :
> Hi Giovanni,
>
> On Tue, 30. Jan 2018 at 09:09:52 +, Giovanni Manghi wrote:
>> * a regression that causes data corruption
>> * a regression that causes qgis to crash
>
> I still don't understand this obsession with regressions ;)
>
> Any bug that is severe should block the release.  Whether it's a regression or
> not doesn't matter.
>
> If it's an unavoidable bug in some heavy used thing that is new, it's just as
> blocking as a big bug in known territory.
>
> IMHO a bug in some remote, hardly used function shouldn't block a release -
> even if it's a regression that corrupts data and causes qgis to crash in some
> edge cases.  We'll probably have plenty of those that we don't know of anyway.
>
> To me it's just a matter of the impact on usablity a bug has.  I'd opt for
> common sense instead of setting strict rules.
>
>
> 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-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] Geometry operations in Python

[Daan Goedkoop]

Yes, that works. Thank you!

2018-01-27 0:43 GMT+01:00 Nyall Dawson <nyall.daw...@gmail.com>:
> On 25 January 2018 at 17:30, Daan Goedkoop <dgoedk...@gmx.net> wrote:
>> Thank you for the answers!
>>
>> Ok, so I don't need to manipulate the QgsMultiLineString directly. Yet
>> I cannot help to wonder a little bit about this (using a .shp file):
>>
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().asGeometryCollection()[0].asWkt()
>> 'LineString (4.83090675976269512 52.44278398333691626,
>> 4.89922802216601205 52.37283112413303598)'
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().asWkt()
>> 'MultiLineString ((4.83090675976269512 52.44278398333691626,
>> 4.89922802216601205 52.37283112413303598))'
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().asGeometryCollection()[0].asWkt()
>> 'LineString (4.83090675976269512 52.44278398333691626,
>> 4.89922802216601205 52.37283112413303598)'
>>>>> type(qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet())
>> 
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().wkbType()
>> 5
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().numGeometries()
>> 0
>>>>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().asWkt()
>> 
>>
>> Is this expected behaviour?
>
> I suspect what's happening here is that the feature is being garbage
> collected early, deleting the geometry and causing the unpredictable
> behavior - try this:
>
> f = qgis.utils.iface.activeLayer().selectedFeatures()[0]
> f.geometry().constGet().. etc
>
>
>
> 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] QGIS3: reminder of an annoying bug

[Daan Goedkoop]

Here is a sample project file.

2018-01-24 14:10 GMT+01:00 Jürgen E. Fischer <j...@norbit.de>:
> Hi Daan,
>
> On Wed, 24. Jan 2018 at 13:20:56 +0100, Daan Goedkoop wrote:
>> E.g. a project with the CRS set to 25833 (ETRS89/UTM zone 33N) in 2.18
>> will open with CRS 3006 (SWEREF99 TM) in the current QGIS 3.0.
>
>> 2018-01-20 18:05 GMT+01:00 Jürgen E. Fischer <j...@norbit.de>:
>> > I guess you see the problem with prj from third parties that use different
>> > projection names.  And hence there may be no clue left in the prj that 
>> > could
>> > help with identifying whether it's EPSG:3044 or EPSG:25832.  How do your 
>> > .prj
>> > actually look like?
>
> That a project is also affected is unexpected.  Sample data?
>
>
> 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
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


Projection_sample2.qgs
Description: Binary data
___
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

[Daan Goedkoop]

Hello,

I just noticed that this issue apparently also surfaces when opening
projects from QGIS 2.18 in QGIS 3.0

E.g. a project with the CRS set to 25833 (ETRS89/UTM zone 33N) in 2.18
will open with CRS 3006 (SWEREF99 TM) in the current QGIS 3.0.

Kind regards,

Daan

2018-01-20 18:05 GMT+01:00 Jürgen E. Fischer :
> Hi Tobias,
>
> On Sun, 14. Jan 2018 at 15:09:30 +0100, Tobias Wendorff wrote:
>> I was able to observe many users over the year, which do not correct
>> the projection neither for work within QGIS, nor for saving (they are
>> not aware of the problem) Worse still: when saving, EPSG:3044 is
>> written to the PRJ file (for shapefiles). Thus, the error manifests
>> itself permanently. There are also other
>
> I just tried and the EPSG is only written to the qpj, but not to the prj.
> That's why we write .qpj, because otherwise we may run into the same problem
> even within QGIS.  GDAL doesn't write the full WKT into the prj - it "morphs 
> to
> ESRI" for compatibility reason.  The qpj carries it.
>
> If there is no qpj, we rely on GDAL to detect the correct CRS from the prj,
> which can have issues with some prjs (if there is a qpj too - but we feed it
> the full WKT from the qpj).
>
> GDAL does detect the correct EPSG from prj it wrote itself. Apparently from 
> the
> different name of the projection, because the rest of the prj is the same.
> There is no information about the different axis order in the prj (ie. the 
> only
> actual difference between EPSG:3044 and EPSG:25832).
>
> I guess you see the problem with prj from third parties that use different
> projection names.  And hence there may be no clue left in the prj that could
> help with identifying whether it's EPSG:3044 or EPSG:25832.  How do your .prj
> actually look like?
>
>> 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.
>
> Unfortunately not.
>
> sqlite> select count(*),count(*)-count(distinct parameters) from tbl_srs;
> 6759|1633
>
> 1633/6759 crs have duplicates.
>
> sqlite> select count(*),parameters from tbl_srs group by parameters having 
> count(*)>1 order by count(*) desc limit 10;
> 138|+proj=geocent +ellps=GRS80 +units=m +no_defs
> 62|+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
> 51|+proj=longlat +ellps=intl +no_defs
> 36|+proj=longlat +ellps=GRS80 +no_defs
> 25|+proj=geocent +ellps=WGS84 +units=m +no_defs
> 17|+proj=longlat +ellps=clrk80 +no_defs
> 15|+proj=longlat +ellps=bessel +no_defs
> 14|+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
> 13|+proj=longlat +ellps=clrk66 +no_defs
> 9|+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +vunits=m +no_defs
>
> So some even have 138 duplicates.
>
> sqlite> select srid,description from tbl_srs where parameters='+proj=utm 
> +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs';
> 3044|ETRS89 / ETRS-TM32
> 25832|ETRS89 / UTM zone 32N
> 6707|RDN2008 / UTM zone 32N (N-E)
> 7791|RDN2008 / UTM zone 32N
>
> The parameters of EPSG:25832 exists 4 times.
>
> https://trac.osgeo.org/gdal/ticket/4345 looks relevant.  With GDAL trunk
> gdalsrsinfo -e on a EPSG:25832/3044 prj with the projection name changed to
> unknown finds EPSG:25832 and EPSG:3044 with a confidence of each 90%.
>
> I guess we better let the user decide with CRS to use, when we don't find an
> accurate match.  Even if there wouldn't be so many duplicates, the frequency 
> of
> use may be different for different areas of application and any automatism 
> might
> still fail and appear as a bug.
>
>
> 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
> 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] Geometry operations in Python

[Daan Goedkoop]

Hello all,

I'm updating my plugin to QGIS 3.

It sometimes needs to reverse line directions. I used to do it like this:

return QgsGeometry.fromPolyline(geom.asPolyline().reverse())

Q1. Do I understand it correctly, that fromPolyline returns a
QgsPointXY list, thus destroying any M/Z values?

What I do now, and what seems to work, is this:

return QgsGeometry(geom.constGet().reversed())

Q2. Is this the preferred way?
Q3. Is it better to use constGet() or normal get()?

The second issue are multi-part geometries. I have tried something
like this, after selecting a simple line in a .shp layer:

>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().wkbType()
5 (note: multipart line. I don't understand why, but ok)
>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().numGeometries()
0
>> qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().constGet().geometryN(0)


So apparently this doesn't work. So now I use an approach like this:

list = 
qgis.utils.iface.activeLayer().selectedFeatures()[0].geometry().asGeometryCollection()
mls = QgsMultiLineString()
for line in list:
   mls.addGeometry(line.constGet().reversed())
newgeom = QgsGeometry(mls)

Q4. Is this the recommended way of doing things?

Can someone shed a light on this?

Kind regards,
Daan
___
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] New feature proposal for the Dissolve tool

[Daan Goedkoop]

Yes I think so -- thank you!

2017-02-22 21:13 GMT+01:00 Nyall Dawson <nyall.daw...@gmail.com>:
> On 22 February 2017 at 21:06, Daan Goedkoop <dgoedk...@gmx.net> wrote:
>> Yes, apparently the dissolve tool merges adjacent geometries into a
>> single "part" when operating on polygons, but not when operating on
>> lines.
>>
>
> Perhaps you're looking for the "merge lines" tool? That will join the
> parts of a multilinestring into single connected linestrings (where
> possible).
>
> My usual process is to chain dissolve -> merge lines -> multiparts to
> singleparts.
>
> 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] New feature proposal for the Dissolve tool

[Daan Goedkoop]

Yes, apparently the dissolve tool merges adjacent geometries into a
single "part" when operating on polygons, but not when operating on
lines.

2017-02-22 11:46 GMT+01:00 Marco Grisolia :
> Hmm maybe I'm wrong, but I think it will only return singleparts without
> taking care of an adjacency criterion (even if ran after the dissolving
> operation).
> Marco
>
> 2017-02-22 11:37 GMT+01:00 Anita Graser :
>>
>> You can run multiplart to singlepart afterwards.
>>
>>
>> On Wed, Feb 22, 2017 at 11:18 AM, roy roy  wrote:
>>>
>>> Hi Anita, that does not do what Marco is asking for, because you get a
>>> multipart geometry;
>>>
>>> he needs a linestring geometry I think...
>>>
>>>
>>> Il 22/02/2017 11:10, Anita Graser ha scritto:
>>>
>>> Hi Marco,
>>>
>>> The Dissolve tool already has a "unique fields" option. It sounds like
>>> you are reinventing that.
>>>
>>> Best wishes,
>>> Anita
>>>
>>>
>>>
>>> On Wed, Feb 22, 2017 at 10:32 AM, Marco Grisolia
>>>  wrote:

 Hi,
 I recently answered to a question on GIS StackExchange [0]. In this
 question, the asker was looking for a way for dissolving features using an
 adjacency criterion instead of using common attribute field (please, follow
 the link below for a better understanding). This feature is already
 available in the analogous ArcGIS tool when the"Create multipart features"
 option is enabled and I think it could be of interest having an additional
 option like this in the "Dissolve" tool main dialog for next releases.
 I never submitted a feature request on the QGIS Project site but, since
 there is already a (very rough) code and a general idea on how to approach
 the issue, I didn't know if this was the case of adding it there. 
 Otherwise,
 let me know if I need to add it on the QGIS Project site (if this is the
 case, I'm sorry for wasting your time).
 Regards,
 Marco


 [0]
 http://gis.stackexchange.com/questions/228267/merging-adjacent-lines-in-qgis

 ___
 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
>>
>>
>>
>> ___
>> 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] New feature proposal for the Dissolve tool

[Daan Goedkoop]

Hello,

the example on StackExchange seems to do this for the currently
selected features.

It might also be desirable to do this for an entire layer, e.g. join
at all places where exactly two line features are adjacent. (I think
v.build.polylines does this, but apparently it is not available from
QGIS.)

A while ago I created a processing script for this, with (compared to
the StackExchange example) some more configurability and optimization
with a spatial index.

I just don't know, what is the best place to upload a processing
script? As a PR against qgis/QGIS-Processing on github?

Kind regards,
Daan

2017-02-22 10:32 GMT+01:00 Marco Grisolia :
> Hi,
> I recently answered to a question on GIS StackExchange [0]. In this
> question, the asker was looking for a way for dissolving features using an
> adjacency criterion instead of using common attribute field (please, follow
> the link below for a better understanding). This feature is already
> available in the analogous ArcGIS tool when the"Create multipart features"
> option is enabled and I think it could be of interest having an additional
> option like this in the "Dissolve" tool main dialog for next releases.
> I never submitted a feature request on the QGIS Project site but, since
> there is already a (very rough) code and a general idea on how to approach
> the issue, I didn't know if this was the case of adding it there. Otherwise,
> let me know if I need to add it on the QGIS Project site (if this is the
> case, I'm sorry for wasting your time).
> Regards,
> Marco
>
>
> [0]
> http://gis.stackexchange.com/questions/228267/merging-adjacent-lines-in-qgis
>
> ___
> 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] Crash in current QGIS 2.14 on right-click on geometry-less layer

[Daan Goedkoop]

Hello,

I'm not sure if this warrants a complete bug-report and/or PR thing,
but the current version of the release-2_14 branch crashes when you
right-click on a data layer. I think it is quite essential that this
is fixed before 2.14.4.

The following commit fixes this in master and should probably be back-ported:

054604b fix crash when right-clicking on geometryless layers

Kind regards,
Daan.
___
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] Accidentally sent report to orfeo-toolbox

[Daan Goedkoop]

Hello all,

In order to test a bug-fix on Windows, I thought the easiest way for a
build would be to use the nightly packaging script to create an
installable build.

Well, it submits a report to orfeo-toolbox and apparently this is not
password-protected or anything like that.

So now I have accidentally submitted a "wrong" report. Is this a
problem and if so, can anyone delete it?

Kind regards,

Daan
___
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] Finding out cause of Travis compile warning failure?

[Daan Goedkoop]

Never mind, I've found it already! The Travis log does contain a link to
the compile log.
Op 29 jan. 2016 19:33 schreef "Daan Goedkoop" <dgoedk...@gmx.net>:

> Hello all,
>
> I have a pull request that fails the ci-check because of 2 compile
> warnings.
>
> I don't see the actual warnings anywhere in the Travis log, and when I
> compile locally with clang, I get quite a lot more warnings than just
> 2, but none of them related to my changes.
>
> How can I find out what the problem is?
>
> Many thanks in advance,
> Daan
>
___
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] Finding out cause of Travis compile warning failure?

[Daan Goedkoop]

Hello all,

I have a pull request that fails the ci-check because of 2 compile warnings.

I don't see the actual warnings anywhere in the Travis log, and when I
compile locally with clang, I get quite a lot more warnings than just
2, but none of them related to my changes.

How can I find out what the problem is?

Many thanks in advance,
Daan
___
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] On-the-fly reprojection and snapping / tracing

[Daan Goedkoop]

Hi everybody,

A few months ago I have raised the issue of floating-point inaccuracies with snapped digitising when OTF reprojection is activated (see bug report #13745). This breaks many functionalities, such as cutting features by clicking on a vertex; topological editing; removing duplicate features; topology checking, and so on. I have also proceeded to create a pull request with a proposed fix for the snapping functionality (#2434), still waiting for feedback.

Now I have noticed that Martin Dobias has introduced a new tracing framework, a couple of days ago. While it is surely a great functionality, currently the tracer object is bound to the map canvas and keeps its data in map coordinates. So here too, layer coordinates are transformed to map coordinates, tracing is performed in map coordinates, and the traced points are then converted back to layer coordinates, leading to floating-point inaccuracies. To be precise: if the active layer and the traced layer have the same CRS, but the project has a different CRS, a feature created by tracing does not exactly match the traced feature. This will again cause functions like removing duplicates and topological features not to work.

How to handle this? As I see it, it will be a bit of work to fix this. Firstly, the tracer class should perhaps be bound to layers instead of canvases. Another possibility might be to just invalidate the tracer when the active layer is changed. In any case, the tracer would need to be changed to return layer coordinates instead of / in addition to map coordinates.

But maybe anyone also has a general opinion about this whole issue of OTF reprojection and floating point inaccuracies?

Kind regards,

Daan Goedkoop
___
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] Snapping rounding errors with on-the-fly reprojection (#13745)

[Daan Goedkoop]

Hello everyone,

Last week I made a bug report (http://hub.qgis.org/issues/13745) and
got redirected to this mailing list.

To summarize, the issue here is as follows. When digitising, QGis
keeps a rubber band in map coordinates and a capture list in layer
coordinates. However, vertices of the capture list are added in a way
where they are first converted from on-screen pixel coordinates to map
coordinates, then snapped, and then transformed to layer coordinates.
This leads to floating point inaccuracies, so that the resulting layer
data are in fact not exactly snapped.

To test if this is really the problem, I have made some changes, so
that the capture list coordinates are directly snapped to the layer
coordinates. With these changes, snapping seems to work correctly,
without such floating point inaccuracies. I've put these changes here:
https://github.com/dgoedkoop/QGIS/tree/digitise_snap_crs

I think they are not (yet?) suitable for a pull request. There are
(still) some problems, such as:
- Snapping tolerance might not be converted between map / layer units
and might thus be completely wrong
- The snapping index is created and destroyed twice in every mapcanvas
mouse event. This is unacceptably slow. At least two snapping caches
are necessary, one for the map CRS and one for the current layer CRS.
- Might crash when digitising without any active layer
- I haven't looked at unit tests yet (only checked that the existing
ones compile at all.)

This is my first try for a little bit bigger contribution to an open
source project. And also the first time to write some C++ code. And
also the first time to use github forks. So I'd appreciate any
feedback!

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