[QGIS-Developer] proj5 and epsg:3857 ?

Fri Mar 9 03:19:09 PST 2018

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 <kreve at sdfe.dk>
> Date :09/03/2018 10:39 (GMT+01:00)
> À : qgis-developer at 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-bounces at lists.osgeo.org] På
> vegne af Jeff McKenna
> Sendt: 8. marts 2018 12:50
> Til: qgis-developer at 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 at 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 at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 