Add MoEML Locations to the Agas Map Martin Holmes Author Martin Holmes Conceptor Martin Holmes Encoder Joey Takeda Copy Editor Data Manager Tye Landels Junior Programmer Joey Takeda Programmer Martin Holmes Associate Project Director Kim McLean-Fiander Project Director Janelle Jenstad The Map of Early Modern Londonhttp://mapoflondon.uvic.ca/includes.xmlVictoria, BC, Canada
Department of English P.O.Box 3070 STNC CSC University of Victoria Victoria, BC Canada V8W 3W1
2016University of Victoria978-1-55058-519-3

Copyright held by The Map of Early Modern London on behalf of the contributors.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Further details of licences are available from our Licences page. For more information, contact the project director, Janelle Jenstad, for specific information on the availability and licensing of content found in files on this site.

 Provider: University of Victoria Database: The Map of Early Modern London Content: text/plain; charset="utf-8" TY - ELEC A1 - Holmes, Martin ED - Jenstad, Janelle T1 - Add MoEML Locations to the Agas Map T2 - The Map of Early Modern London ET - 7.0 PY - 2022 DA - 2022/05/05 CY - Victoria PB - University of Victoria LA - English UR - https://mapoflondon.uvic.ca/edition/7.0/agas_locations.htm UR - https://mapoflondon.uvic.ca/edition/7.0/xml/standalone/agas_locations.xml ER - Holmes, Martin D. Add MoEML Locations to the Agas Map. The Map of Early Modern London, Edition 7.0, edited by Janelle Jenstad, U of Victoria, 05 May 2022, mapoflondon.uvic.ca/edition/7.0/agas_locations.htm. Holmes, Martin D. Add MoEML Locations to the Agas Map. The Map of Early Modern London, Edition 7.0. Ed. Janelle Jenstad. Victoria: University of Victoria. Accessed May 05, 2022. mapoflondon.uvic.ca/edition/7.0/agas_locations.htm. Holmes, M. D. 2022. Add MoEML Locations to the Agas Map. In J. Jenstad (Ed), The Map of Early Modern London (Edition 7.0). Victoria: University of Victoria. Retrieved from https://mapoflondon.uvic.ca/editions/7.0/agas_locations.htm. Born digital. St. Mary Woolchurch Information is not yet available. (STMA37.xml) Silver Street

Silver Street was a small but historically significant street that ran east-west, emerging out of Noble Street in the west and merging into Addle Street in the east. Monkwell Street (labelled Muggle St. on the Agas map) lay to the north of Silver Street and seems to have marked its westernmost point, and Little Wood Street, also to the north, marked its easternmost point. Silver Street ran through Cripplegate Ward and Farringdon Within Ward. It is labelled as Syluer Str. on the Agas map and is drawn correctly. Perhaps the most noteworthy historical fact about Silver Street is that it was the location of one of the houses in which William Shakespeare dwelled during his time in London.

(SILV1.xml)

The Julian calendar, in use in the British Empire until September 1752. This calendar is used for dates where the date of the beginning of the year is ambigious.

The Julian calendar with the calendar year regularized to beginning on 1 January.

The Julian calendar with the calendar year beginning on 25 March. This was the calendar used in the British Empire until September 1752.

The Gregorian calendar, used in the British Empire from September 1752. Sometimes referred to as New Style (NS). Years run from January 1 through December 31.

The Anno Mundi (year of the world) calendar is based on the supposed date of the creation of the world, which is calculated from Biblical sources. At least two different creation dates are in common use. See Anno Mundi (Wikipedia).

Regnal dates are given as the number of years into the reign of a particular monarch. Our practice is to tag such dates with @calendar="regnal", and provide an equivalent date using a more systematic calendar (usually Julian) in a custom dating attribute.

Most MoEML documents, or significant fragments with @xml:id attributes, can be addressed using the mol: prefix and accessed through the web application with their id + .xml.

The molagas prefix points to the shape representation of a location on MoEML’s OpenLayers3-based rendering of the Agas Map.

Links to page-images in the Chadwyck-Healey Early English Books Online (EEBO) repository. Note that this is a subscription service, and may not be accessible to those accessing it from locations outside member institutions.

