Re: [QGIS-Developer] proj5 and epsg:3857 ?
On 9 March 2018 at 19:39, Kristian Evers wrote: > All, > > Just to follow up on this, since I am the one to blame for this error to show > up. Kristian -- just to add my 2c here, there's absolutely NO-ONE who can blame you for this mistake, please do not beat yourself up over this! I'm sure there's not a single developer who hasn't been responsible for at least one serious bug in release software. It's just the nature of the job, and even more so when the software involved is such a complex and esoteric area as that handled by proj. (Heck... you could easily have bluffed your way around this with some explanation about temporal datum shifts and the like and claimed that the proj5 results are "real world accurate" or something, and no-one would have been able to call you out ;) Keep up the great work in this critical, yet underappreciated and under-funded part of our ecosystem. It's very much appreciated and valued by everyone who knows the work you do. 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] proj5 and epsg:3857 ?
On 03/09/2018 07:04 PM, Richard Duivenvoorde wrote: > ps README.md still talking about ./configure in "Building on Unix/Linux" > while apparently it is not there anymore? It's there after you run autogen.sh. ___ 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] proj5 and epsg:3857 ?
On 09-03-18 16:30, Even Rouault wrote: > > I don't think the removal of "+nadgrids=@null" is a "universal" > workaround. It only works when the other SRS has no +towgs84 or > +nadgrids clause itself, which isn't the case of EPSG:28992. Basically > if you transform between EPSG:28992 and WebMercator without > +nadgrids=@null, then no datum shift at all is done, so you have just > the tranform between the Bessel ellipsoid and the sphere of radius > 6378137. The proper fix is to get the patched version of proj Ok, ok :-) Cloned proj.4, compiled master and working \o/ Thanks, Richard ps README.md still talking about ./configure in "Building on Unix/Linux" while apparently it is not there anymore? ___ 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] proj5 and epsg:3857 ?
On vendredi 9 mars 2018 12:19:09 CET Richard Duivenvoorde wrote:
> Hi All,
>
> I second that: not blaming anybody here. This happens in the real world.
>
> My point was that I think as QGIS we can 'hide' this issue by not using
> 5.0.0 'yet' in the osgeo4w package.
>
> I will happily use/test whatever is available in Debian sid :-)
>
> Also tried Kristian's fix.
>
> For QGIS users: QGIS does not use the epsg file provided by your proj
> install, but a srs.db:
> {QGISINSTALLDIR}/share/qgis/resources/srs.db
>
> I edited (using DB browser) and removed the "+nadgrids=@null" clause
> from the epsg:3857 line.
> Checked by looking into the srs chooser of QGIS and seeing that it was
> indeed not visible anymore.
>
> But it does not seem a 100% hack with me. While more near the 'real'
> place, it is still 150m off?
>
I don't think the removal of "+nadgrids=@null" is a "universal" workaround. It
only works
when the other SRS has no +towgs84 or +nadgrids clause itself, which isn't the
case of EPSG:
28992. Basically if you transform between EPSG:28992 and WebMercator without
+nadgrids=@null, then no datum shift at all is done, so you have just the
tranform between
the Bessel ellipsoid and the sphere of radius 6378137. The proper fix is to get
the patched
version of proj
--
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] proj5 and epsg:3857 ?
On vendredi 9 mars 2018 11:38:17 CET Even Rouault wrote: > Kristian > > your are certainly not too blame at à personal level. this is the kind of > this that happen inevitably given a certain amount of changes . i'm > surprised that the GDAL autotest suite did not catch this but the cause is > likely that the GDAL c++ class that wraps proj has an optimisation when > transforming from 3857 to 4326. My bad: going from datum=WGS84 to WebMercator wasn't actually affected by the bug. Only if you go from datum != WGS84 to WebMercator. And there wasn't indeed a test for that later case in GDAL autotest. Now added. -- 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] proj5 and epsg:3857 ?
Thanks Kristian. This experience shows us how today in the world of mapping "services" (remote mapping engines like QGIS, MapServer, PostGIS, GRASS GIS,..) rely on this unfortunate projection (thanks Google ha), where end-users of the services really have no access to the remote server's PROJ settings. It feels like I have been battling this projection for 15 years now ha. -jeff On 2018-03-09 5:39 AM, Kristian Evers wrote: All, Just to follow up on this, since I am the one to blame for this error to show up. Both by introducing it in the first place and by releasing 5.0.0 with this as a known bug. The bug was introduced to fix a range of other potential issues. Unfortunately the architecture in the old API of PROJ makes it almost impossible to both treat other transformations correct while also treating the Web Mercator correctly. The problem is that the Web Mercator is, geodetically speaking, an abomination of a transformation. It basically defies all logic. This has been known for a long time of course. Unfortunately no tests were set up to catch this specific transformation. I'll make sure to at least add Jeff's test case. Regarding releasing the library with this bug included. The cause of the problem was determined very close to the release time (which was announced a month ahead). We did go through six release candidates. The vote for promotion of RC6 to final release was already started so I decided to release anyway since I did not want to prolong the process even more. I am sure this bug would have been discovered earlier if all of you QGIS developers would not have been super busy with QGIS 3.0 and had had some spare time to test the PROJ release candidates. I am not blaming anyone, it is just a case of bad timing. Not much we can do about that really. Had I been in your shoes I would not have prioritized testing other software either, that's for sure! The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg init-file and the transformation should work as expected. A proper fix will come in 5.0.1 around April 1st. I hope you all will continue to use PROJ 5.0.0 in your development builds despite this problem so other bugs can see the light of day and be fixed in time for 5.0.1. I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully 5.0.1 is a little better so that can be the recommended PROJ version for QGIS. I would like to encourage you to take a look at the release schedule [0] for the next couple of years. We are going to change things in order to keep up with current geodetic developments in countries such as Australia, USA and Iceland. It will affect QGIS sooner or later. I am of course happy to provide assistance where needed. /Kristian [0] https://github.com/OSGeo/proj.4/milestones?direction=asc&sort=due_date&state=open -Oprindelig meddelelse- Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af Jeff McKenna Sendt: 8. marts 2018 12:50 Til: qgis-developer@lists.osgeo.org Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ? Hi Richard, You can read my report to the PROJ team while I was testing the release candidates: http://lists.maptools.org/pipermail/proj/2018-February/008082.html Sorry, it is a long thread. I was trying to prevent (this here in QGIS, for example) from happening, before the release. -jeff On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote: Hi, Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home address, and reproject the epsg:28992 coordinate fine to epsg:3857. But since last week Debian has proj5, and the same plugin (in QGIS master) now is off by 500 meter. To reproduce: if you have a QGIS 2.18 with proj4, and the 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example the osm xyz layer. Now do the same in QGIS master with proj5 and you'll see it is not going to the right/same position. Another observation: IN 2.18 I can 'reproject' the OSM layer to for example epsg:4326, and still see (little distorted) map. But in QGIS3/proj5 I do not see a map anymore. Anybody else seeing this? 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] proj5 and epsg:3857 ?
Il 09/03/2018 12:27, Sebastiaan Couwenberg ha scritto: > FWIW, proj (5.0.0-3~exp1) available in Debian experimental contains a > patch with the cherry-picked commit that fixes this issue. [0] Thanks Bas! -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] proj5 and epsg:3857 ?
On 03/09/2018 12:19 PM, Richard Duivenvoorde wrote: > I will happily use/test whatever is available in Debian sid :-) FWIW, proj (5.0.0-3~exp1) available in Debian experimental contains a patch with the cherry-picked commit that fixes this issue. [0] It also contains a patch with the changes from PR #845 [1], but that introduces a regression causing the shapelib test-suite to fail [1]. I've fixed with another patch included in proj (5.0.0-3~exp2). [2] [0] https://github.com/OSGeo/proj.4/commit/f41fad3ac2bff401456f31dd3273e163ea7d09af [1] https://github.com/OSGeo/proj.4/pull/845 [2] https://github.com/OSGeo/proj.4/pull/845#issuecomment-371785556 Kind Regards, Bas ___ 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] proj5 and epsg:3857 ?
Am Fr, 9.03.2018, 12:19 schrieb Richard Duivenvoorde: > > My point was that I think as QGIS we can 'hide' this issue by > not using 5.0.0 'yet' in the osgeo4w package. Hehe, proj is hiding itself, since 493 is still shown in "about" ;) ___ 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] proj5 and epsg:3857 ?
Hi All,
I second that: not blaming anybody here. This happens in the real world.
My point was that I think as QGIS we can 'hide' this issue by not using
5.0.0 'yet' in the osgeo4w package.
I will happily use/test whatever is available in Debian sid :-)
Also tried Kristian's fix.
For QGIS users: QGIS does not use the epsg file provided by your proj
install, but a srs.db:
{QGISINSTALLDIR}/share/qgis/resources/srs.db
I edited (using DB browser) and removed the "+nadgrids=@null" clause
from the epsg:3857 line.
Checked by looking into the srs chooser of QGIS and seeing that it was
indeed not visible anymore.
But it does not seem a 100% hack with me. While more near the 'real'
place, it is still 150m off?
Regards and thanks for all the work on Proj: one of the corner stones of
QGIS!!
Richard Duivenvoorde
On 09-03-18 11:38, Even Rouault wrote:
> Kristian
>
> your are certainly not too blame at à personal level. this is the kind
> of this that happen inevitably given a certain amount of changes . i'm
> surprised that the GDAL autotest suite did not catch this but the cause
> is likely that the GDAL c++ class that wraps proj has an optimisation
> when transforming from 3857 to 4326. if you transform an array of points
> of the same northing they have the same latitude. this is a common case
> for gdalwarp internal mechanics. thus you need to do trigonometric
> computations just once! so proj is completely short circuited for that
> case.
>
> i'll add a test for the reverse transformation that uses proj (could
> receive a similar optimisation but isnt needed when warping unrectified
> imagery with RPC to WebMercator)
>
> Even
> ---
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
>
> Message d'origine ----
> De : Kristian Evers
> Date :09/03/2018 10:39 (GMT+01:00)
> À : qgis-developer@lists.osgeo.org
> Cc :
> Objet : Re: [QGIS-Developer] proj5 and epsg:3857 ?
>
> All,
>
> Just to follow up on this, since I am the one to blame for this error to
> show up.
> Both by introducing it in the first place and by releasing 5.0.0 with
> this as a
> known bug. The bug was introduced to fix a range of other potential issues.
> Unfortunately the architecture in the old API of PROJ makes it almost
> impossible
> to both treat other transformations correct while also treating the Web
> Mercator
> correctly. The problem is that the Web Mercator is, geodetically
> speaking, an
> abomination of a transformation. It basically defies all logic. This has
> been known
> for a long time of course. Unfortunately no tests were set up to catch
> this specific
> transformation. I'll make sure to at least add Jeff's test case.
>
> Regarding releasing the library with this bug included. The cause of the
> problem
> was determined very close to the release time (which was announced a month
> ahead). We did go through six release candidates. The vote for promotion
> of RC6
> to final release was already started so I decided to release anyway
> since I did not
> want to prolong the process even more. I am sure this bug would have been
> discovered earlier if all of you QGIS developers would not have been super
> busy with QGIS 3.0 and had had some spare time to test the PROJ release
> candidates. I am not blaming anyone, it is just a case of bad timing.
> Not much
> we can do about that really. Had I been in your shoes I would not have
> prioritized
> testing other software either, that's for sure!
>
> The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg
> init-file and the transformation should work as expected. A proper fix will
> come in 5.0.1 around April 1st. I hope you all will continue to use
> PROJ 5.0.0
> in your development builds despite this problem so other bugs can see the
> light of day and be fixed in time for 5.0.1.
>
> I completely agree with not requiring 5.0.0 as a dependency for QGIS.
> Hopefully
> 5.0.1 is a little better so that can be the recommended PROJ version for
> QGIS.
>
> I would like to encourage you to take a look at the release schedule [0]
> for the next
> couple of years. We are going to change things in order to keep up with
> current
> geodetic developments in countries such as Australia, USA and Iceland.
> It will
> affect QGIS sooner or later. I am of course happy to provide assistance
> where
> needed.
>
> /Kristian
>
> [0]
> https://github.com/OSGeo/proj.4/milestones?direction=asc&sort=due_date&state=open
>
> -Oprindelig meddelelse-
> Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På
> vegne af Jeff McKenna
> Sen
Re: [QGIS-Developer] proj5 and epsg:3857 ?
Kristian your are certainly not too blame at à personal level. this is the kind of this that happen inevitably given a certain amount of changes . i'm surprised that the GDAL autotest suite did not catch this but the cause is likely that the GDAL c++ class that wraps proj has an optimisation when transforming from 3857 to 4326. if you transform an array of points of the same northing they have the same latitude. this is a common case for gdalwarp internal mechanics. thus you need to do trigonometric computations just once! so proj is completely short circuited for that case. i'll add a test for the reverse transformation that uses proj (could receive a similar optimisation but isnt needed when warping unrectified imagery with RPC to WebMercator) Even --- Spatialys - Geospatial professional services http://www.spatialys.com Message d'origine De : Kristian Evers Date :09/03/2018 10:39 (GMT+01:00) À : qgis-developer@lists.osgeo.org Cc : Objet : Re: [QGIS-Developer] proj5 and epsg:3857 ? All, Just to follow up on this, since I am the one to blame for this error to show up. Both by introducing it in the first place and by releasing 5.0.0 with this as a known bug. The bug was introduced to fix a range of other potential issues. Unfortunately the architecture in the old API of PROJ makes it almost impossible to both treat other transformations correct while also treating the Web Mercator correctly. The problem is that the Web Mercator is, geodetically speaking, an abomination of a transformation. It basically defies all logic. This has been known for a long time of course. Unfortunately no tests were set up to catch this specific transformation. I'll make sure to at least add Jeff's test case. Regarding releasing the library with this bug included. The cause of the problem was determined very close to the release time (which was announced a month ahead). We did go through six release candidates. The vote for promotion of RC6 to final release was already started so I decided to release anyway since I did not want to prolong the process even more. I am sure this bug would have been discovered earlier if all of you QGIS developers would not have been super busy with QGIS 3.0 and had had some spare time to test the PROJ release candidates. I am not blaming anyone, it is just a case of bad timing. Not much we can do about that really. Had I been in your shoes I would not have prioritized testing other software either, that's for sure! The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg init-file and the transformation should work as expected. A proper fix will come in 5.0.1 around April 1st. I hope you all will continue to use PROJ 5.0.0 in your development builds despite this problem so other bugs can see the light of day and be fixed in time for 5.0.1. I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully 5.0.1 is a little better so that can be the recommended PROJ version for QGIS. I would like to encourage you to take a look at the release schedule [0] for the next couple of years. We are going to change things in order to keep up with current geodetic developments in countries such as Australia, USA and Iceland. It will affect QGIS sooner or later. I am of course happy to provide assistance where needed. /Kristian [0] https://github.com/OSGeo/proj.4/milestones?direction=asc&sort=due_date&state=open -Oprindelig meddelelse- Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af Jeff McKenna Sendt: 8. marts 2018 12:50 Til: qgis-developer@lists.osgeo.org Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ? Hi Richard, You can read my report to the PROJ team while I was testing the release candidates: http://lists.maptools.org/pipermail/proj/2018-February/008082.html Sorry, it is a long thread. I was trying to prevent (this here in QGIS, for example) from happening, before the release. -jeff On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote: > Hi, > > Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home > address, and reproject the epsg:28992 coordinate fine to epsg:3857. > > But since last week Debian has proj5, and the same plugin (in QGIS > master) now is off by 500 meter. > > To reproduce: if you have a QGIS 2.18 with proj4, and the > 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example > the osm xyz layer. > Now do the same in QGIS master with proj5 and you'll see it is not going > to the right/same position. > > Another observation: IN 2.18 I can 'reproject' the OSM layer to for > example epsg:4326, and still see (little distorted) map. > But in QGIS3/proj5 I do not see a map anymore. > > Anybody else seeing this? > > Regards, > > Richard Duivenvoorde ___
Re: [QGIS-Developer] proj5 and epsg:3857 ?
All, Just to follow up on this, since I am the one to blame for this error to show up. Both by introducing it in the first place and by releasing 5.0.0 with this as a known bug. The bug was introduced to fix a range of other potential issues. Unfortunately the architecture in the old API of PROJ makes it almost impossible to both treat other transformations correct while also treating the Web Mercator correctly. The problem is that the Web Mercator is, geodetically speaking, an abomination of a transformation. It basically defies all logic. This has been known for a long time of course. Unfortunately no tests were set up to catch this specific transformation. I'll make sure to at least add Jeff's test case. Regarding releasing the library with this bug included. The cause of the problem was determined very close to the release time (which was announced a month ahead). We did go through six release candidates. The vote for promotion of RC6 to final release was already started so I decided to release anyway since I did not want to prolong the process even more. I am sure this bug would have been discovered earlier if all of you QGIS developers would not have been super busy with QGIS 3.0 and had had some spare time to test the PROJ release candidates. I am not blaming anyone, it is just a case of bad timing. Not much we can do about that really. Had I been in your shoes I would not have prioritized testing other software either, that's for sure! The problem has an easy fix. Remove the "+nadgrids=@null" from your epsg init-file and the transformation should work as expected. A proper fix will come in 5.0.1 around April 1st. I hope you all will continue to use PROJ 5.0.0 in your development builds despite this problem so other bugs can see the light of day and be fixed in time for 5.0.1. I completely agree with not requiring 5.0.0 as a dependency for QGIS. Hopefully 5.0.1 is a little better so that can be the recommended PROJ version for QGIS. I would like to encourage you to take a look at the release schedule [0] for the next couple of years. We are going to change things in order to keep up with current geodetic developments in countries such as Australia, USA and Iceland. It will affect QGIS sooner or later. I am of course happy to provide assistance where needed. /Kristian [0] https://github.com/OSGeo/proj.4/milestones?direction=asc&sort=due_date&state=open -Oprindelig meddelelse- Fra: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] På vegne af Jeff McKenna Sendt: 8. marts 2018 12:50 Til: qgis-developer@lists.osgeo.org Emne: Re: [QGIS-Developer] proj5 and epsg:3857 ? Hi Richard, You can read my report to the PROJ team while I was testing the release candidates: http://lists.maptools.org/pipermail/proj/2018-February/008082.html Sorry, it is a long thread. I was trying to prevent (this here in QGIS, for example) from happening, before the release. -jeff On 2018-03-07 4:13 PM, Richard Duivenvoorde wrote: > Hi, > > Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home > address, and reproject the epsg:28992 coordinate fine to epsg:3857. > > But since last week Debian has proj5, and the same plugin (in QGIS > master) now is off by 500 meter. > > To reproduce: if you have a QGIS 2.18 with proj4, and the > 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example > the osm xyz layer. > Now do the same in QGIS master with proj5 and you'll see it is not going > to the right/same position. > > Another observation: IN 2.18 I can 'reproject' the OSM layer to for > example epsg:4326, and still see (little distorted) map. > But in QGIS3/proj5 I do not see a map anymore. > > Anybody else seeing this? > > 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] proj5 and epsg:3857 ?
Hi Tobias, On Thu, 08. Mar 2018 at 10:07:02 +0100, Tobias Wendorff wrote: > Can anyone forward this to osgeo4w-dev please? No need. 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] proj5 and epsg:3857 ?
Can anyone forward this to osgeo4w-dev please? -- Von einem iPhone gesendet und wird daher Fehler enthalten… Am 08.03.2018 um 09:49 schrieb Even Rouault : > > But given we know this is an issue now, we should not distribute this > > further to Windows users/osgeo4w who are NOT running a testing setup. > > Or, good thing with open source, don't wait for official release and apply > the patch that fixes the issue : > https://github.com/OSGeo/proj.4/pull/830.diff > > 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 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] proj5 and epsg:3857 ?
> But given we know this is an issue now, we should not distribute this > further to Windows users/osgeo4w who are NOT running a testing setup. Or, good thing with open source, don't wait for official release and apply the patch that fixes the issue : https://github.com/OSGeo/proj.4/pull/830.diff 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] proj5 and epsg:3857 ?
On 08-03-18 09:05, Bas Couwenberg wrote: > On 2018-03-08 08:43, Richard Duivenvoorde wrote: >> As we have OSM xyz layer now, and I think a lot of people will use it as >> a quick reference map, we should be carefull to include proj5 in >> distributions/installs then I think? >> >> Like: let's not put proj5 as default in Osgeo4w untill this is >> fixed/released. > > When distributions don't adopt proj 5.0.0 it won't get much real world > usage and hence won't uncover other regressions that should be fixed in > the next release. > > There were many release candidates, but only a handful of testers. > > OSGeo projects should get more involved testing new core library release > candidates to catch regressions like these earlier. I mostly agree: /me running Debian sid is supposed to hit this. I'm ok with it. But given we know this is an issue now, we should not distribute this further to Windows users/osgeo4w who are NOT running a testing setup. More testing is always better. But for users/end-users it is pretty hard to keep testing all functionality in all packages used. These bugs just hit you when you use them. Regards, Richard ___ 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] proj5 and epsg:3857 ?
On 2018-03-08 08:43, Richard Duivenvoorde wrote: As we have OSM xyz layer now, and I think a lot of people will use it as a quick reference map, we should be carefull to include proj5 in distributions/installs then I think? Like: let's not put proj5 as default in Osgeo4w untill this is fixed/released. When distributions don't adopt proj 5.0.0 it won't get much real world usage and hence won't uncover other regressions that should be fixed in the next release. There were many release candidates, but only a handful of testers. OSGeo projects should get more involved testing new core library release candidates to catch regressions like these earlier. Kind Regards, Bas ___ 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] proj5 and epsg:3857 ?
On 07-03-18 21:18, Even Rouault wrote: > On mercredi 7 mars 2018 21:13:36 CET Richard Duivenvoorde wrote: >> Hi, > >> Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home > >> address, and reproject the epsg:28992 coordinate fine to epsg:3857. > >> But since last week Debian has proj5, and the same plugin (in QGIS >> master) now is off by 500 meter. > > This is a known issue of proj 5.0.0. > https://github.com/OSGeo/proj.4/issues/834 > > Will be fixed in proj 5.0.1 supposedly released around April Ouch... Ok, thanks for the quick answer. As we have OSM xyz layer now, and I think a lot of people will use it as a quick reference map, we should be carefull to include proj5 in distributions/installs then I think? Like: let's not put proj5 as default in Osgeo4w untill this is fixed/released. 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] proj5 and epsg:3857 ?
On mercredi 7 mars 2018 21:13:36 CET Richard Duivenvoorde wrote: > Hi, > > Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home > address, and reproject the epsg:28992 coordinate fine to epsg:3857. > > But since last week Debian has proj5, and the same plugin (in QGIS > master) now is off by 500 meter. This is a known issue of proj 5.0.0. https://github.com/OSGeo/proj.4/issues/834 Will be fixed in proj 5.0.1 supposedly released around April > > To reproduce: if you have a QGIS 2.18 with proj4, and the > 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example > the osm xyz layer. > Now do the same in QGIS master with proj5 and you'll see it is not going > to the right/same position. > > Another observation: IN 2.18 I can 'reproject' the OSM layer to for > example epsg:4326, and still see (little distorted) map. > But in QGIS3/proj5 I do not see a map anymore. > > Anybody else seeing this? > > 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 -- 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] proj5 and epsg:3857 ?
Now I look in the terminal, and I see this text looping for ever: src/core/raster/qgsrasterprojector.cpp: 440: (preciseSrcRowCol) [0ms] theDestRow = 602 src/core/raster/qgsrasterprojector.cpp: 459: (preciseSrcRowCol) [0ms] x = 514940 y = 6.83887e+6 src/core/raster/qgsrasterprojector.cpp: 441: (preciseSrcRowCol) [0ms] theDestRow = 602 mDestExtent.yMaximum() = 52.4154 mDestYRes = 3.60873e-5 src/core/raster/qgsrasterprojector.cpp: 470: (preciseSrcRowCol) [0ms] mSrcExtent.yMinimum() = 6.83526e+6 mSrcExtent.yMaximum() = 6.8428e+6 mSrcYRes = 6.17316 src/core/raster/qgsrasterprojector.cpp: 450: (preciseSrcRowCol) [0ms] x = 4.66475 y = 52.3936 src/core/raster/qgsrasterprojector.cpp: 471: (preciseSrcRowCol) [0ms] theSrcRow = 636 srcCol = 120 src/core/raster/qgsrasterprojector.cpp: 459: (preciseSrcRowCol) [0ms] x = 519278 y = 6.83772e+6 src/core/raster/qgsrasterprojector.cpp: 440: (preciseSrcRowCol) [0ms] theDestRow = 477 src/core/raster/qgsrasterprojector.cpp: 470: (preciseSrcRowCol) [0ms] mSrcExtent.yMinimum() = 6.83566e+6 mSrcExtent.yMaximum() = 6.84168e+6 mSrcYRes = 4.92686 src/core/raster/qgsrasterprojector.cpp: 471: (preciseSrcRowCol) [0ms] theSrcRow = 803 srcCol = 924 src/core/raster/qgsrasterprojector.cpp: 441: (preciseSrcRowCol) [0ms] theDestRow = 477 mDestExtent.yMaximum() = 52.4216 mDestYRes = 4.52139e-5 src/core/raster/qgsrasterprojector.cpp: 440: (preciseSrcRowCol) [0ms] theDestRow = 602 src/core/raster/qgsrasterprojector.cpp: 450: (preciseSrcRowCol) [0ms] x = 4.62583 y = 52.4 On 07-03-18 21:13, Richard Duivenvoorde wrote: > Hi, > > Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home > address, and reproject the epsg:28992 coordinate fine to epsg:3857. > > But since last week Debian has proj5, and the same plugin (in QGIS > master) now is off by 500 meter. > > To reproduce: if you have a QGIS 2.18 with proj4, and the > 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example > the osm xyz layer. > Now do the same in QGIS master with proj5 and you'll see it is not going > to the right/same position. > > Another observation: IN 2.18 I can 'reproject' the OSM layer to for > example epsg:4326, and still see (little distorted) map. > But in QGIS3/proj5 I do not see a map anymore. > > Anybody else seeing this? > > Regards, > > Richard Duivenvoorde > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] proj5 and epsg:3857 ?
Hi, Having a geocoder plugins, in 2.18 (still proj4), I can geocode my home address, and reproject the epsg:28992 coordinate fine to epsg:3857. But since last week Debian has proj5, and the same plugin (in QGIS master) now is off by 500 meter. To reproduce: if you have a QGIS 2.18 with proj4, and the 'pdokservicesplugin' geocode the zip+number: '2022zj 23' in for example the osm xyz layer. Now do the same in QGIS master with proj5 and you'll see it is not going to the right/same position. Another observation: IN 2.18 I can 'reproject' the OSM layer to for example epsg:4326, and still see (little distorted) map. But in QGIS3/proj5 I do not see a map anymore. Anybody else seeing this? 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
