Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Area name conflicts with oneway arrows #2429

Open
AllroadsNL opened this issue Nov 8, 2016 · 23 comments

Comments

Projects
None yet
6 participants
@AllroadsNL
Copy link

commented Nov 8, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 8, 2016

z17
image

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

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 8, 2016

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

@meased

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 9, 2016

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

This comment has been minimized.

Copy link
Author

commented Nov 9, 2016

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

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Nov 9, 2016

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 kocio-pl added this to the Bugs and improvements milestone Nov 15, 2016

@kocio-pl kocio-pl self-assigned this Nov 15, 2016

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Dec 11, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 11, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 11, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

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

image

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

Currently we have:

No we don't.

image

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2016

Why was it changed?

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

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2016

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

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2016

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

This comment has been minimized.

Copy link

commented Dec 14, 2016

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2016

There is no technical reason.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Dec 15, 2016

Looks like a duplicate of #964.

@pnorman pnorman changed the title Name, rendering not on layer 16 Area name conflicts with oneway arrows Dec 15, 2016

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Dec 15, 2016

Looks like a duplicate of #964.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.