Handling of datum and projection in ADIwg mdJSON and ISO

[stansmith907]

Most reference systems (which I assume define both the datum and projection) will fit into a RS_Identifier block. RS_Identifier is a MD_Identifier with added attributes codeSpace and version. After reading and re-reading the definitions I can see no reason why we need these additional attributes. I think they can be handled in the authority block (a citation) of RS_Identifier.

codeSpace => name or identifier of the person or organization responsible for namespace; looks like authority.title
verision => version identifier for the namespace; looks like authority.edition

"spatialReferenceSystem": {
    "name": [" "],
    "epsgNumber": [0],
    "wkt": [" "],
    "customReferenceSystem": {
        "name": " ",
        "url": " "
    },
    "customReferenceSystem": {
        "all-the-necessary-parameters": " "
    }
}

• name => a list of recognized reference system names that will be placed in the RS_Identifier>code
• epsgNumber => the epsg number only. The number will be formatted in the RS_Identifier>code as urn:ogc:def:crs:EPSG::number
• wkt => the wkt string will be prefaced in the RS_Identifier>code with WKT:string
• customReferenceSystem => not supported
• customReferenceSystem => provide link to external ISO 19111 block through NOAA docucomp or other service. Information will be placed in tag attributes of referenceSystemInfo as we are currently doing.
• customReferenceSystem => collect all reference system parameters but not present in ISO. Could be used in FGDC construction.

Vote the options you think we should support, or add others.

[jlblcc]

I'm not in favor of forcing users to use 19111 to define custom projections. I just don't see that being realistic.
Just so I'm straight, if we add the extra reference system classes to the ISO output, it will fail to validate using the NOAA xsd?

[stansmith907]

I think asking users to create a 19111 record - or even reference it - is a poor choice. This option was a recommendation from NOAA so I thought it should be included. If the user is to create a custom reference system adding it to the EPSG system seems more palpable.

If we did add MD_CRS to the XML (and I tried it) it will fail validation. If we want to do support MD_CRS and associated classes our option would be to extend the XSDs and maintain an ADIwg copy. I'm not feeling warm and fuzzy about that possibility.

I am leaning toward supporting name, epsgNumber, wkt, and no custom reference system unless added to EPSG.

[nunatech]

I say we stick with the EPSG codes. I registered all of the ARMAP projections with EPSG in 2006. Here's a list of them if anyone cares.. http://armap.org/Projections.aspx Alaska Albers and web mercator are most folks will use.

[dwalt]

I agree with the recommendation.

On Thu, Aug 28, 2014 at 4:50 PM, stansmith907 notifications@github.com
wrote:

I think asking users to create a 19111 record - or even reference it - is
a poor choice. This option was a recommendation from NOAA so I thought it
should be included. If the user is to create a custom reference system
adding it to the EPSG system seems more palpable.

If we did add MD_CRS to the XML (and I tried it) it will fail validation.
If we want to do support MD_CRS and associated classes our option would be
to extend the XSDs and maintain an ADIwg copy. I'm not feeling warm and
fuzzy about that possibility.

I am leaning toward supporting name, epsgNumber, wkt, and no custom
reference system unless added to EPSG.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[jlblcc]

I think we need to talk with some more folks about this. I'm not sure why NOAA's not supporting this, but it's a significant departure from CSDGM. I'm not sure how this would impact older data sets that may be using weird projections.

On the other hand, I guess if we're not planning to translate custom projections to ISO, we can add that option later if there's a demonstrated need.

[stansmith907]

Template, example, reader, and writer are updated with spatialDatum changed to spatialReferenceSystem as follows ...

"spatialReferenceSystem": {
    "name": [" "],
    "epsgNumber": [0],
    "wkt": [" "]
}

... resulting in version number increase to 0.7.0.

Changes are pushed to GitHub dev and master.

[jlblcc]

FYI,

The WKT double quotes need to be escaped in the JSON:

      "spatialReferenceSystem":{
        "name":[
          "Alaska State Plane Zone 4",
          "UTM Zone 9"
        ],
        "epsgNumber":[
          102634,
          32609
        ],
        "wkt":[
          "PROJCS[\"NAD_1983_StatePlane_Alaska_4_FIPS_5004_Feet\",GEOGCS[\"GCS_North_American_1983\",DATUM[\"North_American_Datum_1983\",SPHEROID[\"GRS_1980\",6378137,298.257222101]],PRIMEM[\"Greenwich\",0],UNIT[\"Degree\",0.017453292519943295]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"False_Easting\",1640416.666666667],PARAMETER[\"False_Northing\",0],PARAMETER[\"Central_Meridian\",-150],PARAMETER[\"Scale_Factor\",0.9999],PARAMETER[\"Latitude_Of_Origin\",54],UNIT[\"Foot_US\",0.30480060960121924],AUTHORITY[\"EPSG\",\"102634\"]]",
          "PROJCS[\"WGS 84 / UTM zone 9N\",GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-129],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"32609\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"
        ]
      },

[stansmith907]

I changed the double-quotes to single in my example. Was that a bad idea?

[jlblcc]

All the examples I've seen of WKT srs defs use double quotes. Although, I'm not sure how much real impact the change to single quotes would have...

[jlblcc]

Gem published. Close this issue?

[stansmith907]

json-schema Dependency is listed as >=0. Didn't we have a few changes that would bump up the version? Do we need to fork our own version for the chop?

[stansmith907]

Use ESPG.