Historic=yes ...

General talk
1

I cannot understand why this article mentions ; “The form historic=yes has been used in the past, and implies that the type of structure is defined elsewhere. This approach is best avoided, because of the difficulties involved in reliably deriving the type of structure from other tags.”

‘defined elsewhere’ ? … :roll_eyes:

historic=yes is simple and good in my opinion …
Take for example boundary=marker, … when one can simply add historic=yes, when the marker is ‘historic’ , then there is no ‘discussion’ when there are ‘modern’ boundary markers involved , isn’t it ?

2

It means that it’s only a modifier to whatever other tags are, but compared to a lifecycle prefix (or similar prefixes) doesn’t tell which one it applies to, which is imprecise.

A (stupid) exaggerated example, because I can’t make up anything sensible on the fly:

There’s a cafe which has been a (famous or significant for some historical reason) post office.

So, you can’t describe such situation with historic=yes, because you won’t know whether it applies to cafe or post_office, not to mention a conflict of the amenity key in this example.

3

OK, tnx, so the key historic=yes is ‘good to go’ then … but without ‘your explanation’ above , it is rather ‘confusing’ on that article-link … :roll_eyes:
Also , historic=boundary_stone should be ‘abandoned’, because even Lübeck 's map no longer updated with it …
Also, the key:historic is rather ‘useless’ if one can simply add ‘historic=yes’ to a ruin/cannon/castle/and all the other values of ‘key:historic’ … isn’t it ? :roll_eyes:

4

this is still rendered here…

No, as RicoElectrico said, you can’t simply add historic=yes to achieve the same effect.

5

RicoElectrico said ; “There’s a cafe which has been a (famous or significant for some historical reason) post office.
So, you can’t describe such situation with historic=yes, because you won’t know whether it applies to cafe or post_office, not to mention a conflict of the amenity key in this example.”
… i thought that we only have to map ‘the present things’ , and NOT what was in the ‘past’ … so, i do not comprehend any ‘difficulties’ about my ‘reasoning’ … :roll_eyes:

6

It’s perfectly possible to have an amenity and a building mapped as one object. One may be historic, one not.

7

It is also then perfectly possible for that one object to map it as amenity, and to add building=yes and historic=yes … isn’t it ? … Better though ; … key:object , and add amenity=yes and historic=yes and building=yes :stuck_out_tongue:

8

So how do you know if the amenity or the building is historic?

In fact, taking a step back, what are you actually planning to map with the “historic” key anyway?

9

so how does anybody who maps something as ‘historic’, knows that the ‘thing’ he/she is mapping, is ‘historic’ ?
In such rare cases isn’t it is possible to ‘separate’ those 2 with some kind of ‘note’ or something ?

I am not planning anything specifically to map with that ‘ancient’ historic key … all i want to say is ; ‘keep it simple’ , and in my opinion, almost all ‘features’ can be ‘replaced’ with key:object(or something) . For example ‘barriers’ … key:object and then add barrier=yes and add than also (for example) bollard=yes or kerb=yes or bump gate=yes … and so on … simple … isn’t it ? :wink: … though osm people rather like to make it not so easy … :stuck_out_tongue: