Pokeapi: Why are Pokemon height and weight ten times their actual value?

[arnavb]

When I create a sample request for a pokemon, say Garchomp (445), I get that its weight is stored as 950 (950 what?) and its height 19. Checking bulbapedia and pokemondb, I see that these values should be 95.0 and 1.9 respectively. Evidently, these values are ten times what they should be. This can be seen with other pokemon as well. Since JSON supports floating point numbers, why not just place the actual value for these fields?

[Naramsim]

We take our data from Veekun.

We do not modify their data.

[tdmalone]

Just to clarify this... @arnavb it's a good question, and you're welcome to open an issue at Veekun about it: https://github.com/veekun/pokedex/issues

If there's a good reason Veekun can't/won't change the data and that same reason doesn't apply to PokeAPI, I suppose we _could_ make a case for adjusting the data, but it would probably not be ideal as it would introduce additional complexity to the management of the API.

Having said that, there's probably a case for adding a little more details on these fields in our documentation. I'll open an issue in the pokeapi.co repo for that.

Thanks for reporting!

[Anu6is]

Just a note on this. While it may not be a breaking change as such to "correct" these values, it can have an impact on projects that are consuming these values as is and making the necessary adjustments internally.

[tdmalone]

^ That's a good point. If we changed them, it would have to be an API version increase for that reason.

[sargunv]

I'm not sure why we need to discuss making a breaking change for this. Just
update the docs to mention we report height in decimeters. Our number isn't
incorrect, we just need to clarify units.

On Thu, Oct 4, 2018 at 17:44 Tim Malone [e-mail] wrote:

^ That's a good point. If we changed them, it would have to be an API
version increase for that reason.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PokeAPI/pokeapi/issues/380#issuecomment-427212926,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQlpUqalEOFs7QB98-vSBq8-J6MCcvKks5uhquAgaJpZM4XIVoF
.

[tdmalone]

@sargunv That's why this issue is closed and https://github.com/PokeAPI/pokeapi.co/issues/19 is open instead :)

[sargunv]

Cool, just following from email so I didn't notice it's closed :)

On Thu, Oct 4, 2018 at 18:03 Tim Malone [e-mail] wrote:

@sargunv https://github.com/sargunv That's why this issue is closed and
PokeAPI/pokeapi.co#19 https://github.com/PokeAPI/pokeapi.co/issues/19
is open instead :)

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/PokeAPI/pokeapi/issues/380#issuecomment-427215455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQlpa_GGflEk4YcYemKCYrUK0b7u6HCks5uhq_NgaJpZM4XIVoF
.

[phalt]

Doesn't need a change. It's the data we consumed originally.

In software you can just divide by 10 ;)

[arnavb]

Ok, so I opened an issue on veekun, and got the following response:

It's an issue of units: The games store height in decimeters and weight in decagrams (good units to use if you need to store the info as whole numbers, but extremely weird for any other use, like displaying the data to people).

See: https://github.com/veekun/pokedex/blob/master/pokedex/db/tables.py#L1649

As evident, the reasoning here is that the numbers are easier to store in game as whole numbers (floating point errors, perhaps?).

I feel like this API might have to divide these values by 10, since the justification in the issue provided above doesn't really apply for this JSON API.

Thoughts?

[tdmalone]

Thanks for checking up on it!

While I agree it would make more sense for us to be presenting the values divided by 10, given the feedback in this issue I'm not sure we should now, because:

• there's no precedent for us adjusting the Veekun data, so introducing an adjustment introduces extra complexity into the management of the API
• it'll be a breaking change, so can't be done without incrementing the API version
• the change on its own doesn't offer a lot of value so isn't really worth the effort, given it's trivial to divide by 10 in downstream apps (especially now that we've just merged a PR adding the units to the docs)

This is probably worth revisiting in a future API release - _if_ and when that comes - but it's not something we can support at the moment I'm afraid!

[arnavb]

Cool, thanks for the clarification!