No Topographic data OpenCycleMap of North (over 60 degrees)

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

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).

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).