Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

housenumbers on non-buildings areas aren't rendered #1746

Open
Atalanttore opened this issue Aug 15, 2015 · 17 comments
Open

housenumbers on non-buildings areas aren't rendered #1746

Atalanttore opened this issue Aug 15, 2015 · 17 comments

Comments

@Atalanttore
Copy link

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
Copy link
Contributor

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
Copy link

sent from a phone

Am 15.08.2015 um 09:46 schrieb polarbearing [email protected]:

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 pnorman changed the title housenumbers on building parts aren't rendered yet housenumbers on non-buildings aren't rendered Aug 26, 2015
@pnorman pnorman changed the title housenumbers on non-buildings aren't rendered housenumbers on non-buildings areas aren't rendered Aug 26, 2015
@pnorman
Copy link
Collaborator

pnorman commented Aug 26, 2015

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
Copy link
Contributor

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
Copy link

ghost commented Jan 22, 2018

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
Copy link
Contributor

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
Copy link

dieterdreist commented Jan 22, 2018 via email

@kocio-pl
Copy link
Collaborator

Is anybody ready to make the code for testing?

@polarbearing
Copy link
Contributor

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
Copy link

tguen commented Aug 12, 2021

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
Copy link

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
Copy link
Collaborator

imagico commented Nov 5, 2021

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
Copy link

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
Copy link

dieterdreist commented Nov 6, 2021 via email

@aceman444
Copy link

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

@RedAuburn
Copy link
Contributor

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests