Integrate Traffic Data

jwsp1 commented

2021-08-22 17:42:51 +00:00

(Migrated from github.com)

There is an API for traffic data for the German highways: https://github.com/bundesAPI/autobahn-api (in German).

I guess it is much effort to implement the data but it can still be a first step of an enhancement to know about heavy traffic or closed highways.

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

There is an API for traffic data for the German highways: https://github.com/bundesAPI/autobahn-api (in German). I guess it is much effort to implement the data but it can still be a first step of an enhancement to know about heavy traffic or closed highways.  ## Upvote & Fund - We're using [Polar.sh](https://polar.sh/organicmaps) so you can upvote and help fund this issue. - We receive the funding once the issue is completed & confirmed by you. - Thank you in advance for helping prioritize & fund our backlog. <a href="https://polar.sh/organicmaps/organicmaps/issues/1160"> <picture> <source media="(prefers-color-scheme: dark)" srcset="https://polar.sh/api/github/organicmaps/organicmaps/issues/1160/pledge.svg?darkmode=1"> <img alt="Fund with Polar" src="https://polar.sh/api/github/organicmaps/organicmaps/issues/1160/pledge.svg"> </picture> </a>

👍 34 👀 1 ❤️ 9 🚀 2

dumblob commented

2022-06-22 10:06:05 +00:00

(Migrated from github.com)

This (and other countries) is an essential necessity for real world car navigation. It is also the only reason I stay with Google Maps.

Related topic is rerouting based on traffic jams computed from the real-time position of users of OM (of course with asking them first to provide this data voluntarily) and the expected speed on the given part of the track (taking into account all traffic lights, turns, etc.).

This (and other countries) is an essential necessity for real world car navigation. It is also the only reason I stay with Google Maps. Related topic is rerouting based on traffic jams computed from the real-time position of users of OM (of course with asking them first to provide this data voluntarily) and the expected speed on the given part of the track (taking into account all traffic lights, turns, etc.).

👍 4

hermann-san commented

2022-07-07 07:47:24 +00:00

(Migrated from github.com)

OSM and has the same issue of missing traffic data. Maybe there can be some collaboration with them or some hint's on how to make some progress
https://github.com/osmandapp/OsmAnd/issues/6878

OSM and has the same issue of missing traffic data. Maybe there can be some collaboration with them or some hint's on how to make some progress https://github.com/osmandapp/OsmAnd/issues/6878

👍 15

SlouchyButton commented

2022-08-11 12:34:31 +00:00

(Migrated from github.com)

I'd like to add that for Czechia it is possible to retrieve the traffic information for free in XML (and DATEX II, but never heard of that) live - https://dopravniinfo.cz/cs/pages/data-from-jsdi/traffic-information. They should also contain (apart from traffic jams) all traffic incidents (crashes, closures etc.) and expected time to finish the event (finishing works on road or removing crashed cars).

I'd propose that for a sake of usability, the navigation algorithm should be changed, so it can work with traffic information and create some way in which we could implement individual traffic provider sources into the app. My knowledge with C++ and C is very limited for any in depth help with this, but I'd very gladly try to implement the Czech traffic information.

Down the road the system could be expanded with optional sending of current location with speed to servers for "in-house" traffic data not depended on any 3rd party.

I'd like to add that for Czechia it is possible to retrieve the traffic information for free in XML (and DATEX II, but never heard of that) live - https://dopravniinfo.cz/cs/pages/data-from-jsdi/traffic-information. They should also contain (apart from traffic jams) all traffic incidents (crashes, closures etc.) and expected time to finish the event (finishing works on road or removing crashed cars). I'd propose that for a sake of usability, the navigation algorithm should be changed, so it can work with traffic information and create some way in which we could implement individual traffic provider sources into the app. My knowledge with C++ and C is very limited for any in depth help with this, but I'd very gladly try to implement the Czech traffic information. Down the road the system could be expanded with _optional_ sending of current location with speed to servers for "in-house" traffic data not depended on any 3rd party.

