Is the server usable to set up a public OpenStreetMap-like traffic server where users can install trivial apps on their phones just like Google does for all the Android users (edit) to submit their own anonymized traffic information?
https://traffxml.gitlab.io/ seems to be a better landing page than the submission URL which just contains a bunch of loosely organized git repositories.
What the above describes is Navit receiving traffic information, I want Navit (or ideally, an even simpler app) to submit data to an open source traffic server.
The idea is to crowd-collect traffic information just like how Google does it (monitoring speed of those who have their Android phones with Google GPS services on, but out of willing participants): basically transparent to the users (other than them having to install the app and then figure out a way to allow them to run it in the background on recent Android systems :).
I'd feel much more comfortable submitting to a server where I've got full control of the data it emits (I can better ensure it retains my privacy by using new route ids often, for instance).
Seems to be public traces the public are submitting willingly. What's missing is a service to integrate that data into the map view/routing, unless this is exactly what Traff integrates as well, unsure.
Basically, Google knows a road is congested by having dozens of people (with their Android phones and location services turned on) slow down on a road where they would usually go much faster.
I want the same thing with better privacy guarantees and that's open source and free to use.
You’re looking for a sensor fabric that can track mobile devices with their signal strength and time of flight, as it’s likely you’ll never get enough critical mass of devices to do this with open source apps. This allows you to distill traffic velocity without device access or onboard device telemetry being shipped.
Google can do this because they control the Android and Google Maps ecosystem. Without such scale, you’re at a significant disadvantage.
But the same variation in resources holds true for eg. Google Maps vs OpenStreetMaps, yet OSM is still sometimes much better than GMaps. And Google also crowdsources their data even with all the resources at their disposal.
Whether there'd be a critical mass depends on a lot of factors, and it's a safe bet that there wouldn't be one. But I would wish us to try :)
FWIW, there would huge commercial interests for other parties to provide these, eg all the taxi and delivery services could have their drivers participate, while allowing their app developers to integrate that traffic information into their own route estimations and optimizations.
Btw, your suggestions make me think of another interesting approach that local governments could take.
Instead of devices reporting themselves, we could have hotspots observing mobile phone signals (eg. integrate them into traffic lights): we'd need at least 3 nearby for triangulation, and they'd have to be everywhere, so it would require government support and desire to provide traffic info for the public.
I was a bit unclear: I want to submit anonymized traffic information to an open source traffic server, just like how Google uses Android phones' speeds to guess what roads are congested.
Slightly off topic, but it would be nice if there was an option for a group-level Readme on Gitlab. Seeing a collection of projects doesn't tell me much about what is going on.
The view is now sorted by last created by default. Maybe most stars https://gitlab.com/traffxml?sort=stars_desc (and last created for repos with the same starts) is a better default sort?
Why can't there be a group-level setting that allows me to designate any Markdown file in any of the repos in the group as the group-level readme? You could even make a filename such as GroupReadme.md a reserved name that can only be used once in a group. I could also see someone possibly wanting to move that file -- and it's history -- to another repo as a group matures: you start with repos like "API" and "WebUI" but eventually a "Docs" repo could be created as proof of concept solidifies and accumulates personnel and ceremony.
A traffic service could integrate the live data with say, weekly patterns detected in public OpenStreetMap GPS traces, to get better estimates of actual conditions:
Honestly, why XML? Isn't JSON 100 times better, smaller and easy to use than XML? why choose a legacy format (with known security problems in parsers, compability, and unnecessary use of bandwidth) in 2022?
Tooling around JSON schema is lacking. For example, we have a fairly simple XSD which still requires the latest JSON schema version due to a choice element (IIRC), which Swagger doesn't fully support yet.
I think the reason is that mostly people don't define schemas for their json to begin with.
Back when xml was still commonly used, xml schemas were optional as well. The notion of insisting on adding longish urls to every attribute and namespacing elements and attributes, kind of defeated the purpose of using xml. It made everything harder; including parsing, xsl transformations, xpath expressions, etc.
> Isn't JSON 100 times better, smaller and easy to use than XML?
Quite certainly not. It's not even more popular if HTML is included.
It may be smaller, but not nessecarily so: both json and XML are easy to compress due to repetitive (overhead) characters. Uncompressed it depends on the use-case and implementation: the ability to have both attributes and content on a node, allow (but certainly not always are) XML to be smaller than JSON which does not have this.
Easy to use depends on the features: JSON is gaining complexity rapidly (json-ld, json-templates, jsonschemas etc) to fill up what XML can do OOTB. Sure: an all-out XML (XMLT, DTD, etc) is far more complex than a simple JSON. But hardly more than a JSON with JSTL, JSon-schema etc. The exact same performance and security problems arise in JSON with all these features bolted on.
In other words: "it depends". But the idea that "JSON is 100x better" is repeated oft in the tech scene, yet impossible to back up in general. JSON may certainly be better for your case. But so can XML.
What?! You mean everyone is just endlessly reinventing the wheel? You mean they start out simple then quickly realise much of the complexity of the prior is useful?!
I wouldn't call JSON a reinvented wheel. It has different tradeoffs, and so fills a real niche that XML couldn't.
However, we, the engineering community tend to fall in this hammer-nail mindset. Where we know and like JSON, and then start applying it outside of its fitting niche.
We start using it for configuration (only to find out it's lack of features such as not allowing comments makes it fully unusable).
We invent stuff like symlinks, linked data, schemas, JSLT, etc. rather than moving to a much more appropriate format, we change the inappropriate format into an abomination.
With EXI encoding the format XML is many times smaller than Json, it can uses XSD to have a scheme aware compression, and it is better structured with XSD.
That's really cool, but it seems to be monthly/annual data. I wonder how much longer before there are service providers with satellites providing live hourly traffic data without needing some sort of ground support. Something that can compete with Google's live traffic, which I imagine pulls data from the location of their ubiquitous phones...
Once, just once, I would like a traffic routing or analysis system to comprehend the concept of lanes.
There's no point coloring a segment red if I'm turning right, when all the slow-moving traffic is waiting for a left. Anyone who spends more than a day driving a car in a populous area will recognize this.
I noticed that Traff can represent blocked or closed lanes as individual events, but otherwise considers "fast" and "slow" traffic only at the scale of streets and roads.
41 comments
[ 3.2 ms ] story [ 27.2 ms ] threadhttps://traffxml.gitlab.io/ seems to be a better landing page than the submission URL which just contains a bunch of loosely organized git repositories.
What the above describes is Navit receiving traffic information, I want Navit (or ideally, an even simpler app) to submit data to an open source traffic server.
The idea is to crowd-collect traffic information just like how Google does it (monitoring speed of those who have their Android phones with Google GPS services on, but out of willing participants): basically transparent to the users (other than them having to install the app and then figure out a way to allow them to run it in the background on recent Android systems :).
I'd feel much more comfortable submitting to a server where I've got full control of the data it emits (I can better ensure it retains my privacy by using new route ids often, for instance).
Seems to be public traces the public are submitting willingly. What's missing is a service to integrate that data into the map view/routing, unless this is exactly what Traff integrates as well, unsure.
Basically, Google knows a road is congested by having dozens of people (with their Android phones and location services turned on) slow down on a road where they would usually go much faster.
I want the same thing with better privacy guarantees and that's open source and free to use.
Google can do this because they control the Android and Google Maps ecosystem. Without such scale, you’re at a significant disadvantage.
But the same variation in resources holds true for eg. Google Maps vs OpenStreetMaps, yet OSM is still sometimes much better than GMaps. And Google also crowdsources their data even with all the resources at their disposal.
Whether there'd be a critical mass depends on a lot of factors, and it's a safe bet that there wouldn't be one. But I would wish us to try :)
FWIW, there would huge commercial interests for other parties to provide these, eg all the taxi and delivery services could have their drivers participate, while allowing their app developers to integrate that traffic information into their own route estimations and optimizations.
Instead of devices reporting themselves, we could have hotspots observing mobile phone signals (eg. integrate them into traffic lights): we'd need at least 3 nearby for triangulation, and they'd have to be everywhere, so it would require government support and desire to provide traffic info for the public.
[0] https://gitlab.com/traffxml/traff-server
For info beyond the code repo there is this: https://traffxml.gitlab.io/#about
BTW The repo with the specification seems to be https://gitlab.com/traffxml/traff and it contains a presentation with more context https://gitlab.com/traffxml/traff/-/blob/master/TraFF%20Pres...
> it would be nice if there was an option for a group-level Readme on Gitlab.
Thanks for the idea. The proposal for Group READMEs is discussed in this thread: https://gitlab.com/gitlab-org/gitlab/-/issues/15041#note_102... Suggest adding your preferences for the proposed solutions, thanks.
https://en.wikipedia.org/wiki/Traffic_message_channel#Functi...
https://gitlab.com/traffxml/traff/raw/master/TraFF%20Specifi...
> The approach chosen is essentially based upon the following principles:
> • Use the TMC data model as a starting point
https://www.openstreetmap.org/traces
Back when xml was still commonly used, xml schemas were optional as well. The notion of insisting on adding longish urls to every attribute and namespacing elements and attributes, kind of defeated the purpose of using xml. It made everything harder; including parsing, xsl transformations, xpath expressions, etc.
Who thought this was a good idea?
Quite certainly not. It's not even more popular if HTML is included.
It may be smaller, but not nessecarily so: both json and XML are easy to compress due to repetitive (overhead) characters. Uncompressed it depends on the use-case and implementation: the ability to have both attributes and content on a node, allow (but certainly not always are) XML to be smaller than JSON which does not have this.
Easy to use depends on the features: JSON is gaining complexity rapidly (json-ld, json-templates, jsonschemas etc) to fill up what XML can do OOTB. Sure: an all-out XML (XMLT, DTD, etc) is far more complex than a simple JSON. But hardly more than a JSON with JSTL, JSon-schema etc. The exact same performance and security problems arise in JSON with all these features bolted on.
In other words: "it depends". But the idea that "JSON is 100x better" is repeated oft in the tech scene, yet impossible to back up in general. JSON may certainly be better for your case. But so can XML.
Nowadays HTML is not XML anymore [1].
[1]: https://stackoverflow.com/a/39560454/735926
Well I never!
However, we, the engineering community tend to fall in this hammer-nail mindset. Where we know and like JSON, and then start applying it outside of its fitting niche.
We start using it for configuration (only to find out it's lack of features such as not allowing comments makes it fully unusable).
We invent stuff like symlinks, linked data, schemas, JSLT, etc. rather than moving to a much more appropriate format, we change the inappropriate format into an abomination.
https://www.w3.org/TR/exi/
There's no point coloring a segment red if I'm turning right, when all the slow-moving traffic is waiting for a left. Anyone who spends more than a day driving a car in a populous area will recognize this.
I noticed that Traff can represent blocked or closed lanes as individual events, but otherwise considers "fast" and "slow" traffic only at the scale of streets and roads.
Guess I will be waiting longer, still.