The jpd2else utility converts the CIA World Data Bank II from JPD format
to plain TEXT and VMF formats (as well as to the older REZ format, in
order to provide compatibility with rmap or older versions of xrmap).

The enclosed script ./buildvmf shows how to build a VMF map and exploit
it with sunclock.

Notice concerning the JPD format
================================

The CIA World Data Bank II has been converted to a specifically designed 
format to be used with xrmap-2.0 and over. This format, referred to as
the JPD format, has a simpler encoding than the original Cobal data of 
the CIA Data Bank, and is also slightly more compact (11.5MB instead 
of 12MB for the original binary data, approximately 121MB when expanded
as ASCII data). 

The JPD format is organized as follows. All integers are signed integers
which are encoded either as 
   1 byte (-128<=n<128), 
   3 bytes (-8388608<=n<8388608) or
   4 bytes (-2147483648<=n<2147483648), 
in bigendian order (low weight byte first, big weight byte at the end). 
The unit used for the coordinates is 1 second of arc (1/3600 of degree),
both in longitude (x coordinate) and latitude (y coordinate).

A. First there is a header of 576 bytes

struct header
{
  char magic[12];
  unsigned char maxlength[4];  /* 4-byte integer */
  unsigned char index[560];    /* 140 4-byte integers */
};

The magic string identifies the format. It should be "!JPD1.0\n" completed
with zeroes. The maxlength string is a 4-byte integer indicating the 
maximal length of all segments present in the JPD file. The index 
consists of 140 4-bytes integers indicating the number of segments 
present for each of the 140=5*28 continents*types (5 continents and
28 types = 3 int(ernational) + 2 nat(ional) + 10 riv(er) + 11 cil
(coast-island-lakes) types of segments. They are grouped by continents,
0=africa, 1=asia, 2=europe, 3=north america, 4=south america, with all
28 types being contiguous for each continent. The index i-th value 
is actually the total number of segments of (continent,type)<=i where
i=0..139, so that the last value is the total number of segments.

B. The header is followed by a number of "segment_index" records (the total
number of which is the last index value in the header, starting at address
572 there). Each of the segment_index records consists of 16 bytes:

struct Segment_index
{
  unsigned char minlong[3];   /* 3-byte integer */
  unsigned char maxlong[3];   /*       "        */
  unsigned char minlat[3];    /*       "        */
  unsigned char maxlat[3];    /*       "        */
  unsigned char address[4];   /* 4-byte integer */
};

The first four 3-byte integers indicate the bounding box of the segment in
terms of longitude/latitude. The last 4-byte integer is an absolute pointer 
to the position where the segement is actually stored in the file. The
segment data themselves are stored in consecutive order after the 576-byte 
header and the list of segment_index records.

C. Each segment consists of an origin

unsigned char orgx[3],   /* 3-byte integer */
unsigned char orgy[3],   /* 3-byte integer */

where x refers to longitude and y to latitude, and a varying number N of 
strokes 

signed char dx, dy;      /* 1-byte integers */

which indicate the successive relative moves with respect to the origin
(1-byte signed integers for both dx and dy, un fact |dx|<=127 and |dy|<=127).
The total number of bytes is thus 6+2*N, and it is obtained by computing
the difference of addresses in the respective segment_index of ranks 
i and i-1 (from which N can of course be derived by subtracting 6 and 
dividing by 2...)


