PokeAPI
Change evolution chain IDs so there aren't "empty" IDs in between valid ones
Evolution chain IDs range from 1 to 476. Despite that, the following evolution chain IDs return a 404 error when you try to access them: 210, 222, 225, 226, 227, 231, 238, 251
As far as I can tell, there aren't any good reasons to leave these IDs blank, and it makes evolution chains unnecessarily annoying to work with. If someone (reasonably) assumes that there is a valid chain for each ID from 1 to 476, the empty IDs are liable to cause some annoying bugs until they figure it out. It's just very unintuitive.
I propose higher IDs be shifted down to fill in the gaps. It would break legacy code that relies on the current setup, but in a future version or something it should be considered. It would be far cleaner.
Shifting the IDs down would create problems inside pokemon_species. Specifically the problem is that ID's were skipped for whatever reason when this data was originally made in the veekun repository. There may be a reason for this, but there's no discussion in the repo itself for why the numbering is like this.
That said, let's take a look at 210, and why that's missing. 209 is the Shinx family line, and once that finishes 210 should be the next family line, but the next pokemon in line is Budew which adds two pokemon to the Roselina family line started in Generation III. After which the Cranidos line starts at 211.
So yes, it would be nice if they shifted down, I'm not entirely sure why veekun skipped 210, and I'm assuming the same situation applies to the rest of the numbers you listed where a member is being added to family in later generations affect the numbering.
Since this repo is still actively using veekuns data I'm not sure at which point they want to converge from how Veekun's data is structured or if there was an actual reason for how Veekun numbered these evolution chains. Shifting these down in evolution_chains alone will cause issues, and this will have to be adjusted in both evolution_chains, pokemon_species and more outside just the csvs.
@Naramsim
