mapbox / mapbox-gl-js

Interactive, thoroughly customizable maps in the browser, powered by vector tiles and WebGL
https://docs.mapbox.com/mapbox-gl-js/
Other
11.07k stars 2.21k forks source link

Provide "line-stroke-*" properties #4162

Open lucaswoj opened 7 years ago

lucaswoj commented 7 years ago

From @lucaswoj on December 23, 2016 14:36

Copied from original issue: mapbox/mapbox-gl-style-spec#637

lucaswoj commented 7 years ago

From @jfirebaugh on December 23, 2016 16:36

If we add these, we should remove line-gap-width.

lucaswoj commented 7 years ago

From @nickidlugash on January 3, 2017 1:16

If we add these, we should remove line-gap-width.

@jfirebaugh @lucaswoj can you please elaborate on why we should do this?

lucaswoj commented 7 years ago

From @jfirebaugh on January 3, 2017 1:22

Because it's equivalent functionality -- you can replace a pair of fill and casing layers with a single layer with both fill and stroke, or a standalone gapped line with a like with a stroke and transparent fill.

If we don't also remove line-gap-width, then we are adding complexity to the renderer without meaningfully expanding its functionality. I would oppose line-stroke-* in that case.

lucaswoj commented 7 years ago

From @nickidlugash on January 3, 2017 1:55

Ok, that makes sense. I misunderstood this ticket and thought we were just renaming line- to be line-stroke.

you can replace a pair of fill and casing layers with a single layer with both fill and stroke

Just noting that you will still need two layers to create a fill and casing, since they need to be drawn in different parts of the drawing order. However, overall, this will still be more convenient then the current system because the line-width for both the fill and casing will be identical, whereas currently the line-gap-width of the casing is equal to the line-width of the fill.

stevage commented 7 years ago

So, having line-fill-* mean the interior color and properties of the line, and line-stroke-* be the casing properties? I see the logic, but it seems a bit non-conventional. Are there other systems that work like that? Talking about the "fill" of a line just seems unintuitive to me, and the "stroke" of the line is even worse.

What exactly is the proposed relationship between line-width and line-stroke-width? Say, a 5px line-width with a 3px line-stroke-width: does the stroke sit entirely outside the 5px (so a total width of 11px), or is the stroke centred on the edge of the line (total width, 8px: 1.5, 5, 1.5)?

lucaswoj commented 7 years ago

@stevage Where are you seeing mention of line-fill-*? The proposal is to keep existing properties like line-color and add additional stroke properties like line-stroke-color.

Are there other systems that work like that?

Yes. Many. See https://github.com/mapbox/mapbox-gl-style-spec/issues/379#issuecomment-261151165 and the following comments for a full rundown.

What exactly is the proposed relationship between line-width and line-stroke-width?

Like circle strokes, text halos, etc the line stroke would sit entirely outside the line width (there would be a total width of 11px in your example).

jfirebaugh commented 7 years ago

In the other systems though, "stroke" is used to denote what we're calling "line", and there's no equivalent analog of "line-stroke". For example, in Illustrator, to create effects similar to the proposed line-stroke-* properties (or the existing line-gap-width), you'd create multiple strokes and apply offsets to them as needed.

stevage commented 7 years ago

Where are you seeing mention of line-fill-*?

Sorry, looks like I extrapolated incorrectly.

In the other systems though, "stroke" is used to denote what we're calling "line", and there's no equivalent analog of "line-stroke".

Yeah, that's a better way of expressing what I was trying to say. :)

Another thing I would find a bit confusing about the change is the implication for a line which is rendered as two parallel lines with nothing between (like used for divided highways sometimes). Currently the model is "line with a gap in the middle" (which I think matches the user's mental model), and this would change to "invisible line with a border". Probably not disastrous, just...slightly less intuitive?

Would this have any implications for how the end cap is rendered? I notice, somewhat surprisingly, that for a line with a gap-width, "round" cap draws a semi circle on the end, but "square" leaves it open. If instead of a gap-width, you have a "stroke", maybe the open ending is even more surprising.

(Sorry, I don't think any of these comments are very helpful...just sort of musing.)

bergkvist commented 5 years ago

Alternative name: line-border-*

This might avoid confusion of people thinking line-stroke-* is defining the line fill (rather than its border). I agree that line-gap-width would no longer be needed if line-{stroke/border}-* is added.

Use case: selection highlight

You have a map, and you want to be able to hover over/click on a line and see the line highlighted.

The current workaround is to create a separate layer, and show the same line with a different style here. This is not without its problems, however.

Highlighting a line when a lot of features are displayed at the same time is SLOW. This is because actually filtering out that feature in a different layer is O(n). In contrast, drawing a border around a circle using feature-state is O(1).

I have witnessed these speed differences in practice. Highlighting a line when I have loaded all of my features takes around 2-3 seconds, whilst highlighting a circle is basically instant.

This is also quite ugly in code, as I need to have vastly different logic for highlighting lines and circles.

Use case: make line easier to see on chaotic background

Adding a black or white border to the line will make it stand out more clearly on a map that contains a lot of colors (like on a satellite map)

1ec5 commented 1 year ago

@galinelle, this is fixed by #12208, right?

1ec5 commented 1 year ago

Despite the mention of new properties in #12208, these properties don’t seem to be supported or documented yet; just some groundwork I guess.

mack-guardian commented 1 year ago

this would be a useful feature if documented, it looks like #12208 should enable it