<div dir="ltr"><div dir="ltr">On Tue, 15 Jun 2021 at 23:36, Kyle Hensel <<a href="mailto:K.y.l.e@outlook.co.nz">K.y.l.e@outlook.co.nz</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div style="overflow-wrap: break-word;" lang="EN-NZ">
<div class="gmail-m_4330408776427955693WordSection1">
<p class="MsoNormal">Hi, a suggestion on the Survey Point proposal (<a href="https://wiki.osm.org/Proposed_features/Survey_Markers" target="_blank">https://wiki.osm.org/Proposed_features/Survey_Markers</a>) was to re-use the tag marker=* instead of creating survey_point:structure=*</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This sounds like a good idea, but there are some issues:</p>
<p class="MsoNormal">* Some values of survey_point:structure= are not valid for utility poles, and vice-versa, so the marker=* tag would become complicated - some values can only be used with certain tag combinations.</p></div></div></blockquote><div><br></div><div>Not good.  Some mappers will mistakenly use wrong combinations. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" lang="EN-NZ"><div class="gmail-m_4330408776427955693WordSection1">
<p class="MsoNormal">* It will be difficult to create presets in editors like iD because of the foregoing point – fetching a list of common values from taginfo wouldn’t tell you which values are valid for which features.</p></div></div></blockquote><div><br></div><div>Because it would require special-case code to figure out which values are</div><div>valid (yeah, table-driven but extra work, especially when new values are</div><div>added) then iD's authors are likely to refuse to implement a preset for it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" lang="EN-NZ"><div class="gmail-m_4330408776427955693WordSection1">
<p class="MsoNormal">* there will be a tagging conflict for survey points on the same node as a utility pole, since it’s not clear what marker=* refers to (like the service=* tag on roads/railways)</p></div></div></blockquote><div><br></div><div>I don't know if this happens in reality, but it probably could happen.</div><div>Another reason not to do this.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" lang="EN-NZ"><div class="gmail-m_4330408776427955693WordSection1">

<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So what does this mailing list think of using the marker=* tag instead of creating survey_point:structure=* ?
</p></div></div></blockquote><div><br></div><div>I can only speak for me, but I think it's not a workable idea.</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>