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

Remove protected area fill color #3887

Merged
merged 5 commits into from
Dec 15, 2019

Conversation

meased
Copy link
Contributor

@meased meased commented Sep 14, 2019

Fixes

Does not close any issues, but may help mitigate #2199, #3685.

Related to #3045, #3656.

Changes proposed by this pull request

  • Boundaries of protected areas rendered as a fade.
  • Removes the translucent fill from z8-z10.
  • Defines a new @protected-areas color (instead of just using "green").

Rationale

The intent of the current rendering is make it apparent which parts are "inside" of a protected area and which parts are "outside". This PR doesn't change that, it is just a alternate graphical presentation of the same idea. I believe it does a better job of representing the intent, while at the same time being less visually noisy.

Test renderings

https://www.openstreetmap.org/#map=10/42.8734/-120.7040
Before:
diablo_old
After:
diablo_new

https://www.openstreetmap.org/#map=8/46.113/-121.058
Before:
gifford_old
After:
Notice here the "shared borded" case. Also depicts shared and overlapping borders with aboriginal land.
gifford_new

(My database is a bit out of date...)
https://www.openstreetmap.org/#map=9/47.8546/-123.5550
Before:
olympic_old
After:
olympic_new

https://www.openstreetmap.org/#map=15/46.5494/-121.5966
Before:
close_old
After:
close_new

@jeisenbe
Copy link
Collaborator

The gradient effect looks quite interesting. I like that the borders are not so prominent now, but the internal side is still clearly visible.

In the current commit this is achieved by using multiple attachments:
::innerstrokefade1, ::innerstrokefade2, ::innerstrokefade3 etc.

Is this preferable to using the alternative that we use for roads? eg:

	        a/line-opacity: 0.12;
	        a/line-width: 2;
	        a/line-offset: -1;
	        b/line-opacity: 0.08;
	        b/line-width: 2;
	        b/line-offset: -3;

I don't know if there is a performance benefit to one option over the other.

@jeisenbe jeisenbe added the admin label Sep 15, 2019
@sommerluk
Copy link
Collaborator

The :: structure is applied per layer, while the a/x structure is applied per data-item. So they do not give the same rendering. However, as protected area boundaries come from the polygon table and should seldom cross, the visual impact should not be big.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 15, 2019

I've tested this PR at mid to high zoom levels in Singapore. The new borders are much more subtle, especially in woodland areas, and near roads and barriers:

z17 Chestnut nature park

https://www.openstreetmap.org/#map=17/1.37291/103.78089
Before
z17-chestnut-park-before

After
z17-chestnut-nature-park-after-17:1 37291:103 78089

z14 Chestnut / Lower Pierce

Before
chestnut-pierce-before

After
z14-chestnut-nature-park-lower-pierce-after

z16 Kranji Marshes

https://www.openstreetmap.org/#map=17/1.4199/103.7303
Before
z16-kranji-before

After
z16-kranji-marshes-after-1 4199:103 7303

@jeisenbe
Copy link
Collaborator

The :: structure is applied per layer, while the a/x structure is applied per data-item

Ok, so with use of transparency, it's better to use :: attachments. Thank you for the clarification

@imagico
Copy link
Collaborator

imagico commented Sep 15, 2019

I don't think this change would be an improvement.

It emphasizes the existing problem of using transparency (and the resulting trouble of creating visual ambiguities through color mixing) to a problem of variable transparency where this effect is further emphasized. The gradient on color and transparency introduces what is perceived to be a blur to the map essentially smearing everything in the background.

At the low zoom levels it also further emphasizes the already bold and massive rendering of these boundaries to be even more massive and dominating.

Like all other kinds of fading it tries to generate a compromise between showing something and not showing something which as a general rule does not work well in cartography.

The problem about nature reserve and similar boundaries rendering in this style is that it works only in a very narrow window of map scales and with simple semantics. The way we use it however is in most cases outside this window of scales and for a complex system of overlapping protections leading to the kind of unreadable results we can see. This problem is not solved by some tuning of the line rendering.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Sep 15, 2019

