e.g. For an icosahedron defined as follows:
Diagram: A regular icosahedron (courtesy of Microsoft Visio):
We define position and orientation w.r.t. this body's frame of reference as follows:
- Point O at the origin: (0, 0, 0)
- Point P within the half-line: (x=0, y>0, z=0)
- Point P1 within the half-line: (x=0, y<0, z=0)
- Point A within the quarter-plane: (x>0, y<0, z=0)
Question 1: Formal methods/conventions?
Is there (a) a formal way to index/order the faces of a regular polyhedron? In other words, are some methods of ordering the faces/vertices etc., more correct, logical or conventional than certain other methods? If not, then do certain face encodings/orderings facilitate more efficient vector manipulation? How then should the faces be ordered, or, in what order should we generate their normal direction vectors?
OR, is it (b) a matter of arbitrary discretion according to the requirements of the specific application one is designing for; or otherwise arbitrary due to fundamental constraints on the shape of the data structures & algorithms required to manipulate these data most efficiently?
Question 2: Ordering for recursive precision
Suppose we break each surface triangle down recursively into four sub-triangles so that:
- Any face may be folded if its edge-adjacent neighbours are also folded along common edges and their constituent sub-triangles stretched (each sub-triangle remaining flat but no longer remaining coplanar with each other); so as to more perfectly approximate the curved surface being modelled
- Each successive ≈4× improvement in area precision requires exactly two additional bits of information to store the resulting surface-positional “reference code” or “index number”
Is there (a) a formal mathematical way to order or encode these constituent sub-triangles?
Or is this (b) open to the engineer's discretion, to define a convention that he prefers?
Do some encodings of the constituent triangles permit more efficient data manipulation, or is this choice arbitrary? Can this be proven either way? If the choice is theoretically arbitrary, then does a relevant mathematical convention already exist?
Typical application: geographical data visualisation
We will use this for data geocoding, indexing, querying & visualisation; using polyhedral projections from near-spherical shapes (the surface of the Earth) with the best all-round properties of:
- computational efficiency (for encoding/ retrieval/ visualisation)
- low spatial distortion, high area uniformity by code space
- information density
- conceptual simplicity
Our general purposes are illustrated by this document:
Suggested conventions for mapping geographical data
We will orient our icosahedral mapping so that:
- Point O (the origin) corresponds to the centre of mass of the body being modelled
- Point P corresponds to the geographical North Pole at +90° latitude
- Point P1 corresponds to geographical South Pole at −90° latitude
- Point A lies within the half-plane containing the prime meridian i.e. zero longitude in the standard modern polar (latitude, longitude) coordinates. The icosahedral diagram here:
— from Jack van Wijk's work on “myriahedral projections” appears to validate the near-optimality of this convention for planet Earth in the current geological era.
For modelling or display purposes, the model polyhedron should be scaled such that its volume is equivalent to the modelled geoid. Where the geoid is irregular and the modelling polyhedron is of high resolution, approximations to this rule might be considered acceptable.
Reference design for encoding surfaces/ positions
Unless advised of a better way, we plan to order the faces first according to their apex orientation with triangle base perpendicular to (P→P1), whether up/down with respect to vector (P→P1); and second (for each orientation) in a spiral/helix, working first anticlockwise around (P→P1), and then clockwise around (P1→P) for the opposite apex orientation. This would number the 20 main triangles from 0 to 4, 8 to 12, 16 to 20 and 24 to 28 as follows:
+ 0 1 2 3 4 0 P A1 B1; P B1 C1; P C1 D1; P D1 E1; P E1 A1; 8 A1 A B ; B1 B C ; C1 C D ; D1 D E ; E1 E A ; 16 P1 B A ; P1 C B ; P1 D C ; P1 E D ; P1 A E ; 24 B B1 A1; C C1 B1; D D1 C1; E E1 D1; A A1 E1;
— This coding system has discontinuities to simplify logical functions for calculating surface polygon orientation, which is necessary for translating position data between systems of coordinates (orientation might be considered on the basis of individual triangles, or cumulatively on the basis of recursive N-ary sum style positional calculations). Note that the rows in this table correspond to horizontally oriented slices of the icosahedron, whereas the columns in this table correspond to diagonally (near-vertically) oriented half-slices.
We plan to encode each sub-triangle recursively as per:
File format; recursion-conforming data compression
We plan to support data compression and adaptive rendering by storing at each detail level only the differences from the average values corresponding to the hierarchical parent surface. In accordance with this objective, location codes will be stored and communicated in a big-endian format. If modelling a perfect unit sphere, the “unit sphere” should be of unit radius. The volume of the unit spheroid/geoid etc. should generally approach 4π/3 cubic units as closely as possible (altitudes should be defined in proportion with such a unit geoid, and a scale factor should be specified for the entire geoid).
Community benefits (public domain, IP considerations)
To promote industrial standardisation; I now release these plans freely here, and will further consider releasing my work freely when complete as a set of open-source software libraries. For the record, I (Matthew Slyman) started working independently on this project some time around the year 1993, and first proposed this idea to Iestyn Bleasdale-Shepherd late in 1996 (he implemented the first proof-of-concept as an IBM PC program written in C over the Christmas holidays of 1996–1997). We subsequently shelved the original application we were discussing; and as the originator of this idea and the sole developer of this specification, I (Matthew Slyman) hereby relinquish any claim to the intellectual property rights for this data structure or any compatible code implementations that might be created by third parties. In order to better serve the mathematical community, I would like to give priority at the design/implementation stage to any relevant formal mathematical requirements or conventions. Anyone commenting on this thread thereby places their comments likewise in the public domain, for general community benefit. In the absence of further instruction, we will number the faces according to our practical requirements or whims (see above). We would be grateful for any formal improvements that can be offered by anyone better educated in mathematics.
I propose to give this standardised set of conventions a name: “Icosamap”. Please register any objections to this name, including links to any evidence of priority within the relevant field of science.