Distribution charts and place countries

[magicsunday]

If I currently enter a place like this "City, Destrict, County, Country", it is required to enter the country name exactly like the localised name one. Otherwise the distribution chart (which uses Country::getAllCountries) wont show this countries. If I enter "United States of America" in a record, the chart keeps empty as the translation is "United States".

Should there be an extra select field (everywhere you could enter a place) to specify a country using the existing list from Country::getAllCountries and store only the three/two letter country code?

So the chart will be able to match the countries using the country code and not the translation string.

This may also require some automated conversion of existing records (truncating the last part of a place string and match it against the country list, if it match use it in the new field). Could also be an option in the "batch_update" module.

[fisharebest]

The existing "googleMaps" module used a CSV file format to store geographic data.

I want to replace this with http://geojson.org format, and I have created a repository to store it: https://github.com/webtrees/geodata

For each place, we currently store the localized place name and a flag.

It would be straightforward to allow an array of localized names. i.e. alternatives and abbreviations.

"en": ["United States", "United States of America", "USA", "U.S.A."]

This would give us a resource that we could use to convert place names to a standard format. This could be used during

• data entry
• import
• export
• translating place names to the local language

The last option seems pretty exciting. It means that if you had

2 PLAC North Carolina, United States

Then you could display "Caroline du Nord, États Unis" to french users.

[Amgine0]

What remains constant is the geocoordinate or area. Each place may have an infinite number of names, some of which will be translatable, some of which will be disputed. Separating the names from the geopolygons they represent would allow for translation(s). It would also allow for political change - e.g. living persons in Newfoundland, Canada who were born in Dominion of Newfoundland (independent from 1907), Newfoundland and Labrador (1927), then Newfoundland and Labrador, United Kingdoms (again) in 1933, and currently Newfoundland and Labrador, Canada, since 1949.

You might approach locations as standardizing on "admin level name"; there are usually only five levels recognized, A1-A5. GPX and GeoJSON are both supported in Geocoder PHP, which can use Geonames or Nominatim providers.

[fisharebest]

What remains constant is the geocoordinate or area.

I'm not sure it does.

Boundaries change constantly. For example, british counties are constantly gaining/losing parts to neighbouring counties.

Each time this happens, you have a new area and new entity.

I did look at this approach once - but I couldn't even find a definitive history of the boundary of my own county.