Unique Operator / Brand ID's

[UKChris-osm]

Having gone through many of the UK entries in the NSI over the last few months, I've noticed more and more I seem to be repeating myself with certain entries under the operator tree, namely local councils who operate multiple assets, such as school's, parks, recycling, car parks, charging stations, etc.

This means many files have the same operator name / wikidata entries spanning multiple files, so is there any scope for creating a master operator file, which could just contain the raw operator information (name / wikidata / location set) which then has a unique ID created for it, at which point this unique ID could then be referenced within any asset file.

For example:

master-ops.json

{ "displayName": "Somerset West and Taunton Council", "id": "mas-op-somersetwestandtauntoncouncil", "locationSet": { "include": ["gb-som.geojson"] }, "matchNames": ["sw&t", "swt"], "note": "ISO 3166-2:GB - gb-eng (England) , gb-som (Somerset)", "tags": { "operator": "Somerset West and Taunton Council", "operator:type": "government", "operator:wikidata": "Q54554249" } }

/operators/amenity/parking.json

{ "ref-id": "mas-somersetwestandtauntoncouncil", "id": "somersetwestandtauntoncouncil-6e1dc7", "tags": { "amenity": "parking", } }

/operators/leisure/park.json

{ "ref-id": "mas-somersetwestandtauntoncouncil", "id": "somersetwestandtauntoncouncil-09986d", "tags": { "leisure": "park", } }

I feel like this would allow the raw operator data to be maintained in a canonical way (i.e. prevents misspellings across multiple files) as well as makes any edits easier (if an operator changes its name or working area for example) as well as making it easier to add pre-existing operators to new data files.

I also think the above method allows for tag overriding should the need arise.

[bhousel]

I'd like this too, but I'm thinking it would be more for the future, like what a NSI version 7 might look like.

This project was originally built a long time ago with its only goal to generate iD presets for brands (even back before we started adding Wikidata tags and matched only name tags), so that's why a lot of it looks the way it does. It would make more sense now to build a more flexible tag matcher combined with our already flexible location matcher and use those things to define the rules where all this stuff in the world is valid.

The other difficult thing is that - it's almost impossible to get things changed in iD itself anymore. Most people know this but, I maintained that project for many years, and then the OSMF removed me from it in 2020 and has been shuffling the maintainership position around between different people who aren't really as committed to the project as I was.

This has real effects on NSI unfortunately - an issue like #6552 is a one line fix! But actually getting that fix into iD seems impossible now, and if I bump the version of NSI then iD won't pick it up the data files anymore.

So some of these "good ideas" are going to have to wait a while until we can get unblocked by having me back in the maintainer position, or maybe there's a future where RapiD replaces iD as the editor people use.

But for now, if it involves any code change in iD or any change in the structure of the NSI data that we publish, it's going to have to wait a while.

[bhousel]

If i'm reading it right, this is also same as #6143 - the idea that one operator can really be tagged on many different kinds of features, so it has gotten redundant for us to try to record every kind of feature that they operate.

[UKChris-osm]

But actually getting that fix into iD seems impossible now, and if I bump the version of NSI then iD won't pick it up the data files anymore.

Really? I thought NSI had become independent from iD? So our updates were published and iD would always get the latest publish file without iD itself needing an update?

[bhousel]

So our updates were published and iD would always get the latest publish file without iD itself needing an update?

For data files, yes it will pick up the latest v6.0.x.

For the code that reads those files, no. If we change the matcher or change format of the files, I would have to make a change there too.

[peternewman]

Can't we workaround this with a pre-processor though?

Given the other users of NSI, presumably we don't want to change the actual output presets if we can help it, as people using the JSON rather than the library ( https://github.com/osmlab/name-suggestion-index/#readme ) will need to rewrite their code.

But if we stored it as @UKChris-osm proposed, we could produce an NSI v7 output, in that raw format, and a backwards compatible NSI v6 which uses the ref-id as a lookup to a template to populate the actual fields.