Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connecticut has different hc-key format than every other state #163

Open
em843 opened this issue Dec 19, 2024 · 3 comments
Open

Connecticut has different hc-key format than every other state #163

em843 opened this issue Dec 19, 2024 · 3 comments
Labels
pending reply awaits OP reply question Further information is requested

Comments

@em843
Copy link

em843 commented Dec 19, 2024

The hc-key format for Connecticut is different than for every other US state I've noticed. I'm guessing this was introduced in #146. This quirk makes applications that use maps for multiple states more difficult as special configuration is needed just for CT.

Connecticut:

hc-key: "us-ct-09170"

Arkansas, for example:

hc-key: "us-ar-073"
@KacperMadej
Copy link
Contributor

Hi @em843

Thank you for reporting the problem.

That map was updated recently and if other maps were to be updated they would also be following the kc-key generation rules applied here:

'hc-key': `${countryCode}-ct-${feat.properties?.['nist:fips_code']}`

Adding a special case for Connecticut for now might be beneficial in the future if other maps will also follow up on the new format.

The old key was based on something that is no longer available so instead of copying it over we have switched to using fips codes as they are more reliable.

Any hc- properties are generated based on something that makes sense but if you prefer to use properties based on some standards developed and maintained outside of Highcharts you could use fips, hasc, iso-.

I think I understand your problem and I tried to better explain why things are like they are right now, but if you have an expected behavior in mind we could continue the discussion.

@KacperMadej KacperMadej added question Further information is requested pending reply awaits OP reply labels Dec 20, 2024
@ryanparker-st
Copy link

Would you consider adding iso 1366 codes to the properties of all topo geometries?

Also would you mind sharing the reason why hc-keys are moving away from iso codes?

@KacperMadej
Copy link
Contributor

Hi @ryanparker-st
Yes, here's a ticket for it with more details (assuming 1366 is a typo for 3166).

Also would you mind sharing the reason why hc-keys are moving away from iso codes?

They were never strict binding between ISO 3166-2 codes and hc-key as far as I know. We follow the docs to keep the backwards compatibility and in there there's no ISO obligatory mention in relation to the hc-key property. Relation for hc-key and ISO 3166-1 for countries is maintained, but providing a more dedicated iso-3166 property is preferred so the expectation would be clearer. hc-key usage is mostly internal by design, hence the prefix hc-.

Connecticut's ISO 3166-2 is US-CT and there's no further subdivision for Connecticut with ISO 3166 codes as far as I know. New maps and updates for the Map Collection are made using OSM that is public and open for modifications, so if a code is missing or wrong it can be added or corrected at the source. We are also using older fips or hasc codes from the current Map Collection maps when OSM is not providing them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending reply awaits OP reply question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants