Skip to content
This repository has been archived by the owner on Jan 12, 2024. It is now read-only.

ordering of attachments across mss files #239

Closed
ajashton opened this issue Jan 18, 2013 · 6 comments
Closed

ordering of attachments across mss files #239

ajashton opened this issue Jan 18, 2013 · 6 comments
Labels
Milestone

Comments

@ajashton
Copy link
Member

Update: my initial claim that this is a regression seems to be incorrect.

With 2 mss files, attachments defined in the first file will render on top of attachments defined in the second file. The proper behavior should be the opposite, since we say "Symbolizers are rendered in the order they are defined".

Test case

springmeyer pushed a commit that referenced this issue Jan 24, 2013
@springmeyer
Copy link

  1. I added your test case to master (currently failing as intended by manually switching the expected style attachment order)
  2. In looking at past commits this one looks the most likely to impact style order: f6c07af#L3L62
  3. However, using the carto command line tool I am unable to replicate different behavior in jumping back to old tags, as old as v0.6.0 has the same behavior as master (so this failing test fails for older versions for me too)

@springmeyer
Copy link

It seems like to support the file order being relevant the sortStyles function would need to be modified to work differently and the original order, by file, would need to be passed in somehow.

@ajashton - seems like we may also need a non-attachment testcase added for preventing regressions in style overrides between files.

springmeyer pushed a commit that referenced this issue Mar 1, 2013
@springmeyer
Copy link

downstream report with pirate map that seems to point to this actually having regressed(even though we thought differently above): http://support.mapbox.com/discussions/tilemill/6565-labels-are-behind-features-in-tilemill

@springmeyer
Copy link

one possible hunch - the regression in #247 was preventing this from looking like it regressed.

@springmeyer springmeyer mentioned this issue Jun 3, 2013
@springmeyer
Copy link

incorrect hunch. we have a testcase for this regression and it has not regressed in master since the latest changes around #247. Closing.

@springmeyer
Copy link

was unable to replicate any ordering problems with the pirate map(https://github.com/ajashton/pirate-map) which seems stable across carto versions.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants