member_type in relations and osm_type use different case.

[giggls]

What version of osm2pgsql are you using?

2022-09-26 10:10:16  osm2pgsql version 1.7.0
Build: None
Compiled using the following library versions:
Libosmium 2.18.0
Proj [API 4] Rel. 7.2.1, January 1st, 2021
Lua 5.3.3

What operating system and PostgreSQL/PostGIS version are you using?

Debian 11 (PostgreSQL 13 and PostGIS 3.1.1 from Debian 11)

What did you do exactly?

I try to import site relations.

What did you expect to happen?

I would expect that member_type of relations and regular osm_type would use the same case.

What did happen instead?

While member_type uses lowercase ('n','w','r') osm_type uses uppercase ('N','W','R').

What did you do to try analyzing the problem?

The Problem can be reproduced using the following lua script:

local tables = {}

tables.point = osm2pgsql.define_table{
    name = 'osm_point',
    ids = { type = 'any', id_column = 'osm_id', type_column = 'osm_type' },
    columns = {
        { column = 'tags',  type = 'jsonb' },
        { column = 'geom',  type = 'geometry', projection = 'latlong'  },
    }
}

tables.siterel = osm2pgsql.define_table{
    name = 'osm_siterel',
    ids = { type = 'relation', id_column = 'site_id'},
    columns = {
        { column = 'member_id', type = 'bigint' },
        { column = 'member_type', type = 'text' },
        { column = 'site_tags',  type = 'jsonb' }
    }    
}

function osm2pgsql.process_node(object)

    tables.point:add_row({
        tags = object.tags,
        geom = { create = 'point' }
    })

end

function osm2pgsql.process_relation(object)

    if object.tags.type == 'site' then
      for _,member in ipairs(object.members) do
        tables.siterel:insert({
          member_id = member.ref,
          member_type = member.type,
          site_tags = object.tags 
        })
      end
    end
end

[joto]

That's unfortunate that we have this inconsistency in "naming" the OSM types. The problem is that we can't really change that now, more than two years since version 1.3.0 was released, which introduced this.

I see two options:

1. Live with it. Add big warnings to the documentation.
2. Leave the upper case used in the type column, it was chosen to be compatible with what's used in the gazetteer output. Add a new field to the member, say member.osm_type or so, that uses the uppercase handle. Mark the member.type as deprecated and remove it in a few years.

[giggls]

I just saw that it is easy to remove the inconsistency from the database by replacing this piece of code as follows: member_type = member.type member_type = string.upper(member.type) So documenting the inconsistency is probably the way to go.