使用地图服务器将 NAD83 转换为 WGS84
我正在向谷歌地图添加 WAC 叠加层。
地图图块以 NAD83 (lcc) 投影,谷歌地图以 WGS84 (mercator) 投影。
WAC 图块被分成各自的区域,如下所示:http://map.aeroplanner .com/mapping/chart/smartchart.cfm 所以有相当多的图块。也就是说,我目前在定位单个图块时遇到了问题。
世界文件的格式似乎正确,因为 ArcGIS 使用关联的世界文件正确显示切片。
当使用 LCC 投影并设置其平铺预期填充的纬度/经度时,构成 WAC 扇区的北面和南面平铺彼此正确对齐。
http://img716.imageshack.us/img716/1742/waclcc.jpg - 在此图像中,您可以看到 CF16 A&B 和 CF17 A&B。投影看起来工作正常,但位置错误。必须指定绝对纬度/经度,因为忽略它们会导致 MapServer 抛出定位错误。
这是地图文件中的一个片段,它产生上述输出:
LAYER 类型光栅 名称“16_40_NORTH” 集团“wac” 数据“/opt/fgs/www/htdocs/WAC/CF-16 WAC 40 North.tif”
#projection of this layer
PROJECTION
"proj=lcc"
"lat_2=49"
"lat_1=44.5"
"lat_0=40"
"lon_0=-125"
"x_0=0"
"y_0=0"
"ellps=GRS80"
"datum=NAD83"
"units=m"
"no_defs"
END
OFFSITE 0 0 0
END
LAYER
TYPE RASTER
NAME "16_40_SOUTH"
GROUP "wac"
DATA "/opt/fgs/www/htdocs/WAC/CF-16 WAC 40 South.tif"
#projection of this layer
PROJECTION
"proj=lcc"
"lat_2=49"
"lat_1=44.5"
"lat_0=40"
"lon_0=-125"
"x_0=0"
"y_0=0"
"ellps=GRS80"
"datum=NAD83"
"units=m"
"no_defs"
END
OFFSITE 0 0 0
END
其他类型的定位(例如 UTM)提供不正确的投影(因为线不是水平的)并且类似地错误定位。
为什么尽管给出了绝对值,MapServer 的定位却如此不正确,而 ArcGIS 使用世界文件显示切片却没有任何问题?
是否有可能是MapServer的版本有问题,或者更有可能是我们的mapfile的问题?
I'm in the process of adding a WAC overlay to google maps.
The map tiles are projected in NAD83 (lcc), google maps is WGS84 (mercator).
The WAC tiles are broken up into their individual areas as found on: http://map.aeroplanner.com/mapping/chart/smartchart.cfm so there are quite a large number of tiles. That said, I'm currently experiencing problems positioning even a single tile.
The world file appears to be properly formed, as ArcGIS displays the tiles properly using the associated world file.
When using LCC projection and setting the lat/long that they tiles are expected to fill, the north and south tiles which comprise a WAC sector are correctly aligned with respect to each other.
http://img716.imageshack.us/img716/1742/waclcc.jpg - In this image, you can see CF16 A&B, and CF17 A&B. The projection looks like it is working correctly, however the position is wrong. An absolute lat/long must be assigned as leaving them out causes MapServer to throw a positioning error.
This is a segment from the map file which produces the above output:
LAYER
TYPE RASTER
NAME "16_40_NORTH"
GROUP "wac"
DATA "/opt/fgs/www/htdocs/WAC/CF-16 WAC 40 North.tif"
#projection of this layer
PROJECTION
"proj=lcc"
"lat_2=49"
"lat_1=44.5"
"lat_0=40"
"lon_0=-125"
"x_0=0"
"y_0=0"
"ellps=GRS80"
"datum=NAD83"
"units=m"
"no_defs"
END
OFFSITE 0 0 0
END
LAYER
TYPE RASTER
NAME "16_40_SOUTH"
GROUP "wac"
DATA "/opt/fgs/www/htdocs/WAC/CF-16 WAC 40 South.tif"
#projection of this layer
PROJECTION
"proj=lcc"
"lat_2=49"
"lat_1=44.5"
"lat_0=40"
"lon_0=-125"
"x_0=0"
"y_0=0"
"ellps=GRS80"
"datum=NAD83"
"units=m"
"no_defs"
END
OFFSITE 0 0 0
END
Other types of positioning such as UTM provide incorrect projections (in that the lines are not level) and are similarly incorrectly positioned.
Why is MapServer positioning so incorrectly despite being given absolute values, where ArcGIS displays the tiles using the world file without any problems?
Is it possible the version of MapServer is faulty, or is it more likely to be our mapfile?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
一个月前,我们在解决一个完全不同的问题时重新讨论了这个问题。
我们发现我们的旧版 JavaScript(使用 Google Maps API)无法正确计算边界框。我们认为它没问题,因为它已经生产了几年而没有出现任何问题。
我研究了替代映射 API,包括 leaflet.js 并从头开始创建了一个示例解决方案。我们对内部 JavaScript 功能进行了一些调整,并且能够正确地进行地图项目。
就我个人而言,我发现 Leaflet.js 和 OSM 在尝试解决 Google 地图问题时非常有用。
We revisited this issue a month ago while solving a completely different issue.
What we found is that our legacy JavaScript (using Google Maps API) wasn't calculating the bounding box properly. We had assumed it was fine, given it had been in production for a few years without issue.
I investigated alternative mapping API's including leaflet.js and created a sample solution from scratch. We made some adjustments to our internal JavaScript functionality and were able to have the maps project correctly.
Personally, I've found Leaflet.js and OSM to be invaluable when trying to troubleshoot Google Maps issues.