Stop rendering oneway=-1

[dch0ph]

oneway=-1 has been deprecated for a long time and is on its way out:

[0.01% of all oneway values]

But handling it adds significant code complexity, and makes it more difficult to address issues such as #706 .

@pnorman has previously suggested explicitly reversing oneway=-1 ways, but at this point, I would just stop rendering it.

[HolgerJeromin]

I would not oppose but where is this tag deprecated?

https://wiki.openstreetmap.org/wiki/Tag:oneway%3D-1

[dch0ph]

Interesting, I assumed it was "officially" deprecated since JOSM complains about it. So technically it's just "highly discouraged".

I don't think that's a show-stopper. If you were designing a new renderer, I doubt you would bother supporting oneway=-1.

[imagico]

Like @HolgerJeromin i don't see much evidence that there is consensus among mappers that oneway=-1 is not acceptable tagging any more.

If there are concrete changes in this style that would be much harder to implement with support for oneway=-1 then we can consider dropping support since this is not a very widely used tagging. But i'd suggest to cross that bridge if and when we come to it.

@pnorman has previously suggested explicitly reversing oneway=-1 ways.

That is definitely a bad idea. There are countless tags for which the orientation of a way has meaning and just universally reversing ways with oneway=-1 would mess with those. And not all of them are easily reversible like oneway (in the highway context most notably placement).

[dch0ph]

If there are concrete changes in this style that would be much harder to implement with support for oneway=-1 then we can consider dropping support since this is not a very widely used tagging. But i'd suggest to cross that bridge if and when we come to it.

Fair enough. I'll close this for now.

I think it would be useful to have a roadmap for potential improvements to the roads layer (such as including oneway marking as part of road rendering to address #706 ). The roads layer looks so horrific that it would be a brave contributor who decided to tackle it.

[imagico]

I think it would be useful to have a roadmap for potential improvements to the roads layer (such as including oneway marking as part of road rendering to address https://github.com/gravitystorm/openstreetmap-carto/issues/706 ). The roads layer looks so horrific that it would be a brave contributor who decided to tackle it.

I agree it would be good to develop some strategic planning on such questions that require more elaborate work to tackle. Even more than for the road layers this applies to #3880 IMO. But given how much difficulty we have these days on agreeing on any decisions that reach further than the merging of a single PR i am not sure this is realistic. But it does not hurt trying probably. Personally i would welcome any discussion on developing and agreeing on a more overarching long term approach on any of the bigger strategic issues of this style.

[dch0ph]

But given how much difficulty we have these days on agreeing on any decisions that reach further than the merging of a single PR i am not sure this is realistic.

Well, yes...

Having looked at it, I think any general and comprehensive solution to #3880 is going to be very difficult (a partial solution covering just symbols is easier). In the end, Carto still does a better job than Google-style vector maps where symbols randomly flick in and out at different zoom levels.

Roads struck me as an area where it might be possible to break things down into manageable steps or where new solutions might be possible after moving to the osm2pgsql flex input.

[imagico]

Roads struck me as an area where it might be possible to break things down into manageable steps or where new solutions might be possible after moving to the osm2pgsql flex input.

That seems doubtful to me. The problems we have with the road layers are structural, owed to the limitations of Mapnik of separating query structure from drawing order and to the limitations of CartoCSS in managing highly complex and interdependent styling rules like we have them in our roads system. This is possible to address - but not through incremental changes, it requires big steps, and that requires a plan, discussion and consensus building.

OTOH there are plenty of design issues and potential improvements that can be worked on within the current system that are fairly independent of the structural problems. That is why i have not included the road rendering system in the list of important todos in #4901. It would be a significant part in an overall consolidation of the style but so far it is not something that holds us back fundamentally in solving concrete design problems in most cases.

That, however, does not mean more fundamental discussions of the road layers are pointless. There is much to be gained by exchanging ideas.