Why aren’t non-fuctional telraam not removed from the map? I can see telraam cameras that didn’t send data since 2021 and earlier.
That’s a good question.
The point is that data that was gathered at the time is still useful for any data analysis that is done, so we want to show that the segment data does exist, even if it is not being added to at the moment.
With only a few thousand devices, this is not a problem, but maybe as we grow the number of devices and segments we may need to revisit this.
Is it causing any issues we’re maybe not aware of?
Ok, but i’m not a data-analyst. To me, the map now seems a bit chaotic and sloppy (just check Halle, Belgium). Maybe it is possible to add a layer for only functional devices?
Hi Stijn, inactive segments need to be visible, to allow anyone to check historic detailed data for that segment, but I agree it’s not looking pretty now.
We used to have a toggle between “live” and “historic”, but it created too big a load on the server. We’re in the process of redesigning it and reactivate that toggle, so the result would be a toggle, allowing to switch between only live segments, or all sgements that had counts at one point.
It’s on the list, can’t say when it’ll be live…
I’m attempting to produce my own map, using data from the Telraam API.
I decided to use Google Maps, because it’s used quite frequently by folks in my network, and I’ve used it before.
I’m using parabola.io to pull data from the Telraam APIs and then manipulate it, because it’s super easy to manipulate API responses into a format that’s useful to me.
Unfortunately when I try to map these locations, I noticed that the coordinates for segments are in “EPSGS 31370” format.
The traffic and traffic snapshot APIs return coordinates as lat/lon, so I can use this instead to give me the location of each segment.
I’m not familiar with EPSGS 31370 or the reasons why this might be preferable to using lat/lon. From my perspective, it makes the API harder to work with. What are the benefits of using EPSGS 31370 format in the API vs lat/lon?
Thanks!
Dave
1 Like
I’m not a data or mapping expert I’m afraid, but I have asked my colleague, and here are a couple pieces of advice which I hope answer this.
-
Use Open Street Map rather than Google Maps
-
Apparently, if you use the traffic snapshot or live traffic snapshot API it contains the right coordinates as these are meant for map-making. I think this might therefore not need parabola?
-
Regarding EPSGS 31370 … the answer is:
the EPSGS 31370 format is a leftover from the initial pilot when we were only limited to Belgium, and segments were coming from a Belgian database and not OpenStreetMap as they do now, so there are some old APIs that are still returning that format
Hi Robert,
Thanks for the quick reply!
There’s a property called hardware_version returned by the /cameras API which appears to show if the device is an S2. That property isn’t documented in the API docs, and doesn’t seem to be available in any other API. So for that reason, I have to query /cameras and also /traffic_snapshot and correlate the results. Maybe there’s an easier way to achieve this?
Regarding the Belgian-format coordinates - any visibility of this changing in the future?
And regarding OpenStreetMap … yeah, I should use it. Is this the best option? uMap ?
Thanks!
Dave
Hi Dave,
I added the hardware version to the documentation of the cameras API, that was indeed missing as it was not originally included there when the API was made. Thanks for pointing that out.
Since traffic snapshot is only available on segment level, there it does not make sense (or it is not very straightforward) to include a camera version field, as segments can (and some do) have multiple sensors and those can be different hardwares too. I do not recommend you polling the cameras API if you are making a map, everything a map needs (traffic volumes and segment geometries) is in the traffic snapshot API. If you are making a live map, always use the live traffic snapshot API, that is much much faster than the other one.
Those old APIs that are returning the Lambert projection x,y coordinates will not be changed (as that could be feature-breaking for some users), but we are not going to be adding new APIs with that system, only the standard EPSG:4326. All the APIs that we have added since the very first initial ones are using this system, it was an unfortunate oversight at the very beginning that we went for the Lambert system.
Cheers,
Peter
1 Like
Hi Peter,
Thanks for your response.
I’m aiming to create a map that shows the status and version of cameras, with a link to view the Telraam page for the segment. Here’s a work in progress:
The cameras API is the only endpoint that provides the version and status of the camera, as far as I see?
The camera API doesn’t provide coordinates, which is why I’m using the traffic snapshot API - and as you point out, that provides a sequence of points for the segment, not the camera position.
As I’m sure you know, it should be possible to avoid a breaking change by adding a new version of the segments API e.g. /v2/segments/all API that provides results in EPSG:4326 thereby providing consistent coordinates.
I looked into submitting a PR on Github, but I don’t see the API there. But if there’s anything I can do to help with this, please let me know!
Thanks 
Dave
2 Likes
Hi Dave,
nice map. In January 2024 we setup our dashboard.berlin-zaehlt.de (based on Elasticsearch/Logstash/Kibana) for analyzing Telraam data. One of the next steps is a table view which lists all devices in the Berlin area with the version and the current status. Currently you can select some controls to show the devices on the map. For this we will import each day at 12 o’clock the file https://berlin-zaehlt.de/csv/kibana/bzm_telraam_segments.geojson (based on the Traffic API) via Logstash into Elasticsearch.
Oh wow, that’s really impressive! I look forward to seeing what you do next. Will you post updates here or in the main forum?
Maybe in the main forum.