filter - exclude_tags improvements

[ImreSamu]

I have created a simple exclude_tags improvements , I don't know it is acceptable or not ...

• [x] fix: closure problems on loop iterator variables - with multiple exclude_tags - only the last element used
• [x] implement [ <<key>> , "__nil__" ] Exclude filter
• [x] generating customised exclude filter functions

The proposed syntax:

    filters:
      exclude_tags:
      - [ "area"     , "yes"      ]
      - [ "area"     , "no"       ]
      - [ <<key1>>   , <<value1>> ]
      - [ <<key2>>   , <<value2>> ]
      - [ <<key3>>   , <<value3>> ]
      - [ <<key4>>   , "__any__"  ]
      - [ <<key5>>   , "__nil__"  ]
          - ...

Examples

  admin_polygons:
    fields:
    - name: id
      type: id
    - name: geometry
      type: geometry
    - key: name
      name: name
      type: string
    - key: 'name:en'
      name: name_en
      type: string            
    - key: admin_level
      name: admin_level
      type: integer
    - name: area
      type: area
    filters:
      exclude_tags:
      - [ "admin_level", "__nil__" ]
      - [ "admin_level", "3" ]
      - [ "admin_level", "5" ]
      - [ "admin_level", "6" ]
      - [ "admin_level", "7" ]
      - [ "admin_level", "8" ]
      - [ "admin_level", "9" ]
      - [ "admin_level", "10" ]
      - [ "admin_level", "11" ]
      - [ "admin_level", "12" ] 
      - [ "admin_level", "13" ]                             
    mapping:
      boundary:
      - administrative
    type: polygon

  buildings:
    fields:
    - name: osm_id
      type: id
    - name: geometry
      type: geometry
    - key: name
      name: name
      type: string
    - name: type
      type: mapping_value
    filters:
      exclude_tags:
      - [ "building", "yes" ]
      - [ "building", "hangar" ]
      - [ "building", "roof" ]     
      - [ "amenity", "__any__" ]  
      - [ "name", "__nil__" ]  
    mapping:
      building:
      - __any__
    type: polygon

[olt]

exclude_tags was a quick hack. How about adding reject and require which take mapping like arguments. This would make it more clear.

For example:

  filters:
    require:
      admin_level: ["1", "2", "4"]

And:

  filters:
    require:
      name: [__any__]
    reject:
      amenity: [__any__]
      building: [roof, hangar, yes]

[ImreSamu]

How about adding reject and require which take mapping like arguments. This would make it more clear.

perfect :)

But later it is possible to extend with a

• regexp
• and a lua filter ?

How about this extended spec ?

filters:                                        
 reject:                                        // ===========================================
 - [ key, val]                                  // AND key != val
 - [ key, __nil__]                              // AND key IS NOT NULL
 - [ key, __any__]                              // AND key IS NULL
 - [ key, val1,val2]                            // AND key not in ( val1,val2 )
 - [ key, val1,val2,val3, ... valn]             // AND key not in ( val1,val2,val3, ... valn)
 require:
 - [ key, val]                                  // AND key = val
 - [ key, __nil__]                              // AND key IS NULL
 - [ key, __any__]                              // AND key IS NOT NULL
 - [ key, val1,val2]                            // AND key in ( val1, val2 )
 - [ key, val1,val2,val3, ... valn]             // AND key in ( val1,val2,val3, ... valn)
 reject_regexp:
 - [ key, regexpr]                              // AND NOT (  regexpr.MatchString ( key.value)  == true )
 - [ key2, regexpr2]                            // AND NOT ( regexpr2.MatchString ( key2.value) == true ) 
 require_regexp:
 - [ key, regexpr]                              // AND ( regexpr.MatchString ( key.value) == true )
 luafilter: |                                   // AND ( evaulate(luafilter)  )
    --* imposm3 complex lua filter example 
    _luafilter= false 
    if tags["name"] and tags["amenity"] and tags["wheelchair"] then
        _luafilter = true  
    end            
    --* end of Lua code
 exclude_tags:  // message: Depricated !
 - [ key, val]                                  // AND key != val

( but now I would like to implement the accept + reject )

[olt]

I don't like the list syntax - [ key, val1, val2,...] and would go with the syntax from mapping and my example above key: [val1, val2,...]. I would also not add support for __nil__. You can always use the other filter with __any__. Or not?

Regarding the option name: include/accept/require would all work, but I think require makes it clear that an element is not imported if a tag is not present.

[ImreSamu]

I don't like the list syntax - [ key, val1, val2,...] and would go with the syntax from mapping and my example above key: [val1, val2,...]. I would also not add support for nil. You can always use the other filter with any. Or not?

ok , I will rework according your spec - in the next days / weeks