Incorrect input values

[ebocher]

in this case :

select ST_AsText(ST_Transform(ST_SetSRID(ST_Point(379550.883, 1815125.223), 4326), 2154))

CTS must throw an error like

The projection X supports only latitude and longitude values.

[ebocher]

Dear @mukoki Imagine the following test

@Test
    public void testFrenchEPSGCodeFrom4326To27582WrongCoordinates() throws Exception {
        String csNameSrc = "EPSG:4326"; //Input EPSG
        double[] pointSource = new double[]{284173.736, 3594514.828};
        String csNameDest = "EPSG:27582";  //Target EPSG lambert 2 etendu france
        double[] pointDest = new double[]{584173.736, 2594514.828};
        double tolerance = 10E-3;
        CoordinateReferenceSystem inputCRS = cRSFactory.getCRS(csNameSrc);
        CoordinateReferenceSystem outputCRS = cRSFactory.getCRS(csNameDest);
        verbose = true;
        double[] result = transform((GeodeticCRS) inputCRS, (GeodeticCRS) outputCRS, pointSource);
        ->> Must throw an error because the input coordinates are not expressed in LAT/LONG
    }

Do we need to test if the input coordinates are in the good x, y range for each transform operations ?

[mukoki]

Erwan,

Here are some hints about this problem Model In CTS, the class which could help to check if input values are valid is org.cts.cs.Extent. Extent is an attribute of Datum. It is not used currently. In EPSG database "Area of use" is also used by CoordinateReferenceSystem and by CoordinateOperation. I think I implemented Extent in Datum and not in CRS for bad reasons. It would probably makes sense to have it in CRS too. Area of use definition One of the main reason it is currently not used in code is that area of use is not defined in registry files and generally not in WKT representation. But it seems it "can" be defined in WKT. Another difficulty is that Area of use is sometimes defined as a named area (ex. France, World...) and sometimes by a bounding box (may be by a polygon). Using a bounding box in the library seems doable, using named area is more difficult. Finally, there is the question of the CoordinateReferenceSystem used by the area definition itself. If the area is expressed in the same CRS as the CRS it defines, it is easy to check input coordinates validity, but often, bounding box is in geographic coordinates (in wkt, it is required that it is in decimal degrees). In France, area of use is generally defined in geographic coordinates, but it maybe in grades. Having bounding box in geographic coordinates means that we must first convert input coordinates to know if we can convert it ! Usage Once it is implemented and initialized, I think we can find a way to use it to check input validity. But if it is stored in geographic coordinates, there is an unchecked conversion to perform first. May be we must be able to initialize extent information from geographic coordinates (WKT compatibility), but store it in the local CRS so that conversion is made only once, and not for each coordinate. Conclusion The simplest and more efficient way I can see to add the kind of check you want is to

• add an Extent object to CRS
• add a way to initialize this Extent object directly (from local coordinates) or from a bounding box in decimal degrees
• add a method to check input validity (and output validity ?) again this extent if it is defined.
• anyway, we must be able to initialize this information (probably available in EPSG database) as we do not have it in registry files currently.

[ebocher]

Dear @mukoki My apologies for this long delay. Thank you for this detailed explanation. I will keep in mind the idea of adding an Extent object to CRS. Maybe to be planned in version 1.6 of CTS Cheers