ok, and you always have to compare floats with a tolerance, not exact. ive
been bitten many times by that.
John
On Tue, Apr 21, 2015 at 8:02 AM, Daniele Romagnoli <
daniele.romagnoli@xxxxxxxxxxxxxxxx> wrote:
> Hi John,
> thanks for your reply.
>
> The problem I have with this is that I'm setting up a predefined set of
> custom CoordinateReferenceSystem definitions:
> as an instance, a LambertConformal projection where standard parallels is
> 25.
> Then, I'm parsing the gridMapping attributes in order to try to recognize
> a known custom CRS and I'm getting no matches since it is expecting 25
> instead of 25.00002. (CRS matching checks use WKT parsing).
>
> In the meantime, I will investigate more on this.
> Cheers,
> Daniele
>
>
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
> On Tue, Apr 21, 2015 at 2:15 AM, John Caron <caron@xxxxxxxx> wrote:
>
>> Hi Daniele:
>>
>> GRIB projection info is stored in the GRIB file in (at most) 3 bytes, so
>> has a maximum precision of 24 bits.
>>
>> Im surprised that you are seeing a problem, it seems unlikely that a
>> roundoff in the low order bit of a float should matter.
>>
>> But theres not really a good reason that we couldnt use doubles if
>> needed.
>>
>> John
>>
>>
>> On Mon, Apr 20, 2015 at 3:45 AM, Daniele Romagnoli <
>> daniele.romagnoli@xxxxxxxxxxxxxxxx> wrote:
>>
>>> Hi List,
>>> I'm using NetCDF Java 4.5.5.
>>> I have noticed that when computing the LambertConformal projection
>>> components (such as latin1, latin2...) in Grib1Gds I'm getting:
>>>
>>> latin1 = 25.00001
>>> latin2 = 25.05002
>>> dx1 = 13.545001
>>> dy1 = 13.545001
>>>
>>> Instead of:
>>> latin1 = 25
>>> latin2 = 25.05
>>> dx1 = 13.545
>>> dy1 = 13.545
>>>
>>> Plus, I'm getting some additional precision loss when extracting these
>>> attributes
>>> from the associated grid_mapping variable, as numbers (double values).
>>> I will surely investigate more on the topic to become more confident
>>> with that code and I will read again about representation errors on
>>> floating point arithmetics so my question could sounds trivial: Why these
>>> variables and scale constants are floats instead of doubles? (is it for
>>> size and performance issues?)
>>>
>>> Regards,
>>> Daniele
>>>
>>>
>>>
>>>
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>> Ing. Daniele Romagnoli
>>> Senior Software Engineer
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054 Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> -------------------------------------------------------
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>>
>>> _______________________________________________
>>> netcdf-java mailing list
>>> netcdf-java@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>
>>
>
