How to create a gazetteer - what I've learned

I recently completed the seventh year of continual work on the Mycenaean Atlas Project. In that time a great deal has been done but that's not what I want to write about now. I want to write about what I've learned during this work - and one thing in particular. 

 When creating a gazetteer or Atlas of the world of antiquity you must tell the user a story about each site. 

A gazetteer is not simply a matching list of feature names with latitude/longitude pairs. No usable gazetteer of antiquity can be written in this fashion.  Why not?  Because there are too many sites whose positions we do not know for certain.   So when choosing a lat/lon pair it almost always is a judgment - an approximation or a guess.   The user has to be told what went into that judgment.  In that case, it is crucial to give the user some hints about how to proceed in the face of uncertainty. At the very least the user must be given in full the references that you used (and with internet links if possible). 

Full disclosure is important when articles and/or books are not available to the gazetteer creator. For example, the ancient city of Iton in Phthiotis poses a number of geographical puzzles concerning not only Iton but the nearby sites of Zerelia, Karatsadagli, and Marmara. These sites form a little conceptual cluster which may or may not have something to do with a temple (the Barrington Atlas shows Iton and Marmara as cult sites). The gazetteer writer has to sort the sites out, locate them, evaluate their significance, and in particular, discuss the problem of whether there was or was not a cult of Athena Itonia in that area (as Strabo claims).  In my Commentary on Pleiades I went all the way back to the original investigators but I wasn't really able to seal the deal - to remove the last bit of ambiguity. The reason? I have no access to Lalonde's Athena Itonia: Geography and Meaning of an Ancient Greek War Goddess from just three years ago. Brill wants $195.00 for it and Amazon wants $143.00. Impractical either way. This isn't really a complaint. For one reason or another, this happens a lot and to just about everybody. How did I handle this? This is the message I put at the end of my comments for Pleiades 540935 which deals with Marmara. 

"Most of these questions should now be resolved in Lalonde [2019].  Regrettably, Lalonde's book was not available to me at the time of writing." 

Pleiades Commentary on Marmara (Pl. no. 540935)

 Now that the user is warned he or she might be able to get their hands on a copy of Lalonde and figure out the ambiguous parts. 

- Room has to be given to scholarly disagreements.  In the case of Iton which I mentioned above both Stählin [1924] and Philippson [1950] think that there was a temple there.  Roller [2018] thinks not.  The user needs to be told.

 - There are puzzles of transliteration to work through. The user has to be told what these are if they are material. 

 - Bibliography, bibliography, bibliography.  The user needs to know what research the position is based on.  Gazetteers are not just a circular citation game where gA cites gB and gB cites gC and gC cites gA. The user needs to be grounded at least as well as the gazetteer maker himself or herself was grounded. 

 - Misleading descriptions by the primary investigators. Investigators routinely get directions wrong, distances wrong, etc. Investigators are human. We get it. But when these problems are identified then the resolution (if there is one) must be explained to the user.   Here's an example: of a site in Euboea Sackett says 

" ..., Kherronisi, is a rocky headland immediately south of the island church Ayios Nikolaos. It is about 25 m. above the sea ... "[1] 

But Kherronisi isn't south of the Ayios Nikolaos - it's to the NE.  And the elevation of Kherronisi is not 25 m. - it is no more than 15 m.  I nearly made a serious error here but I finally convinced myself, in the teeth of Sackett's description, that Topostext was right in their placement and so I followed Brady Kiesling's solution.[2]

Pleiades Commentary on Helleniki (Pl. 540809)

Status of the commentary on Pleiades:  As of 12/11/22 I have completed some 400+ corrections/annotations to the Pleiades dataset.  These corrections complete the repair of the  rounded coordinates for mainland Greece as far north as Thessaly, the Cyclades, Crete, the Dodecanese, and some of the islands of the Aegean NE.  I have made the data table of these corrections and supplemental notes available to Pleiades. Perhaps they'll be interested.

Because there are about 5000 potentially correctible sites I won't ever be able to finish this.  But already Pleiades, for the Greek worlds and as seen through my Digital Atlas, has a much bouncier and usable feel.  It starts to be what it should be - a product that pays attention to correctness and usefulness and, as a result, gives the user confidence in the result.  And using the Digital Atlas you can also easily compare  Pleiades' solutions with the solutions of the Vici, DARE, and Trismegistos data sets as well as to the Topostext gazetteer and to de Graauw's Harbors.  

The Digital Atlas is now a working prototype of a full-up gazetteer of Antiquity.

And, as always, this is a useful reminder.

Footnotes

[1] Sackett et al. [1966] 42, #11.  'Elliniko'.

[2] Topostext is here, Pleiades is here, and my own solution is here.

Bibliography

Sackett et al. [1966] : Sackett, L.H. with V. Sankey, R.J. Howell, T.W. Jacobsen and M.R. Popham, 'Prehistoric Euboea: Contributions toward a Survey', Annual of the British School at Athens (61) 33-112.  1966.  Online here.

Digital Antiquities Databases; Their Visualization and The Mycenaean Atlas Project Digital Atlas

