New Ceramic Horizons search page
The Mycenaean Atlas has a new way to search for date ranges if that's all you want to do. Right now you can do this from the Control Page drop-down menu for 'Ceramic Horizon'. I thought that it would be handy to be able to search for time periods by thumbnail, the same way that you can search by region from the thumbnail maps. So I created such a whole page search just for ceramic horizons. To the Control Page thumbnail box I added a new thumbnail called 'CHRON'.
When you click on that thumbnail you'll get the new Chrono search page:
It should be easy to understand this page. The abbreviations for the various ceramic horizons are standard English abbreviations. When you click on one the Atlas will return a map page with just the sites on it for that ceramic horizon. At this point you can generate reports for that ceramic horizon if that's what you want to do.
The page does not cover all date ranges (ceramic horizons). For the full set you have to go to the drop-down. There ahould be enough choices on the new ceramic horizon page to make it very useful.
This page does not yet include a number of useful ceramic horizons, specifically 'Cypriot' but I'm going to work on adding those.
Years AD
I've been experimenting with the idea of bringing coverage in the Atlas forward in time from the Bronze Age. The island of Naxos is a convenient place to start as it is self-contained. The first of these sites to be added was Irokastro (C7405) which was a stronghold in the SE part of the island.
The page for C7405 looks like this:
Adding this site caused breakage to the Atlas because C7405's dates of use span the year 1 AD and the database isn't designed for years in the Christian era. What to do? I've defined the R(oman) period as 753 BC to 395 AD.
The old time_span DB table has two columns for year ranges: post and ante. If I just stored R(oman) as post:753 and ante:395 the software would interpret this as R ranging from 753 BC to 395 BC. Not good.
This is a fairly vanilla problem in DB design and development and several solutions are possible. First, as doctors say, do no harm. The least desirable solution is to perturb what's already there. In its restricted range of BC the code already works fine. How will we add in years AD in a non-destructive way?
One thing that could be done is to assign years BC a minus sign: Make them negative with years AD being positive. This kind of solution makes me itch and sounds too clever by half. I don't do any year span calculation in the code but if I did this would be the wrong solution.
Computing a range of years with the years BC negative would be like this:
$R = $Yante + abs($Ypost) - 1;
So 753 BC to 395 AD is 395 - -753 - 1 = 1147;
Making the years AD negative is still icky and amounts to about the same thing. Here computing a range of years is just Ypost - Yante - 1.
So 753 BC to 395 AD is just 753 - -395 - 1 = 1147 (we subtract 1 because there's no year 0).
I still don't like it.
A better solution is to bite the bullet and add a column or two(?) to the DB time_span table which will carry the era information about the era for each year range endpoint. In this way we separate out the absolute year value from the era it belongs to. Having done that we can now rely on the software to put these together in whatever way seems suitable at coding time. What should these extra columns contain? Well we could have two columns of binary values; one column for post and one for ante. false (0) could stand for BC and true for AD. This is the classic computer solution and a lot of people would do this but from my perspective this has a drawback.
For the two year range endpoints there are only three legitimate values: BC & BC, BC & AD, and AD & AD. AD & BC (AD followed by BC) is not a valid value.
Decoupling these two values into two separate columns will not automatically prevent our specifying AD-BC or 1,0. I want to be protected from my own stupidity. I finally decided to implement 1 new field with a set of three allowable values: '00', '01', and '11' where 0 represents 'BC' and 1 represents 'AD'. The DB allows no other values in this field (which I called 'bcad') such as '10'. I defaulted this field for the whole table to '00'. I then set the new R record to '01'.
There remained two places in the SW where changes had to be made:
a) where I print out the year ranges in the place key report page and
b) where I pop-up the year ranges on the Chron report page.
I had to change the query to retrieve the new bcad field for each range and write separate code for each of the new three cases to add on the correct 'BC' or 'AD' suffix before printing out the year range: In PHP pseufo-code it looks like this:
switch ($bcad)
{
Case '00' : {$postname = $postname."BC"; $antename = $antename. " BC"; break;}
case '01' : {$postname = $postname. "BC"; $antename = $antename." AD" ; break;}
case '11' : {$postname = $postname. "AD"; $antename = $antename." AD" ; break;}
default : {break;}
}
or ( more cryptic)
$postname = $postname. " BC"; $antename = $antename. " BC";
switch ($bcad)
{
case '01' : { $antename = $antename." AD" ; break;}
case '11' : {$postname = $postname. " AD"; $antename = $antename. " AD"; break;}
default : {break;}
}
The first is what I actually did. Another solution consists of treating the $bcad values as indexes into an array of suffixes:
$baArray = array( "BC", "AD");
The code is then just:
$postname = $postname." ".$baArray[$bcad[0]];
$antename = $antename." ".$baArray[$bcad[1]];
O.k. you get the idea. So on the place key report page you now will see 'BC' for years BC where you never did before and when you look at C7405 you'll see "753 BC - 395 AD" shown correctly:
This also goes for the tooltips on the chronology page. I hope that's the last correction I have to make to support dates 'AD'.
No comments:
Post a Comment