Proposal talk:Survey Markers

Let's use ground instead of none

Resolved

It is proposed to use survey_point:structure=none for ground installed nails as survey markers. See marker=ground (referring to underground features markers) to get inspired about ground value instead of none.
survey_point:structure=ground would be better Fanfouer (talk) 15:58, 4 June 2021 (UTC)

Hi, I think you've made a good point, none probably isn't a good name for the value. The problem with ground is that the pin/bolt might be embedded in something other than the ground - maybe a boulder, boardwalk, etc. What do you think of changing none to pin? --Kylenz (talk) 22:48, 5 June 2021 (UTC)

Yes, this would correctly describe it. "Ground" is not a "structure" in the first place. ---- Kovposch (talk) 07:42, 6 June 2021 (UTC)

I'll make the change --Kylenz (talk) 21:27, 6 June 2021 (UTC)

According to this, this would led us to split marker=ground in two with marker=plate and a new marker=pin for sake of consistency? It sounds weird that survey_point=* and marker=* won't have a set of values in common (despite some different specific values) Fanfouer (talk) 21:50, 7 June 2021 (UTC)

Hi, I think your suggested change for the marker=* tag is logical. As User:Kovposch said, ground is not a "structure", so it doesn't make sense for the survey_point:structure=* tag. I think pin/bracket/etc. is more descriptive than ground, it allows us to specify more detail, so it is better (?) What do you think? --Kylenz (talk) 05:58, 8 June 2021 (UTC)

Ok to me, I'll plan to propose changes on marker=* depending on this vote result Fanfouer (talk) 18:41, 8 June 2021 (UTC)

Reason for deprecation

Resolved

Why would you deprecate a tag as basic as survey_point=* when you have not touched the other main attributes, ie method (eg triangulation), spatial measure (eg horizontal control), and purpose (eg national datum). ---- Kovposch (talk) 07:47, 6 June 2021 (UTC)

Hi, survey_point=* is used very varyingly, almost like the source=* tag. See the taginfo page. We can't propose to repurpose this tag since it is used 12,389 times for very different purposes. And it would be impossibly hard to clean up every single one. So, I think the namespace approach works well, because as you alluded to, it's easy to add new tags to describe other features of survey points. --Kylenz (talk) 21:27, 6 June 2021 (UTC)

No matter what a tag usage is, it's possible to review a few values with definitions that get consensus. Introducing namespaces because of existing values that could be barely cleaned up is not so useful. Furthermore it doesn't encourage to cleanup original survey_point=*. I could just add new survey_point:structure=* and leave survey_point=* untouched Fanfouer (talk) 21:44, 7 June 2021 (UTC)

Hi, I agree that is it unfortunate that we can't repurpose survey_point=*. There are two problems that we cannot work around:

1. Cleaning up the 12,000 nodes with the survey_point=* tag is an impossible task. We would need to consult with the mappers of all 12,000 nodes to ensure we don't delete valuable information. OSM also does not allow automated edits for situations like these (See Automated Edits/Code of Conduct) so this is simply not feasable.

2. We cannot create a proposal for a tag that is already in use for a different purpose (especially one that is used 12,000 times).

--Kylenz (talk) 06:09, 8 June 2021 (UTC)

Let's keep it relative to whole population of man_made=survey_point: more than 300k occurrences. Cleaning survey_point=* isn't an unachievable goal, particularly when you define new values. When it came to clean up tower:type=* from power lines, there was more than 40k values to remove and adapt and it goes well. See this diary for more informations and return on experiences.

I still don't get why you don't take the opportunity to encourage manual changes over survey_point=* with this proposal. You'll get not only cleaned features but you will certainly get many more than 12k survey point qualified with approved survey_point=* values instead of now. Fanfouer (talk) 18:33, 8 June 2021 (UTC)

So, are you suggesting that this proposal should just ignore survey_point=* and not deprecate it, just leave it as-is? --Kylenz (talk) 22:24, 8 June 2021 (UTC)

You can make it approved with a few well defined values (currently proposed in survey_point:structure=*). Rolling out those values will encourage mappers to replace existing tagging at the same time and produce a greatly usable piece of data about survey points. This will be simple tagging, without namespaces. From 12k survey points currently qualified, you'll easily get 100k occurrences of approved values. Fanfouer (talk) 22:49, 8 June 2021 (UTC)