@imagico - I checked what you had done at the alt-colors style, but I see that you have removed the protected-area rendering: imagico@f5801f4

It seems unlikely that such a change would be acceptable for this style. Any other ideas for improvements?

@imagico
Copy link
Collaborator

imagico commented Sep 15, 2019

It seems unlikely that such a change would be acceptable for this style.

I don't think it is likely we could achieve consensus on this but a fairly strong argument could be made for it (non physical features, largely dysfunctional rendering, evidently counterproductive for mapper feedback and map readability in general, in many cases doubtful significance for a general purpose map).

If i was being asked what feature i'd drop from osm-carto if i'd have to choose one feature of significant weight in the style to drop the choice would for me immediately and without question fall on this. And i'd recommend this (to ask yourself what you'd drop if you'd had to choose one feature of impact) as something to consider for any style developer by the way - good cartography is at least as much about what not to show as it is about what to show.

@jeisenbe
Copy link
Collaborator

I see the argument for it improving the rendering, especially in Europe where landcover is well mapped and many National Parks appear to include many towns and villages, hence are not very protected.

However, these features are shown on most maps produced in North America: road maps, topo maps. US and Canadian users would be quite surprised to find National Parks missing. And US Wilderness areas are quite significant: all mechanical transportation is prohibited, including bicycles. Similarly, the protect_class=1a areas are as restrictive as military bases: usually no access is permitted. And aboriginal_lands (such as American Indian Reservations) often have similar restrictions for non-members: travel is only permitted on a few through routes without prior permission. I think the Brazilian and Australian protected indigenous areas are similarly restrictive.

@jeisenbe
Copy link
Collaborator

But getting back to this PR: since these areas are rendered, are there any suggestions for how @meased could make improvements?

How about using solid color lines rather than transparency, and slightly narrower width than currently? The current colors are ADD0AC for the narrow line over and CDDEC8 for the wider line, on untagged land. But we could try a lighter green than the current color, perhaps?

Then the protected-areas layer could be moved below roads and barriers, right before tourism-boundary, for example?

@jeisenbe
Copy link
Collaborator

At z8 the proposed rendering gives national parks a "3-dimensional" feel, like they are a bubble over the landcover:

Wales z8 before
z8-wales-national-parks-before

z8 after
z8-wales-parks-after

@imagico
Copy link
Collaborator

imagico commented Sep 15, 2019

I don't really want to discuss the idea of dropping protected/restricted area rendering here because as said it is unlikely we will be able to achieve consensus on this.

When you say:

I see the argument for it improving the rendering, especially in Europe where landcover is well mapped and many National Parks appear to include many towns and villages, hence are not very protected.

apart from probably overstating the differences between Europe and other parts of the world in terms of the meaning and use of nature reserve tags i hope you realize that you with that statement kind of acknowledge that showing these features is counterproductive for mapper feedback because it gives the illusion of things already being mapped while the map is essentially empty. You can see the practical effect of this for example in California where much of the landcover mapping is limited to areas with no protection status.

The different expectations of European and North American map users has probably less to do with actual differences in the geography of their countries but more with different cartographic traditions. In Europe most cartographic tradition predates the creation of formal nature reserves while in the more remote parts of the US most map production has happened after and was motivated by the existence of nature reserves.

The USGS topographic maps - which build a lot on European traditions and which were produced parallel to the creation of protected areas - interestingly do not prominently feature nature reserve boundaries.

@jeisenbe
Copy link
Collaborator

USGS topographic maps ... do not prominently feature nature reserve boundaries.

That was true of the older printed series. The 1955 legend doesn't mention National Forests, Parks or Monuments (administrative boundaries and Indian Reservations are showed with various dashed and dotted black line patterns).

But the current series shows National Forest, National Monument and National Park boundaries with a black dashed line and a pink color on the inside. (State and county forests and parks are shown rather minimally, just with a dot-dash black line):

USGS-new-boundaries-legend

