I would, in fact, keep event information in TraFF format, separate from OSM data, and map the location to OSM segments as needed: map data may change and people may inadvertently break tags they don’t understand. Also, some events are short-lived in nature (e.g. if roads are closed for a marathon, the closure lasts less than a day), which would clash with the OSM rule of anything that lasts for at least a week. To use this information in a renderer, navigation software or other, the location would need to be decoded to OSM ways (or parts thereof). This can be done using a plain old routing algorithm (Dijkstra, A* or similar) – cost would be way length with a penalty factor, based on how closely the attributes of the message location and the way match. Then, one way to provide this information would indeed be to map the OSM feature ID to generated tags. This, together with the way attributes, could then be used by a renderer, e.g. to produce a traffic layer on top of OSM, or a traffic map.

You might be interested in some work I’ve done previously.

I have drawn up a data exchange format for traffic information. This covers road closures but also has support for other event types like temporary speed limits, hazards and congestions.

There is also a web API for the transfer of feeds. Details on both at http://traffxml.org. The full specification is at https://gitlab.com/traffxml/traff.

TraFF does not use OpenLR but is based on end points (from/to), with at most one intermediate point, plus optional attributes (road ref, highway type) to aid matching. The idea is to make location references simple, and translatable from other formats. (Some other formats do not translate well into OpenLR linear locations unless you have a full map at hand for decoding and re-encoding.)

The web API is currently session-based (called subscriptions in TraFF). Apps (called consumers) subscribe to a certain region of the map, get an initial feed of the situation and can poll for updates. (Probably less of a concern with planned road closures, but vital if the data also includes unplanned events.) One-shot queries could be added if needed (right now one can just subscribe and unsubscribe after receiving the first feed).

There are some code resources at https://gitlab.com/traffxml, mostly in Java. They include a support library for the TraFF format, conversion libraries for a few agency-specific formats. There is also a server, but it is very much in it infancy, buggy and Java might not have been the best technology.

I’m aware of at least one other effort to implement a traffic server, though I am not sure if they are still active. See https://github.com/TobiPeterG/OSMTraffic and https://github.com/TobiPeterG/OSMTraffic-server.

https://gitlab.com/traffxml/roadeagle/-/wikis/Data-Sources has a list of potential data sources.

TraFF support has been added to Navit; I am currently adding it to the Organic Maps/CoMaps codebase (CoMaps is a fork of Organic Maps, and my work is based on code just before the fork, thus it could theoretically be added to both).

Take a look at TraFF and see if it suits your needs. The spec is still under development and can be extended if needed. If you have any questions regarding implementing location matching to a navigation app, I may be able to help – I am just doing this for the second time.

So, in short – the one thing we will need but don’t have yet is a central server, and it will make sense to have a universal server, not tied to one particular navigation app. Osmand is a major player but doesn’t seem to have any traffic support yet – adding that will certainly help the DB and API in achieving critical mass.

If any of this sounds interesting, drop me a message!

I guess so… alas, it has only one point per address. Too bad, I was hoping to find more geometry details, like the French have… but I can’t find that anywhere.

Does the opening refer just to address information, or is there other cadastre information we can use in OSM? Is there anything official from Registrų Centras about what data has been opened?

Im Carto-Stil sehe ich nur die lokalen Namen, aber Nominatim scheint hier zu “übersetzen”. Einfach mal in der Suche “Klaipėda” eingeben; in den Ergebnissen erscheint dann:

City Memel, Klaipėda City Municipality, Klaipeda County, Lithuania

Und das, obwohl mein Browser als Sprache Englisch anfordert. Sieht so as, als ob die Sprache hier über einen Geo-IP-Lookup ausgewählt wird. Erst wenn die hier ermittelte Sprache nicht angeboten wird, kommt zunächst die User Agent-Sprache zum Einsatz, erst dann der lokale Name. Aus meiner Sicht nicht optimal… hatte dazu mal ein Ticket eröffnet, aber da ist nicht viel passiert.

Off the top of my head, the following should work:

• Open the GPX track in JOSM.
• Download existing OSM data for the region.
• Right-click the GPX layer (in the Layers pane) and choose “Convert to data layer”. This should turn the GPX track into a way.
• Cut the way into pieces as needed and delete unneeded pieces.
• Tag the individual pieces as needed.
• Merge the two data layers (using the Layers pane).

Be aware, however, that this comes with a few pitfalls and it is all too easy to break something if you’re not careful. Keep in mind the following:

• You might want to run “Simplify way” on each converted GPX track before uploading it to OSM. Else you will end up creating lots of unnecessary points.
• Make sure the ends of your way are properly connected to existing ways (unless they end in the middle of nowhere). Else routing algorithms won’t be able to work with your newly-created ways.
• Make sure you’re not adding duplicate ways.
• Check accuracy of your GPX track (e.g. using aerial imagery or other GPX tracks, if available), and correct if necessary.

That being said, drawing roads by hand is usually the preferred way – unless you are mapping a blank area from scratch.

Die Qualität des GPS-Empfängers ist natürlich eine mögliche Fehlerquelle - das hängt vom Modell ab. Aber auch äußere Faktoren beeinflussen den GPS-Empfang und damit die Qualität der Tracks:

Zwischen hohen Gebäuden oder in Waldstücken gibt es die größten Ungenauigkeiten. Wichtig ist auch, wo du das Gerät trägst. Versuche herauszufinden, wo in deinem Gerät die GPS-Antenne untergebracht ist, und stelle sicher, dass dieses Ende des Geräts möglichst freie Sicht zum Himmel hat. Tief in der Hosen- oder Jackentasche ist der Empfang naturgemäß nicht besonders gut.

Wenn ich zu Fuß mappe, trage ich das Gerät meist in der Hand, für Fahrrad oder Auto habe ich einen Smartphone-Halter am Lenker bzw. Armaturenbrett, und zum Skifahren benutze ich ein Sportarmband. Letzteres ist nicht unbedingt optimal - hier habe ich die größten Abweichungen. (Mein altes Smartphone habe ich beim Skifahren unter dem Gummi der Skibrille eingeklemmt und mit einem Band plus Karabiner gegen Verlust gesichert, an meinem aktuellen kann ich keine Kordel festmachen.)

Auch Bumper/Gel Cases u.ä. habe ich im Verdacht, den GPS-Empfang zu verschlechtern - genau getestet habe ich es noch nicht, aber es ist eine zusätzliche Barriere zwischen Antenne und GPS-Satelliten.