<div dir="auto"><div><div dir="auto">I was originally against the proposal too, so I want to explain why I'm now still talking about it, and am indeed considering to start mapping it.</div><div dir="auto"><br></div><div dir="auto">1) shade can be made a constant either by:</div><div dir="auto">a) focusing on a time of day and season at which it is important (yes, accepting it's useless at other times)</div><div dir="auto">b) documenting the directions from which shade is cast at a given season</div><div dir="auto"><br></div><div dir="auto">2) shade is indeed easier to map than 3D buildings, especially with complex building parts, and 3D trees are a whole other subject.</div><div dir="auto">Adding attributes to existing objects is easier than mapping geometries.</div><div dir="auto">I've explicitly suggested not allowing ways to be split solely to capture shade.</div><div dir="auto"><br></div><div dir="auto">3) mapping shade provides implicit data about nearby 3D objects, and can therefore help prioritise 3D mapping in the longer term</div><div dir="auto"><br></div><div dir="auto">4) Living in Australia, I frequently take into account shade when going outside with the kids, in summer to avoid the heat and sun, and in winter to find a warmer place.</div><div dir="auto">I have my own existing heuristics involving looking at hires imagery, but given the very low level of building mapping in Australia let alone vegetation and 3D, both (2) and (3) are increasingly attractive.</div><div dir="auto"><br></div><div dir="auto">This tag isn't going away, so unless you want me and others to do any tag we like, it would be great for others to engage in the specific suggestions for tag design, or at least names of tags, e.g. in </div><a href="https://lists.openstreetmap.org/pipermail/tagging/2021-July/062015.html" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/pipermail/tagging/2021-July/062015.html</a></div><div dir="auto"><br></div><div dir="auto">I particularly appreciate bkil's analysis of valid reasons to reject a tag:</div><div dir="auto"><a href="https://lists.openstreetmap.org/pipermail/tagging/2021-July/062012.html" target="_blank" rel="noreferrer">https://lists.openstreetmap.org/pipermail/tagging/2021-July/062012.html</a></div><div dir="auto">"Surely you should not add things to OSM that are not of common public</div><div dir="auto">interest. You should not bloat the database with items that will make</div><div dir="auto">it many times as big without a perceived benefit. You should not mark</div><div dir="auto">things in a different way if they already have an agreed upon,</div><div dir="auto">established way of marking. You should not overload existing tagging</div><div dir="auto">in a way that could potentially confuse either human readers of the</div><div dir="auto">tags or existing data users. You should not add things that can't be</div><div dir="auto">realistically verified or that would cause a maintenance burden for</div><div dir="auto">others (and you). Don't add things that could lead to edit wars and</div><div dir="auto">conflicts all the time. I don't think that any of these apply here, so</div><div dir="auto">we're good."</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I'm also happy for the discussion to move to the wiki, but would be unlikely to bring a proposal back to the list myself given the hostile reaction.</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, 17 Jul 2021, 4:25 am Frederik Ramm, <<a href="mailto:frederik@remote.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">frederik@remote.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 7/16/21 19:42, bkil wrote:<br>
> Could you perhaps share your reasoning or what needs to be improved<br>
> for you to accept it or could you propose a better alternative?<br>
<br>
I'm sorry to have to say it so bluntly, but no improvement can fix this <br>
proposal. Whether something is in the shade or not is dependent on time <br>
of day and time of year. It cannot be mapped as a constant. And even if <br>
you were to qualify that ("at noon during the usually hottest month of <br>
the day") it would still mean that you'd have to split up the way in <br>
tons of mini pieces AND the information would be useless for someone <br>
seeking shade at four in the afternoon. This proposal has so many <br>
problems that it should have been thrown out after the first few <br>
exchanges. It has zero chance of being accepted.<br>
<br>
If you want routing in the shade, your router will have to employ a <br>
mathematical model during graph building to derive that property from <br>
nearby shade-giving structures. Yes, that is more complex than the "few <br>
lines of code" that you mention in your wiki page. But we can't pollute <br>
our whole database with derived information just to save someone from <br>
having to do the math.<br>
<br>
Bye<br>
Frederik<br>
<br>
-- <br>
Frederik Ramm ## eMail <a href="mailto:frederik@remote.org" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">frederik@remote.org</a> ## N49°00'09" E008°23'33"<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>
</div></div>