MKReverseGeocodingRequest and CNPostalAddress from MKMapItem

I then enumerate its attributes to pull out specific elements like just the street or state or zip etc.

What do you do with this information? Parsing the structured information is not always the right thing to do.

— Ed Ford,  DTS Engineer

Hi Ed! The use case in my app is to get the address for where a photo was taken. The user selects which address component(s) they want included. So I look at each attribute from the full attributed address to see if the CNPostalAddressPropertyAttribute is a component the user selected if so I add it to an array. Once enumeration is complete I join the array with commas to separate the components. For examples, if they selected zip it would be just 92101, or if they selected street and city and state it’d be 3835 N Harbor Dr, San Diego, CA. (The selected attributes aren’t guaranteed to be in the final string and that is acknowledged.)

I have your code-level support request, and from that I have your Feedback Assistant report FB19363454 (thank you for that!) that has a bit more info on what you're doing.

Since you're using the address for display purposes, I would try to see if you can make MKAddressRepresentations work for your needs, and if you could present the customization options to your customers based that line up with what that class offers. I realize the options are not as granular as you would like, and I can intuit that for certain customers, the API options may not be enough, so expressing your requests for even more API in FB19363454 is the right thing to do.

Once enumeration is complete I join the array with commas to separate the components

I want to call this out as an issue. Techniques like this are understandably common, and unfortunately, it is very easy to naively construct geographically incorrect place descriptions as a result. Geographic data and place identity has regional complexity and subtleties that are easy to over look! Thus, we want to discourage folks from doing these string concatenation techniques, and instead rely on the framework to provide you with the correctly formatted information through MKAddressRepresentations — you can specify a description of how much address detail for the place is needed, and delegate the correctness of how to represent the place with different levels of detail onto MapKit.

— Ed Ford,  DTS Engineer

I would try to see if you can make MKAddressRepresentations work for your needs, and if you could present the customization options to your customers based that line up with what that class offers

I'll pursue this route, thanks! Existing customers will need to change their settings to choose one of the predetermined formats that most closely matches their use case. As folks reach out to report what they can't achieve anymore, I can file feedback reports requesting more formats be added to MKAddressRepresentations.

The only thing I'm struggling to come up with is a friendly name to show in the UI for selecting the predetermined format of "city with context" both the short and full variants. Best I have is City, City and State, or City and State and Region - the word "state" is probably not appropriate everywhere. 🤔

it is very easy to naively construct geographically incorrect place descriptions ... we want to discourage folks from doing these string concatenation techniques, and instead rely on the framework to provide you with the correctly formatted information through MKAddressRepresentations

Makes sense! With the approach to select specific date components, I took inspiration from DateFormatter.setLocalizedDateFormatFromTemplate(_:) where you specify which components you want and you'll get an appropriately formatted localized string. I thought I achieved that fairly well by preserving the order of components in the postal address just filtering out undesired ones, but can certainly imagine there could be scenarios where the resulting string doesn't really work for different locations around the world. I did file FB8648023 (Template API desired to format addresses with different components, similar to DateFormatter.setLocalizedDateFormatFromTemplate) hoping to replace my solution with a native API, but maybe that's infeasible given address complexity?

I did file FB8648023 (Template API desired to format addresses with different components, similar to DateFormatter.setLocalizedDateFormatFromTemplate) hoping to replace my solution with a native API, but maybe that's infeasible given address complexity?

Thanks again for the input through these requests. I can't comment on if this is totally infeasible or not, and so that's why we value the request for consideration. I have a small working set of examples where I know its easy and common to misrepresent a place by "simply" extracting values from a structured postal address and combining them back together in a way appears to work for some regions but is incorrect for other regions, and I'm sure our folks who are more deeply attuned to worldwide geographic subtleties than I will have many more examples and counter examples and ideas of how to approach the problem space.

— Ed Ford,  DTS Engineer

Hello,

my app is designed for frequent travelers. It's kind of a "collectors book". The user collects continents, countries, states, cities, sub-cities, rivers, seas etc. All the required data for that were well provided by CLPlacemark ...

I also understand, that you try to provide good quality in the presentation of the (postal) addresses. The new API looks quiet good for this purpose.

I never constructed a postal address by my own, as I understand the difficulties to build a proper postal address based on the users local needs. For that I used the "postalAddress" of CLPlacemark.

Are there other ways to get this detailed informations?

I really enjoyed the detailed data/Infos of the CLPlacemarks. Used to that richness of content and now seeing the puristic MapItem address strings is similar to be used to modern HDR-TVs and suddenly fall back to a Black&White TV from the 1960.

So far new APIs were allways some kind of a better way to achieve something. Well some better, some not so good.. but it was always fair.

This one sounds like "we know you don't need that" and by the way you are not able to use the existing API properly, so we force you to this way....

I think that's a kind of arrogance and a typical example for the german word "Übergriffig" (paternalistic and overreaching)

Hardy

Hi,

I just learned that there is a ways to get more informations from an MapItem...

MKReverseGeocodingRequest -> MapItem -> region: Locale.Region?

By this you can see e.g. the continent and if you parse the BCP 47-Identifier you can get the ISO Country Code. Which is important to have a single code for a country no matter what languange the user is using ...

So I think, there are ways to finally get a good subset of all the CLPlacemark infos by using several API ... what a wast of code, computing power and battery....

Does anyone know how to get infos about oceans and inline waters nearby a given Address?