👍 3 🎉 1

biodranik commented

2022-08-11 22:00:30 +00:00

(Migrated from github.com)

Of course, the server should collect and pre-process traffic data, not millions of clients. Otherwise, that free public API will be DDOSed and closed.

It is a good idea to make an aggregate issue with a list of all publicly available sources/countries, so we can have a good starting point.

Are there already some aggregators for information like that?

Of course, the server should collect and pre-process traffic data, not millions of clients. Otherwise, that free public API will be DDOSed and closed. It is a good idea to make an aggregate issue with a list of all publicly available sources/countries, so we can have a good starting point. Are there already some aggregators for information like that?

SlouchyButton commented

2022-08-12 12:02:08 +00:00

(Migrated from github.com)

@biodranik I don't think there is in this project. When researching I found one source of these traffic APIs for different countries, but it seemed outdated (was on OSM wiki if I remember correctly). I propose making a wiki page with a table where we could link all the public (and/or private) traffic APIs for future reference. I could try and look up if other countries (except DE and CZ) has something like this and make more comprehensive list.

Personally, I'd try to gather information directly from the official sources of individual countries. I expect most of them should be free, since it is official source. Going the route of paid plug-in, or subscription service doesn't seem a viable option, because there are many alternative free navigation apps. Having this pretty crucial feature behind paywall would inevitably hurt the app.

You mentioned a server collecting this data and processing it. If needed, I can provide server for backend as I have business in web dev, and I own a physical server located in the Czech Republic, Brno. (Have no idea what are current options for backend servers for this app)

Regarding the OsmAnd and OrganicMaps collaboration (as proposed by @hermann-san ), there is one possibly mutually beneficial way of collaborating. If both apps implemented the optional location and speed tracking for their users, both apps would have much bigger user base together. This would result in much more accurate information about traffic, than would be possible to achieve only relying on the user base of one of the apps. I would understand any privacy concerns regarding this feature, but this could be implemented in a privacy respecting way and on an optional basis. Together with open source nature of app, it could be fully transparent and work mainly as a supplement for the official sources.

@biodranik I don't think there is in this project. When researching I found one source of these traffic APIs for different countries, but it seemed outdated (was on OSM wiki if I remember correctly). I propose making a wiki page with a table where we could link all the public (and/or private) traffic APIs for future reference. I could try and look up if other countries (except DE and CZ) has something like this and make more comprehensive list. Personally, I'd try to gather information directly from the official sources of individual countries. I expect most of them should be free, since it is official source. Going the route of paid plug-in, or subscription service doesn't seem a viable option, because there are many alternative free navigation apps. Having this pretty crucial feature behind paywall would inevitably hurt the app. You mentioned a server collecting this data and processing it. If needed, I can provide server for backend as I have business in web dev, and I own a physical server located in the Czech Republic, Brno. (Have no idea what are current options for backend servers for this app) Regarding the OsmAnd and OrganicMaps collaboration (as proposed by @hermann-san ), there is one possibly mutually beneficial way of collaborating. If both apps implemented the _optional_ location and speed tracking for their users, both apps would have much bigger user base together. This would result in much more accurate information about traffic, than would be possible to achieve only relying on the user base of one of the apps. I would understand any privacy concerns regarding this feature, but this could be implemented in a privacy respecting way and on an optional basis. Together with open source nature of app, it could be fully transparent and work mainly as a supplement for the official sources.

👍 5

baarkerlounger commented

2022-09-28 15:48:39 +00:00

(Migrated from github.com)

In England National Highways provides a similar API that can be used free of charge for traffic data in DATEX II format.

https://www.trafficengland.com/services-info

They also publish Java and C# libraries for processing it https://github.com/SaturnEclipseUK

