Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render barrier=toll_booth areas #3244

Closed
ghost opened this issue May 22, 2018 · 10 comments
Closed

Render barrier=toll_booth areas #3244

ghost opened this issue May 22, 2018 · 10 comments

Comments

@ghost
Copy link

ghost commented May 22, 2018

Render barrier=toll_booth, area=yes.

Edit: Typo fix

@pnorman
Copy link
Collaborator

pnorman commented May 22, 2018

How do you think it should be rendered? Just a symbol in the centre of the area?

#3005 had some discussion at the time about areas but it couldn't be solved with the DB schema of the time.

@kocio-pl kocio-pl added this to the Bugs and improvements milestone May 23, 2018
@kocio-pl kocio-pl changed the title Render tolls Render barrier=toll_booth areas May 23, 2018
@sommerluk
Copy link
Collaborator

@ivan-rsm Thanks for the issue report!

Currently, we do not treat barrier=toll_booth as area in our database layout. Or at least not in general – when it is used together with other area features like building=yes than it is treated as area, otherwise not.

Independent of the discussion how to render this (I agree that just a symbol in the centre of the area would be a good starting point), we need to change the database layout. I’ve opened a ticket therefore at #3249 A database layout change is likely to take some time.

@sommerluk
Copy link
Collaborator

@pnorman My fear in #3005 was that we render an icon for some of the closed ways (for example these that also have a building or landuse tag), but for other closed ways we don’t – and that might be confusing for the mapper. As you say in #3249 area=yes forces treatment as area, so this combination can be rendered without a database layout change. Do you think it makes sense? (If so, I could create a PR…)

@jeisenbe
Copy link
Collaborator

Requires merging #3788 and reloading database first

@jeisenbe
Copy link
Collaborator

I opened #3788 but now we need to consider if we should really support this method of mapping.

Currently, almost all barrier features are either mapped as linear ways (fences, walls, hedges and similar), or as nodes (for barriers which block a highway).

While a few types of node barrier have been mapped as linear ways, for example long gates, there is some discussion about whether it would actually be a good idea to support this. If mappers use only a 2-node way to map a gate, this does not add more information than using a 'width' tag, but it does make it harder for routers and other database users to properly interpret the highway as obstructed by the gate or other barrier. If 3 nodes are used, then it's not clear if the central node should also be tagged as a barrier or not. See discussion at #3929 and please comment there as well.

Mapping toll booths as areas also causes these same problems. Mapping as a node on the highway makes it clear that this is a obstruction where drivers expect to slow down or stop. Mapping as an area is difficult to interpret if there are no shared roads with the highway. Also, mapping as an area is not described on the wiki page but mapping as a node is suggested. Only in the iD editor and in a note in the "Description" box on the wiki pages is area mapping mentioned.

Currently there are 42k toll_booth nodes and 2.4k areas, so almost 95% are mapped as nodes, though the area mapping does exist.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 9, 2020

Input needed: should we consider supporting barrier=toll_booth on areas or consider it a bad idea which we don't need to support, since nodes on the highway are much easier for routing applications to use.

@Adamant36
Copy link
Contributor

Adamant36 commented Jan 9, 2020

👍 for bad idea. If its being mapped as an area, then what exactly is being mapped that isn't over the road? If its the office then its not really the barrier and should just be mapped as its own object with something like office=toll_booth or building=toll_booth IMO. Unfortunately both have extremely low usage . Doing a quick glance that's how areas seemed to be mapped though. For instance here and here. Both are miss-leading and probably can't be accounted for in navigation apps. Btw, its worth mentioning that 1663 are tagged as areas and 1971 are tagged as buildings. If most toll booth areas are buildings or the majority are mapped that way (because they can be) its pointless to add area=yes rendering.

@jeisenbe
Copy link
Collaborator

Also see comments by @sommerluk in #3005:

"barrier=toll_booth on areas? JOSM and iD have a preset for both, points and areas. The wiki allows it on points and areas (right box on the wiki page), but at the same time, the wiki description says “The node should be on the highway the toll applies to, in order to support routing decisions.” and doesn’t describe a correct mapping on areas. Actually about 5% of the toll booth objects in the database are areas – most of them have also a building=* tag."

@pnorman
Copy link
Collaborator

pnorman commented Feb 12, 2020

Input needed: should we consider supporting barrier=toll_booth on areas or consider it a bad idea which we don't need to support

I'm inclined to agree with it being something we don't need to support.

@jeisenbe
Copy link
Collaborator

We decided not to import these closed ways as polygons - though in practice, most closed ways with this tag are also a building=* (or building=roof) feature and will already be rendered in that way.

So I am closing this issue: the wiki and actual usage suggest that these features should be mapped as points (nodes). If this changes we can consider reopening this issue in a year or two, next time that a database reload is planned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants