Opened 7 years ago

Closed 5 years ago

#6737 closed defect (wontfix)

w -> ? in ellipse.pcs

Reported by: Kurt Schwehr Owned by: Even Rouault
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: unspecified
Severity: normal Keywords: epsg
Cc:

Description

In https://trac.osgeo.org/gdal/browser/trunk/gdal/data/ellipsoid.csv?annotate=blame#file3 w = -> ? =.

It looks like this is supposed to be an omega.

http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4326&reportDetail=long&title=WGS%2084&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code

Is this patch okay? It reverts to the old w =. Or should there be something else? A ? seems not very helpful.

  • ellipsoid.csv

     
    26267027,Plessis 1817,6376523,9001,308.64,,1,Rescaling of Delambre 1810 figure (a=6376985 m) to make meridional arc from equator to pole equal to 10000000 metres exactly. (Ref: Strasser).,"IGN Paris ""Constants d'Ellipsoides"" February 1972.",OGP,1995/06/02,,0
    27277028,Struve 1860,6378298.3,9001,294.73,,1,"Original definition of semi-major axis given as 3272539 toise.  In ""Ellipsoidisch Parameter der Erdfigur (1800-1950)"" , Strasser suggests a conversion factor of 1.94903631 which gives a=6378297.337 metres.","""Geodesia y Cartografia Matematica"" by Fernando Martin Asin; ISBN 84-398-0248-X.",OGP,1998/11/11,1998.070 1998.340,0
    28287029,War Office,6378300,9001,296,,1,"In non-metric form, a=20926201 Gold Coast feet. DMA Technical Manual 8358.1 and data derived from this quotes value for semi-major axis as 6378300.58m: OGP recommends use of defined value 6378300m exactly.","Tables for the use of the Gold Coast Survey Department, 1935.",OGP,2009/10/29,2009.075,0
    29 7030,WGS 84,6378137,9001,298.257223563,,1,"1/f derived from four defining parameters semi-major axis; C20 = -484.16685*10e-6; earth's angular velocity ? = 7292115e-11 rad/sec; gravitational constant GM = 3986005e8 m*m*m/s/s. In 1994 new GM = 3986004.418e8 m*m*m/s/s but a and 1/f retained.",DMA Technical Manual 8350.2-B,IOGP,2015/11/25,1998.320 2015.047,0
     297030,WGS 84,6378137,9001,298.257223563,,1,"1/f derived from four defining parameters semi-major axis; C20 = -484.16685*10e-6; earth's angular velocity w = 7292115e-11 rad/sec; gravitational constant GM = 3986005e8 m*m*m/s/s. In 1994 new GM = 3986004.418e8 m*m*m/s/s but a and 1/f retained.",DMA Technical Manual 8350.2-B,IOGP,2015/11/25,1998.320 2015.047,0
    30307031,GEM 10C,6378137,9001,298.257223563,,1,Used for  GEM 10C Gravity Potential Model.,,OGP,1995/06/02,1998.320,0
    31317032,OSU86F,6378136.2,9001,298.257223563,,1,Used for OSU86 gravity potential (geoidal) model.,,OGP,1995/06/02,1998.320,0
    32327033,OSU91A,6378136.3,9001,298.257223563,,1,Used for OSU91 gravity potential (geoidal) model.,,OGP,1995/06/02,1998.320,0

Change History (5)

comment:1 by Even Rouault, 7 years ago

The root cause should be fixed in libgeotiff first, otherwise the issue will re-appear at the next refresh from the latest EPSG database.

comment:2 by Kurt Schwehr, 7 years ago

Agreed. I should have been more explicit about mentioning that the issue is handling !isascii() chars.

Does this mean editing

https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/pg_to_csv.py

mentioned in

https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/README?rev=2735

or is this a part of

   1a) Insert a line "\encoding WIN1252" at start of the _Data_ sql file.

   1b) Modify the _Tables_ sql file, changing every occurance of (254) to
   (300).  This is to ensure that text fields are still big enough
   after Latin1 special characters are expanded into multi-byte
   UTF8 characters.

And what is the designer result? w, omega, a change in the csv encoding form, or ?

Right now I see:

file *.csv
compdcs.csv:          ASCII text
coordinate_axis.csv:  UTF-8 Unicode text
datum_shift.csv:      UTF-8 Unicode English text, with very long lines
ellipsoid.csv:        UTF-8 Unicode English text, with very long lines
gcs.csv:              ASCII English text
gcs.override.csv:     ASCII English text
gdal_datum.csv:       UTF-8 Unicode English text, with very long lines
geoccs.csv:           ASCII text
gt_datum.csv:         ASCII text
gt_ellips.csv:        ASCII text
ozi_datum.csv:        ASCII English text
ozi_ellips.csv:       ASCII text
pcs.csv:              ASCII text, with very long lines
pcs.override.csv:     ASCII English text, with very long lines
prime_meridian.csv:   UTF-8 Unicode text
projop_wparm.csv:     ASCII text, with very long lines
s57agencies.csv:      ASCII English text
s57attributes.csv:    UTF-8 Unicode English text
s57expectedinput.csv: ISO-8859 English text
s57objectclasses.csv: ASCII English text, with very long lines
stateplane.csv:       ASCII text
unit_of_measure.csv:  UTF-8 Unicode English text, with very long lines
vertcs.csv:           ASCII text
vertcs.override.csv:  ASCII English text

comment:3 by Even Rouault, 7 years ago

Given the instructions it is surprising that the UTF-8 omega character didn't show up. Perhaps WIN1252 isn't appropriate ? or there's an issue in the initial dump coming from EPSG ?

comment:4 by Even Rouault, 7 years ago

Regarding "earth's angular velocity ?" issue, I can see that the issue is already in the EPSG_v9_0.mdb_Data_PostgreSQL.sql dump delivered by the EPSG folks, so the issue should be submitted to them.

comment:5 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.