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

Fix #996 by adding intermittent water bodies support #3104

Merged
merged 1 commit into from
Mar 9, 2018

Conversation

Penegal
Copy link
Contributor

@Penegal Penegal commented Mar 6, 2018

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 6, 2018

Here are the keywords for automatically closing tickets:

https://help.github.com/articles/closing-issues-using-keywords/

Could you post some images with the rendering of the actual code from this PR?

@Penegal
Copy link
Contributor Author

Penegal commented Mar 6, 2018

@kocio-pl: Edited.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 6, 2018

Thanks! The links to rendered locations are useful for testing - could you post them too?

It looks great and intuitive for me, some more examples:

Intermittent pond in the forest near the river
al3d54wf

Intermittent water in the small park
zais5eo3

Seasonal pond with a name in the park
xhwxnnwd

@Penegal
Copy link
Contributor Author

Penegal commented Mar 6, 2018

@kocio-pl: Edited.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 6, 2018

South Australia example on z6 - I don't know if the tagging is complete, but at least some of the biggest lakes there are clearly intermittent:
xictib09

Whole continent view on z5 (click to see the full size):
v7qapvzy

@sommerluk
Copy link
Collaborator

Given that the pattern is quite simple and maybe pixel-aligned, is there a chance to have this as SVG pattern avoiding #2750 problems?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 7, 2018

Currently we're not sure why such problems exist at all and how to fix/avoid them with vector patterns (looks to me like a Mapnik issue), so raster version is the only safe bet for now.

@Penegal
Copy link
Contributor Author

Penegal commented Mar 8, 2018

What does miss for this to be merged? Approval? Testing?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 8, 2018

I just wait one day more to give a chance for anybody to post additional comments/improvements, because it's now more visible than just an old issue, but that's all.

@Penegal
Copy link
Contributor Author

Penegal commented Mar 8, 2018

OK, just wanted to be sure.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Mar 9, 2018

Thanks for the work! I like the result, especially because it tunes a look on low zoom (probably not only in Australia).

matthijsmelissen pushed a commit to matthijsmelissen/openstreetmap-carto that referenced this pull request Mar 10, 2018
@turnsole80
Copy link

I've updated the tagging on some of the lakes in Australia, so it should look even better now :)

@kocio-pl
Copy link
Collaborator

Thanks a lot! I've been thinking lately about asking the Aussie community about it.

There can be similar examples across the globe, if anybody knows one, please tag them too.

@Gazer75
Copy link

Gazer75 commented Apr 27, 2018

There is a small issue with this. It will not display over a dam polygon.
https://www.openstreetmap.org/relation/8248594

@kocio-pl
Copy link
Collaborator

I think the water just should not be rendered over dam, no matter if intermittent or not.

@Gazer75
Copy link

Gazer75 commented Apr 27, 2018

Why not? When the doors are open the water flows over in that area.

@kocio-pl
Copy link
Collaborator

The main reason is that there are so much combinations with layers and they are expensive (in terms of performance and maintenance), that we must have a strong reasons to add/split more of them. And it would mean that intermittent water should have its own layer. And that would be always above the whole class of things, not only dams...

We would need some generic solution like global render layers - that would mean that layer=1 is always above layer=-1. Yet we have only per-layer rendering priority (road with layer=1 over road with layer=-1) not the global one (building with layer=1 over road with layer=-1). I'm not even sure if this is doable with our framework, but even if it is, it would be huge code rewrite probably.

For a notable example of layering problem without global rendering layers see #688 (comment).

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.

Special rendering for intermittent water areas
5 participants