	Old Hampshire Gazetteer MN's Notes
	Notes from Martin Norgate in 2001 whilst registrar for Hampshire County Council Museums Service.
Introduction	The Old Hampshire Gazetteer has been built for two purposes: to hold information about places in the county found on old maps and in old descriptions of the county, ie as an aid to the Old Hampshire Mapped project; and to be the basis for terminology control for recording place data in Object Records. Both these aims have limits which fall far short of making this gazetteer an all inclusive environmental record for Hampshire - it is not trying to be that. But the system could do that, probably more powerfully than other systems. All the data here is useful and most is fascinating. But if you need to know about 'all' the sorts of localitites which interest you, you must continue your research, by thorough searches of many other sources. We hope the bits served up here provide access to some fascinating sources.
sources	The sources used in preparing the Old Hampshire Gazetteer are widening steadily. The choice of sources is driven by the need to support Old Hampshire Mapped, and chance, and curiosity and opportunity. Each map which is thoroughly studied for the map project provides input to this gazetteer; the existence of a place on the map is noted with its spelling in that source. Each 'old' place is related to a 'modern' place - if that is possible. And to hold that data a record of the 'new' place must be made. This is done even if the modern place cannot be determined: some of the places in the gazetteer are supposition, or not well located. As well as holding the things we know for sure the gazetteer database has to be a notepad to hold things we guess, and may be able to resolve better in the future. Note that the lack of a position makes it difficult to use a GIS system to hold this data; in any case this data is predominantly text. Mostly, if a source is found to answer one problem in identifying an 'old' place, then all the data available in that source is loaded into the database just in case it is useful. In all cases the source is given so that you can go and check our interpretation of the facts, and look for more.
PLACE Records	Examples of how a selection of places are recorded can be found in an xml format as Raw Data. For a detailed explanation see below.
PLACE Format	The database structure is PLACE Format which is supported by MODES software, widely used in UK museums. The data structure is hierarchical, a very powerful style of data structure which has been found to be necessary to the complex and unpredictable data associated with museum objects and related data. This type of structure is used in this gazetteer project for similar reasons it is used for objects; the data associated with places is unpredictable and varied - far too varied for the tables of relational database management systems to cope with in a managable and clear way. The type of structure has affinities to the structure of language. The type of structure fits easily into software based on SGML (or its more comfortable subform XML). PLACE Format is still experimental. The Old Hampshire Gazetteer is its first large field test although a variant set of the format has been in use for nearly 20 years for recording museums as institutions (MUSREC Format). The format has close links with the OBJECT Format used in UK museums, and with a PERSON Format. In common wth the last it uses an EVIDENCE group of fields in a way that facilitates managing guessed and uncertain data.
PLACE Format rules	PLACE Format file: PLACE.rul MN: 28.11.1994 last edit 14.2.1999 PLACE RECORDS BEWARE: these notes are my working notes, jottings of ideas which are only gradually becoming organised for other readers. PLACE Format is being radically revised (not backwards compatible) later in 2001. This data structure for recording a locality attempts to provide a broad and general range of recording opportunities; I hope you can record anywhere! The structure has been grown from a knowledge of various building records, archaeological site and monument records, MUSREC for museums, and so on. I have stood back and taken a general view of what concepts need to be recorded. A mapping to all established data structures which have been made for specific tasks has not been attempted, how could it be? but the approach taken here should be sufficiently generalised to cope with most needs. In particular it is possible for the user to define how some fields and groups are used - so almost anything is theoretically possible, you can define a field to carry the data you want; mostly without undue stress to credibility. GROUPS The groups provided try to allow for whatever needs to be recorded, partly in specific fields, partly in general fields whose nature is defined either by the terminology used, by data in a subfield, or by terms in other fields within the group. Keeping a balance between providing for all likely or unlikely data, but not overwhelming the recorder with too many fields, is tricky. The groups provided are:- CLASS Same sort of idea as Admin_category in OBJECT.fmt Derives from CLASS group in MUSREC, used to declare records 'confidential' etc. IDENTIFICATION Identifying the Locality, where it is, summary description, etc. Also identifying the type of record being made. ASSOCIATION General group to record data associated with the Locality. A 'Nature' field defines what the link between locality and data is. EVIDENCE Group to record source data used in defining and identifying the Locality. (The idea parallels a successful experiment in PERSON.fmt, qv). RELATIONSHIPS To relate the Place recorded to another. Used together with Record type field in Identification group, the data here can link records of different types in one file. ADMINISTRATION A group to record who manages the Locality. A specific field; the data could be recorded in Association with Nature='administration'. FINANCE Analysed summary data about income and expenditure for the Locality. Detailed financial records are better kept in a spreadsheet; this experimental field should be abandoned. OWNERSHIP A group to record who owns the Locality A specific field; the data could be recorded in Association with Nature='ownership'. ACQUISITION How the locality was acquired, from whom, etc. This will only be relevant if the sites recorded belong to the recording institution; ownership can otherwise be recorded in an Association group. DISPOSAL How the locality was disposed of, to whom, etc. This will only be relevant if the site recorded belonged the recording institution (?). VISITORS How many visitors, what period, what type. This is not tested; a spreadsheet is a better place to record this sort of information? The field must be retained so that the format is upward compatible with the existing MUSREC standard. ACTION What is done to the locality, by whom, when, etc. A specific group that could be replaced by the use of Association group. DESCRIPTION A generalised group for descriptive data; this will include facilities, use, etc, mostly by means of user defined fields. MAPPING An experimental group for holding extensive mapping data, ie Coordinates, which makes it easier to control this osrt of data without clogging up other groups. Using this group does not overide the use of Coordinates field in any other group, especially Identification group. SURVEY Who surveyed the locality, etc. A specific group that could be replaced by the use of Association group. REFERENCES References to other data. NOTES Unanalysed data. RECORDER:DATE Who made the record, when. CHECKER:DATE Who checked the record, when; intended to record a check by the owner of the locality. The groups contain fields for person, place, date and event, etc, as appropriate, and have a number of utility fields. Do remember that it is not intended that all fields are used in every record. The style of data structure is enabling not prescriptive. The uses of the fields provided overlap, it is up to the user, planning a particular project, to use the appropriate set of fields, keeping in mind the relationship of the new project to existing projects where necessary and useful. Numerical Data The numerical data that can be recorded in Visitors and Finance groups cannot be analysed in the same way that descriptive data is for other groups. The data is far better recorded in spreadsheet software which I would recommend in practice. The inclusion of groups for this data here is to enable recording of summary data as part of the description of the Locality. I have tried to find very general ways of structuring data that leave the user able to define exactly what is recorded, and how. This has meant that the fields do not have an obvious structure as in other groups; local conventions to define their use are essential. PERSON FIELDS I have tried to be consistent with fields used for Person data; and tried for a balance between specific and general fields, allowing for different styles of recording. PERSON TYPE3 ROLE TYPE4 PERSON_NAME TYPE4 TITLE DESIGNATION TYPE4 QUALIFICATION DATE4 TYPE4 RANK DATE4 TYPE4 AWARD DATE4 TYPE4 ADDRESS ADDRESS_LINE TYPE4 POSTCODE POST_TOWN TELEPHONE TYPE4 PERSON_ID TYPE4 PLACE FIELDS I have tried to be consistent with fields used for Place data; and tried for a balance between specific and general fields, allowing for different styles of recording. PLACE_NAME TYPE3 OTHER_NAME TYPE3 PLACE TYPE3 STREET LOCALITY TYPE4 PARISH DIOCESE HUNDRED DISTRICT COUNTY REGION TYPE4 LOCATION LOCALITY_TYPE TYPE4 HABITAT SITE_NAME TYPE4 REL_POSITION TYPE4 COORDINATES TYPE4 MAP_NUMBER TYPE4 ALTITUDE DEPTH VICE_COUNTY LOCALITY_ID TYPE4 MDA_CODE ADDRESS TYPE4 ADDRESS_LINE POSTCODE POST_TOWN TELEPHONE TYPE4 DATE FIELDS I have tried to be consistent with fields used for Date and Event data; and tried for a balance between specific and general fields, allowing for different styles of recording. DATE TYPE3 DATE_BEGIN DATE_END TYPE3 PERIOD TYPE3 EVENT TYPE3 EVENT_TYPE EVENT_NAME EVENT_ID DATE3 TYPE4 PLACE3 TYPE4 MAPPING GROUP The following example records show how this group might be used; note that Coordinates in Identification group is still used for a 'root' ngr. A PARISH BOUNDARY PLACE_IDENTITY Nether Wallop parish IDENTIFICATION PLACE_NAME Nether Wallop ... PLACE COUNTY Hampshire LOCALITY_TYPE parish ... COORDINATES SU3036 TYPE4 centre SOURCE REFNO3 HANTSLOC.t MAPPING PLACE COUNTY Wiltshire COORDINATES SU256327 & SU262339 & SU260349 & SU262353 & SU252362 & SU237365 & SU239374 LOCALITY_TYPE boundary PLACE PARISH Over Wallop COORDINATES SU239374 & SU253376 & SU269375 & SU279376 & SU286382 & SU289281 & SU290284 & SU292283 & SU290280 & SU291279 & SU292280 & SU293279 & SU292278 & SU294277 & SU295278 & SU294279 & SU304290 & SU310302 LOCALITY_TYPE boundary LOCALITY_TYPE boundary PLACE PARISH Abbotts Ann COORDINATES SU310302 & SU320300 LOCALITY_TYPE boundary PLACE PARISH Upper Clatford COORDINATES SU320300 & SU324293 PLACE PARISH Goodworth Clatford COORDINATES SU324293 & SU328287 LOCALITY_TYPE boundary PLACE PARISH Wherwell COORDINATES SU328287 & SU330284 LOCALITY_TYPE boundary PLACE PARISH Longstock COORDINATES SU330284 & SU328281 & SU333272 & SU330266 LOCALITY_TYPE boundary PLACE PARISH Broughton COORDINATES SU330266 & SU323266 & SU319257 & SU306248 & SU302250 & SU292247 & SU290246 & SU278241 & SU275238 LOCALITY_TYPE boundary PLACE PARISH Buckholt COORDINATES SU275238 & SU267224 LOCALITY_TYPE boundary PLACE PARISH West Tytherley COORDINATES SU267224 & SU256327 & SU256327 LOCALITY_TYPE boundary DATE 1974 SOURCE REFERENCE OS: 1975: Administrative Areas Diagram, Hampshire The extensive recording of the parish boundary is experimental - just to show that MODES and this format could hold data for plotting in a CAD system. Output from MODES can be made together with a MMAGIC routine to produce an .dxf file, or .mcr file to load into AutoSketch for example. This is probably not a good way to 'do' GIS. The data is segmented to show which parish the boundary is with. In each sugroup the Place data is intended to stand alongside the Place data identifying the record that is in the Identification group. For instance:- Buckholt SU275238 & SU267224 boundary is the boundary of Nether Wallop (in Identification group) with Buckholt (in the Mapping.Place subgroup). The Mapping group can be dated and referenced. A RIVER's PATH PLACE_IDENTITY Wallop Brook IDENTIFICATION PLACE_NAME Wallop Brook PLACE PARISH Houghton PARISH Bossington COUNTY Hampshire LOCALITY_TYPE river COORDINATES SU338307 RELNSHIP tributary to: Test, River MAPPING PLACE PARISH Houghton PARISH Bossington LOCALITY_TYPE river COORDINATES SU338307 & SU338312 & SU334314 & SU332314 & SU328316 & SU325315 & SU324315 PLACE PARISH Broughton COORDINATES SU324315 & SU323315 & SU319319 & SU320320 & SU316322 & SU314325 & SU313325 & SU310333 & SU309334 & SU307339 & SU306340 & SU306348 PLACE PARISH Nether Wallop COORDINATES SU306348 & SU306357 & SU305358 & SU306361 & SU304364 & SU301365 & SU293373 & SU293376 & SU292379 & SU291381 & SU289381 & SU286382 PLACE PARISH Over Wallop COORDINATES SU289381 & SU286382 & SU283383 & SU281383 & SU278387 This is only a little, short, stream! No attempt is in the Mapping group to indicate the width of the stream, or any braiding. The inclusion of parish data is unecessary, but records the presence of the river in these places. In the HANTSGAZ database less detailed data is recorded. A RAILWAY LINE A railway line mighe be recorded with Mapping data:- PLACE_IDENTITY Oysterperch Railway IDENTIFICATION PLACE_NAME Oysterperch Railway PLACE COUNTY Burghshire LOCALITY_TYPE railway ... MAPPING PLACE SITE_NAME Burcester Station PARISH Burcester COORDINATES ST907568 LOCALITY_TYPE railway station PLACE PARISH Burcester COORDINATES ST907568 & ST910535 & ST920930 & ... Both spot positions, the station, and continuous lines might be recorded. A simplified approach might be sufficien for some purposes. A POINT A Point field, with the same subfields as PLACE in Mapping group, has been providied experimentally. It is intended to use this field directly - not to use the subordinate fields. The user might define conventions, but the use imagined is on the pattern:- MAPPING POINT [Locality type]: [Coordinates]: [Note] eg:- MAPPING POINT cross roads: pl.25/2 m.55'3 (Ogilby) & SU713372: turning to Worldham CONTOURS Perhaps contour data might be recorded. There are particular problems that the data for even one contour could be large. Can it be cut up by parish - no the parish boundaries are not stable, by grid square, yes but with dificulty in making segments match at the joins, ... BEWARE In all the Mapping group possibilities there is a nasty catch in data management, see a note below. UTILITY FIELDS Some utility fields are liberally provided throughout the structure:- PART For linking groups. - I would probably never use this or recommend its use. REFLINK To link group to a Reference. ASPECT:COMMENT A 'user defined' field pair. KEY This is somewhat like Part:aspect:desc in the museum world's Object Format. BUT with this arrangement you can have repeat Key fields with keyword lists from a hierarchical termlist (a facility that disappeared with the demise of the sublist separator, a semicolon). NOTE Any old unanalysed data, AUTHOR:DATE and its authorship. REFNO Reference to other data, KEY and a keyword for what sort of data you might find, or whatever. TYPE3 The type of data recorded in the field above it at level 2. TYPE4 The type of data recorded in the field above it at level 3. As a general rule in recording a Type3 or Type4 field will not be used if the field to which it attaches does not have subfields - ie does not use colon separators. Instead the type data will be recorded in the field after a colon. Example:- LOCALITY_ID ABB TYPE4 libary code will be written:- LOCALITY_ID ABB: library code This makes for much neater and more readable records. PARTICULAR TASKS There are some particular tasks that the format should be able to handle:- museum records ie MUSREC data, qv. site records All sorts of environmental records; archaeological sites and monuments, building records, natural science sites, etc. location code Museum store location control; see OFR file STORE.trm. boundary The record should be able to hold a 'definition' of the boundary of a place as a series of ngr points. unidentified place The system should be able to cope with records of places known from old sources, or wherever, that cannot be identified today. HANTSMAP PROJECT The HANTSMAP project, 'Hampshire Cartulary', is exploring the data available on old early county maps of Hampshire. Data on these maps is being related to modern places; records of the following pattern are beiing made:- PLACE_IDENTITY Nether Wallop parish IDENTIFICATION PLACE_NAME Nether Wallop OTHER_NAME Wallop, Nether & Wallops, The PLACE Nether Wallop & Hampshire LOCALITY_TYPE parish PLACE_NAME NETH TYPE4 library code COORDINATES SU3036 TYPE4 centre SOURCE REFNO3 HANTSLOC.t EVIDENCE NATURE old map PLACE_NAME Nethterwallop PLACE HUNDRED Thornegate COUNTY Hamshire LOCALITY_TYPE settlement & village COORDINATES SU33 TYPE4 imposed DATE 1595=1607 (?) PERIOD 16th century & 17th century SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.22 REFNO3 NORDEN1 EVIDENCE NATURE old map PLACE_NAME Neitherwallop PLACE HUNDRED Thorngate COUNTY Hampshire LOCALITY_TYPE settlement & village COORDINATES SU33 TYPE4 imposed DATE 1695=1701 (?) PERIOD 17th century & 18th century, early SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.33 REFNO3 MORDEN2 EVIDENCE NATURE old map PLACE_NAME Lowr. Wallop PLACE HUNDRED Thorngate COUNTY Hampshire LOCALITY_TYPE settlement & village COORDINATES SU33 TYPE4 imposed DATE 1788 PERIOD 18th century, late SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.34 REFNO3 HARRIS1 RECORDER:DATE MN: 11.12.1997 The historical information is added to data loaded from the termlist used for Hampshire localities: HANTSLOC.t. The data, so far, taken from three old county maps of 16th-18th centuries each with their spelling of the place name. The imposed ngr is explained in the HANTSMAP project notes; it is an indexing tool for the old maps. A hundred might have a record like:- PLACE_IDENTITY Thorngate Hundred IDENTIFICATION PLACE_NAME Thorngate PLACE COUNTY Hampshire LOCALITY_TYPE hundred COORDINATES SU21 & SU22 & SU23 & SU24 & SU32 & SU33 TYPE4 area EVIDENCE NATURE old map PLACE_NAME Thornegate PLACE COUNTY Hamshire LOCALITY_TYPE hundred DATE 1595=1607 (?) PERIOD 16th century & 17th century SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.22 REFNO3 NORDEN1 EVIDENCE NATURE old map PLACE_NAME Thorngate PLACE COUNTY Hampshire LOCALITY_TYPE hundred DATE 1695=1701 (?) PERIOD 17th century & 18th century, early SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.33 REFNO3 MORDEN2 EVIDENCE NATURE old map PLACE_NAME Thorngate PLACE COUNTY Hampshire LOCALITY_TYPE hundred DATE 1788 PERIOD 18th century, late SOURCE OBJECT_NAME map ID_NO HMCMS:FA1996.34 REFNO3 HARRIS1 RECORDER:DATE MN: 10.12.1997 Rivers should be recorded. A simple record could have coordinates to find one end, the lower end has been chosen, then - as an extra - a list of parishes through or by which it flows, and a note of its relationship to the next river 'down':- PLACE_IDENTITY Pillhill Brook IDENTIFICATION PLACE_NAME Pillhill Brook PLACE PARISH Upper Clatford COUNTY Hampshire LOCALITY_TYPE river COORDINATES SU3544 PLACE PARISH Abbotts Ann PARISH Monxton PARISH Amport PARISH Thruxton PARISH Fyfield COUNTY Hampshire RELNSHIP tributary to: Anton, River Plotting data could be included in Mapping group as shown above. PLACE_IDENTITY Miscellaneous thoughts about Place identity data, which must be a unique identifier for the record. NB do remember that the Place identity is just a record identifier: it is NOT the definitive Place name for the record. Serial number A 'content free' serial number, patterns:- [serial no] [prefix][serial no] etc. A prefic might be useful to keep particular sequences together, or have other manangement uses. A useful prefix in our database might be:- Parish code+serial number eg: ABB103 While this would group records within a parish together (which could otherwise be done from the recorded data anyway) it would set up a tricky situation for control of allocation of the numbers Source+serial number eg: Kelly 1907.123 or: GOSD1907.123 which has been used by IE to mean the same thing 'GOSD' refering to Kelly's 1907 directory of Gosport NGR ... plus 10Km square reference could be used as a prefix, eg:- SU28 for a recording describing a 10Km square This could have additions for various purposes, eg:- ST73 IA104 for iron age site no 104 within the 10Km square ST73 42 19 82 for data about 'spot' ST74183292, a 10x10metre square Quadrat biological record system, eg:- SU47D for a record about a 2x2km square. Again, add a serial number for records of areas within the quadrat Place name+modifier Use the 'definitive' place name, or a version; without a modifier there will be repetition, place names are not unique So, for Nether Wallop, use:- Ashton Common, Steeple Ashton Prefer the straightforward place name (Alternative forms, eg inversions etc, can and should be recorded within the record) There will be special rules to cope with repetitive names, for churches, rivers, ... Parish/Locality, subplace It may be useful to group some records under a place name, parish or locality for which there is already a record. For example nameless localities within a place, or perhaps streets within a locality, eg:- Ampfield, pound Alton, High Street, 3 If any historical research is used there will be a need to invent records for places that might never have existed. These could be signalled by a question mark in the Place identity, eg:- PLACE_IDENTITY Turton Magna? Sweetcote and might be supported by Note data justifying the invention, eg:- IDENTIFICATION ... NOTE cf Turton Lane, and Turton Magna Farm, ... HANTSLOC Rules Place identity will generally be on the pattern:- [Place name], [Parish] eg:- Holybourne, Alton Titchfield, Fareham The Place name is the definitive name for the place, this is described elsewhere. NB the 'parish' used is the civil parish, or pseudo parish where this is necesary; see OFR file PLACE.trm. This pattern is used as consistently as possible. Long parish names are not abbreviated, so that cross referencing is not compromised by differences in data. The long record identifiers that might be produced are accepted, eg:- Harbridge, Ellingham, Harbridge and Ibsley Note that the first comma is likely, but not guaranteed, to be the separator between Place name and Parish, but there might be further commas which are part of the data, not separators. Rule Modifications The general rule is not always apt. The parish term is not used when the place recorded is the same, eg:- Alton When the parish is recorded the word 'Parish' is attached, eg:- Alton Parish making a separate record. Parish records for parishes outside Hampshire will have their county name as detail, eg:- Verwood Parish (Dorset) If the place is conjectural, we do not know it exists, but are inferring this from other information, a question mark might beused, eg:- St Clair's? Denmead If the parish is not known you may record with an indication of this, eg:- Ashley Squires, () but more effort should be made to locate the place! A place that is unrecognised, from an old map, caan be located on that map by its hundred, eg:- Tertiodean, Titchfield Hundred Rivers Some 'places' need to abandon the parish modifier rule. For instance rivers are too extensive; the only parishes that would make any sense are that where the river rises or that where it loses its identity into a bigger stream. Generally use the river name alone, eg:- Stour, River Inversion is more useful than not. Duplicate river names need explicit rules for each instance; if this can follow some sort of common practice so much the better, eg:- Avon, Salisbury for that river which runs through Salisbury as different from the Bath Avon, or whatever. A single record could be made about a river. Additional records could be made to describe stretches of the river. It is probably better to do this in a disciplined manner; recording chunks parish by parish seems the best (but untested) idea. In this caes the parish term will be added into the Place identity, making a series of records, eg:- Wallop Brook Wallop Brook, Nether Wallop Wallop Brook, Over Wallop ... The chances of these records being in the right order is about zero! So maybe another idea could be tried - but I prefer to keep to an existing pattern. Routes and Roads Similar rules could be used for recording routes, eg:- Ogilby Route 25 and roads, eg:- Portway, The The Ogilby routes are those depicted by John Ogilby in his route maps, 1675. The number is the plate number from his road book. Subdivision of these routes into segments could use his distances from London, or parishes as before. The distances have the advantage of sensible ordering. The Portway could be subdivided by parish: but remove the ', The' when adding the Parish. Forests Forests are very large areas which cannot sensibly have a Parish; woods are smaller and should, eg:- Chute Forest Lower Wood, Ashmansworth Administrative Areas Administrative areas that are larger than a parish will not have the parish term. This rule particularly applies to hundreds, districts, county, etc. Examples:- Alton Hundred Basingstoke Borough Hampshire The word 'Hundred', 'District', 'Borough', etc should be attached to the Place name, but it is thought unnecessary to use 'County'. Churches The dedication of the church will be used, with the Locality or Parish, eg:-- St Mary, Alton Use the church's Locality if this is known, else use the civil parish - not the ecclesiastical parish. Unknown Places which have no known name could be recorded as:- Unknown, [Parish] Possibly adding a serial number to the first element if needed, eg:- Unknown [no], [Parish] EVIDENCE.NATURE Nature field in Evidence group is being used in the HANTSLOC gazetteer to declare what type of ewvidence is being recorded. the termlist for this field is:- old map Data taken from an old map, eg Saxton, Norden, Ogilby, etc. description Description of the place from an old geography or journal or whatever, eg Camden, Leland, Cobbett. archaeology Data coming from sitefinds or single finds. This may well be generated from Object Records of sitefinds groups or single finds. place name Place name explanations. coat of arms Descriptions of coats of arms, seals, etc. domesday Data from Domesday survey, via various sources. These terms might be used to group data for output. NGR DATA SETS There are various ways a set of ngr coordinates, for a boundary, contour, or other extensive place feature, could be stored. CAD Drawing The data could be stored as a CAD drawing. CAD is needed to 'see' the coordinate data anyway, so this is an obvious storage protocol. CAD data is not accessible except in CAD; the numeric values cannot just be read from a list, nor can they easily be manipulated except within the CAD environment, with only whatever procedures the CAD software provides. It is possible to get the numeric data out in .dxf form (which is a nightmare to read) and to do calculations on the data there. DXF File The 'master' copy of the coordinate data could be stored as a .dxf file; output from a CAD drawing or generated by other means. Data in this form is very portable, in theory. In practice there are differences between .dxf formats for different CAD software that make portability unreliable. The format is horrible to understand, very inefficient, and needs to be loaded into CAD to be seen. Some image software can read a .dxf file and convert to raster, making a useable image file; the quality of this conversion is sometimes poor. DXF data looks like, following a complicated header, a series of entries like:- POLYLINE 8 1 62 4 70 0 66 1 40 0 41 0 0 VERTEX 8 1 10 390.7 20 156.8 0 VERTEXT ... SEQEND MCR File Some CAD software can make and use a macro file, imitating what would have been done within the CAD program to make the drawing. In AutoSketch this is an .mcr file. It would be possible to store coordinate data as an .mcr file; the file has a simple and reasonably efficient structure which can be generated from other sources and then used in CAD. The data is fairly readable but has to be loaded into exactly the right CAD software to be seen. Eg:- "Menu","Polyline" POINT 390.7,150.8 POINT ... ASCII Text Coordinate data could be stored as an ascii text file, marked up with tags in some way to make the data 'useable'. The data is comprehensible and safe, but has to be edited into a .dxf or a macro file before loading into CAD; it has to be loaded into CAD to be seen. Eg:- @by ST907568 ... MPLUS DATA The PLACE Format can store coordinate data in a MODES file. The data storage is compatible with all our other museum data and is easily understood, if a bit unreadable if there is a lot (the same applies to any data set). MODES can output the data to .dxf or a macro, or whatever, with a little help from MMAGIC software which is already written; the data has to be loaded into CAD to be seen. Data storage is not inefficient. BUT - In the use of Mapping group described above, note that each segment of line is intended to stand alone as a 'polyline' in a CAD drawing. Drawing each segment separately they must join end to end properly; this demands that data at the end of one segment must equal data at the start of the next (and is recorded twice). Recorded data for a boundary might belong in two separate records, it could initially be copied from one to the other. The data will be very difficult to manage; it will be difficult to maintain integrity. Relational Tables It may be far better to store mapping data outside MODES; and a relational database management system will probably be the best idea. It is likely that a future MODES, networked, in Windows, will be able to use such data. Terminology Control It may be possible to generate terminlogy control files (OFR termlists or MODES .vln files) from the database. To facilitate this it is necessary to include a note of what field in a MODES format the definitive place data found in Item name field, belongs in. A suggested pattern of recording is:- IDENTIFICATION PLACE_NAME Alton TYPE3 Place term PLACE ... LOCALITY_TYPE parish which defines 'Alton' as a valid parish term to go in a keyword list in Place field. In this database the other Type3 term used, so far, is 'Site name term'.