Talk:Key:shade

Rendering link moved

link is down with a message telling the service has moved. but c/p the new host return a 404

Removed the rendering link --JoeG (talk) 03:27, 17 July 2021 (UTC)

type of shade

How would you specify the kind of shade, like whether it comes from a man_made feature or foliage (tree or hedge)? What is the criterion with regard to time of day, like if due to the angle of the sun, it only provides shade between 11:00-13:00 (the most important time), before noon or in the afternoon? It can also come handy to know whether the pavement will still be burning to your dog if shade only reaches the highway during the afternoon. Also, should it be combined with seasonal=* for deciduous plants? It would definitely be great to have this information in the database so an application could be developed that could route you as much as possible in the shade during hikes either in urban areas or forests. -Bkil (talk) 12:41, 3 July 2021 (UTC)

see next section --Hufkratzer (talk) 14:06, 5 July 2021 (UTC)

I've added a discussion of issues around this to the wiki page. This is a hotly debated issue and will need to be addressed in a full proposal. --JoeG (talk) 03:27, 17 July 2021 (UTC)

yes/no/limited

What if we defined tagging like the following?

• shade=yes If a sidewalk is covered by a mature tree row, it should be shady during the hottest days in the most critical hours (10:00-15:00?),
• shade=limited If no foliage covers a sidewalk but there are high rising structure just besides the two sides of the road or foliage is nearby the sidewalk, it would be shady in limited times of day varying by place
• shade=no Otherwise it's not particularly shady. In days of heat wave, you should definitely try to avoid these stretches.

-Bkil (talk)

This would not reflect the current usage of this tag. Most used values currently are:

* no or none 227

* yes 171

* roof 145

* tree(s) 117

* portico 76

* pergola 27

* partial 17

* building 4

So, apart from "no" and "yes", it's more used like covered=*, using the value as an indication what causes the shade. --Hufkratzer (talk) 12:29, 5 July 2021 (UTC)

We may choose another key if you think this would clash, although many of the above may be mistaggings of covered=*. We can also consider moving these to a new subtag, like shade:caster=*. This aligns with progressive refinement commonly found in OSM. -Bkil (talk) 12:51, 5 July 2021 (UTC)

I doubt that "shade=tree" is a mistagging of "covered=tree" (we have only 4 "covered=tree"). But shade=* and covered=* are somehow similar. So why not use them in a similar way as it was done? You can also express that the shade is temporary in some other way, perhaps with temporary:shade=*? (I am not sure if this can be used for properties too) --Hufkratzer (talk) 13:59, 5 July 2021 (UTC)

The phrase "many of the above may be mistaggings" means that some, but not all instances of some, but not all of the above key-value combinations were mistaggings. Are you familiar with the concept that I called progressive refinement above? It means, that both data consumers and mappers may decide how much time on their hands they have and they may choose to only specify something up to a certain precision, but they (or other mappers), perhaps based on better sources or some financing may decide to enhance precision by continuing to add further tags to refine the meaning. But in the process, the previously added, imprecise, categorical tags will also stay and remain searchable at a later time. -Bkil (talk) 14:24, 5 July 2021 (UTC)

Refinement in fine, but redefinition should only be done if there is some good reason to do it, IMHO. I don't understand the reason that "limited" has to be mixed between the other values or to move the values different from "yes" and "no" to "shade:caster=*"? --Hufkratzer (talk) 14:36, 5 July 2021 (UTC)

Well, this is all just brainstorming and it would be great if everyone shared whatever came to mind. Surely, we may only consider redefining and mass-editing of existing keys after we have discussed every possibility with the community and data users at large and after sending in a formal tagging proposal request. My thinking was that yes/no/limited is a common range of values of both lit=* and wheelchair=* (see taginfo), and in this case it is a range of values that I could add with confidence to a given longer stretch of road. Someone proposed on the list that we may specify a percentage as an approximation, but I don't that I could verify that with confidence. Also consider what our potential mappers could gather and what our potential data users would be and what they could utilize. If you are mapping a street in full 3D, you don't need this key at all. However, if you wished to include each and every instance of what casts the shadow along a footway (roof, tree/trees, portico/portic, pergola, building, etc) you would need to split the footway to many small pieces and would need to take much more photographs on your survey - effectively negating the ease of mapping and maintainability. The gain for a future router would also be comparatively small from a cost to benefit perspective. So, let's ask ourselves this question: what would be the *least* amount of work that we can do to deliver something usable by a router? -Bkil (talk) 22:22, 6 July 2021 (UTC)

The existing values probably come mainly from Proposed features/Shade. Proposed features/Shadiness is also relevant. I suggest Proposed features/Shade and its talk page is the best place to continue exploring this topic? --JoeG (talk) 03:27, 17 July 2021 (UTC)

I've now added three examples using hires aerial imagery for discussion at Proposed features/Shade --JoeG (talk) 05:52, 17 July 2021 (UTC)

direction

Someone on the local mailing list also proposed that we might indicate the general direction where the shading is mostly coming from in a given stretch. Like if a tree row does not cover a footway completely, but if lies just 1 meter from it to the East, it would provide cover before noon. Or if tall rise buildings lie beside the Eastern side of the road, but not the other side. Could this be indicated in shade:direction=* as per direction=*? Would this add value if no other value is present (like heights or density)? -Bkil (talk) 10:05, 5 July 2021 (UTC)

I think think this is the most promising way forward, but is worth developing as a proposal rather than adding directly to this page. Note that multiple directions and ranges would need to be permitted, and that the season could change whether shade is observed. --JoeG (talk) 03:27, 17 July 2021 (UTC)