sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (Jira)" <>
Subject [jira] [Created] (SIS-502) Allow users to define CRS for custom codes
Date Thu, 05 Nov 2020 09:15:00 GMT
Martin Desruisseaux created SIS-502:

             Summary: Allow users to define CRS for custom codes
                 Key: SIS-502
             Project: Spatial Information Systems
          Issue Type: New Feature
          Components: Referencing
    Affects Versions: 1.0
            Reporter: Martin Desruisseaux
            Assignee: Martin Desruisseaux
             Fix For: 1.1

Provide a mechanism for defining easily (without interacting with a database) a few CRS definitions
for codes other than EPSG. For example [ESRI also provides their own codes|]
and the International Astronomical Union (IAU) makes some experiments.

The easiest way is to provide CRS definitions in Well-Know Text (WKT) format, which is an
OGC/ISO standard. But the WKT format provides a standard way to define a single CRS, while
we need to define many CRS associated to codes. I'm not aware of a standard for such registry.
Other projects like GDAL and GeoTools use key-value pairs with one entry per line. Example
with [ESRI codes|]:


(Note: above example uses legacy WKT 1 because ESRI file defines CRS that way, but this proposal
does not depend on WKT version)

However above format does not said which authority to associate the 9248 and 9251 keys (ESRI
in above example). In order to know the authority, we have to look at the end of WKT strings
for the {{AUTHORITY["Esri",…]}} elements. But if we have to look for {{AUTHORITY[…]}}
(WKT 1) or {{ID[…]}} (WKT 2) elements anyway, then we do not need the keys at all because
they are redundant with {{AUTHORITY/ID[…]}} elements. Dropping the keys simplify the file
format and remove one possible source of inconsistencies.

Another issue is that above format puts each WKT definitions on a single line, which is difficult
to read. For making the file more human-readable, I propose to allow WKT definitions to span
many lines provided that each additional lines is indented relative to the first line. With
those two proposed changes, above example would become:



i.e. we just put standard WKT definitions one after the other (without "{{<key>=}}"
prefix) indented in a human-readable way. An inconvenient is that the {{AUTHORITY[…]}} or
{{ID[…]}} elements, which are optional in WKT standard, become mandatory in this format.

h2. Aliases for WKT fragments
Files with more than one WKT definition tend to repeat the same WKT fragments many times,
e.g. the same {{BaseGeogCRS[…]}} element may be repeated in every {{ProjectedCRS}} definitions.
I propose to allow redundant fragments to be replaced by aliases for making the file more
compact, easier to read, faster to parse and with smaller memory footprint. The syntax would
be the same than environment variables in Unix shell: each line starting with "{{SET <identifier>=<WKT>}}"
defines an alias for a fragment of WKT string. The WKT can span many lines as described above.
Aliases can be expanded in other WKT strings by "{{$<identifier>}}". So above example
could become (if user wishes):

SET Int1924 = SPHEROID["International_1924",6378388.0,297.0]
SET Greenwich = PRIMEM["Greenwich",0.0]
SET Degree = UNIT["Degree",0.0174532925199433]

  DATUM["Tapi_Aike", $Int1924],
  $Greenwich, $Degree,

  DATUM["Ministerio_de_Marina_Norte", $Int1924],
  $Greenwich, $Degree,

The possibility to define fragments is already a [feature of our WKT parser|,java.lang.String)].

This message was sent by Atlassian Jira

View raw message