Maciej,

that looks great. I agree that this new projection is the best way to 
maintain backwards compatibility. In the test script, for "source pt = 
(0, 0)", the "target pt" latitude matches the projection 
latitude_of_origin, as I expect for a Rotated Pole projection.

I repurposed my Jira issue (as a New Feature) and renamed your pull 
request to match:

[GEOT-5396] Support Rotated Pole projection
https://osgeo-org.atlassian.net/browse/GEOT-5396

One issue is that we are in a code freeze for 15-beta2 (due next week). 
Most of the drama this release cycle has occurred in GeoServer (Spring 4 
upgrade) but I will need to check to see whether this new feature can be 
added before 15-beta2. I am being especially careful as gt-referencing 
is a core module and notable for its complexity.

Kind regards,
Ben.

On 11/04/16 19:31, Maciej Filocha wrote:
> Ben,
>
> in order not to break API, I propose to add new transformation first
> (named otatedPole) with this PR:
>
> https://github.com/geotools/geotools/pull/1168
>
> and then remove (by depreciation?) the GeneralOblique one. This should
> be safer because of somehow "fundamental" change in one of the key
> parameters.
>
> I can prepare a backport of RotatedPole transformation to 14.x, of course.
>
>
> Maciej
>
>
> W dniu 05.04.2016 o 02:20, Ben Caradoc-Davies pisze:
>> On 05/04/16 08:27, Maciej Filocha wrote:
>>> W dniu 02.04.2016 o 02:34, Ben Caradoc-Davies pisze:
>>>> I have created a Jira issue for this problem:
>>>> [GEOT-5396] Incorrect General Oblique transform
>>>> https://osgeo-org.atlassian.net/browse/GEOT-5396
>>> I'll prepare fix for it this week.
>>
>> Thanks very much. The projection seems to work fine for me if I set
>> latitude_of_origin to 90 degrees minus the correct latitude_of_origin,
>> so I have workaround. For example, for a grid with origin at latitude 54
>> degrees North, I am using PARAMETER["latitude_of_origin",36] (36=90-54).
>> I do not know if this is correct, but the results are plausible.
>>
>>>> One other question: is General_Oblique the most appropriate name for
>>>> this MapProjection? Although the implementation methods could be
>>>> used be
>>>> used to build general oblique projections, its Provider does not
>>>> support
>>>> other parameters. Could this projection instead be called Rotated_Pole
>>>> or Rotated_Latitude_Longitude?
>>> It was my initial idea to use one of that two names. Later on, I decided
>>> to follow proj4 internal name of "ob_tran":
>>> echo "0 0" | cs2cs -v +proj=ob_tran +o_proj=longlat +to_meter=0.0174533
>>> +lon_0=106 +o_lat_p=36 +ellps=WGS84 +datum=WGS84 +wktext +nodefs
>>> I agree, this could be misleading. It's up to you, core developers, to
>>> judge it!
>>
>> I am not an expert on projections, so I am hoping others on this list
>> can suggest a preferred alternative. I can find no OGC equivalent. I
>> suspect that, as a projection, this may be considered an Oblique Plate
>> Carree, but I have never seen it referred to as such and so choosing
>> this name would be unhelpful.
>>
>> The NetCDF CF Conventions use the term "rotated pole":
>> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch05s06.html
>>
>>
>>
>> The COSMO manual uses the terms "rotated spherical" and "rotated
>> geographic". GRIB2 GDS documentation uses "rotated latitude/longitude":
>> http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table3-1.shtml
>>
>> Maciej, your first guess was "rotated pole":
>> http://osgeo-org.1560.x6.nabble.com/Rotated-pole-coordinate-system-td5204800.html
>>
>>
>>
>> I would be happy with "rotated pole", but I lack expertise in this area.
>>
>> One other question is whether this renaming is considered an API change.
>> According to Jira, this projection has been included in all 14.x
>> (stable) releases to changing the name will break code that uses it.
>>
>> Kind regards,
>>
>

-- 
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to