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

Wed Jul 14 11:15:40 UTC 2021

+1
Sorry, but I see this as a fairly pointless activity, which will consume a great deal of somebody's time to no real advantage.
IMHO OSM should stick to mapping things that are at least fairly permanent and verifiable.  Shade is far too ephemeral.
Regards,Peter

    On Tuesday, 13 July 2021, 17:21:29 BST, mail at marcos-martinez.net <mail at marcos-martinez.net> wrote:  

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 dayand 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 shadeafter 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, notsubject of rotation like most shades are
 You are again not focusing on the problem at hand and what thecustomer (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 stopit before it spreads like other clearly bad ideas such ashttps://wiki.openstreetmap.org/wiki/Key:class:bicycle 

Mapping shade=* would require unusuallycomplex conditional syntax and ridiculous way splitting.
 It would not make sense to add it to such a level of detail. This wasonly 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 agiven path is never shade in the summer months around noon, why notput 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 givenstretch of footway and provide shade during summer months for manyhours 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 trickiercases, this will fail and we will have one more broken tagging scheme.
What if several possible paths/sidewalks/cycleways exist in the samearea and long stretches of them can be easily compared in some casesand 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, includinglong-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 yourpeers that they can make educated decisions for themselves as themature adults they are". We are intelligent humans. Please trustmappers that they can make usable decisions in fuzzy situations - thisis what differentiates us from robots. The map is made by humans forhumans.
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 aslarge 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 buildingswhere shade depends on time of yearand day I am curious how you would eventag using it with shade.
 Not sure where you live, but in this region, heat is only problematicin very specific months and very specific hours of a given day.
Poland. Shade is useful both in winter (where some would ratheravoid it, but it is not so important). Shade would be desired by at least some cyclists/hikers/pedestriansin summer months, often across the entire day.

In my area deciduous trees, changingsun location etc result in shade changingmassively during year.
 In my area, in the few months of the warmest part of the summer whereshading matters at all in real life, the sun shines in a well definedangle and deciduous trees have their foliage on. I would be surprisedif 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 soundsmore reasonable and less misleading. * Southern-East and Southern-West to be more exact, with exact position changingas year progresses.

Tree size should be estimatable by measuringit's trunk diameter and species.
 I've surveyed thousands of trees around the area, so I know exactlyhow much work it is. It is unfeasible even for me, let alone laymenmappers to do this. 
I am not arguing that it is feasible, I am arguing that it is more feasiblethan shade=*  And using shade=* for "summer midday shade status" may it morefeasible but it is making it misleading at least.
The godfather of the iD editor called me namessome years ago when I suggested that it should be possible to add thetaxon or at least the genus of a tree, reasoning along the way thatmappers aren't smart enough to tell apart an apple tree from figs (andif some of them can, they should be denied the possibility to mark itanyway 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 urbanareas), the trunk diameter keeps growing annually, but the height andthe number of branches and the volume of foliage stays approximatelythe same every year (along with its cast shadow). I'd say at leasthalf of urban trees are trimmed as a method of precaution. Mybotanical observation tells me that weather, the genetic makeup of thegiven individual, its health and life record can cause a lot ofvariance in crown diameter and foliage density (along with accidentsin the past and trimming patterns), so I think the approximation basedon 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 buildingcan be done by surveying.See StreetComplete
 How many towns have you yourself drawn on an empty map, encirclingevery structure and then walking through every street and adding theheight and shape of every building and fence?
Zero, as I started mapping where Poland was not a blank map.
 We regularly organizeparties over here where many do this, I have drawn towns from theground up and many 3D stuff, so I know exactly how much work it is (alot, hence I prefer not to do that any more). I see you have lots ofedits (mostly single changes, though, so I can't feasible reviewthem), but I don't know how much 3D you have done.
I also know this, my city still has several thousands StreetComplete questsand 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 inthe map for us, it will never contain the needed information to a highenough coverage that would make a service usable based on that. Iwould 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 usingsummer_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 myway 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 causeclearly visible problems in the future. I was in position of saying to people "this mapped data is useless, astagging scheme is fundamentally pointless/broken/useless" or seeing it,so I think that it is valuable to mention clear problems before massive workwill be put into it.
Volunteering does not work like that. The world does not work thisway. People have needs, there are many viable and useful solutions totheir problems, and people will definitely solve their problems oneway 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 itthat naysayers say that they should not solve their problems.
I am not saying that, just saying that solution as presented andunderstood by me is doomed to failure.

Still easier than mapping whether it shadesroad 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 waythat would actually work given thatshade changes during daySingle 10 storey building would requirefootways split every 10cm around it(towards East, West, North from it)or such shade=* tags would be useless.That sounds like horrific idea that shouldbe considered as ridiculous, unusuable,not worth encouraging and bad idea.
 Yes, I agree that your recommendation is ridiculous and unusable. Lotsof 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 dayand 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 havealready stated, and I have shared a possible way of approximatesurveying that takes a similar amount of time as adding interpolatedhouse number ranges - stopping for a minute at each street corner.There could exist other approximations and many others ways to tagsuch approximation as well. It was suggested on our local list that even an average percentage orexpected probability of shade could be marked per longer stretch ofpath. I think that would be more difficult to verify exactly, but thisalso shows that we could come up with lots of useful methods forapproximation if we really put some effort and a positive attitude init together. _______________________________________________Tagging mailing listTagging at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging

- in case of placing lamps the goal is ofmaking entire stretch of easy lit,something else happens in case of someweird plans or deep incompetence
 Imagine that endangered trees can be protected in many places, sotrimming them is not allowed and they can thus grow unhindered. Oninstallation, the lamps provided enough light everywhere, but in a fewyears, even the growth of a few branches that took a wrong turn couldblock a significant portion of light.
As mentioned, way splitting may be necessary in case of incompetentlyplaced street lamps mismatching the situation 
_______________________________________________
 Tagging mailing list
 Tagging at openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
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/bf3de919/attachment-0001.htm>