NOTICE: help.openstreetmap.org is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

Why is there no topographic data of the North of the globe (anything over 60 degrees)?

I found This message through Google and according to this source, there is data available up to 83 degrees.

asked 16 Jul '12, 16:27

JvdP's gravatar image

JvdP
16112
accept rate: 0%

edited 04 Aug '13, 17:05

Andy%20Allan's gravatar image

Andy Allan
12.5k23128153


This is no longer the case - see for example Trondheim in Norway. Elevation, shading and contours are now available up to 83°N.

permanent link

answered 04 Aug '13, 17:08

Andy%20Allan's gravatar image

Andy Allan
12.5k23128153
accept rate: 28%

This is definitely on OpenCycleMap's maintainer's todo list, and will happen at some point. There is no planed date for this upgrade however, and other tasks (such as the redaction bot) are usually more urgent.

Note that OpenCycleMap is just one map that includes the (non-OSM) elevation data. There are certainly other maps out there showing OSM data with better elevation data.

Note also that other elevation data sources such as ASTER are not a panacea and have their own set of problems (1, 2).

permanent link

answered 16 Jul '12, 17:22

Vincent%20de%20Phily's gravatar image

Vincent de P... ♦
17.3k18152249
accept rate: 19%

Also, ASTER's license would be problematic for OpenCycleMap's use.

(17 Jul '12, 19:57) Breki
-2

Though I think it's normally not needed for a cycle map, we still need map rendering and editors working with something else than Mercator's cylindric projection, for polar areas near or above 83°. At 83° the scale is such that we have too much precision at the highest zoom level, and this unnecessarily uses too much storage space on the server (at 83° the pixel density is multiplied by around 120, which means that these areas require 121 times more storage space than on equatorial area, and this also means that this limits the possible resolution for equatorial area if we limit the max zoom level.

Ideally, the server should use a setting not based on the max zoom level, but on the maximum pixel density (or equivalently the minimum distance size).

If we keep some constraints, given the way the Mercator conformance (that preserves local angles and relative scales on small distances, we should be able to swithc progressively to conic projections (but the non rectilinear aberration increase a lot along parallels so that the usable area becomes very small. Above 83° any accurate orthophotography will be too far from the Mercator projection, with straight lines becoming curves (except along meridians). We loose a lot of precision while at the same time we have increased too much the pixel precision far above the actual precision of distances.

A server should probably not use a single max zoom level, but should compute it in bands, so that we could get better precision of rendered bitmaps near the equator and in tropical areas, by savings made within the polar circles.

Note however that the OSM database does not care about the projection, it can correctly store any point on Earth with at least the precision you find on the equator. So only the edit tools and renderers (which work with prerendered bitmaps, that could be rescaled dynamically to correct the aberrations around the viewpoint center) need further improvements (renderers have other issues when they draw segments which are supposed to be straight in reality, such as house walls : near the poles, all these walls except those along a meridian must become a curve in a flat 2D projection where parallels ae represented as horizontal lines; this means that renderers shoud should have to split these segments). The prerendered bitmaps will show curves, but the viewpoint will autocorrect these images (just like with orthophotography remapped to Mercator projections), except that here we will inverse this process when rendering them on the client side. Native photos (or prerendered map bitmaps) stored on the server in Mercator projections are NEVER accurate (even if we restrict to 83° of latitude).

permanent link

answered 05 Aug '13, 07:51

Verdy_p's gravatar image

Verdy_p
14181115
accept rate: 0%

3

This is the wrong place. Copy'n'paste your text to a mailing list or forum.

(05 Aug '13, 08:17) scai ♦

No this is the rght plae, because the limtation of latitude is caused by the inaccuracies of the Mercator projection with elevation data which requires very high horizontal precision.

But if the horizontal precision is good in a Mercator projection on the equator, it will be even better near the pole. The problem is that the Mercator image will be ifinitely high even if using the same longitude resolution.

(05 Aug '13, 09:01) Verdy_p

Mercator is in fact the WORST projection for storage and delivery of orthophotographic images. It would be much simpler (and more efficient) to store images in polar coordinates, i.e. with X and Y proportional to logitude/latitude, like in the OSM database for nodes (it would still waste some space near the poles, but it would just require inverse projection from Mercator for reading and using them. However if these images are bitmaps, this will require interpolation (at least quadratic but probably better with Lanczos). The needed space would not be infinite like with Mercator in ALL scales.

(05 Aug '13, 09:06) Verdy_p

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×62
×18
×7
×3

question asked: 16 Jul '12, 16:27

question was seen: 5,495 times

last updated: 05 Aug '13, 09:06

NOTICE: help.openstreetmap.org is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum