For `flood_probability` to be useful and verifiable in some way, there should be a link to the source in the changeset, or perhaps also source: flood_probability= on the object.
Such statistical features like "1% risk of flood per year" can't really be verified by individual mappers, since they are based on calculations of the floodplain geometry and historical observations of floods over many decades. So it's probably more useful to have these mapped in official sources which are kept up-to-date, rather than importing the data from the external source into OSM, and then having to maintain it in our database. I agree that if there is a sign that says "this area prone to flooding", then "flood_prone=yes" is verifiable and helpful to add, since that's representing a feature that can be checked when the area is next survey. On 9/1/19, Paul Allen <pla16...@gmail.com> wrote: > On Sun, 1 Sep 2019 at 05:24, Warin <61sundow...@gmail.com> wrote: > > You could add flood_prone=yes to the car park tag but that will show the >> whole car park as affected, whereas it's only the bit down this end that >> has a problem. Would drawing a separate area & marking that as >> flood_prone=yes work? >> > > Better than nothing. If you feel adventurous, you could try mapping it as > two, non-overlapping, > constituent areas of a multipolygon and see what happens. > >> I asked this question some time ago. I was told it was not verifiable and >> therefore not for OSM. >> > > My opinion is that if there is signage/road markings it's verifiable and > mappable. When we > map the speed limit of a road from signs the only actual, verifiable > information we have is > the presence of the sign, but we assume the sign is true and infer the > speed limit of the > road from it. Same thing here: sign says it's prone to floods so we infer > the place is prone to > floods. > > Where I differ from some is that I'd consider official documents also > providing verifiability > provided their copyright permits it. > > However there is the question of frequency, once in 10 year event, once in >> 100 etc. So I would add a sub tag or value about frequency of the event.. >> The key frequency is already in use. Period has some use too, though the >> use looks to be years.. no wiki to say what it is? >> > > Period is the multiplicative inverse of frequency: normalize the units, > multiply them together > and the result should be 1. Neither is appropriate in this case. A > once-in-100-year event > does not occur at 100 year intervals, it has a probability of 1% of > occurring (technically, > being equalled or exceeded) in any given year. > https://en.wikipedia.org/wiki/100-year_flood > So we should be tagging a probability. Technically, exceedance probability > for floods. > > Taginfo shows floodplain_probability used 77 times. Is that sensible? > It's a floodplain or it isn't. > Also flood_probability 4 times (better) and hazard:probability once. The > flood_probability value > in taginfo is "100y" rather than 1%. People who used > floodplain_probability divide into those > who expressed a large number like 100 (probably meaning years) and those > who expressed > a small number like 1 or 0.5 (probably a percentage). The only value for > hazard:probability > is "low" (which I consider to be effectively meaningless). > > I dislike floodplain_probability because it IS a floodplain with a > probability of being > flooded, not a probability of an area being classified as a floodplain. > Also because > it's been given both in terms of years and percentages (except it's > impossible to be sure > because nobody has given units, so maybe the 100 means it's 100% likely to > flood and > the 0.5 means it is likely to flood every six months). It's a mess. > > I'm fairly happy with flood_probability. There's something nagging at the > back of my > mind saying I ought to be unhappy with flood_probability, but it's not > telling me why. > > I like hazard:probability, especially if we document that it should be > tagged as a > percentage (and ignore or fix the sole value of "low"). Only problem with > it is that > hazard=* is a proposal from 2007 that is supposedly still active, so we'd > have > to do something about hazard=*. Then again there is hazard_prone=* and > hazard_type=* which seem to have appeared in the wiki without a proposal > and have a few thousand uses. > > -- > Paul > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
