This varies from between 130% and 200% of horizontal scale on the horizon, in order to clarify small distant features, to less than 100% lower down, in order to reduce the number of features that fall below the scope of the strips. In the field, the eye tends to magnify the vertical scale on the horizon in this manner, but photographs do not, so the vertical scale will be noticeable when comparing panoramas with photographs.
Terrestrial curvature has been allowed for by adjusting heights by an amount varying with the square of the distance from the viewpoint. The earth's assumed radius has been increased slightly to allow for atmospheric refraction, i.e. the bending of light rays as they pass from lighter, high altitude air to denser low altitude air. Under special atmospheric conditions (e.g. temperature inversions) features not shown on the panoramas may be visible.
Viewfinder panoramas are made from Digital Elevation Models (DEM's). These are two-dimensional digital arrays of elevations above sea level. Some of these DEMs were downloaded or bought direct from suppliers; others were made from vectorised contours. Some (e.g. SRTM) are public domain. More details about these can be found in the stock section.
The main production process involves ray tracing across the DEMs, outward from the viewpoint in tens of thousands of different directions. 100x100km blocks (UK/Eire) or 1x1 degree blocks (elsewhere) are loaded from disk into memory and ray traced, one block at a time. When a ray reaches a block boundary, it is suspended, then another ray is traced until all the rays that cover that block have been analysed. Blocks are worked outwards until is there is an infinitesimal likelihood of anything appearing above the mathematical horizon. Finally the rays are put together to form profiles that can be compared with real visible profiles.
I make no apology for extending the panoramas all the way to the mathematical horizon. Sadly, there is a myth around that anything more than 30 miles away is hardly ever visible and therefore not worth showing. For me, searching for the more distant features, which are frequently visible throughout the UK, adds to the pleasure of hill walking.
The features are named from gazetteer files. The distances of the fractals are recorded for each ray. By clicking above or within a feature shown, the direction and distance of the fractal from the viewpoint, and hence its coordinates, can be determined. The appropriate gazetter is then searched for matching coordinates, and the feature name and distance placed on the image.
Curvature
Readers who are still with me will know that the surface of the earth is not flat. After reading DEM elevations, my panorama algorithm adjusts them downwards by an amount proportional to the square of the distance from the viewpoint. The constant of proportionality is determined from the radius of the earth and adjusted for the effect of refraction. It is set at 0.1695 metres/mile^2, i.e. the drop in metres is calculated by multiplying the square of the distance in miles by 0.1695. This figure allows for refraction by assuming the radius of the earth is about one-sixth higher than it actually is. It does not give exact results because the actual effect of refraction varies with the weather. It can be enhanced by temperature inversions. Under such exceptional conditions, features not shown on the panoramas may be visible.
For non-UK/Eire locations, where the DEM spacing is in arc seconds rather than metres, the locations of the elevations read by the straight rays must be converted from Universal Transverse Mercator (UTM) to latitude and longitude. This is done by interpolating in a 4km grid, rather than running the complicated conversion algorithm each time an elevation reading is taken.
Programming Language
I developed the software used to produce both panoramas and prominence listings myself, all the way down to the language in which the software is written. This language is much closer to X86 machine code than C++ or higher level languages. It is closest to assembly language, but without the long-winded mnemonics. This unusual approach has provoked, at best, lack of interest, and at worst, downright derision. This is disappointing, because the results are more compact, more flexible and run faster than anything in C++.
Most lower level programmers seem to use C++. About two years ago I decided that I really ought to try to move into line with the rest of the computer programming community, so I bought myself a best seller called "Teach Yourself C++ in 21 days". I soon noticed that the accompanying C++ program disk took only 16-bit instructions. I could never work with 2^16-byte data segments. In fact my earliest panoramas, dated 1993, were generated by Amiga computers using 32-bit Motorola 68K instructions, before 32-bit Intel X86 processors were available. I read on, and found that one of the C++ examples used 139 lines for a program which I was able to reproduce in 11 lines using my own language. Then on page 291 (day 11), I read the following sentence: "Other more advanced data structures that solve large data storage problems are beyond the scope of this book". At that point I gave up C++ and decided to continue to process my large data stores using the methods that I had developed myself.
I persevered with Amiga computers and Motorola 68K instructions until 2002. I had noticed that Intel X86 processors were getting faster, but I had been hoping that Motorola 68K technology would catch up with or even leapfrog Intel. But this did not happen. Eventually there seemed to be no alternative but to move over to Intel. Now the problem was the lack of textbooks on machine level programming; it became clear that the establishment did not want to encourage this. Eventually I found an Internet site with the necessary software and documentation. Rewriting my programs to run on X86 processors took several weeks, but was done.
Ultimately, my ability to produce panoramic maps and prominence lists are limited by the availability of Digital Elevation Models. Large quantities of accurate DEM data are required, and if these are priced in pounds/euros or even pence/cents per square kilometre, prices become prohibitive. The present system obstructs progress. Economic theory tells us that the general interest is best served when price is based on cost of reproduction. For digital data, this is infinitesimal.
The noble authors of Uncle Sam's Freedom of Information Act understood this well. Canada, Australia and New Zealand have been moving towards similar public domain digital mapping. Even in Great Britain pricing has moved down to reasonable orders of magnitude. But the rest of the world, including most of continental Europe, remains in the dark ages. Some countries even continue to restrict their mapping.
I realise that there is political pressure on national surveys to show profit, so that those with no interest in digital maps do not have to pay taxes to fund their production. But in reality everyone is paying anyway, not directly, but indirectly through higher local taxes, mobile phone charges and automobile association membership fees. All these are driven up by current pricing policy. But if national surveys must generate revenue then it should be from the profits of large companies, not individuals and their cats.
A big step forward has occurred recently, with the release of DEMs from data collected by the February 2000 Shuttle Radar Topography Mission. But no data was collected from the polar regions, and there are void areas coinciding with areas of very high relief, i.e. those areas that are most important for panorama and prominence generation. By various means, I have been filling these areas since 2005 - and with genuine elevation data, not merely by interpolation of 30" DEM data, which for SRTM3 void areas, tends to be little improvement on void data. The polar areas are taking me longer than I had hoped, but I still plan to complete them.
On the general subject of the pricing of digital mapping data, an article I got published in the International Map Trade Association's monthly newsletter can be found here (page 5).
Most of this page was wrirren in 2005, Minor revisions have been made subsquently.
List of stock VIEWFINDER Maps.............VIEWFINDER Home Page