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

Do not render link roads until z12 #2601

Merged
merged 1 commit into from
Aug 15, 2017

Conversation

matthijsmelissen
Copy link
Collaborator

@matthijsmelissen matthijsmelissen commented Mar 28, 2017

This improves rendering on mid zoom levels by smoothing up the highways.

Before:
screenshot_2017-03-28_21-44-40

After:
screenshot_2017-03-28_21-45-12

This becomes especially important after implementing something like #2194 (comment):

Before:
screenshot_2017-03-28_21-52-06

After:
screenshot_2017-03-28_21-47-36

@imagico
Copy link
Collaborator

imagico commented Mar 28, 2017

I suppose you mean z<12.

Could this result in gaps in cases like here:

http://www.openstreetmap.org/#map=15/42.1637/12.6129

@matthijsmelissen
Copy link
Collaborator Author

I suppose you mean z<12.

Yep.

Could this result in gaps in cases like here:

Likely yes. Unfortunately Luxembourg doesn't seem to have a case like this.

@nebulon42
Copy link
Contributor

It reduces clutter which is great but on the other hand it leads to gaps at junctions and there are also some longer link passages that could have some relevance on < z12.

Compare https://www.openstreetmap.org/#map=11/48.0510/16.4991 of Vienna's south east with
after_marked
(I have not checked if the tagging is accurate.)

So I'm leaning a bit to the negative side due to the side effects, but otherwise it would be a good improvement.

@HolgerJeromin
Copy link
Contributor

Even in Luxembourg we have a problem. Last image from math.
image

Rendering links like the connecting highway (yellow?) is probably not a good idea, too.

@matthijsmelissen
Copy link
Collaborator Author

Thanks for the examples!

@pnorman
Copy link
Collaborator

pnorman commented Apr 4, 2017

Lately I've gone for starting rendering of links at z10 in my projects. I've found if I increase that it leads too too many problems of gaps.

@matthijsmelissen
Copy link
Collaborator Author

matthijsmelissen commented Apr 4, 2017

Google Maps has the same problem, by the way (see bottom):

screen shot 2017-04-04 at 11 06 40

@imagico
Copy link
Collaborator

imagico commented Apr 4, 2017

We probably need to consider

  1. what our expectations of quality are here.
  2. what side effects rendering artefacts will have regarding mapping practice. I suppose if we have visible gaps at larger highway crossings with long links people will be tempted to at least partly tag the links as normal highways.

You might also consider some fancy logic only removing topologically redundant links but that is probably too expensive for us.

@HolgerJeromin
Copy link
Contributor

Rendering links like the connecting highway (yellow?) is probably not a good idea, too.

After thinking about it more this could probably work. Calculating the connecting road class is probably not doable, but render all motorway links with a primary color could be nice.

@pnorman
Copy link
Collaborator

pnorman commented May 3, 2017

Perhaps instead of z12 (proposed) or z9 (current) we could go with something between them?

@pnorman
Copy link
Collaborator

pnorman commented May 10, 2017

As this has cartography changes, this PR is currently held up by the feature freeze until 4.0.0 has been released.

This improves rendering on mid zoom levels by smoothing up the highways.
@matthijsmelissen matthijsmelissen merged commit d8f4ea3 into gravitystorm:master Aug 15, 2017
@matthijsmelissen
Copy link
Collaborator Author

Thanks for all comments. I have changed the PR to only drop link roads up to z11 (rather than z12). Merged.

@nebulon42
Copy link
Contributor

Hm, I have the impression that recently it doesn't matter any more so much if others have concerns about changes. They get merged anyway. I think that decreases quality.

@nebulon42
Copy link
Contributor

Also: Didn't we have the requirement that there has to be at least one approving review?

@matthijsmelissen
Copy link
Collaborator Author

You're right, I reverted this merge. As it is not possible to re-open a PR, I created a new PR here: #2758 Could some of you please review it?

@kocio-pl
Copy link
Collaborator

I have warned about problem with reviews lately. Lack of discussion seems to be a bigger factor regarding quality than making informed decision.

@matthijsmelissen
Copy link
Collaborator Author

Sorry, I'm not sure if I understand what you mean with you last commebt?

@kocio-pl
Copy link
Collaborator

It was response to both @nebulon42 comments.

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

Successfully merging this pull request may close these issues.

6 participants