Wrong data in json but correct data in contributions folder

[timkolloch]

Hey guys I am a bit confused by the data.

In a program I am using I noticed that for example the city of Arrecife on the Canary Islands has a wrong location set. I tried to confirm that looking at the json here by searching for Arrecife. The location given in that file is wrong as the longitude misses a "-". However when I look at the contributions folder in the ES.json the data is correct.

How does that work?

Best wishes!

[dosubot[bot]]

Hi @timkolloch! I'm Dosu and I’m helping the countries-states-cities-database team.

The main JSON file (states+cities.json) is generated from a central MySQL database, which is updated from the contributions folder through an automated process. When someone corrects or adds data in the contributions folder (like ES.json), those changes are not instantly reflected in the main JSON export—they appear after the next automated export cycle runs. This means the contributions folder can have the latest fixes, while the main JSON file may lag behind until the automation updates it. The export automation is running regularly and should pick up recent corrections in the next cycle, so you don’t need to take any extra steps unless you notice a long-term delay or a problem with the automation itself.
See export workflow details and recent export activity
How contributions are merged and exported

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[timkolloch]

@dosu I do understand that but according to the dataset the ntry for Arrecife was last update on 12/02/2025 while the last database export was done on 12/13/2025 which is why the export should already have the data if I understand correctly

[dosubot[bot]]

The export process doesn't automatically pick up changes from the contributions folder—exports only update when a maintainer manually triggers the workflow. So, even if the Arrecife fix was merged before 12/13/2025, the main JSON export won't reflect it unless someone ran the export after the merge. This is due to the current GitHub Actions setup, which ignores most data changes and only triggers on export script updates or manual runs. If you need the latest data in the main JSON, a maintainer has to manually trigger an export.
See workflow details

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[timkolloch]

@dosu okay that is a bit weird I would welcome it if an export also represents the newest data. Otherwise it is confusing.

[dosubot[bot]]

You're right, it is confusing—the export files don't always reflect the newest data right after a contribution is merged. This happens because the export workflow is set up so that updates to the contributions folder (like your fix for Arrecife) do not automatically trigger a new export; a maintainer has to manually run the export process for those changes to appear in the main JSON files. This gap between contributions and exports is a known issue and has caused confusion for other users too see discussion.

There have been recent improvements to the contribution and export workflow (like new sync scripts and clearer guidelines), but full automation—where every data merge instantly updates the exports—is not implemented yet details. Right now, there aren't any active plans or discussions about changing this, so exports may lag behind the latest data until a maintainer triggers them.

If you want more technical details about how the workflow is set up or have ideas for improvement, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}