Parse decimal building heights

[Symmetricity]

This PR is AI generated.

Parse decimal building heights

The OpenMapTiles profile parses height, min_height, building:levels, and
building:min_level with tonumber(value, 10).

That works for integer tags, but newer Lua versions reject decimal strings when
an explicit base is supplied. Valid OSM values such as height=18.5 and
building:levels=3.5 therefore parse as nil and fall back to the default
one-floor render height. LuaJIT accepts the same values with the base argument,
so the same input can produce different render_height values depending on the
Lua runtime used to build tilemaker.

Parse these four fields with plain tonumber(value) instead. That keeps
integer handling unchanged, accepts decimal OSM values, and makes the profile
consistent across Lua runtimes.

The change is intentionally scoped to the OpenMapTiles building height helper.
It does not alter layer selection, building feature counts, minzoom handling, or
the existing fallback height for buildings with no usable height/level tags.

Examples

The examples below are from Liechtenstein CI artifacts generated from the same
input.

Decimal height

Source object:

way 490877222
height=18.5
building=detached

OSM link:

https://www.openstreetmap.org/way/490877222

Pre-fix output on a newer Lua runtime:

render_height=3.66

Pre-fix output on LuaJIT:

render_height=18.5

Post-fix output:

render_height=18.5

Decimal building:levels

Source object:

way 165295920
building:levels=3.5
building=school

OSM link:

https://www.openstreetmap.org/way/165295920

Pre-fix output on a newer Lua runtime:

render_height=3.66

Pre-fix output on LuaJIT:

render_height=12.81

Post-fix output:

render_height=12.81

These examples show both parts of the bug: decimal tags were being ignored on
some Lua runtimes, and generated tile content could differ across CI runners
for the same input.

Reproduce

With a newer Lua runtime:

lua -e 'print(tonumber("18.5", 10)); print(tonumber("18.5"))'

Before this change, the first expression returns nil, so
SetBuildingHeightAttributes() falls back to BUILDING_FLOOR_HEIGHT.

After this change, decimal height and level values parse as numbers and the
rendered building attributes use the source tag values.

Testing

• git diff --check origin/master..HEAD
• luac -p resources/process-openmaptiles.lua
• Focused Lua check that tonumber("18.5", 10) is rejected by the local newer
  Lua runtime while tonumber("18.5") is accepted
• Local generated-tile artifact comparison for decimal height and decimal
  building:levels examples

Related Issues And PRs

Related upstream context:

• How to configure fields? #121 includes prior maintainer guidance to parse OSM height tags with plain
  tonumber.
• PR Add render_height and render_min_height to buildings for 3d rendering #263 added the current render_height and render_min_height attributes
  for 3D building rendering.
• PR feat: export and render building:part #692 is an open building-related PR that expands building:part handling,
  but it does not directly address this Lua-runtime decimal parsing issue.

I did not find an existing upstream issue, PR, or discussion that directly
reports decimal building heights being ignored on newer Lua runtimes.