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 amenities, a secondary entrance may be signed for a single amenity 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
63511016
accept rate: 14%

edited 08 Aug, 23:29


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
9.8k1287117
accept rate: 36%

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
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:

×764
×144
×32
×16
×12

question asked: 08 Aug, 21:01

question was seen: 66 times

last updated: 09 Aug, 15:15

powered by OSQA