In England National Highways provides a similar API that can be used free of charge for traffic data in DATEX II format. https://www.trafficengland.com/services-info They also publish Java and C# libraries for processing it https://github.com/SaturnEclipseUK

dumblob commented

2022-10-05 09:44:19 +00:00

(Migrated from github.com)

Hey everybody!

I just stumbled upon an open source project which seems to actively gather real-time traffic data in a multinational manner.

https://traffxml.gitlab.io/ (https://gitlab.com/traffxml )

Thery also have an Android app RoadEagle.

Could you get in contact with them ( info@traffxml.org ).

Btw. Navit seems to use their traffic data. @metalstrolch @bkoppelmann @jkoan @OLFDB @mvglasow and others could maybe know something more.

Hey everybody! I just stumbled upon an open source project which seems to actively gather real-time traffic data in a multinational manner. https://traffxml.gitlab.io/ (https://gitlab.com/traffxml ) Thery also have an Android app [RoadEagle](https://gitlab.com/traffxml/roadeagle ). Could you get in contact with them ( info@traffxml.org ). Btw. [Navit](https://github.com/navit-gps/navit ) seems to use their traffic data. @metalstrolch @bkoppelmann @jkoan @OLFDB @mvglasow and others could maybe know something more.

👍 5

mvglasow commented

2022-10-05 19:00:37 +00:00

(Migrated from github.com)

Yes, TraFF is my project (so far I’ve been alone on this, but contributions will certainly be welcome).

Just to give you an idea of what TraFF is: at its core, there is an open data format for traffic information, designed for fully machine-parseable event information, independent of the underlying map.

On the software side, there is a library to parse and generate feeds in the TraFF XML format, as well as import libraries for a bunch of formats, including the Datex II format, which is widely used in the EU.

As for the software ecosystem, so far there are three workable products:

Navit, a navigation system which processes TraFF data (this feature is currently available on Android only)
RoadEagle, an Android app which reads traffic information from a number of sources and makes them available on screen as well as in TraFF format (currently with support for Poland, Lithuania and Latvia)
Qz, another Android app which can receive TMC data via an external hardware device and makes it available on screen as well as in TraFF format (works in a number of places in western an d central Europe)

A TraFF server (which would aggregate data from various sources and make them available in TraFF format via an API) is in the works. Future clients could then directly connect to a TraFF server, rather than tap into sources locally. This would also allow for integration of a bunch of additional sources, which are not feasible to process with an Android app (e.g. the Datex-II library relies on components not available on Android, and the Czech service mentioned above requires running a server at a static IP address).

The source code for all of this can be found at https://gitlab.com/traffxml (the only exception being Qz, which lives at https://gitlab.com/mvglasow/qz.)

Main obstacle to implementing all of this is my own limited free time – as I said, if anyone would like to participate in the further development of TraFF, I’d be more than happy.

As for the German API, I have come across that before. While its authors look official (“Bundesstelle für Open Data”), they are actually an activist organization. I am not sure where exactly they pull their data from and under what terms. It might be a legal gray area in the sense that they do not have a formal license to use the data, but since all it was ever intended for is to power a free-of-charge app, nobody has objected to this usage so far.

However, Germany does offer some sources of traffic data which are officially free to use. Visit https://mcloud.de and search for “Datex”, which will give you a bunch of sources in Datex-II format. (The TraFF Datex-II converter will convert that into TraFF, though you might need some external data to decode the locations.)

As for TraFF, there is a list of potential sources at https://gitlab.com/traffxml/roadeagle/-/wikis/Data-Sources.

