Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#5724 closed defect (fixed)

wkt strings derived from loading via epsg code do not validate - esri_extra.wkt

Reported by: Kurt Schwehr Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: OGR_SRS Version: unspecified
Severity: normal Keywords: wkt epsg
Cc:

Description (last modified by Kurt Schwehr)

I'm having a bit of trouble with EPSG:3857 in gdal 1.11.0, which got me looking at esri_extra.wkt. 3857 loaded up gives a WKT that was not validating.

OGRSpatialReference::Validate Parsing error : syntax error, unexpected ',', expecting ']'. Error occured around:
ts=m +nadgrids=@null +wktext  +no_defs"],AUTHORITY["EPSG","3857"]]

input_spatial_reference.Validate() -> OGRERR_CORRUPT_DATA

I made a quick c++ program with 1.10.0 to try to validate all of the epsg codes in esri_extra.wkt... sketched:

  string wkt_csv_path(CSVFilename("esri_extra.wkt")); 
  FILE *wkt_csv = VSIFOpen( wkt_csv_path.c_str(), "rb" );
  char **fields = nullptr;

  while (nullptr != (fields = CSVReadParseLine(wkt_csv))) {
    const int field_count = CSLCount(fields);
    if (field_count < 2) {
      continue;
    }
    const string wkt_str(fields[0]);
    if (wkt_str.size() == 0 || wkt_str[0] == '#') {
      continue;
    }
    int epsg = atoi(fields[0]);
    OGRSpatialReference srs;
    srs.importFromEPSG(epsg);
    if (srs.Validate()) {
      cerr << "epsg validated: " << epsg << "\n";
    } else {
      cerr << ">>>>>>>>>>>>>> epsg FAILED: " << epsg << "\n";
    }
  }
  // Missing a free call above

A snip of the output. Shouldn't everything validate?

>>>>>>>>>>>>>> epsg FAILED: 37254
>>>>>>>>>>>>>> epsg FAILED: 37255
>>>>>>>>>>>>>> epsg FAILED: 37257
>>>>>>>>>>>>>> epsg FAILED: 37259
>>>>>>>>>>>>>> epsg FAILED: 37260
epsg validated: 53001
>>>>>>>>>>>>>> epsg FAILED: 53002
epsg validated: 53003
epsg validated: 53004
epsg validated: 53008
>>>>>>>>>>>>>> epsg FAILED: 53009
>>>>>>>>>>>>>> epsg FAILED: 53010
>>>>>>>>>>>>>> epsg FAILED: 53011
>>>>>>>>>>>>>> epsg FAILED: 53012
>>>>>>>>>>>>>> epsg FAILED: 53013
>>>>>>>>>>>>>> epsg FAILED: 53014
>>>>>>>>>>>>>> epsg FAILED: 53015
>>>>>>>>>>>>>> epsg FAILED: 53016
epsg validated: 53017
epsg validated: 53018
epsg validated: 53019
>>>>>>>>>>>>>> epsg FAILED: 53021
epsg validated: 53022
epsg validated: 53023
>>>>>>>>>>>>>> epsg FAILED: 53024
epsg validated: 53025
>>>>>>>>>>>>>> epsg FAILED: 53026
>>>>>>>>>>>>>> epsg FAILED: 53027
epsg validated: 53028
>>>>>>>>>>>>>> epsg FAILED: 53029

See also #4653

Change History (4)

comment:1 Changed 7 years ago by Kurt Schwehr

Description: modified (diff)

comment:2 Changed 7 years ago by Even Rouault

Hum this is certainly linked to ogr/osr_cs_wkt_grammar.y that I derived from the BNF rules of WKT. The issue is that EXTENSION is ... an extension to normal WKT. In the grammar I placed it after the authority node, but cannot think of a good reason for doing so. It might be reasonable to accept it before too. And perhaps only before, because in fact I can see in ogr_srsnode.cpp :

/* EXTENSION ... being a OSR extension... is arbitrary placed before the AUTHORITY */
static const char * const apszPROJCSRule[] = 
{ "PROJCS", "GEOGCS", "PROJECTION", "PARAMETER", "UNIT", "AXIS", "EXTENSION", "AUTHORITY", 
  NULL };

comment:3 Changed 7 years ago by Even Rouault

Component: defaultOGR_SRS
Milestone: 2.0
Resolution: fixed
Status: newclosed

trunk r27975 "OSR: various fixes to put EXTENSION node before AUTHORITY and make it pass Validate() (#5724)"

Potentially a bit too risky for 1.11

comment:4 Changed 6 years ago by Even Rouault

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.