Ok, just to be clear, you want to replace survey_point:structure=* with survey_point=* but keep and survey_point:condition=* and other future namespaced tags? --Kylenz (talk) 22:53, 8 June 2021 (UTC)

I disagree with this for the same reason stated in the beginning. I'm only opposed to deprecating all of survey_point=* flat-out. I support adding survey_point:structure=*. This is a fine proposal about a particular attribute of this feature. It's not a must to ask for a expansion in coverage. Deprecatable values can be identified for migration. ---- Kovposch (talk) 02:39, 9 June 2021 (UTC)

Raised concerns about survey_point:structure=* weren't about relevancy but formal naming. Namespaces aren't required if survey_point=* is defined with Nature of a survey point or Structure of a survey point and if you use Lifecycle_prefix instead of particular survey_point:condition=*. Fanfouer (talk) 19:57, 9 June 2021 (UTC)

Some things, like the alignment with the local geodetic datum can't be expressed with Lifecycle prefix tags. In this thread's original message, User:Kovposch also suggested some future detail that would need to be expressed using namespaced tags. So, regardless we will end up with some namespaced tags for survey points. So for consistency, I think it's better to use survey_point:structure=* over survey_point=*. But I will update the proposal to not deprecate survey_point=*. --Kylenz (talk) 03:26, 10 June 2021 (UTC)

Such reasoning lead to fire_hydrant:position=* in place of location=* which causes a little harm actually. Finally, why existing marker=* isn't suitable for survey points? They depict a structure, currently used in combination with utility=* for utility markers but could be used with man_made=survey_point as well, could't you? I'm not against namespaces in general, I intend to use them only when necessary. Fanfouer (talk) 22:21, 10 June 2021 (UTC)

Using marker=* sounds like a good idea, but there could be issues. Would beacon/cut/bracket/magnet be valid values for marker=*?

More importantly, what if the survey point was located on an utility marker. For example, a survey_point:structure=cut on a marker=post, or a survey_point:structure=bracket fixed onto a marker=stone. Or survey_point:structure=medallion affixed to marker=post...

While these are rare cases, I think we wouldn't want to create a tag conflict. Similar to service=* on a way tagged as railway=* and highway=*

Thoughts? --Kylenz (talk) 03:42, 11 June 2021 (UTC)

That's good questions and I think yes, marker=* could be completed with additional necessary values. Look at marker=plate's definition: only valid on a not dedicated support. If you find a cut or a bracket on a dedicated stone, I'd be tempted to use marker=stone. Same question applies currently on survey_point:structure=bracket vs survey_point:structure=pillar.

Unless with a valid example provided, I don't think survey points could be mixed with utility markers: the first is installed at a precise place while second are here to warn about buried feature and can be changed/altered/destroyed/replaced at any time with no precise position. Fanfouer (talk) 22:20, 11 June 2021 (UTC)

Yeah, I think using marker=* could lead to some confusion though. We may find features tagged as man_made=survey_point and utility=*. As you alluded to, another point of confusion may be that marker=* implies something haphazardly placed, purely for informative purposes, whereas man_made=survey_point is very precisely placed. Seeing both those tags on one feature seems unexpected. And I suspect the possible values for survey_point:structure=* and marker=* will continue to diverge, and we will want some more specific values for survey point than normal markers. Like cut/bracket/magnet which wouldn't really be valid values for marker=*... --Kylenz (talk) 02:17, 14 June 2021 (UTC)

marker=* implies nothing but a visible structure of a marker. It includes not only utility markers but also milestones and property limits, there is no normal markers, each one got its own purpose. Erroneous combinations of man_made=survey_point and utility=* are advisable in QA tools, no problem to make them both incompatible. It's desirable and correct to separate purpose (man_made=survey_point, utility=*...) and structure/appearance (marker=*). Again, we had similar discussions about fire hydrants with particular tags that covers more general ones and prevent wider tagging extension for common good now. No problem to add as many value as needed in marker=* as well. Fanfouer (talk) 22:45, 14 June 2021 (UTC)

