<div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Dec 2020 at 11:42, Brian M. Sperlongano <<a href="mailto:zelonewolf@gmail.com">zelonewolf@gmail.com</a>> wrote:<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 class="gmail_quote"><div><br></div><div>Yes, this makes sense in broad strokes, though some thought is needed as to the exact set of keys and values would be needed to describe these things.</div></div></div></blockquote><div><br></div><div>Indeed! But we've still got another 10 - 12 days of RFC, so lo's of time :-)  <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 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 dir="ltr"><div class="gmail_quote"><div></div><div>I don't think we'd need to drill down further into what "type" of unit it is (Armour, Artillery, Engineers, MP etc) as that will just introduce a whole realm of further confusion, especially if it's being done by non-Military mappers, plus which I also still have some security concerns about identifying things too accurately‽<br></div></div></div></blockquote><div> </div><div>I think it would be fine to have a way to tag such unit identifiers, though there can be multiple tenant units within a base, so this is possibly beyond the scope of base tagging.</div></div></div></blockquote><div><br></div><div>Yes, that may be another step after this gets through (assuming it does, & I've got say that, so far at least, nobody seems particularly upset with the idea) <br></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 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 dir="ltr"><div class="gmail_quote"><div><div>I did mention earlier in reply to one of the comments that (previously base=) military_service=yes / unknown would be OK if you can't work out what's in there, so that should hopefully cover that problem?</div></div></div></div></blockquote><div><br></div><div>I do not think that military_service=yes or =unknown should be included in the proposal.  For the "=unknown" situation, this is accomplished by simply omitting the tag, and for the "=yes" situation, this is redundant with the military=* tag.</div></div></div></blockquote><div><br></div><div>In the How to Map section of the proposal, I had worded it that military_service=xxx was mandatory. A comment was then made "that [it] prevents the mapping of military bases where the service is unknown", so I included 
=yes / unknown

for those cases (which should be rare). At the time, I was thinking about the ubiquitous building=yes & highway=yes, when you can't work out any further details beyond "It's there". Easier solution will be just to remove the "mandatory" requirement!</div><div><br></div><div>
Thanks<div><br></div><div>Graeme</div></div><br></div></div>