User mosaics #133
User mosaics #133
Conversation
Including source prioritization (currently disabled).
There was a problem hiding this comment.
If you can enable repository maintainer permissions I can add some tests so they can be all part of the same pr.
I will try to look into some other options for tile coverage calculation.
What are your thoughts about storing catalog as property of User that is updated when new images get uploaded so it is not recalculated for every request? Probably overkill for now but might be worth consideration in the future?
| const { user } = request.params; | ||
|
|
||
| return Promise.all([ | ||
| User.findOne({ |
There was a problem hiding this comment.
Is the user record necessary for the catalog json? Can we just use the user id then we can avoid the findOne query and just perform the Meta.find
There was a problem hiding this comment.
Just to fetch the username for descriptive purposes (which is never surfaced anywhere public).
| Meta.find({ | ||
| user | ||
| }, { | ||
| bbox: 1, gsd: 1 |
There was a problem hiding this comment.
I am not sure but I think the idiomatic way to do projections with Mongoose is with string literals. http://mongoosejs.com/docs/api.html#find_find
I found the 1s confusing since I normally associate this with sort order.
There was a problem hiding this comment.
I found the space-delimited string literals mildly alarming, so deferred to MongoDB docs. I'll update that.
There was a problem hiding this comment.
I am ok with the object notation. Just wasn't sure what the standard way of doing it was.
| } | ||
| } | ||
| }, { | ||
| acquisition_end: 1, |
There was a problem hiding this comment.
Same comment as previously concerning projections.
Checkbox checked.
JSTS might work (it was replaced in turf by For the user mosaic, skipping the tile coverage calculation seems ok, which will buy us some time on waiting for a fix to that crasher. I'm not smart enough to understand what it's doing in the
Maybe? The |
There was a problem hiding this comment.
@smit1678 We can approve this pull request and I will add some tests with another pr.
This is a refined version of #122 specific to users (and feels sufficient to deploy from my perspective).
It allows marblecutter-openaerialmap w/ https://github.com/mojodna/marblecutter-openaerialmap/blob/master/openaerialmap/web.py#L274-L292 to render tiles from
/user/<id>/{z}/{x}/{y}.png.It includes logic to prioritize sources that more fully cover a given tile (preferring recent + higher resolution versions), but that's currently disabled due to the Zanzibar data hitting w8r/martinez#74.
(This is the same logic we'll want for the global mosaic, especially since the likelihood of more sources fully covering a given tile is substantially higher.)