-
Notifications
You must be signed in to change notification settings - Fork 74
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
Annotation layer #613
Annotation layer #613
Conversation
Before they were special properties, which made them harder to work with. Added mouseDown information to mouse click events, since the click is triggered with mouse up, buttons are typically up. Crude, if functional, support for polygon and rectangle annotations.
Clean up a bunch of code and add comments.
1226b78
to
130c89d
Compare
Current coverage is 82.75% (diff: 100%)@@ master #613 diff @@
==========================================
Files 83 85 +2
Lines 7563 7966 +403
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 6186 6592 +406
+ Misses 1377 1374 -3
Partials 0 0
|
Nice! Will start the review. I am assuming that we are going to add tests as well for this PR? |
Yes, that's why this is marked a work-in-progress. |
@manthey Would it be a big lift to include point annotations in this PR as well? |
@kotfic It won't be much work -- I'll get to it today or tomorrow. |
roger that, thanks @manthey |
@kotfic Point annotations. In the annotations example, click the middle mouse button to enter point-creation mode, then click the left mouse button to add a point. |
One problem with using a middle click is that apple devices don't support it. |
It is only for development -- I intend to add some control widgets to the example so you can pick what annotation you want and then use left-click for all of them. It will go away by the time the WIP label comes off. |
Fix some minor issues in drawing polygons (such as ending with two points).
Allow annotations to be removed in the example. Added more annotation events. Fixed a problem with removeAllAnnotations.
Accept colors of the form #rgb in the convertColor function.
In the annotation example, you can now edit annotation properties (color, stroke width, etc.). |
very cool! I guess we are still waiting for tests? |
I'll work on tests next. |
@manthey This is really awesome! Something to consider for the example - it would be nice if pressing escape exited polygon creation. |
+1 |
To handle keyboard events nicely, I've used a library called Mousetrap in the past. For just handle escape it is overkill, but I can envision more interactions (nudging points with the arrow keys, etc). Opinions? |
I'm fine with mousetrap. Looks like a pretty small library, and it would remove a lot of custom code for detecting mouse and keyboard events we have in place. |
+1, looks like a nice little library |
Added the Mousetrap library to handle keyboard actions. Rather than binding key events to the global document, they are bound to the map node. This necessitates the map node having a tab index so that it will receive key events. A tab index is added if not present, but only if a map interactor is specified. In the event that no interactor is desired, the map can be constructed will a null interactor, rather than creating and then clearing the interactor.
The animation frame was mocked after an animation frame might have been requested, which could lead to a failure to step through animations properly.
Test short hex color strings. Test bad polygons. Test one-vertex lines. In general tests, if beforeEach and afterEach are at the global score of the test, they apply to ALL tests, not just the describe functions in that file. This results in odd behavior that shouldn't be relied on. Fix this in the tests for d3GraphFeature, d3PointFeature, geojsonReader, and heatmap. In resizing a map, asking for a zero size causes errors (this could happen when the DOM was created without a size and then later resized). Guard against this in the map, and assign sizes to test divs *before* adding them to the body. The divs in the mapInteractor tests were relying on the size being affected by the beforeEach and afterEach of other modules, so set those explicitly and adjust the tests accordingly. Fixed a type on the test-utils when unmocking the VGL renderer.
Split the annotations into their own source file. This could later become a directory of the same name (annotation) with each annotation in a separate file, if needed.
…otations. Make the annotation states one of a set of constants.
Now with tests. |
awesome @manthey thanks. I/we will try to review this asap. On this note, I guess the next task in the list would be "editable annotations" followed by "adding text to annotations". Is that correct? Thanks, |
@aashish24 I thought it was the opposite order: adding text, then editing, but it is your choice. |
I see. For the NEX, editing has become a little bit higher priority. So I would prefer we do that first unless we hear otherwise. |
zoomselect: 'geo_action_zoomselect', | ||
|
||
// annotation actions | ||
annotation_polygon: 'geo_annotation_polygon', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should it be annotate_polygon (verb vs noun?) similar to 'select'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was viewing this as the action belongs to the annotation module and the action is to make a polygon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure this is fine with me.
* | ||
* @param {object} annotation the annotation to add. | ||
*/ | ||
this.addAnnotation = function (annotation) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
* @namespace geo.event.annotation | ||
*/ | ||
//////////////////////////////////////////////////////////////////////////// | ||
geo_event.annotation = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here verb vs noun? I do not have strong preferences and my comments are more as second thoughts.
* @returns {geo.annotation} | ||
*/ | ||
///////////////////////////////////////////////////////////////////////////// | ||
var annotation = function (type, args) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are types defined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each annotation subclass defines the type, so this is fully extensible and types aren't predefined. I don't expect users to call the annotation base class by itself unless they are defining a new type. Internally, we have polygon
, rectangle
, and point
right now, but I could see adding lots more -- lines, labels, ellipses, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I saw the code " annotation.call(this, 'rectangle', args);" so the type names are defined by each subclass. I am wondering if could return a list of supported types (assuming after the annotations are initialized) as something like this could be useful for ui. But I don't think this is critical or needed at the moment. May be (no strong preference) in the comment, we could add a line in the doc stating that type is defined by sub-classes as they extend the base annotation class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment there isn't an annotation registry. I think it would be good to have one, as this (a) allows easily enumerating available annotations, and (b) each annotation can list its required features, so when you ask for an annotation layer, instead of asking for a specific renderer or a list of required features, you could alternately supply a list of annotations that would be used and that would be used to select an appropriate renderer.
It isn't much work to add that. I can do it now or deferred it to the next PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks. next PR is fine with me.
I liked the design overall 👍 👍 👍 with separation of annotations, features, and layers. |
This requires PR #612.
This adds an annotation layer and an example that uses it. Currently, there are two annotation types: polygon and rectangle. It should be straightforward to allow the annotations to be edited and to add metadata to the annotations (such as name, changing the style, or arbitrary other data).
There are no tests yet.