Add rendering for straits mapped as linear ways

[jeisenbe]

Partial fix for #3634 and related to #804
Follow up of #3438

Changes proposed in this pull request:

• Add rendering for natural=strait mapped as a linear way

Explanation:

• Nodes and polygons (closed ways / multipolygons) tagged with natural=strait area currently rendered, since Rendering of strait from z10 #3438. However, many straits are tagged as linear ways, and these are not yet rendered.
• The current PR renders the text label for the name of a strait as soon as the way is longer than 100 pixels. This is similar to the standard for rendering name labels at >3000 waypixels, but somewhat stricter.
• The name label is repeated after 800 pixels, so that there will usually be one label on the screen at zoom levels where the way is long relative to the screen size.
• A similar font style is used as with the name labels for straits, bays and lakes, with a larger font used at z14 and above.

Test rendering with links to the example places:

Bering Strait, between Alaska and Russia
https://www.openstreetmap.org/#map=9/65.7046/-169.0192
z7 before = after (unchanged because the way is less than 100 pixels long at this zoom level)

z8 before

z8 after

z9 before

z9 after

z10 before

z10 after

[jeisenbe]

North Inian Pass, Alaska - example with a ferry following the center of the strait. The text style and color is different, so there should not be confusion.

https://www.openstreetmap.org/#map=14/58.2839/-136.3820
z10 after

z12 after

z14 after - shows larger strait text labels at z14, and contrast with ferry text labels.

[jeisenbe]

Strait of Magellan
https://www.openstreetmap.org/#map=8/-52.916/-70.672

• Many of the straits near Tierra Del Fuego are mapped as linear ways.

z8 after - Strait of Magella and Cascada Channel

z9 after - Cascada Channel and other straits. (The "senos" could also be tagged as natural=bay, & bay=fjord)

z10 after - Strait of Magellan (northeast portion) - also labeled is a segment called "Second Narrows" (Angostura Segunda)

z12 after - First Narrows, Strait of Magellan

[imagico]

I would be against rendering straits in a way where the mapper can decide on if and how the strait is shown by changing the length of the way - same reason as with use of way_area with polygons. And as i like to say: The typical strait between two convex coasts is a one dimensional feature, it does not have a length, it only has a width.

I see three reasonable possibilities to render linear ways representing straits without taking the coastline into account:

• rendering a horizontal point label in the middle, i.e. rendering exactly like a node. This has the advantage of not communicating the mapper any preference regarding way vs. node from the side of the style.
• rendering a rotated point label in the middle of the way with the rotation being based on the direction of the way at this point.
• rendering a line label along the way similar to a river with the size and starting zoom level not depending on the way length. This would create problematic mapping incentives to place the line where the mapper wants to show the label. But it would still be a significant step forward from the current situation. And it would need to be tested to work for all kind of way lengths at different latitudes. The suggested label sizes at the different zoom levels will not work universally - like here:

https://www.openstreetmap.org/#map=14/-0.1787/130.2420
https://www.openstreetmap.org/#map=14/5.2108/120.2296
https://www.openstreetmap.org/#map=14/9.1439/-82.1666

[jeisenbe]

• rendering a horizontal point label in the middle, i.e. rendering exactly like a node. This has the advantage of not communicating the mapper any preference regarding way vs. node from the side of the style.

This is easy, but often the labels will be oriented quite wrong. For large straits it's no problem, but for narrow passages it could make the label seem out of place

• rendering a rotated point label in the middle of the way with the rotation being based on the direction of the way at this point.

This seems unnecessarily complicated, compared to the option below, and will not provide optimal results when the strait is narrow and curving.

• rendering a line label along the way similar to a river with the size and starting zoom level not depending on the way length.

Does this mean repeating the label after 800 pixels (at higher zoom levels) as shown above, or should it only be rendered once, no matter the zoom level?

It sounds like you want the initial zoom level to be limited to z14? Mapnik normally will not place a label along a linestring if the length of the linestring is less than the size of the label, but this will only prevent the label from showing if the line is too short at the minimum zoom level, so I imagine that this is acceptable. There are few straits short enough at z14 for this to present a problem.

it would need to be tested to work for all kind of way lengths at different latitudes. The suggested label sizes at the different zoom levels will not work universally - like here:
https://www.openstreetmap.org/#map=14/-0.1787/130.2420
https://www.openstreetmap.org/#map=14/5.2108/120.2296
https://www.openstreetmap.org/#map=14/9.1439/-82.1666

