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

Special rendering for intermittent waterways - fixes #805 #1000

Merged
merged 1 commit into from
Jan 25, 2015
Merged

Special rendering for intermittent waterways - fixes #805 #1000

merged 1 commit into from
Jan 25, 2015

Conversation

matkoniecz
Copy link
Contributor

Note: there are still some issues.

  • (1) - in a rare situation - intermittent waterway with bridge=*, connecting with not intermittent waterway ordering of rendering may be wrong, leading to a small glitch. It is fixable by ordering waterways in SQL querry - but is it worth additional complexity and performance hit to solve something that never appears in data? Or in the worst case - is really rare? (based on math1985's comment)
  • (2) - is it possible to maintain consistent dashes across (meta)tiles? See the first image. (thanks @pnorman!)
  • (3) - is it necessary to modify rendering of wadis? And (changed) derelict canals? Both use dashes, but wider and rounded ones. See examples at http://www.openstreetmap.org/way/81918899 and http://www.openstreetmap.org/way/220089162#map=16/31.0738/34.5945 (wadi rendering is changed, for derelict canals I opened dry canals are displayed as blue dashes #1003)
  • (4) - is it a good idea to assume that ditch is intermittent ? (no)

glitch

Examples of a new rendering on an example of http://overpass-turbo.eu/s/5ec (+some minor modifications of OSM data)

Minor waterways:

z19
z16
z14
z13
tunnel
bridge

Major waterways:
z19
z16
z14
z13
bridge
bridge2
tunnel17
selection_005

@matthijsmelissen
Copy link
Collaborator

Do we want to render intemittent waterways different from wadis?

@matkoniecz
Copy link
Contributor Author

I considered treating wadis as intermittent rivers, but I am not sure is it a good idea. Also, according to http://en.wikipedia.org/wiki/Wadi wadi is rather term for an entire valley - not just intermittent waterway.

@imagico
Copy link
Collaborator

imagico commented Sep 29, 2014

The problem is if wadi is understood as a synonym for intermittent waterway it should be rendered the same. If it is understood differently it should probably not be rendered implying a waterway at all since it can be permanently dry. Rendering it differently but still waterway-like is the worst solution IMO.

I would probably change the dashing for rivers to make sure the dashes are always at least as long as wide.

@@ -133,6 +138,19 @@
[zoom >= 18] { bridgecasing/line-width: 13; }
}
}
[intermittent = 'yes']{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in our coding style, we use a space before {.

@matthijsmelissen
Copy link
Collaborator

I agree that wadi and intermittent rendering are too similar in this proposal. Either we need to render them such that the difference can easily be detected, or we need to render them the same.

I would prefer the latter: I checked with Overpass Turbo, and it seems that waterway=wadi is currently being used in the same way as intermittent=yes.

In places where intermittent is used, is it also used for riverbeds that have been dry for years?

@daganzdaanda
Copy link

The white with dashed outline could be misunderstood as a road. IMHO, the dashed blue line works nicely and should be working across all widths.
Edit -- or are the last two examples for tunnels? Then I guess it's OK, since tunnels would probably be used mainly for short ways only.

"Ditch" kind of implies "intermittent" already. See the wiki http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dditch They may contain little water or even be dry most of the year.
So maybe a ditch should always be a dashed thin blue line? Could that be mistaken for some kind of track? Also - we just made ditches wider, maybe wait with another change.

@matkoniecz
Copy link
Contributor Author

I agree that wadi and intermittent rendering are too similar in this proposal. Either we need to render them such that the difference can easily be detected, or we need to render them the same.

OK, I will merge wadi and river/canal definitions. I will also fix coding style.

In places where intermittent is used, is it also used for riverbeds that have been dry for years?

I am not aware about this kind of geographical features in Poland.

Edit -- or are the last two examples for tunnels? Then I guess it's OK, since tunnels would probably be used mainly for short ways only.

Yes, I am not expecting that something like exists in data - it was mainly sanity check to avoid some weird bugs.

"Ditch" kind of implies "intermittent" already.

I admit that I missed it (in my mapping I was adding intermittent=yes but never intermittent=no to ditches).

Could that be mistaken for some kind of track?

I think that it is unlikely.

Also - we just made ditches wider, maybe wait with another change.

This examples are already with wider ditches (I branched from the last trunk version).

@matkoniecz
Copy link
Contributor Author

Coding style fixed, river/canal and wadi styles merged.

@matkoniecz
Copy link
Contributor Author

For ditches - explicit intermittent is IMHO better, implied tags that are not super obvious lead to problems (and I modified wiki page about ditch with recommendation to tag this way).

@daganzdaanda
Copy link

For ditches - explicit intermittent is IMHO better

Yes, definitely. Funnily, the German wiki page already had the recommendation to use "intermittent=yes".

@matthijsmelissen
Copy link
Collaborator

For river, and perhaps even for stream, I would go for a bit longer dashes. Maybe the same length/width proportions as for drains? I think it would make intermittent rivers and intermittent streams look more similar. Apart from that, code and resulting rendering looks good!

@matthijsmelissen
Copy link
Collaborator

Oh, and:

(1) - in a rare situation - intermittent waterway with bridge=*, connecting with not intermittent waterway ordering of rendering may be wrong, leading to a small glitch. It is fixable by ordering waterways in SQL querry - but is it worth additional complexity and performance hit to solve something that never appears in data? Or in the worst case - is really rare?

I wouldn't worry about this case.

@matkoniecz
Copy link
Contributor Author

For river, and perhaps even for stream, I would go for a bit longer dashes. Maybe the same length/width proportions as for drains? I think it would make intermittent rivers and intermittent streams look more similar.

It turned to be a good idea for rivers.

selection_001

Still, I think that streams are now OK.

@matkoniecz
Copy link
Contributor Author

Note: once changes stop, I will test various edge cases to ensure that nothing is broken and rebase everything into a one commit.

Also, is it possible to maintain consistent dashes across (meta)tiles?

selection_002

@matthijsmelissen
Copy link
Collaborator

It turned to be a good idea for rivers.

Hmm, now I see the result, I'm no longer sure if it looks nice. What are the opinions of others?

Also, is it possible to maintain consistent dashes across (meta)tiles?

pI'm not sure if there is a way to do that, maybe @gravitystorm or @pnorman know?

@matkoniecz
Copy link
Contributor Author

I used short dashes as I was sure that longer will look like series of lakes rather than a linear object (it was worse with round caps). I like both versions, though metatile glitches seems to be less iritating for a short dash version.

@imagico
Copy link
Collaborator

imagico commented Sep 29, 2014

At the highest zoom levels where rivers are drawn very thick it would probably be good to style them in a way that works well together with the style of intermittent water areas (see #996).

One option for the high zooms would be to use a style similar to highway=proposed, just without the white parts, i.e. a thin non-dashed casing and a dashed interior, all in the normal water color.

@matkoniecz
Copy link
Contributor Author

At the highest zoom levels where rivers are drawn very thick it would probably be good to style them in a way that works well together with the style of intermittent water areas (see #996).

Yes, but currently it is unknown how #996 will be solved. But with this proposal intermittent waterways should not be more troublesome than a normal ones unaffected by this change.

One option for the high zooms would be to use a style similar to highway=proposed, just without the white parts, i.e. a thin non-dashed casing and a dashed interior, all in the normal water color.

I am unsure how it may be in CartoCSS. Standard method will not work, as it is based on painting one color wider tha placing narrower dashes on it ("Another common railroad line style is similar" from https://www.mapbox.com/tilemill/docs/guides/styling-lines/ ).

Also, such symbol change depending on a z-level may be confusing.

@imagico
Copy link
Collaborator

imagico commented Sep 29, 2014

I am unsure how it may be in CartoCSS. Standard method will not work, as it is based on painting one color wider tha placing narrower dashes on it ("Another common railroad line style is similar" from https://www.mapbox.com/tilemill/docs/guides/styling-lines/ ).

You can probably do that with line-offset (two thin solid lines with offset and one thick dashed line without). It will of course look somewhat ugly when several waterways meet.

Also, such symbol change depending on a z-level may be confusing.

I don't think this would be a problem. The thinner the whole river line gets when you zoom out the thinner the outer lines will be as well and at one point you simply leave them away completely leaving only the dashed center line.

@pnorman
Copy link
Collaborator

pnorman commented Sep 29, 2014

I'm not sure if there is a way to do that, maybe @gravitystorm or @pnorman know?

Turn off clip

@matkoniecz
Copy link
Contributor Author

@pnorman - thanks!

What fixed one bad consequence of long dashes, but I found another problem with long dashes.

selection_004

so I roll back to a short dash version

selection_005

I think that in this version "thin non-dashed casing and a dashed interior" is not needed.

@matkoniecz matkoniecz self-assigned this Sep 30, 2014
@matkoniecz
Copy link
Contributor Author

Still needs rebasing and retesting, I plan on do this tomorrow (maybe somebody has some comments).

@mboeringa
Copy link

What fixed one bad consequence of long dashes, but I found another problem with long dashes.
...
so I roll back to a short dash version

Minor issues will always exist with display of lines, and especially dashed lines. I don't know if that needs to be a reason to "roll back" or refrain from using them. Personally, I think the very short dash, is to much like some kind of "steps"... It doesn't appear to work cartographically. I think the medium or long dashes you showed in these images appear best.

Alternative is the dashed outline you showed, but that one could be confused with a motorway tunnel considering the close resemblance in color, although the general irregularly bended nature of it and no connections with other highways, will likely avoid this confusion.

@matkoniecz
Copy link
Contributor Author

The problem is that these problem appeared on many curved segments of rivers, it was not something rare. But I am not strongly against long dashes.

Is there anybody else who have an opinion on long dash vs short dash issue?

@matthijsmelissen
Copy link
Collaborator

What about blue dashes on some grayish/brownish background, or something like that?

@matkoniecz
Copy link
Contributor Author

It was not working well with white casing for streams and ditches (that is why for intermittent small waterways casing is also dashed) - it was quite messy except on high zoom levels. And I think that the doing it only for rivers may be confusing.

@mboeringa
Copy link

Maybe you could also reduce the rendered width of the major waterways a bit on some zoom levels. It is not entirely clear to me from the images you posted what the actual rendered width at each zoom level is, but it appears quite wide at some. Reducing it might also reduce the visibility of possible artefacts.

@matkoniecz matkoniecz added this to the Bugs and improvements milestone Oct 1, 2014
@matthijsmelissen
Copy link
Collaborator

@mkoniecz Could you rebase this?

@matthijsmelissen
Copy link
Collaborator

@mkoniecz Can you rebase this?

@matkoniecz
Copy link
Contributor Author

Yes, I will do it tomorrow.

Includes change to wadi rendering.
@matkoniecz
Copy link
Contributor Author

Rebased, now I am testing whatever everything works properly.

@matkoniecz
Copy link
Contributor Author

Probably too late for this release, but according to my tests everything works properly.

@matkoniecz matkoniecz removed their assignment Jan 15, 2015
@matthijsmelissen matthijsmelissen merged commit 511e1d3 into gravitystorm:master Jan 25, 2015
@matkoniecz matkoniecz deleted the dash branch January 25, 2015 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants