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

[mail at marcos-martinez.net]

Hi everybody, 

Although I understand the desired outcome of such a tagging scheme I
honestly think it is senseless trying to implement it due a huge amount
of parameters each of which can be decisive: Moment of the day, moment
of the year, exact location on the globe, height, density and width of
all potential shade-providing elements (buildings, trees, street lamps,
covered bus stops, hills etc). 

I am aware there is no easy solution but imho it would make more sense
to create some kind of 3D model outside of OSM which calculates shade
based on existing OSM data instead of adding a tag that is hardly
capable of reflecting reality. 

Cheers, 

Marcos 

Am 13.07.2021 08:54, schrieb Mateusz Konieczny via Tagging:

> 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 is doomed to failure. 
> 
> I would consider using summer_midday_shade=* if you tag that. 
> 
> 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. 
> 
> Using shade=* for just summer midday shade will end in a miserable confusion. 
> 
> Jul 7, 2021, 01:17 by bkil.hu+Aq at gmail.com:. 
> 
> - lamps put light in one direction, not 
> subject of rotation like most shades are 
> 
> You are again not focusing on the problem at hand and what the 
> customer (map user) wants and what an MVP means.

Proper MVP is either throwaway prototype or extendable. 

shade=* tagging is not fitting either one, and I prefer to stop 
it before it spreads like other clearly bad ideas such as 
https://wiki.openstreetmap.org/wiki/Key:class:bicycle 

>> Mapping shade=* would require unusually 
>> complex conditional syntax and ridiculous way splitting.
> 
> It would not make sense to add it to such a level of detail. This was 
> only considered as a time saver approximation.

The problem is that in this case such approximation is not viable for 
most of cases as shade is changing far more than other properties 

> Also, if you are unsure, just don't map it. If it is clear that a 
> given path is never shade in the summer months around noon, why not 
> put something like shade=no on it?

Because it may be shaded for entire morning or entire afternoon, 
as trees/buildings are on one side of it? 

While other path is not shaded at all? 

> If trees completely cover a given 
> stretch of footway and provide shade during summer months for many 
> hours around noon, why not put something like shade=yes on it?

That is viable in isolation but people will try to use shade=* for a bit
trickier 
cases, this will fail and we will have one more broken tagging scheme. 

> What if several possible paths/sidewalks/cycleways exist in the same 
> area and long stretches of them can be easily compared in some cases 
> and in case of one being clearly inferior, mark it with shade=limited?

And as soon as you will have different context competing 
(as this kind of info will be especially useful for cyclists/hikers,
including 
long-distance cyclists/hikers) then it will start being problematic. 

> In many company cultures (and many open and volunteer communities) 
> many code of conduct contain clauses to the effect of "trust your 
> peers that they can make educated decisions for themselves as the 
> mature adults they are". We are intelligent humans. Please trust 
> mappers that they can make usable decisions in fuzzy situations - this 
> is what differentiates us from robots. The map is made by humans for 
> humans.

Yes, but tagging schemes need to be properly designed. 
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. 

>> For what? In case of shade from buildings 
>> where shade depends on time of year 
>> and day I am curious how you would even 
>> tag using it with shade.
> 
> Not sure where you live, but in this region, heat is only problematic 
> in very specific months and very specific hours of a given day.

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. 

>> In my area deciduous trees, changing 
>> sun location etc result in shade changing 
>> massively during year.
> 
> In my area, in the few months of the warmest part of the summer where 
> shading matters at all in real life, the sun shines in a well defined 
> angle and deciduous trees have their foliage on. I would be surprised 
> if you lived on a planet where this goes differently.

In Poland sun rises in East* and sets in West*, with angle changing as
day progresses. 

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

It sounds like you want to map summer_midday_shade=*, not shade=* that
sounds 
more reasonable and less misleading. 

* Southern-East and Southern-West to be more exact, with exact position
changing 
as year progresses. 

>> Tree size should be estimatable by measuring 
>> it's trunk diameter and species.
> 
> I've surveyed thousands of trees around the area, so I know exactly 
> how much work it is. It is unfeasible even for me, let alone laymen 
> mappers to do this.

I am not arguing that it is feasible, I am arguing that it is more
feasible 
than shade=* 

And using shade=* for "summer midday shade status" may it more 
feasible but it is making it misleading at least. 

> The godfather of the iD editor called me names 
> some years ago when I suggested that it should be possible to add the 
> taxon or at least the genus of a tree, reasoning along the way that 
> mappers aren't smart enough to tell apart an apple tree from figs (and 
> if some of them can, they should be denied the possibility to mark it 
> anyway just because).