I don't see any nodes, ways or multipolygons in any of those three areas that are tagged with natural=strait or =bay? But I've added some fictitious labels for test rendering.

Are you saying that the 15 point label would be too wide for the narrow passages in these examples at z14? River labels are 12 points at z14 and below, so I could change it to this width.

z14 Raja Ampat Islands, West Papua - 10pt font for straits (polygons on left, way on right, node below)

z14 SW Phillipines very narrow - 12pt font

• 40 meters wide at the narrowest spot!
• I do wonder if this very narrow example could serve as a "strait"; perhaps there is a minimum width to be navigable by marine vessels that defines a named strait?

Same strait, labeled on center point without rotation. Poorer cartography:

[imagico]

Note i don't want to dominate this discussion - i think it is important for others to weigh in and communicate their opinion on this matter. It is a topic that goes somewhat beyond the particular change here because it is about how to best render features that can be and are validly mapped in different ways by mappers. For cases of different tagging we have a consensus position on this of the project (the 'non-proliferation' principle w.r.t. new synonyms for established tags) but for different geometric modelings we don't have anything comparable.

This is easy, but often the labels will be oriented quite wrong. For large straits it's no problem, but for narrow passages it could make the label seem out of place

Since the label is not oriented but plainly horizontal it is not wrong, it is just not indicating the orientation of the actual strait with the way it is drawn.

The aim here is not how to draw the best map with the least effort for the developer because then the answer is obviously to have the mapper draw the label. The question is how to formulate the rules to create constructive feedback to the mappers on their work in documenting the geographic reality.

No matter what design approach you use my aim would always be to try not rendering the same thing differently depending on how it is mapped without there being a constructive message communicated in this. If the reason for rendering things differently because rendering them identically based on either node, linear way or polygon is too difficult without sacrificing quality i would sacrifice quality before creating wrong incentives (which speaks strongly for the first option). Because our inability to equally label straits mapped with nodes, linear ways and polygons with an oriented label is just our technical inability and not due to necessary information being missing in the data. But as already said the other approaches seem reasonable ideas as well.

I talked about essentially the same problem using the example of waterway=dam/waterway=weir recently by the way at FOSSGIS - in German though so it is not that accessible for everyone:

https://media.ccc.de/v/fossgis2019-457-wenn-mapper-karten-malen

Does this mean repeating the label after 800 pixels (at higher zoom levels) as shown above, or should it only be rendered once, no matter the zoom level?

I don't see a particular problem in repeating labels.

It sounds like you want the initial zoom level to be limited to z14? Mapnik normally will not place a label along a linestring if the length of the linestring is less than the size of the label, but this will only prevent the label from showing if the line is too short at the minimum zoom level, so I imagine that this is acceptable. There are few straits short enough at z14 for this to present a problem.

If you don't want to make decisions based on way length and lack any other importance rating information you have to choose a relatively late starting zoom level. For bays this is z14 so it makes some sense to use approximately the same for straits.

That Mapnik does not show line labels beyond the extent of the linestring is a problem since (a) the way length comes in again as a deciding element for the starting zoom level and (b) showing/not showing a label will confusingly depend on the length of the name and both without the source geometry of the decision being actually visualized in the map.

You can of course go and use SQL code to extrapolate the way to the needed minimum length in both direction to deal with this problem but that would add a lot of complexity. This is mainly why i mentioned the second possibility of oriented point labels. You can also choose between these options based on way length but as you mentioned if you because you don't have a suitable importance rating use a rather late starting zoom level the problem is not really that significant practically.

[jeisenbe]

No matter what design approach you use my aim would always be to try not rendering the same thing differently depending on how it is mapped without there being a constructive message communicated in this.

Based on your suggestion, I went back and checked how nodes are rendered. It's quite different than polygons currently; they are only shown from z17 which is quite late (isolated dwellings, farms and "localities" are shown at z15), and the font size is always 10 pt. I'll plan to have the nodes and ways render in the same font size and style after this PR.

[Also I notice that bays are rendered in a different font when tagged on nodes; this needs to be fixed.]

I don't see a particular problem in repeating labels.

