Hi Martin,
I've tried with IdentifiedObjects.newFinder, setting
finder.setIgnoringAxes(true), but I still could not find the
equivalent EPSG code.
String esri4326wkt =
"GEOGCS[\"GCS_WGS_1984\",DATUM[\"D_WGS_1984\",SPHEROID[\"WGS_1984\",6378137.0,298.257223563]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]]";
WKTFormat parser = new WKTFormat(null, null);
parser.setConvention(Convention.WKT1_COMMON_UNITS);
CoordinateReferenceSystem crs = (CoordinateReferenceSystem)
parser.parseObject(esri4326wkt);
IdentifiedObjectFinder finder = IdentifiedObjects.newFinder("EPSG");
finder.setIgnoringAxes(true);
Set<IdentifiedObject> candidates = finder.find(crs);
which returns an empty Set.
Do you have any idea?
Regards,
César
On 20 February 2018 at 11:09, Martin Desruisseaux
<[email protected]> wrote:
> Hello César
>
> Le 19/02/2018 à 17:34, César Martínez Izquierdo a écrit :
>
> - After parsing an ESRI WKT, I'd like to get the equivalent EPSG definition.
> Is there a way to achieve this?
>
> Yes. A first thing to do is to not use the CRS.fromWKT(String) convenience
> method because that method parses standard WKT as defined by ISO 19162 (WKT
> 2) or OGC 01-009 (WKT 1), while ESRI WKT 1 and GDAL differs from those
> standards (note: latest ESRI products support WKT 2 in the standard way, but
> did not changed their WKT 1 for compatibility reasons). We have to use
> WKTFormat for instructing Apache SIS to parse non-standard WKT 1:
>
> WKTFormat parser = new WKTFormat(null, null);
> parser.setConvention(Convention.WKT1_COMMON_UNITS);
>
> See http://sis.apache.org/apidocs/org/apache/sis/io/wkt/Convention.html for
> more information. You may also consider using Convention.WKT1_IGNORE_AXES,
> which I think is GDAL behaviour. Then you can parse with parseObject(String)
> method.
>
> After having a CRS, we can search for its identifier code with following
> convenience method:
>
> Integer code = IdentifiedObjects.lookupEPSG(crs);
>
> Note that this method is likely to return null for most geographic objects,
> because axis orders used by GDAL (and I think also ESRI before their upgrade
> to WKT 2) differ from EPSG definitions. If you want to get an EPSG code
> despite the difference in axis order, see
> http://sis.apache.org/apidocs/org/apache/sis/referencing/IdentifiedObjects.html#newFinder-java.lang.String-
>
>
> I've seen that there is ESRI citations in the providers, but I don't know
> how to use them.
>
> The ESRI citations are used for map projection parameters, which sometime
> differs from other authorities. For example on
> http://sis.apache.org/tables/CoordinateOperationMethods.html#9822 click on
> "Latitude of false origin". This allows SIS to be able to parse ESRI WKT
> despite differences in parameter names. But there is not ESRI definitions of
> CRS in SIS yet (as far as I remember).
>
>
> I've tried the following code:
>
> (…snip…)
> crs = CRS.fromAuthority(crs, factory, null);
>
> However, the resulting CRS still looks an ESRI one.
>
> Did it returns the same instance (return value == argument)?
>
>
> - There is a database of ESRI codes in the CRS library we are currently
> using in gvSIG. If we were willing to use this database with Apache SIS, I
> assume we should create a plugin which provides a new authority factory. Am
> I right Is this feasible?
>
> Yes, there is already a JIRA task for that:
> https://issues.apache.org/jira/browse/SIS-117
>
> Note that when using WKTFormat, it is possible to define shortcut for
> frequently used elements:
>
> http://sis.apache.org/apidocs/org/apache/sis/io/wkt/WKTFormat.html#addFragment-java.lang.String-java.lang.String-
>
> It does not only make the definition files smaller, but also faster to parse
> and consume less memory (in above example, every time $MyEllipsoid is used,
> SIS share the parsed tree - it is not just a search-and-replace of texts).
>
> Martin
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
César Martínez Izquierdo
GIS developer
- - - - - - - - - - - - - - - - - - - -
SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
