What About ... ?
Most of us probably mumble "Type What You See" in our sleep, but there are still times we wonder if THIS
is an exception. Usually the answer is NO
. If you are in doubt, don't hesitate to ask. Also, the analysts appreciate it if you warn them about these odd cases. See the link at the end of this post
UPDATE: Initially we requested transcribers to put only spaces between degrees and minutes and between minutes and seconds. Philip has revised his software; now 42 33 02, 42.33.02, 42d33m02s and even 43$33&02 are all treated identically. So, TWYS.
Philip is aware that some logs express latitude and longitude as degrees and minutes with a decimal point to indicate fractions of minutes. For example, 63 48.5N
Observed vs. Dead Reckoning:
... guess enthusiastically. If some people guess DR and some guess obs, I know that we don't know.
The degree and minute symbols printed in the log can look almost like decimal points. Although it will no longer cause a problem, please try to use spaces unless the log keeper has used decimal points or other characters.
If the D.R. readings have N/S and E/W specified and the Observed readings don't, do not add the N/S and E/W to the Observed readings even if it is obvious that they apply. The same is true if the Observed readings have N/S and E/W specified and the D.R. readings don't.
If the letter for the latitude or longitude is clearly incorrect, even if the correct letter is known, it should be transcribed as written.
If the letter is before the number (e.g., N 37 12), it should be transcribed that way. NOTE: At the moment you need to click OK and then Close, and it will not be displayed on the map or below POSITION.
If the position is a latitude and longitude determined by bearings on a place, enter it as Observed.Observed | Latitude = N 76 02 | Longitude = W 68 49
If the position is a place with a bearing (and distance), use Place Name. Place Name = Marrowstone Point NWxN - dist 3'.5
If a place is sighted, you can put the whole comment in Place Name.
For example, if the entry is "Sighted Farallon Lighthouse brg S43E dist 5m", put Sighted Farallon Lighthouse brg S43E dist 5m
into Place Name.
What we really want is the best noon position - any other positions are just gravy.
So I think we should tell people that: please enter at least one position - in order of desirability:
Other time obs
Other time DR
Place or landmark name
At least one of these if possible from every page. (We want both lat and lon, best of each) If they want to enter more that's useful, but not vital.
I don't think we can start labeling them - though we might want to add that to the UI in the future.
The CS will have to use their own judgement of what the best noon ob is in difficult cases like the corrected 8a.m. observed position you show. Is this better than a noon DR? I suspect so, but don't know. The CS should feel free to guess. Is the observed lat with no time better than a known noon dr lat?
I don't know this either, in such tricky situations, guess.
Missing Pressure Digits
In a case like the following:
the integer part should not be copied from above nor should a ditto be added.
I just started the Manning and I see that the log keeper doesn't enter the first 2 digits of the barometer reading unless it changes. This is obviously an implied ditto. Does TWYS apply in this case or should I make a lot of extra work for the editors by not entering them?
This is, as so often, a tricky point, but please stick to strict TWYS - just put in exactly what is in the log.
The logkeepers leave out the '30' from '30.12' because it is not interesting - it changes so slowly that we can guess what it is, and that means that my software can guess it too (I have not tried this yet with this data, but I'm confident). So you don't need to enter it, we can work it out in post processing.
So - RECOMMENDED: Just put in what the logkeeper put - don't add missing digits. As far as possible, stick to strict TWYS. If the entries are strange or doubtful, please do mention it in a forum thread - just like this one.
But don't bother correcting previous entries - it's useful to have a few human assessed entries to check the computer, but we'd rather not have them in general.
No Decimal Point in Pressure Reading
Normally the pressure reading has a decimal point between the integer and decimal parts. However, you may occasionally simply see four digits.
For example, 29.63
may also be written as 2963
Philip has asked us to enter it as it is written. He says that his software treats all those variants in the same way.
Dash or Space in Pressure Reading
Normally the pressure reading has a decimal point between the integer and decimal parts. However, you may occasionally see a dash or a space between the integer and decimal parts.
For example, 29.63
may also be written as 29-63
, 29 63
, or even as 29:63
Philip has asked us to enter it as it is written. He says that his software treats all those variants in the same way.
"Extra" Weather Entries
Occasionally there will be a reading inserted between two of the hourly readings. In this example (http://oldweather.s3.amazonaws.com/ow3/final/USCS%20Patterson/Book%201/IMG_4785_0.jpg
), there is a ditto (") in the Wind Direction column between 9 and 10 am. Philip has asked us to include these readings. As shown below, it can be entered with 9.30 for the Hour.
There were some pages (e.g., http://oldweather.s3.amazonaws.com/ow3/final/USS%20Jeannette/vol001of004/vol001_012_0.jpg
) with a weather reading on the "PM" line. Normally this line is blank. Philip says he is "utterly baffled" at this, but he asks us to transcribe it and to put PM for the Hour (and to be extra careful to fill in the Hour for all weather entries). If the 1 pm line contains dittos, please enter the actual values when transcribing to avoid possible loss of data. In this example, at 1 pm you would enter SSW
for the Wind Dir instead of "
for the Weather Code instead of "
When you have two readings, such as wind direction or pressure, one right after the other, it can be difficult to determine what the log keeper intended. Sometimes other information in the log will help. In most cases, it will simply indicate that the value has changed suddenly, and the readings should be placed one below the other according to their times. In the example below, two different instruments have been used to measure data at the same time. Since the readings were taken at the same time, Philip asks that the readings be put on the same line and that the analysts be warned. For example, if there are two pressure readings, create one 'normal' record with all the data and the first pressure and then create a second record with just the hour and the second pressure. Don't hesitate to ask if you are not sure!
At some point on "Victorian" two barometer readings began to appear at mid-day, one above the other and written in red.
The readings were similar and sometimes identical.
Eventually I came across the "Instruments" page at the start of a log book which indicated that there were two barometers, the mercury being used for every reading and the aneroid readings being shown in red. No explanation was offered, unfortunately in 1915 this practice had not been introduced so I can't post a link but if anyone else if transcribing "Victorian" they might find the relevant pages. ...
Sorry for the slow official response, but I was not at all sure what the best action here is. However, on reflection, I think that the ship is actually making two observations at the same time, and we should enter them as two separate observations.
So please input the whole observation as normal but using just the first of the two barometer values, and then click again in almost the same place to create another weather observation, and put the second barometer height in that. So, one normal observation (wind, temperature etc. + first barometer reading), and another with only the second barometer reading in it (you don't need to put the wind etc. in again).
As always, thanks for letting us know. Now we're warned, we should be able to do some interesting comparison of the two barometers. I hope the ship meets a storm or two (so we see a big pressure change) while making the paired observations.
USC&GSS Yukon (I) records aneroid and mercurial barometer readings in some of its logs. Please see: Yukon -- Reference: Transcription Example and Log Description
is NOT a double entry. The log keeper simply used the whole box rather than writing all four letters on one line. The weather code would be transcribed as ocrq.
Multiple Cloud Codes
Usually there are only one or two cloud codes on one line, but sometimes there are several cloud codes on multiple lines for one entry. Because there is no way to insert a line break in our transcriptions, we use a space to indicate a line break. These entries can be challenging. Just make your best guess. TWYS may save you a lot of agonizing.
For example, the 6pm entry on https://oldweather.s3.amazonaws.com/ow3/final/USS%20Jeannette/vol001of004/vol001_089_0.jpg
is written as
With TWYS this would be transcribed as: "cir. cir strat strat." (or "Cir. Cir Strat Strat.").
Based on the drop-down list, it could be transcribed as: "cir cir str str" (or "Cir Cir Str Str").
Given that both "cir" and "strat" appear individually and that "cir strat" is on a line by itself, it is reasonable to assume that "cir strat" refers to cirrostratus clouds. So, this could also be transcribed as "cir cir-str str". This is in the gray area between guessing enthusiastically (which is encouraged) and adding (which is not permitted), so this option should be used with caution.
In general, unless there is a hyphen, you should assume that the cloud codes are separate:
should both be transcribed as either "cum nimb" (TWYS) or "cum nim" (according to the list).
Remember, our job is to transcribe what is written as accurately as possible. Interpreting it is the science team's job.
For further discussion, see Cloud Code Questions
As noted above (General Comments
) "Cir Str" and "cir str" are equivalent, so if you are typing codes from the list you can use lowercase.
Overwritten Cloud Code http://oldweather.s3.amazonaws.com/ow3/final/USS%20Jeannette/vol001of004/vol001_036_0.jpg
Usually when something, like temperature or pressure, is overwritten it is a correction and you can determine the correct value. However, in some cases, like this one, it is very difficult to decide which value is correct. Philip suggests that the first entry should be transcribed as Nimb -
and the other three should be transcribed as " -
"My log starts at 1 PM !!!" / Nautical Day
This is very rare, but it does happen in some old logs.
Here is an example: http://oldweather.s3.amazonaws.com/ow3/final/USCS%20Yukon/Book%202/IMG_4130_1.jpg
According to Philip:
The nautical day started at noon on the previous (conventional) day and ran to noon on the next day - so Nautical 21st Oct ran from Noon on the (civil) 20th to Noon on the civil 21st. Nautical days are standard in older ships logbooks (at least from the UK). The Admiralty abolished it in 1805 so I'm surprised to see it in these logs. It was usual to switch back to the civil day when in port, but the older logbooks I've looked at so far don't have data while in port so I've never before seen a logbook where they are actually doing the transition.
We should be able to deal with this in post processing, provided that we know it's happening. ...
When entering Weather Records for nautical days (1PM to noon), please include AM or PM with the hour and use midnight (or mid) and meridian (or merid or noon) for 12 o'clock. If you are not sure whether it is AM or PM, just enter the hour. You do not need to include AM/PM with the normal 1AM to midnight log format. Events should be transcribed exactly as they are written.
Note: 1AM, 1am, 1 AM, and 1 am are all treated the same.
Missing or Incorrect Day, Month, or Year
If all or part of the date is incorrect or missing, please do not fix it.
The only time this rule [i.e., do not add or correct] makes me squirm a little is when the date is obviously wrong - often there are a few days in January when the logkeeper continues to write the wrong year - but it happens at other times, too; most often the wrong year or month.
Ever since the "Don't add" message was posted, I've been scrupulously entering these erroneous dates, even though it seems it will be difficult to sort out later. I confess that in my first few days, I added an "event/other" that said "wrong date" but I haven't done that since October. I swear. ...
From what we've seen so far, the log keepers write in the wrong date about once a year.
Here's the blob plot for the date information from HMS Goliath (4 months, January-April 1915).
This shows the day (top) month(middle) and year(bottom) for each page - big red blobs show where everybody reading the log agreed on what was written, smaller blobs mark occasions where one or two readers thought it said something different. For Goliath, we had little trouble reading the logs, and everybody agrees that there were two occasions when the day written in the log disagreed with the day we'd expect from the pages for the days before and afterwards - these are errors in the logs: on March 14th the logkeeper wrote 19th, and on April 26th he wrote 25th.
So the occasional date error is to be expected (we can't expect the logkeepers to be perfect), and we'll spot it (and fix it) when processing the results. Thanks for mentioning it though - it helps to be warned, and please keep an eye out for more subtle or comprehensive errors.
If you have questions or comments, or want to notify the analysts about odd cases, please post them in: Type What You See - Questions and Comments
or in the Discussion topic for the ship in question.