Kristian Evers-2 wrote >> On 25 Mar 2018, at 21:15, Helmut Kudrnovsky <
> hellik@ > > wrote: >> >> Kristian Evers-2 wrote >>> There’s already a ticket for this: >>> https://trac.osgeo.org/osgeo4w/ticket/558 >>> >>> The bug you are referring to is not fixed in PROJ 5.0.0 so an update >>> will >>> not really help you in that regard. Best option for that is to use >>> 4.9.3. >>> A >>> bug fix release is on its way though, so when that is out it should be >>> safe >>> to update the OSGeo4W PROJ package and have it as the default. >>> >>> /Kristian >> >> for the record, GRASS trunk is PROJ 5 ready: > > Very cool! I wasn’t aware of that. > >> >> https://lists.osgeo.org/pipermail/grass-user/2018-March/078023.html >> >> https://lists.osgeo.org/pipermail/grass-commit/2018-March/043391.html >> to >> https://lists.osgeo.org/pipermail/grass-commit/2018-March/043408.html >> >> Log: >> libproj: +new GRASS API for coordinate transformation >> >> this isn't backported to the 7.4.-release branch, not sure it will ever >> be. >> >> so it could be that GRASS 7.4.-release branch has to live with 4.9.3 for >> a >> while. > > The API from PROJ 4 lives on in PROJ 5, so GRASS 7.4 should be able to use > PROJ 5 as well. We’ve been carefull not to breaking anything with this > release. > That comes with PROJ 6 and 7. Of course there might be implementation > details > in GRASS that I am unaware of that makes using PROJ 5 impossible. > >> >> >> >> ----- >> best regards >> Helmut >> -- >> Sent from: >> http://osgeo-org.1560.x6.nabble.com/osgeo4w-dev-OSGeo-Win32-Installer-List-f3765018.html >> _______________________________________________ >> osgeo4w-dev mailing list >> > [email protected] >> https://lists.osgeo.org/mailman/listinfo/osgeo4w-dev > > _______________________________________________ > osgeo4w-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/osgeo4w-dev See https://lists.osgeo.org/pipermail/grass-dev/2018-March/088123.html ----- There is an important difference between the PROJ4 and the PROJ5+ API/syntax: The old PROJ4 API uses latlong WGS84 as pivot datum for coordinate transformations like projection1 -> latlong WGS84 -> projection2 or in '+to' syntax projection1 +to projection2 The new PROJ5+ API no longer uses a pivot datum. The advantage is that you can directly convert from one datum to another, without going through WGS84. The disadvantage is that the user/software using the new API has to make sure that either a common pivot datum is used or coordinates are correctly transformed from one datum to another, e.g. with a Helmert Transform. Both GDAL and GRASS have implemented the new API as a simple 2-step pipeline like 1. projection1 -> some latlong 2. some latlong -> projection2 or in pipeline syntax +proj=pipeline +step +inv projection1 +step projection2 Even Rouault has done some tests and found sometimes subtle differences in the results between the old and new API/syntax. Further on, there is no mechanism (yet) in place to validate the pipeline, most importantly that the output of step 1 conforms to the required input for step 2. IMHO, the implementation of the new PROJ5+ API/syntax in GDAL and GRASS should be regarded as experimental and testing by as many people as possible would be a huge benefit to PROJ/GDAL/GRASS and to all applications using these projects. Markus M ------------------- ----- best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/osgeo4w-dev-OSGeo-Win32-Installer-List-f3765018.html _______________________________________________ osgeo4w-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
