Street Preview #315
Merged
Street Preview #315
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
All of the providers were hidden inside LocationProvider, this change splits them out. It also adds GpxDrivenProvider which is the start of a combined provider that is driven by GPX files. And finally it adds updating of the current location to StaticLocationProvider. This allows the app to move the location for StreetPreview purposes.
This change notes which points have already been joined up so as to avoid joining them A->B and B->A. The result is just a single line between each pair of adjacent interpolated points.
The way that we add lines to the RTree is that each line segment is added pointing to the same feature. However, this means that a search will return all the RTree entries which are within the search criteria which means the same feature will be duplicated depending on how many of its segments fall within the search area. This change de-duplicates the feature addition so that each feature is only added a single time.
A long press on the GUI map was creating an audio beacon, but it's more useful to bring up the LocationDetailsScreen where the user can create a beacon or they can enter StreetPreview mode. This makes it easier to select somewhere to enter StreetPreview mode.
This change add a tiny GO button next to the StreetPreview icon which can be used to advance the StreetPreview in the direction that the phone is pointing. The current behaviour is that it jumps to the next intersection. It's definitely a work in progress.
Rather than pick the first points which are close, pick the pair that are nearest together (within 1.0m). Also skip precisely coincident points as they don't need a line to connect them. Add some tracing to aid checking unmatched pairs and to see how far apart points can be.
Include paths in our StreetPreview traversal. Need to check whether iOS makes this optional or not.
The FeatureTrees are updated when we the tile grid is updated. Because the FeatureTrees are also being used in all of the callout and street preview calculations we need to take care when we access them. This change puts all access in a single threaded context - treeContext - which means that the assigning of the trees to new data, and all of the callout and street preview calculations should be safely using the FeatureTrees.
Several changes in functionality here: 1. The initial StreetPreview jump is now to the nearest node on the nearest road instead of the nearest intersection. 2. As a result the StreetPreview code has been updated to be able to split a road at its current location so that it can move either way along a road. 3. When the StreetPreview hits the edge of the grid, it has to stop and then allow time to load in the new grid. From that point, it has to move along the short new joining road which is slightly tricky because it's pointing in the wrong direction - it will always be along the grid edge. This commit deals with that by removing the joining line segment from choice and replacing it with a segment starting at the current location. The result is that StreetPreview now seems fairly robust - though if you jump to a tile grid edge there will be a delay until the next jump can be made.
Polygon's are valid in OSM e.g. the precinct in Milngavie, but we can't navigate along them so filter them out.
When in StreetPreview mode, the location only updates at intersections and not in between. That meant that only intersections were being called out and not POIs as the autocallout would only do the first one it found. This change means that it build all of the callouts that it can on the first change in location.
Also includes the correction of an assert which was bogus.
Currently it's not configurable, just turn it on at build time by making streetPreviewGo call the streetPreviewGoWander code instead of just streetPreviewGoInternal. It prefers to continue in the same direction as the road it comes into an intersection on, but doesn't have any memory so can switch direction randomly.
This adds support for the tags that the iOS app was already translating. For reasons best known to itself it was altering strings like bicycle_parking to bike_parking in the Swift JSON parsing code. We just use the stock OSM values in our lookup.
davecraig
temporarily deployed
to
development
GitHub Actions
Inactive
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.
This is the initial Street Preview backend implementation that behaves similarly to the iOS app. The UI needs some work, but the APIs to the geo engine should be enough to do that work.