In that case, I will try having them repeat every 400 pixels, the same as rivers. This helps show the geometry of the way on higher zooms, and helps confirm that it is mapped correctly. It's analogous to the river labels in a large river or estuary.

If you don't want to make decisions based on way length and lack any other importance rating information you have to choose a relatively late starting zoom level. For bays this is z14 so it makes some sense to use approximately the same for straits.

Can I confirm that the database is not imported with a field like way_length? We only have way_area for polygons, right? It would be ideal if this existed, because then we could render the label with text-placement: line when the line is long enough, but use text-placement: point for short ways that would otherwise not be rendered at the minimum zoom level.

You can of course go and use SQL code to extrapolate the way to the needed minimum length in both direction to deal with this problem but that would add a lot of complexity. This is mainly why i mentioned the second possibility of oriented point labels.

I believe that orienting the direction of the labels based on a point text placement would also require too much complexity.

I've been researching the minimum zoom level that would be most appropriate for nodes and ways; see the next comment.

[jeisenbe]

I downloaded all of the nodes and ways that are tagged with natural=strait in Asia, Australia, Melanesia, the British Isles, Greece, and the area around Tierra Del Fuego. This was about 270 features; 110 ways and 160 nodes. I did not download relations because I assume most of these are larger, and my bandwidth is limited; also this PR is not addressing polygon rendering.

I found that the majority of the nodes and ways could be rendered at low or mid zoom levels <10, and 95% can be rendered at z13 without the label overlapping significantly with the land. There were a dozen that are questionable or clearly a problem. Of these, 2 appear to be ship channels or canals (in Japan and Macau), which may be mistagged due to linguistic differences; these look quite narrow until z16 or z17:

z15 Japan

z17 Macau

(There were several other closed ways in Macau that were also quite small straits, but these are polygons so I have not discussed them).

6 features are too narrow for even z15; these were all in Scotland and Japan, but it looks like there are others in Norway and Sweden, which I glanced at briefly. These are part of the "long tail" of smaller and smaller features, generally narrow passages between a small island and the mainland. All were tagged as nodes.

z15 Scotland

z15 Japan

Another 5 features were probably too small for z13 but acceptable for z14. Two examples, the only 2 mapped as a linear way:
z13 Phillipines

z13 Solomon Islands

Nodes in Japan (I consider the smallest to be questionable for z13, but the others are OK):
z13

