Openstreetmap-carto: Collision between entrance boxes and address labels or icons

Created on 26 Jan 2018  路  12Comments  路  Source: gravitystorm/openstreetmap-carto

With the rendering of entrances as small boxes in #2936, there is a collision when labes or icons are rendered from the same node.

It is quite frequent that addr:housenumber is on the entrance node,
http://www.openstreetmap.org/node/2825036652 18000 times in Berlin,
or a shop icon in addition,
http://www.openstreetmap.org/node/2446830336 99 times in Berlin

Depending on the shape of the label or the icon, elements of the entrance box remain visible, creating a systematic pixel clutter that is not originated by the building geometry.

Examples:
Housenumber 7 looks like in a circle:
7
71 looks like 7.1:
71
The jewellery ring has the entrance in the middle:
ring

I could imagine the following methods to avaid this:

  • putting the address labels on a shield that is larger than the entrance box
  • making the inside of icons in-transparent
  • not rendering the box when a label or icon is present
amenity-points

All 12 comments

@tpikonen What do you think about these problems? Do you think you could fix them?

Personally I don't think this problem is as bad as the examples make it seem, but if this needs to be fixed, I think the easy options are

  1. Further increase the halo of address labels on high zooms where entrances are rendered.
  2. Move the entrance marker layer on top and do not allow overlap, i.e. do not render the marker when there is something else nearby.

Option one would fix the first two examples (probably) but leave other markers overlapping. I don't see why amenities should be tagged on the entrances though.

Option two would be a more invasive fix, but would fix all these cases.

The problem with the shop on the entrance can also be interpreted as bad tagging. If the shop is tagged on a separate node in the building, both can be rendered better. _(I know there are long discussions on this topic and I do not want to restart them here.)_ It will be difficult for the renderer itself to put the shop in the building.

2018-02-15 8:47 GMT+01:00 geozeisig notifications@github.com:

The problem with the shop on the entrance can also be interpreted as bad
tagging. If the shop is tagged on a separate node in the building, both can
be rendered better. (I know there are long discussions on this topic and
I do not want to restart them here.)
It will be difficult for the
renderer itself to put the shop in the building.

+1, I agree that it is topologically bad mapping, because the shop is _in_
the building (only inside), while the entrance is on the perimeter of the
building, i.e. the limit between inside and outside (it is both, inside and
outside). Aside from rendering aspects it is "halfway wrong".

Is it possible to render entrance in the node place and (at the same time) housenumber under/ on the right side of it's icon with some distance between them?

To expand the proposal by @Tomasz-W,, please render any housenumber (e.g. 7) and/or entrance ref (e.g. B) next to (or inside) the entrance icon.

I consider

+1, I agree that it is topologically bad mapping, because the shop is _in_
the building (only inside), while the entrance is on the perimeter of the
building, i.e. the limit between inside and outside (it is both, inside and
outside). Aside from rendering aspects it is "halfway wrong".

argument as convincing. Why mapping jeweler location within door would be correct?

Why mapping jeweler location within door would be correct?

The mapping of the entrance to the shop is clear with this tagging. No need to find the nearest entrance for this shop. But this is no strong argument

Am Mi., 2. Okt. 2019 um 10:33 Uhr schrieb Holger Jeromin <
[email protected]>:

Why mapping jeweler location within door would be correct?

The mapping of the entrance to the shop is clear with this tagging. No
need to find the nearest entrance for this shop. But this is no strong
argument

in case there is an internal corridor leading from the building entrance to
the POI, mapping the thing on the entrance could be seen as factually
wrong. In case of several POIs this isn't a viable approach anyway.

I'm usually putting address information on both, the entrance and the POI
(because in Italy housenumbers refer to gates and entrances, and not to
buildings), so that the relation becomes clear.

My usecase would be something like the following building with two POI and three entrances. Which entrance should a router use to bring you to the hairdresser? (The middle entrance is to the apartments in the top floors.)

image

But again, I do not say mapping the poi on the entrance is correct, just playing devil's advocate.

Am Fr., 4. Okt. 2019 um 13:27 Uhr schrieb Holger Jeromin <
[email protected]>:

My usecase would be something like the following building
https://www.openstreetmap.org/way/111088821#map=19/51.88196/8.50655
with two POI and three entrances. Which entrance should a router use to
bring you to the hairdresser? (The middle entrance
https://www.mapillary.com/map/im/ROhSp-X2OEKqLFiBOpE9rg is to the
apartments in the top floors.)

IMHO the solution is generic: if the whole building has the same address,
add the address to the building. If the entrances have their own
housenumbers, add addresses to the entrances. For POIs I would always use
the address that they use themselves. If you want to have routing working
at the microlevel (which entrance etc.), you will have to add routing data
at the microlevel (indoor mapping).

While the issue with POI icons might be wrong mapping, it's certainly encouraged to add addr:housenumber and addr:unit tags to building entrances, especially in certain countries where the address is directly associated with the door.

One possibility would be to use text-dy to move the addr text down below the icon.

Was this page helpful?
0 / 5 - 0 ratings