Add an option to get centroids #371
Merged
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
The format for how source files are mentioned changed between version 2.5.x and 2.6; follow along.
When there are too many elements to load all of them due to complexity, this loads all element centroids (actually the center of their bounding boxes) along with the element size (the diagonal of the bounding box). If an element has not been loaded, a circle is shown at the centroid with an adjusted diameter that is related to the bounding box size. This doesn't actually load *all* element centroids, just the first 2,000,000. This number should be empirically determined based on GPU memory (something like half the memory divided by (16 or 17) * 4 * vpf would be appropriate). Other improvements would be to (a) add hover events for centroid elements -- we know the ID and the center position, but not much else, (b) determine if any point's radius would be bigger than the webgl maximum point size, and, if so, render using a different primitive shape; otherwise, very large points render incorrectly, (c) if zoomed-out fully there seems to be an extra fetch of data on initial load, (d) compute a better centroid and size that the bounding box center and diagonal; this could be done on ingest. This PR will benefit from a GeoJS release -- small points are rendered poorly in master. When annotation centroids are retrieved, the response is a json-like object with a binary payload in the center. If there are a large number of distinct styles in the annotation, this can become inefficient (for instance, if every element has a distinct fill and stroke color).
|
Since #369 was approved, I'm merging this as well. |
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.
When there are too many elements to load all of them due to complexity, this loads all element centroids (actually the center of their bounding boxes) along with the element size (the diagonal of the bounding box). If an element has not been loaded, a circle is shown at the centroid with an adjusted diameter that is related to the bounding box size.
This doesn't actually load all element centroids, just the first 2,000,000. This number should be empirically determined based on GPU memory (something like half the memory divided by (16 or 17) * 4 * vpf would be appropriate).
Other improvements would be to (a) add hover events for centroid elements -- we know the ID and the center position, but not much else, (b) determine if any point's radius would be bigger than the webgl maximum point size, and, if so, render using a different primitive shape; otherwise, very large points render incorrectly, (c) if zoomed-out fully there seems to be an extra fetch of data on initial load, (d) compute a better centroid and size that the bounding box center and diagonal; this could be done on ingest.
This PR will benefit from a GeoJS release -- small points are rendered poorly in master.
When annotation centroids are retrieved, the response is a json-like object with a binary payload in the center. If there are a large number of distinct styles in the annotation, this can become inefficient (for instance, if every element has a distinct fill and stroke color).