【问题标题】:UTM to Lat/Long generates offsetUTM 到纬度/经度产生偏移
【发布时间】:2015-03-05 20:58:25
【问题描述】:

我正在尝试通过 Oracle Spatial 将所谓的 UTM Zone 33, Northern Hemisphere (WGS 84) SRID (Norway) 转换为 Lat/Long (Longitude / Latitude (WGS 84) SRID),并在 stackoverflow 上找到了一些很好的示例。问题是,无论哪个 SRID 用作源(引用 UTM 33N),纬度/经度的结果似乎是偏移的,并且会将任何位置放在离岸向西的位置。

代码:

select t.sdo.sdo_point.x as x
     , t.sdo.sdo_point.y as y
  from (select sdo_cs.transform( 
                       sdo_geometry( 2001
                                   , 82347  -- UTM Zone 33N SRID,
                                   , SDO_POINT_TYPE(a.coordinate_x,a.coordinate_y,NULL)
                                   , null
                                   , null)
                             , 8307     --Longitude / Latitude (WGS 84)  SRID  
                            ) as sdo
        from table a
      ) t;

我的一位同事实际上在 SAS 中硬编码了一个逐步计算,基于:http://www.uwgb.edu/dutchs/usefuldata/utmformulas.htm)

他的结果是

北纬 6716777,东纬 40137 --> 纬度 60.321808644 经度 6.6585114124

实际上与 Google 地图匹配。

上面的代码,为我生成相同的输入值:

64.0777530402641 0.231518684247992

对于 32633 等其他 SRID,我得到了类似的值。

任何想法我做错了什么?

【问题讨论】:

    标签: oracle google-maps latitude-longitude spatial utm


    【解决方案1】:

    糟糕,数据库中的 x 和 y 似乎相反(标签错误),当旋转时,工作正常!

    【讨论】:

    • 可能不是,在 Geodesy 中,笛卡尔轴与数学约定相比是交换的,请参阅Easting and northing
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-02-14
    • 2012-01-10
    • 2013-09-09
    • 2017-11-12
    • 2022-01-15
    • 2016-06-19
    • 2010-09-15
    相关资源
    最近更新 更多