Geocoding requirements

[rockivist]

From Jane Stevenson (ArchivesHub) (email, 4/26/13):

Re: geographical coordinates.

From discussions with some folks here, what we're thinking is:

1. We would want to specify the system being used to create co-ordinates. My understanding is that WGS84 is generally the best option, although with some caveats. So, I would imagine that we would want the option to add the source of the coordinates.
2. I think that we'd need the option to add more than one lat/long pair, so that we can specify areas. I'm not sure, but I think that at present this is not valid for place names?

Its not that easy to know how best to proceed, as I simply don't know enough about best practice in these things. I think Humphrey Southall, a geographer who has close links with the archives community in the UK, has talked a bit to Bill about this (is that right Bill?). I know he recommends using WGS84.

[rockivist]

Follow up from Jane (email, 4/26/13):

HI Mike,

Cheers. We (at the Hub) felt that what is most important is to have more than two coordinates, so that an area can, in theory, be specified. But I don't know enough to say more than that!

Humphrey has also given me a name - Raj Singh is Director of Interoperabilty Programmes at Open Geospatial - so may be just the guy to ask, and may be able to provide information in the most helpful way for the EAD revision.

Humphrey emailed me the following (but really I wanted something a bit more straightforward):

The EPSG Geodetic Parameter Registry (www.epsg-registry.org) identifies coordinate systems.

Especially relevant systems are:

"OSGB 1936 / British National Grid": SRID = 27700

“European Terrestrial Reference System 1989” (ETRS89): SRID = 3034

Latitude and longitude/WGS-84: SRID = 4326

More about WGS-84 here:

http://en.wikipedia.org/wiki/World_Geodetic_System

This covers marking up a WGS-84 coordinate as XML:

http://en.wikipedia.org/wiki/Geo_%28microformat%29

An obvious extension would be to use another coordinate system and identify the system via the EPSG registry codes, but cannot find anything quickly on that. The big problem with WGS-84 coordinates is that they define locations on a sphere, i.e. planet Earth, so they cannot be used to define locations on a conventional flat map. All the other coordinate systems "flatten" the earth, and the reason there are so many is that a given "flattening" (i.e. a map projection) will work very well in a particular small area, but as you move away from that area the distortions get marked. Vision of Britain is actually built around ETRS-89, which works better in central Europe than in Wales -- and by the time you get to Australia it has been rotated by 90 degrees, as most people would think about it.

Encoding anything more complex than a point should use GML, an Open Geospatial Consortium standard:

http://www.opengeospatial.org/standards/gml

"The OpenGIS® Geography Markup Language Encoding Standard (GML) The Geography Markup Language (GML) is an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. As with most XML based grammars, there are two parts to the grammar – the schema that describes the document and the instance document that contains the actual data. A GML document is described using a GML Schema. This allows users and developers to describe generic geographic data sets that contain points, lines and polygons. However, the developers of GML envision communities working to define community-specific application schemas [en.wikipedia.org/wiki/GML_Application_Schemas] that are specialized extensions of GML. Using application schemas, users can refer to roads, highways, and bridges instead of points, lines and polygons. If everyone in a community agrees to use the same schemas they can exchange data easily and be sure that a road is still a road when they view it. Clients and servers with interfaces that implement the OpenGIS® Web Feature Service Interface Standard[http://www.opengeospatial.org/standards/wfs] read and write GML data. GML is also an ISO standard (ISO 19136:2007) [www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32554 ]. See also the GML pages on OGC Network:http://www.ogcnetwork.net/gml ."

cheers, Jane.

[rockivist]

From Bill (email, 4/26/13):

Hi all,

This obviously a very complex area and I suspect one where professional archival communities are only beginning to find their feet (I know I am) - so as with much else with in this revision I suggest we dip our toes in and see how it works over the period to the next one. So on Jane's points below:

1. I've consulted the Library's expert (Kimberley Kowal) here and she says that basically Latitude and Longitude are most likely to be WGS-84 based and this is generally fine in terms of the precision necessary for describing archival maps - a different story of course for digital mapping. It's what is used by geonames for example which is where we at the Library suggest cataloguers take co-ordinates for published and archival maps. So I think in EAD adding Latitude and Longitude as attributes to our revised <geogname> will (with Altitude - to align with EAC-CPF) be sufficient for now.
2. Generally (for our purposes) a place will be a single lat/long pair as it is a 'place' rather than an 'area'. The need for area co-ordinates comes when wanting to describe that covered by a map. The co-ordinates here then are part of the description of the object rather than those of a place related to that description. There is a need for both! So here at the Library (as noted at 1 above) we can add a lat/long pair to places in our system and we have recently added an element to capture a co-ordinate statement for the area covered by a map alongside a set of other 'cartographic' elements (Scale, Orientation, Projection etc). When looking at how to represent these in EAD I've used <materialSpec>: so for example:

`

IOR/X/1-4999 Map of Arabia. Compiled from all the most recent authorities, by order of the Court of Directors of the East India Company by John Walker. Published according to the Act of Parliament by J. Walker, Geographer to the Honble [Honorable] East India Company, July 31st 1849. Engraved by J. & C. Walker. 1:1,330,000 E 34°33'36"-E 59°48'36"/N 31°4'12"-N 12°36'0" ` In other words EAD already allows for this without adding further elements. Kimberly is mulling over and I'll get back if her advice changes! Does that make sense? Thoughts? Cheers, Bill

[rockivist]

From @tcatapano (email, 4/26/13):

Jane, Bill, Mike,

I work with biologists who are very concerned with geolocation data and know from that experience that it can be pretty involved (lat/long (verbatim and decimal), altitude/elevation, accuracy, etc...). It would be good to know what geographic applications are envisioned and what the data needs are at the level of the schema and the instance.

I do want to point out that for <geographicNameEntry> at least there is a repeatable part element with which one can do pretty much what one want.

Something like this could be done, for example:

`

-81.1, 32.2, -81.0, 32.3

        <part localType="decimal_latitude">32.28</part>
        <part localType="decimal_longitude"> -81.071</part>
        <part localType="locality">Hardeeville</part>
        <part localType="state">South Carolina</part>

`

One thing we might want to consider is creating a wrapper element for all the geocoding data in a geogNameEntry (and possibly any other geography related element). Something like this:

`

WGS84 -81.1, 32.2, -81.0, 32.3 32.28 -81.071

        <part localType="locality">Hardeeville</part>
        <part localType="state">South Carolina</part>

`

I'd even suggest lifting the lid a bit more off of Pandora's box and allow objectXMLWrap in this context. ;-)

I'll follow up with more soon.

/Terry

[rockivist]

Closing. See #286