<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Ah, I think removing the specifications to electricity:access may
have made this a bit more ambiguous than it was in the previous
rendition (but then it was overworked so...) To make it clearer
(hopefully!): electricity should be tagged on significant public
buildings or amenities where the information is beneficial to the
community. So, the knowledge of if a hospital has a generator
would generally be helpful but that a supermarket has electricity
in the US can be assumed to be given. If the electricity is
available to the public then access=* or electricity:access=*
should be used to clarify. (I just noticed that this tag is
missing in one example, I'll add it when voting finishes). Default
is access=private so that any travellers are not unduly surprised
in case of mistagging. So for the cafe page I would add a note
that electricity=yes + electricity:access=customers + socket:*=#
would be the tagging method if there are publicly available
charging spots.</p>
<p>I think adding the word significant to the definition would bring
it on par with the natural=tree definition. Many other tags that
can similarly be over-tagged don't have disclaimers however. I can
further define what significant means, but I fear this means that
it then becomes too long again and people don't actually bother
reading the page. I'm open to suggestions!</p>
<p><br>
</p>
<p>I think a general discussion as to the breadth of tagging would
be good for OSM - I'm not so sure that the electricity proposal is
the right place for that though. In OSM I can find the color
temperature, ref, direction, mounting method and a host of other
information about the street lamp outside my window as well as the
building material that my house is made of. Certainly too much
information for me but perhaps useful to some. Perhaps having some
sorts of layers could be useful? It seems most major tags are
already categorized but perhaps it would be useful to start
thinking about the level of detail each tag provides so that some
can be filtered out. That is, you can view only buildings and then
with a further layer download the detail-tags of the primary
objects and the not-so-important-for-navigation amenities. I think
some map providers such as OSMAnd already do this to some extent?<br>
</p>
<p>Mapping in OSM seems to be headed in two directions - those that
want a extremely accurate map with every detail possible and those
that want a barebones navigation map. Personally, I think the
strength of OSM is the level of detail available in the database,
but when e.g. travelling one only needs outlines and some basic
amenities typically. Perhaps then the worry of excessive
over-tagging would be lessened. Are there any other problems with
too much detail other than excessive file size that I'm
overlooking?<br>
</p>
<p><br>
</p>
<pre class="moz-quote-pre" wrap="">On 20/01/2021 23:57, Stefan Tauner wrote:<blockquote type="cite"><pre class="moz-quote-pre" wrap="">On Wed, 20 Jan 2021 23:45:46 +0100 (CET)
Mateusz Konieczny via Tagging <a class="moz-txt-link-rfc2396E" href="mailto:tagging@openstreetmap.org"><tagging@openstreetmap.org></a> wrote:
</pre><blockquote type="cite"><pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/#map=19/48.20506/16.37955">https://www.openstreetmap.org/#map=19/48.20506/16.37955</a>
</pre></blockquote><pre class="moz-quote-pre" wrap="">
Yes, this was a big import done from OGD in Vienna with about 300k
trees about 8 years ago IIRC and there are quite some problems with them
(e.g., regarding keeping them up to date).
However, I am not so sure if this is a good example for an argument
against "overtagging" though. Most of these trees are tagged with quite
many details (species, height, circumference of the trunk,
diameter_crown, a start_date) and thus are regularly used to showcase
proof of concepts like 3d mapping based on OSM data where these tags
are used, cf.
<a class="moz-txt-link-freetext" href="https://demo.f4map.com/#lat=48.2040328&lon=16.3774375&zoom=19">https://demo.f4map.com/#lat=48.2040328&lon=16.3774375&zoom=19</a>
This very clearly shows how such data can be beneficial although
looking redundantly and not fitting initially.
(I was not involved in the import and would not support a similar
operation in the future but not because of the questions at hand but
maintainability).
</pre>
</blockquote>
</pre>
<br>
<div class="moz-cite-prefix">On 21/01/2021 10:37, Mateusz Konieczny
via Tagging wrote:<br>
</div>
<blockquote type="cite" cite="mid:MRZWQ4a--3-2@tutanota.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Jonathan Haas now phrased much better what I was trying to
express and noticed a bit wider <br>
</div>
<div>issue:<br>
</div>
<div><br>
</div>
<div>"I feel it is not well defined what electricity=yes actually
means. Does it mean the building<br>
</div>
<div>has electricity, or the electricity is available to a
visitor/guest? Or putting it another way,<br>
</div>
<div>what is the implied value of electricity:access=* if it isn't
present? If it just means that the<br>
</div>
<div>building has electricity, tagging electricity=yes is useless
in most developed countries, as<br>
</div>
<div>that should be implied. If it means the electricity is
available to guests <br>
</div>
<div>(like in the café/campsite example), that means the tagging
doesn't make sense for<br>
</div>
<div>third-world-hospitals."<br>
</div>
<div><br>
</div>
<div><a
href="https://wiki.openstreetmap.org/wiki/Proposed_features/electricity#Voting"
moz-do-not-send="true">https://wiki.openstreetmap.org/wiki/Proposed_features/electricity#Voting</a><br>
</div>
<div><br>
</div>
<div>Jan 20, 2021, 22:02 by <a class="moz-txt-link-abbreviated" href="mailto:lrichert@posteo.de">lrichert@posteo.de</a>:<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<p>Hi Mateusz,<br>
</p>
<p>the proposal doesn't encourage pointless spam. I have already
said that I agree with you and will add that language into the
final wiki page, although I personally think that it is a
given that one shouldn't tag things when there is a clear
default. Abstain from the vote if you must - I asked often
enough if there were any other small fixes that need doing,
but I strongly object to the word <b>encouraging</b> in your
text. Encouraging would be if I explicitly asked people to tag
this on every public amenity, which I don't. <br>
</p>
<p>Unfortunately I can't change the wording during the vote but
this is a truly minor change that can be done afterward. You
seem to be trying to find any reason to vote against it - it's
quite tiring - instead of focussing on the substance of the
proposal. <br>
</p>
<p>Regards, Lukas<br>
</p>
</blockquote>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>