gvSIG bugs #4174

If a new gvSIG version has a new JCRS library it would have to run the new one by default

Added by Mario Carrera about 8 years ago. Updated over 6 years ago.

Status:Won't fix% Done:

0%

Priority:HighSpent time:-
Assignee:-
Category:Installer
Target version:2.4.0-2838 (rev. org.gvsig.desktop-2.0.205)
Severity:Minor Add-on version:
gvSIG version:2.3.0 Add-on build:
gvSIG build:2425 Add-on resolve version:
Operative System: Add-on resolve build:
Keywords: Proyecto:
Has patch: Hito:
Add-on name:Unknown

Description

If we have gvSIG 2.2 it runs with JCRS 6 library. If we install gvSIG 2.3 after that, a new JCRS library is installed (8.7 version), but gvSIG runs the old one because it's at the Preferences menu.

If a new gvSIG version includes a new JCRS library it would have to be executed with the new one. It would have to change it at the Preferences by default.

History

#1 Updated by Antonio Falciano about 8 years ago

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

Hi Mario,
I'm agree with you. Just for clarity, jCRS uses the EPSG Registry v. 8.7 by default (#3488) in gvSIG 2.2, while it should use the EPSG Registry v. 8.8 in gvSIG 2.3 after #4029, even if I don't see it in the Preferences of jCRS or in the testing repository yet.

#2 Updated by Antonio Falciano about 8 years ago

Build 2426 uses the EPSG Registry v. 8.8 by default yet (gvsig-jcrs:r530), but it calls v. 8.7... So it's only a cosmetic issue at the moment. ;)

#3 Updated by Joaquín del Cerro Murciano over 7 years ago

  • Target version changed from 2.3.0-2447-final (rev. org.gvsig.desktop-2.0.153) to 2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220)

#4 Updated by Álvaro Anguix almost 7 years ago

  • Target version deleted (2.4.0-2850-final (rev. org.gvsig.desktop-2.0.220))

#5 Updated by Antonio Falciano over 6 years ago

  • Target version set to 2.4.0-2838 (rev. org.gvsig.desktop-2.0.205)
  • Status changed from New to Won't fix

Let me to clarify something on this ticket. After the release of gvSIG 2.3.0 and so with the GDAL usage, if a new gvSIG version includes an update of the EPSG Registry (e.g. 9.0) and we try to use it with an older gvSIG version (e.g. 2.3.1 or 2.2.0), there could be some misalignments between the EPSG Registry and the GDAL data in relation to the new CRSs introduced by the first one. So I'd avoid to do it limiting the maximum EPSG Registry version usable in a specific gvSIG one. On the other side, it's possible to use a newer version of the EPSG Registry in an older gvSIG one, but you should also update the gdal-data folder in org.gvsig.gdal.app.mainplugin manually. Better to update gvSIG directly! ;-)
I'd set this ticket as "Won't fix" (if you are agree), because it's not possible to introduce the whole correct behaviour in older version of gvSIG.

Also available in: Atom PDF