Rubix982 Structure

[Rubix982]

Project Structure

Pull Request Type

🏆 Enhancements - requirement#1, models, exceptions, API ends points, DocStrings for documentation, skeleton functions

Purpose

The purpose is to,

• Further, improve the state of the structure and standardize workflows and introduce better practices for testing and writing code

Why?

Each of the commits contains a detailed explanation but in short,

1. The Mapillary has skeleton wise implemented the required functions and introduced properly written DocStrings for documentation purposes
2. The Exceptions file contains a base model to follow along if any exceptions occur, and to help users understand them
3. The Credentials class for the 1st requirement of the function
4. The API as an idea to test if it would be better if we took this approach

Feedback required over

What kind of feedback do you require from this PR, if any? For example,

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

Feedback required when

Whenever feasible

Mentions

• @OmarMuhammedAli Do you think this is a good approach and a good workflow to maintain for the project? This simplifies the implementation side of things. Some decisions I took when writing the code keeping in mind future developers and the audience to help them better and more easily use the package
• @cbeddow What do you think about the current structure? Is it good? Where can improvements be? I looked at other python packages and tried to introduce something similar. Particularly, for this commit, I took inspiration from the requests library. I will definitely look at the mercantile, and the osmnx library even further.

References (OPTIONAL)

This is OPTIONAL.

• Getting Started with the new Mapillary API v4
• Mapillary API Documentation

[Rubix982]

New Commits!

New commits reasoned as the following, as discussed in a meeting with @OmarMuhammedAli and with @cbeddow on the Discord chat. The commit itself should be self-explanatory, but for context, the complete commit says the following,

feat: Add basic API interfacing with APIv4 @ Mapillary

Description

This is meant to implement logically, as code, the API interface with which to access the APIv4 web interfaces. I thought the URLs themselves did not seem intuitive at first, so I made some wrapper functions around them to promote compatibility that is, if the URLs were to change tomorrow for some reason, we can simply fix that by adding editing a single line and breaking nothing in the codebase.

Reasoning

Changing the configurations here in the functions should be enough to accompany what the API endpoints are. Maybe even adding new functions or types of endpoints.

Lines Of Code

The lines of code may seem overwhelming, but they really are just basic implementations of some modules for the needed API.