Definitely a bug

​@da2999047 Donald, Thanks.  Today, I also confirmed even the Swagger UI is not returning latlng when I select all possible key options.

Are there any known workarounds (I need the lat / lon coordinates for approximately every second during the run)?

What is the process to get this bug fixed?  Does the Strava dev team pick up on this thread and fix the issue, or do I need to report it in a bug system somewhere else?  (I’m new to the community.) 

latlng is critical to my project and I would expect is a very important for others.

For me it works correctly, but I always use the time series_type instead of the distance series_type.

​@Jan_Mantau, thank you for the details.  After taking your response, I troubleshooted further and found my API call sometimes works and sometimes doesn’t work.

1) WHAT DOES WORK:

Calling the activity stream API appears to work normally when the <ACTIVITY_ID> used contains non-empty values for sstart_latlng] and ]end_latlng] in the activity details.

2) WHAT DOESN’T WORKS:

I first calling the activities API call (to return all activities), getting an <ACTIVITY_ID>, and then calling the activity stream API call using that id (to return all lat/lon for that single activity).  It seems the <ACTIVITY_ID> I was  using using had empty values (“t]”) in the �start_latlng] and aend_latlng] fields.

It appears the activities recorded with a Garmin watch did not populate the lat/lon values; this is a different issue which I will look into separately.

It seems my specification of “keys=distance,latlng” vs “keys=time,latlng” in the URL made no difference and is unrelated to the underlying cause of my issue (thank you, ​@Jan_Mantau  for confirming the call was working for you).

​@rc100 I didn’t mean to use other keys, but another series_type. This won’t make any difference for you when the problem is missing data in the recording (recorded as indoor?), I only want to clarify that I use a URL like api/v3/activities/2250402881/streams?keys=latlng,distance,altitude,velocity_smooth,heartrate,cadence,watts,temp,moving,grade_smooth&key_by_type="&series_type=time

My first guess would be that some activity types (e.g. Strength, Yoga, etc) do not record GPS coordinates which is why there is no data for those.

The other thought is that the activity does have data but it all falls within the user’s privacy zone(s) and therefore isn’t visible to you.

Does changing the request parameter work? I’ve been wondering what would affect the response’s series_type or resolution but they aren’t documented as request parameters.

​@gerwitz It used to work but since today (or yesterday) the series_type parameter is ignored and every stream defaults to the series_type = distance. They seem to have removed it from the documentation too but without mentioning anything in the API change log.

​@Jan_Mantau I’m so glad you tagged me for this! I failed to validate the series_type return and blindly trusted the result, and now I have incorrect calculations happening.

My use case is daily location tracking, and with activities being able to span days, it’s important to me to know when a coordinate was visited. I guess I’ll have to use the same approach I have with polylines, and dumbly interpolate based on the start time and duration. :-(

​@gerwitz It’s not quite as bad, because you can request the time stream explicitely together with all the other stream types and then it is the same as before. At least I couldn’t determine any difference between the former implicit time stream when using the series_type parameter and the time stream when requesting it in the keys parameter.

Ah, I see. This doesn’t cause me any trouble, except that perhaps I won’t get many points when no distance has been accumulated. That was useful for me detecting “dwells” but is not at all critical.

Still, I am annoyed at the lack of API versioning discipline!

Even for indoor activities with no distance the result claims it’s a series_type=distance so I believe this series_type is just irrelevant and useless.

I now am getting a CORS error when fetching that endpoint that was working until today...

Are you sure it was removed in the documentation? I still see the following (https://developers.strava.com/docs/reference/#api-models-BaseStream):
 

I just discovered that we're getting the "distance" stream type even when we request "time," but this happens in cases where we're not getting the "time stream" either. We need to investigate further what data we're getting in different cases (different Strava data sources).

We reported the issue to Strava, because we noted that the order in the keys parameter array of the GET streams query influences which data types are returned in the JSON array. There is currently something really weird with the GET activities streams API. Let's hope Strava will clarify what changed and what is a bug, and stabilize the API soon.

​@hophoff The docu for the basestream is only for the response json. I’m not completely sure but I would say the series_type was at some time listed as a possible parameter for the GET, else I wouldn’t have used it for years.

Since yesterday I always request the time stream in the keys parameter too.

I am also having issues with the streams in the API. The format of the response has changed. It should, according to the documentation and my implementation, return an array. In the last week the response has changed to return an object.

I am also having issues with the streams in the API. The format of the response has changed. It should, according to the documentation and my implementation, return an array. In the last week the response has changed to return an object.

 

 

This looks like a bug, I suggest to report it to Strava. But the main reason this happens is that you don't get the requested streams, in your case the ‘altitude’ stream in combination with distance and/or time. Normally you should get the distance or time stream in the result also, then there are at least two stream objects, and the result will be an array. 

You can try to add time and/or distance to the request, hopefully that solves the issue.

Strava just informed us that the issue with the different results for different ordering of the keys parameter array has been resolved. We tested it and it works fine again. So if you request both time, distance, ...]  with additional stream types, then you should get all the requested streams, independent of the order of the stream types in the array.