Links to page-images in the English Broadside Ballad Archive (EBBA).

The mdt (MoEML Document Type) prefix used on <catRef>/@target points to a central taxonomy in the includes file.

The mdtlist (MoEML Document Type listing) prefix used in linking attributes points to a listings page constructed from a category in the central MDT taxonomy in the includes file. There are two variants, one with the plain @xml:id of the category, meaning all documents in the specified category, and one with the suffix _subcategories, meaning all subcategories of the category.

The molgls (MoEML gloss) prefix used on <term>/@corresp points to a a glossary entry in the GLOSS1.xml file.

This molvariant prefix is used on <ref>/@target attributes during automated generation of gazetteer index files. It points to an element in the generated variant spellings listing file which lists all documents which contain a particular spelling variant for a location.

This molajax prefix is used on <ref>/@target attributes during the static build process, to specify links which point to MoEML resources which should not be loaded into the source page during standalone processing; instead, these should be turned into links to the XML source documents, and at HTML page load time, these should be turned into AJAX calls. This is to handle the scenario in which a page such as an A-Z index of the whole site would end up containing virtually the whole site inside itself.

The molstow prefix is used on @facs attributes to link to the HCMC verison of the Stow facsimiles. Usually the first group is the year (1633) and then last is the image number (0001).

The molshows prefix is used on @facs attributes to link to the copies of page-images from mayoral shows stored in the london account on the HCMC server. The first group is the year (1633), the second is the source repository, and then last is the image file name.

The sb prefix is used on <ref>/@target attributes to link to Stow’s Books URLs at UToronto.

Our editorial and encoding practices are documented in detail in the Praxis section of our website.

Author A person or organization chiefly responsible for the intellectual or artistic content of a work, usually printed text. This term may also be used when more than one person or body bears such responsibility. MoEML uses the term author to designate a contributor who is wholly or partly responsible for the original content of either a born-digital document, such as an encyclopedia entry, or a primary source document, such as a MoEML Library text. Conceptor A person or organization responsible for the original idea on which a work is based, this includes the scientific author of an audio-visual item and the conceptor of an advertisement. MoEML uses the term conceptor to designate any person or organization responsible for envisioning the design, structure, or general function of a page or project within MoEML. We use this term to give credit to early contributors whose work has been substantially revised and replaced, or contributors who provided input or inspiration on some aspect of the design, structure, and/or implementation of a project within MoEML. Acceptable names for this role are conceptor or originator. Data manager A person or organization responsible for managing databases or other data sources. MoEML uses the term data manager to designate contributors who maintain and manage our databases. They add and update the data sent to us by external contributors or found by MoEML team members. They also monitor journals and sources regularly to ensure that our databases are current. Markup editor A person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc. MoEML uses the code mrk both for the primary encoder(s) and for the person who edits the encoding. MoEML’s normal workflow includes a step whereby encoders check each other’s work. We use the term encoder to designate the principal encoder, and markup editor to designate the person who checks the encoding. Project director A person or organization with primary responsibility for all essential aspects of a project, or that manages a very large project that demands senior level responsibility, or that has overall responsibility for managing projects, or provides overall direction to a project manager. MoEML’s Project Director directs the intellectual and scholarly aspects of the project, consults with the Advisory and Editorial Boards, and ensures the ongoing funding of the project. Programmer A person or organization responsible for the creation and/or maintenance of computer program design documents, source code, and machine-executable digital files and supporting documentation. MoEML uses the term programmer to designate a person or organization responsible for the creation and/or maintenance of computer program design documents, source code, and machine-executable digital files and supporting documentation. Research team head A person who directed or managed a research project. MoEML uses the terms research term head and assistant project manager interchangeably. Copy editor MoEML uses the term copy editor to designate the person who brings the document into conformity with MoEML stylistic and citational practice. Acceptable names for this role are copy editor, principal copy editor, secondary copy editor, or copy editor of a particular section of text. Revised wording and adding a few more examples. Standardized <respStmt>s for JENS1, MCFI1, and HOLM3 and added TAKE1 as Junior Programmer. Added section on location diagnostics. Created this document. Add MoEML Locations to the Agas Map
Introduction to the Agas Map