It seems wrong to create tags like marker=beacon and marker=cut, because these will never be valid when used with utility=*. I think this may also cause confusion in editors, because they will suggest all the common values for marker=* when you add a utility=*, some of which will not be valid for man_made=survey_point and others will not really be valid for utility=*, but editors/software won't know this. Is there actually a benefit in using marker=*? It seems like we are justifying that potential points of confusion aren't that bad, when the simpler approach would be just to use survey_point:structure=* as currently proposed --Kylenz (talk) 01:49, 15 June 2021 (UTC)

Why beacon and cut won't be valid with utility? We already have marker=stone which is actually barely used in combination with utility=*. marker=* can be used in combination with utility=*, not must. Software also can be aware of awkward combinations and warn mappers (see josm, id...). Don't you see any problem using fire_hydrant:position=* instead of location=*? In the past I was more confused by unnecessary particularism than documented and consistent tagging. Fanfouer (talk) 07:53, 15 June 2021 (UTC)

I don't think fire_hydrant:position=* is a good comparison, maybe fire_hydrant:type=* is a better example: It's useful that it's a separate tag rather than using marker=* since it can have more specific values that only apply to fire hydrants. If marker=* was used, software that processes fire hydrants would have to check that the values are actually valid for hydrants - for example marker=pin wouldn't make sense on a hydrant. Also, editors would have to maintain their own list of valid values, taginfo alone wouldn't tell you which values are logical. You're right, software and editors can work around complicated tagging schemes, but it's a pain (for example in openstreetmap/id-tagging-schema ^GitHub, ideditor/schema-builder ^GitHub wouldn't be able to). And it would make the documentation for marker=* rather complicated. So why should we use marker=* when it makes things more confusing than it needs to be? I don't see why there is an actual benefit of using marker=*, when the alternative (as currently proposed) is much simpler. --Kylenz (talk) 08:25, 15 June 2021 (UTC)

fire_hydrant:position=* was quoted relatively to location=*, not marker=*. Simplicity is subjective. Here you are currently proposing to develop a particular tag instead of using existing and more common ones (a big advantage actually), so sounds complex for anyone interested in completing those. Why did we define location=*, material=*, direction=*, voltage=*... instead of street_cabinet:position=*, bench:position=*, street_lamp:material=*, pole:material=* and so on? Anyway, dealing with shape here sounds more correct than structure. Fanfouer (talk) 10:27, 15 June 2021 (UTC)

I agree it makes sense for location=*, material=* etc. But in this case the values of marker=* will be different to survey_point:structure=*. And it'll cause confusion when there is a survey point on a utility marker, and for other reasons discussed above. You're right, Simplicity is subjective, but you haven't explained why reusing marker=* would make things simpler or easier. I've asked a question on the mailing list, we can change it if people agree that all these inconveniences are not important --Kylenz (talk) 22:36, 15 June 2021 (UTC)

A survey point on a utility pole

Following feedback from the mailing list, I think we should keep using survey_point:structure=* instead of marker=*. Also, see the photo on the right of a survey marker attached to a utility pole, which would cause a tag conflict... I'm going to mark this as resolved since I think every point has been addressed, if you disagree of course you can change it back to unresolved --Kylenz (talk) 23:33, 20 June 2021 (UTC)

To restate (same indent) from above: survey_point=* is needed still. Not a survey technician here but looking at the proposed structures, I'd suggest, that the proposal include "survey_point=fixed_point" at least. That will say, that the marker is useful as a geodetic fixed point in a survey. Such are still being newly built. They are not outdated yet. --Hungerburg (talk) 16:47, 14 June 2021 (UTC)

Hi, I've since updated the proposal not to deprecate survey_point=*. My intention was to express precise-placement using survey_point:condition=reliable/not_reliable but following feedback below I think it makes sense to change it to survey_point:datum_aligned=yes/no. what do you think? --Kylenz (talk) 19:54, 14 June 2021 (UTC)

