Larger and important survey points often have coordinates associated with them, often shown on a plaque. Obviously we don’t need to tag coordinates of ordinary objects, but in this case of official positions it might be beneficial to do so: Objects are easily moved, e.g. because they connected to a larger object or because available imagery is slightly misaligned. A tag would help to keep the information accurate. Secondly, a survey point might serve a greater purpose, like being a reference point between two different coordinate systems, e.g. for local surveying coordinates.
It seems that we’re missing a common scheme for this, so I would like to suggest a scheme and to ask for comments. Some of the tags below are already used somewhere, but usually only by a single import or by a single user.
In general, we need to specify the coordinate system used, and the coordinates, which can be given with latitude/longitude or northing/easting. The tags should align with the existing survey_point:* namespace.
Tagging:
The reference information: survey_point:datum = WGS84 / ETRS89 / EPSG:4326 ... - to name the used system survey_point:vertical_datum = EGM2008 - for the geoid model or sea level reference used for the height. The term is already used on some seamarks
The coordinates can be given with one of these, depending on the format used: survey_point:utm = 32T 653623 5543934 - for coordinates given in UTM format survey_point:lat = 50.76,survey_point:lon = 50.76 - for coordinates given in lat / lon survey_point:northing = 653623,survey_point:easting = 5543934 - for coordinates given in rectangular coordinates survey_point:ele - for the height of the point
If a point uses more than one set of coordinates, keys can be numbered in the same style as used on seamarks: survey_point:2:datum.
*:datum= , *:vertical_datum= : WGS84 is not enough. You need to specify the realization / reference frame, epoch. There are some ideas already, where *:datum= is *:datum:horizontal= (unsure about author’s opinion on vertical) Revent/Key:datum - OpenStreetMap Wiki
*:lat= , *:lon= : There’s some inconvenience to input when the coords are officially recorded in DMS
survey_point:2:datum= : Let’s not use numbering. It’s not pretty. This can also theoretically be interpreted to be there are multiple survey marks. Following ele:*= , it should be *:lat:*= etc, and *:datum:horizontal= can simply use semicolon.
If EPSG is to be used as suffixes, I personally suggest other formats eg *:EPSG****= / *:EPSG-****= / *:EPSG_****= / *:EPSG/****= not colon to avoid confusion with date suffix. Or, it can be always infix *:EPSG:****:*= , not trailing at the end.
It shouldn’t be a problem to allow all these formats where the latter omits the sometimes difficult to type degree symbol (although we already use it for inclines).
40.234
40° 12’ 23"
40 12’ 23"
This seems to be the case in the data we have so far, but we might also change to the more explicit tag.
The value should be as precise as possible. The EPSG number would be sufficient, for others we can think about a proper format to include all necessary information.
Could you make a suggestion how the information may be formated? What we have so far in various tags looks like a unformated mess.
The amount of information also makes it difficult to use suffixes, because the keys would be just too complicated. Better separate it into tags.
Not pretty, but easy to tag and interpret and successfully used in many contexts.
Sure.
Mammi71
(One feature, Six mappers and still More ways to map it)
4
Ich habe dies bisher immer als Freitext in description geschrieben, aber das ist leider schwer maschinell auswertbar.
Ein bischen schwierig finde ich das tag datum. Ich weiß, dass damit der Bezugspunkt gemeint ist, fürchte aber dass dies missverständlich sein kann. Ich verstehe unter datum eigentlich einen sehr konkreten Wert und nicht das Bezugssystem.
Also einen Begriff in der Richtung survey_point:coordinate_reference_system=* (WGS84 / ETRS89 / EPSG:4326 …) fände ich sinnvoller, eine kürzere Variante davon noch lieber (gängige Abkürzung survey_point:CRS=*)
Ich habe auch noch keine konkrete Idee, aber ich fände es am besten (insbesondere wenn mehrere verschiedene Referenzkoordinaten angegeben sind) je Koordinatenpaar nur eine tag/value-Zeile zu verwenden (und das wird immernoch komplex genug werden!)
For suffixing, I was only thinking about using the abbreviation or EPSG, no realization or epoch. Is there some need for multiple realizations or epochs?
The *:datum:horizontal= idea already had *:datum:horizontal:epoch= separately. WGS84 can have the G-number further split out. Is it clean enough already?
*datum* including this survey_point:datum= specifically is already being used. This post is only (trying) standardizing them.
CRS is not exactly the same as datum. However, you would be correct in using CRS for projections. On the other hand, datum might be a more commonly known term.
British Rail’s Computer Reservation System code has used ref:crs=
Mammi71
(One feature, Six mappers and still More ways to map it)
7
That’s the problem with using abbreviations
The >500 instances appear to be the result of a data import, presumably limited to the USA.
I have not checked whether this presumed import has been discussed in accordance with the import guidelines. However, the scale is manageable, and it is not too late either to devise a better tagging scheme or to convert the existing one into a better one.
And the problem with this data is that it does NOT contain the actual coordinates (otg) in the dataset, apart from the fact that they were originally (hopefully) placed in the correct location, together with a
note=... Please do not move it unless you know what you are doing.
This does not prevent accidental relocation and makes it extremely time-consuming to continuously check the correct location.
There is the approved survey_point:datum_aligned for points that are properly aligned OTG. For these a QA bot could compare coordinates and give a warning if they are off.
Btw. ele is quite often suffixed with some kind of reference system - this might set a precedence for using suffixes here as well: Search results | OpenStreetMap Taginfo
Mammi71
(One feature, Six mappers and still More ways to map it)
9
@mueschel ich weiß nicht ob wir uns d missverstanden haben: das aligned gibt ja nur mit ja oder nein an, ob sich der reelle survey_point otg exakt an der Stelle befindet, an der er sich lt. angegebenen Koordinaten befinden sollte oder durch Vandalismus oder Naturkatastrophen verschoben würde.
Der Poin in den OSM-Daten hat Koordinaten implizit durch das Datenmodell. Alle survey_points, welche bereits ein survey_point:datum enthalten (vermuteter Import in USA) habe in meiner Stichprobe ein aligned.
Aber:
womit soll ein Bot denn die Koordinaten vergleichen, solange wir diese nicht mit einem einheitlichen Taggingschema erfasst haben? Was bisher mit survey_point:datum erfasst ist, gibt das nicht her. Aus diversen inscription, description oder Note herauslesen halte ich für unrealistisch, ebenso unrealistisch darauf zu vertrauen, dass das erste Setzen des Datenpunktes exakt ist und auf jedes Verschieben in der Historie zu prüfen.
Well, things that haven’t been tagged according to a (new) scheme can often not be retagged automatically - this is the same here. Either the tagged coordinates are useful and can be verified, or they have to be resurveyed.
Mammi71
(One feature, Six mappers and still More ways to map it)
11
Ich verstehe nicht worauf du hinaus willst. Vielleicht könntest Du mir bitte näher und ausführlich erläutern welche markierten Koordinaten Du wie überprüfen möchtest oder wie neu vermessen werden sollen.
I don’t want to check any coordinates. All I say is that if something has been mapped before a tag was formalized it can’t be assumed to be correct according to the new standards. This is not unique to survey points but a general problem with anything we map.
Survey points should be stand-alone nodes (the other case remains valid).
So I to agreed with the issue, not with the solution.
But we could ask editors to warn if a survey point has been moved (well maybe make in “unmovable” with the mouse, similar to names when Wikipedia entries exist: in Id name:* edition is disabled on the top part, you have to change it on the bottom part. So you change change, but you’re aware of what you’re doing.
I see little added value in adding datum and coordinates. Because the coordinates have been converted in a common CRS.
Two possibilities: we have the official information and a bot can change or update the information. Osmose already does the validation check.
Or the information is hard to parse. In this case I can see an added value, but what could be the usage? Here the hard work (or not) is done in a Python script by Osmose.
Note: survey points are usually not alone and build a site. They can even share a reference! Brest E - 29019E have two staked survey points.
The point has a well-defined coordinate in some datum. We should be able to record this and not only a converted value that is limited to the precision of conversion and the OSM database.
My proposal is not to add mandatory tags to every survey point - it’s just to consolidate what mappers do since many years in many different ways: They see a survey point with coordinates and want to record this information explicitly.
This is one of the things that this proposal (if it becomes one) makes simple: You can add both sets of coordinates and datums on the same object.
Mammi71
(One feature, Six mappers and still More ways to map it)
15
This is either a reason not to use survey_point:datum at all, because it is already being used in a way that may not lend itself to conversion into a formalised schema, or to check whether the existing data can be converted with a reasonable amount of effort.
If I have counted correctly, there are 547 instances of survey_point:datum with just 14 different values. All of them relate to NAD83 … and WGS84 … with varying spellings in some cases (with and without spaces) and different epochs. Plus two instances of “Multi-Year CORS Solution 2”. The effort involved should be manageable.
And now, my objection once more: :datum= means, for me, a very specific value, a very specific coordinate in lat/lon. However, up to now this has been used to refer to the underlying coordinate system of the data source (the data in OSM would, of course, always be in WGS84). This is likely to become a problem in the long term if it is used more widely – which is why I recommend using a key name for the underlying coordinate system of the data source that more clearly describes the coordinate reference system.
I missed the ugly part with numbering ;-).
For clarity, can you please convert the data given in the mentioned document reproduced below in tags you’re proposing?
survey_point:datum=RGF93 v1 or EPSG:4965 (3D) or EPSG:4171 (2D) or the CRS EPSG:4964?
For information, RGF93 v1 is deprecated.
You may prefer ETRS89. But you’ve also 3 variants, ETRS89 - EPSG:4258 (2D, UoM: degree)?
Some variants include the third dimension. I would tend to prefer the 3D variant (omitting the vertical_datum as separate key).
Value conversion or not: here the decimal separator is the dot, so the English separator. But the Easting is using E/O, so the French abbreviation. Happy generic conversion! Or we do it once and use numeric values (my preference).
I tend to prefer keeping using lat, lon, ele (reference being mean sea level, here NGF-IGN 1969) and using tools to check unintentional moves.
Another important information is missing: accuracy.
Perhaps I should add the posted coordinates of some of my survey points. I’ve got both NAD27 and PLSS. I’m not sure how best to notate township/range/section coordinates, though.
I guess in this case of two points that agree in 2 out of 3 dimensions having them on two different objects is the correct way.
It seems the point is defined in RGF93 v1, so I think we have to use this whether it is deprecated or not. Maybe there is an updated version of the definition?
I agree. If the ‘datum’ contains information about the vertical datum, then the additional tag can be omitted.
No matter how exactly the value is formatted in the original document, we should always use English notation, but keep the scheme in DMS or decimal as in the source.
Thanks for all the input. I think we can summarize the current idea as follows:
survey_point:EPSG1234:lat or survey_point:EPSG1234:northing
survey_point:EPSG1234:lon or survey_point:EPSG1234:easting
survey_point:EPSG1234:ele
survey_point:EPSG1234:accuracy
Only if additional information like the epoch is needed and is not part of the code in the key survey_point:EPSG1234:datum, survey_point:EPSG1234:vertical_datum
A second set of coordinates for the same point can be added using a second set of these tags.
If two points do not agree in all three dimensions, then they should be mapped on separate nodes.
Could we collect a few names for datums? With EPSG it is simple, but I’m not familiar with all the other notations.
Jein ;-) this point is defined in RGF93 v1, so it make sense to use it. Some survey points of the same network use now RGF93 v2b. To be honest I was surprised to see the old reference, while at the same time, I’m used to see EPSG:2154 used… so this.
One issue is the definition of a datum ensemble, my understanding is that due to the precision of older data sets, the new version won’t make a meaningful difference, below an extract from the IGN article I mentioned earlier.
Side note: it’s in France, Europe is relatively fixed relative to WGS84, I believe that answers from Australia for instance would make much more sense.
