Labels of areas and POIs conflict with oneway arrows

[AllroadsNL]

name=Autódromo Santiago "Yaco" Guarnieri
on a polygon, leisure=sports_centre , sport=motor

Layer 15 it is
but not on
Layer 16
then on
Layer 17 it is back

[pnorman]

z17

Looks like a collision between the icons and text happens on z16.

[kocio-pl]

I would like the parking icon ("P") to have lower priority than names in general. Is it possible?

[meased]

I would like the parking icon ("P") to have lower priority than names in general.

👍

Usually when I add parking lots to an area the rendering gets worse.

[pnorman]

I would like the parking icon ("P") to have lower priority than names in general. Is it possible?

Yes. My guess on how to best implement it would to be move parking to the low priority amenity points layer.

[AllroadsNL]

Although both should be visible at the layers. Name above the P icon.

[kocio-pl]

Unfortunately I'm not too familiar with layers.

Parking is already included in amenity-low-priority-poly, but probably this layer should be moved earlier (as it was with #2394)?

[kocio-pl]

I've made map.osm export from this area and was trying to change tags in text editor to see the difference. It looks like both oneway arrows and parkings are blocking the name from rendering on z16 - changing both tags allows it to be seen.

I was also trying to remove just the arrows from the data and play with parking layers - but even placing "amenity-points-poly" and "amenity-points" as the first layers was not working. Only removing these layers allows the name to be rendered.

Maybe someone more experienced with layers could help?

[pnorman]

Maybe someone more experienced with layers could help?

Good time to learn ;)

When it comes to placements with collisions, each layer is rendered in the order specified, and collisions bounding boxes are generated. Most symbols won't place where there is an existing symbol. You can see the order of the layers in the Layer array in project.mml, or extract the names with this bit of Python

import yaml
for l in yaml.safe_load(open("project.mml"))["Layer"]:
  print(l["name"])

Because amenity=parking is already in the last two layers, moving it won't change anything.

The oneway arrows are probably colliding with the name. I'm not sure what the best solution here is.

cf. #2320 #1840 #1968

[kocio-pl]

Good time to learn ;)

Thanks for your comments and a code snippet!

I think the most useful tool for learning this would be text editor with support for collapsing and moving the whole layers. Looks like Atom can do that, however I don't know yet if I could collapse all for a start and if moving is supported more easily than just copy/paste.

Because amenity=parking is already in the last two layers, moving it won't change anything.

I did my homework. 😄 I haven't mentioned it, but moving these last two layers ("amenity-low-priority" and "amenity-low-priority-poly") to the top along with "amenity-points-poly" and "amenity-points" did not help, so there's something I still don't understand.

[pnorman]

I think the most useful tool for learning this would be text editor with support for collapsing and moving the whole layers. Looks like Atom can do that, however I don't know yet if I could collapse all for a start and if moving is supported more easily than just copy/paste.

Any decent text editor should have folding capabilities, but you might have to manually tell it the file is YAML

As an example

If I position my cursor at the start of the array element with id: waterway_name and press shift-down arrow it will select the entire element, I cut it, and I can then put my cursor at the start of the element with id: building, and paste it in before that layer.

Back to this problem, I can see a few ways to fix this

1. Make oneway arrows non-colliding
2. Move road names + oneway arrows later
3. Move oneway arrows out of the road name layer and put them into their own layer, positioned later.
4. Radically change the oneway styling

I don't think 2 will work since we might end up with no road names in POI-dense areas.

1 would be easy. 3 makes our roads code bigger :( 4 requires ideas.

I'm concerned about the size of our roads code, and really wouldn't like to see it grow any larger. I'd be inclined towards 1, which is how it used to be.

[kocio-pl]

There's a problem that folding happens at "-", so with two layers (- name: "roads-casing" and - name: "admin-low-zoom") it tries to fold from name, leaving id in the previous layer. This would of course not hurt this case, since we don't need to touch these layers, but could we fix it without causing other problems?

I was thinking about simply dragging folded elements as the most convenient way, but I can live without it. Also folding all elements at the start would be great and maybe fold-functions plugin can do it, but I've just found that Atom remembers folding state of the code, so it's also not a big deal for me now.

[pnorman]

Folding still works fine on those layers, folding the entire array element into one line.

The following YAML is the same, just with a different text representation

  - name: "roads-casing"
    id: "roads-casing"
    geometry: "linestring"

  - id: "roads-casing"
    name: "roads-casing"
    geometry: "linestring"

  - 
    id: "roads-casing"
    name: "roads-casing"
    geometry: "linestring"

- {geometry: linestring, id: roads-casing, name: roads-casing}

I'm not aware of any editors which allow re-ordering of a YAML array by drag-and-drop, mainly because I don't know of any YAML editors, just text editors. I am aware of JSON and XML editors, but normally gets used in situations where you don't need an editor for it and can edit the raw text.

[kocio-pl]

Thanks. Just double checking: so I guess I can make a patch moving both "-" (dashes) from name: to corresponding id:, like it's done in the rest of layers? Currently we have:

    id: "roads-casing"
  - name: "roads-casing"
    geometry: "linestring"

which is of course not the same as any of your proper examples, like:

  - name: "roads-casing"
    id: "roads-casing"
    geometry: "linestring"

and that's why folding is broken at the moment.

[pnorman]

Currently we have:

No we don't.

The meaning of the two is completely different. - starts an array element, so in the first you pasted the array element with name: roads-casing does not have id: roads-casing

[kocio-pl]

No we don't.

I had it in my code and I don't know how did it happen, but that's not important now - you're right. Still a cosmetic patch making things uniform would make me happy.

[kocio-pl]

I'm concerned about the size of our roads code, and really wouldn't like to see it grow any larger. I'd be inclined towards 1, which is how it used to be.

Why was it changed? I can't find the right PR. I though we rather made arrows less visible than names?

I have no favorite solution, but any would be welcome. No 1 reason I see is that universal style is rather to show names than help routing - they are useful hint, so I have nothing against showing them, but we have specialized software for routing.

[pnorman]

Why was it changed?

We changed to arrows made from dashed lines to SVGs. #1840

[kocio-pl]

I haven't notice that it was also layers change. Making it a low priority layer again would be good enough for me.

[pnorman]

I consider showing arrows important.

Making it a low priority layer again

It wasn't a low priority layer before. When it was dashes, it didn't conflict with any other placements.

[dieterdreist]

sent from a phone

On 14 Dec 2016, at 17:44, Paul Norman ***@***.***> wrote: It wasn't a low priority layer before. When it was dashes, it didn't conflict with any other placements.

is there a technical or cartographic reason we don't want to allow overlap of later rendered stuff with them?

[matthijsmelissen]

There is no technical reason.

[kocio-pl]

Looks like a duplicate of #964.

[pnorman]

Looks like a duplicate of #964.

This is specific to oneway arrows, which are not POI labels and can have a different solution.

[jeisenbe]

Anyone still interested in trying "1. Make oneway arrows non-colliding" again?

[imagico]

#4192 showed this is also a problem with point symbol labels.