Yes, TraFF is my project (so far I’ve been alone on this, but contributions will certainly be welcome). Just to give you an idea of what TraFF is: at its core, there is an open data format for traffic information, designed for fully machine-parseable event information, independent of the underlying map. On the software side, there is a library to parse and generate feeds in the TraFF XML format, as well as import libraries for a bunch of formats, including the Datex II format, which is widely used in the EU. As for the software ecosystem, so far there are three workable products: * Navit, a navigation system which processes TraFF data (this feature is currently available on Android only) * RoadEagle, an Android app which reads traffic information from a number of sources and makes them available on screen as well as in TraFF format (currently with support for Poland, Lithuania and Latvia) * Qz, another Android app which can receive TMC data via an external hardware device and makes it available on screen as well as in TraFF format (works in a number of places in western an d central Europe) A TraFF server (which would aggregate data from various sources and make them available in TraFF format via an API) is in the works. Future clients could then directly connect to a TraFF server, rather than tap into sources locally. This would also allow for integration of a bunch of additional sources, which are not feasible to process with an Android app (e.g. the Datex-II library relies on components not available on Android, and the Czech service mentioned above requires running a server at a static IP address). The source code for all of this can be found at https://gitlab.com/traffxml (the only exception being Qz, which lives at https://gitlab.com/mvglasow/qz.) Main obstacle to implementing all of this is my own limited free time – as I said, if anyone would like to participate in the further development of TraFF, I’d be more than happy. As for the German API, I have come across that before. While its authors look official (“Bundesstelle für Open Data”), they are actually an activist organization. I am not sure where exactly they pull their data from and under what terms. It might be a legal gray area in the sense that they do not have a formal license to use the data, but since all it was ever intended for is to power a free-of-charge app, nobody has objected to this usage so far. However, Germany does offer some sources of traffic data which are officially free to use. Visit https://mcloud.de and search for “Datex”, which will give you a bunch of sources in Datex-II format. (The TraFF Datex-II converter will convert that into TraFF, though you might need some external data to decode the locations.) As for TraFF, there is a list of potential sources at https://gitlab.com/traffxml/roadeagle/-/wikis/Data-Sources.

👍 13

dumblob commented

2022-12-17 18:11:31 +00:00

(Migrated from github.com)

Potentially related: https://github.com/organicmaps/organicmaps/discussions/4102 (Overture Maps Foundation - seems governed by Linux Foundation).

👍 2

gerion0 commented

2023-01-01 12:06:00 +00:00

(Migrated from github.com)

As for the German API, I have come across that before. While its authors look official (“Bundesstelle für Open Data”), they are actually an activist organization. I am not sure where exactly they pull their data from and under what terms. It might be a legal gray area in the sense that they do not have a formal license to use the data, but since all it was ever intended for is to power a free-of-charge app, nobody has objected to this usage so far.

The "Bundesstelle für Open Data" only documents the API for data that are provided officially by the government.
In this case let me translate the README of the link Autobahn App API:

The BMVI (official department) built a completely useless app. An autobahn information app
See: https://autobahn.api.bund.dev/

Really completely useless?
No, since there is a public API for up-to-date data with regard to construction side information, webcams, parking places, ... - surely useful for someone.

So to say, while the API documentation is inofficial, the information itself comes directly from autobahn.de which is a official website of the Autobahn GmbH which belongs to the government.

> As for the German API, I have come across that before. While its authors look official (“Bundesstelle für Open Data”), they are actually an activist organization. I am not sure where exactly they pull their data from and under what terms. It might be a legal gray area in the sense that they do not have a formal license to use the data, but since all it was ever intended for is to power a free-of-charge app, nobody has objected to this usage so far. The "Bundesstelle für Open Data" only documents the API for data that are provided officially by the government. In this case let me translate the README of the link [Autobahn App API](https://github.com/bundesAPI/autobahn-api): > The BMVI (official department) built a completely useless app. An autobahn information app > See: https://autobahn.api.bund.dev/ > Really completely useless? > No, since there is a public API for up-to-date data with regard to construction side information, webcams, parking places, ... - surely useful for someone. So to say, while the API documentation is inofficial, the information itself comes directly from autobahn.de which is a official website of the Autobahn GmbH which belongs to the government.

Rows
Columns

Integrate Traffic Data #1160

Upvote & Fund