Polygonzone add multiple anchors support - #910
Merged
onuralpszr merged 13 commits intoFeb 28, 2024
Merged
Conversation
LeviVasconcelos
force-pushed
the
polygonzone-add-multiple-anchors-support
branch
from
February 15, 2024 21:34
617a445 to
b5452f6
Compare
SkalskiP
requested changes
Feb 23, 2024
Collaborator
|
Hi @LeviVasconcelos 👋🏻 ! Awesome PR. I liked your ideas. I left some comments. I'd appreciate it if you consider my feedback. |
add multiple anchors support remove old trigger
add polygon_zone unit tests
pre-commit reformatting
pre-commit
LeviVasconcelos
force-pushed
the
polygonzone-add-multiple-anchors-support
branch
from
February 26, 2024 20:42
b01950c to
8b443d1
Compare
Contributor
Author
|
Thank you for your comments, @SkalskiP ! I've addressed all of them. Please let me know what you think |
SkalskiP
previously requested changes
Feb 28, 2024
SkalskiP
reviewed
Feb 28, 2024
onuralpszr
self-requested a review
February 28, 2024 17:27
onuralpszr
force-pushed
the
polygonzone-add-multiple-anchors-support
branch
from
February 28, 2024 19:04
01c0281 to
7adb368
Compare
Signed-off-by: Onuralp SEZER <thunderbirdtr@gmail.com>
onuralpszr
force-pushed
the
polygonzone-add-multiple-anchors-support
branch
from
February 28, 2024 19:10
7adb368 to
d0ad5fe
Compare
Contributor
|
@LeviVasconcelos thank you for your contribution I am merging in. For examples I did not touch it. There is little bit more work I see in example let's do them outside. |
onuralpszr
approved these changes
Feb 28, 2024
onuralpszr
approved these changes
Feb 28, 2024
onuralpszr
approved these changes
Feb 28, 2024
onuralpszr
dismissed
SkalskiP’s stale review
February 28, 2024 19:23
I fixed all changes as has been requested.
Contributor
Author
|
Thank you guys @SkalskiP @onuralpszr. It was a big pleasure to contribute! Congratulation for the awesome project you guys are building :) ! |
Collaborator
|
Thanks for your help @LeviVasconcelos 👋🏻 ! I really like your |
This file contains hidden or 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
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.
Description
This PR addresses Issue #844.
triggering_positiontotriggering_anchorsto be consistent with theLineZonenaming convention.PositiontoIterable[Position].Position.BOTTOM_CENTER.PolygonZone.Type of change
How has this change been tested, please provide a testcase or example of how you tested the change?
For a minimalist setup, I'm doing the following:
1- Create mock detections simulating an object moving in a straight line.
2- Instantiate a
PolygonZoneobject with polygon partially intersecting the line.3- Compute the
PolygonZone.trigger(mock_detections)and annotate the detections triggering thePolygonZoneobject as green, and red otherwise.The setup used here was also used as base for the unit tests.
Google colab: https://colab.research.google.com/drive/1fcsVrprMuf7hm_bxitSqmeL5L7KBVGHh?usp=sharing
Deployment Concerns
API Backward Compatibility
Option 1: Maintaining Deprecation Logic Within the Function
To ensure backward compatibility after renaming a parameter in this PR, one approach is to maintain deprecation logic within the function itself. The implementation could look something like this:
While effective for specific cases, this approach has some drawbacks:
**kwargsmight make the documentation less clear.Option 2: Adding a
@deprecated_parameterAnnotator (Adopted Solution)The chosen solution involves creating a
@deprecated_parameterannotator using pseudocode like this:While this solution may not be suitable for highly complex parameter changes, it aligns with existing practices, such as the use of the
@deprecatedannotator, making it easier to track deprecated code references.Please share your thoughts on this proposed solution.
Deprecated Examples
Some examples, like
examples/traffic_analysis, explicitly settriggering_positionfor thePolygonZoneclass. This PR renders it deprecated.Should we address these changes within this PR, or would it be more appropriate to handle them in a separate one? I am open to incorporating the necessary modifications here if that is the preferred approach.
Let me know your preferences regarding these considerations.
Docs
Changed the documentation for class
PolygonZone.Fix : #844