@imagico
Copy link
Collaborator

imagico commented Sep 19, 2019

I am familiar with the largely automatically produced new 24k series and none the less I stand by my statement (which does not claim USGS maps do not show nature reserve boundaries).

To what extent these new maps are built of the USGS tradition and to what extent they build on other trends and are subject - like we - to technical and economic constraints of the framework chosen, is a different story.

If you want to take cues from these maps also note two things:

  • you are talking about the 1:24k scale - while as i indicated above one of the main problems with the drawing style we use here is that it only works in a very narrow range of scales.
  • the map style you mention is specifically intended to allow turning on and off different layers of the map separately.

Independent of that the widespread concept of paper maps to use a dark hairline signature (potentially with some form of dashing or line pattern) in combination with a broader, potentially asymmetric line for either emphasis or additional classification is something worth studying. Look in particular here where you can see how the dark centerline can in such case also be locally hidden in favor of other more important features while maintaining the visual continuity through the broader and weaker line.

The asymmetric border signatures in other maps are also often used to allow displaying two different line types along the same line in parallel without the need for displacement. Drawing rules for such can be quite complex and are obviously not possible to implement with independently drawing individual polygons. You'd need to analyze the topological structure of the boundaries for that.

All of this is meant to illustrate that compound line signatures are a relatively complex matter in practical application to work well. Just superficially imitating the look of some other map style but with a much simpler drawing logic is not going to make it work.

I very much appreciate the attempt of @meased to try out new ideas here but it is important to take a critical look at what problems this does not solve. And in this light i still don't think this change would be an improvement.

Copy link
Collaborator

@jeisenbe jeisenbe left a comment

Choose a reason for hiding this comment

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

Ok, I'll try to condense this discussion into some clear ideas for @meased to try:

dark hairline signature with some form of dashing or line pattern in combination with a broader, asymmetric line

This idea would be worth trying.

The protected-areas layer needs to be moved under highways and water lines.

The thin line should be adjusted so that it is always narrower than waterways, railways and highways at each zoom level, and should be made darker, either black, dark gray, or very dark green or brown. It would be good to use a dash-dot sort of pattern, but make sure it won't be confused with highway=track, bridleway or similar linear features.

The wider line should be changed to a solid color, without transparency. This means the green color needs to be adjusted so that it is still visible over forests, scrub, allotments, grass, parks and pitches. Perhaps a slightly bluer shade of green would work? The line should be wide enough that it is still visible when a protected area boundary follows a river or highway - so it will need to be wider than currently, at higher zoom levels.

I'm afraid this would take a bit of time to test and get right, so it is totally optional if you want to try these ideas or not.

@Prince-Kassad
Copy link

I don't really want to discuss the idea of dropping protected/restricted area rendering here because as said it is unlikely we will be able to achieve consensus on this.

It is also a tagging issue. Some national parks might be visible on the ground because they're prominently fenced in and only accessible by passing through specific checkpoints (i. e. Kruger). Most other nature reserves, however, are not. Apart from the occasional signpost, you can not tell the boundaries of a nature reserve just by looking at it. When they're mapped, it's because someone has found a public-domain/otherwise license compatible source and just felt like importing something to OSM because all imports are inherently good. This is entirely bad practice.

Anyway I don't want to take this further because it's a bit off-topic.

As for the PR, I am entirely in favor of dropping the fill color but reject the other changes. They blend in too much with common landuses (i. e. forest) at high zoom levels and make the name rendering look weird.

@imagico
Copy link
Collaborator

imagico commented Sep 25, 2019

Some national parks might be visible on the ground because they're prominently fenced in and only accessible by passing through specific checkpoints

And we render physical barriers of course and one of the constraints in nature reserve rendering is that it must not hide or disguise the display of physical barriers of course.

@Adamant36
Copy link
Contributor

Some national parks might be visible on the ground because they're prominently fenced in and only accessible by passing through specific checkpoints

From what I've heard some national and state parks also mark the trees around their boundaries.

@kennykb
Copy link

