[Tagging] Planning route in the shade during hikes either in urban areas or forests

[Joseph Guillaume]

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.

1) shade can be made a constant either by:
a) focusing on a time of day and season at which it is important (yes,
accepting it's useless at other times)
b) documenting the directions from which shade is cast at a given season

2) shade is indeed easier to map than 3D buildings, especially with complex
building parts, and 3D trees are a whole other subject.
Adding attributes to existing objects is easier than mapping geometries.
I've explicitly suggested not allowing ways to be split solely to capture
shade.

3) mapping shade provides implicit data about nearby 3D objects, and can
therefore help prioritise 3D mapping in the longer term

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

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
https://lists.openstreetmap.org/pipermail/tagging/2021-July/062015.html

I particularly appreciate bkil's analysis of valid reasons to reject a tag:
https://lists.openstreetmap.org/pipermail/tagging/2021-July/062012.html
"Surely you should not add things to OSM that are not of common public
interest. You should not bloat the database with items that will make
it many times as big without a perceived benefit. You should not mark
things in a different way if they already have an agreed upon,
established way of marking. You should not overload existing tagging
in a way that could potentially confuse either human readers of the
tags or existing data users. You should not add things that can't be
realistically verified or that would cause a maintenance burden for
others (and you). Don't add things that could lead to edit wars and
conflicts all the time. I don't think that any of these apply here, so
we're good."


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.


On Sat, 17 Jul 2021, 4:25 am Frederik Ramm, <frederik at remote.org> wrote:

> Hi,
>
> On 7/16/21 19:42, bkil wrote:
> > Could you perhaps share your reasoning or what needs to be improved
> > for you to accept it or could you propose a better alternative?
>
> I'm sorry to have to say it so bluntly, but no improvement can fix this
> proposal. Whether something is in the shade or not is dependent on time
> of day and time of year. It cannot be mapped as a constant. And even if
> you were to qualify that ("at noon during the usually hottest month of
> the day") it would still mean that you'd have to split up the way in
> tons of mini pieces AND the information would be useless for someone
> seeking shade at four in the afternoon. This proposal has so many
> problems that it should have been thrown out after the first few
> exchanges. It has zero chance of being accepted.
>
> If you want routing in the shade, your router will have to employ a
> mathematical model during graph building to derive that property from
> nearby shade-giving structures. Yes, that is more complex than the "few
> lines of code" that you mention in your wiki page. But we can't pollute
> our whole database with derived information just to save someone from
> having to do the math.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210717/9a52eb5c/attachment.htm>