[Feature] Utilities for extracing fields, filtering pipeline

[Rubix982]

[Feature] Utilities for extracting fields, filtering pipeline)

Pull Request Type

• 🏆 Enhancements - adds utilities for filter pipeline, extracting fields

Purpose

To simply the filtering purpose, and for users who might want to extract only certain fields from a GeoJSON. I ran into a problem when testing requirement#2 where I just wanted to check the final id property across all features in a GeoJSON and did not need everything else, so I came up to write a simple function that does it for me.

I noticed that the DRY principle was being violated with the filtering ideas. As we go on in the requirements, there are fields that are common across requirements, and can be also common with future requirements, that we would have to write the same code for over and over again - what if can automate that?

A pipeline does just that. It passes the data to the first filter it has received, then that output of that gets passed to the 2nd filter, then the output of the 2nd filter gets passed as the input to the 3rd filter.

Why?

The most important change that this PR introduces is the filtering pipeline which lets us reorganize, add, remove filters as simple objects, future demonstration will be worked on. This means if a filtering mechanism breaks or if we want to add a new one, it will be a simple addition, and then any future user or potential developer can just reuse this pipeline component

Feedback required over

• A quick pair of :eyes: on the code
• Discussion on the technical approach
• Critique on design

Feedback required when

Whenever feasible

Mentions

• @cbeddow what do you think about this approach? Can you think of some other utilities like these that can we can write that might be helpful to either in development or to the users? A user can always import the utilities by writing code such as,

from mapillary.utils.filter import pipeline.
pipeline(...)

• @OmarMuhammedAli what do you think about this design aspect of the code?

[Rubix982]

For the above commits,

• [X] Tests added for both pipeline and extract_properties, and as such, examples that
• [X] Refactored pipeline extensively, there is the only part that will have to be configured going into the future, and that is the list of filter functions in the variable function_mapping
• [X] Added DocStrings to each function in the above commits, along with Usage, and Imports, and Test, wherever possible.
• [X] Moved tests from utils under /tests/utils/
• [X] Statically typed function parameters for clarity of use

CC: @OmarMuhammedAli review please

[Rubix982]

Amazing work, @Rubix982 !!!!! I really enjoyed reviewing this PR. Can you share some resources that inspired you to apply the design decisions you used here?

Just the DRY principle suggested by someone called "Omar". I think you know him :wink: