Closed Rubix982 closed 3 years ago
@cbeddow 'Image", and "Map Feature Key" are different, right? I remember we discussed the idea of the id
key that we can see in a GeoJSON object.
If they are different, then since we have two types of inputs, indicated by the "takes an image or map feature key" from the requirements, it would be much better if we implemented two functions here, one using the image key, and one using the map key.
For now, I'll implement a skeleton of the two functions (the function definition, the DocString, and the return type", so we can move on to the implementation part in the future.
@Rubix982 yes, image is different rom map feature, so they have different keys (id) but the API can work with either graph.mapillary.com/IMAGE_ID or graph.mapillary.com/MAP_FEATURE_KEY. For tiles, images are the coverage tiles with image layer, with map feature is split into two tiles, the points one and the traffic signs one, representing items the algorithm found in the image and located geographically on the map.
I think two functions is perfectly acceptable.
Is your feature request related to a problem? Please describe. This issue deals with the 11th requirement from the PRD over getting features from a key
Describe the solution you'd like The base requirements are,
Describe alternatives you've considered NA
Additional context Consider if this should return a GeoJSON point object by default or should return just the JSON (no properties field with sub-properties, but instead flattened) as the graph API returns by default
Should this function and all others return all fields by default?