I am rendering lots of MapKit overlays. MapKit overlays are specified in terms of MKMapPoint's. I'd like to save the effort of translating GeoJSON text coordinates into MK polygons every time the app executes. The docs say I should stick to CL ~spherical coordinates and not store MK points.
As a practical matter, can I store MK geometry if it's just a local cache and never shared?
I am working with a dataset of polygons (US counties) with about 4000 elements. My source format is GeoJSON, for which MapKit has a reader. The process, as I imagine it, starts with a String-to-Double interpreter that yields CLLocationCoordinate2D's (or equivalent intermediates). For MapKit to render a run of CL coordinates as a polygon, they must be translated (internally or through a convenience init) into aggregates of MKMapPoint's, resolving the spherical coordinates into projected graphical coordinates.
Let's stipulate that this pipeline is as efficient as the best minds can make it.
Suppose I want to save as much decoding time as possible by storing arrays of binary coordinates as Data blobs in CoreData.
Encoding an array of CL coordinates is a wIn as far as it goes. Extending the CL struct for NSCoding isn't hard.
Naïvely, encoding an array of MK coordinates would be an even bigger win. The documentation, however, says I shouldn't persist MK coordinates.
I can imagine why. The coordinate mapping MapKit uses might differ across architectures and OS versions. These wouldn't be stable across contexts, even for a single user: Not only could she not share the translated points, but she couldn't upgrade the OS or buy a new phone. (I want her to upgrade her operating system. Apple wants her to buy a new phone.)
Certainly I couldn't bake a translated gazetteer into the app; I'd have to cache an interpretation of the GeoJSON as part of onboarding. If update rot turns out not to be a thing.
Right?
Is there a loophole? One that would allow me to generate and cache MK geometry at every run? Is there a cache directory I can expect the OS to purge upon OS updates and hardware changes? And would that be enough? (Checking MK's arithmetic before using the cached values smells.)
Or should I back off and be happy with caching the JSON → CL locations?
As a practical matter, can I store MK geometry if it's just a local cache and never shared?
I am working with a dataset of polygons (US counties) with about 4000 elements. My source format is GeoJSON, for which MapKit has a reader. The process, as I imagine it, starts with a String-to-Double interpreter that yields CLLocationCoordinate2D's (or equivalent intermediates). For MapKit to render a run of CL coordinates as a polygon, they must be translated (internally or through a convenience init) into aggregates of MKMapPoint's, resolving the spherical coordinates into projected graphical coordinates.
Let's stipulate that this pipeline is as efficient as the best minds can make it.
Suppose I want to save as much decoding time as possible by storing arrays of binary coordinates as Data blobs in CoreData.
Encoding an array of CL coordinates is a wIn as far as it goes. Extending the CL struct for NSCoding isn't hard.
Naïvely, encoding an array of MK coordinates would be an even bigger win. The documentation, however, says I shouldn't persist MK coordinates.
I can imagine why. The coordinate mapping MapKit uses might differ across architectures and OS versions. These wouldn't be stable across contexts, even for a single user: Not only could she not share the translated points, but she couldn't upgrade the OS or buy a new phone. (I want her to upgrade her operating system. Apple wants her to buy a new phone.)
Certainly I couldn't bake a translated gazetteer into the app; I'd have to cache an interpretation of the GeoJSON as part of onboarding. If update rot turns out not to be a thing.
Right?
Is there a loophole? One that would allow me to generate and cache MK geometry at every run? Is there a cache directory I can expect the OS to purge upon OS updates and hardware changes? And would that be enough? (Checking MK's arithmetic before using the cached values smells.)
Or should I back off and be happy with caching the JSON → CL locations?
