Data retrieval & project planning
New thoughts on work with Davin (6/5/04), remembering that we need to get cash flow started ASAP and with minimual outlay.
- We've got to be impressive (splashy).
Census data is a dull subject and nobody will be out of the box interested in anything on that subject.
- We do have an advantage in that we have some very desired data that nobody else has (block level income data).
- There is a big market in small area analysis.
Claritis, Arc-Info, MapInfo and Fred's MS GIS system will be our guides. Thank goodness for apl-draw.
Because of our having block level income data,
we could become the preferred product for that sort of work for many types of clients.
- APL cannot be the primary software vehicle because it will take too long to get an RTS version ready
and we'll then always be struggling with programming challenges.
Instead I'm calling what people will see and hear about is code named APSQL (pronounced "apsqueel").
I'm imaging Pervasive SQL with Davin's apl interface and with as comfortable and familiar a user interface as possible,
I'm hoping we can make good progress on this before I talk to Mellon United Bank.
The hope is that data retrieval & display can be demoed and discussion will be around
SQL and Access, not APL.
APSQL will have the following characteristics.
- Ease of interaction. It will never "go dead" like an APL RTS system can.
- It can include the powers of APL.
- It will provide SQL as a means for adding data and for linking it to external uses and databases.
- It must be self-adjusting so whenever data is added or changed, all the parts of the system know it.
- I have data for a third county but no paying client.
That means we can use it to establish our procedure for rolling out a Florida, Texas, and national database.
It is a small county (Martin County, FL) and we can do anything we wish to the data and not worry about hurting a client.
- The platform we are creating will work for my real estate software.
In fact our new platform may greatly enhance its usefulness.
Where my current real estate software has a line item called "roads",
the new software will have relational tables of projects or contracts to be let to build the roads.
Roads not detailed can be lumped into a project called "future roads".
The same logic applies to hundreds of other cost and revenue line items and budgets.
By building on an SQL database, links to accounting systems will be easy.
Below are notes I made a month or so ago.
"QK Software" provides the following functionality.
- It is designed for the census database being developed for Polk County & Lake County (Florida).
- The following user commands are provided (in the first version of the software).
- Select one or more topics (ceDataSet) either individually or from datasets (ceDataSets).
- Select one or more geographic areas (ceTargetArea).
- Select census sources which include that topic ("100% count" or "sample", 2000 or 1990) (ceSources).
- Select presentation aggregated or in detail (ceRollup).
- Compare the data selected with the same data in another census, e.g. 2000 vs. 1990 (ceSources).
- Revise any of the above and display again.
- Export data on the screen for import to Excel or other software (.csv file).
- The following features are expected to be added with conversion to an SQL database.
- The user will be able to add data (without engaging the creator of the software).
- The following is a description of the data warehouse that exists at present.
- Source databases are identified in ceSources.
- Syntax to learn what is in each file is shown in ceDataAvailable.
- The generic data dictionary is in 5001 13. Access it easily with ceGlossary.
- The translation of db specific table names to QK generic aBBR is in 5001 11 (fields are in 5001 12) & in 5001 10.
Those sources are redundant and should be reduced to a single source.
Redundant sources are managed with help from ceInventory.
- db delivers any data without properties such as row & column titles.
- dbPVM delivers any data with properties such as row & column titles.