gvSIG bugs #3954

prj file with 3857 WKT not working

Added by Andrea Antonello over 8 years ago. Updated over 7 years ago.

Status:Closed% Done:

0%

Priority:NormalSpent time:-
Assignee:-
Category:CRS
Target version:2.3.0-2445 (rev. org.gvsig.desktop-2.0.152)
Severity:Minor Add-on version:
gvSIG version:2.3.0 Add-on build:
gvSIG build:2412 Add-on resolve version:
Operative System: Add-on resolve build:
Keywords: Proyecto:
Has patch: Hito:
Add-on name:Unknown

Description

I am having issues loading a shapefile with the attached prj file.

The content is a standard WKT of the projection 3857. Tested on the lastest devel build downloaded yesterday (sorry, I am out of office and have no link to look the exact number).

The shapefile is not loaded and the status bar tells me that it doesn't recognise the SRS.

non_working_3857.prj (749 Bytes) Andrea Antonello, 12/22/2015 02:16 PM

gvSIG.log (386 KB) Antonio Falciano, 12/28/2015 04:27 PM

ESRI_3857.prj (547 Bytes) Francisco Díaz Carsí, 01/29/2016 11:38 AM


Related issues

Related to Application: gvSIG desktop - gvSIG bugs #4235: Error reprojecting vector layers in 3857 Closed 06/20/2016

Associated revisions

Revision 493
Added by Francisco Díaz Carsí over 8 years ago

refs: #3954
- Parcheada la exportación de las proyecciones para que cuando se le pide que sea en formato de ESRI lo haga en WKT estandar.
- Capada la importación de las proyecciones a partir de la cadena WKT-ESRI si la librería no es capaz de Autoidentificar el código EPSG correspondiente.

History

#1 Updated by Álvaro Anguix over 8 years ago

  • gvSIG build set to 2412
  • Assignee set to Francisco Díaz Carsí

#2 Updated by Antonio Falciano over 8 years ago

Hi all,
I confirm the issue reported by Andrea at least in build 2413 win 64 bits. I attach the gvSIG.log.

#3 Updated by Antonio Falciano over 8 years ago

It seems that also other prj files are not recognized.

#4 Updated by Antonio Falciano over 8 years ago

Update (build 2414)

It's possible to add a layer defined in EPSG:3857 now, but there are two different related issues:
  1. its geometries are not correctly reprojected on the fly (see #2739);
  2. EPSG:3857 (but also other CRSs) is not identified in the Add layer window, near the "(reprojected on the fly" text, because the following error occurs
    ERROR AWT-EventQueue-0 org.gvsig.crs.Crs - Can't autoidentifyEPSG.
    java.lang.RuntimeException: OGR Error: Unsupported SRS
        at org.gdal.osr.osrJNI.SpatialReference_AutoIdentifyEPSG(Native Method)
        at org.gdal.osr.SpatialReference.AutoIdentifyEPSG(SpatialReference.java:247)
        at org.gvsig.crs.Crs.initFromSpatialReference(Crs.java:113)
        at org.gvsig.crs.Crs.<init>(Crs.java:100)
        [...]
    

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

  • Target version set to 2.3.0-2447-final (rev. org.gvsig.desktop-2.0.153)

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

  • Target version changed from 2.3.0-2447-final (rev. org.gvsig.desktop-2.0.153) to 2.3.0-2417 (rev. org.gvsig.desktop-2.0.123)
  • Status changed from New to Fixed

No es directa la identificación del código EPSG a partir de una cadena WKT-ESRI que suele ser el contenido de los archivos .prj por lo que podemos no ser capaces de crear una proyección completa a partir de los datos suministrados por el WKT-ESRI.

Así pues, hemos decidido tomar una solución salomónica hasta que veamos una posibilidad viable de hacerlo con WKT-ESRI.

1º Cuando creemos nosotros un archivo .prj, el contenido será el del WKT estandar de la proyección (éste sí podemos leerlo sin problemas)
2º Cuando abrimos un archivo con un .prj asociado (esté en formato WKT estandar o en WKT-ESRI) si somos capaces de reconocer la "authority" de la proyección se la asignaremos a la capa, pero si no, no le asignamos ninguna proyección a la capa haciendo caso omiso del archivo prj. En este último caso deberá el usuario asignar la proyección a la capa como se hacía antes de poder leer archivos prj.

He probado el prj adjunto y sí he podido utilizarlo para asignar la proyección a la capa.

#7 Updated by Antonio Falciano over 8 years ago

Hi all,
gdalsrsinfo could be our friend here... A great advantage of using GDAL/OGR libraries is that we can do all it does. So if a projection file (usually ESRI WKT, sometimes OGC WKT) is parsed by gdalsrsinfo correctly, it should be readable by gvSIG. But the AUTHORITY tag is available only in the full OGC WKT.

For instance:

gdalsrsinfo -o wkt_all non_working_3857.prj

OGC WKT :
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84",6378137.0,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0.0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.017453292519943295],
        AXIS["Geodetic longitude",EAST],
        AXIS["Geodetic latitude",NORTH],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Popular Visualisation Pseudo Mercator",
        AUTHORITY["EPSG","1024"]],
    PARAMETER["semi_minor",6378137.0],
    PARAMETER["latitude_of_origin",0.0],
    PARAMETER["central_meridian",0.0],
    PARAMETER["scale_factor",1.0],
    PARAMETER["false_easting",0.0],
    PARAMETER["false_northing",0.0],
    UNIT["m",1.0],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","3857"]]

