Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapillary icons keep trying to overlay eachother #4297

Closed
JamesKingdom opened this issue Aug 29, 2017 · 4 comments
Closed

Mapillary icons keep trying to overlay eachother #4297

JamesKingdom opened this issue Aug 29, 2017 · 4 comments
Assignees
Labels
map-renderer An issue with how things are rendered in the map streetlevel An issue with streetlevel photos

Comments

@JamesKingdom
Copy link
Collaborator

When dragging the map around at a higher zoom level, the mapillary icons seem to fight for who is on top.
screen

cc @kepta

@bhousel
Copy link
Member

bhousel commented Sep 7, 2017

The Mapillary data is stored in an Rbush spatial index and, when redrawing, if too much of it appears in the same place, we only take the top few results.

Rbush does not guarantee a stable sort in the results that it returns (because that would negatively affect performance). If we wanted to sort the results before limiting them, we could add sorting to this block of code, as long as performance isn't affected too much.

// no more than `limit` results per partition.
function searchLimited(psize, limit, projection, rtree) {
limit = limit || 3;
var partitions = partitionViewport(psize, projection);
return _.flatten(_.compact(_.map(partitions, function(extent) {
return rtree.search(extent.bbox())
.slice(0, limit)
.map(function(d) { return d.data; });
})));
}

@bhousel bhousel added the map-renderer An issue with how things are rendered in the map label Sep 7, 2017
@kepta
Copy link
Collaborator

kepta commented Sep 18, 2017

@bhousel was looking at the performance penalty of adding a stable sort.
I wonder if the _.compact is redundant here

return _.flatten(_.compact(_.map(partitions, function(extent) {

I believe in this case
rtree.search always returns an [].
hence, _.map(partitions, function ...) would be an array of array [[]].

Which should make running _.compact redundant.
I guess the intent was to run it after _.flatten?

@bhousel
Copy link
Member

bhousel commented Sep 18, 2017

I agree the _.compact is unnecessary - I probably added it during development, thinking that rbush.search might return null instead of [].

@bhousel
Copy link
Member

bhousel commented Sep 25, 2017

I played around with this earlier today and I realize now that we need to change the viewport partitioning code if we want the markers to sort in a stable way. The viewport is split up in screen coordinates, and needs to be properly tiled in world coordinates, otherwise we will always be selecting from a different set of marker results (so sorting them won't matter much).

@bhousel bhousel added streetlevel An issue with streetlevel photos and removed new-feature A new feature for iD labels Oct 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
map-renderer An issue with how things are rendered in the map streetlevel An issue with streetlevel photos
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants