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

[BUG] Respect the order of conditions in a match expression array #1091

Closed
zstadler opened this issue Nov 7, 2024 · 1 comment · Fixed by #1101
Closed

[BUG] Respect the order of conditions in a match expression array #1091

zstadler opened this issue Nov 7, 2024 · 1 comment · Fixed by #1101
Labels
bug Something isn't working

Comments

@zstadler
Copy link
Contributor

zstadler commented Nov 7, 2024

Describe the bug
When using the array form of a match expression, the order of elements in the array is sometimes ignored.

Consider a schema defining a color attribute taking different OSM tags in descending order of priority. An over-simplification of the expression could be:

    - key: color
      value:
      - if:
          natural: tree
        value: green
      - if:
          historic: memorial
        value: black
      - if:
          tourism: viewpoint
        value: green

An OSM element, that has both a historic=memorial and a tourism=viewpoint tag, is assigned a color=green attribute rather than color=black.

To Reproduce

  1. Use the following my_pois.yml definition
schema_name: My POIs
schema_description: My Points of Interest (not openmaptiles)
attribution: <a href="https://www.openstreetmap.org/copyright" target="_blank">&copy;
  OpenStreetMap contributors</a>
args:
  area:
    description: Geofabrik area to download
    default: israel-and-palestine
  osm_url:
    description: OSM URL to download
    default: '${ args.area == "planet" ? "aws:latest" : ("geofabrik:" + args.area) }'
sources:
  osm:
    type: osm
    url: '${ args.osm_url }'
layers:
- id: my_pois
  features:

  - source: osm
    geometry: point

    include_when:
      natural: tree
      historic: memorial
      tourism: viewpoint

    attributes:
    - key: historic
    - key: tourism

    - key: color
      value:
      - if:
          natural: tree
        value: green
      - if:
          historic: memorial
        value: black
      - if:
          tourism: viewpoint
        value: green
  1. Generate my_pois.pmtiles
docker run --rm -v .:/data ghcr.io/onthegomap/planetiler generate-custom --download --force --output=/data/my_pois.pmtiles --schema=/data/my_pois.yml
  1. Serve the tiles
docker run --rm --detach --name my-pois-tileserver -v .:/data -p 8080:8080 maptiler/tileserver-gl --verbose --file /data/my_pois.pmtiles
  1. Node 2156431602 has both a historic=memorial and a tourism=viewpoint tags. Examine its tile and see that it was assigned color: green rather than color: black

Expected behavior
I expect the "if" conditions to be evaluated in the order they appear in the array.

I believe this is natural expectation after reading the documentation for the match expression

  • For the first format:

    the expression evaluate to the value associated with the first matching boolean expression at runtime:

  • For the second format:

    you can use an array of objects with if and value keys and a last object with an else key

Regardless of my interpretation of the documentation, I believe this evaluation order would provide a valuable expressibility enhancements for priority-based value expressions.

Screenshots
image

Environment:

  • Hardware: Any
  • OS: Docker
  • Java version and distribution: Planetiler latest docker image
  • Maven version: Planetiler latest docker image

Additional context
It seems like the implementation is unifying all conditions with the same resulting value and thus converting the above into

    - key: color
      value:
      - if:
          natural: tree
          tourism: viewpoint
        value: green
      - if:
          historic: memorial
        value: black

As far as I could see, the order is preserved between different value expressions, i.e. green has higher priority that black.

@zstadler zstadler added the bug Something isn't working label Nov 7, 2024
@msbarry
Copy link
Contributor

msbarry commented Nov 14, 2024

Good catch, I put out a fix in #1101, the description there explains what was going on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants