It’s an undocumented tag and seems to be entirely for renderer use (although AFAIK there are no renderers that use it). They were mostly added ~6 years ago. There’s no benefit to it as curved geometry can be detected and smoothed automatically without these nodes, purely based on the angle difference.
this tag would also be a pain to maintain, as (I assume) it requires every curve to have the tags.
This originally came from an abandoned proposal. I’ve seen a few of them in my area and have always deleted them on sight. The proposal seems to misunderstand how simplification algorithms work anyhow. There’s a related turning_radius experiment that is at least more grounded in reality, but I don’t think that approach is workable either, given the variations in how road and railway curves are measured.
Shape simplification algorithms can automatically decide which nodes are important for the shape and which are not. No tagging needed.
The radius of a curve can also be automatically estimated from any sequence of 3 points (or more points for more numerical stability), so again no need for tagging.
This tag first crossed the DWG’s desk in 2016; I guess the proposal followed from that (and was later abandoned). Back in 2016 a person using the tag wrote to the person who had raised the issue with the DWG:
… One of the tags we use internally is “curve_geometry” which allows us to identify nodes that have geometrical importance. The reason this is needed on our end is because we filter nodes that have no navigation tags and, for simplicity and performance issues.
That was basically what I said in back 2016 too
The worry back in 2016 was that we’d get millions of these tags and a small subset of mappers annoyed when other mappers removed a tag of unknown meaning. That doesn’t seem to have happened; we have 12,000 tagged “curve_geometry=yes”
It doesn’t mean that adding them is a good idea though - hopefully the person adding the tags now can be persuaded to discuss it here.
For OSM purposes, yes. In theory, accurate turning radius data could help a router keep a long vehicle with a poor steering radius from taking a particular switchback where the signs don’t already restrict such a vehicle. But the proposed method would have been limited to only a subset of curves – not even the one pictured in the infobox that appears to curve on an incline. The curb-to-curb and wall-to-wall turning radius can differ, but the definition instead prefers the centerline-to-centerline radius, making its usefulness dubious for this one real-world use case.
Anyhow, turning_radius is only used a handful of times, so curve_geometry is the bigger fish to fry.
Does this consider the long-standing issue of intersections at transitions between divided and undivided roads? Lines are distorted there, especially for RHT right-turn around the street corner when the cross street is undivided. Also offset intersections, where type=connectivity is used.
Not saying curve_geometry=, or the existing definition and use of turning_radius= is good. But there are some real problems that can potentially be worked on.
The popular Ramer–Douglas–Peucker and Visvalingam–Whyatt algorithms do erase some contours and can break topological relationships when applied too aggressively (for example, causing neighboring areas to overlap or come apart). But these problems can be mitigated without resorting to tagging every curve that is subjectively “significant”. Use cases that involve simplification typically aren’t the ones that need to display, say, survey markers in the correct locations along their associated boundaries.
. But these problems can be mitigated without resorting to tagging every curve that is subjectively “significant”.
from our data model you cannot tell whether a line is meant to be round or should represent an angular line. With tags this distinction could potentially be expressed.
That’s not what this tag was proposed for anyhow. If I’m reading the proposal correctly, the idea is that a simplification algorithm shouldn’t cause the roadway to move away from a particular control point, but the tag doesn’t indicate whether it should be angled or curved. On the other hand, @erantr1 has been using it in some places to indicate that a sharp bend in the roadway should be sanded off and in other cases where I find it hard to believe that it would make any difference.
To be clear, I’m neutral on whether there should be a bulk cleanup of these tags, but I’m not going to bother maintaining them when I realign parking aisles and such. That realignment makes much more of a difference to aesthetics than any attempt at representing a Bézier curve as a single one-dimensional point.
I think that’s the key point - having cruft in the database that doesn’t get in anyone’s way shouldn’t be a problem for anyone, but having cruft that people actually have to maintain definitely is.
An example of the former that lives in the database and no-one cares about is the abutters key - it was widely used in the very early years of the project before the concept of landuse was a thing, but almost no-one uses it now.
I think it’s about indicating that a node is part of a curve by mapping two tangent points and one or two nodes in between. This way curves can be drawn and not just straight lines. The tag is good but nodes cannot be moved from one place to the other unless you know what you’re doing and sometimes the tag must be removed. Using this tag will probably cause chaos so I’m against using it.
It’s for professionals.
Edit: I’m not answering to Jeroen only. How can I change this?
That’s just the “unusual” way that this forum works. I tend to make it more obvious by manually quoting a bit of what I am replying to, like I did here.
Domain specific is fine. But tags that are brittle in subtle ways that aren’t obvious to a new user are problematic. If you use tags to define geometry in such a way that moving a point causes your geometry to be messed up, then you’re placing an undue maintenance burden on every other user.
As in the original message the usage is completely unknown. So how can you tell its brittle or what its used for.
Thats the whole point. You THINK thats its bullshit, your THINK its brittle, you have NO clue about the application and what to delete something the only point is that you dont have any information about.
And as there is no knowledge about its usage you cant even tell anything about maintenance burden as noone knows about it.
So just leave it alone. People who care shall maintain it. No burden for anyone else i can see.
