Hi,
hier fehlen die Tags an der Relation:
relation/20044848

Hi Robert,
wouldn't it be better to replace those "old school" "distance:Nelson Monument" tags with a more modern tagging that doesn't use free text in the key? This would do the job - and at the same time also keep the order of entries on the milestone:

destination = A City; B Village; C Place
distance = 10 mi;2 mi;234 mi

Using 'destination' on a milestone seems appropriate to me, even though it's not a guidepost pointing in the right direction...

In einem Value ist das auch weniger ein Problem, aber für Keys nicht geeignet.

Meiner persönlichen Meinung nach gehört das ohnehin gar nicht in den Key. Lieber in einer sauberen, nummerierten, maschinenlesbaren Form inklusive eindeutigem Link zu wikidata:

railway:name:1
railway:ref:1
railway:operator:1
railway:operator:1:wikidata

Wenn aber ein Name im Key erwünscht ist, dann so kurz wie (eindeutig) möglich, aber mit Leerzeichen durch Unterstriche ersetzt und ohne Semikolons.

Und als letztes Argument möchte ich erwähnen, dass diese Tags am Knoten eigentlich gar nicht nötig sind: Ich brauche nur auf die beiden anschließenden ways zu sehen um diese Information zu bekommen.

Hi,
could you check this node, it got no proper tags:
node/13429412538

Hi,
'gbt' is not a socket type, but a standard defining many sockets. Please check the precise type - I guess it is "gb_dc".

Hallo,
du hast hier neue "railway:name:xxxxxxxx" mit sehr langen Namen inklusive Leerzeichen und Sonderzeichen verwendet. Diese sollten in Keys generell nicht auftauchen. Könntest du das bitte ändern?

Andere "railway:name:XXX" keys verwenden kurze Akronyme, siehe hier: https://taginfo.openstreetmap.org/keys/railway%3Aname#similar

If that's not the source, the tag should not be added. On the original building the source was correctly given in the changeset. When you set it to 'demolished', you added the tag, which you claim was not the source - which means it's wrong and shouldn't be there.

Thanks for the information!
How about this full set of descriptive tags?

tourism=information
information=route_marker
material=brass
height = 0
support = ground
ref = XXX
operator = Thornbury & District Museum
name = Thornbury Heritage Trail
url = https://www.thornburymuseum.org.uk/wp-content/uploads/Heritage_Trail_Guide_for_website.pdf

Hi,
I found 15 nodes with the key "southglos:heritagetrail"
node/4751832643

What do they represent? A board with information? trail blazes?

Hi,
when you're checking these bus stops, could you also update the tagging? 'lines' is deprecated since several years and should be replaced by 'route_ref'.

Hi,
hast du noch eine Ahnung was diese Tags an den Masten hier bedeuten? In 12 Jahren hat das wohl niemand nach dir noch getagged...

node/2296882665
2dcode
Dreieck
Kreis
Quadrat

(+1 to what Manuel wrote)

For huge features like this that partially can reuse existing objects like ridges, tags on the ways are not really helpful and all tagging should be on relations. If this is type=watershed (which is mostly used in a different sense), but e.g. here for the alpine divide: relation/14461262
Or another type like 'drainage_divide' or 'water_divide' can be discussed / propose.

Hi,
please don't invent new tags just to "silence JOSM warnings". watersheds are being mapped since more than 15 years without the need for such a tag.

These ways are part of a proper relation with an at least documented type. That should be perfectly sufficient to just ignore warnings of an imperfect validator.

You write "used to provide a link for a source:geometry" - but this is exactly the definition of "source_ref".

cited from the wiki: "In contrast to source=*, which holds a description of the source of data, source_ref=* is used to link to an external source of information. "
source_ref=*

"*:link" tags are rarely used and not documented, 'source:geometry:link' isn't used at all up to now.

There are ways with tags like "6 = 4" or "6=5"

"boundary" doesn't necessarily mean "administrative boundary":

boundary=statistical

I'd argue it is a boundary and should have regular boundary tags, no matter what a validator says.

'lanes:bus:backward' already says that there is a lane for buses. Without further tags, there is no reason that it is not 24/7.

The current tagging scheme is with explicit access tags:

access:lanes:backward = no|
bus:lanes:backward = designated|

and, if bicycles share the lane:

bicycle:lanes:backward = yes|

What has been lost? A road that is open at all times doesn't need an additional tag stating this.

Additionally:
- 'busway' is deprecated and shouldn't be used anymore

- 'opposite_lane' only makes sense in combination with a oneway road

- "opening_times" is a key that doesn't exist at all - a bus lane that exists for a limited time would be tagged as
lanes:bus:conditional = 1 @ Mo-Fr 08:00-16:00

Hi,
I wonder what the reason is to use "is:boundary" instead of "boundary"?