I have been working on placing the boundary in the correct location, or at least as “correct” as is technically possible. Before I started this, the boundary was mostly mapped using (as best as I can tell) data from the Canadian “Canvec” and “Geobase” datasets along the St. Croix River, and the NAD83 coordinates published by the International Boundary Commission in Passamaquoddy Bay. This was roughly correct in most cases, but some in some places the boundary is/was completely on the wrong side of the river. Essentially, we have been using the edge of the Canadian hydrography dataset as the national border.

The actual border

The actual position of the border is defined by the Treaty of 1908, as modified by the treaties of 1920 and 1925. The text of these treaties can be found on the website of the International Boundary Commission. The general message from actually looking at them is that the determinations and demarcations of the IBC are “definitive”… the boundary is where the IBC says it is, in their official publications and on their official maps.

These publications can be found in scanned form on HathiTrust. All but Special Reports 8 and 9 predate the adoption of the North American Datum of 1983… this means that the official position of most of the boundary is actually defined in either the pre-1927 United States Standard Datum, or the North American Datum of 1927.

While the IBC does publish a shapefile of the boundary (in NAD83) and a “coordinate listing” for each section in both NAD27 and NAD83, these files are of limited use. They are explicitly stated to be not official, and I have found obvious typos that would locate the border miles out of position. Also, the given NAD83 coordinates are unhelpful since they do not state which “realization” of NAD83 they are in. OSM is capable of storing coordinates to a degree of precision at which this makes a difference.

Obtaining correct coordinates

Because of these issues, the only method of accurately locating the border is to use the original coordinates as published in the original datum, bring them forward to NAD83, and then convert them to WGS84. When doing so, it’s important to have a understanding of how these systems are actually related in order to end up with coordinates that are as correct as possible. This is because, while the transformations between the USSD, NAD27, and NAD83 are static, those between NAD83 and WGS84 are not. While there have been multiple “realizations” of NAD83, the definition of the system has not changed. Instead, the revisions of NAD83 have been to correct network inaccuracies as the precision of measurement has improved. This means that the most current realization, NAD83(2011), should be used to give the most accurate result. The reference epoch for this is 2010.0.

NAD83 vs WGS84

When NAD83 was initially published in 1986, was defined on the the GRS 80 spheroid. This has not changed.. NAD 83 is a “fixed, geometric ellipsoid that doesn’t change it’s location as more accurate information becomes available.” This is not true for WGS84. NAD83 was initially, in 1984, the same as both WGS84 and the “International Terrestrial Reference Frame”, but both have been redefined multiple times since. This is done for the ITRF by the International Earth Rotation and Reference Systems Service, to result in “zero net rotation” while also improving the reference spheroid. The US Department of Defense then occasionally adjusts WGS84 to match the ITRF. Every time this is done, the WGS84 Prime Meridian moves, to match the ITRF at a specific point in time. This was last done in early 2021.

The center of the NAD83 “Earth” is now several meters away from the center of the center of the WGS84 “Earth,” and the offset between the two systems varies over time. This means that any rigorous transformation between the two requires knowing the epoch of the coordinates being used.

The current realization of the ITRF is “ITRF2020”, and the current realization of WGS84 is “WGS84 (G2139)”. These systems are defined to be coincident at the reference epoch of 2015.0. This is the system in which a GPS unit gives coordinates, and thus what is effectively used by OSM.

Putting it together

The process, then, begins with obtaining the NAD27 coordinates, and converting them to NAD83 (2011). I am using the NGS Coordinate Conversion and Transformation Tool (https://geodesy.noaa.gov/NCAT/) to do this. This places the coordinates at the reference epoch of 2010.0. I am then using NOAA’s “Vertical Datum Transformation” tool (https://vdatum.noaa.gov/vdatumweb/) to convert the coordinates to ITRF2020 @ 2015.0, with the elevation set to zero (the NAVD 88 zero point is mean sea level).

For portions of the boundary located on land (I’m not there yet) only the second step will be needed, since the NGS publishes well-determined locations for the boundary monuments in NAD83, as well as elevations.

Using this process, the main source of error in the calculated positions should be due to the unknown elevations (the convergence factor). I intend to post tables of the original and converted coordinates to the wiki, for future reference if the nodes are moved, or if I have made an error.

Hopefully, this will be a useful read for anyone looking to convert published geodetic positions for use on the map.

Just a quick note, re my previous one about the ‘project’ to fix the duplicate search results for US counties by linking the boundary relations.

I’m keeping a ‘informal’ worklist here… http://wiki.openstreetmap.org/wiki/User:Revent/Counties because I’m OCD and want to know they are all done.

Currently we have over 1100 counties done (out of about 3400), so approximately 1/3. More volunteers to do your local state welcome! :P Letting me know that an area has been done would also be nice, so I can mark it off the list.

ToeBee has a nice blog post about an efficient ‘workflow’ for fixing a state with JOSM here… http://ksmapper.blogspot.com/

After lots of Googling, talking on IRC, and futzing with things, I’ve learned how to get Nominatim to properly link boundaries and place nodes, and thus get addressing to work correctly (at least on the county level). I’m assuming this also works at the city level, though I’m still in the process of fixing Texas counties and haven’t tried it with cities yet.

The ‘key’ is in the names and alt_name, and using the ‘label’ role on the boundary relation. For example, “Anderson County, Texas” has ‘name=Anderson County’ and ‘alt_name=Anderson’, while the county node has ‘place=county’ and ‘name=Anderson”. Also, importantly, the county node is a member of the boundary relation, with the role ‘label’.

This is how it looks in Nominatim when working right…. the boundary: http://nominatim.openstreetmap.org/details.php?place_id=98191762 the county node: http://nominatim.openstreetmap.org/details.php?place_id=9162125655

This is an example of one I haven’t fixed yet, that is still working wrong… the boundary: http://nominatim.openstreetmap.org/details.php?place_id=98029496 the county node: http://nominatim.openstreetmap.org/details.php?place_id=1600889

As you can see, in the one that works right, the county node is listed as a ‘linked place’ in the boundary relation entry, and all of the places in the county are ‘addressed’ to the boundary relation instead of split between it and the county node. Also, if you look at the places located in the county, such as http://nominatim.openstreetmap.org/details.php?place_id=2769902 you can see that Nominatim is no longer having to ‘guess’ at the county addressing, as it’s now explicit.

I’m also setting the boundary ways as “boundary=administrative and admin_level=6”, but I don’t think this is really essential…it’s more a backup for if those keys get removed from the relation.

Thanks to the people who’ve talked this out with me on IRC, and especially lonvia, who gave the final part of getting it to work correctly. Now, we get to fix lots of counties…

Spam, sorry, nevermind. I though the recent entries thing would chop it off. My apologies.

(chopping this off into an offline file)