A tag on a random node in a way without documentation (except an abandonded proposal from 2017) which can be removed or shifted anywhere without any error message IS bullshit.
If any application is making use of such tag there should be some documentation in the wiki as OSM is not a private project but a community project as far as I understand. So everyone should have simple access to information about what any tag is used for.
If someone comes across such nodes while finetuning ways and does not dare to touch or delete them because of being afraid to make a mistake it IS a burden.
And this tag is not some decent idea, it is a manual preprocessing again:
Some map processing applications disregard nodes along a way and only include the first/last nodes. This tag allows these significant nodes to be identified and included.
which is a terrible idea that should be ejected as soon as spotted
I’m pretty sure existing usage differs from the proposal in some fundamental way, but it’s hard to say exactly because the manner of usage was never documented. It’s a problem whenever someone single-handedly co-opts a tag without documenting why, and even to some extent after documenting why (as we saw in the service=driveway2 debacle).
I agree that we should maintain a degree of humility when dealing with any-tag-you-like mapping. However, that doesn’t necessarily mean the original mapper’s choice must be set in stone.
Here in the U.S., @NE2 pioneered many domain-specific keys like note:lanes, centre_turn_lane, and NHS. Some of these choices turned out to be a poor fit for OSM tag naming conventions, so we’ve gradually replaced them with better alternatives like lanes:forward and lanes:both_ways, while others were more palatable, so we documented them as is.
In the spirit of avoiding dataloss, what is the alternative to these curve_geometry tags? If we can be sure that, in practice, they represent hints to round off corners, then in the process of removing these tags, we should actually round off the corners by splining the roadway with more precise nodes. All renderers would benefit, not just the one mysterious proprietary one that supposedly uses curve_geometry.
But if these curve_geometry nodes represent control points as originally proposed, then I’m unsure what to replace the tag with. Moreover, I’m also unsure how many times I’ve subtly broken these nodes because I touched nearby geometry without noticing them. Such is the risk of relying on ATYL for something so advanced without coordinating with other mappers and software developers. Assuming I’m not the only mapper in this position, how much can this one supposed data consumer even rely on the tag anymore?
well, in such case usefulness and usability of tag is even lower
good point, it may be worth to process some sample manually and check whether it is reliable indicator of places where standard way of representing geometry of way (by modifying geometry of way) should be used instead of unusual tags
In the spirit of avoiding dataloss, what is the alternative to these curve_geometry tags? If we can be sure that, in practice, they represent hints to round off corners, then in the process of removing these tags, we should actually round off the corners by splining the roadway with more precise nodes.
this is not the same, augmenting resolution of the angular representation of a curve and stating that a line should be curved.
Well, it isn’t the same, but doesn’t that amount to a fixme=geometry if practically no data consumer would understand it and it doesn’t stand a realistic chance of gaining more support in the foreseeable future? A way’s geometry is a pretty fundamental concept, not some micromapping detail to be handwaved.
To recap my understanding of the situation:
The tag as originally proposed does not represent a curve; rather, it represents a control point along a curve.
The proponent was an anonymous organization (“we”), who only came forward after DWG intervention, after mappers had been raising questions about it, but it isn’t clear if that organization is still involved with OSM. (They also used an extra_curves tag that they never explained.)
So far, I have come across one open-source project that uses this tag – in order to discard it as a troll tag. And I know of no other data consumer that uses it.
In the last year, 22 mappers have intentionally deleted curve_geometry tags (not just as part of deleting the parent way), while nine have intentionally added them. At a glance, the additions appear to be for a variety of purposes:
In this discussion there are already 10 people involved. And no one (including me) seems to be able to define the meaning of curve_geometry=*.
I did some analysis with overpass and was able to generate a list with usernames. The users are the ones with the last edit of a node, way or relation with curve_geometry=*. The list of the nearly 400 people can be found below.
@nickvet419 you seem to be the only person with a lot (more than 50) of edited curve_geometry=* objects who has a matching forum account name. Can you help us understand the meaning of this tag?
table
user
number
GidonW
2984
erantr1
1903
Guy Zohar
1382
snake21
766
noa_m
763
nickvet419
352
Gil Schaechter
344
brevans
332
SemanticT0urist
323
PioneerSquare45
145
MapCam
83
Andrew Matheny_import
80
mitchelldm
77
RopponggiHills
69
BatsmanMapsman
49
Abdelrahman_mahmoud
48
e pt
47
Florimondable
47
gymsNmaps
45
Siguatepeque
45
stand_it
44
michael60101
43
Clarke22
42
yossaito
40
jimjoe45
38
BurntSteam
37
Andrew Matheny
36
brandonmcfadd
36
Gisolic
35
Akgeo
34
maximummap
32
phiphou
30
Fluffy89502
30
MacLondon
30
magrej
29
Artibonite
28
Sal73x
28
LakatosVL
27
ArchesPark
26
Delocuro
25
KB-01
24
Marc Mongenet
24
Michelle Liang
24
Perfal
24
Russell722
23
99of9
22
DavidKewley
22
joshuaseed
22
oba510
21
Pamir20
21
RunTrails
21
Smitology
21
stst415
21
Zol87
21
amircah91
20
AntBurnett
20
Britzz
20
KindredCoda
20
linus_at
20
Winultimate
20
guiguimapper2002
19
JÉT
19
Mikhail1412
19
Shamokin
19
OrenF
18
Nour Ayman
16
ConsEbt
15
j numminen
15
Meersbrook
15
Misa_zumba
15
PAL3001
15
vrynkevich_lyft
15
Yonatan Chamish
15
DaleOfAire
14
kmarkish_lyft
14
Rudy355
14
BrackoNe
13
JAAS
13
jula_2106
13
vaibhavnz
13
2hu4u
12
clay_c
12
dbqeditor
12
mannux
12
Oconomowoc
12
stick2
12
Supt_of_Printing
12
cquest
11
Emey_lyft
11
kan_kan
11
Neesa
11
Phil Scherer
11
Radek_trz
11
Russ
11
ika-chan! UK-USA
10
kurugunk
10
lxbarth
10
Timothy Smith
10
AndjelaS
9
anilkgba
9
Black_Diamond
9
DareDJ
9
KingRichardV
9
Marting77
9
Supaplex030
9
bspecht
8
flierfy
8
jeffxf
8
knight_moves
8
miha12
8
Nrg800
8
oanac2_telenav
8
puzzlefan
8
rusefkuma
8
Shadi Alshabi
8
zyxzyx
8
DrDurance
7
gionax
7
GobiDesert
7
Halfdeaf007
7
huonw
7
James_Griffiths
7
KySy
7
luxiaghd
7
Moult
7
NickJOB
7
NW757
7
o68
7
smikhnouski_lyft
7
acres1nvented
6
aharvey
6
akuksouski_lyft
6
arichnad
6
cbllkev
6
ecatmur
6
mama_bear
6
Nockamixon
6
Rob-au
6
StenSoft
6
Wey2go
6
YuliyaShustava_lyft
6
حبيشان
6
aleksaJov
5
amakarevich_lyft
5
arkdatta
5
khajurun
5
luked2000
5
Msalmanq
5
Netzach
5
peregrination
5
Peter Newman
5
Ploto
5
quikee
5
Random Person
5
rolandmwagner
5
sirorezka
5
Stephen214
5
teodorab_telenav
5
WoodWoseWulf
5
yanisperron
5
amarajz
4
bogdan_andrei
4
borovac
4
egordobatovkin
4
jamenimm
4
johnparis
4
kvenkatl
4
Luis36995
4
Map builder user
4
Matthew Grund
4
nevw
4
njtbusfan
4
okwithmydecay
4
ortho_is_hot
4
pravenya
4
Rallysta74
4
roberts_telenav
4
ruggs
4
salma_z
4
unknowndomain
4
VLD062
4
yasslay
4
Σεραφειμ
4
Alexey Lukin
3
AndrewS
3
atlas-3d
3
BrandonAGr
3
Carto’Cité
3
dhaird
3
finfly_99
3
Gangadi Anusha
3
guybrush127
3
Kouji915
3
Lockstar
3
mubshh
3
n76
3
Peter Heald
3
RainbowReef
3
ralley
3
samely
3
seav
3
SemanticTourist
3
shushmit
3
SirTopRamen
3
sivachak
3
someart13
3
sskalyan
3
Steven Vance
3
TreeTracks
3
txemt
3
wille
3
Mathieu
2
amsshalo
2
ArminGh
2
asdf1234
2
ashs_as
2
ashybko_lyft
2
Benoît C MdP
2
Benzauderer
2
Bobby_Boom
2
Caledonia659
2
Cape8
2
captain_slow
2
ChelSeaTheWorld
2
Chusovaya
2
darkemyst
2
DavidDrax
2
di4tu2
2
DUGA
2
enjawoke
2
geocruizer
2
guyporter
2
jangah1
2
Javelin1994
2
Jean-Marc Liotier
2
JesseAKARaccoon
2
Jojons
2
jraller
2
karmsudi
2
karragha
2
KingstonPike
2
Kivi
2
mapash
2
markbegbie
2
markzawi
2
mash84121
2
Mikey Co
2
Montebest
2
mrpulley
2
Ollie
2
Palolo
2
pmarkina_lyft
2
prasadtx
2
ramthelinefeed
2
rojganes
2
SabineSW
2
sellyme
2
Shhoo
2
telcodude
2
Truchin
2
VLD157
2
VLD175
2
VLD273
2
vsahith
2
Yom
2
YTaulai_lyft
2
عثمان ਉਸਮਾਨ bgo_eiu
2
近場行き
2
_yog
1
A_Prokopova_lyft
1
abvincen
1
achantav
1
adlid
1
AmeliaMag
1
amzmkuma
1
atsialiak_lyft
1
avssr
1
aya1985
1
BartekChom
1
bazgal
1
bhavyakota
1
Bolt017
1
Bolt043
1
BubbleGuppies
1
Cactux1122
1
calcium990
1
catalinad_telenav
1
ChaireMobiliteKaligrafy
1
ChookMan
1
civitano
1
danbjoseph
1
DannyAiquipa
1
Ddoolittle86
1
Deciduous Waffle
1
Denis_Helfer
1
Diego Esteban Alonso Blas
1
Diego Sanguinetti
1
Dimitar155
1
dirtyidol
1
doublah
1
dqn
1
DzmitryBachkarou
1
Euclid71
1
Falsernet
1
Fivea
1
gohimans
1
Harry Wood
1
higa4
1
Himké
1
hoream_telenav
1
idkwhatname2use
1
itsafrogslife
1
Iztaccihuatl
1
JaneOwl
1
jmty8
1
Joseph R P
1
kartonage
1
Khomille
1
kleroux
1
ksnghr
1
KVI0n
1
LACDH
1
lacram_telenav
1
LibertyWentWest
1
Linfindel
1
little_maper
1
locke
1
lrysiukevich_lyft
1
mahmedqg
1
manings
1
mapper175
1
Mara
1
Maradona11
1
markm851003
1
Mauls
1
maxolasersquad
1
mihaii_telenav
1
mike140
1
mirelal_telenav
1
miroslavuzice87
1
Mortein
1
mundlk
1
Nadeaua
1
nallivn
1
nattatatatat
1
Nick Parker
1
nihaalr
1
nlehuby
1
OrdinaryScarlett
1
overflorian
1
pbobbili
1
Penobscot
1
pkoby
1
ppjj
1
promiseofbirth
1
pshalyt_lyft
1
Psykle
1
PulisakZ
1
rapchira
1
RockCreekPark
1
Seandebasti
1
shahed alsheyab
1
shilpi sarkar
1
Skogafoss
1
speaketh
1
srividya_c
1
stadtob_rk
1
Stephen Males
1
sunilaak
1
Swihail
1
TacoBeans44
1
TheConductor
1
TheHunt
1
threefoursixninefour
1
tmadhuli
1
Tom Lee
1
unnsyeda
1
vardhamk
1
Velfo
1
VijitVijayan
1
Vladislav Konoplev
1
VLD165
1
VLD166
1
vogelfreier
1
WakatobiPark
1
whammo
1
YellowberryHN
1
Yod4z
1
yxoc
1
ZakharP
1
Zian Choy
1
zmoore_lyft
1
overpass query
[out:csv(::user, ::version, ::timestamp;',')]
[timeout:25];
(
nwr["curve_geometry"]({{bbox}});
);
out meta;
This query can only find curve_geometry nodes that mappers have incidentally touched without necessarily adding the tag, for example by moving a way that happens to touch the node or repurposing the node for something else (rendering the tag meaningless). Your list includes many of the people OSMCha identifies as having intentionally removed curve_geometry in the past year, including @nickvet419.
From the top of your list, the DWG has been involved with both @GidonW and @erantr1 over this matter. The former wrote the abandoned proposal on the wiki on behalf of their organization but is no longer active in OSM. The latter is active, but I don’t know if they’re affiliated; their usage seems to differ.
I made another analysis that looks at object history - and will not attribute use to someone who moved node or added another tag (still, some false positives to be expected). But shows main users, who dominated tag use. 12463 in total, 6093+2314+2254+1138=11799 - 95% of all uses.
import who_added_this_tag
config = {
'key': 'curve_geometry',
'value': None, # may be None - in such case it looks for all values of key
'area_identifier_key': None, # may be None, in such case search is worldwide, 'ISO3166-1' is a good identifier
'area_identifier_value': 'PL', # ignored if area_identifier_key is None
'list_all_edits': True,
'list_all_edits_made_by_this_users': [], # ignored with list_all_edits set to True
}
who_added_this_tag.statistics.process_case(config)
# https://community.openstreetmap.org/t/proposal-to-delete-all-curve-geometry-tags/106627
Thanks everyone for the awareness and the discussion.
After reading through the discussion I totally understand the difficulties it may raise, and would like to elaborate.
The curve geometry tag was introduced a few years ago in order to solve a problem we had with curved roads, of course with hope it will also contribute to the OSM community.
This tag serves as a marker for where to break curved ways into edges when building a graph (in addition to intersections, which are straightforward breaking locations).
In the vast majority of cases we actually don’t need it anymore, but we do have some legacy parts in our system that still use it. We’re on the track of replacing those parts, so in the relatively near future (~1.5 years) we will not need it anymore.
If possible, we’ll be happy to keep it for this remaining period. As commented above, eventually it’s not a very common tag, so I guess it doesn’t affect that many places globally.
Of course, we’ll understand and respect any decision taken by the community.
Thanks for the clarification. I suggest those tags to be removed two years from now, when nobody uses them anymore.
It’s a mass removal so this thread will then have to be briefly revived I guess.
actually the initial premise was plain wrong: “There’s no benefit to it as curved geometry can be detected and smoothed automatically without these nodes, purely based on the angle difference.”, because without the tag you cannot even know if it is a curve (that should/could be smoothed) or not (it cannot be automatically detected), so if there is information in the tag it should not be automatically removed. Actually I think we could have a tag to say whether the points in a line are an approximation to a curve or an angle is meant to be an angle (to be set on a node I think?). Could be useful for some buildings as well. Similarly, we also cannot distinguish a way of which the width continuously widens from a to b from another one where there is actually a step/jump, or can we?
Interesting, if this is actually a routing use case, rather than a rendering use case, then why is curvature relevant to the routing graph? Are you using the tag to indicate that the router needs to indicate a turning maneuver of some sort? Or is it related to linear referencing or traffic segments? Just trying to get an understanding of how mappers should deal with these nodes when they need to modify the way for any reason.
It’s mostly about routing and display.
When edges are not geometrically aligned with the actual map, the route is poorly displayed (I’m referring to internal display in our tools), and driving instructions may also be distorted. In some cases it can also lead to driver’s off-routes (being snapped to the wrong edge of the graph).
In extreme cases such as here, it could lead to a “collapse” of edges into a 1-D line.
Regarding “how mappers should deal with these nodes when they need to modify the way” - it’s quite flexible. Eventually, as long as there’s no “too sharp” segment with no curve geometry tag along it, it should be ok. I know it’s not well-defined, but there is no good simple definition.
In that case, it sounds like you should probably be following these guidelines as well. These probably weren’t in place when your organisation started adding these tags, but they’ve been in place for a few years now.
Thank you, I think I understand your use case now. If your routing engine optimizes the full geometry out of your routing graph upfront, it’s unsurprising that you’ve wound up with oversimplified geometries. I know you’ve said that this is legacy code and you’re replacing it with something newer and better. Hopefully your replacement will eliminate the need for this tagging – it’s extra manual work that shouldn’t be necessary.
Other OSM-based routing engines have taken a different approach. For example, OSRM retains every node in the way, so that there’s an arbitrary number of segments along an edge. This is advantageous because ETAs are partly based on travel distance, speed limits and freeflow speeds can vary from one segment to another, and rerouting usually requires calculating a route partway along an edge. Map matching (snapping) remains accurate because nothing has been simplified yet.
Once the route is computed, the client can request the full geometry or an automatically simplified version. Polyline encoding also avoids bloating the response with geometry data. I know this works because one of the most common pitfalls of using Mapbox’s navigation software is forgetting to disable simplification and enable Polyline encoding. I distinctly remember the look on colleagues’ faces as they stared at a “route” as straight as the crow flies.
Of course, the downside to retaining the full geometry in the graph is the memory overhead. OSRM is a very memory-intensive router. Valhalla mitigates this cost somewhat by tiling the data, and I think its gridded contour lines format might have something to do with it too. GraphHopper and OpenTripPlanner are also more lightweight than OSRM, but they still don’t need to prune non-intersection nodes out of the data upfront and don’t require these “do not erase” nodes to be tagged explicitly.
These are some interesting ideas that might be worth following up on in a separate thread, but I think we now know that the actual intention behind curve_geometry is closer to what was stated in the original post.
