• Software GNU Copyleft.
• One thing is becomming clear is that it will be necessary to process the data in a database to build the output data structures.
• A pre processing of the data to generate lists of data by quad.
• Would need to be done on a state by state basis, or even partial area of a state at once.  This is due to the volume of data present in some states.
• Partial data compaction can be done at this step.
• Border cells could be merged in a latter process.
• All states would need to be processed with the same code using the same base quadrant.  I propose 0.00 Lat / 0.00 Lon as the refference point as I ultimatly wish to streetmap the world.
• This will allow us to get an idea of the area densities involved.
• Long = 32bit int.
• I'd like to maintail as much of the source data information as possible.  This includes Street Numbers, zipcodes, etc as realistically possible.  Zip+4 likely can be dropped, but I want to be able to definitively tell it to highlight XXXXX zipcode, and have the zipcode area highlighted, or substitute Town Name or some other feature.
• Thoughts should be entertained to make the CD-ROM data structures able to handle data from other countries.  The US isn't the only country with digital streetmap data.  What are the others?  Can we get their data also?

• Provides Index to find out which quad(s) to grab for rendering.
• Looks like the top levels will all be index entries due to the number of bits available for lat/lon vertex use.  (Data could possibly be pre-processed on a state by state basis into the highest level where data can possibly be stored at.)

With this layout I'm getting away from fixed size blocks.  Linear lists seams to be a better way to go.  Much more potential for compaction, quick reading from the realistically linear CD-ROM.

• A group of data all pertaining to a specific square region.
• I'm seeing an initial header index with Long offsets (16bit) that point to starting offsets for each type of data in the quad.
• Offset is NULL if the type of data isn't present.
• Last (or first) entry in the table is the overall length of the quad data.
• The 16bit offset value is the Long sized memory unit offset from the start of the Quad-Data structure.
• This gives a maximum of 256k Bytes per Quad-Data Structure including header.
• This means out Quad-Data blocks will be somewhere from 64k to 256k in uncompressed size.  This is a nice size for in memory processing of a block at a time.  Some blocks in sparce areas may be under 64k, but I see that as unavoidable.
• Each type of data I see having an initial header, then a packed list of elements.
• Datasets found in Quad-Data (Order may be different.)
1. Vertex Data
• Street Lines
• Highway Lines
• Interstate Lines
• River lines
• River Boundaries
• Water features Boundaries (lakes, ponds, etc.)
• Political Boundaries
• Town Boundaries
• ???etc.  ( An authoritative list needs to be generated.)
2. Place-Names Data
• Street Names
• Town Names
• Feature Names
• ???etc. (again an authoritative list needs to be generated.)
3. Polygon Region Data
4. Linkage to relate Street-Segments to Place-Names
5. Linkage to relate Polygons to Place-Names
6. ??? Plus More ???
• Stuf to be determined
• How far can we go in reducing the effective resolution of the coordinate data?  10 feet at 40 Degrees North? (1/3-1/2 average street width?)  (Remember personal GPSs are only good for +/-300ft.
• Determine the number of bits to use in the vertex lat/lons?
• 16 bits = 124 Mile wide Quad Area at 10 feet per bit at 40 Degrees North.
• 14 bits = 31.0 Mile
• 12 bits = 7.75 Mile
• 10 bits = 1.93 Mile
• 8 bits = 0.484 Mile
• Should we handle differing sizes of bit information in quads?  If so we can implement one size first (say 12 bits).  Get it working, then extend the code to handle smaller and larger bit sizes.
• Do we want to try to handle bit sizes at 14 and 10 bits per vertex?  Below 8 sounds pointless, but 10 may be usefull for cities and 14 for suburbia.

• I envision a Place_Name Object that for the most part behaves like a string, but really is a highly compacted string.
• Each string would be made up of refferences to other Place_Name strings, and sequences of characters.  This idea comes from compression programs.
• Note this is not writeable at run time.  It needs to be precoded.
• Encoding of string:  (For this number bits 0-31 starting from highest order bits first in byte / word / long)

Bits 0-1 =	full code length	Use / Notes
00	Byte	bits 2-7 = # telling how many of the next 63 bytes are a string of charecters. Note: Value 0X00 = string of zero bytes long, or in otherwords a null string or end of line marker.
01	Byte	Use bits 2-7 = first 64 entries in Place_Name_Table (Note will be the 64 most often showing up words used in place names, like Rd, Ln, St, etc.)
10	2 Bytes	Use bits 2-15 = next 214 entries in Place_Name_Table
11	3 or 4 Bytes	Use bits 2-23 = next 222 entries in Place_Name_Table (Note: possible will need to have this be 4 bytes long.  Depends on the max number of entries needed.)

• Format of an entry in the table:
1. List of ((00 Code Byte + string of one or more charecters of determinable length) || (01 Code Byte) || (10 Code Byte + Ext Byte) || (11 Code Byte + 2/3 Ext Bytes))
2. 00 Code Byte with Zero Length.
• An external refference to the Place_Names Object would be a 32bit integer selecting which entry to display.
• A possible variation is to do this on a quad by quad level to get the table size to a more manageable size, and only have those names needed for current rendering in memory.  I think this would be the better solution.
• The table should be able to be stored on disk as a list of only the compressed strings, then assembled into a string starting pointer list plus compressed strings data on read in.
• Note: If strings like "RD" are stored with the preceeding space like " RD", then that takes care of storing that space.  Likely after frequency analisys code 00000001 will be set to space to handle the spaces between frequent words.
• The codes in the 11 area can be sorted by Alphabetical order of the decoded string to aid in determining if X name / word shows up in the quad.  The 10 code area can also be treated this way, but likely separitly sorted area, as well as the 01 area.

• Identify / Quantify / Enter code lists.
• Build input templates for all data files.
• Line and area clipping algorythims need to be determined.  Initially algorythims can be picked (any known packages that provide).  Then data source and destination adjustments can be made.
• Determin an implementation language.  I vote for C, C++.
• Make or find a GPS Unit Interface Library / whatever.  (Bulletproof it).
• Devise the GUI interface
• I'm partial to using Gnome as the basis rather than KDE as it's fully copyleft free software.
• ??? Help me fill in more areas to work on. ???

• (Tiger Manual) OLD.
• wxWindows (wxwindows.sourceforge.net) Cross platform windowing library.
• 2k data errata (www.census.gov/geo/www/tiger/tiger2k/error2k.html).
• 2k data (www.census.gov/geo/www/tiger/tiger2k/tgr2000.html).