-
Notifications
You must be signed in to change notification settings - Fork 819
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
Symbol and label prioritization is not in sync with the starting zoom levels #3880
Comments
I agree that at high zoom levels, icons that appear at z17 should not disappear at z18 or z19 because another feature begins to render at the higher zoom levels. For very large features, it sometimes makes sense for the text label to disappear when the feature begins to take up most of the screen. This was implemented for One issue currently is with |
The big question is how the MSS code should look like. Example: #amenity-points[zoom >= 10][int_startzoom <= 10],
#amenity-points[zoom >= 11][int_startzoom <= 11],
#amenity-points[zoom >= 12][int_startzoom <= 12],
#amenity-points[zoom >= 13][int_startzoom <= 13],
#amenity-points[zoom >= 14][int_startzoom <= 14],
#amenity-points[zoom >= 15][int_startzoom <= 15],
#amenity-points[zoom >= 16][int_startzoom <= 16],
#amenity-points[zoom >= 17][int_startzoom <= 17],
#amenity-points[zoom >= 18][int_startzoom <= 18],
#amenity-points[zoom >= 19][int_startzoom <= 19],
#amenity-points[zoom >= 20] {
// Here comes all the existing icon/label code
} This would work. But it would increase the size of the Carto-generated XML file from 3 MB to about 6 MB for the hole style (just a quick test, not an exact measurement). Mainly because zoom filters are different from “normal” data filters like here “int_startzoom”. For each zoom level CartoCSS has to generate an own set of XML rules. So you get many duplicate rules that will never be used (for example for shops on z10, z11, z12, z13, z14, z15, z16) because at these levels shops do not render. It would be obviously better if we could use the current zoom level to compare against the SQL-generated int_startzoom, but I'm not sure render-time variables like |
My idea was actually not to have any zoom level based selection in MSS code but to select per zoom level in SQL using the |
Okay, got it. But wouldn't this be a problem with vector tiles? If I understand correctly vector tiles will be produced only up to z14 (or z15?) and everything above is rendered from z14 tiles. (I havno experience with vector tiles.) |
@imagico - do you have an example of how this would work? It doesn't seem to have been implemented in https://github.com/imagico/osm-carto-alternative-colors yet? |
@sommerluk - i don't see a fundamental problem here - as @jeisenbe illustrated you could have a kind of There are different ways to implement this - you can either write this directly in SQL in project.mml or you could have a yaml file with the different POI types and their starting zoom levels and either auto-generate an SQL function from that which matches these with a large CASE statement (similar to https://github.com/imagico/osm-carto-alternative-colors/blob/master/line-widths-generated.sql) or generate a separate postgres table with these once similar to |
See #3635 which is related to this issue. |
I'm trying to figure out how to implement this:
I think it would be best to start with SQL in project.mml directly, since it will be clearer how things work and we can make changes. Is there an example of this somewhere? Perhaps we could start by testing with |
You would do something like
|
How do I add z() to PostGIS? "In addition you need to install the I've added z.sql to my repository but get the error:
|
You need to run z.sql in postgis on the osm database to install the function. |
Explain it to me step-by-step, please: the “For Dummies” version.
I am using the docker container set-up.
|
@jeisenbe I believe it's a case of using the 'psql' command in a terminal window to run the statement contained in z.sql on the Postgres installation itself. Something like:
|
Also related to #1026 and #964. The |
Symbols vanishing as you zoom in can be a deliberate and useful choice but never the vanishing and reappearance later - which is a common effect with the non-consistent prioritization. Also typically you would - even if you choose to have a symbol vanish - continue rendering the feature in question in a different form - using something other than a symbol - maybe a label only - or a geometry using a drawing signature classifying it as what it is. Anyway - this issue is about the prioritization being non-consistent and arbitrary. To deliberately have symbols vanish under certain conditions would likewise depend on first having a consistent prioritization to then deliberately adjust it as such. |
To clarify - because that seems to be occasionally misunderstood: This issue is of high importance to fix, and it should be done in a way that scales well in light of the 250+ different symbols we render. Manually syncing the starting zoom levels defined in MSS with an equally hand written prioritization logic in SQL is not a viable way to do that IMO (see #4836). That does not mean we need to wait with fixing any of the concrete prioritization problems we have until this is addressed. We have other related issues like #4631 and #4676 that can be fixed independently of this (though there would of course be a benefit of addressing them together) and introducing an ability to explicitly define order of prioritization for specific feature types would be possible as well in that context. My impression is that solving this issue is right now hampered by two things:
What i can offer in that regard is that i look at any proposal how to address this and assess the suitability and if i would be in support of such an approach here. See also #4901. |
I've been experimenting with an approach summarised in this gist. It started as an experiment to see whether I'm only testing this on a personal style, hence the rendering of As already stated, overhauling all of |
I am not quite sure if i understand where your sketch is meant to go. You seem to re-frame the feature column into a coarser classification, which requires you to have two big CASE statements in the SQL code in mml - containing the translation from tag to You have some styling data (starting zoom levels, SVG file names) in SQL code while other styling data (text parameters, but also way_pixels thresholds - which change the starting zoom levels) in MSS. Given the complexity of the layer you need to take care of avoiding combinatorial explosion in the CartoCSS to Mapnik translation. This is why we work with a feature column and not with key and value. Andy has explained this in detail in his early OSM-Carto talks (like https://www.youtube.com/watch?v=RgSye4IbnD8). In principle the idea of creating database tables and filling them with styling data that is necessary on the SQL level (for priority ordering) is a viable approach. But i would not recommend trying to design these tables in a way that designers are meant to directly edit SQL code for filling these tables. That is fairly awkward in terms of style writing ergonomics and it requires you to compromise between optimizing for human editing and optimizing for efficiency in use. The more recommendable approach is to have a script fill the table from styling data provided in a YAML file. The other big principal question you would need to decide is if you want to have the MSS code for the amenity-points layer manually maintained or script generated as well. There are pros and cons for both. But as you say - amenity-points.mss is a rather big and messy file (with various errors i might add - so yes, a major rewrite will realistically involve differences in styling logic in some cases) so whatever approach we would take here would need to be evaluated for scalability and maintainability. More generally speaking: IMO a solution for this should be in particular designed with the usability for the map designer in mind. All of this is just my personal perspective on this though - other maintainers might have a different view on this. In light of this my recommendation would be not to invest too much work in writing production code at this stage but work on an overall concept and see if that can find consensus support from the maintainers.
Technically a new major version is needed only with a change of database schema or the software versions required. But this is not really a question we need to look at at this stage. |
Not quite. The big primary CASE which selects the features for rendering is retained (with a bit of rationalisation in order to group related items together). The second CASE is limited to pulling out the relevant primary key:
and so should be quite limited. It would be great to get rid of this, but I haven't seen a way to retain both feature and value as keys and feature_value as a combined key from the "primary CASE".
All the starting zoom information is in the Postgres table(s), which it is necessary for the correct prioritisation. The SVG pass through doesn't need to be included, but it seems a nice way to simplify the MSS and mapnik XML if you're going to the trouble of creating a POI table. It seems you don't need a separate filter for every symbol, which would remove a lot of repetition from amenity-points.mss! That aspect could be removed, but (without changing the current logic) you need to be able to set a zoom level for some key_value combinations, e.g. Introducing a POI database is always going to split where information is placed. I guess this is why there are different opinions?
I've looked into this, and the number of mapnik rules is not increased; you still still have one rule for a given styling:
i.e.
Agreed. This is just testing ideas. It would be perfect sense to generate the Postgres tables in a similar way to
I think creating a POI database and simplifying / rationalising the MSS would be a first step. It would be easier to judge the usefulness of auto-generating amenity-points.mss once it was reduced in size. Frankly it's too much of a mess as things stand to understand which option would work best.
Absolutely. The current model is only suitable for the "map tinkerer" adding the odd POI. It's very hard to design when it's so difficult to get an overview. Realistically some kind of POI database is needed to bring some order.
Indeed. This is "production code" in the sense that I'm using it on an experimental branch, but it was posted as a gist for comment / sharing rather than rushing to a PR on the parent project.
I suspect that as a PR on the master branch, there would be extreme nervousness about a wholesale rewrite of amenity points. A bleeding edge branch with maintenance on 5.8.X until folks were happy with the direction of travel might provide a smoother route. |
No, according to your sketch it is not - as i have already indicated. With the polygon size dependent labeling of landcover and water polygons the starting zoom level depends on the size - large lakes get labeled earlier than small ones. And there are other POI types where the starting zoom level depends on secondary tags. You could flatten those out into different feature types - but then you quite definitely would need to script generate the code for that because of the large number of feature types this generates. For determining the starting zoom levels based on way_pixels thresholds you'd need something like
To be clear: The current structure of amenity-points rendering is fairly designer friendly in principle (in terms of the complexity of the work needed to make changes). The main problems are that
The route i see forward here is the following
The decision on if to maintain a separate long term branch would be decided in the second step. Since this would be a fairly well compartmentalized project affecting only two layers of the style i see less need for that than for other bigger changes in the past. I would not worry too much about the bulk work of converting the logic of |
As far as I could tell, the starting zoom usually just depends on a single
From a quick scan,
you could again set the start_zoom to 15, and sort out the rest in MSS:
Different castle types wouldn't be quite prioritised correctly against other Z16 POIs, but I doubt that anybody would notice! So you don't need to reproduce all of the zoom logic in SQL, although it might ultimately be desirable not to have zoom logic in multiple places. |
For the landcover and water polygon labels that is correct.
Well - this issue calls for prioritizing by actual starting zoom level, not by some other manually defined importance scoring. I also don't see how introducing an additional, less distinctly defined scoring would make things any easier. |
So as far as I can tell, the only parameters determining starting zoom level are area in the form of I can see a way to do this more neatly. I'll test out a version 2. P.S. It was interesting to see from Andy Allan's presentation what OSMCarto looked like in the early days. It's certainly looking a lot better! |
Version 2 here. This is much cleaner. The first version tried to group things to reduce the number of database rows. But this is not relevant given that the plan would be to generate the POI database table via a YAML config file. This version also demonstrates how zoom levels affected by secondary tags could be handled, as well as handling (or not) of catch alls. |
As mentioned before i don't really see the reasoning behind the complex data structures you generate. All that is needed to solve this issue is:
The difficulty with that is not the need to develop come complex data structures and algorithms, it is to design this in a designer-friendly way that scales well with style complexity. If you want to go beyond that (like by script generating/parameterizing MSS code) that is fine. But do not underestimate the challenges involved in that. Independent of that - your sketch so far still fails to actually determine the starting zoom level for features where this depends on way_area. For you the starting zoom level for natural=wood labels for example is either z8 or z17 (and is not constant but varies with the zoom level). That is not correct. I already mentioned the formula you would need to use here. |
The starting zoom level function for selection works as present:
i.e. the feature will be selected and shown once the I agree that it would be more elegant to also get rid of But given the amount of cold water dropped on these efforts so far, I'm not motivated to continue to work on this problem. |
There might have been a misunderstanding here due to my formulation of this issue. When i am talking about the starting zoom level that refers to the first zoom level at which a symbol/label actually occurs.
The reason why i provided critical comments early on regarding your ideas was to avoid you investing a lot of work into something only to later run into issues that cannot be solved using the approach taken. That is also the reason for the procedure suggested above in #3880 (comment). But again: This is only based on my perspective on this matters (which is based on my own work on this problem mentioned in #3880 (comment) - and therefore certainly somewhat limited). Other maintainers might well have a different view of this and might be able to guide you in a way you find more motivating. And i am perfectly fine if that leads to solving this issue or otherwise improving the symbol/label prioritization in a way that is different from what i have in mind here. |
Yes, certainly other input is needed on direction here. Personally I think the only scalable and maintainable solutions involve "intermediate" tables, such as a table of POI starting priorities. From the map designer view, the detailed implementation shouldn't matter (and can be iterated) as it would sit behind say a YAML configuration interface. |
Currently the drawing order of point symbols and labels (layers amenity-points and text-point) but also of other text layers is not in sync with the starting zoom levels as defined by the MSS code in amenity-points.mss. This leads to in some cases symbols and labels disappearing as you zoom because other symbols and labels appear at a later zoom level but with higher priority.
This is related to #234.
The superficial solution would be to manually work through these layers and adjust the drawing order to match the order of starting zoom levels. This is however very maintenance intensive. The alternative would be to define the starting zoom levels in SQL and use that for starting zoom level selection rather than MSS logic.
This would also have the advantage it could easily be adapted to dynamic starting zoom levels based on continuous importance rating and local map scale/latitude.
Neither of these solutions would of course affect the same problem when to comes due to labels and symbols from different layers competing with each other.
Examples:
https://www.openstreetmap.org/node/59646817#map=16/47.9973/7.8364
https://www.openstreetmap.org/node/59646817#map=17/47.99652/7.83686
https://www.openstreetmap.org/node/3913744216#map=18/47.99380/7.85089
https://www.openstreetmap.org/node/3913744216#map=19/47.99384/7.85109
The text was updated successfully, but these errors were encountered: