[WIP] Improve OSM GeoJson data loading pipeline #72
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes failing due to issues with voices.
The previous strategy used for parsing the OSM GeoJson data received from our services was based on old Objective-C compatibility, which is generally no longer needed. Replacing it provides significant simplification and type safety. First, we now use `JSONDecoder` and the `Decodable` protocol to parse GeoJson data, rather than the old (NS)JSONSerialization strategy. Second, `GeometryType` and `GeoJsonGeometry` have finally been merged into a single enum (which was previously not done due to Objective-C support) - This guarantees that invalid coordinate structure for a geometry type is unrepresentable - We also use CLLocationCoordinate2D instead of keeping Double arrays Since GDASpatialDataResultEntity objects (among others) are cached in the local Realm database, the schema is left unchanged, despite otherwise improving the usage - Eventually, a migration from the legacy Obj-C Realm mode to the new Swift mode should be done, which will also allow objects to be stored more naturally. I would also like to note that the various implementations of GeoJson objects do not entirely adhere to the spec, and it may be preferable to parse GeoJson objects while adhering to spec, and only then convert it into the desired forms.
This improves consistency with naming of GeoJsonGeometry and GeoJsonFeature, as well as reducing clutter.
This reduces the complexity significantly, and since they were already being called with callbacks, it doesn't change the end use as we can now just spawn a task - HTTPStatusCode had inconsistent implementation between `nil` and `.unknown` for other status codes, so we now favor `.unknown`
Slowly moving up the call stack. This makes the process for queueing tile fetches much simpler, both via async and separating responsibilities
Switched to the newer RealmSwift, instead of the older Objective-C based version Mostly this is a drop-in replacement due to backwards compatibility Then updated definitions to the newer `@Persisted` syntax
Data cacheing documentation was very outdated, so updated that Fixed some warnings
Split `SpatialDataCache` to only deal with our primary cached map data, moving the markers and route database handling to `SpatialDataCustom`
All modifications to the cache realm should be run on this actor to avoid race conditions - Additionally, moved cache-related functions from SpatialDataContext to SpatialDataCache - Clean up split predicates
Since the initializer will always set SuperCategories, it doesn't have to be optional Also, added a retry version for getTileData
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improvements to the way the Soundscape app handles the GeoJson data it receives from our services.
I have a few likely goals: