2
1

How should we map POI nodes with multiple entrances?

For instance, a restaurant occupies the ground floor of a multi-level building that spans an entire city block. It has a main entrance that corresponds to its official address, and another entrance on a parallel street.

If this restaurant were a mapped as way, I'd simply add two entrance nodes to the way's perimeter, entrance=main and entrance=yes. But because there are other tenants in the building -- maybe just flats, or maybe other amenities -- the restaurant is mapped as a node. There's no obvious way to associate entrance nodes with the restaurant node.

Note that:

  • Entrances might be on the same street, or on different streets.
  • Secondary entrance is often constructed and signed for wheelchair access.
  • Secondary entrance may be signed with its own differing address, or with the main address, or may have no address.
  • In some buildings, both main and secondary entrances can correspond to multiple POIs.
  • When a building contains multiple POIs, a secondary entrance may be signed for a single POI but in fact allow access to all of them.

My instinct says there should be a way to join the POI node and the entrance nodes into a relation, but I wouldn't know what to use for type or roles.

Another thought was simply drawing footways connecting the POI to the entrance nodes, but I'm a little uncomfortable mapping a footway that does not, in fact, correspond to anything in real life. Is there an appropriate tag for a way that isn't meant to directly correspond to something geographically? symbolic=yes or isomorphic=yes or visible=routing_only, something like that?

Using the indoor tagging scheme also comes to mind, but ideally I'd want a solution that would allow indoor-tagging-agnostic routing engines to be able to direct users to the best entrance (especially for wheelchair users) without having to deduce, for instance, that an entrance on level 0 corresponds to a POI on level 0 when connected by a corridor on level 0.

Thanks, J

asked 08 Aug, 21:01

jmapb's gravatar image

jmapb
84021421
accept rate: 18%

edited 21 Aug, 16:23


From your description, I see no reason not to map this restaurant as an area instead of a node. That the building has other tenants is a good reason to avoid putting the restaurant's tag onto the building area, but it does not stop you from creating an area for the restaurant itself – this second area can even share nodes with the building area. By mapping the POI as an area, adding multiple entrances becomes very easy.

Although this particular situation may be solved using an area, though, you are ultimately correct that there are more complex cases where that doesn't work any more – such as an entrance that provides access to multiple amenities. Using relations is probably the best solution for those cases. There is no firmly established relation type yet, but there have been some proposals over the years. For example, I believe the associated_entrance relation would cover this use case.

permanent link

answered 08 Aug, 23:03

Tordanik's gravatar image

Tordanik
10.1k1293123
accept rate: 35%

Thanks. A distinct but overlapping area specifically for the POI is a mapping method I've never encountered, but it sounds useful for the simple cases, of which there are many. Also useful for POIs that span the ground floor of multiple buildings. And it would be compatible with the indoor tagging schema.

Offhand, one thing that gives me pause is the difficulty of estimating the footprint of a restaurant etc if it's not occupying the entire floor. How best to tag the fact that this may be a rough estimate? I'd hate to clutter the map with notes.

The associated_entrance relation, though, looks very much like what I had in mind originally. But do any routing engines respect this?

(08 Aug, 23:27) jmapb
1

@jmapb: it's very unlikely that routers support an abandonned proposal with only 44 occurrences (according to taginfo).

(09 Aug, 04:11) escada

@jmapb: Estimated polygons can still be useful. And for indoor and underground features, them being estimates would be my default assumption unless the changeset has a source indicating otherwise. But yeah, if you want to explicitly indicate that you've been using an estimate, note or fixme tags would do the job.

And routing engines are of course highly unlikely to already support relations for entrances. But one of the best ways to encourage developers to add support for any new tag is to use it a lot!

(09 Aug, 15:15) Tordanik

Thanks... I've been trying out some polygon areas for shops and restaurants. Here's a restaurant similar to the situation described in the original question, with a main entry on the corner and a wheelchair entry in the back: https://www.openstreetmap.org/way/617474313

I've also found this is a great way to map large USA drug stores like Duane Reade and Rite Aid which function as grocery/convenience stores 24/7 and contain a pharmacy with daytime-only hours:

https://www.openstreetmap.org/way/617474312 https://www.openstreetmap.org/way/616812439

I've taken special care to make the the entrance nodes are connected to the POI way only, not to the building polygon, so they won't be mistaken for general entrances to the building. I've even separated them from the building footprint by a couple inches, which might be overkill.

I've also tried out the associated_entrance relation, and though it makes sense to me, JOSM flags it, so I doubt these will survive for too long.

(21 Aug, 16:20) jmapb
1

It's all a bit moot at the moment because the available routing doesn't even route to an entrance in the simple case (ie, directions to building that has one and only one entrance node), much less an associated_entrance. But hopefully these things will get more sophisticated with time.

(21 Aug, 16:21) jmapb

Something I've just noticed re: mapping POIs as areas versus as nodes -- A POI mapped as a node inside a building will inherit that building's address (if it has one) in Nominatim, a but a POI mapped as a closed way will not. Even if the way is entirely inside the building, Nominatim will simply associate it with the nearest road, not the building address. So when mapping POIs as areas, be sure to tag them explicitly with addr:* tags if possible.

(30 Oct, 15:48) jmapb
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×791
×147
×33
×17
×12

question asked: 08 Aug, 21:01

question was seen: 369 times

last updated: 30 Oct, 15:48

powered by OSQA