While retrieving county display names via the API, I noticed that the contents are returned in two separate formats. One format lists them in “county, country, state” order while another in “county, state, country” order. For example, Tarrant county’s (place 2444) display name is “Tarrant County, US, TX” while Travis county’s display name is “Travis County, TX, US”. In the 31 counties in Texas that I sampled, the display names were about evenly split between the formats. While I looked at only a limited sample, the inconsistency does not appear to be limited to Texas counties. For example, at least two counties in California show the different formats. Alameda county (place 845) is shown as “Alameda County, US, CA” while San Diego County is shown as “San Diego County, CA, US”. The standard way of the ordering this in the US would be “county, state, country”, so this is what I would expect, but I would at least expect it to be consistent.
I had thought of using the display name as an easy way to dump the county names into a CSV file, but the inconsistent formatting would make that difficult on sets containing a large number of counties. There are of course other ways to get at the information I need from the API that require a bit more coding, but this seems like an oddity.
I have never actually used this search box and have no idea why the results are coming out that way. It doesn’t necessarily seem to be related to this issue as far as I can tell, but I could be wrong. However, on that list one can see the same inconsistency with the San Juan County entries being followed by the country “US” whereas San Juan Islands just below are followed by the state “WA”. I think perhaps even the entry from Mexico lists the country first and then the state.
Oh my that is annoying. I don’t think I have used that place box before, but it definitely seems to use the display name. As far as I can tell one cannot tell which state the county is in unless you actually select it, so one would either have to go through every entry or get lucky. That would definitely be an argument for putting it in “county, state, country” order.
It sorta sounds like the problem is that some counties were assigned in error to the country (United States) as their parent rather than to their actual parent state.
I would suggest moving this topic to Bug Reports where iNat admins/developers are more likely to see it, but not sure if that can be done unless you are a moderator.
From the data returned by the API, it appears that it is localized to the “display_name” field. At least “parent” data or ancestor data seems to be the same for counties that are listed in different formats.
San Diego County: “ancestor_place_ids”:[97394,1,14,829]
Alameda County: “ancestor_place_ids”:[97394,1,14,845]
So it seems to me that either the display names were populated differently, either by different people or different scripts or something like that.
I was reluctant to enter it as a bug because it seems more like a data entry issue, but I may try to flag down a moderator to get some additional feedback.
I get the feeling that this is probably a known issue and that standardizing it might break something that relies on some places being in one order or the other.
the way default place display names are generated was changed about 9 years ago, but the existing display names (saved in the database prior to the change) were never updated, it seems. i guess you could request that the staff go in and change those existing display names, but it seems like kind of a minor thing to me.
Thanks for the link. I am not familiar with the Ruby language and the code is very sparsely documented, so it is not clear what the desired ordering in display_name actually is. It is also hard to see what change you are pointing to as only two of the change comments reference display name.
It is not a huge issue for me as I don’t do much programming, but it is annoying and it is unclear to me how far the effects actually reach (such as the filter by place example above).
