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

[bkil]

> I think that root of problem is that you care specifically about midday summer shade,
> where summer_midday_shade=yes/no/limited may be viable.
>

Yes, thank you, that sounds like a step in the right direction.

> And I have taken shade=* as tag intended to cover shade status across entire day
> and across year that is doomed to failure.
>

Well, I guess it would be theoretically possible to also determine
areas which are shaded in almost all year long (or shaded in x% of the
time), but verifying that would be difficult. Sometimes
shaded_all_year_long=no (or yes) may be obvious on the ground, though.
But indeed, this is not _my_ primary motivation (as I see much less
utility in that and would require much more effort).

> My problem with shade=* is that across day and year status of
> shade at a given location changes dramatically
>
> For example path with building/trees on its western side, giving heavy shade
> after noon but none in the morning and around noon.
>

For this problem I proposed the approximation of
summer_midday_shade=limited - depending on footway geometry, you may
be able to walk close enough to the trees so that at least part of
your body is shaded.

Someone else proposed that we might want to treat this specially and
mark the approximate direction of the shade caster in these special
cases, like when walking along tree rows, high fence or long stretches
on houses. For example with summer_midday_shade:caster_direction=*
(see direction=*), or as a shorthand just by enriching the possible
values of summer_midday_shade=* with abbreviations like N, NE, NW,
etc. (but in this case, is the direction of the caster or the
direction of the shadow implied?), although I prefer the former
approach of typed value separation.

> Proper MVP is either throwaway prototype or extendable.
> summer_midday_shade=* tagging is not fitting either one,
>

On the contrary: some may just want to tag the obvious cases with
yes/no, while others may be more specific with yes/no/limited or
percentages or time syntax and whatnot. I'd call that extendable on
demand. And of course in areas where this doesn't make sense, just
don't tag it and use 3D only. This is only a shorthand for regions
where it could potentially help save time.

And coming from the top down: you can mark a whole section of hiking
trail as not having any shade from memory as a quick approximation at
first, and then others after you could refine it by doing a more
thorough survey and decide to split the way to three sections: the
beginning and end which are not shady and the middle one leading
through the forest that is.

And no, MVP is usually not understood to be synonymous to a prototype.
It means minimal viable product, which hints at that efforts should be
focused towards a direction which solves all major aspects of the
business case broadly (bad may need some polishing or further features
at the end). This is in contrast to working in a kind of depth-first
search, meaning that if time or money ran out, certain features of the
product would be implemented perfectly and fully, while others would
still not be functional at that point, but that usually makes the
whole business fail miserably as the product can't be sold.

https://en.wikipedia.org/wiki/Minimum_viable_product

>> A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
>>

Surely we could do 3D measurements of structures and vegetation all
day long, but if after many years of work it becomes obvious that no
user is really using this information, this would be wasted effort
that could have been spent better on other things.

> and I prefer to stop
> it before it spreads like other clearly bad ideas such as
> https://wiki.openstreetmap.org/wiki/Key:class:bicycle
>

1) What we proposed differ from that key in that this is a boolean or
ternary value that most mappers could agree upon after some practice -
this isn't that subjective at all. In situations when in doubt, just
don't add the tag and leave it to someone else who is more confident.
Or better yet, accept "NULL" as a valid value, as in leaving the tag
off in cases that are not clear cut. 3D mapping could be done in such
areas.

2) Why do you want anybody to stop anything (all the time)? Why does
it hurt you personally if I add this on a given footway? What kind of
conflict would that cause, what kind of data user would it confuse,
what kind of convention would it go against? I'd be actually okay with
something more specific like summer_midday_shade=*.

OpenStreetMap is better than our competitors in just this: we can map
whatever we see of value. And of course most cases, only time can tell
its value - things that never get mapped or don't have data consumers
implemented will just fade away eventually.

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.

> Yes, but tagging schemes need to be properly designed.
>

Up to now, I have read a lot more talk than design. ¯\_(ツ)_/¯

> There are some that are miserable failures for various reasons,
> and shade=yes/no/limited is going to be a massive failure as
> large part of places is shaded partially and this matters.
> Yes, there are places never ever shaded and basically always shaded,
> but for this data to be useful you need to handle what is between that.
>

Something to think about. I'm not completely against percentages
either (and interpreting yes/limited/no as 100%/50%/0%).

