#59 closed defect (fixed)
Suppling StdParallel1 with CT_Mercator, ie. Mercator_2SP, doesn't work
| Reported by: | tpiepho | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | libgeotiff | Version: | 1.3.0 |
| Keywords: | mercator 2SP | Cc: |
Description
There is currently no way to specify a Mercator_2SP in a geotiff. The unofficial projection list, http://www.remotesensing.org/geotiff/proj_list/mercator_2sp.html suggests that "ProjStdParallel1GeoKey" should be used for the parallels of true scale and that a scale should not be specified. When given such a geotiff, the normilization code will drop the latitude and generate a scale of 1. This silently mangles the projection.
I will supply a patch to fix this behavior.
Attachments (1)
Change History (6)
comment:1 by , 11 years ago
| Status: | new → assigned |
|---|
by , 11 years ago
| Attachment: | 0002-Support-ProjStdParallel1GeoKey-in-Mercator-projectio.patch added |
|---|
Patch (vs libgeotiff from gdal git)
comment:2 by , 11 years ago
Changes to geotiff in patch:
For writing, there are no changes.
For reading, there are some changes. There is no change for geotiffs with 1SP projections, which will be presented in same manner as before. For 2SP there could be a change with applications that do not support 2SP in geotiff.
Current behavior is effectively to silently change the lat_ts value to 0.0, a rather poor outcome. There is no way the app can work correctly.
A possible new behavior is the app will notice ProjScaleAtOriginGeoKey has not been provided and generate a warning or error.
Another possibility is that the app will just use what it thinks should be the scale and get 0.0. This results in an invalid projection, presumably letting the user know their app does not support this geotiff. GDAL does this (I have a patch to fix).
I think both these possibilities are better than the current behavior. And of course an app that supports 2SP can now work correctly. An alternative patch to libgeotiff could calculate a scale value and provide that to the app, allowing non-2SP aware apps to understand the projection. However, I think this isn't a good idea.
- The calculation requires some math and the eccentricity of the datum's ellipsoid, which libgeotiff would now have to figure out. And what if the datum is missing? I think this kind of projection math doesn't belong in libgeotiff and should be somewhere higher up, like in PROJ4, which is in fact where it currently exists.
- Given both a lat_ts and a scale, how is an application to know which to prefer? Presumably the one specified in the geotiff should be used, rather than the inexact value calculated from it, but which is that?
I skimmed the code and I see what you mean. I'll attempt to review and apply your patch when I see it.