[Tile-serving] [openstreetmap/osm2pgsql] Lua relation members gets post-way transform member tags (#659)

[Paul Norman]

I am working on a transform which creates a table with wood areas, a name column, and no other transform-generated columns.

This means I want a way function like

```lua
function wood_ways(tags, num_keys)
    if tags["natural"] == wood then
        local cols = {}
        cols.name = tags["name"]
        return 0, cols, 1, 0
    end
    return 1, {}, 0, 0
end
```

This works properly, turning a way with `natural=wood` into a row with no transform-generated columns

If I am only concerned with old-style MPs, I can then add 

```lua
function wood_rels (tags, num_keys)
    if (tags["type"] == "multipolygon" and tags["natural"] == wood) then
        return 0, tags
    end
    return 1, {}
end

--- test function
-- @param tags OSM tags
-- @param member_tags OSM tags of relation members
-- @param member_roles OSM roles of relation members
-- @param membercount number of members
-- @return filter, cols, member_superseded, boundary, polygon, roads
function wood_rel_members (tags, member_tags, member_roles, membercount)
    assert(membercount == 2) -- hard-coded to avoid loops to generate member_tags
    if tags["natural"] == wood then
        local cols = {}
        cols.name = tags["name"]
        return 0, {}, {0, 0}, 0, 1, 0
    end
    return 1, {}, {0, 0}, 0, 0, 0
end
```

It's not obvious, but member_tags is member tags **after** transformation by the way function, i.e. columns to be output to PostgreSQL, not original tags.

This causes a problem when I ~~want~~need to handle old-style multipolygons, like a relation with `type=multipolygon` and two members, one with `natural=wood` and the other with no tags.

The output of `wood_ways` for the first way is `0, {}` and the second is `1, {}`. This means the function called for rel members is
```lua
wood_rel_members({type="multipolygon"}, {{}, {}}, {"",""}, 2)
```

This is the same as any two-member MP which does not have any tags on ways, which does not have natural=wood on any ways, or that does have natural=wood on the ways, but also has different tags (e.g. `leaf_type` key). Because of this, it's impossible to correctly handle old-style MPs with the above way transform.

Although I made this example with the multi backend, it shows up if you do the same thing with the pgsql backend. The difference is people tend to either **modify** existing keys when generating columns (e.g. @SomeoneElseOSM) or **add** new columns (e.g. @systemed), but seldom replace all the columns with the pgsql backend like I am doing.

I'm not certain if this is a bug in the Lua API we define, or what we've implemented.

Putting print statements into the way call shows that `wood_ways` gets once for each way, and once more for each relation membership a way participates in.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/659
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20161221/c09bcda6/attachment.html>