Maciej, I thought you might like to know that I have just submitted pull requests to add support for your Rotated Pole projection to the GeoTools NetCDF module and the GeoServer NetCDF output module: https://github.com/geotools/geotools/pull/1205 https://github.com/geoserver/geoserver/pull/1631 https://osgeo-org.atlassian.net/browse/GEOT-5428
Your projection is working well. Combined with the NetCDF changes I mentioned above, and changes I made to GRIB2 support in NetCDF-Java (expected in 4.6.6), GeoServer can deliver the native GRIB2 output of NOAA's Rapid Refresh (RAP) weather forecast model: http://rapidrefresh.noaa.gov/ https://github.com/bencaradocdavies/geoserver/wiki/RAP-Native-Grid https://github.com/bencaradocdavies/geoserver/wiki/RAP-Native-Grid-ImageMosaic Thanks again for your contribution. Kind regards, Ben. On 12/04/16 13:08, Ben Caradoc-Davies wrote: > 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 ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
