Citation very much needed for that!
OSM data gets everywhere and most commercial providers of map data use much “cleaner” styles that allow easier over-the-top display of other information (which is what most uses are for).
5 Likes
go to Discord and see for yourself what people use to visualise their mapping
- PAA Radiation Monitoring Map Państwowa Agencja Atomistyki
- GUS Geostatistics Portal Główny Urząd Statystyczny
- CANARD Speed Camera Map (Główny Inspektorat Transportu Drogowego):
- Bank Danych o Lasach (BDL): The National Forest Data Bank
- National Geoportal (Geoportal.gov.pl)
A few examples from Poland. Feel free to link some of your country.
carto use in different services is supposedly estimated ~100,000 to 150,000
But lets say it’s not carto that is the most widespread for OSM, then what is? How do you use that finding to gain the discussion?
Strava claims 200 million users, that’d be up there I guess.
1 Like
Uhm… thinking… The main road does not seem te be rendered at all? If it were rendered, it would cover the gap, right? In my thinking, I assumed that the main road would be rendered.
It depends what you consider “widespread”.
Most people probably see OSM-based maps via third-party apps*. Pokémon GO alone is 55mln users, but in Poland we have very popular apps like Yanosik or jakdojade which also use osm but not carto.
Although Carto is probably the most used as “background”. If you want to show your data and you need a background map Carto is a good choice as it shows a lot of things and it’s free to use.
*I know that carto is technically third-party too. But I don’t know how to call it.
1 Like
Were you REALLY expecting a map made by ME to render “the main road”? Surely at this point you know me better than that 
2 Likes
Jokes aside, even with the middle carriageway is rendered, you need to know when to stop rendering the cycle track, so it doesn’t extend beyond where the centre-link line “leaves” the cycle track on its way out to the separated cycleway. It’s a task.
That is something one can never do right due to logic of OSM mapping that is a compromise between detail and routing.
Especially for big carridgeways with turn lanes at intersections with traffic islands, that is the exact thing that happens, When branching from the main highway way when do it so the geometry looks somewhat okey and at the same time tagging lanes, the distances are of course somewhat vague, but not critically too much.
Can one add those “links” around kerbed traffic islands or should they be around painted ones as well?
When small kerbed island extend with a looong painted one, then merge that “link” through it or only when the painted island ends?
Yeah, there are even more problems with carriadgeways than there are with foot/cycle ways. It’s always about compromising detail, though when tactile_paving is present, that is when it’s especially usefull to draw em separatelly to provide more detail to people with sight disablities.
With carriadgeways those tactiles mapping is not necessary, but autonomous vehicles are somewhat “blind” as well and could use those details that the OSM model compromises.
There is a way to do it, but as long as you don’t know the width of the road, you might not get to the correct offset. And you need to match the correct position of two or three nodes perpendicular to the road.
Let me try to explain how that works. Below is an image of the iD editor from the place I’ve used as an example. Note: the aerial photos are old, so they don’t provide much help here.
In this place, there is a cycle track coming from the south-west (lower left in the image) going toward the north-east (upper right in the image). The cycle track is two-sided from the south-west, but at the node labelled 2-1 in the image, the right-hand cycle track becomes a separated cycleway.
The yellow line is tagged cycleway=track until node 2-1, when it instead becomes cycleway:left=track. At the same lateral (perpendicular) position as node 2-1, the separated cycleway starts at the node labelled 2-2. It’s important that the lateral position of those two nodes is the same, since this is the real world position where the cycle track ends and the cycleway starts. The reason they are not the same point in OSM is because the cycle track is mapped on the centre line.
The line between node 1 and node 2-2 is the virtual connector link for routing purposes. The position of node 1 isn’t important, but it should be far enough away from node 2-2 to make the navigation software go “keep right onto cycleway” instead of saying “turn 90 degrees right unto cycleway”.
The left-hand cycle track (going the opposite direction, towards south-west) starts at node 3-1. So the centre line is tagged cycleway:left=track between node 2-1 and 3-1. Node 3-1 and 3-2 need to be in the same lateral position to correctly position where the cycleway ends and the cycle track starts.
The line between node 3-2 and 2-1 is the same virtual connector link as previously described between node 1 and 2-2.
Everything in this image is OTG truth, except for the two virtual links highlighted in yellow that are there only for navigation purposes. The cycle track is tagged correctly on the centre line, and the cycleway lines are placed correctly from where they are in the real world.
My map doesn’t render the virtual links, and assumes a road width to offset the cycle tracks, so you get the result below..
2 Likes
okey, so i understand your map representation then. It’s very smart that you actually attempt to render separatelly the ways tagged on carriadgeway. Thats likelly much easier when width is set, (but then i wonder what should be the width=* and what should be the cycleway:right:width=* when its separated from the lanes by area of painted lines or say a traffic island)
But i gotta disagree that
in a way as precise as when it’d be mapped separatelly
Since there is no standarised way to do it, everyone does it vaguelly by feel.
Even in your example the triangle [2-1 3-1 3-2] is smaller then the [1 2-1 2-2] and for a rendering software this is real hard to gues. Sure we could utilise AI to gues it and likelly with good results… but then we could start mapping with AI aid to make it standarized as data is saved to the database.
The work you’re trying to do is real important, but IMO the OSM logic gotta evolve at some point. And that’s why your work is important, so it can be done smart and people actually understand what’s the goal.
I didn’t mean that it is equally precise. Just that it is possible.
They don’t need to match in size. Like I said, the virtual links are purely for navigation and their “angle” is only there to make sure navigation software doesn’t say “turn 90 degrees” or something like that.
Other map renderers typically prioritise “the main road”, and don’t ignore virtual links, so the virtual links are rendered when they go beyond the assumed road width – which means it looks topologically correct in these maps.
That’s what I had in mind. If the edge of the main road shows that there is a cycle track, then the rendering shows nice connectivity for cycling, albeit not exactly positioned.
Absolutely. But when either of those two conditions fail (rendering “the main road”, and rendering it on top), it no longer connects.
I thought yes, that makes sense, but then again: not rendering the main road, but rendering the cycleway=track as if the road were rendered, still would give you visual connectivity?
Doing that properly involves computations that we are not able to express in the rendering configuration. We can’t express that the start of the cycleway is the intersection of the virtual link line with the offset cycle track line.
Either you render something from X to Y, or you don’t. You could render it in the background colour, so it is “invisible”, but then the cycleway won’t have the proper look – it will look cut off rather than having the correct borders.