Dispatches from the TEI's GIS Working Group


https://tei-gis-wg.github.io/docs/presentations/TEI2025/index.html

Joey Takeda, Martin Holmes

TEI Annual Meeting, Kraków, September 18, 2025




🤷

The overall objective of the GIS Working Group is to provide standards-informed mechanisms that are at least interchangeable, if not interoperable, for encoding geographic information in TEI that are capable of unambiguous interpretation and transformation to and from standard GIS file formats.

Current State of Things

  • geo: allows for lat lon
  • geoDecl: documents the notation and the datum used for geographic coordinates expressed as content of the geo element

Assumptions

  • People like maps and want to encode geographic coordinates
  • People want to be able to express this in their TEI files
  • People have done so (kind of)
  • Places are not just points
  • We are not all geographers
  • But geographers exist, and have thought a lot about this

How do people encode geographic information in TEI?

  • We ran a survey asking about it
  • We looked through GitHub (searching for "<geo")
  • We asked ChatGPT
  • It's all over the map
  • By and large, lat lon (with space separation); there's evidence from code for processing that this is also what people expect
  • Lots of people doing maps, but they don't seem to use TEI / if they use TEI, they reserve TEI for the texts, and use something else for the maps



        
            
        
    

Our (Modest) Proposal

  • Update geoDecl
  • Create (or add) scheme to geo and geoDecl to allow for various kinds of encoding (e.g. embedding GML, embedding GeoJSON etc)

geoDecl

  • Defines the standard used and any additional definitions to remove ambiguity as to the use of the standard (or if there are multiple different definitions of CRSs)

scheme

Denotes the scheme/standard being used

Optional on geo; mandatory on geoDecl

        
            
        
    

scheme

  • Overall, the principle for all established schemes is that the content of the geo should represent a valid object as defined by that scheme.
  • If the content of geo is in an XML language, it must have a single root element; fragments are not allowed.
        
            
        
    
  • This is likely the right approach – something fairly lightweight but expressive and clear. However, we see this as a bit of a first step or entry point into a larger set of questions regarding the way that we describe 2D spaces in TEI
http://lotrproject.com/map/#zoom=3&lat=-1587&lon=1500&layers=B

Current questions:

  • Is it right to keep surface/zones completely separate from geo (i.e. allowing them to develop in parallel)? Should we be more ambitious in our thinking with 2D coordinate spaces and how we describe them in TEI?
  • In other words, should geo still be "geography" or should it be "geometry"?

Thanks! Questions?

  • Official Charge: https://tei-c.org/activities/workgroups/gis-charge/
  • GitHub: https://github.com/TEI-GIS-WG/

Appendix

  • Map screenshots taken using Vertexer (https://hcmc.uvic.ca/vertexer)
  • Code fragments taken from the Epidoc (https://epidoc.stoa.org/)
  • Image of Middle Earth taken from the the Lord of the Rings Project (http://lotrproject.com/map/#zoom=3&lat=-1587&lon=1500&layers=BTTTTT)