Several of the common digital antiquities databases have very poor or non-existent visualization tools.  Their focus is showing you individual sites on a map and with precious little other support.  The least satisfactory in this regard is Arthur deGraauw's Harbors project.  Dr. deGraauw is an outstanding expert in the field of harbor research; he freely and generously makes his data available to everyone.  This data is, however, in the form of a spreadsheet (computer types refer to this as a 'flat file') and no map visualization is possible on his site.  The remainder among these various DBs provide a dedicated page for each site along with minimal, mostly useless information about it, but without any larger visualization.  The best user interface among these databases is Vici which provides a visualization map for each site and shows you the context.  I do notice, though, that when I use Vici that there is often no site description or indication of the site's significance.   Here's an example: this shows Neftina on Lemnos which appears to be a quarry although we are not told this:

Vici is actually pretty good and contains nearly everything you want in map visualization.  Vici also  provides context in the form of other near-by sites.  The zoom-level is user controlled and jumping to another site does not require you to go back into outer space before zooming in again.  

Multiple Databases

When research involves the several popular databases dealing with antiquity it necessitates running back and forth from one window to the next and trying to put all this data into context.

   

There must be a better way.

What do we require when visualizing geographic data from antiquity?  Ideally we should be able to see all the data simultaneously on one map so the databases are inter-comparable.  Is the site coverage around Peristeria in Messenia significantly different between Pleiades and Vici?   To answer this question you need these two DBs on the same map so that they can be compared.  And each site on this combo-map should link back to the dedicated page which contains more info about that one site.  The map itself should be interactive. You should be able to click/tap on it and have it redraw centered on where you've clicked/tapped; restoring the data context at the same time.

 We're talking about a lot of data here.  The M.A.P. Digital Atlas can display abut 100,000 data points.  So when the user looks for one site (Chania on Crete, say) how many surrounding DB sites should be drawn automatically? 

Dumping the entire DB is too much.   It's time consuming.  Most of the DB would not be of concern to the user.  And the program response would take a significant hit.

Showing just the individual site is too little.  (Pleiades is worst in this regard.  P. annoyingly zooms in from outer space for every site search and it never shows any context.) 

Pleiades: Searching for Kydonia.
Phase 1: Outer Space!

Topostext shows the context around a sought-for site but it also forces the user back into outer space in most instances.)

The Mycenaean Atlas Project Digital Atlas chooses a middle way.  What is needed is enough context so that the user can work for an extended period on that specific level (Zoom levels 12-18 in most instances).  The Digital Atlas creates and  populates a frame which is about 1/5 of a degree in lat and lon.  In practice this seems to afford adequate space for investigating the immediate surroundings with little or no detectable drawing time.  When the user clicks/taps on the map it is redrawn with the new frame centered at the click.  The new frame is filled in from whatever data sets the user has chosen.

Part of Lemnos in the Mycenaean Atlas Project Digital Atlas
Features (red F paddles), M.A.P. sites (Bronze Age) in blue and Trismegistos sites are displayed

In any solution all the data sets should be visible.  In practice, even when limited by a frame, this can produce a great deal of confusing data overlay.  The user should, therefore, be able to  pick and choose among the various sets - showing all, or none, or some combination.  One wants to be able to see what Pleiades has covered as opposed to what Vici has covered, for example.  The M.A.P. Digital Atlas features a pull-down menu which allows the user to select as many/few database layers as desired.

The Lemnos map (detail)
Layer Menu visible along with 'spotter' map

In sum, then, the Digital Atlas from the Mycenaean Atlas Project adheres to the following design features:

1. Supports visualization for the following DBs: DARE, deGraauw's Harbors Project, Mycenaean Atlas Project (with features), Pleiades, Topostext, Trismegistos, VICI
2. Displays these databases in a frame that is 0.18° 'square'.
3. Differential selection among the seven data sets
4. Persistent zoom level (user-controlled zoom) (The user is never catapulted into outer space against his/her will)
5. User-controlled redraw of the frame by clicking anywhere on the map
6. Links from each DB icon to the relevant details page (Pleiades, Topostext etc., even deGraauw's Harbors).
7. User-selectable map sheet backgrounds

The result is a quick and easy way to examine coverage for a place (e.g. Siteia on Crete) among the several databases.

I have said that each icon has links to a site details page.  Pleiades icon to Pleiades site, Topostext icon to Topostext site, etc.  The only exception is Dr. deGraauw's Harbors project.  There are no detail pages on his site for individual harbors and so I created a harbor details page for him.  Those pages faithfully reflect HIS data.  Here's an example:

Sample detail page for Arthur deGraauw's Harbor data.
This is Neftina on Lemnos

Looking at this I see that this page should have a 'spotter' map like the Digital Atlas.  Always something more to do.

Databases aren't just created for random and unstatable purposes.  They are created for reasons.  These reasons take their form in the software that is written to execute over them.  One thing that is absolutely essential is careful thinking about the user interface and visualization.  With awkward or non-existent visualization tools the database is incapable of effectively displaying itself.