The original Fleet maps are basically a spatial representation of data without complete database utility.  DigFindR maps are actually a database with spatial markers.  To make this implementation possible, all the data from the excavation symbols (known as 'attributes') was collected, normalized, recorded in a robust portable database, and the markers were re-cast in world space using exact geographic coordinates based upon the required three-decimal place minute notation.  DigFindR maps use an array of symbols rather than simply representing all spatial data with circles alone. The official Fleet maps require the use of AutoCAD to see the data.  DigFindR makes it possible to build maps independently, using the same excavation data, along with any records NOT found in the existing data.  With a little practice, you can add your own excavation data to the existing database using free, third-party tools such as DB Browser for SQLite, shown below hosting the current DigFindR database, AllDigs...





The Database


Traditionally, the data for the maps has been handled using an Access database and spreadsheets, without any strictly controlled record input mechanism.  Spreadsheets will generally limit records to around 65,000 rows/records.  There are more than 140,000 records to use, which means that they can not be handled efficiently using a spreadsheet.  The DigFindR records are stored, managed, and queried in a SQLite database.  SQLite is a totally self-contained database engine that does not require additional support modules to operate.  It is very compact, and very quick, running queries in the blink of an eye!  SQLite is widely used throughout the information technology business.  SQLite is in the public domain and no licensing for its use is required.  DigFindR has its own interface to the SQLite database, designed for ease of use, and pragmatic operation.  This Data Utility, as shown below, can be instantiated by a button click, or via the Data Menu...





You can find what you need by using filters at the head of each column, as seen above where the Vessel is filtered for LOBS (Lobster Man). The record count is 1586, meaning there are 1586 records in the database where the Lobster Man reported excavations.  Additionally, you may select records from the database using their Latitude values, rather than their Site values and then further filter the record set. All columns can be sorted in ascending or descending order.  Using filters, latitude values, and sorting techniques, you can isolate just about anything you need to find.  But, you must know what the data means, and how it might be recorded.  To make this easier, the data has been normalized to some degree where possible.


* In 2022 an additional column was added to the database as Zone, which is keyed to the new base map layout.




Normalization


The attributes of each excavation have been stored as ditems (data items) in the database.  There are ten ditems per record.  They are:


  1. Tag Number
  2. Description
  3. Vessel
  4. Quantity
  5. Year Found
  6. Latitude
  7. Longitude
  8. Site
  9. Date
  10. Depth


Tag Number:  if an artifact was found, it is given a state-supplied tag number, and a plastic tag is affixed with that number.  If the ditem is empty, there was no tag used.  Some artifacts are tagged while they remain on the bottom, in situ (as found), such as cannons.  The Tag Number ditem is alpha-numeric; it may have letters as well as numbers.


Description: the item observed and/or recovered is given a brief description in this ditem.  There are items described that have no Tag Number, but these are generally annotated "In Situ".  It can be tricky to find everything you want using the Description ditem.  For example, if you want to see all the records where coins (both gold and silver) have been found, you need to filter for the terms "Coin", "Escudo", and/or "Real". Each filter must be applied separately, meaning you have to search three times. If you are only interested in seeing records for escudos, you must filter for "Escudo", and "Gold Coin", performing the search twice.  This is because some operators used the word "escudo" interchangeably with the words "gold coin(s)"  Be aware that the filter is NOT case sensitive: you can type in "Escudo" or "escudo" and get the same results.  In fact, you could use the term "escu" and the database would still echo all records with "escudo" in the Description ditem field. The Description ditem is alpha-numeric.


Vessel: this ditem is supposed to contain a four-character moniker for the boat making the record... not a person... the boat.  There have been scores of boats involved in the Fleet salvage over the last sixty some years.  Over the years as the data from the daily log sheets was input, some clerks failed to use the correct moniker, or frequently used the whole name of the boat, to wit: "Capitana" instead of "CAPT".  These types of discrepancies result from input into the system without benefit of control tables that force the use of specific terminology per given ditem.  Many of these discrepancies have been corrected to reflect the proper moniker.  This is called normalizing the data, making it uniform, and easier to query.


Quantity: is a number only.  100 coins, 12 ballast stones, 3 cannons, ect.  You might see "0" as a ditem, meaning "nothing".  This is not necessary.  If, for example, the excavation was an Empty Hole (EH), then there will be an empty Quantity ditem to match.  You can find all EH records by filtering the Description column with the logic of "=" without applying any value, and all the empty hole records will show up.  It's counter-productive to filter the Quantity ditem for the term "0".


