Re: [Geotools-devel] Problem with General Oblique transform latitude?
Ben, I'm glad to hear that. Thank you! Maciej W dniu 04.06.2016 o 07:44, Ben Caradoc-Davies pisze: > 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 -- 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
Re: [Geotools-devel] Problem with General Oblique transform latitude?
Ben, in order not to break API, I propose to add new transformation first (named RotatedPole) 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, > -- 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! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problem with General Oblique transform latitude?
Ben, 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. > > 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! Regards Maciej -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Problem with General Oblique transform latitude?
Ben, W dniu 18.03.2016 o 03:49, Ben Caradoc-Davies pisze: > I note that (lambda_g^N, phi_g^N) is the North Pole of the rotated grid, > so phi_g^N is not latitudeOfOrigin, which is measured from the equator. You're right here. Proj's "+o_lat_p" parameter (undocumented, of course) used in my reference example, is latitude of rotated North Pole, not latitude of the origin. Thank you for pointing this out! Maciej -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [JIRA] (GEOT-5199) Add Meteosat Second Generation imagery projection
Title: Message Title Maciej Filocha created an issue GeoTools / GEOT-5199 Add Meteosat Second Generation imagery projection Issue Type: Improvement Assignee: Unassigned Components: referencing Created: 25/Aug/15 3:09 PM Priority: Medium Reporter: Maciej Filocha Add possibility to convert Meteosat Second Generation satellite images coordinates (pixel column and row) into lat-lon. Pull request is here: https://github.com/geotools/geotools/pull/947 Add Comment
[Geotools-devel] Meteosat imagery projection
Dear all, I'm working on the new projection to handle Meteosat Second Generation images. It is some sort of a "Vertical Perspective" (Snyder) as I understand. A reference C/Fortran code (pixel row-col to lat-lon) is available from Eumetsat website. My draft implementation of that code computes right results, however only under assumption that Earth radius parameter is equal to 1: set _MSG_ = PROJCS["MSG", GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AUTHORITY["EPSG","4326"]], PROJECTION["MeteosatSG"], PARAMETER["semi_major", 1.0], PARAMETER["semi_minor", 1.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["central_meridian", 0.0], PARAMETER["scale_factor", 1.0], PARAMETER["false_easting", 0.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0]] That looks strange for me. I'd appreciate any hints how to do it in more straightforward (proper?) way. My code is here: https://github.com/mfilocha/geotools/blob/b42be2ffc30784b61bfd114bc273bd534996713b/modules/library/referencing/src/main/java/org/geotools/referencing/operation/projection/MeteosatSG.java Test data: https://github.com/mfilocha/geotools/blob/b42be2ffc30784b61bfd114bc273bd534996713b/modules/library/referencing/src/test/resources/org/geotools/referencing/test-data/scripts/MeteosatSG.txt Regards Maciej -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] General Oblique Transform
Dear All, motivated by Andrea: http://sourceforge.net/p/geoserver/mailman/message/34095134/ I adopted new projection, used often by Numerical Weather Prediction community. Proposed name for this transformation is "General Oblique Transform" or "Rotated Pole Coordinates Transform". The first name is taken directly from proj.4 "+proj=ob_tran" definition. Code is based on example provided by Jürgen Seib from Deutscher Wetterdienst, altered to follow proj.4 behaviour. My biggest concern in this code is how differences between spherical and non-spherical Earth are handled, but as long as this projection is applied for computing grids with horizontal resolutions on order of one or more kilometres, this is probably acceptable (see test cases). Any comments are welcome. Pull request is here: https://github.com/geotools/geotools/pull/870 Regards Maciej -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
