Traff: A universal format for live traffic information
traffxml.gitlab.io
traffxml.gitlab.io
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.
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.
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.
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
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.
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].
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.