3D mapping and topology

[turepalsson]

How do we handle points with the same (lat,lon) coordinates but different levels?

For example, in this (somewhat sketchy) multi-storey car park, where the red line represents a highway=service access road, the two points circled in blue have the same positions projected on the ground plane, but different elevations. For the horizontal bits of the way, we could use level tags, but how to handle the slopes, which have different levels at each end?

One possibility would be something like start_level=1,end_level=2 or even level=1;2, though I’m not super fond of tags where the value depends on the orientation of the way.

[tordanik]

Currently, the values in a level tag are considered unordered. Using established tags, the situation could be made unambiguous by adding incline=up or incline=down.

Certain use cases such as calculating a route would have to start looking at layer/level information to still produce correct results after the change.

[turepalsson]

Oops, I wasn’t even aware that levels could have multiple tags today. =)

[flacombe]

With all due respect I think it's a pretty bad idea to solve core data model issues with tagging.

Tagging is high level conceptual model and shouldn't have any influence on lower layers.
This would be inconsistent with area type definition where it is clearly intended to remove tags from decision making in area/polygon guessing.

[turepalsson]

I agree that solving data model limitations with tags does not feel good... after all, this is how we got into the racetrack-or-area mess that we are now trying to get out of!

[1ec5]

This gets tricky when vertices of a single way, such as a building way, exist on multiple levels. The simple indoor mapping scheme has affordances for repeating, say, a door on multiple levels. However, this doesn’t address one situation I often run into, that there’s a statue or flagpole mounted on the wall directly over a doorway, requiring a different set of tags that would be weird to mix. It isn’t great to have to overlap two nodes of the same way to express this fact. Because of validator warnings, mappers tend to offset one of the features slightly, but it results in an imbalanced 3D rendering.

[1ec5]

It’s common to map a single man_made=flagpole node with semicolon-delimited values for flag:wikidata etc. After all, what’s being mapped is not the flags themselves (which are kind of ephemeral) but rather the flagpole that supports them. The identities of the flags are ancillary information.

While this approach works reasonably well for multiple flags on flagpoles, it doesn’t help as much for multiple signs assembled on the same signpost. The current traffic_sign documentation recommends semicolon- or comma-delimited values. However, this is different than flagpoles because it’s the signs themselves that are being mapped as features in their own right. A lot of attributes can differ between the signs within an assembly, but the data model doesn’t allow us to nest an array of key-value tables inside a single tag. I would prefer to map the signs as individual features to allow for more detail about each sign, but some way of associating the features would be beneficial.

[1ec5]

One possible hack would be to create a relation that contains only the flagpole node as a member, set the role to something like "is_also" and then put the tags for the second flag on the relation.

At one point, I considered proposing a scheme for street parking restrictions that relied on multiple relations containing the same way as a member. However, in the current data model, a limitation of this approach is that a feature’s relation memberships are inherently unordered. You’d need to rely on layer-like tags on each relation to rank the memberships, which could get out of sync pretty easily.

[bryceco]

In your street parking example why do you need to rank the relations? At least in the multistory building case it's necessary to have layer/level tags anyhow.

[1ec5]

Only because some restrictions could override others – think exceptions that only apply to certain times, or under certain conditions, or that extend other restrictions. We’re currently handling this by having mappers interpret the signs and distribute the details of a sign across multiple multivalued *:conditional tags. This gets really confusing in some cities in the U.S., where streets typically accrue partially redundant restrictions over time.

[1ec5]

However, in the current data model, a limitation of this approach is that a feature’s relation memberships are inherently unordered.

Do folks see this as a major concern? It might also have something to do with the prevalence of subarea relation roles, which are unfortunate for how they create reference loops.

[turepalsson]

(I suppose the obvious solution is to store Z coordinates as well... However, that means either increasing database space by almost 50% or complicating things by having mixed 2D and 3D coordinates. Also, while consumer-grade GPS produces 2D coords which are perfectly usable for everything except extreme large-scale mapping, the Z coordinate is a whole different ball game, so this seems like a non-starter.)

[bryceco]

I agree that adding a z-coordinate to every point is overkill, but we could add 3-d variants of ways and areas where only those variants have 3-d points, and everything else keeps the existing 2-d points.

[flacombe]

How all of this can be edited with 2d editors, from the very first 3d point?