iD tagging schema improvements - which would be especially worth doing? Which should be avoided?

it would be worth expanding a bit Key:ref:FR:SIRET - OpenStreetMap Wiki - currently it looks like one more pointless external reference added by badly done imports - not saying it is, but nothing indicates otherwise

if adding it is supported and done by French community and it is actually useful, it would be worth noting there

(French page mentions some use in Osmose, no idea is it more useful than a typical Osmose report - and nothing about whether adding it is supoerted by French community, though it has a lot of technical detail. Some may be also worth translating, like valid patterns.)

I admit that I am also not fan of it, though it never reached point where I bothered to make issue on issue tracker, investigate why it got added and how mappers feel about it.

(if anyone is invested into this enough enough to do this, feel free to do so)

It’s a well used sample even if superficial review might not show it. Every country/region has some that are useful for them.

The question is if such fields are easily possible or not. Given your answer, it’s doesn’t seem to be.

It is simply a safety policy issue. I’m not against introducing new tagging when the need is clear, there is no existing tagging (in this case there is only misused tagging), and it is done in the open (contrary to gaming the system). Yes I’m not particularly in love with it, but lets not redo the whole discussion.

PS: for what it is worth, the proposal would have easily been accepted at the time, with a lot more people weighing in than your typical tagging proposal.

1 Like

they are possible, but threshold is fairly high - Add `ref:mastr` field for power plant/generator presets by FloEdelmann · Pull Request #2250 · openstreetmap/id-tagging-schema · GitHub was latest addition.

In that case it was verified with Should iD show ref:mastr= when tagged on power plants and generators? [PR merged]

after someone from interested community wrote a pull request adding it

Thanks for the sample. From the diff, the changes seem straightforward . In the discussions/pages, I didn’t find any mention of potential uses, but from generator:method | Keys | OpenStreetMap Taginfo Germany this could be 300,000 features (currently 3700). Regrettably, they didn’t go for ref:DE:mastr .

Is there a way to limit it to areas below countries?

see id-tagging-schema/SCHEMA.md at main · openstreetmap/id-tagging-schema · GitHub

it is supposed to be possible, but it seems unused right now and there is an active proposal to remove it, see Replace locationSet `Q*` with regular country codes · Issue #1625 · openstreetmap/id-tagging-schema · GitHub

Interesting, it cross-references https://github.com/rapideditor/location-conflation which also has a possibility with a geojson file, us-nj.geojson in the sample.

id-tagging-schema/SCHEMA.md at main · openstreetmap/id-tagging-schema · GitHub limits it to “identifiers of regions” which I expect to exclude circles and geojson references

1 Like

For start, if someone is convinced that it is a good idea, issue proposing it can be created at Issues · openstreetmap/id-tagging-schema · GitHub (seems to not exist yet Issue search results · GitHub )

I am not really convinced (yet?), and plan to do via ferrata first (which has much more clear support and probably bigger safety issues from mapping it as highway=path and should be fine to add suport to just it for start).

From what I remember vote happened but not succeeded? (this does not mean that idea was bad or that it is blocked)

It seems to be present in the code id-tagging-schema/data/fields/ref/FR/siret-FR.json at main · openstreetmap/id-tagging-schema · GitHub but only displayed if it already has a value.

No, the vote was broken off/suspended/whatever (at a point where it would have succeeded).

2 Likes

With 41 for and 34 against it would not pass.

(From quick check at Proposal:Highway=scramble - OpenStreetMap Wiki )

It may have gained more support in the end, I agree with Simon that we might have seen a voting with much higher participation than usual.

I propose expanding the tag highway=proposed. Currently, a preset is available, but you can’t search for it. Also, it only has a name=* field, unlike the other highway=* values.

Another one that doesn’t always appear - opening hours?

& I noticed that you had phone:AU in the list? I thought that had been fixed as it’s working.

For which objects/tagging?

weird, it is not supported by tagging schema from what I see

where you see it working?

This is entirely deliberate, to discourage using it. highway=proposed is widely used in cases where it should be rather removed and should not be encouraged to be used more.

And having it as a searchable preset may mislead people into thinking that using it heavily and early and for very dubious routes is a good idea.

It’s very difficult to look at many suggestions from many users. Can you enable Discussions in Github? Eg SC has it.

in this case I treat it as opportunity for people who have no Github account for one reason to another to voice their needs, with me lifting ideas worth doing

not sure whether enabling discussions at Github would help with that (or anything else), for StreetComplete I am dubious whether it was worth doing - I have feeling that many go into void, I had plans to respond to some but now months later I see that it will likely never happen. I would not want this to repeat elsewhere.

then I see that you voted for “Replace querying taginfo by prefined lists wherever possible” of which it is subset

this specific field is annoying as values are orthogonal - as I understand denotation=urban would be “Tree in urban area, not covered by other values”

and how you are supposed to tag trees in avenue that are also for agricultural purpose?

or natural monument trees that are in avenue? (for bonus points, agricultural trees that are also in city)

EDIT: commented on Talk:Tag:denotation=urban - OpenStreetMap Wiki

1 Like