<div dir="ltr"><div>Hi all<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 16 juin 2021 à 01:40, Paul Allen <<a href="mailto:pla16021@gmail.com">pla16021@gmail.com</a>> a écrit :<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 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" target="_blank">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 lang="EN-NZ">
<div>
<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></div></blockquote><div><br></div><div>We should be careful about validity and probability.</div><div>survey_point:structure=* and marker=* are both about shape and appearence of survey points or markers, not purpose.<br></div><div>If some values are not valid (understood as unlikely) with man_made=survey_point or utility=*, why mappers be confused when they look on ground?</div><div>The shape is enough to determine the right value to use, why have we to look to purpose? Did we confuse shapes and purpose?<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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 lang="EN-NZ"><div>
<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></div></blockquote><div><br></div><div>Josm warns me very often about poor choices of values depending on context (in a simple mapcss file). Why iD and other tools can't do the same?</div><div><br></div><div>Furthermore, Data Items now allow to state some values incompatible with others.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-NZ"><div>
<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></div></blockquote><div><br></div><div>A survey point is precisely placed (and kept in place), an utility marker or highway milestone is here to give an information (and can be moved a few meters away without bother anyone)<br></div><div>Do you have any examples of survey point and utility marker found in the same place?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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 lang="EN-NZ"><div>

<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></div></blockquote><div><br></div><div>Do you feel the same about usage=*, location=*, tower:type=*, substation=*, material=*, surface=* ...?</div><div>Will you agree to define a new key each time you need to specify a subset of values in a given context?</div><div><br></div><div>Interesting point to discuss, thank you Kyle</div><div><br></div><div>François<br></div></div></div>