I think this goes too far beyond what is observable on the ground by casual mappers, a possible add-on for experts. While it still fails to mention, what kind of survey point is found there, aligned or not. It is also about the scope of this proposal; There are several kinds of surveys. Not everything is a fixed point, used for registering a location in a grid, some also serve other purposes, e.g. the boreholes, that I mentioned below, to be used with an inclinometer, which is used to survey shifts in-between layers in the vertical dimension. --Hungerburg (talk) 22:34, 14 June 2021 (UTC)

okay, so you're suggesting using survey_point=* for the purpose of the survey point? The only survey points I'm familiar with are geodetic ones aligned to the local datum - can you think of some possible values other than geodesy and tectonic shift? Also, do you think this proposal should formalize this use of the survey_point=* tag or just leave it as is? --Kylenz (talk) 01:49, 15 June 2021 (UTC)

I was thinking, we should add survey_point:purpose=horizontal/vertical/both, and leave survey_point=* as it is. Any comments? otherwise i will add it to the proposal --Kylenz (talk) 00:18, 19 June 2021 (UTC)

Confusion over status

Resolved

There are some issues entangled in survey_point:condition=*.

1. At the very least, it mixes a certain "visibility" and "reliability", which can be separately tagged.

1. *:condition=* is not an ideal sub-key, when parking:condition=* and *:conditional=* are widely used.

1. You need to make it clearer that survey_point:condition=reliable and survey_point:condition=not_reliable means its relationship with the datum, not whether its coordinate is aligned (converted from the datum and positioned in WGS84) in OSM.

1. survey_point:condition=not_visible may be mistaken for not visible from aerial/satellite, from afar, or close up (need to remove grass or some obstacle over it), etc. Your definition of road surface and building base is more like covered up and not reachable.

-- Kovposch (talk) 08:00, 6 June 2021 (UTC)

Hi, I replied to this but the wiki seemed to delete my comments...

1. There is a similar ongoing discussion in the tagging mailing list which may affect this

2. Do you have a suggested alternative?

3. Do you have a suggestion for how to improve this?

4. Okay, what do you think of changing it to obscured or concealed ?

--Kylenz (talk) 21:27, 6 June 2021 (UTC)

1. Only saw replies about survey_point:condition=destroyed. Not sure about the outcome of those discussions.

2-3. I'm kinda stuck in this. No good idea yet.

4. I see you added survey_point:structure=underground for underground magnet. Maybe simply suggest adding location=underground for both cases, and use survey_point:structure=magnet for this?

---- Kovposch (talk) 03:23, 9 June 2021 (UTC)

1-4. I like your suggestion, what do you think of replacing survey_point:condition=* with survey_point:datum_aligned=yes/no. Then, covered/obscured/not_visible markers can be tagged as survey_point:structure=* and location=underground ? --Kylenz (talk) 04:39, 10 June 2021 (UTC)

Hi User:Kovposch, I didn't hear back from you, do you still think it's a good idea to change the proposal - perhaps as suggested above? --Kylenz (talk) 22:04, 17 June 2021 (UTC)

This is fine. After your reply, I was thinking whether it can be simplified, but it seems *:datum_aligned=* is the simplest. (I was also thinking about the lengthy section above) ---- Kovposch (talk) 06:50, 18 June 2021 (UTC)

I've made the change, feel free to unresolve this if you have further suggestions --Kylenz (talk) 00:04, 19 June 2021 (UTC)

plaque versus plate

Resolved

We already had defined marker=plate and this proposal introduces survey_point:structure=plaque. What is the best word between them both? Fanfouer (talk) 21:52, 7 June 2021 (UTC)

Hi, in New Zealand English / Australian English, 'plaque' is generally used to describe something like the photo on the right

- it would be unusual (but not wrong) to call it a 'plate'. I know OSM uses British English so we might need to ask this question on the mailing list --Kylenz (talk) 06:03, 8 June 2021 (UTC)

Well no one replied to my email... Personally I think 'plaque' describes this better, but I like the idea of being consistent with marker=plate. Then again, I think these kinds of survey markers will more closely resemble memorial=plaque so perhaps we should be consistent with that tag instead. What do you think? --Kylenz (talk) 03:32, 10 June 2021 (UTC)

