Using geographic coordinates from MARC records

Using geographic coordinates from MARC records

This information is from a 2018 feature implementation. Primo code is in GitHub, but stopped working when OSM introduced a CDN: https://github.com/cbaksik/HVD2/blob/7ee515983d32abde6d9f67ee966a979b116d98f8/js/prm-search-result-availability-line-after.js#L181

Coordinates and geometry types

Coordinates are stored in MARC field 034, subfields $d, $e, $f, $g as follows:

  • westernmost longitude

  • easternmost longitude

  • northernmost latitude

  • southernmost latitude

Coordinates may be represented in one of two formats (there are more but we’re focusing on two):

  • Decimal Degrees format (may or may not contain decimal points)

  • HDDDMMSS format (Hemisphere, Degree, Minute, Second)

Also, coordinates may represent one of two “geometry types:”

  1. Points – a single point on a map

    1. IF (westernmost longitude = easternmost longitude) AND (northernmost latitude = southernmost latitude), THEN geometry type is a point

  2. Bounding boxes (“Bbox,” also called “envelopes”) – these represent geographic areas

    1. If coordinates do not meet the requirements for Point above, then they represent a bounding box.

 

Converting HDDDMMSS to Decimal

If MARC 034 contains hemispheric data and not decimal data, it must be converted to decimal.

  • The simplest way to determine whether MARC coordinates are in HDDDMMSS format (vs. decimal) is to test if $$d starts with W or E (i.e. a letter).

  • If it doesn’t start with W/E, then it’s in decimal format.

Conversion math

H value -

  • N = ‘+’ Northern hemisphere is always a positive numeric value 0 to 90

  • S = ‘-’ Southern hemisphere is always a negative numeric value 0 to -90

  • W = ‘-’ Western hemisphere is always a negative numeric value 0 to -180

  • E = ‘+’ Eastern hemisphere is always a positive numeric value 0 to 180

Decimal degrees = H value (+ or -) + DDD + ((MM + (SS/60))/60)

Example conversion tool:
https://www.fcc.gov/encyclopedia/degrees-minutes-seconds-tofrom-decimal-degrees

Example 1:

  • N0804515

  • Decimal degrees = + 080 . ((45 +(15/60))/60)

  • 80.7541666

Example 2:

  • W0071205

  • Decimal degrees = - 007 . ((12 +(05/60))/60)

  • -7.201389

Example 3:

  • E1800000 [international date line]

  • Decimal degrees = 180

Example 4:

  • S0000000 [equator]

  • Decimal degrees = 0

 

OpenStreetMap (OSM) API

Background - this section describes use of PNX field for integration with OSM. We mapped MARC coordinates into lds40, e.g. <lds40>$$DE0300000$$EE0700000$$FN0350000$$GS0300000</lds40>

OSM requires decimal format. Some of our data in <lds40> are already in decimal, but most is in HDDDMMSS format. These need to be converted to decimal degrees using an equation.

The call to OSM will be slightly different depending on the geometry type. OSM will return appropriate image.

A call to set the map properties, such as bounding box comes from calling one of 2 functions. Each call sets the map extent and draws either a box or marker symbol showing the approximate area of interest.

After parsing the PNX coordinates, pass them to the OpenStreetMaps API, which will return an image we will emded in the Primo detail page.

(See github for how Harvard implemented this in 2018).


Example Harvard records

(Any of these identifiers can be searched via basic search in HOLLIS)

Print maps

  • 990028235430203941 - print map of Seattle from 1920, with coordinates in hemispheric form

  • 990027978990203941 - print map of Paris from 1878, with coordinates in hemispheric form

FGDC data layers (all coordinates in decimal)

  • EV_ISRAEL_CROPA - Crops, Israel, 1987

  • NLD_AMST6202RD_RELIEF_LJN - Relief Lines, Amsterdam (East), Netherlands, 2008-2010

  • CAMBRIDGE14CITYBOUNDARY - City Boundary, Cambridge, Massachusetts, 2014


We don't have a way to export this macro.