> Poland. Shade is useful both in winter (where some would rather
> avoid it, but it is not so important).
> Shade would be desired by at least some cyclists/hikers/pedestrians
> in summer months, often across the entire day.
>

Well, I have heard and seen awareness campaigns on many channels of
media that warn people to seek shade during midday and to try to
organize their activities to avoid direct sunlight illumination.

I have not seen similar warnings in winter around here ("it is going
to be especially cold, avoid shady paths at all times"). However, if
you think this could be of public interest in some areas, we could
introduce a shorthand to survey this just as easily (surely the heat
from the sun is still only usable during the midday):

winter_midday_shade=yes/no/limited

> Also, shade info would be useful for people desiring sunny bench during winter.
>

Oh, benches can be a lot of fun - you could add dozens of tags on them
if you wanted to.

Sitting in the shade during summer and on the sun in winter can be
nice. I would like to sit on a bench where rain is not pouring on me,
but this can be achieved in ways other than being covered=* by an
elaborate structure, hence it could have its own tag. In winter, I
would prefer ones without snow buildup, this also related to a kind of
shade or coverage against light rain.

I would prefer a bench that has grass as a landcover under it or at
least something that drains away water, otherwise I can't sit on it
for hours after the rain because mud can form under it.

I would sometimes prefer a bench that is shaded and/or on which I can
sit without the sun shining in my eyes or on my screen if I want to do
use a laptop when waiting for the train.

I would prefer benches of certain height and certain backrest angle
for comfort. I would prefer materials during the hot season that don't
heat up that much and that allow the breeze through, but would prefer
materials that don't get soaking wet after a rain in colder seasons.

I would like to sit in a windy spot during the hot season and in a
place that protects against cold breezes during the cold season.
Surely the wind isn't going to blow all day, but the level of wind
protection can be assessed, non the less (and then cross referenced to
the weather forecast of the day).

I want to know whether two benches are seated back-to-back in a way
where our heads can touch with those behind you or whether they are
fully separated (stay apart as per COVID-19).

I want to know whether benches are welded together in a way that
motion is easily transmitted across a row of seats (or connected
backrests), because it's annoying to sit along with children or this
with restless feet (in cases when there exist alternative spots).

I want to know whether the great majority of the sky would be visible
from a bench to observe the stars at night (or at least up to a level
of precision of direction=*).

The above were all pretty much objective and easily verifiable (up to
common sense). However, if we allowed for a little slack towards
subjectivity, I'd prefer benches that are not located at a noisy
place, having a certain level of noise insulation from nearby busy
roads by distance, foliage or otherwise.

> Good point, still mapping crown diameter still seems more viable
> than shade=* as tree will give shade that changes as day and year progresses.
>

Estimating height and crown diameter can be a lot more work. Maybe it
would get faster for an experienced mapper and with some special
smartphone app, perhaps using stereo vision or photos taken at
multiple places, but who will develop this? We usually joke about
adding this locally, but they are already pointing fingers at me for
micromapping much less involved things.

> No, I am pointing that it is a dead end that will lead nowhere or will cause
> clearly visible problems in the future.
>
> I was in position of saying to people "this mapped data is useless, as
> tagging scheme is fundamentally pointless/broken/useless" or seeing it,
> so I think that it is valuable to mention clear problems before massive work
> will be put into it.
>

Yes, it can be good to hear about multiple viewpoints before
committing ourselves to a scheme, hence why I asked (and also because
this is starting to get a FAQ).

> I think that root of problem is that you care specifically about midday summer shade,
> where summer_midday_shade=yes/no/limited may be viable.
> And I have taken shade=* as tag intended to cover shade status across entire day
> and across year that will fail.
>

Well, to be honest, we can't be sure what people meant when they
tagged things with shade=*. Maybe sometimes they meant to use
covered=*, at other times tried to imply an umbrella or a
building=roof above a POI or something like that. The author of the
wiki page had also declared to have just documented what can be seen
in TagInfo (I also document things like that in the wiki if they
appear enough times).

However, if people started to use the wrong way of tagging things, the
best course of action is to provide them with a way of marking things
up properly as soon as possible and document that. The sooner presets
could be created for it (and/or existing presets could be enriched
with further keywords), the better.