(here's an example of nodes at z13 that I consider close but OK:)
z13

Based on this research, over 95% of straits can be rendered at z13 or below.
2% of straits would ideally begin to render at z14, and another 3% of straits are too small for even z15.
I also noted that the text labels of rivers begin at z13.

Therefore I will change this PR to set the initial zoom level to z13 for linear ways and nodes, with text size 10, increasing to 12 point at z14.

[jeisenbe]

Here are examples with the latest commit:

North Inian Pass, Alaska (no longer rendered at z10 to z12)
https://www.openstreetmap.org/#map=14/58.2839/-136.3820
z13

z14

Lilleboelt, Denmark - a long, curving strait
https://www.openstreetmap.org/#map=13/55.5200797/9.6739767
z13

Selat Bali, Indonesia - 2 straits mapped as nodes
https://www.openstreetmap.org/#map=14/-8.0928/114.4272
z13

Selat Lumut, Malaysia - (Hey, today you learned that "selat" means "strait" in Malaysian and Indonesian! They are both dialects of Bahasa Melayu)
https://www.openstreetmap.org/#map=13/2.912838/101.3197141
z14

Mboli Passage - (From above, listed as one of the straits that is a little too narrow at z13):
https://www.openstreetmap.org/#map=13/-9.1021544/160.2978732
z13

[imagico]

Can I confirm that the database is not imported with a field like way_length? We only have way_area for polygons, right?

Yes, for linestring length you have to use ST_Length(way). But keep in mind that a way can only have a maximum of 2000 nodes and most straits mapped with linear ways only have a few nodes. So this is not really that expensive. It could be advisable to exclude route relations (i.e. only allow osm_id > 0).

If you don't really need the exact length (which you don't because you don't know the exact size of the label in rendering anyway) you can also work with the bounding box size instead.

It would be ideal if this existed, because then we could render the label with text-placement: line when the line is long enough, but use text-placement: point for short ways that would otherwise not be rendered at the minimum zoom level.

Yes, you could do that - but you would need to make sure that even for very long names the label does not vanish when switching from point to line labeling as you zoom in because Mapnik does not fit it on the way.

I believe that orienting the direction of the labels based on a point text placement would also require too much complexity.

I am not sure if the complexity is actually larger than what you need for the above.

Regarding size and zoom level thresholds: Keep in mind that:

• the current set of straits mapped in OSM is obviously biased towards larger ones which are mapped with priority.
• the label not extending over the coastline is not a requirement - important but small straits can reasonable be labeled this way but it is of course not good to fill the map with labels for unimportant straits. So the criterion is not so much size but density.
• if you render straits too early this will incentivize against tagging small or unimportant straits as straits and encourage mappers to either invent a small strait tag or abusing waterway=stream.

[jeisenbe]

I believe that orienting the direction of the labels based on a point text placement would also require too much complexity.

I am not sure if the complexity is actually larger than what you need for the above.

OK, perhaps I guessed wrong about how it would be done, I haven't learned much about SQL yet. I was thinking that a longer linestring would have to be generated, e.g. as in your code for fords in alt-colors

But if there is a way to determine the approximate orientation of the way in the SQL, then we could create a column with this value, and use it with text-orientation and text-placement: point I think - but I don't know how to do this.

[jeisenbe]

• the current set of straits mapped in OSM is obviously biased towards larger ones which are mapped with priority.
• the label not extending over the coastline is not a requirement - important but small straits can reasonable be labeled this way but it is of course not good to fill the map with labels for unimportant straits. So the criterion is not so much size but density. [emphasis added]
• if you render straits too early this will incentivize against tagging small or unimportant straits as straits and encourage mappers to either invent a small strait tag or abusing waterway=stream.

I downloaded all of the straits mapped as ways and a selection of those mapped as nodes, to check the density of straits at different zoom levels. [I did not download relations, but these are only 1/3rd of the straits mapped, and I think they are larger ones on average]

A hard limit for "too dense" is if one strait name label blocks another from being rendered, due to being too close for both labels to fit. I believe this is the most important criteria for the zoom level being too early, because it can be misleading to mappers if too many of the features are not shown.

I also considered the subjective appearance of density, based on the number of straits shown on-screen at one time.

Most parts of Asia, Australia and Europe do not have straits close together. The 2 areas with the densest mapping of straits are in Macao (China) and the coast of Norway and Sweden. Chile has the largest number of straits mapped as linear ways, but none of these are too close at z13.

In Macao, most of the straits are mapped as closed ways, and a couple are too close for z13 or z14:
z13, z14, z15 (left to right):

z13, z14, z15 (left to right):

The second example in context. This is one of the denser areas, with 6 straits in this image (5 are shown, 1 is blocked by being too close)

This was the other place in Asia that had more than 4 straits in one screen; this is in southern Japan:

I was surprised by the high density of straits in Norway, but it appears that many of these were imported:
z15

z14

z13 - 22 of the straits (all mapped as nodes) are displayed; 6 are blocked by other labels. This appears to be the worst area globally.

Norway also had the one spot with too many straits mapped as linear ways close together. 11 are shown out of 13 (half are mapped as linear ways):

My conclusion is that z13 is appropriate for 95% of straits based on these density criteria. z14 would add a couple percent more, but perhaps 3% of straits would still be in overly dense areas. It's possible that the number over very densely mapped areas will increase over time, which could make these numbers worse. But Norway and Sweden may be exceptional due to their complicated coastline and unique cultural history.

Next, I checked how many straits are too short for the name label to render; This again shows that Norway is the main problem area. Test renderings show that the rendering is sometimes blocked for straits shorter than 1 km at the equator at z13 (<500m at 60 degrees). At z14 it's 500m at the equator and 250m at 60 degrees, approximately, depending on the length of the name.

There are 564 straits mapped as a linestring or linear way (an additional 60 straits are mapped as closed ways). Over half (293) are mapped in Chile alone; the second most common place in Norway, with 55, and Russia also has a large number (but not a high density).

Of the 564 straits, 42 appear to be too short: 7%.

However, 28 of these are in Norway: more than half the straits mapped as linear ways in Norway are less than 500 meters.

Outside of Norway, less than 3% (14 of 509) are too short to show at z13. Based on this, I think it's not necessary to write specific code to deal with the shorter ways, unless it is extremely simple.

This image shows a half-dozen out of the 55 straits mapped as linear ways in Norway:

• rendered with point placement

Compared to the current commit with line placement at z13. The straits show at z15; most are still too short at z14 in Norway.

All straits in Chile and the Falkland Island mapped as ways or nodes (from JOSM):

[imagico]

For rotated point labels you could do something like:

SELECT 
    ST_LineInterpolatePoint(way, 0.5) AS way,
    degrees(
      ST_Azimuth(
        ST_LineInterpolatePoint(way, GREATEST(0.0, 0.5-1.0/ST_Length(way))),
        ST_LineInterpolatePoint(way, LEAST(1.0, 0.5-1.0/ST_Length(way)))
      )
    ) AS angle,
    name
  FROM planet_osm_line
  WHERE "natural" = 'strait'

Or - since you'd probably use it for small scales where the length of the way is small relative to the size of the label you could also simply estimate the orientation from ST_StartPoint() and ST_EndPoint().

Practically it is a bit more complicated since you want to avoid upside down labels. There are other options like constructing a line geometry based on this orientation (ST_Rotate()/ST_Translate() are useful for that).

Anyway - as your tests also show - the real problem is importance rating and that is not reasonably possible without pre-processing. So it is of rather limited use to invest a lot of work in designing a sophisticated labeling logic that lacks this fundamental prerequisite.

At the moment i see two relatively simple approaches therefore (but would be open to other suggestions):

• render all straits no matter how they are mapped with a simple horizontal point label. This is the simplest approach with the least potential for bad mapping incentives. For linear ways ST_LineInterpolatePoint(way, 0.5) would be preferable to ST_PointOnSurface(way), in particular for two node ways.
• render linear ways with a line label - combined with a starting zoom level that makes sure most of the labels are shown at starting zoom level.

I think for the second approach the starting zoom level constraint is harder because it is less intuitive to the map user why a label might be missing.

[jeisenbe]

I gave it a try. First I used this suggestion from above:

ST_Azimuth(
        ST_LineInterpolatePoint(way, GREATEST(0.0, 0.5-1.0/ST_Length(way))),
        ST_LineInterpolatePoint(way, LEAST(1.0, 0.5-1.0/ST_Length(way)))
      )

But the angle column did not seem to work properly with text-placement: point; & text-orientation: [angle]. Then I tried replacing ST_LineInterpolatePoint with ST_StartPoint(way), ST_EndPoint(way) - this works, but half of the labels are in the wrong orientation.

This looks like too much trouble for a minor fix:

• render linear ways with a line label - combined with a starting zoom level that makes sure most of the labels are shown at starting zoom level.

I'm inclined to render linear ways with the line label, because a large majority of straits that are mapped this way will benefit from the rendering and this will also provide better mapper feedback about the database geometry of long, curving straits.

To finish checking the initial zoom level, I downloaded the rest of the nodes (about 1,200). Unfortunately I don't know of an easy way to find if 2 nodes of the same type are within a certain distance with Overpass or JOSM, so I manually searched for areas that appeared to have a high density of nodes. Only 5 spots in southern Norway had more than one strait that would not render on z13 due to being blocked by a close-by strait. There was one strait in Sweden, one in Finland, and a couple in Macao. So I believe z13 is a reasonable initial zoom level.

Finland, z13 - close, but not interfering

I'll keep the PR unchanged for now, with z13 the initial zoom level, and linear ways rendered every 400 pixels along the line.

Once we have preprocessed data this could be reconsidered, but I imagine that the results of the script will be nodes with a zoom level / label size field and a field to position the label? I suspect a linear geometry would not be generated for long, narrow straits. If that is correct, then this rendering from the linear ways will be superior cartographically.

[imagico]

Sorry - mistyped, that should have been:

ST_Azimuth(
        ST_LineInterpolatePoint(way, GREATEST(0.0, 0.5-1.0/ST_Length(way))),
        ST_LineInterpolatePoint(way, LEAST(1.0, 0.5+1.0/ST_Length(way)))
      )

I have never used text-orientation so i am not really sure what is happening here but as said you'd need some additional logic to avoid upside down labels.

Regarding starting zoom level - you should keep in mind that z13 in southern Norway is the same scale as as z14 at the equator. And as said starting too early would incentivize against mapping straits as straits.

Regarding your concrete changes - what you changed in the labeling logic for the polygons does not make much sense to me. As written in other context before - i think if you want to change the polygon labeling you should remove use of way_area.

Once we have preprocessed data this could be reconsidered, but I imagine that the results of the script will be nodes with a zoom level / label size field and a field to position the label? I suspect a linear geometry would not be generated for long, narrow straits. If that is correct, then this rendering from the linear ways will be superior cartographically.

That depends on how much effort you put into this. Generating a directed labeling geometry from either linear ways or nodes is perfectly doable but of course more complicated than a simple distance to shore based importance rating.

[jeisenbe]

Ok, now it works with ST_LineInterpolatePoint (which is in theory better for ways that are somewhat curved), but some of the labels are still reversed.

The results of angle for a north-south line is 0 or 180 now, but it should be 90 or -90. An east-
west line is 90 or -90, but should be 0 (180 or -180 would both be flipped upside down). A northwest to southeast line is about -45 degrees, and a southeast to northeast line is +135, but both should be +45.

The values of the angles are also not exactly as expected, probably because we are rendering in mercator and the azimuth calculation is based the geometry on the surface of globe.

It appears we would need to:

1. Convert to "mercator degrees of rotation" instead of actual rotation on the globe to get the orientation right (add something like ::geometry ?).
2. Reorient by +/-90 degrees, because ST_Azimuth() is zero degrees for a north-south line, while text-orientation is 0 for an east-west label orientation.
3. Add a function that would limit the value of angle to > -90 and < 90 degrees, so that the text labels would not be flipped upside down.

Uncorrected result:

Sounds like too much trouble for only linear ways, but it would be nice to solve for nodes once we have preprocessed data, so I've recorded these thoughts for posterity, in case it is possible.

[jeisenbe]

Regarding starting zoom level - you should keep in mind that z13 in southern Norway is the same scale as as z14 at the equator. And as said starting too early would incentivize against mapping straits as straits.

The problems in Norway seem related to the extensive areas of fjords and small islands created by glaciation, which is not as prevalent near the equator. I'm also concerned that showing straits only on high zoom levels will discourage mappers from adding larger straits, because the labels will be hard to see. However, I will change the initial level to z14.

Regarding your concrete changes - what you changed in the labeling logic for the polygons does not make much sense to me. As written in other context before - i think if you want to change the polygon labeling you should remove use of way_area.

I did not intentionally do this for polygons, but I see now that adding [zoom >= 13][feature = 'natural_strait'], would also show all polygons at this zoom level. I've changed this to affect nodes only and changed to z14, so that removing way_area filtering can be discussed in a separate PR.

[imagico]

Regarding label rotation - all operations are done in projected coordinates, you don't have to consider that. Point 2 and 3 look right.

The point of this as mentioned would be to allow labeling straits mapped with a linear way with a directed label at scales where the way itself is not long enough to place a line label. This is a relatively small window (usually probably just one zoom level).

I'm also concerned that showing straits only on high zoom levels will discourage mappers from adding larger straits, because the labels will be hard to see.

Right now - without changing the way_area logic for polygons - this style loudly screams at mappers to map any strait or bay with a polygon with the size representing cartographic importance. As long as this is the case smaller subtleties in starting zoom level will not have much influence on mapping with nodes and linear ways. But apart from that - we have for many years rendered bays starting at z14 and this did not have a negative effect in that direction apparently. Most of the large bay polygon drawings added recently were replacing node based mapping and were not newly mapping things not previously mapped.

But if you truly think z13 is safe even in densely mapped areas near the equator i would be fine with that. You have looked at this more in depth than i have.

[jeisenbe]

It's okay to set the initial zoom level to z14 for now. Once we have a way to calculate an importance / size for nodes, then we can reconsider the initial zoom level for linear ways as well.

[jeisenbe]

I believe this PR is ready for review / merging

[imagico]

Works fine.

One problem i noticed but that is not specific to straits and therefore does not need to be fixed here is that when a node is double tagged natural=strait + place=locality (which is fairly common) it starts at z14 with the strait styling but switches to the place=locality styling at z15 since the placenames layer has priority over the amenity-points layer. I think labeling of place=locality should be moved to amenity-points and - like the rest there - needs to be prioritized according to starting zoom level.