gvSIG bugs #2738

EPSG:3857 Proj4 representation is not correct

Added by Antonio Falciano almost 10 years ago. Updated over 9 years ago.

Status:Closed% Done:

0%

Priority:NormalSpent time:-
Assignee:Joaquín del Cerro Murciano
Category:CRS
Target version:-
Severity:Major Add-on version:
gvSIG version:2.1.0 Add-on build:
gvSIG build:2239 Add-on resolve version:
Operative System: Add-on resolve build:
Keywords:3857, web_mercator, proj4 Proyecto:
Has patch:Yes Hito:
Add-on name:

Description

After #1371, #2306 and gvsig-jcrs:r246, the EPSG:3857 Proj4 representation is now the following:

+proj=merc +lon_0=0.0 +lat_ts=0.0 +x_0=0.0 +y_0=0.0 +a=6378137.0 +b=6378137.0 +ellps=WGS84

while it should be something like this (skipping +nadgrids, +wktext and +no_defs, not used by the org.gvsig.crs.Proj4 class):

+proj=merc +lon_0=0.0 +lat_ts=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +a=6378137 +b=6378137 +units=m

Instead, this is how the USR:3857 CRS Proj.4 string is defined:

+proj=merc +lon_0=0.0 +k=1 +x_0=0 +y_0=0 +R=6378137.0

In detail, the missing scale factor (+k=1.0) is not a problem, while +ellps=WGS84 should override the semiaxis definition.

Proj4.patch Magnifier (10.5 KB) Antonio Falciano, 09/01/2014 01:03 PM

Related issues

Related to Application: gvSIG desktop - gvSIG bugs #2739: Conversion between EPSG:3857 and EPSG:4326 doesn't match Closed 07/29/2014

History

#1 Updated by Álvaro Anguix almost 10 years ago

  • Related to gvSIG bugs #2739: Conversion between EPSG:3857 and EPSG:4326 doesn't match added

#2 Updated by Álvaro Anguix almost 10 years ago

  • Assignee set to Joaquín del Cerro Murciano

#3 Updated by Antonio Falciano over 9 years ago

Being Web Mercator (EPSG:3857) a single projection, I think that we could simply hardcode its Proj4 definition. For instance, in the Proj4.class:

public String exportToProj4(CoordinateReferenceSystem crs) throws CrsException
{
    // a lot of stuff here...

    if (projectionAcronym[0].equals("merc"))
    {
        // other stuff here...

        if (projectionName.equalsIgnoreCase("Popular_Visualisation_Pseudo_Mercator"))
            isWmerc = true;
    }

    // other stuff here...

    if (isWmerc)
        strProj4 = "+proj=merc +lon_0=0.0 +lat_ts=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +R=6378137.0 +units=m ";

}

#4 Updated by Antonio Falciano over 9 years ago

I attach a patch that fixes this issue ...and also #2664 and #2596 (only partially).
The right Proj4 string of EPSG:3857 doesn't solve the other related issues (e.g. #2739) without the upgrade of libjni-proj4 (crsjniproj), because the conversion between EPSG:3857 and EPSG:4326 is actually not managed at all.

#5 Updated by Joaquín del Cerro Murciano over 9 years ago

  • Target version set to 2.1.0-2259-rc3
  • Assignee changed from Joaquín del Cerro Murciano to Francisco Díaz Carsí

#6 Updated by Francisco Díaz Carsí over 9 years ago

  • Target version deleted (2.1.0-2259-rc3)
  • Assignee changed from Francisco Díaz Carsí to Joaquín del Cerro Murciano
  • Status changed from New to Fixed

Se ha aplicado el parche suministrado, y los cambios serán efectivos en el siguiente build de jcrs (2064)

#7 Updated by Antonio Falciano over 9 years ago

Francisco, thank you very much for gvsig-jcrs:r263. It's only a little piece of the whole puzzle. ;)

#8 Updated by Álvaro Anguix over 9 years ago

  • Has patch set to Yes

#9 Updated by Antonio Falciano over 9 years ago

  • Status changed from Fixed to Closed

Also available in: Atom PDF