Our implementation of the Agas Map is based on the OpenLayers 4.6 library and presents the map as a tiled image at a range of different resolutions.The OpenLayers implementation of the Agas map was first created in 2014, replacing the old "star map". Locations are plotted on the map in three forms: Polygons: closed shapes MultiLineStrings: lines with multiple points Points: single points Each of these forms serve a different purpose, depending on the type of location you are encoding; each of these shapes and their purposes are discussed in more detail below.

The information used to display locations is provided to the map through two JSON files: categories.json: provides information about all the location categories in our document type taxonomy agasLocations.json: provides information about the locations, including each location’s document type(s) and the list of referring documents These files are created during the static build process and are generated from the metadata contained within the TEI location files.

The Agas Map interface can also be used to create new shapes, lines, and points for locations, which can be either associated with a location file or can be used more generally to interact and draw on the map. This document will explain how to do both.

Creating a Polygon

To create a polygon shape, first zoom right into the map so that the shape you want to outline is taking up most of the window. In this example, we’re going to outline St. Mary Woolchurch:

Then choose Polygon from the Draw a shape drop-down list:

A red box appears at the bottom of the screen. We’ll see the purpose of this later. You’ll notice that the cursor turns to a blue point. Now you can click on one of the corners of the object to add a point. Move your mouse to the next corner, and click there to add the next point:

Keep adding points until you have outlined the whole object:

Click back on the original starting point to complete the shape.

Two things will happen: the shape will change colour to show that is is complete, and in the red box, a block of XML code will appear. This is the TEI <surface> element that you need to add into the location file for the place. In Oxygen, open up the appropriate location file (in this case, STMA37.xml), and locate the <facsimile> element. Note that if you are creating a new document or adding a location to an existing document that is not already on the Agas map, it may not contain a <facsimile> element. In this case, simply add a <facsimile> element between the <teiHeader> element and the <text> element. However, you may find that there is already a <surface> element from the old Agas map images. Leave this alone, but add the new element immediately after it:

You’ll notice that this is invalid when we first paste it in, because the location id is wrong. Change the first part of the @xml:id attribute on the <zone> element to match the location’s @xml:id:

What if your shape is not perfect first time around? You can easily edit it after it’s completed. Put your mouse over one of the existing points to click and move it; put your mouse over one of the lines to add a new point. Every time you make a change to the shape, the XML in the red box will update itself automatically.

If you need to delete one of the nodes in your shape, press the Shift key and click on it.

It is best to have the map zoomed to its maximum size when you create the shape, because you’ll be more accurate. If you’re outlining a large area, this may mean that the shape does not completely fit on the screen. Don’t worry about this; even while you’re in the middle of drawing the shape, you can still click and hold (hold down the mouse button), drag the map around, and release without adding a new point in your shape. It’s only when you click and release immediately that a new point is added.

Creating MultiLineStrings

While we usually draw buildings as shapes, streets are drawn as MultiLineStrings (in other words, a series of connected lines). The process is exactly the same as for Polygons, except that to finish the shape, you just double-click on the last point. When tracing a street, start the line in the middle of the junction where the street starts, and end in the middle of the junction where it ends. Keep the line in the middle of the street.

Creating Points

Some locations cannot be precisely outlined, perhaps because although we know approximately where they were, they do not actually appear on the map. You can use a Point for this.

Creating a Point is the simplest process of all: select Point from the drop-down list, then click on the location.

Creating a MultiPolygon

There will be some circumstances in which you need to associate multiple polygons with a single location. For example, imagine that a guild owns two buildings which are not contiguous; in one sense, they are the same "location", but they are clearly two separate shapes on the map.

This can be done by creating multiple <zone> elements inside the <surface> element for the map. Here is an example:

<surface> <graphic url="agas_full.jpg"></graphic> <zone xml:id="STBO4_1_agas" points="18913,6593 18919,6692 18983,6687 18994,6686 18995,6621 18995,6593 18913,6593"></zone> <zone xml:id="STBO4_2_agas" points="18994,6681 18998,6708 19007,6721 19032,6721 19033,6682 18994,6681"></zone> </surface>