kennykb commented Sep 26, 2019

I feel strongly that nature reserve rendering needs to preserve a visual distinction between 'inside' and 'outside. (A subtle highlight on the 'inside' side of the line will suffice.) Otherwise, interpreting the map of a diffuse area like https://www.openstreetmap.org/relation/6362702 becomes inordinately difficult when looking at high zoom at the irregular border.

From what I've heard some national and state parks also mark the trees around their boundaries.

Yes indeed. In my part of the world the protected areas are all pretty apparent if you're on a road or path, because there are indeed markers. Some places mark the whole boundary with them.

https://www.flickr.com/photos/ke9tv/14018132286 (New York City Watershed Recreation Area)

https://upload.wikimedia.org/wikipedia/commons/3/31/NYS_Forest_Preserve_sign.jpg (New York State Wilderness Area)

https://www.flickr.com/photos/blogdog/119668164/ (North Carolina State Park)

https://upload.wikimedia.org/wikipedia/commons/7/7c/National_Forest_Wilderness_Boundary_Marker.JPG (US National Forest)

https://appalachiantrail.org/images/default-source/myatstory/myatstory_df/d80_5701.jpg (US National Park Service)

Far from a road or trail, the marking may drop back to the marking of survey lines. These will be marked with hatchet blazes https://inr.oregonstate.edu/file/glocornercap2png is an old one before refreshing it, and https://inr.oregonstate.edu/file/glocornercap3png is a refreshed blaze revealing the original surveyor's mark. Newer marks may just be blazed with paint - it's much less durable but also thought to be less damaging. https://www.flickr.com/photos/ke9tv/17257829216 is pretty typical of what one will see in the field.

I've done many off-trail hikes where I've navigated by following a survey line part of the way. The lines exist and can be followed. You may argue that the individual signs and blazes don't make a line, but in practice the blazed features are close enough together that you can sight between them to strike a line - for OSM's typical level of accuracy, even a mirror-sight compass would be Good Enough.

When they're mapped, it's because someone has found a public-domain/otherwise license compatible source and just felt like importing something to OSM because all imports are inherently good. This is entirely bad practice.

That statement is entirely out of the bounds of courtesy and respect for your fellow mappers. It assumes that the entire world is like the dense cities where OSM excels, and that if it isn't practicable to map an area in the field, that means nobody cares about. It dismisses entirely the concerns of those of us who live or travel in remote areas, and have to deal with the constraints of trying to do something useful with far too few people.

Yes, I've brought in a bunch of boundaries by import, because I can't go out and survey them all. That doesn't mean they can't be surveyed or that they're not visible; it's just that it's a lot of work getting to these lines (and isn't always lawful - some of these areas have 'stay on trail' rules). I have tried to resolve some of the biggest inconsistencies. For instance, I've made the arduous trip in to the obvious worst corner of https://www.openstreetmap.org/relation/6304865 - out of sheer curiosity and cussedness. I found rock cairns at both corners. This would be the fount of a property line dispute to be resolved in the courts, if the landowners on the two sides were hostile. Since both landowners (New York State Department of Environmental Conservation, and New York City Bureau of Water Supply) are friendly, the inconsistent line is just there. Both of them. Land surveying in these areas is far from perfect, and it's what we have to live with.

It's not that nobody cares, or even that too few people care. The Adirondack Mountains, where I do a lot of my mapping, have fewer than five inhabitants per km² - three-fourths of whom have no internet access. There's no cellular phone coverage in a lot of the region. And yet, there are those of us who travel there, and wander that wilderness. We wish not to trespass, and need the boundaries. We also want the trails to be mapped - and that is something for which no good data sources exist, so we have to map them ourselves. (There are data sources available for import. The data quality is poor enough that importing them would endanger travellers.) Mapping all the boundaries, when professional crews have gone in with differential GPS on many of them and made their results public, would be a duplication of effort requiring a number of people that we simply do not have.

