Sub-regions, repeated data and .geojson hosting

[UKChris-osm]

To be honest, I'm not sure where would be best to ask about this, either here, location-conflation or the Name Suggestion Index, so apologies if this isn't relevant here.

Basically, over on the Name Suggestion Index, there is a /features/ folder that I've expanded recently, and it contains .geojson files for mapping certain areas that a brand should be limited to, and this is powered by location-conflation and seems to work well.

However, I've noticed that the osm-community-index has the same concept, with a /features/ folder linking areas where an OSM community group is based.

Within both projects are similar region files, and I can see both projects expanding with similar data. One example being the West Midlands in England (NSI vs OCI) which is basically the same region.

I imagine other projects exist (or will exist) with the same goal of having sub-regions where the .geojson files are similar.

I gather that this project (country-coder) doesn't intend to expand into sub-regions, so as to prevent it becoming too large, and I can understand that.

However, is there any scope for hosting sub-region .geojson files within the repository (or location-conflation) so there is a central place for users to reference the region files, without having to recreate them for their own project?

[bhousel]

We have the following projects which work this way now:

• osm-community-index (probably has about as many custom geojsons as it needs)
• name-suggestion-index (potential for many custom geojsons)
• id-tagging-schema (needs few if any custom geojsons)
• and then there's background imagery 🤣 the less we say about that, the better.

I'm ok with just leaving the features/ folders in the separate projects for right now, without trying to establish a central place for them. Each project should just bring the minimal amount of geojsons that it needs. The goal is to ship less stuff with core iD, then pull it in only as needed. I'm not too worried about duplicating kilobytes of geojson. iD is already pretty data heavy, but most of that cost comes from downloading geodata from OSM and imagery tiles from wherever.

We also use a few tricks on the iD side to work with data when the browser is idle. For example, the community index gets downloaded and setup in the background while the user is either preparing their changeset comment or waiting for the upload to finish - so even if it got bigger or had redundant data in it, nobody would notice.