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

Wed Jul 14 08:41:16 UTC 2021

Thanks for the detailed responses.

In terms of design of a summer_midday_shade key, here's a few further
thoughts:

- How would splitting of ways be dealt with?
Rather than encouraging it, maybe it's better to limit the tag to benches
and playgrounds rather than linear features, e.g. places one would actually
go to or stop in the shade. If a full way is in the shade, then it could
still be treated as a place one would go to and tagged accordingly.
Creating polygons solely to map shade, e.g. in the middle of a park, would
also be discouraged.

- Given that the tag can be estimated from 3D data, would this be
explicitly discouraged?
Presumably yes, but this then means that a lot of duplicate work is
required to map shade in areas where 3D buildings are already mapped.

- If a QA tool compares 3D shade and mapped shade, it would need a precise
definition of when shade is calculated.
Presumably it wouldn't be exactly 12:00 noon in the local time zone or
solar noon, or only on 21 June, or at ground level.
Would the definition be something like  shaded at least some time in the
calendar summer months within 2 hours of solar noon at 2m height?
This would give sufficient leeway to be mappable on the ground while
retaining geometric verifiability.
The date and time range chosen would imply the direction in which shade is
coming from, so automated checking could involve checking whether an object
of the necessary height is present within the necessary distance in that
direction.

- summer_midday_shade:caster_direction would actually be a bit redundant
from this perspective.
This suggests that a general summer shade tag that specifies directions
could indeed be feasible, e.g. summer_shade:caster or
summer_shade_directions.

If we know the direction of the sun, then we can check whether shade is
cast by an object in that direction.
The tag then encodes two forms of information: 1) whether there is shade
for any position of the sun (in summer months), 2) that there are objects
worth mapping in 3D in those directions.

Both cardinal/intercardinal directions and bearings in degrees could
probably be used, e.g.
summer_shade_directions=S;SW
summer_shade_directions=70-80;120-140
And maybe special values, e.g.
summer_shade_directions=always
summer_shade_directions=no
summer_shade_directions=yes could be retained to mean that shade does occur
from unknown directions, and mappers would be encouraged to add a fixme
with the time of day and date that shade was observed.

This type of tag is probably also more forgiving of being placed on linear
features because it provides information about the object casting shadow,
but splitting ways solely for shade would probably still be discouraged.

On Wed, 14 Jul 2021, 4:05 pm bkil, <bkil.hu+Aq at gmail.com> wrote:

> > 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.
>
> _______________________________________________
> 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/20210714/5d8cbedc/attachment-0001.htm>