Validate `check_dates`, `source`, `note` and `fixme` related tags

[Dimitar5555]

check_dates, source, note and fixme are prefix tags, not suffix tags.

Any instances of *:check_dates, *:source, *:note and *:fixme should be flagged (the proper tags are check_date:*, source:*, note:*, fixme:*) surface_survey should be check_date:surface smoothness:date should be check_date:smoothness

[jajajaneeneenee]

A note: there is an ongoing proposal Proposed features/:note suffix which argues to change note to a suffix with some reasons (some language suffixes for note can cause conflicts/ambiguities in some rare cases if it's used as a prefix).

And the German wiki page for note even recommends using it as a suffix rather than a prefix! And the English wiki page for note for example doesn't say a word about it (the same with fixme). Some kind of confusing ...

Another note: I saw the tag "parking:note" serveral times in my region which causes already an Osmose warning because it's not a valid/common suffix like left|right|both. Seems to make sense.

[Dimitar5555]

A note: there is an ongoing proposal Proposed features/:note suffix which argues to change note to a suffix with some reasons (some language suffixes for note can cause conflicts/ambiguities in some rare cases if it's used as a prefix).

The "ongoing" proposal seems to be inactive for the past 7 months and most people who commented on it seem to disagree with it.

And the German wiki page for note even recommends using it as a suffix rather than a prefix! And the English wiki page for note for example doesn't say a word about it (the same with fixme). Some kind of confusing ...

It looks like this is a mistake since the text says that is should be a prefix. There are about 2.1k highway:note in Germany which is why I've created a topic on their community forum (https://community.openstreetmap.org/t/highway-note-in-germany-highway-note-in-deutschland/8776)

[jajajaneeneenee]

The "ongoing" proposal seems to be inactive for the past 7 months and most people who commented on it seem to disagree with it.

Yes, I know. But the author gave an answer to every comment. And I only wanted to inform about this proposal, not really supporting it ... but I can understand why it was written.

And the German wiki page for note even recommends using it as a suffix rather than a prefix! And the English wiki page for note for example doesn't say a word about it (the same with fixme). Some kind of confusing ...

It looks like this is a mistake since the text says that is should be a prefix. There are about 2.1k highway:note in Germany which is why I've created a topic on their community forum (https://community.openstreetmap.org/t/highway-note-in-germany-highway-note-in-deutschland/8776)

Not sure if I understand you correctly (or if you understood the German text correctly). The German text does NOT say, that note should be a prefix, but that other keys can be written as a prefix in front of note. (I just want to make that clear, nothing else.) Or do you mean another text with "the text"?

The sentence "Wenn man sich mit der Notiz direkt auf ein bestimmtes Attribut (z.B. highway=secondary) eines Elements bezieht, kann man dieses durch einen Doppelpunkt getrennt als Präfix vor note schreiben" means in English: "If the note refers directly to a specific attribute (e.g. highway=secondary) of an element, you can write this as a prefix before note, separated by a colon." – Therefore, there is no discrepancy between the sentence and the example highway:note! Conclusion: note is recommended as a suffix (as I already wrote). Perhaps this can help to make things clear in your posting to the community forum.

But one important question: can you provide a clear source for your statement "check_dates, source, note and fixme are prefix tags, not suffix tags." – especially regarding note? (Because I could not find a clear statement about that in the Wiki – which also surprised me a lot.)

[Dimitar5555]

Not sure if I understand you correctly (or if you understood the German text correctly). The German text does NOT say, that note should be a prefix, but that other keys can be written as a prefix in front of note. (I just want to make that clear, nothing else.) Or do you mean another text with "the text"?

The sentence "Wenn man sich mit der Notiz direkt auf ein bestimmtes Attribut (z.B. highway=secondary) eines Elements bezieht, kann man dieses durch einen Doppelpunkt getrennt als Präfix vor note schreiben" means in English: "If the note refers directly to a specific attribute (e.g. highway=secondary) of an element, you can write this as a prefix before note, separated by a colon." – Therefore, there is no discrepancy between the sentence and the example highway:note! Conclusion: note is recommended as a suffix (as I already wrote). Perhaps this can help to make things clear in your posting to the community forum.

My translator translates "Präfix" as "prefix". You've also translated it like that:

...you can write this as a prefix before note...

But one important question: can you provide a clear source for your statement "check_dates, source, note and fixme are prefix tags, not suffix tags." – especially regarding note? (Because I could not find a clear statement about that in the Wiki – which also surprised me a lot.)

Key:note:* Key:check_date

For fixme and source I used Taginfo: https://taginfo.openstreetmap.org/search?q=fixme%3A 10k+ uses on the first page https://taginfo.openstreetmap.org/search?q=%3Afixme ~4k uses on the first page

https://taginfo.openstreetmap.org/search?q=source%3A 50M+ uses on the first page https://taginfo.openstreetmap.org/keys/tiger%3Asource ~4M uses on the first page (ignoring generator:source and plant:source since they are actual tags)

[jajajaneeneenee]

My translator translates "Präfix" as "prefix". You've also translated it like that:

...you can write this as a prefix before note...

I there a misunderstanding on your side? Or are we talking past each other? The translation "Präfix" - "prefix" is correct, but the whole sentence and the reference of the word "prefix" is important in this sentence. Did you understand it correctly? I try to explain it again:

• "You can write this as a prefix before note" – "this" means other keys, which are a prefix in front of "note", like highway:note. So note is a suffix, not a prefix in this case and in the meaning of the sentence, although the word "prefix" is a part of the sentence. There should be no misunderstanding, it's quite clear. Do we both have the same understanding?
• So I think your OSM forum post is based on wrong assumptions about the German wiki text.
• My native language is German (for information only).

But one important question: can you provide a clear source for your statement "check_dates, source, note and fixme are prefix tags, not suffix tags." – especially regarding note? (Because I could not find a clear statement about that in the Wiki – which also surprised me a lot.)

Key:note:*

Thank you very much. I never saw that. It's from July 2022.... And a shame it's not mentioned on Key:note where I would expect it to be (at least under "See also", but better directly integrated). This is directly an example of bad information for mappers and bad Wiki editing.

Key:check_date

Check date is clear ... no questions about it. A good example, how to integrate it in the Wiki.

For fixme and source I used Taginfo: https://taginfo.openstreetmap.org/search?q=fixme%3A 10k+ uses on the first page https://taginfo.openstreetmap.org/search?q=%3Afixme ~4k uses on the first page

https://taginfo.openstreetmap.org/search?q=source%3A 50M+ uses on the first page https://taginfo.openstreetmap.org/keys/tiger%3Asource ~4M uses on the first page (ignoring generator:source and plant:source since they are actual tags)

I fully understand your point ... tiger:source is interessting, too ... I also think that it's better to use these keys as a prefix. But there seems to be a lot of confusion, I would suspect some source for that are editor preferences (e.g. to display notes for a key alphabetically under the associated key).

I saw some good examples for confusion when looking at the combinations of important keys with note at taginfo https://taginfo.openstreetmap.org/search?q=note: • note:maxspeed4172 – maxspeed:note4146 (almost a tie) • note:highway2758 – highway:note2171 (almost a tie) • note:access3415 – access:note 1178 (clearly less, but not extrem significantly less)

Sometimes, it's also useful to look at some curve charts which show the development of the usage numbers. Examples:

• access + note – both curves rise quite regularly (with a steep increase in note:access in 2021)
• highway + note – a very steep in increase of highway:note in 2017!
• Very interesting with maxspeed + note in 2013 + 2017!

I think one could or should argue more with the semantics behind the ":" syntax, which unfortunately is ambiguous if you look at the syntax only. But usually the first key in such a colon construct is the main key, so the values of the combination should also be common values of THIS key (that is, the prefix), and not the suffix. Examples:

• note:access is a note on an access key, values are texts up to 255 characters
• access:note would be an access condition for 'note', so should have usual values of 'access'. For example, if an object had the tag 'note=Some important information' and 'access:note=no', then that could mean at most that you are not allowed to read or edit the note, but basically it doesn't make any sense.

This is made very clear by other examples, e.g.: • bus:lanes=* (values are access values for the access key bus per lane, e.g. bus:lanes=yes|yes|designated • lanes:bus=* (values are lane values, i.e. a number, e.g. lanes:bus=1 – there is one bus lane)

If we had a more in-depth discussion, I'd generally criticize the limited prefix/suffix syntax (which can seem to confuse mappers, especially when other keys are referenced). Thus, expanding the syntax especially for these keys could eliminate confusion and misunderstandings. But I guess that's not going to happen – that would be too big a change. But here an example what I mean (of note):

• note:en[access;bus]=Some important information could be an english note for the keys access and bus of an object.

The same could be useful e.g. for check_date: • check_date[kitchen_hours;opening_hours;payment]=* could be a checkdate for kitchen_hours, opening_hours and payment of a restaurant (to express explicitly that only these things have been checked).

[jajajaneeneenee]

I forgot: the curve chart for tiger:source is interesting, too. But also a bit sobering ... http://taghistory.raifer.tech/#***/tiger%3Asource/

I would vote at once for more "mechanical" edits (not exclusively related to the tiger:source example) ... I think it's too much restricted (based on negative examples, which should be avoided of course). Unifying some things could really help save mappers' energies and free them up for other things. Currently, a lot of my mapping time is wasted by changing deprecated tags (without a mechanical edit) and I lose the fun of mapping, especially when I'm on the go.

[Dimitar5555]

I there a misunderstanding on your side? Or are we talking past each other? The translation "Präfix" - "prefix" is correct, but the whole sentence and the reference of the word "prefix" is important in this sentence. Did you understand it correctly? I try to explain it again:

You are right, I was reading through the lines.

• note:maxspeed4172 – maxspeed:note4146 (almost a tie)

2500 of maxspeed:note have the value "Oxford␣20␣mph␣zone"

• note:highway2758 – highway:note2171 (almost a tie)

Almost all instances of hihgway:note were added around 2017 and the edit in the German wiki was made on 24/01/2017 by T2425b. It seems like he also added most of the instances of this tag.

• note:access3415 – access:note 1178 (clearly less, but not extrem significantly less)

Most of access:note instances are also in German.

If we had a more in-depth discussion, I'd generally criticize the limited prefix/suffix syntax (which can seem to confuse mappers, especially when other keys are referenced). Thus, expanding the syntax especially for these keys could eliminate confusion and misunderstandings. But I guess that's not going to happen – that would be too big a change. But here an example what I mean (of note):

* `note:en[access;bus]=Some important information` could be an english note for the keys `access` and `bus` of an object.

The same could be useful e.g. for check_date: • check_date[kitchen_hours;opening_hours;payment]=* could be a checkdate for kitchen_hours, opening_hours and payment of a restaurant (to express explicitly that only these things have been checked).

Sounds like an interesting idea but a lot of people won't like the use of special symbols (square brackets).

I forgot: the curve chart for tiger:source is interesting, too. But also a bit sobering ... http://taghistory.raifer.tech/#***/tiger%3Asource/

That is because of the Tiger clean up that's ongoing in the US.

I would vote at once for more "mechanical" edits (not exclusively related to the tiger:source example) ... I think it's too much restricted (based on negative examples, which should be avoided of course). Unifying some things could really help save mappers' energies and free them up for other things. Currently, a lot of my mapping time is wasted by changing deprecated tags (without a mechanical edit) and I lose the fun of mapping, especially when I'm on the go.

We are on the same page but that's a whole different discussion. I think that it would be good to reduce the off topic since the discussion is getting quite lengthy.

[Marc-marc-marc]

imho this issue must be splited by key for source it's very clear that it's a prefix (I don't know if it's worth spending time on it as it should be on the changeset but if someone wants to do it, it's not a bad thing) but be aware that not all *:source are errors, e.g. generator:source here is a list of cases I've detected https://github.com/Marc-marc-marc/ansible-scripts/blob/taginfo/roles/taginfo/files/key-source-valide.txt