<div dir="ltr"><div dir="ltr">On Thu, 6 Feb 2020 at 05:06, Warin <<a href="mailto:61sundowner@gmail.com">61sundowner@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>It seems to me that the present use of the key damage=*, which has no documentation, would better fit into the life cycle system.<br></div></blockquote><div><br></div><div>If we need it to map damage all (I think we do) then we need both ways of doing</div><div> it, for the same reasons discussed some weeks ago regarding disused=* and</div><div>the disused: lifecycle.</div><div><br></div><div>We need both because they have different effects. They have different</div><div>effects because we need those different effects. I'll use "disused"</div><div> rather than "damaged" below to make the point clearer.<br></div><div><br></div><div>Lifecycle prefixes prevent rendering of the feature. They are equivalent to</div><div>deleting the feature tag and adding a note to the effect that the object is</div><div>a disused <whatever>. Except that the word "disused" might not appear</div><div>in the note and a synonym or circumlocution might be used instead. Having</div><div>disused:amenity=hospital allows database queries to pick out hospitals</div><div>(used or disused), disused hospitals, or functioning hospitals. Removing</div><div>the amenity=hospital tag completely prevents the object appearing in</div><div>queries for hospitals, or for disused hospitals.<br></div><div><br></div><div>Having disused=* doesn't prevent rendering. A disused water tower looks</div><div>like a functional water tower and is (usually) a landmark used for</div><div>navigation. Again, database queries can pick out water towers, disused</div><div>water towers and functioning water towers.</div><div><br></div><div>Is having two ways of doing it tagging for the renderer? No more than having</div><div>amenity=hospital or removing amenity=hospital. One renders the object</div><div>as a hospital and the other does not: the mapper chooses based upon what</div><div>the object is. Objecting to a mapper being able to decide whether it</div><div>is rendered as a hospital or not means objecting to being able to tag</div><div>a POI in any meaningful way.<br></div><div><br></div><div>Isn't it recording history and OSM doesn't do that? It serves two purposes:</div><div><br></div><div>1) QA. A formalized way of telling other mappers that no matter what the</div><div>POI looks like in aerial imagery, street-level imagery or a drive-by, the object</div><div>isn't what it appears to be. A note could do that, but is opaque to database</div><div>queries ("former hospital," "was a hospital," "no longer a hospital," etc.)</div><div><br></div><div>2) A formalized way of telling data consumers who query the POI that it</div><div>isn't what it appears to be. Don't hang around that church you spotted and</div><div>wait for it to open up so you can have a look around, it's disused.</div><div><br></div><div>Will all renderers honour those interpretations? Probably most will. It's</div><div>easy to not render tags with lifecycle prefixes by simply ignoring them</div><div>as being unknown. It's easy to render tags with disused=* by ignoring</div><div>"unknown" tags. A renderer would need extra code and have to be</div><div>somewhat perverse (IMO) to render tags with lifecycle prefixes or<br></div><div>not render POIs with disused=*. We can probably rely upon these</div><div>behaviours for most renderers.</div><div><br></div><div>There are two ways of doing it, and ithat's a good thing. <br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>