¯\_(ツ)_/¯ 

I see no reason to treat it as a good reason for not mapping it. 
(I also had some disagreements with iD authors) 

> Also, I'm not sure if you ever had a garden or been to one

I am not wealthy enough to own garden but I visited several. 

> towns or gardens where they trim trees (basically in many urban 
> areas), the trunk diameter keeps growing annually, but the height and 
> the number of branches and the volume of foliage stays approximately 
> the same every year (along with its cast shadow). I'd say at least 
> half of urban trees are trimmed as a method of precaution. My 
> botanical observation tells me that weather, the genetic makeup of the 
> given individual, its health and life record can cause a lot of 
> variance in crown diameter and foliage density (along with accidents 
> in the past and trimming patterns), so I think the approximation based 
> on the trunk would only be useful in the wild and in a statistical 
> (population) context, not for such micromapping.

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

>> Mapping approximate height of building 
>> can be done by surveying. 
>> See StreetComplete
> 
> How many towns have you yourself drawn on an empty map, encircling 
> every structure and then walking through every street and adding the 
> height and shape of every building and fence?

Zero, as I started mapping where Poland was not a blank map. 

> We regularly organize 
> parties over here where many do this, I have drawn towns from the 
> ground up and many 3D stuff, so I know exactly how much work it is (a 
> lot, hence I prefer not to do that any more). I see you have lots of 
> edits (mostly single changes, though, so I can't feasible review 
> them), but I don't know how much 3D you have done.

I also know this, my city still has several thousands StreetComplete
quests 
and solving more than 50 000 of them is only small part of that. 

Around 15 000 were about building detail and most of that in Kraków. 

> What you must understand is that unless you come over here and fill in 
> the map for us, it will never contain the needed information to a high 
> enough coverage that would make a service usable based on that. I 
> would guess that the situation is the same for most parts of the world 
> (especially where people walk and finding shade matters at all).

the same goes for shade=* 

If you want to map just midday summer shade then using 
summer_midday_shade=* seems much better tag that would be far less
confusing. 

> Hence you are basically saying that "if you can't do it 100% 
> precisely, don't do it!" or "you're either doing overtime and do it my 
> way or it's the highway!". This is toxic to the community.

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. 

> Volunteering does not work like that. The world does not work this 
> way. People have needs, there are many viable and useful solutions to 
> their problems, and people will definitely solve their problems one 
> way or another if they need to be solved.

Though it is useful to solve problems in way that makes sense. 

> It simply does not cut it 
> that naysayers say that they should not solve their problems.

I am not saying that, just saying that solution as presented and 
understood by me is doomed to failure. 

> Still easier than mapping whether it shades 
> road depending on time of day and year. But how common is it that one would have all required data? 
> More likely than mapping shade= in way 
> that would actually work given that 
> shade changes during day 
> Single 10 storey building would require 
> footways split every 10cm around it 
> (towards East, West, North from it) 
> or such shade=* tags would be useless. 
> That sounds like horrific idea that should 
> be considered as ridiculous, unusuable, 
> not worth encouraging and bad idea.

Yes, I agree that your recommendation is ridiculous and unusable. Lots 
of straw man arguments here - I'd prefer if we wouldn't do that. 
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. 

I would consider using summer_midday_shade=* if you tag that. 

> We have none of this data available in the whole country as I have 
> already stated, and I have shared a possible way of approximate 
> surveying that takes a similar amount of time as adding interpolated 
> house number ranges - stopping for a minute at each street corner. 
> There could exist other approximations and many others ways to tag 
> such approximation as well. 
> 
> It was suggested on our local list that even an average percentage or 
> expected probability of shade could be marked per longer stretch of 
> path. I think that would be more difficult to verify exactly, but this 
> also shows that we could come up with lots of useful methods for 
> approximation if we really put some effort and a positive attitude in 
> it together. 
> 
> _______________________________________________ 
> Tagging mailing list 
> Tagging at openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging

>> - in case of placing lamps the goal is of 
>> making entire stretch of easy lit, 
>> something else happens in case of some 
>> weird plans or deep incompetence
> 
> Imagine that endangered trees can be protected in many places, so 
> trimming them is not allowed and they can thus grow unhindered. On 
> installation, the lamps provided enough light everywhere, but in a few 
> years, even the growth of a few branches that took a wrong turn could 
> block a significant portion of light.

As mentioned, way splitting may be necessary in case of incompetently 
placed street lamps mismatching the situation 

_______________________________________________
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/20210713/9d0f9afd/attachment-0001.htm>