[HN Gopher] Traff: A universal format for live traffic information
___________________________________________________________________
Traff: A universal format for live traffic information
Author : KoftaBob
Score : 136 points
Date : 2022-10-20 09:19 UTC (13 hours ago)
(HTM) web link (traffxml.gitlab.io)
(TXT) w3m dump (traffxml.gitlab.io)
| noja wrote:
| Is this at all like RDS-TMC?
|
| https://en.wikipedia.org/wiki/Traffic_message_channel#Functi...
| danuker wrote:
| Yes, they even compare with TMC in the specification:
|
| 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
| cbolat wrote:
| 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?
| hokkos wrote:
| 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.
|
| https://www.w3.org/TR/exi/
| [deleted]
| berkes wrote:
| > 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.
| hk__2 wrote:
| > Quite certainly not. It's not even more popular if HTML is
| included.
|
| Nowadays HTML is not XML anymore [1].
|
| [1]: https://stackoverflow.com/a/39560454/735926
| sirsinsalot wrote:
| 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?!
|
| Well I never!
| thibaut_barrere wrote:
| Maybe because other standards
| (https://www.datex2.eu/datex2/about) in the same area are also
| XML based, I wonder :-)
| huggingmouth wrote:
| While i prefer json, I absolutly would not consider xml a
| legacy format.
| alexchamberlain wrote:
| It looks like the primary implementation is in Java, which is
| still all about SOAP services and XSDs.
| rschoultz wrote:
| We are on Java 19 now. Several that spits out the same
| sentiment as you seem to be stuck with Java 8 and EE legacy
| projects from 2012.
| magicalhippo wrote:
| 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.
| jillesvangurp wrote:
| 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.
| kybernetyk wrote:
| Json is terribly unstructured
| dewey wrote:
| There's https://json-schema.org for that.
| karussell wrote:
| If you lack the source data you might get them from official
| feeds. A few years ago I started to collect them:
| https://github.com/graphhopper/open-traffic-collection
| jolmg wrote:
| 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...
| necovek wrote:
| 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?
| 29083011397778 wrote:
| That's actually what this appears to be (though under the
| RoadEagle name on F-Droid). Looks like this [0] is the backend.
|
| [0] https://gitlab.com/traffxml/traff-server
| necovek wrote:
| 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.
| capableweb wrote:
| Seems so? https://traffxml.gitlab.io/app-navit.html (also at
| https://www.navit-project.org/ apparently)
|
| 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.
| necovek wrote:
| I am looking for the other direction.
|
| 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).
| capableweb wrote:
| Maybe this is more what you're looking for?
| https://www.openstreetmap.org/traces
|
| 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.
| necovek wrote:
| Nope: those are not anonimized nor real time.
|
| 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.
| toomuchtodo wrote:
| 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.
| llui85 wrote:
| See: https://traffxml.gitlab.io/ for a better summary.
| dang wrote:
| Ok, we've changed to that from https://gitlab.com/traffxml
| above. Thanks!
| danuker wrote:
| 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:
|
| https://www.openstreetmap.org/traces
| uoaei wrote:
| 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.
|
| Guess I will be waiting longer, still.
| mikece wrote:
| 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.
|
| For info beyond the code repo there is this:
| https://traffxml.gitlab.io/#about
| mikercampbell wrote:
| Same. I clicked the link and bounced because I wasn't sure
| which repo to open to get the basics, and wasn't willing to
| iterate through.
| sytse wrote:
| 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?
|
| 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/tr
| aff/-/blob/master/TraFF%20Pres...
| dnsmichi wrote:
| GitLab team member here.
|
| > 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.
| mikece wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-10-20 23:01 UTC)