No problem to me to replace marker=plate with marker=plaque for consistency sake, independently of choice to use marker=* in this proposal or not Fanfouer (talk) 22:49, 14 June 2021 (UTC)

okay, i will mark this as resolved---Kylenz (talk) 01:50, 15 June 2021 (UTC)

Structure = pole

Resolved

Scheibensignal (popular in western Austria)

Picture shows a pole (Stangensignal), in the past these were used as remote fix points, now mostly rotting. On the ground features, should fit some category in man_made survey_point, shouldn't it?

PS: Actually, there are two markers in the picture, both are poles. --Hungerburg (talk) 08:30, 8 June 2021 (UTC)

Is it a pole or a post? Fanfouer (talk) 18:36, 8 June 2021 (UTC)

The one behind the bench I'd call a pole; the one in front of the path may be called a post. Both are survey points. Never been to the very location in the picture, but knowing such from other sites, the black plaque on the post is a sure sign. --Hungerburg (talk) 20:20, 8 June 2021 (UTC)

Do y'all think it makes sense to create both pole and post? In addition, I'm wondering if we should remove pillar (use block or post) instead)? --Kylenz (talk) 22:20, 8 June 2021 (UTC)

Actually we had issues to find independent definitions for man_made=tower, man_made=mast and man_made=pole. It's not so desirable to create both pole and post because one would barely make a distinction between them. Fanfouer (talk) 19:59, 9 June 2021 (UTC)

Okay, makes sense. I've added pole and marked this as 'resolved', feel free to un-resolve --Kylenz (talk) 03:48, 10 June 2021 (UTC)

I am fine with the solution; the article about "post" calls the posts "poles" too. Might be worth to note in the table though, that the picture actually shows TWO poles, so the the smaller, wooden one in the front is not overlooked. It is a true survey point, the plaque/plate says that moving it is a punishable offence. --Hungerburg (talk) 08:05, 10 June 2021 (UTC)

I've updated the wiki page as you suggested, feel free to change the wording if you want --Kylenz (talk) 09:39, 10 June 2021 (UTC)

Mapping destroyed markers

Resolved

(written by User:Kylenz to summarise a lengthy discussion on the tagging mailing list)

The original proposal contained the sentence:

" survey_point:condition=destroyed is not proposed. If the survey marker no longer exists, it should be deleted from OSM"

There was a mixed opinion on whether destroyed survey markers should be mapped, but a general support for mapping obscured/covered survey markers.

Following the email discussion, the proposal was updated to read:

" survey_point:condition=destroyed is not proposed. Replace man_made=survey_point with destroyed:man_made=survey_point if you really want to map it, but keep in mind Good practice."

At this point there have been no further comments so I have marked this dicussion as 'resolved'. Feel free to un-resolve if you have further comments --Kylenz (talk) 04:59, 10 June 2021 (UTC)

Different kind of surveys

Moved to #Reason for deprecation

