[Tagging] Proposed feature - RFC - Military Bases

[Graeme Fitzpatrick]

On Fri, 11 Dec 2020 at 11:42, Brian M. Sperlongano <zelonewolf at gmail.com>
wrote:

>
> 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.
>

Indeed! But we've still got another 10 - 12 days of RFC, so lo's of time
:-)

>
>
>> 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‽
>>
>
> 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.
>

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)

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?
>>
>
> 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.
>

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!

Thanks

Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201211/e548f20e/attachment.htm>