DatMapR uses data held in a DatMapR Project file. These are created (or selected) and managed through the Project / Data Management window, which is opened from the Main Window.

(The Project files are ‘SQLite’ databases containing three SQL tables – Fields, Settings and Data. They can be edited by the user (if required and if they are very brave!) using a facility such as the SQLite Manager plug-in for Firefox. If someone asks very nicely I will explain their structure, but editing them is done AT YOUR OWN RISK – and you should always make a copy of the file first, just in case you corrupt the content!)

If the project is NOT based on OS NGR, the location data has to be imported as numeric values which are treated as Eastings and Northings (i.e. left to right, and bottom to top). Their meaning and precision is then a matter of convenience to the user (e.g. they could be Longitude and Latitude as decimal degrees).

Whichever format is chosen, the location data will be held within the data records as two numeric values, called (for simplicity) ‘Eastings’ and ‘Northings’. If the data was imported as OS NGR strings, the ‘Precision’ of the reference will also be stored within the data records (e.g. SK123456 is at 0.1km precision, SK1234 at 1km precision).

'Precision' may be an illogical name for this value since a higher 'precision' has a lower numeric value!!!!  Perhaps 'Imprecision' would be better - but what's in a name!

The precision is used for formatting information messages in the Map Window (by regenerating an appropriate OS NGR from the E/N coordinates), but it can also be used in the selection of the records to be mapped (in the Main window)  (e.g. selecting those records where the 'NGR Precision' is (numerically) less than (say) 10km - i.e. omitting any records which are considered to be too imprecise).

As well as the Location, 10 data fields are held within the project file and are, by default, imaginatively named ‘Field 1’ – ‘Field 10’, but these names can be changed in the Project / Data Management window (or in the Import window) to convenient Short Names (e.g. Species, Year, Area, PerCent Cover). These short names will be shown in pull down lists within the other windows and in other text.

Each of the 10 data fields needs be flagged as Numeric or Text. This will affect how the field is handled within the other windows and in the mapping – e.g. Numeric fields can be aggregated as a Sum or an Average, while Text fields can only be Counted.  The flag does not affect how the data is stored, only how it is used.  (Internally, all data is held as both Text and Numeric values.  A 'non-numeric' text value (e.g. a Species Name) will be treated as a 0 numeric value.)

Each field can also be given a Description, but currently this is not used by the application.  It is purely there as documentation for the user.

The Short Names, Content flag and Descriptions can be changed at any time, either here or in the Import window. They do not have to be defined when the project is first created. They do not affect how the data is stored, only how it is used. The Short Name and Description are primarily there for the convenience of the user.

Not all of the data fields need to be populated when data is imported.  In fact, it is quite acceptable to import no data into any of the data fields.  In that case, the import will populate 'Field 1' with a dummy value of '1' which can be counted or summed to map the number of records.

Data fields not included in the import will be populated with 'null' values. Blank values within the imported fields can also optionally be treated as 'null' in the Import process.  'Blank' is regarded as a valid value and is therefore included in counts.  Null is not - it is treated as missing data and is omitted from aggregations.