Hi Michael, Ede
I try to summarize all the aspects (development and reasons) going back to
2016 when I added Vector/Raster SRS reading and (at that moment) writing
with the great help of Michael
To, please, forgive me if I am a bit verbose.
*Reading (This was my first purpose)*
Since the idea was to have only one method with Vectors and Raster (both
via ReferenceImage and SextanteRaster classes), I divide the problem into
two aspects:
a) reading .PRJ and .AUX.XML files (the first for Shapefile but also for
ESRI .asc and .flt raster files)
b) reading coordinate code embedded into GeoTIFF file
Since I didn't want to have huge databases, the idea was to have a simple
text (*srid.txt*) file with only three definitions for each EPSG;
<EPSG code><EPSG definition>[Unit]. The EPSG definition should have been a
good human readable (no underscores, slashes or exemplifications (like ESRI)
The Layer>Propertes dilaog shows my idea
[image: image.png]
The first base of my job was to use an ESRI database, probably taken from
the same Github page where it camoes yours
I used a spreadsheet SpreadSheet to modify the file according to my idea
and some methods to decode the file and give
the <EPSG code><EPSG definition>[Unit]
For instance, for a shp or aux.xml file, OpenJUMP reads the projection
sidecar file:
GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
There are some methods in the ProjUtils class that
a) point to "GCS_WGS_1984" position into the .prj file and read what is
into the double quotes.
b) remove underscore to create <EPSG definition> (*GCS WGS 1984*),
c) match with corresponding ine (if any) into* sridj.txt.*
d) take out <EPSG code> (4326) and [Unit] (degree). These datas are stored
into Layer metadata
After the framework was complete, I tested with different shapefiles coming
from different public organizations in Italy and I discover that there was
(still is) a confusion as some were using
ESRI definition while other were using OGC WKT
For instance ESRI: GEOGCS["GCS_WGS_1984"..
OGC WKT: GEOGCS["WGS 84".....
The recommendation of the Italian National Cartographic Bureau was (and
still is) to use the OGC WKT definitions.
To bypass the problem, since I didn't want to duplicate the definitions
into *srid.txt*. (and in that moment there was only ESRi database
available),
I worked on reading and decoding on both ESRI and OGC
The method is ProjUtils.decodeProjDescription(String) and has an
explanation about how it works and try to decode the two different dialects
(ESRI and OGC).
Later I added other definitions form EPSG database
If no definition is found into the TXT file, OJ reports, in any case, what
is read into prj file (point a) made in a more readable way (point b)
Reading coordinate code embedded into GeoTIFF file and decoding to a SRS
follows more or less the same idea, except that scans whatever possible
within projection tags.
Writing epsg code.
That is made by methods into SridLookupTable class and another small text
database file *srid2prj.txt *
In this text file each EPSG definition has a corresponding .prj code *but I
wanted to follow the recommendation of the Italian National Cartographic
Bureau (to use OGC .prj files)*
I don't remember where I found a file with OGC prj definition which I
modified to obtain *srid2prj.txt , possibily from *CDB | OGC
<https://www.ogc.org/standards/cdb>
This Writing code works only when and user save a SextanteRaster layer: it
create a AUX.XML file. Or, if aux.xml file already exists, write the entire
OGC WKT definition into it.
Going back to Michael mail
All the problems you discover were probably connected to the matter that
the previous SRS framework in OpenJUMP read ESRI but* wrote OGC* prjs
which ArcGIS possibily cannot decode.
My proposal is
Reading: we keep the actual method, which uses *srid.txt* file: it can
decode both ESRI and OCG. Maybe we can upgrade with the few news
definitions ( I started on github a couple of days before)
The only effort of this method is to retrieve a valid EPSG code and maybe
an human readable definition
Writing: Vector: we keep the new *pe_list_projcs_geogcs* ESRI which work
fine. SextanteRaster we migrate from old *srid2prj.txt OCG* to newer
*pe_list_projcs_geogcs* ESRI
Best regards
Peppe
Il giorno gio 25 ago 2022 alle ore 09:09 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:
> Ede, Peppe
>
> EPSG is good at listing all known coordinate systems in the world but
> unfortunately,
>
> standardization to describe them is a slow process and we sometime have to
> deal with
>
> different identifiers (ex. epsg/esri), names (wkt/esri convention),
> formats (wkt, wkt2).
>
> This post gives some good hints on this problem :
>
>
> https://gis.stackexchange.com/questions/355184/prj-files-from-esri-arent-wkt
>
> When I added pe_list_projcs_geogcs, it was because we cannot retrieve the
> exact
>
> esri denomination from the srid2prj.txt which is based on epsg data.
>
> I don't know why some srid are missing from pe_list_projcs_geogcs but it
> is an esri database not epsg.
>
> Now, if the srid is not find in pe_list_projcs_geogcs, I get it
> from srid2prj as sugggested by Peppe but
>
> this later does not follow esri naming convention. An "esri" friendly name
> can be retrieved
>
> from epsg.io web site, but this is online. I don't know if they use a
> esri database or if they use
>
> some rules to make names esri friendly as discussed in the post.
>
>
> Michaël
>
>
> envoyé : 21 août 2022 à 13:20
> de : edgar.sol...@web.de
> à : jump-pilot-devel@lists.sourceforge.net
> objet : Re: [JPP-Devel] OpenJUMP throws a null point exception if
> coord_ref_sys is found
>
>
> On 21.08.2022 10:56, Michaud Michael wrote:
>
> Hi Peppe,
>
> You're right, I found 171 srid in srid2prj which are not
> in pe_list_projcs_geogcs.zip.
>
> Can you remember where the srid2prj file comes from ? And can you telle me
> which projection you use which are not in pe_list_projcs_geogcs.zip (just
> curious).
>
> Using several reference file is far from ideal, but until we find a better
> option, your proposition seems reasonable to me.
>
> hmm, a quick text search does not find all of these in
> https://github.com/Esri/projection-engine-db-doc/
>
> and what i can find is spread over several files. any idea why that is?
>
> why is there not a _complete_ epsgid/name mapping file somewhere? or is
> there and we are just not using it?
> registering and downloading wkt files-zip from
> https://epsg.org/download-dataset.html seems to inlude "all" of the
> missing epsg-ids. should we reformat and use those?
>
> sunny regards ..ede
>
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
