[User Story] 2. Images & Traffic Signs
まだ誰も着手していません。
評価
調査の方向性
まず、提案されている get_data 操作の SDK エントリーポイントと、既存の image-coverage および traffic-sign のタイルリクエストを特定します。組織、日付範囲、バウンディングボックス、半径、必須入力のバリデーションをどのように組み合わせられるかを確認します。image と traffic-sign のフィルタリングワークフローおよびリクエストサイズの制限について、合意された設計と実装スコープが決まれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Context
A user who uses a camera to take images all over the city would like to,
- Get a list of images uploaded to their organization (request to the image coverage tiles, then filter by the organization)
- Filter for images during a certain date range, like last week (so apply a date filter).
- Then they want to get all traffic signs visible in these images (so must really then call the same tiles from the traffic signs layer, using the same z/x/y)
- Then filter by calling graph.mapillary.com/TRAFFIC_SIGN_ID?fields=images, and keep only the traffic signs where at least 1 image in the images list matches a universal list of images from the tile request that uses date and organization filter
Concern
Each of these red boxes is 1-degree longitude by 1-degree lat. Maybe the max can be 2x2 degrees. And the user could set an override maybe, but by default, we reject if the area is 2x2 = 4 square degrees for a bbox.
For a radius, simply take area = (2* radius) ^ 2. And reject if area > 4 sq degrees also. But radius may be in meters, we need to have a handler of that too. The user should input radius in meters which we need to convert to degrees maybe.

Approaches/Limitations
Interestingly, this is not a function to get data by a bounding box, nor an input coordinate with a radius search. It has no geographic input argument, only organization name/key, and date range. So maybe a get_data function needs some special design.
It must have some argument that limits the search,
- The bounding box (with max size maybe, like a bounding box for all of Africa may be too big for the API or server)
- A radius around a coordinate (and max radius, like 200 meters is okay but 25,000km is too much), a date range (is their one that is too big?)
- An organization key for example, if I just do get_data(<date range from 2014 to 2021>) it would try to pull all global data from all time Mapillary existed. Too big. But the API would return a 500 probably, or deny access with a rate limit.
- We also need to say that you need either a bbox, a radius, an organization key, or a date range, or a combination, but you cannot have any. So all these arguments are optional as long as 1 exists as a minimum, but you cannot call a get_data function with no arguments. So thinking about how to check that.
- The other limitation then is just on bounding box, radius, or date range size maybe. For example,
- If bbox is within the size limit, then the date range can be anything
- If bbox and date range both exceeds the size limit (box size of Africa, date of 3 years), reject
- If bbox is the size of Africa, but the date range is 1 week, accept
- Same with radius. No limits on the organization as a parameter.
I will ask for some tips on bbox and radius size limits. For bbox, maybe an area limit, so abs(max_x - min_x) * abs(max_y - min_y) must be < limit. Then x,y of bbox are in degrees though, not meters. But that's okay. Maybe 1x1 degree is the limit, so 1 square degree.
Code Example [OPTIONAL]
Something like,
get_data(layer=traffic_signs,filter=[organization=XXX, min_date=YYYY-MM-DD HH:MM:SS, max_date=YYYY-MM-DD HH:MM:SS])
Inside this is a function that gets a list of all image keys that are in the organization, and have the date range like valid_images=[key1,key2,key3,...keyN], but also the tile coordinates like tiles = [ [x,y], [x,y], [x,y] ]
If there are 3 tiles (maybe just 1, maybe 20?). Then get a list of all traffic sign IDs in the same tile coordinates, and make an API request for each traffic sign ID (that's a lot of computing, unfortunately)
If there are 500 signs, for example, with fields=images, and then a condition of if any image keys in the traffic sign. Images field is in the valid_images list, then push the traffic sign with all fields including geometry to the output file
- 主要言語
- Python
- スター
- 66
- フォーク
- 23
- 平均マージ
- 1日 20時間
- マージ済み PR(30日)
- 11
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
mapillary/mapillary-python-sdk のほかの issue
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
mapillary/mapillary-python-sdk#156 · コメント 1 件 ·
-
Bug Report オープンbug
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
mapillary/mapillary-python-sdk#150 · コメント 1 件 ·
-
point cloud data オープンexample
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
mapillary/mapillary-python-sdk#147 · コメント 11 件 ·
-
feature
難易度 5/5 1週間以上 初心者へのやさしさ 32/100
mapillary/mapillary-python-sdk#127 · コメント 1 件 · リアクション 2 件 ·
mapillary/mapillary-python-sdk の issue をすべて見る
似ている issue
-
essnmx good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 95/100
-
[Feature] 奇物选择添加优先级 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
syfoud/Simulated_Scepter#174 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Giskard-AI/giskard-oss#2840 · コメント 1 件 ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success オープンarea: repo bug perceived difficulty: 2
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
yeti-platform/yeti#1380 ·