housenumbers on non-buildings areas aren't rendered

[Atalanttore]

Hi,

it would be useful to see the tagged housenumbers (addr:housenumber=XX) of building parts (building:part=yes) on OpenStreetMap.org.

Example of building parts with unrendered housenumbers: http://www.openstreetmap.org/#map=19/49.00980/12.12049

Regards, Ettore

[polarbearing]

building:part is an element from 3D-mapping, that is used to characterise physical differences in the parts, such as different height or materials. It always needs a building outline, carrying the building=* tag. This building outline is supposed to carry further information, such as address and usage details.

In the example above, there is an outline, and several building:part(s) that only carry the addr:* tags. This can be achieved with simple address nodes within the apartment block.

If these are physically individual buildings wall-to-wall, such as terraced houses, the block can be split, i.e. what are now building:part can become building=house.

[dieterdreist]

sent from a phone

Am 15.08.2015 um 09:46 schrieb polarbearing notifications@github.com:

building:part is an element from 3D-mapping,

not only 3D

that is used to characterise physical differences in the parts, such as different height or materials.

not only physical differences, can be all kind of properties like wikipedia links, architectural typology, name, address, usage, ...

In the example above, there is an outline, and several building:part(s) that only carry the addr:* tags. This can be achieved with simple address nodes within the apartment block.

there is nothing wrong with assigning an address to an area, indeed it has certain advantages over a node

[pnorman]

Because the issue is actually about non-building areas, not building parts, I've revised the topic to reflect this.

The relevant SQL is

The relevant SQL is
```sql
(SELECT
    way,
    "addr:housenumber",
    way_area/NULLIF(!pixel_width!::real*!pixel_height!::real,0) AS way_pixels
  FROM planet_osm_polygon
  WHERE "addr:housenumber" IS NOT NULL
    AND building IS NOT NULL
UNION ALL
SELECT
    way,
    "addr:housenumber",
    NULL AS way_pixels
  FROM planet_osm_point
  WHERE "addr:housenumber" IS NOT NULL
  ORDER BY way_pixels DESC NULLS LAST
) AS housenumbers

This code is old, coming from osm.xml SVN revision 15913, written by ldp in 2009.

The logic is even older, coming from svn revision 13495 (see way_numbers), written by Steve Chilton in Feb 2009, 7 years ago.

To see how dropping the building is not null condition would look, I'd want to try it out.

[polarbearing]

there is nothing wrong with assigning an address to an area

There are also amenities, such as amenity=[hospital | school | community_centre], that have one address for the whole campus. In Berlin, the "housenumber" is in fact a number for the plot of land, thus it would be logical that attaching addr:* to the amenity outline gets rendered.

Consequently, however, we would need to show both number and name, thus #735 would need to be extended to non-buildings.

[ghost]

Hi

Are there any plans for this issue?

According to the wiki, it's fine to add addresses to any areas. Besides, it's more exact than adding them to a node and it doesn't require to duplicate the address for POIs inside that area (e.g. for buildings that are separated inside and thus have more than one house number).

It would be nice to see addresses on non-building areas rendered on OSM Carto.

[polarbearing]

We would need to discuss if we compile a positive list of areas on which addr:housenumber is rendered, or do so on any area.

[dieterdreist]

2018-01-22 14:35 GMT+01:00 polarbearing notifications@github.com:

We would need to discuss if we compile a positive list of areas on which addr:housenumber is rendered, or do so on any area.

I would suggest to render them on any area (i.e. consider the housenumber a feature in this rendering, not a property of something else).

[kocio-pl]

Is anybody ready to make the code for testing?

[polarbearing]

What about the conflict with names. For buildings, currently, the housenumber is not rendered when the building or the feature using the building has a name. For areas, we have some where the name scales with way-size. Both are currently placed in the middle. Would it make sense to place the housenumber more peripheral (e.g. similar to naming borders)? Would it be possible to turn the housenumber towards the street matching the addr:street name?

[tguen]

It's common to tag apartment complexes and mobile home parks with a single address, usually (not always) with landuse=residential. I would like to see addresses rendered in these cases.

[hungerburg]

Here is one building https://www.openstreetmap.org/way/314228700 that has two house numbers, that were put on building:parts. I would appreciate, if the numbers where shown on the map; Even on zoom 18 there is enough space for them not to overlap the name of the building.

[imagico]

I would be reluctant to add rendering of housenumbers to polygons with building:part because that does not seem to be a well established tagging at the moment. The most common way to map different housenumbers on a single building right now is to tag the housenumber on the entrance (918k combinations - vs. 20k combinations) - which tends to be the verifiable information available to the mapper (the housenumber tends to be indicated at the entrance). Which parts of the building internally correspond to which housenumber is not usually publicly visible. If or not there are other polygon features other than buildings where tagging housenumbers is common practice is a different matter.

[hungerburg]

Sticking the number to the part is nice, so the complex can get a name and the house-numbers still (could) show. Agree, with the numbers on the entrances, this is working right now. And that is where they are available for inspection from the outside. But it is oh so fashionable to map everything as an area. Last year, I mapped the entrances for the parts because they are not immediately obvious. One of the parts has two of them with a full table of door bell buttons. A week ago, I mapped a newly built house close by as two buildings, because there are two addresses. Actually, I could not tell from the outside, where the building parts are separated. It will not get on any aerial this year or next, but that very likely wont help either. It also has a name for the complex, but I did not bother to map that. I thought of it as a marketing gag. So going to tag the entrances. House numbers considered indispensable here :)

[dieterdreist]

sent from a phone

On 5 Nov 2021, at 23:36, hungerburg @.***> wrote:

A week ago, I mapped a newly built house close by as two buildings, because there are two addresses.

ideally the housenumbers should be added to where they apply, although in Germany for instance this is hardly possible because of the „we do not map plots“ doctrine. Actually housenumbers a two fold, they are (typically) assigned to something physical like a building, a plot, an entrance, a gate, etc. but then they also serve as addresses for people and things, and we are using the same tags for it. In case the housenumber is for a point, we cannot unambiguously rely on spatial inheritance and repeating the address as property seems the most sane way (relations would be an alternative).

[aceman444]

Yes, rendering "name" of "building:part" and also its "addr:*" would be great.

[RedAuburn]

This should really be added. I'd imagine the main reason it isn't as widely adopted is because it's not rendered in Carto.

[aceman444]

True, because some people may map building parts as separate "building=*" because the name renders. When mapping as a single encompassing building and having building parts with names the names disappear.