Recently I learned about the inclinometer. This is a device to measure drift in a hill/slope. On the ground it looks like a manhole (older ones) or a smaller type of manhole (only 20cm diameter), much like the caps on underground gate valves in drinking water supply e.g. The cover sits on a borehole - where I learned about it, close to 100m deep, as it goes down to where "solid rock" starts. Thankfully, this proposal will not deprecate survey_point=*, so I could put the term somewhere sensible. Any idea how the marker would be spelt? No picture here :( --Hungerburg (talk) 22:11, 10 June 2021 (UTC)

Sorry, I'm not familiar with with what you're talking about. In New Zealand, survey points are sometimes located underneath a manhole. Like this one, which is a pin inside a tube inside a manhole. This would be tagged as survey_point:structure=pin since the pin is the actual survey point. Not sure about your example --Kylenz (talk) 20:00, 14 June 2021 (UTC)

Adding the proposed keys (and values) to the "Proposal Page" template

Resolved

See title, and for "Applies to: node" you might add a template as well: . --MalgiK (talk) 17:52, 15 June 2021 (UTC)

Hi User:MalgiK, I was a bit confused by that template since it doesn't explain what to do when you have multiple proposed keys and values. Any advice? And I will change the word "node" to "" --Kylenz (talk) 22:09, 15 June 2021 (UTC)

Hi, you are right, the proposal template seems not really suitable for multiple keys and values, maybe at least just via a text form like this:?

{{Proposal Page | name = Survey Markers | key = survey_point:structure=beacon/block/pillar/pole/bracket/plaque/medallion/pin/cut, survey_point:condition=reliable/not_reliable/not_visible <!-- The key of the proposed new tag, if relevant --> | value = <!-- The value of the proposed new tag, if relevant --> | type = {{IconNode}} | definition = The structure and condition of a survey marker. }} --MalgiK (talk) 02:24, 16 June 2021 (UTC)

I've made the change (it seems to have broken the page layout...). Feel free to edit it yourself too :) --Kylenz (talk) 04:36, 16 June 2021 (UTC)

Scope of "survey_point:structure=pin"

Resolved

Hello! I'm currently not sure about how broad the definition of "survey_point:structure=pin" is supposed to be. Are there any constraints in size or whether there is an indentation to insert survey instruments?

1

2

3

4

--Nw520 (talk) 22:38, 15 June 2021 (UTC)

Hi, yes at the moment survey_point:structure=pin is a bit broad, I don't think we need a size limit, do we? Maybe it would be useful to use diameter=*. I'm not sure how you could express that there is an indentation to insert survey instruments - any ideas/suggestions? --Kylenz (talk) 22:47, 15 June 2021 (UTC)

Personally I don't think there's need to include strict constraints regarding size in any of the types or markers, so using diameter=* should be fine. However, I'd argue that it would be good to be able distinguish the markers as shown in the images I've included above (especially 1 in contrast to 2 in contrast to 3/4). This could be done by either having an additional value for survey_point:structure with 1 and 2 each having a different value from 3/4, or alternatively by introducing a new key for whether there's an indentation and of what type it is, which would be nice to have included in this proposal but not a necessity. I don't have a strong opinion which option is better, so I suppose it's up to you whether you see the need to include this in your proposal. --Nw520 (talk) 17:46, 16 June 2021 (UTC)

I don't have a strong opinion either, perhaps survey_point:structure=indented_pin? I don't know if there is a special name for these in English - "Mag Spike" appears to be a brand --Kylenz (talk) 19:58, 16 June 2021 (UTC)

I've added indented_pin as an option, feel free to unresolve if you have other ideas/suggestions --Kylenz (talk) 00:05, 19 June 2021 (UTC)

Tagging conflict between survey markers and utility poles

• I have comments but abstain from voting on this proposal. A way too short period of time to evaluate impact of survey_point:purpose=* (introduced on june 20). I still wish to complete existing marker=* instead of introducing specialized survey_point:structure=* Fanfouer (talk) 10:19, 21 June 2021 (UTC)

Hi User:Fanfouer, as we discussed, there is simply no way around these 3 issues which make it an inconvenience to use marker=* --Kylenz (talk) 22:40, 21 June 2021 (UTC)

Did you read my answer @Kylenz:? Fanfouer (talk) 22:48, 21 June 2021 (UTC)

Hi, yes I did, I also included a photo of a survey marker on a utility pole which creates a tagging conflict. You asked why people will be confused - that question can't really be answered, we should just avoid creating situations that could lead to confusion --Kylenz (talk) 23:02, 21 June 2021 (UTC)

Thank you for picture, I guess you're dealing about conflict between man_made=utility_pole + utility=* and marker=plaque + survey_point:purpose=both + ... right?

In such a situation, is the survey marker related to the pole itself or does the pole is used as a common support?

You're probably dealing here with supported features on a single OSM node (a sign on a pole, a light/camera on a pole, a clock on a wall, antennas on a mast, whatever). There are plenty of cases like this we can solve with splitting the node in independent features with their own tagging or punctually using namespaces to solve the indetermination (here with survey_point:marker=* for instance to let utility=* related to the pole only). Anyway, it's a flaw in OSM modelisation we spend hard time to handle and find solutions for, proposing a specialized tag instead of using a common one isn't a valid one to me.

Your proposal may require a bit more discussion to get details about different situations you want to tag, survey point on a pole wasn't part of it prior to start the vote. Fanfouer (talk) 10:32, 22 June 2021 (UTC)