This limitation is true even at the level where you would imagine that there are near-unlimited resources to establish boundaries. There are some county lines in the area that have never been surveyed successfully on the ground. https://caltopo.com/l/L1F4 is an example. But the fact that a portion of the line between them is indefinite does not mean that nobody cares that Franklin County and Essex County exist, or that nobody cares about where the Essex County line cuts through Keeseville or Schroon Lake. We should be able to answer the question, "what county is Lake Placid in?" or "is Vanderwhacker Mountain in the High Peaks Wilderness?" despite the fact that there's uncertainty in a line that is kilometers away.

We're doing the best we can with the resources we have. And all that we hear from some quarters is that the hard work of the few people that we have available doesn't meet an OSM minimum standard and doesn't deserve to be in the map. If that's the message you're trying to send, it's coming through loud and clear. We're not ignorant of it. We simply reject it.

@Prince-Kassad
Copy link

And all that we hear from some quarters is that the hard work of the few people that we have available doesn't meet an OSM minimum standard and doesn't deserve to be in the map. If that's the message you're trying to send, it's coming through loud and clear. We're not ignorant of it. We simply reject it.

OpenStreetMap explicitly does not have any minimum standards beyond some legal constraints preventing us from mapping certain features (i. e. private information of residents like name/phone/email, in the case of businesses women's shelters and the like). Other than that, we map everything, including features that might seem spammy or culturally unacceptable to some.

I've done many off-trail hikes where I've navigated by following a survey line part of the way. The lines exist and can be followed. You may argue that the individual signs and blazes don't make a line, but in practice the blazed features are close enough together that you can sight between them to strike a line - for OSM's typical level of accuracy, even a mirror-sight compass would be Good Enough.

You speak for the American continent, which I have to admit I've never set afoot on.

On the European continent, signs are purely of an informative nature, only posted along roads and they're so few and far in between that you could not guess the boundaries of a nature reserve just by looking at the signs alone. In many cases, the borders are only defined by a printed map that is lying around in some office, only viewable by physically showing up at the office to take a look at the printed map. All the nature reserve borders on the European continent come from imports of some kind, usually the EEA import which we have explicit permission to import into OSM.

Edit wars over nature reserve boundaries are all too common in Europe because when the only source is not publically accessible beyond showing up in some office and there's no way to figure out the boundaries from the ground, there's bound to be unresolvable disputes because there is no "right" or "wrong" like with most other features of the database. They've more or less destroyed the German community, for example, which is harmful to OSM as a whole. We cannot be wasting time on these edit wars, we really have better things to do.

@meased
Copy link
Contributor Author

meased commented Sep 27, 2019

My original goal for the PR was to tone down the strong rendering of nature preserves. I have read through the comments and spent some time trying to incorporate some of the ideas discussed above. Here are some quick results:

  • Color is not pure green anymore.
  • Dash-dot border.
  • Fade is removed.
  • Bugfix: Border and text are now based off of the same color.
    • The text was a darkened park color before.

reserve_dashed

@kocio-pl
Copy link
Collaborator

Dash-dot border.

What is the direct reason for this? I rather understand it as something like admin border, not for standalone areas.

I also don't see the difference between green and brown areas other than on labels and I think this is too close.

@meased
Copy link
Contributor Author

meased commented Sep 27, 2019

What is the direct reason for this?

It was brought up by @imagico in the above discussion in reference to paper maps and @jeisenbe mentioned that it would be worth trying.

I rather understand it as something like admin border, not for standalone areas.

Preserves are admin borders. They are classified in this style as admin borders, they are defined in the file admin.mss.

I also don't see the difference between green and brown areas

I can see the difference quite clearly. Any other opinions on this?

With so many features vying for attention in this style, are the differences between nature preserves and abiriginal preserves really worth cranking up the contrast up for? As I have stated before, toning this feature down was the primary goal of this PR.

@Prince-Kassad
Copy link

The proposed change will accentuate #3647.

I am not entirely sure why we render preserves like this, but it is probably some cultural difference I'm unaware of.

@kocio-pl
Copy link
Collaborator

Dotted border looks to me too similar to the real border going along protected area, like here:

protected-border

@jeisenbe
Copy link
Collaborator

jeisenbe commented Oct 3, 2019

Sorry, the current color and opacity is too light to be visible on woodland and scrubland areas:

z14-ronnheck-compare

z14-ellergronn-compare

I was thinking of using a much darker narrow line, with full opacity, but rendered underneath roads.

@jeisenbe jeisenbe closed this Oct 3, 2019
@jeisenbe jeisenbe reopened this Oct 3, 2019
@jeisenbe
Copy link
Collaborator

There are some conflicts that need resolving due to #3911

@jeisenbe
Copy link
Collaborator

I've fixed the merge conflict. But I still believe the current commit is too low of opacity to be clearly visible on several types of vegetation (see #3887 (comment))

@meased, I think we have consensus to make the 2 smaller changes in this PR right away. Would you be interested in limiting the changes to these:

  • Remove the translucent fill from z8-z10.
  • Define a new @protected-areas color (instead of just using "green").

Then we can work on the more extensive rendering changes later?

@meased
Copy link
Contributor Author

meased commented Nov 16, 2019

@jeisenbe, I have made the changes you suggested.

Note that before, the color of the area labels (darken(@park, 70%)) was different that the color of the border labels ("green", #008000). Now that both colors are defined in one place as #008000, the area label color is noticeably different.
protected_label_colors

And one more to show the fill removal at z8-z10:
protected_area_fill

@jeisenbe jeisenbe dismissed their stale review November 17, 2019 10:44

PR updated

@jeisenbe
Copy link
Collaborator

There is one line that needs to be fixed in the latest commit.

The new label color is less similar to named woodlands. This makes it easier to distinguish protected area labels from named woods or forests.

Left before, right after
z14-enneschte-besch-beforez14-enneschte-besch-after

Wales at z8 and z9:

z8 Snowdonia National Park - before
z8-snowdonia-before

After
z8-Snowdonia-park-after

z9 South Wales before
z9-brecon-before

After
z9-Brecon-beacons-park-after

Copy link
Collaborator

@jeisenbe jeisenbe left a comment

Choose a reason for hiding this comment

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

Thank you, @meased. I have approved this PR.

The current commit changes the central labels on boundary=protected_area, boundary=national_park and leisure=nature_reserve from darken(park, 70%) to a new variable @protected-area with value #008000 - this color is the same as green used previously for the text labels along the boundary, but the hex code is more consistent with how other colors are named. This color is higher saturation and lightness than the previous text color, which makes it more distinct from the labels for parks and woods. The new color is somewhat closer to the leisure=garden text color, but those features are less likely to overlap with protected natural areas.

The transparent green fill color, which was only used at z8 and z9, has been removed. This reduces the confusing color mixing and makes it easier to see where landcover features (like landuse=meadow, natural=wood) are missing at z8 and z9 - the previous rendering gives the false impression of some sort of landcover mapping in protected areas.

I believe these 2 changes are clear improvements to map legibility and mapper feedback about consistent tagging. And subjectively the map looks a bit clearer:

z9 southern Wales - after
z9-brecon-after-new

Text labels comparison:
text-labels-after

@jeisenbe
Copy link
Collaborator

I will merge this PR in a day or two, unless there are any concerns or objections?

@kocio-pl
Copy link
Collaborator

I have no problem with current rendering, but I think this is also plausible solution.

As seen on the example renderings, dropping the fill makes inconsistency with some big military areas (they have a fill) and a new border makes it harder to see on a forest, but these problems are not blockers.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 23, 2019 via email

@imagico
Copy link
Collaborator

imagico commented Nov 23, 2019

I won't block this if others find this beneficial since i don't see this introducing too serious new problems but: i don't see this actually solving any of the big problems with nature reserve/protected area rendering.

I would regard this mostly as trying to change things a bit in the hope that in application this might be slightly better than what we have right now although we know that if at all this improvement will be marginal.

Regarding the pointer to Apple from @jeisenbe - yes, that is something important to always keep in mind when taking cues from other maps. Google, Apple and others - they have different goals than we with their maps. But of course some aspects - like to have an appealing and readable map - are common goals. We need to make up our own minds about what cartographic strategy is beneficial for our goals. Adjusting to what people at a certain point would want when they think of our style as a Google/Apple maps replacement (and this is in my eyes the main reason for the landcover fading we have right now) is not a good idea because

  • the goals are different and
  • their strategy to serve their goals might change completely from one day to the other.

One thing by the way to keep in mind in consideration nature reserve rendering vs. landcover rendering (which at all zoom levels is a universal conflict at the moment) is that mapper feedback through the map is much more significant for landcover. Nature reserves/protected areas are rarely mapped on the ground because they are often not locally verifiable but are imported from external sources instead. Mappers depend much less on feedback through the map for accurate mapping of these than for landcover mapping.

@meased
Copy link
Contributor Author

meased commented Nov 24, 2019

i don't see this actually solving any of the big problems

I agree.

Here's the problem as I see it:

  1. Reserve rendering is not verifiable and is an eyesore on the map a vast majority of the time.
  2. A small number of reserves are very prominent and not rendering them is a sin akin to leaving a city off the map (strong user expectation, at least in some cultures).

As with airports, we lack a tagging system the differentiates minor reserves from major reserves. This may be the ultimate solution to this problem.

We've tried using a fill, using an outline, dashing the outline, and smudging the outline to no avail. Just to be complete, I think someone somewhere mentioned displaying labels without displaying the outline/fill (at least for low zooms), easy enough to test:

Gifford Pinchot (current/new):
Selection_005
Selection_006

Olympic (current/new):
Selection_007
Selection_008

It's a bit like someone turning the static off of a TV set...

@Prince-Kassad
Copy link

As with airports, we lack a tagging system the differentiates minor reserves from major reserves. This may be the ultimate solution to this problem.

This would very likely create another "mapping for the renderer" pitfall like with leisure=water_park. I'd rather not make a rendering distinction based on completely subjective criteria/cultural bias.

@imagico
Copy link
Collaborator

imagico commented Nov 24, 2019

Label only rendering with the label styling and starting zoom level being dependent on the geometry without visual feedback on the geometry is out of the question - see #3634.

@jeisenbe
Copy link
Collaborator

dropping the fill makes inconsistency with some big military areas (they have a fill)

That's true, but it's also the case currently at z10 and higher: there protected areas only have the (double) outline, but no fill, while military areas always have the semi-transparent red fill and cross-hatching.

new border makes it harder to see on a forest

True. The idea is to make it clearer when landcover such as forests is mapped, which means that the protected area will be less visible. We could use the double-outline style for z8 and z9, but I think that isn't necessary at low zoom levels such as these, where it is rare for a protected are to be larger than the screen. The double outline is used at z10 and higher, where it's likely for larger national parks to extend off the screen, and then the inner line helps show what side is the inside of the protected area.

Label only rendering with the label styling and starting zoom level being dependent on the geometry without visual feedback on the geometry is out of the question

Agreed.

we lack a tagging system the differentiates minor reserves from major reserves

We could try experimenting with rendering different protected_class levels later. For example, protect_class=2 (national parks) may be worth showing at z8 and z9, while protect_class=5 and =7 might not be as significant, but this would require testing in different countries to see the results. However, I think this can be done in another PR or issue.

Overall, I think the 2 small changes in this PR would be an improvement, so I am willing to merge this if @meased is happy enough with the current commit.

@jeisenbe
Copy link
Collaborator

@meased are you ok with merging this as is?

@meased
Copy link
Contributor Author

meased commented Dec 12, 2019

@jeisenbe Yes.

@jeisenbe jeisenbe changed the title Fade protected area boundary Remove protected area fill color Dec 15, 2019
@jeisenbe jeisenbe merged commit 9b82c0e into gravitystorm:master Dec 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants