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.
Is this patch okay? It reverts to the old w =
. Or should there be something else? A ?
seems not very helpful.
-
ellipsoid.csv
26 26 7027,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 27 27 7028,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 28 28 7029,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,029 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 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 30 30 7031,GEM 10C,6378137,9001,298.257223563,,1,Used for GEM 10C Gravity Potential Model.,,OGP,1995/06/02,1998.320,0 31 31 7032,OSU86F,6378136.2,9001,298.257223563,,1,Used for OSU86 gravity potential (geoidal) model.,,OGP,1995/06/02,1998.320,0 32 32 7033,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 , 7 years ago
comment:2 by , 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 , 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 , 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 , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
The root cause should be fixed in libgeotiff first, otherwise the issue will re-appear at the next refresh from the latest EPSG database.