Application: gvSIG desktop

He comparado el INSERT que hacemos en la base de datos en el script y no he encontrado diferencias con los datos definidos en http://spatialreference.org/ref/epsg/ch1903-lv03/

Exploring the INSERT statements in gvSIG\plugins\org.gvsig.projection.app.jcrs\db\EPSG.sql it seems that we are working with the version 6.14 (2007) of EPSG Geodetic Parameter Registry, instead of 8.4.1 (2014) (http://www.epsg-registry.org/):

(41,'2007-09-02','6.14','Version 6.14 release.','','6.13')

That's why we have several open tickets on CRSs and their transformations (#1371, #2306, #2389, #2455 and #2596).

I can confirm this issue. It's not possible to assign EPSG:21781 to a view. It happens with the latest version of EPSG Registry too (#2306). Although, the warning message is different:

java.lang.Exception: The projection'Hotine_Oblique_Mercator_(variant_B)' is not a proj4 projection.

And again there's not trace of this issue in the gvSIG.log. It looks like the Hotine_Oblique_Mercator(variant_B)_ is not well managed by gvSIG (and GeoTools in the past). For instance, see http://jira.codehaus.org/browse/GEOT-4438

Further info: if I search 21781 code in the EPSG repository of "New CRS" dialog and then click on the Info button, I can see that is not available the PROJ.4 string and then this error appears in the console of log messages:

Can't get proj4 string. org.gvsig.crs.CrsException: java.lang.Exception: The projection'Hotine_Oblique_Mercator_(variant_B)' is not a proj4 projection. 
    org.gvsig.crs.Proj4.exportToProj4(Proj4.java:3170)     
    org.gvsig.crs.Crs.getProj4String(Crs.java:706)
    org.gvsig.crs.gui.panels.InfoCRSPanel.createPage(InfoCRSPanel.java:561)
    org.gvsig.crs.gui.panels.InfoCRSPanel.inicializate(InfoCRSPanel.java:171)
    org.gvsig.crs.gui.panels.InfoCRSPanel. (InfoCRSPanel.java:133)
    org.gvsig.crs.gui.panels.EPSGpanel.actionPerformed(EPSGpanel.java:786)
    [...]

So this projection should be remapped as "Oblique Mercator" in order to be translatable in PROJ.4 format.

'Hotine_Oblique_Mercator_(variant_B)' is a new alias of 'Oblique Mercator' (see EPSG:9815). So, in order to remap 'Hotine_Oblique_Mercator_(variant_B)' as 'Oblique Mercator', I believe that we should add a new alias of 'Oblique Mercator' in the org.gvsig.crs.Proj4 class:

    String[] projectionName = { "Oblique_Mercator" };
    this.projectionNameList.add(count, projectionName);
    addProjectionName(count, "Oblique Mercator");
    addProjectionName(count, "9815");
    addProjectionName(count, "CT_ObliqueMercator");
    addProjectionName(count, "Hotine_Oblique_Mercator_Azimuth_Center");
    addProjectionName(count, "Rectified_Skew_Orthomorphic_Center");
    addProjectionName(count, "Hotine Oblique Mercator");
    addProjectionName(count, "Hotine_Oblique_Mercator");
    addProjectionName(count, "Hotine_Oblique_Mercator_(variant_B)"); // <---------------

This one should be the trick to recognize the projections (different from Web Mercator) with new alias which cause the "Can't get proj4 string" (e.g. #2371) kind of errors.

Muchas gracias por el aporte... en el proximo build de jcrs estara

gvsig-jcrs:r245

This is an old problem in gvSIG, as documented here:
http://osgeo-org.1560.x6.nabble.com/Problems-with-EPSG-21781-td4111081.html

The CRSexception "In proj4 projection 'Oblique_Mercator' not allow azimut close to 90" occurs because there's a strict check of projection parameters in the org.gvsig.crs.Proj4 class, in detail:

if (gtParameterName.equalsIgnoreCase("azimuth"))
          {
            valueAlpha = Double.parseDouble(gtParameterValues[j]);
            if (Math.abs(valueAlpha - 90.0) < 0.0001)
            {
              throw new CrsException(new Exception("In proj4 projection 'Oblique_Mercator' not allow azimut close to 90"));
            }

It happens because the azimuth of EPSG:21781 is equal right to 90°. Consequently the Proj4 class can't generate its Proj4 format...

So a workaround (aka not elegant solution) could consist into bypass the above mentioned strict check of projection parameters and hardcode in some manner the Proj.4 string of this CRS. Any other idea?

From GeoTools javadocs (http://docs.geotools.org/latest/javadocs/org/geotools/referencing/operation/projection/ObliqueMercator.html):

Azimuth values of 0.0 and ±90.0 degrees are allowed (and used in Hungary and Switzerland), 
though these cases would usually use a Mercator or Transverse Mercator projection instead. 
Azimuth values > 90 degrees cause errors in the equations.

So the strict check reported above should be formulated differently. For instance:

if (gtParameterName.equalsIgnoreCase("azimuth"))
          {
            valueAlpha = Double.parseDouble(gtParameterValues[j]);
            //if (Math.abs(valueAlpha - 90.0) < 0.0001)
            if (valueAlpha > 90.0)
            {
              //throw new CrsException(new Exception("In proj4 projection 'Oblique_Mercator' not allow azimut close to 90"));
              throw new CrsException(new Exception("In proj4 projection 'Oblique_Mercator' azimut values > 90 are not allowed"));
            }

If this doesn't work as expected because of calculation errors (e.g. tan 90° is infinite), we can set valueAlpha = 89.9999 as suggested here: http://osgeo-org.1560.x6.nabble.com/Problems-with-EPSG-21781-td4111081.html

I've just attached a cumulative patch of Proj4 class in #2738 that allows to set EPSG:21781 as a view CRS.
Unlocking this feature, other issues appear, like the Proj4 string that is not right.

gvSIG Proj4 String:

+proj=omerc +lat_0=46.95240555555556 +lonc=7.439583333333333 +k=1.0 +x_0=600000.0 +y_0=200000.0 +ellps=bessel

+proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel 
+towgs84=674.4,15.1,405.3,0,0,0,0 +units=m +no_defs

I've extended the correction of the proj4 strings to all the Swiss Oblique Mercator CRSs (not only EPSG:21781) in #2813, so don't consider Proj_EPSG21781.patch attached here. Consequently this ticket is followed by #2813.