Proposal for design goals and guidelines - part 2 #2462
Conversation
|
Looks good.
This could be a bit less restrictive, for example: "The only situation where this can be appropriate is in case of features that get very large (for example larger than a typical monitor) and where labeling or drawing them is therefore no more useful."
This sentence is not clear to me. Ideally, it would also be good if somebody that is not so familiar with our processes could read over this and give feedback. |
CARTOGRAPHY.md
Outdated
|
|
||
| Transparency should be used very carefully with consideration for the color mixing this can result in and the ambiguities possibly caused by it. | ||
|
|
||
| It is generally advisable to design color relationships in perceptual color spaces. Use of internal color functions like `lighten()` and `darken()` should be considered carefully since they are performed in sRGB. |
There was a problem hiding this comment.
This is not necessarily true in all cases in Carto 0.16.x
There was a problem hiding this comment.
Do you say that behavior of these functions has changed and rendering results with recent carto versions are not backwards compatible?
There was a problem hiding this comment.
No, they are backwards compatible, otherwise I would have had to tag 1.0.0. But they are not necessarily performed in RGB. If you have a HuSL color as input the calculation is performed in this color space, which is a perceptual one (even if a bit distorted). You can also force conversion and calculation in this color space by using lightenp darkenp functions.
There was a problem hiding this comment.
Ah, that is - well - unexpected. What happens if you mix rgb and husl: mix(#fff, husl(100, 50%, 50%), 50%)?
There was a problem hiding this comment.
If we decided to use husl we'd have to revisit this, but as it stands, the text is accurate.
There was a problem hiding this comment.
@imagico when there is a husl colour present the calculations happen in husl colour space
|
cc @k127 |
Yes, that probably could me made clearer. What i had in mind here is things like dense city centers with shops etc. If only like half of the icons that could be shown are actually shown due to the lack of space and there is no meaningful prioritization to select which are shown that leads to arbitrary and therefore undesirable results. We could also remove that because it is actually just a special case of what is written in the general part already:
Probably a good idea. |
|
I am a bit surprised that there is not much objection to the specific guidelines proposed here. They clash with quite a few design decisions we currently have in the style and while likely everyone agrees there is a lot of room for improvements in the current design i did not expect that everyone agrees where these deficits are. Or maybe i just phrased the more controversial points in ways that are difficult to understand. Of course it is also clear that just because some aspects of the style currently are at odds with some fairly fundamental and broadly accepted design principles that does not necessarily mean there is an easy way to fix this without causing new problems. |
|
I didn't have the time to read such a big chunk of text yet. It's hard for me to comment it, because it's so high level and there are so many words, that even just reading "Design guidelines" was substantial effort and I leave the rest for later. I'm not able to get the whole picture - let alone have my opinion on every paragraph. This might not be a problem in itself - this change describes your vision and it can make people think in a certain way. I'm interested more in how such vision is applied to a map and this is just a different level. Currently I can only point out one problem - I don't get what's the meaning of this sentence, so I'd like it to be rephrased:
From my point of view it would be better if this text is much shorter (to avoid people TL;DR-ing) and instead have some examples. Current form sounds like a blog post - I like to read such things from time to time as a food for thought (including your blog). If you want it to be casual help in case of doubt, this is OK for me, but if you want people to follow it in everyday activities, I think it needs to be seriously edited (for example by a fellow journalist). It depends on how do you expect people to use it. |
There was a problem hiding this comment.
I read through it. As it stands, the current text is difficult to read through, excessively lengthy, sets out too many complex guidelines, and will probably not be helpful for people not already contributing to the project.
I'd like to see
- Much less text. Right now it's ~1.5k words, I'd like under 500. I'd also like to see the existing text shortened, but that can be a different PR.
** Less text per guideline
** Fewer guidelines - Shorter sentences
- More sections of shorter length
- References to external resources for general cartographic principles when possible
- A better split between technical recommendations (e.g. avoid
lighten) and cartographic principles.
I'm not providing a detailed review of the content since I think the bigger issues need to be addressed first, and it will be easier to review a shorter document.
Technical issues
- Sentences should have a single space after them, not two.
- The convention from
README.mdis to hard wrap lines, which helps in reviewing long paragraphs.
CARTOGRAPHY.md
Outdated
|
|
||
| Decisions on if and how to display something in the map should be primarily based on the significance of features for the purposes and goals above. | ||
|
|
||
| * How often something is currently mapped in OSM has relatively little influence on such decisions. Widespread use of a tag can be a supporting factor but should never be the reason for rendering something. Tag use also needs to be seen in relation to the actual occurrence of the type of feature in reality. And rare use of a tag of course means there is very limited information to assess the quality of the data. |
There was a problem hiding this comment.
👎 for this phrasing. We want to exclude PRs for <new feature with no uptakeyet from users>
There was a problem hiding this comment.
But do we have a clear guideline on what basis we decide this? I thought about this point when drafting the text and i could not really find such a principle in past decisions.
CARTOGRAPHY.md
Outdated
| @@ -37,3 +37,67 @@ account. | |||
| * **A rich map** - This style deliberately creating a fairly rich map showing a significant number of different features. This way it shows the richness of OSM data and gives a broad recognition to the mappers' work. The aim is not however to show all or even most of the OSM data. | |||
| * **Maintainability** - The implementation of this style should not be too hard to maintain. This refers to both the volume and complexity of the code and how fast the style can be parsed when rendering it, which is very important for efficient development work. So the amount of code should be kept small and complex and fragile interdependencies should be avoided. If the code is difficult to maintain this would ultimately seriously affect all of the above goals. | |||
| * **Adaptability and ease of use** - The style should be easy to customize, like for creating localized or special purpose maps. It is also important to keep demands on rendering infrastructure for serving the style low so it is not too difficult and costly to set up a tile server for this style or a specialized variant of it. | |||
|
|
|||
| ## Design guidelines | |||
There was a problem hiding this comment.
I think this entire section is too long. #1630 (comment) seems relevant, and the problems with your suggestions there seem repeated here.
There was a problem hiding this comment.
I'd set a target of about a third of the current wordcount for this section, less if possible.
CARTOGRAPHY.md
Outdated
| Decisions on if and how to display something in the map should be primarily based on the significance of features for the purposes and goals above. | ||
|
|
||
| * How often something is currently mapped in OSM has relatively little influence on such decisions. Widespread use of a tag can be a supporting factor but should never be the reason for rendering something. Tag use also needs to be seen in relation to the actual occurrence of the type of feature in reality. And rare use of a tag of course means there is very limited information to assess the quality of the data. | ||
| * If mapping in OSM (i.e. use of tags and geometric representation) is consistent, verifiable and accurate is highly relevant. Rendering something that is mapped inconsistently is counterproductive for all of this style's purposes. Consistency is to be looked for both in a positive way (mapping with the tag in question is consistent) and in a negative way (the same kind of object in reality is not frequently mapped in a different way). Different competing tags can be accepted (to be rendered in the same way) if both variants are well established and the difference mainly exists for historic reasons and their use is compatible. |
There was a problem hiding this comment.
I get some of what this is trying to say, having worked with landuse=forest and natural=wood. I don't think most people will understand it.
I'm not sure if I agree with it as phrased.
There was a problem hiding this comment.
This is a good example for the subject of writing style i think - the main idea is in the first sentence here. We could leave it at that. With the following i try to explain the reasons for having this rule, what is actually meant by consistent and that there are some exceptions being made for long term established tags.
I think these might be helpful for a contributor to understand but i am not sure about this. If most readers don't understand this it is surely better to remove it.
CARTOGRAPHY.md
Outdated
|
|
||
| Design of symbols, area and line patterns should be in a way that avoids their geometries to be mistaken as actual data. | ||
|
|
||
| How something is rendered should - as far as possible within the guidelines and goals outlined so far - be in line with mappers' expectations. If the way something is rendered appears either ugly, too prominent, contradicting or diametrical to readability in general mappers will try to avoid mapping it this way and if another feature class appears to look more according to the expectations its tagging is often used instead (also known as mapping for the renderer). Similar things happen if the way some feature is rendered is very generic, not particularly indicative and distinct for the class of features it is meant to represent. It then will often be abused to map other types of features. For these reasons it can be more productive to not render something than to render it in a suboptimal way. |
There was a problem hiding this comment.
I'm not sure what "be in line with mappers' expectations" means here.
There was a problem hiding this comment.
Ideally the way we render things should confirm the mapper that he/she mapped correctly. If the rendering is highly unexpected that would not be good. Usually something like this will likely also create conflicts with other design principles but it would not hurt IMO to also make this as a separate point to consider.
CARTOGRAPHY.md
Outdated
|
|
||
| If several similar types of features should be rendered identically or differently and which features should differ strongly in appearance and which only in minor nuances should foremost be based on their difference in meaning and purpose for the target map users. Differences in physical appearance are only relevant as far as they also represent differences in meaning and purpose. | ||
|
|
||
| Using data that is not from the OSM database should be avoided - unless it is strictly necessary for the goals. Preprocessing of OSM based data can be and is used (like for the coastline) but should carefully be considered regarding the influence this has on mapper feedback. |
There was a problem hiding this comment.
I thought this was covered already
CARTOGRAPHY.md
Outdated
|
|
||
| Also important in terms of mapper feedback is that how data influences the appearance of features in the map needs to be comprehensible for the viewer. Complex relationships and unexpected interactions between different features should be avoided. | ||
|
|
||
| One particular consideration due to this style being an important part of the public face of OpenStreetMap is to be careful and considerate with changes having a strong impact on the overall appearance of the map, especially with elements that have been rendered a certain way for a long time. Such changes should be broadly discussed also beyond the issue tracker and comments and concerns should be carefully considered. |
There was a problem hiding this comment.
We don't need to discuss beyond the issue tracker, but instead inform people that a change is being considered and that discussion is taking place on the issue tracker.
There was a problem hiding this comment.
I disagree here - Because of the map style being the face of OSM in many ways we need to be willing to discuss significant changes to this with the OSM community on a larger scale. @matkoniecz did this quite well with the road color changes and if we should have other changes with similar impact in the future (boundary color and water color come to mind here) we should broaden the discussion on these as well. This does not mean decisions should be made elsewhere but opinions should be considered even if they have only been articulated abroad.
There was a problem hiding this comment.
I think its difficult to make this it a hard requierement to broadly survey all communication channels for discussions (also when looking at the relation between workload for this and possible outcome). I support what @pnorman has sad.
CARTOGRAPHY.md
Outdated
| * Decisions at what zoom level to start showing a certain feature type should prominently consider that not actually rendering a large number of elements because of competing labels or icons is often diametrical to the purpose of providing useful mapper feedback, in particular if feature priorities are not based on a meaningful property. | ||
| * Decisions at what zoom level to start showing something are also particularly prone to causing bad mapping decisions (mapping for the renderer). This should be considered when making choices here. | ||
|
|
||
|
|
There was a problem hiding this comment.
there's an extra newline here
CARTOGRAPHY.md
Outdated
| * Design differences between zoom levels should be small and used with caution. Map users should be able to read the map without learning to interpret every zoom level separately. Continuous or small step changes over multiple levels is preferable in comparison to constant styling across multiple levels followed by a huge step. When increasing dimensions (line widths, text sizes, icon sizes etc.) with higher zoom levels this size increase should not be larger than the scale ratio between the zoom levels, in other words: sizes in which things are drawn should not increase relative to ground units with increasing zoom level. | ||
| * Many map features start being displayed at a certain zoom level and continue being shown, sometimes with changing styling, at subsequent higher levels. What is highly undesirable though is to show a feature first and then have it vanish again at a higher zoom level. The only situation where this can be appropriate is in case of labels for features that get very large and where labeling them is therefore no more useful. | ||
| * Decisions at what zoom level to start showing a certain feature type should prominently consider that not actually rendering a large number of elements because of competing labels or icons is often diametrical to the purpose of providing useful mapper feedback, in particular if feature priorities are not based on a meaningful property. | ||
| * Decisions at what zoom level to start showing something are also particularly prone to causing bad mapping decisions (mapping for the renderer). This should be considered when making choices here. |
There was a problem hiding this comment.
Not clear what this means
There was a problem hiding this comment.
Mappers frequently choose incorrect tagging to push features to a lower zoom level. Like for example by tagging remote hamlets/villages as place=city. Such things cannot always be fully avoided but they should be considered when making styling decisions IMO.
There was a problem hiding this comment.
But how could the style help to avoid this? Rendering hamlets yet at z7 would likely avoid tagging hamlets as cities, but would break other parts of the feedback loop.
There was a problem hiding this comment.
In this case considering the population tag would probably help. But you have to be careful of course so the rendering rules are still comprehensible for mappers.
To be frank - if we right now had the decision to make if and how to render place=city/town/village/hamlet i would probably be against differentiated rendering at all because the wiki lacks a clear definition of the tags and the data is globally quite inconsistent on the matter. place =city essentially just means here the mapper thought this is a place that should be shown significantly earlier and more prominently than other populated places.
CARTOGRAPHY.md
Outdated
|
|
||
| ### Zoom levels | ||
|
|
||
| An important aspect of styles for interactive maps is that they are used for a large number of different map sizes or zoom levels. This creates special challenges for map design. A particular problem with this stems from the fact that the Mercator projection is a variable scale projection so the different zoom levels do not represent specific map scales. This fact should always be considered when making design decisions. Styling should always work for the whole map and for the whole range of map scales present in the zoom level in question. This normally requires testing changes in different areas at different latitudes. |
There was a problem hiding this comment.
I'd pull this paragraph out and put in something in general about the style needing to work around the world, city density is often relevant, and in the mercator projection density can change with latitude. I'm not sure what section that would go in.
|
@kocio-pl #1753 (comment) gives an example of this sentence. |
Yes, as I read through it, it reminded me of a first draft of one my blog posts when I have all the content I want in, but haven't started to remove stuff. |
|
Ok, it seems the current draft is widely considered hard to read and understand. This can probably be improved. I was specifically not trying to make this a list of short bullet points of the form do this, don't do that because in my eyes this is ultimately of little help since good design cannot be condensed into a set of simple rules. Therefore i deliberately tried to include the reasoning behind and the interrelations between the principles listed which probably makes it fairly abstract. I would appreciate it if you could make some concrete suggestions how to formulate things in a more compact and better understandable way. I don't think i would be able to compress this to something like 1/3 the volume without removing a lot of things i consider important. But i am open to the idea of a more compact document as long as this still represents those things we consider the guiding principles here. |
I agree with this as well, I also found the text long and hard to get through. |
|
I understand the need to learn people to think about cartographic design, but style documentation is not a good place for general education. So maybe here we should have only guidelines in a nutshell (like bullet points), but you could use the current text as a base for an article - or even series of articles - about the reasoning behind it? |
|
As said i understand the desire to make it shorter but at the moment i don't see how i can compress it to about 1/3 the volume while still keeping it a comprehensible guideline for contributors. So i could use some more specific suggestions how to formulate things in a compact yet understandable way. |
|
That's why I suggested help from someone with journalistic background - I know how hard is it to be an author and editor at the same time. |
|
I liked the three bullet points in another issue from which this discussion started. It leaves a lot of rationale implicit, but to me that's fine. I also liked the style of the original documentation. |
|
Ok - i thought a bit more about this and it seems quite clear to me that the approach i took, writing things down in the way i see them and trying to develop this into a common view on the design principles, won't work. It is quite possible that if someone else with a different point of view tries the same this could work better, approaching a consensus position both design wise and in terms of writing style from a different side. Independent from that i will try a different approach now, just formulating the individual design principles i consider most useful and important, in a very compact form. In my eyes this will probably be of rather limited help for contributors as practical guidelines. But it could make it easier for us to find common principles we agree upon and that is likely of significant help per se for contributors. I also removed those points which i consider less important because they are either generally accepted anyway, rarely turn up in practical work, are special cases of already mentioned more general principles or where we will likely not reach a common position (like rules what to render and what not to render). If that is fine with you I will add consistent line wrapping and change sentence spacing if and when we have a version ready for merging. @math1985 - regarding your early suggestion for
Could you point to a practical case where you consider dropping elements other than labels from rendering at higher zoom level is desirable? |
The only example I know: we currently drop the national park fill from z10. I'm not sure whether we should adapt the rendering rules to the guidelines or the guidelines to the rendering rules here. |
To me that is a styling difference between zoom levels (rendering fill+outline vs. outline only). But national parks do not fully disappear. The outline only rendering can of course be highly confusing, especially if there are several touching or nested features of this type. |
|
Then I'm fine with the original formulation. |
|
Now it's much better, thanks. My Zoom levels review - I think that points 2 and 3 could be merged:
|
|
I see no gain in this but i have no objections either. |
What about sport then? |
|
I did an initial skim, and it looks much better. I still need to do a detailed review. |
I guess that depends on if you consider that a vegetation related feature. 😄 In the original long version i had quite a few additional explanations on how this is meant. In any case keep in mind that neither the goals nor the more specific design principles we discuss now are conflict free. As i explained elsewhere the purpose here is not to slavishly obey rules but to make conscious decisions considering the different aspects that play a role. What we should ask ourselves is if these ideas are generally useful as guiding principles. |
For me, in cases where I see conflict (like " +* Use of red, orange, yellow and brown line colors should be reserved to roads and paths." vs linear brown outline of theme parks/zoos) I recognize that it is unfortunate but I see no ready solution to improve it and map would not get better from dropping rendering of that feature. |
CARTOGRAPHY.md
Outdated
|
|
||
| * Styling of map elements should always work for all parts of earth shown on the map and for the whole range of map scales present in each zoom level the feature is shown in. | ||
|
|
||
| * Design differences between zoom levels should be small. |
There was a problem hiding this comment.
"Design differences between adjacent zoom levels should be small."
I am not sure about exact word (adjacent/joining/neighbouring are all really bad), but it should be clear that z5 and z19 may have vast differences in styling and it is OK. It is partially clarified in the next line but it would be better to make it completely clear.
There was a problem hiding this comment.
subsequent is probably the right word here.
There was a problem hiding this comment.
Yes, 'subsequent' is what I wanted to propose.
CARTOGRAPHY.md
Outdated
|
|
||
| * Features can start to appear at a certain zoom level when zooming in but they should not disappear again at a later zoom level - except possibly for labels of features becoming very large. | ||
|
|
||
| * Starting zoom levels for showing features should be selected so that competition between elements does not result in the majority of features of a certain type not being shown, especially if there is no meaningful measure of priority that is used for selection. |
There was a problem hiding this comment.
I would remove "especially". With clear priority it is perfectly fine to start from displaying only some. First labels for countries appear on z3, first cities appear on z4 etc.
It is issue for things like shops where it is really hard to get priority.
There was a problem hiding this comment.
I think the only clear prioritization we have right now is the way_area based one and i don't think that is very good to use for showing/not showing features if there is strong competition. Even when just using it for prioritizing labels it can be fairly irritating. Any class based prioritization leads to arbitrary choices within the classes.
So i am fine with the change you suggested but it should be clear that "meaningful measure of priority" is pretty tough, especially if you are limited to information that is entered by the mappers.
There was a problem hiding this comment.
Yes, way_area works not as often as one may expect and cities are unique with population as objective ranging information that is usually available.
CARTOGRAPHY.md
Outdated
|
|
||
| * Use of red, orange, yellow and brown line colors should be reserved to roads and paths. | ||
|
|
||
| * Transparency tends to lead to undesirable and ambiguous color mixing and should therefore be used very carefully. |
There was a problem hiding this comment.
Is there any case where we are using transparency? I think that stronger wording ("should not be used" or similar) would better describe our approach to it.
There was a problem hiding this comment.
The most prominent use of transparency is currently the boundaries. This is especially problematic since they are in strong color leading to strange color mixing. Other uses are nature reserves and military areas.
CARTOGRAPHY.md
Outdated
|
|
||
| ### Zoom levels | ||
|
|
||
| * Styling of map elements should always work for all parts of earth shown on the map and for the whole range of map scales present in each zoom level the feature is shown in. |
There was a problem hiding this comment.
"should always work" is unfortunately too ambitious. I am pretty sure that for any feature one may find well mapped places where due to some special case map is not really working.
"should work for the entire range of displayed latitudes"?
There was a problem hiding this comment.
I was specifically trying to avoid making latitude the only criterion here. There are other aspects (like cultural and climate) that likewise play a role here even with out the latitude dependent scale.
So i would extend your suggestion:
"should work for the entire range of displayed latitudes and the full bandwidth of geographic situations that exists on earth"
There was a problem hiding this comment.
That would work well - "full bandwidth of geographic situations" is vague enough that failing for something really, really weird will not clearly violate it.
Maybe the wording should be changed like "should be reserved for" -> "should be primarily used for" to better reflect the intention expressed in this comment? |
No, if that is the general feeling we should remove those altogether. should be primarily used for is not really helpful as a guiding principle since an individual change will hardly ever change what a certain range of colors is primarily used for.
I generally dislike this kind of outline rendering independent of the color because it adds a lot of noise and bloat to the map with very little information and is only readable across a very limited range of scales. The main motivation for using it to me seems indeed to be able to overload colors by using them with a fairly distinct line style.
Well - we cannot solve all problems at once but recognizing where the issues are is the first step in solving them. Dropping features that have been rendered for a long time is going to be tough but it is for example not that far fetched to say that something like nature reserves can also be rendered in a separate overlay and therefore do not absolutely need to be in the main map. |
OK, makes sense for me. |
CARTOGRAPHY.md
Outdated
|
|
||
| * Stronger colors indicate fairly distinct and meaningful features as opposed to more general and less distinct features which use weaker colors. | ||
|
|
||
| * Small areas work well with somewhat stronger colors while large areas tend to call for weaker tones. |
There was a problem hiding this comment.
After some testing with midzoom and my thinking about parks, I guess it's not as simple. I would rather remove this rule.
There was a problem hiding this comment.
This is a fairly widely accepted principle but it is usually understood to be not the only guiding principle - see for example the point immediately before in the text.
If you want to remove this point i would like to see cases where you think violating it is desirable even though there are no other principles that suggest this.
Please keep in mind we do not color areas individually based on their size so this guideline refers to the typical size of areas of a certain type of course.
There was a problem hiding this comment.
What is important for me is if it works for this style. If we know the typical size (which is not always true) this is not always "smaller is more important". On the other hand I would also not argue that "bigger is more important", that's why I think it's hard to say about a rule here.
-
When working with midzoom I see that the area size doesn't matter for colors - it's rather areas vs lines and points (and you have proposed such rule in this PR, which I agree with).
-
When working with pitches I see that they are typically a part of the school area or sport centres. Both of these are now rendered as pale yellow and dark pitches/tracks were hiding the fact that they are just a part of the feature. We loose the feeling of having the structure, which I consider to be a bad thing.
-
The same with park. I see it like no matter if we have tree area or the grass area or whatever else, we're still basically in the park, this is the important frame for all the features inside and it looks bad when smaller areas make it not clear.
-
The land color is light as a bigger area than most of the others, and here is where this rule works for me. But if you can find both valid examples and counterexamples, we can't really talk about the rule any more.
There was a problem hiding this comment.
I cannot quite follow here since i neither understand which of the colors you mention you consider good and bad choices nor in what way you think the guideline interferes with that.
In my eyes a very good example for application of this principle in the past is the farmland color. This was relatively strong which would be in line with the fact that agricultural land use is fairly distinct and meaningful. But since agricultural land use covers huge areas in many countries it makes sense to give it a significantly weaker color to maintain an overall balance.
There was a problem hiding this comment.
Well, I've tried to give very simple examples from my experience - maybe other people could comment it?
Regarding agricultural land - I understand this and agree, but this falls into 4. for me: there are case where this works, but still it's not enough to coin a rule, because there are also important cases where it doesn't.
CARTOGRAPHY.md
Outdated
|
|
||
| * Size increase (line widths, text sizes, icon sizes etc.) with increasing zoom level should not be larger than the scale ratio between the zoom levels so sizes do not increase relative to ground units at higher zoom levels. | ||
|
|
||
| * Features can start to appear at a certain zoom level when zooming in but they should not disappear again at a later zoom level - except possibly for labels of features becoming very large. |
There was a problem hiding this comment.
What do you mean by "feature"? For example airport icons and city names are hidden in higher zoom levels, so maybe we should be more clear with mentioning exceptions.
There was a problem hiding this comment.
Feature here means OSM map feature - like in one feature, one OSM element. When the way a feature is rendered leads to some design elements disappearing as you zoom in but the feature itself continuing to be represented that is fine - see my remarks to @math1985 w.r.t. nature reserves in that regard. This still has to be considered carefully because of the irritation for the user this might cause, see also the keep differences between zoom levels small concept.
There was a problem hiding this comment.
Thanks, that sounds reasonable to me.
CARTOGRAPHY.md
Outdated
|
|
||
| * Features can start to appear at a certain zoom level when zooming in but they should not disappear again at a later zoom level - except possibly for labels of features becoming very large. | ||
|
|
||
| * Starting zoom levels for showing features should be selected so that competition between elements does not result in the majority of features of a certain type not being shown if there is no meaningful measure of priority that is used for selection. |
There was a problem hiding this comment.
This sentence needs rewording, because I read it few times and I'm still not sure what is the "result" we're trying to avoid.
There was a problem hiding this comment.
If you'd for example show all shops at z16 that would mean only a small fraction of the shops are actually shown (the majority of features of a certain type not being shown) because Mapnik does not render a symbol if there is already one rendered that would be overlapping. If the rendering order or prioritization of the shops is not meaningful (there is no meaningful measure of priority) the results would be highly non-intuitive which is not desirable.
There was a problem hiding this comment.
Thanks, now I understand this rule and I agree with it. However the language still needs simplifying to be usable. What about something like:
Starting zoom levels for a given feature should be selected to show at least most of these elements if we can't prioritize them.
If that's not precise enough for you, one can always add second sentence to clarify.
There was a problem hiding this comment.
I find my formulation more to the point and less cryptic but i am certainly not the right person to judge this.
There was a problem hiding this comment.
@math1985 What's your opinion as a senior collaborator? 😄
There was a problem hiding this comment.
I find the current text cryptic.
|
@imagico What do we need to proceed with this? |
|
I am not sure about this at the moment. My intent was to resolve #2270 by defining and documenting a set of overall principles regarding design in this style we all feel should guide us in decisions made. I still think the draft as it is - with maybe a few smaller changes still to be made - could serve this purpose. But it would be pointless if we do not adhere to what is written in it. And with changes like #2515 i really do not have the impression what we have done here has much useful effect (see in particular #2515 (comment)). |
imagico
force-pushed
the
design-goals-document2
branch
from
dfc2947
to
bb68be6
Compare
|
Ok, i looked over the previous discussion, made two changes:
In addition i reformatted to single spaced sentences and uniform hard line breaks. I am open to further suggestions for changes, esp. to make things better understandable but preferably not at the expense of precision (which is why i did not go with the suggestion in #2462 (comment) for example). Since this is supposed to document the guiding principles of this style i am not going to push for merging it unless all maintainers agree with these - it would be pointless to have rules in the repository we do not agree upon. But when contemplating these keep in mind that these principles, in particular the ones regarding use of colors, are not meant to be conflict free. There will always be cases where different design principles suggest different things and you need to find a middle way of sorts. You should not just look at each guideline individually and dismiss it if you can find a case where following only this principle will lead to a suboptimal choice. |
|
At this point in my life (outside the project) I'm not able to review this PR once again, and after so much time with no action I've just lost most of details. However I agree with big part of your propositions, and only few cases raised issues for me. For me the preferred option would be to merge all the non-controversial rules now, but I like our current policy that in the end it's simply your decision what to do. |
|
I understand - but i stand by my choice not to merge it without consensus of all maintainers. To me a value in having such a set of guidelines in the style would only exist if these are considered to be guiding principles by all of us. If you have a subset of the principles i drafted or a completely different set of principles you would consider a useful set of guidelines i would be glad to see that. |
|
All the rules which have no comment from me or I said (after some changes or explanations) something like "OK, makes sense for me" are the rules I agree with. |
|
The question is if you consider the set of guidelines minus the ones you don't agree with to be a useful and balanced set of design principles. Overall i am slightly astonished that no one seems to think i have missed any important design principles - which i likely have. By the way i also considered the suggestion from @pnorman to add references to external sources. I found this difficult in many cases because many ideas are either fairly specific to this style or specific to digital maps (like the zoom level considerations) for which there is still relatively few good literature around. But having a list of more in depth literature on map design in general would certainly be a good idea. |
|
I simply don't see the vision behind these rules, so I'm not in a position to judge the balance. I also don't believe that a strict set of important rules can be found in such a project, but I also don't see it's the most important problem for this project to improve. |
|
I explained, above and in #2270, my motivation and also that these are not rules to follow but are meant to document the principles that guide us in work here to help us understand each other's decisions and contributors to understand and learn what guides us when making choices. As said these are my suggestions for such guidelines but i welcome any alternative suggestions documenting what guides you and what you think should guide us, either as a modified version or a completely different proposal. For me having such a document is not really important but having common guiding principles is quite essential, without it development seems likely to become increasingly divergent with each maintainer developing and merging changes with respect to individual goals but without a common sense of direction design wise. |
|
I understand your point of view, but I'm not able to deal with this PR more than I already did. |
|
Closing this because the goal of achieving consensus among the maintainers does not appear attainable on this matter. I would like to keep #2270 open because it is unresolved and IMO still deserves addressing. I will also probably put this draft as it is somewhere for future reference as the guiding design principles for my work on this style. Maybe the other maintainers could also try to put down their design paradigms so even if we cannot agree on a common set of principles we might be able to document the diversity in viewpoints somehow. From my work on this stuff i can say that i do not only think this might help others to understand my views and decisions, it also helped myself to develop a clearer understanding why i - often intuitively of course - make certain decisions and have certain opinions. |
|
I had no time yet, but I planned to go over this again. I know this was open very long already, but maybe closing would not be necessary yet? |
Ok - here is the second part with more specific guidelines.
Not much to explain about it - right now this is essentially just a collection of ideas. There is a general part focusing on ideas how to decide if and how to render things and two more specific subsections on colors and zoom levels.