Note that you can only combine polygons in this way; you cannot create sets of MultiLineStrings or Points.

Editing an Existing Location

Sometimes you will have to make changes to a location which has been entered by someone else, and is already showing on the map. To do this, first zoom into the location and select it:

Then choose Clone selected feature from the drop-down list. The shape will turn into a red outline which you can edit as explained above. As you edit, the XML in the red box will change, and when you’re happy with the result, you can copy/paste the XML into the location file, replacing the original <surface> element. Ensure that you update the <respStmt> in the <teiHeader>, giving yourself credit as the Geographic Information Specialist. See Create a MoEML <teiHeader> for details on how to encode a <respStmt>.

Bookmarking Shapes

Just as you can bookmark locations or sets of locations, you can also bookmark a shape you have created. This can be handy if you’re emailing someone and would like to refer to a specific location on the map, if you would like to suggest a particular location for inclusion, or if you would like to share a custom shape that does not belong in the database.See, for instance, the footnote in Silver Street, which shows the house that Shakespeare may have lived in during his stay on Silver Street. To do this, simply create the shape as you normally would, and then when you’ve finished, press the Bookmark button. A long, inscrutable URL will be created and a popup alert will tell you that it is about to redirect you to the bookmarked URL.

Press OK and the page will redirect you to the bookmark URL. Once the page has reloaded, you can copy and paste the entire URL in the address bar. If you plug this URL into a browser, the map will recreate the shape and zoom to it, also showing the TEI <surface> element at the bottom of the screen.

Uncertainty and Imprecision

It is often the case that a feature may not appear on the Agas Map, although we know more or less where it should be if it did appear; or that we know more or less, but not exactly, where a feature is. In order to be truthful, we need to record the level of certainty and precision associated with a location. The <certainty> and <precision> elements enable us to do that. We use <certainty> to quantify our confidence that the location assigned is the correct location; and we use <precision> to quantify how "accurate" our point or outline is assumed to be. This is perhaps best explained through examples.

<zone xml:id="ROSE66_agas" points="14676,9076 14910,9081 14918,9405 14684,9401 14676,9076"> <precision precision="low" resp="mol:HOLM3"></precision> <certainty cert="medium" resp="mol:HOLM3" locus="value"></certainty> </zone>

The <precision> and <certainty> elements appear as children of the <zone> element to which they refer. In the absence of these elements, certainty and precision are assumed to be high. The @precision and @cert attributes record the level of certainty or precision in each case; allowed values are: "high": default value "medium" "low" "unknown"Note that you will almost always encode certainty and precision using "high", "medium", or "low"; there are few instances where "unknown" is useful. It is always good practice to provide @resp (using the standard "mol" prefix and your @xml:id) to identify someone (usually yourself) as the person responsible for introducing or encoding this expression of doubt. Where appropriate, you might also provide @source to point to one or more sources of evidence; the source can either be an internal bibliographic item (and thus pointed to using the standard mol prefix and the @xml:id of the bibliographic item) or an external URI.

The method outlined above is relatively crude; it allows us to say that the feature may not in fact be at the location specified (<certainty>) and/or that the coordinates provided may be somewhat inaccurate (<precision>). You may wish to add a <note> inside the <zone> to clarify the situation for a human reader, and it is also possible to provide much more specificity in the encoding if we determine that this is desirable. If the location consists of more than one zone, add a <note> inside <surface>.

Note also that using this method, it is possible to encode multiple possible locations for a single feature, each with its own level of certainty; you might believe that it is most likely in one place (@cert="medium") but that it could possibly be somewhere else (@cert="low"), and each location can have its own <zone> element containing a <certainty> element, with @source pointing to the evidence available.

<facsimile> <surface> <note type="editorial" resp="mol:JENS1">The southern half of the alley, if it existed, would have been destroyed for the building of the Royal Exchange. The northern half ran east of St. Christopher le Stocks. Neither half is visible on the 1633 version of the Agas Map.</note> <graphic url="agas_full.jpg"></graphic> <zone cert="medium" xml:id="CHRI4_1_agas" ulx="16783" uly="4684" lrx="16883" lry="4817"></zone> <zone cert="low" xml:id="CHRI4_2_agas" ulx="16687" uly="4562" lrx="16749" lry="4656"></zone> </surface> </facsimile>
Participants Joey Takeda Joey Takeda JT

Programmer, 2018-present. Junior Programmer, 2015-2017. Research Assistant, 2014-2017. Joey Takeda was a graduate student at the University of British Columbia in the Department of English (Science and Technology research stream). He completed his BA honours in English (with a minor in Women’s Studies) at the University of Victoria in 2016. His primary research interests included diasporic and indigenous Canadian and American literature, critical theory, cultural studies, and the digital humanities.

 Tye Landels-Gruenewald Tye Landels-Gruenewald TLG

Data Manager, 2015-2016. Research Assistant, 2013-2015. Tye completed his undergraduate honours degree in English at the University of Victoria in 2015.

 Kim McLean-Fiander Kim McLean-Fiander KMF

Director of Pedagogy and Outreach, 2015–2020. Associate Project Director, 2015. Assistant Project Director, 2013-2014. MoEML Research Fellow, 2013. Kim McLean-Fiander comes to The Map of Early Modern London from the Cultures of Knowledge digital humanities project at the University of Oxford, where she was the editor of Early Modern Letters Online, an open-access union catalogue and editorial interface for correspondence from the sixteenth to eighteenth centuries. She is currently Co-Director of a sister project to EMLO called Women’s Early Modern Letters Online (WEMLO). In the past, she held an internship with the curator of manuscripts at the Folger Shakespeare Library, completed a doctorate at Oxford on paratext and early modern women writers, and worked a number of years for the Bodleian Libraries and as a freelance editor. She has a passion for rare books and manuscripts as social and material artifacts, and is interested in the development of digital resources that will improve access to these materials while ensuring their ongoing preservation and conservation. An avid traveler, Kim has always loved both London and maps, and so is particularly delighted to be able to bring her early modern scholarly expertise to bear on the MoEML project.

 Janelle Jenstad Janelle Jenstad JJ

Janelle Jenstad is Associate Professor of English at the University of Victoria, Director of The Map of Early Modern London, and PI of Linked Early Modern Drama Online. She has taught at Queen’s University, the Summer Academy at the Stratford Festival, the University of Windsor, and the University of Victoria. With Jennifer Roberts-Smith and Mark Kaethler, she co-edited Shakespeare’s Language in Digital Media (Routledge). She has prepared a documentary edition of John Stow’s A Survey of London (1598 text) for MoEML and is currently editing The Merchant of Venice (with Stephen Wittek) and Heywood’s 2 If You Know Not Me You Know Nobody for DRE. Her articles have appeared in Digital Humanities Quarterly, Renaissance and Reformation,Journal of Medieval and Early Modern Studies, Early Modern Literary Studies, Elizabethan Theatre, Shakespeare Bulletin: A Journal of Performance Criticism, and The Silver Society Journal. Her book chapters have appeared (or will appear) in Institutional Culture in Early Modern Society (Brill, 2004), Shakespeare, Language and the Stage, The Fifth Wall: Approaches to Shakespeare from Criticism, Performance and Theatre Studies (Arden/Thomson Learning, 2005), Approaches to Teaching Othello (Modern Language Association, 2005), Performing Maternity in Early Modern England (Ashgate, 2007), New Directions in the Geohumanities: Art, Text, and History at the Edge of Place (Routledge, 2011), Early Modern Studies and the Digital Turn (Iter, 2016), Teaching Early Modern English Literature from the Archives (MLA, 2015), Placing Names: Enriching and Integrating Gazetteers (Indiana, 2016), Making Things and Drawing Boundaries (Minnesota, 2017), and Rethinking Shakespeare’s Source Study: Audiences, Authors, and Digital Technologies (Routledge, 2018).

 Martin D. Holmes Martin D. Holmes MDH

Programmer at the University of Victoria Humanities Computing and Media Centre (HCMC). Martin ported the MOL project from its original PHP incarnation to a pure eXist database implementation in the fall of 2011. Since then, he has been lead programmer on the project and has also been responsible for maintaining the project schemas. He was a co-applicant on MoEML’s 2012 SSHRC Insight Grant.