BigDecimal与经纬度有关的问题 [英] BigDecimal issue with long and lat

查看:71
本文介绍了BigDecimal与经纬度有关的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个地址域,其中的字段lat和BigDecimal一样长,并且我使用的缩放比例为16.我有这个地址

I have an address domain , which has fields lat and long as BigDecimal and i am using constraints of scale as 16. I have this address

550 Tremont St, Boston, MA 02116, USA

其经度和纬度分别为-71.07126540000002和42.3438919

its long and lat are -71.07126540000002 and 42.3438919

此地址的经度以-71.0712654000000200的形式存储在db中.现在,我需要将保存的经度与任何新请求进行比较,以检查经度是否已经存在.

Longitude for this address is stored in db as -71.0712654000000200. now i need to compare the saved longitude with any new request to check if longitude already exist.

我将再次发送相同的经度-71.07126540000002,但是我无法将其转换为保存在db(-71.0712654000000200)中的形式,因为它们比较长.相同的地址.

I am sending the same longitude again -71.07126540000002 but i am not able to convert it the form as it saved in db (-71.0712654000000200) before comparing as they are the long. of same address.

我尝试使用

BigDecimal a = new BigDecimal(-71.07126540000002)
println a.setScale(16,  RoundingMode.CEILING)​ // tried all other RoundingMode

但所有人的响应都为-71.0712654000000156或-71.0712654000000157,但没有得到-71.0712654000000200

but all are giving response as either -71.0712654000000156 or -71.0712654000000157 but not getting -71.0712654000000200

帮助!

推荐答案

应使用

a.setScale(14, RoundingMode.HALF_UP)

自第14个位置后开始.零并不重要

since after 14th pos. zeros are not significative

最后将是 -71.07126540000002

这篇关于BigDecimal与经纬度有关的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