DanRunfola
commented
2 years ago @amanda-reed @lydiatroup I think this was resolved by https://github.com/wmgeolab/geoBoundaries/pull/2510, but I am not sure and don't have time to review this minute.
The specific reason I think this is resolved is that the new source is directly from the Swiss Federal office of Topography, as @davescodeproject recommeneded for a potential solution.
Could you take a look, and if we're good close this one out?
Dear geoBoundaries,
Hello from Australia!
Firstly, I want to say that I think you are doing important and meaningful work with geoBoundaries. I am heartened by the generosity of yourselves and your sponsors in making the resource generally available; and I recognise the enormous investment of time, effort, and dedication that geoBoundaries represents. In this context, the below is intended to strengthen the data set (if there is indeed anything to remedy), and if conclusions I have drawn are incorrect please endure them with patience.
*In comparing the boundaries specified by coordinates in the files (i)"geoBoundaries-AUT-ADM0.shp", (ii)"geoBoundaries-LIE-ADM0.shp", and (iii)"geoBoundaries-CHE-ADM0.shp" (corresponding with the ADM0 boundaries for Austria, Liechtenstein, and Switzerland) I have noted an apparent mis-registration/misalignment between (1) the borders of Austria and Liechtenstein (Liechtenstein in general is bordered on its Eastern and Northern flanks by Austria and its southern and western flanks by Switzerland (being enveloped by those two nations)); and (2) the borders of Austria and Switzerland (Switzerland is bordered to the North-East and East by Austria).
On the other hand, the border between Liechtenstein and Switzerland appears well registered.
*I cannot be absolutely sure which is 'correct': specifically (a) whether the Austrian border is accurately specified and the union of the Swiss and Liechtensteinian borders is wrongly shifted down by about 65 metres at a bearing of about 193°T relative to the Austrian border; (b) whether the Austrian border is wrongly shifted up by about 65 metres at a bearing of about 013°T relative to the union of the Swiss and Liechtensteinian borders; or (c) whether each is wrongly shifted by some margin with respect to some ground truth position.
Nevertheless, based on some checking I have done by obtaining more boundary data from what I think are official sites of the Swiss and Austrian Authorities (https://www.swisstopo.admin.ch/ and https://www.data.gv.at/katalog/dataset/db2c5b34-2410-4c80-b62c-bfee69417b7a respectively) I think the issue is with the "geoBoundaries-AUT-ADM0" dataset, and not the "geoBoundaries-LIE-ADM0" or "geoBoundaries-CHE-ADM0" datasets.
Here are some things I considered or checked in forming this view: *The boundary mis-registration/shifting does not seem to be an error of precision but rather of accuracy. The shape of the mis-registered borders between the Austrian and the Swiss/Liechtensteinian data sets corresponds well and neatly (the convex parts of one border match neatly with the concave parts of the associated alternative national border), which indicates that there is a uniform shift of all points, rather than some more intentional discrepancy within and between the data sets of the countries/nations. For example it does not appear to be an overlap or an underhang based on contested boundaries or different boundary definitions between the countries/nations.
*I wondered if the discrepancy may have been down to the software with which I was visualising the boundaries; however when checking the actual (Longitude, Latitude) data points in the geojson files directly there did seem to be a real offset in the data itself (not merely an apparent offset based on graphical projection).
*The source of data for the borders in Liechtenstein and Switzerland appears to be derived from "OpenStreetMap", according to the metadata, while for Austria it appears to be sourced from the "Federal Office for Metrology and Survey, Austria". So at first I speculated that the discrepancy may result from the OpenStreetMap data source using the 'Web Mercator' EPSG:3857 which apparently employs spherical formulae at all scales for projection, while the Federal Office for Metrology and Survey, Austria may more accurately assume a WGS-84 oblate spheroid. However, that notion was a guess without any actual knowledge of the methods used to generate the boundaries for either group. For example, I am not aware of whether the data inherently in the OpenStreetMap repositories encodes accurate observational (Longitude, Latitude) data using the WGS-84 reference for subsequent visual projection later (and if so whether the protocol for extracting the information from .osm files automatically makes that projection), or whether the data encoded in the .osm files carries some systematic variation stored in a state for immediate visual display.
*So I sought to compare the data for Switzerland in "geoBoundaries-CHE-ADM0" with some other authoritative/official source. In relation to Switzerland, it seems they may now (as of March 2021) provide an open licensed representation of digital data regarding administrative boundaries for Switzerland and Liechtenstein through its 'Federal Office of Topography'. (I think the main site is https://www.swisstopo.admin.ch/). Having located some relevant Swiss boundary data at https://www.swisstopo.admin.ch/en/geodata/landscape/boundaries3d.html, I found that it did seem to align on the eastern side with the current "geoBoundaries-CHE-ADM0" sourced from OpenStreetMap. This tends to indicate that there is not likely to be a systematic error in the OpenStreetMap data.
*I then sought to confirm the Austrian dataset "geoBoundaries-AUT-ADM0" by obtaining data from https://www.data.gv.at/katalog/dataset/db2c5b34-2410-4c80-b62c-bfee69417b7a which provides data for Vorarlberg (the Austrian region that abuts Liechtenstein and parts of Switzerland). Unlike the "geoBoundaries-AUT-ADM0" which was relatively mis-registered/offset, that Vorarlberg dataset seemed to register well with the Swiss boundary from "geoBoundaries-CHE-ADM0.shp" and with the Liechtenstein boundary from "geoBoundaries-LIE-ADM0.shp" (about 1-2m difference in places with minor shape variation). When this new Austrian data for Vorarlberg was then compared with "geoBoundaries-AUT-ADM0.shp", the "geoBoundaries-AUT-ADM0.shp" was found not to register with it, yet to be of a very similar (if not identical) shape.
Therefore, perhaps unexpectedly, it seems to me the "geoBoundaries-AUT-ADM0.shp" file may not be accurate; as opposed to either "geoBoundaries-LIE-ADM0.shp" or "geoBoundaries-CHE-ADM0.shp" being in error.
*I should also mention that I do recognise geoBoundaries principle of "provisioning the highest quality dataset feasible for each individual country ... with no guarantee of cross-country topology validity" meaning national boundaries may overlap one another. "For example, in cases where two nations share a contested border" geoBoundaries could rely on each country's definition of its own boundaries potentially resulting in overlaps. Nevertheless, the case I am describing seems to me less a question of different countries' boundary definitions, and more a question of alignment/registration. The significance may be that points apparently excluded from one nation due to the offset may in fact be contained, and points apparently included may not truly belong within the boundary of the shifted nation.
*Finally, I note incidentally that it may now be possible to obtain an official dataset for Switzerland and Liechtenstein from the Swiss "Federal Office of Topography" with license terms appropriate for geoBoundaries (see web address above). This may not have been possible previously. I don't know all of the inclusion criteria for geoBoundaries; however the Swiss site indicates "From 1 March 2021 swisstopo will offer its geodata according to the principles of Open Government Data (OGD)". Even if the requisite data for geoBoundaries were not downloadable there, this increased openness may indicate that a phone call or higher level contact could result in an official dataset with the appropriate license for geoBoundaries.
I hope that geoBoundaries has the time and resources to review of the issue described. And whatever the result, thank you for your great work with geoBoundaries.