Year Found: while a great many of the records had no Year Found ditem, they did have a Date ditem, and the Year Found was extrapolated from that to fill Year Found ditem fields.  This normalization occurred because it is easier to filter for a four-digit year, rather than filter for a specific date. Almost all the records have a Year Found ditem.  Many records do NOT have a Date ditem.


Latitude:  there were thousands of records harvested that had errors in Latitude, either by being put into the wrong field, or by failing to format properly.  These have been normalized by formatting and proper field allocation.  Where no Latitude ditem was provided, the ditem was supplied by extrapolation of adjoining records, records recorded by the same boat on the same day.  Where that was not possible, the record was excluded.  The Latitude ditem is expected to follow this format example:  "28 36.455" (sans quote marks).  For Fleet maps, the whole two-digit degree, followed by a space, then a single or two-digit minute, a period, and a zero, or, a three-digit decimal minute.  Actually, the decimal minute can be a single-digit, two-digits, or three-digits, to wit: "28 36.006" and "28 6.04" are acceptable.  A whole degree exactly would be expressed as "28 0.0".  No other characters are expected or permitted.  There are a very few records that might have more digits in the decimal minute, and these will be ignored most often.  If an error is reported, for example while re-casting records from the Data Utility, simply hit the Enter Key and the operation will proceed. Trailing zeros or repeating decimal values are permitted, and you will find that records for 2009 typically use them.


Longitude:  there were thousands of records harvested that had errors in Longitude, either by being put into the wrong field, or by failing to format properly.  These have been normalized by formatting and proper field allocation.  Where no Longitude ditem was provided, the ditem was supplied by extrapolation of adjoining records, records recorded by the same boat on the same day.  Where that was not possible, the record was excluded.  The Longitude ditem is expected to follow this format example:  "80 36.455" (sans quote marks).  For Fleet maps, the whole two-digit degree, followed by a space, then a single or two-digit minute, a period, and a zero, or, a three-digit decimal minute.  Actually, the decimal minute can be a single-digit, two-digits, or three-digits, to wit: "80 36.006" and "80 6.04" are acceptable.  A whole degree exactly would be expressed as "80 0.0".  No other characters are expected or permitted. Leading zeros, typically indicating western values are not used, and negative numbers are not permitted. There are a very few records that might have more digits in the decimal minute, and these will be ignored most often.  If an error is reported, for example while re-casting records from the Data Utility, simply hit the Enter Key and the operation will proceed. Trailing zeros or repeating decimal values are permitted, and you will find records for 2009 typically use them.


Be aware that there were hundreds of records that were so extreme in their Latitude and Longitude values, they could not be placed in the maps at all.  These records were deleted and are not included in the database.  Also, in 2018 there were decimal degree values sharing some of the Latitude and Longitude fields with the usual decimal minute values.  While these can be used with greater accuracy to pin-point locations, these values were discarded from the database while the traditional format was retained.



Site: to manage all of the many thousands of excavation records, the leased areas are broken down into discreet parcels, with each parcel registered in the map set with a three-character abbreviation as seen below:





Contractors are provided with the map files according to where they plan to work during the season. If, for example, you planned to work on the Nieves at Douglass Beach, you would get the DOUGLAS BEACH map file and all of the attributes in that map would feature the DGB "Site" reference as seen in the sample DigFindR inquiry below:





In those instances where the Site ditem used a string of text other than the three-character moniker intended, the correct moniker was inserted in most instances.  There is no data at this time for the SPT (Sandy Point) wreck, and you will find records for the Rio Mar Wreck using "RIO", and "Rio Mar".  


Because there are so many records with improperly attributed Site ditems, the ability to search for records using Latitude ranges was added to the Data Utility.  This means that you can find ALL records in a certain area regardless of how they were saved using improper Site monikers.  DigFindR maps are constructed using Latitude ranges, rather than Site monikers.





Date:  the Date ditem is expected to be formatted as follows: a one or two-digit month, a forward slash, a one or two-digit day, a forward slash, and a four-digit year, to wit: "9/20/1948" (sans quote marks).



Depth: the addition of depth data to the excavation records is recent.  It will be a single or double-digit number indicating the water depth at the point of excavation.