OGC WKT (simple) :
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84",6378137.0,298.257223563]],
        PRIMEM["Greenwich",0.0],
        UNIT["degree",0.017453292519943295]],
    PROJECTION["Popular Visualisation Pseudo Mercator"],
    PARAMETER["semi_minor",6378137.0],
    PARAMETER["latitude_of_origin",0.0],
    PARAMETER["central_meridian",0.0],
    PARAMETER["scale_factor",1.0],
    PARAMETER["false_easting",0.0],
    PARAMETER["false_northing",0.0],
    UNIT["m",1.0]]

OGC WKT (no CT) :
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84",6378137.0,298.257223563]],
        PRIMEM["Greenwich",0.0],
        UNIT["degree",0.017453292519943295]],
    PROJECTION["Popular Visualisation Pseudo Mercator"],
    PARAMETER["semi_minor",6378137.0],
    PARAMETER["latitude_of_origin",0.0],
    PARAMETER["central_meridian",0.0],
    PARAMETER["scale_factor",1.0],
    PARAMETER["false_easting",0.0],
    PARAMETER["false_northing",0.0],
    UNIT["m",1.0]]

ESRI WKT :
PROJCS["WGS_84_Pseudo_Mercator",
    GEOGCS["GCS_WGS_1984",
        DATUM["D_World Geodetic System 1984",
            SPHEROID["WGS_1984",6378137.0,298.257223563]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Popular Visualisation Pseudo Mercator"],
    PARAMETER["semi_minor",6378137.0],
    PARAMETER["latitude_of_origin",0.0],
    PARAMETER["central_meridian",0.0],
    PARAMETER["scale_factor",1.0],
    PARAMETER["false_easting",0.0],
    PARAMETER["false_northing",0.0],
    UNIT["m",1.0]]

#8 Updated by Francisco Díaz Carsí over 8 years ago

Gracias Antonio,
pero el problema no está cuando viene un prj cuyo contenido es OGC-WKT,
el problema está cuando en el prj está el ESRI-WKT.

El archivo que adjuntó Andrea era del primer tipo, OGC-WKT, pero era otro el problema que hacía que no se cargase correctamente (el parseo de un número creo recordar).

Adjunto un archivo de este tipo, ESRI_3857.prj con el que podemos comprobar que gdalsrsinfo no es capaz de descubrir la AUTHORITY.
Es con este tipo de prj con los que tenemos problemas para identificar la AUTHORITY y, por tanto, hemos decidido que si no podemos hacerlo, mejor no hacer caso al archivo para asignar la proyección.

#9 Updated by Antonio Falciano over 8 years ago

Francisco Diaz wrote:

Gracias Antonio,
pero el problema no está cuando viene un prj cuyo contenido es OGC-WKT,
el problema está cuando en el prj está el ESRI-WKT.

Hi Francisco,
I'm agree with you... OGC WKT is easy to identify thanks to the AUTHORITY tag.

El archivo que adjuntó Andrea era del primer tipo, OGC-WKT, pero era otro el problema que hacía que no se cargase correctamente (el parseo de un número creo recordar).

Ok, the prj attached by Andrea (OGC WKT) is well recognized as EPSG:3857 in build 2417, but not reprojected on the fly because gvSIG isn't able to get the proj4 string from EPSG:3857 actually, so it's still not working.

Adjunto un archivo de este tipo, ESRI_3857.prj con el que podemos comprobar que gdalsrsinfo no es capaz de descubrir la AUTHORITY.

This is true for EPSG:3857 (ESRI WKT), because EPSG:3857 and EPSG:3395 (WGS 84 / World Mercator) have the same proj4 definition and their ESRI WKTs differ only for the name of the PROJCS. So it's not possible to identify the CRS univocally. Instead, EPSG:23030 (ESRI WKT) should be identified by gdalsrsinfo without problems.

Es con este tipo de prj con los que tenemos problemas para identificar la AUTHORITY y, por tanto, hemos decidido que si no podemos hacerlo, mejor no hacer caso al archivo para asignar la proyección.

It's a first approximation that solves the issue only in part. The problem is to convert EPSG:3857 (and also the other CRSs) in proj4 strings now and gdalsrsinfo is able to do it, without reinventing the wheel. ;-)

#10 Updated by Antonio Falciano over 8 years ago

Antonio Falciano wrote:

This is true for EPSG:3857 (ESRI WKT), because EPSG:3857 and EPSG:3395 (WGS 84 / World Mercator) have the same proj4 definition and their ESRI WKTs differ only for the name of the PROJCS. So it's not possible to identify the CRS univocally. Instead, EPSG:23030 (ESRI WKT) should be identified by gdalsrsinfo without problems.

EPSG:3857 and EPSG:3395 have different proj4 definition, sorry for the mistakes

#11 Updated by Álvaro Anguix over 8 years ago

  • Status changed from Fixed to Closed

#12 Updated by Antonio Falciano over 8 years ago

  • Target version changed from 2.3.0-2417 (rev. org.gvsig.desktop-2.0.123) to 2.3.0-2447-final (rev. org.gvsig.desktop-2.0.153)
  • Status changed from Closed to New

The prj attached by Andrea has the main AUTHORITY tag, it's identified now in the "Add layer" dialog, but if I associate it to a shape, it's still not working because the proj4 string can't be retrieved:

WARN AWT-EventQueue-0 org.gvsig.crs.Crs - Can't get proj4 string from EPSG:3857
java.lang.RuntimeException: OGR Error: Unsupported SRS
    at org.gdal.osr.osrJNI.SpatialReference_ExportToProj4(Native Method)
    [...]
ERROR Thread-12 org.gvsig.crs.Crs - Can't get proj4 string.
org.gvsig.crs.CrsException: java.lang.Exception: The projection'Popular Visualisation Pseudo Mercator' is not a proj4 projection.
    at org.gvsig.crs.Proj4.exportToProj4(Proj4.java:3241)
    [...]
Caused by: java.lang.Exception: The projection'Popular Visualisation Pseudo Mercator' is not a proj4 projection.
    ... 10 more
ERROR Thread-12 org.gvsig.fmap.geom.jts.primitive.Envelope2D - Unable to reproject envelope with transf: org.gvsig.crs.COperation@6b977201
[...]
The error is due to "Popular Visualisation Pseudo Mercator" alias that is not recognized as a proj4 projection. Maybe we need to add this alias in the org.gvsig.crs.Proj4 class, like we did in #2624 and #2664.

#13 Updated by Álvaro Anguix about 8 years ago

  • Target version deleted (2.3.0-2447-final (rev. org.gvsig.desktop-2.0.153))

#14 Updated by Joaquín del Cerro Murciano almost 8 years ago

  • Assignee deleted (Francisco Díaz Carsí)

#15 Updated by Antonio Falciano almost 8 years ago

Related to #4288 and #4290.

#16 Updated by Álvaro Anguix almost 8 years ago

#17 Updated by Antonio Falciano over 7 years ago

  • Target version set to 2.3.0-2445 (rev. org.gvsig.desktop-2.0.152)
  • Status changed from New to Fixed

Fixed together with #4288 and #4290.

#18 Updated by Antonio Falciano over 7 years ago

  • Status changed from Fixed to Closed

Also available in: Atom PDF