[OSM-talk] Mappers and apps should focus on relations at the very start

[Fernando Trebien]

Well, this was not targeted at iD since Potlatch and Merkaator (and
probably others) suffer from the same problem.

Making the user understand the simple "membership logic" would be a
great first step. The second one would be to develop apps (in
particular, editors) that support all the variations you mentioned.

> Maybe they can even contain themselves.

Actually no, the server checks for circular dependencies, and a
relation pointing to itself is a cycle. Try it, the server returns a
validation error.

> Almost all of the time, a relation with zero members is a mistake, except
> for one case where it isnt.

That's misleading. The article [4] clearly says that such cases are
either mistakes or placeholders (which could be considered mistakes as
well).

> The distinction between relations as a bug in
> the data and as a legitimate, complex semantic statement is not something we
> can autodetect, so use your judgment.

Not quite. JOSM's relation editor will show you when a route relation
is broken and exactly where. It will also show you when the relation
is a closed cycle, as expected from boundaries. So multipolygons and
boundaries must have closed cycles and routes cannot be broken, this
is easy to verify (just check if members are ways and if their start
and endpoints match). JOSM also includes an algorithm to automatically
sort members. That algorithm could even be used to automatically place
a new member at the correct position, or to prevent an unconnected
member from being added to the route. That would make sense in a basic
editor where people are not expected to do advanced editing. JOSM
prefers to let the relation get broken to let you work and issue a
warning when validating data before submission in case you forgot
something.

> Cool: let's start editing relations. Well, first, earlier we said that
> relations aren't spatial.

The meaning of the vast majority of relations is spatial. Are lines
spatial without their points? Is an empty line spatial?

> Well, some are, some aren't. Maybe half and half.
> Some are used to structure multipolygon geometries.
> Okay, but most relations are invisible.
>
> Great, so relations are groups of things that can be zero or many, for
> technical reasons, spatial relationships, or abstract relationships. Now
> we're getting started. Relations, unlike sets in math, are ordered. Unlike
> ordered sets, they also have special ways in which each element is
> contained. So they're kind of like ordered, semantic sets of potentially
> anything. And, typically, invisible.
>
> Now that we've discussed the basics of relations, let's cover each of the
> different kinds, including each kind's stipulations of what is contained,
> whether order matters, and the role tags that are unique to each use-case.
>
> ...You can see where this is going: I haven't started to explain what you
> use relations for, and we've already seen the sort of mountain of
> unpredictable complexity they add to the OpenStreetMap data model - one of
> the fundamental things that makes it both more powerful than most data
> models and incompatible with all other data models.

Relations are lists of objects, each with an assigned role. They are
used to represent areas with holes (called multipolygons), large
boundaries, routes (roads, railroads, buses, trams, ferries, hiking,
cycling, and waterways), and turn restrictions. [2][3]

Multipolygons, boundaries and routes (including waterways) are all
very common relations and they all represent spatial concepts do get
rendered - at least by popular renderers like Carto.

Restrictions are far less common (1/5th of occurences when compared to
multipolygons, surely fewer than routes+boundaries combined). It's
hard to say they do not represent a spatial/directional concept since
the vast majority have a "via" point around which the restriction is
placed.

The remaining common types [1] that are also approved by the community
[3] essentially fall in the category of "invisible unordered sets":
public_transport, route_master. It's hard to say that public_transport
is not spatial, since the bounds of its members usually occupy a very
narrow area. route_master is seldom broken because users rarely edit
its member relations.

> You're editing the map, but the
> relation is for routing software or maybe a very large polygon which is
> limited by some technical limits that we'll get into later.

If that's your view, why is that iD (and Potlatch) has a turn
restriction editor? Isn't the interest in turn restrictions limited to
routing software?

Another very practical use of relations is to avoid having to overlap
lines that match exactly. Editing areas and lines that overlap is very
cumbersome in any editor, even in JOSM.

> Regardless, when
> you break those kinds of relations, you won't know, because you can't see
> the breakage on the map, only in some software that you probably aren't
> using.

Which map are you talking about? The one the editor displays, the one
on the main website, or some other apps' view of map data?

On JOSM you do see very clearly when a multipolygon/boundary is
broken, they are rendered as "open areas" (which are filled but
missing one side). You don't get to see broken routes (for now), but
there's a validator to tell you that the route you messed up with
(even if you didn't edit the relation directly) is missing a piece.
Double click the validator warning and it will highlight where the
problem is and the unconnected ways in the route relation. It is very
precise and visually clear.

This problem is similar to that of lines whose nodes overlap exactly
but are not connected. JOSM solves this by rendering the node
differently when it is connected. Other editors don't care. When two
streets overlap exactly, no editor shows you that they overlap. Even
basic things are sometimes not visible to the mapper, no matter the
level of experience.

> The problem coming from the "building an editor" perspective is that
> relations add a level of complexity to the question of "not breaking data"
> that wholly explains why it's such a rarely attempted feat to "edit all
> openstreetmap data". I would love if this problem were fixable with
> documentation, but unfortunately, this is actually just a deep issue that
> isn't easy to document, and iD would still be grilled on the regular for not
> preventing people from doing things.

Again, this is not targeted at iD, but JOSM does a good job and I
think good ideas should be at least considered. I also think that JOSM
is way more complex, and if the good idea requires a lot of
development complexity, then maybe similar, but not-as-good ideas
should be considered too.

> The data model could be improved in a few ways: if it embraced the
> long-awaited area datatype[1] and stopped using relations as a brittle
> stopgap around multipolygons and node limits. Or if it specified & enforced
> well-established types of relations in such a way that the validity of an
> editor's approach was agreed-on rather than constantly argued about.

I kind of agree, but this brings us down to two other topics:
- areas as relations: pretty much the same discussion as with ways;
this could be related to multipolygons in some aspects
- the server performing validation, which is probably controversial
because it would impose complexity on apps

Besides, OSM lets people invent tags freely. Why wouldn't it let
people invent relations too? It's this freedom that has made some
relations emerge and then be phased out as people realized they
weren't good enough.

To truly let people invent things, two basic problems need to be well
solved: have a good tag editor, and have a good relation editor. If
ways and tags were the same entity, that would translate to a single
relation editor and the work would be greatly reduced.

> And it's not that I hate relations: they are truly one of the only
> successful instances of "linked data" in the entire world of computers.
> They're also a legitimate reflection of the world's actual complexity. But
> reconciling their ephemeral, non-visual, intensely-freeform properties with
> the ideal of "a map of the world everyone can edit" is not a simple matter.

I know that. I actively avoid relations whenever possible, but routes
have no other better solution, and while boundaries could be expressed
as simple areas (closed ways), that would cause two problems:
- lots of space lost in the server by replicating point references
- editing usability while handling areas that share edges (not uncommon)

[1] http://taginfo.openstreetmap.org/keys/type#values
[2] http://taginfo.openstreetmap.org/keys/route#values
[3] http://wiki.openstreetmap.org/wiki/Types_of_relation
[4] http://wiki.openstreetmap.org/wiki/Empty_relations

> Tom
>
> [1]: http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html
> [2]: http://wiki.openstreetmap.org/wiki/Empty_relations
>
> On Sat, Jun 27, 2015 at 12:58 PM, Fernando Trebien
> <fernando.trebien at gmail.com> wrote:
>>
>> This is surely going to spur controversy, but here I go.
>>
>> Imagine a world in which a new mapper opens its (newly-discovered)
>> favourite editor and is presented with the following message the first
>> time they edit anything:
>>
>> "You can map using points and relations. Relations are groups of
>> things with specific roles: groups of points make lines, groups of
>> lines can make things like routes bus routes, city boundaries, hollow
>> buildings, turn restrictions, etc., groups of routes can make route
>> networks. Mappers rarely group further, but they could.
>>
>> Because lines are very common, you can draw them by simply adding many
>> points one after another. If you want to make more complex relations
>> such as routes and boundaries, check out the relation editor."
>>
>> Of course, such an editor would have to be designed with that
>> philosophy in mind from the start.
>>
>> Is this a rant? Not really, this a sincere impression I've had for a
>> very long time. Many novice users are confused by relations because
>> they need to build their understanding later, often when someone
>> complains they've made some mistake. When this notion of "grouping" is
>> presented at the very beginning, I believe people will easily
>> understand it for all of the advanced scenarios (the most common being
>> routes and boundaries). It would just be didactic.
>>
>> Some people have even proposed abolishing the "way" entity from OSM's
>> API and replacing it with a relation "type=way" with "node" members.
>> Some logic (such as checking for empty ways/empty relations and
>> checking membership across different entities) would be simplified,
>> which would be good for database maintenance. It would also be good
>> for app development, apps would have to understand relations from the
>> very start and would thus be encouraged to support advanced features.
>> That would be very little extra development overhead compared to just
>> points and lines.
>>
>> I understand that very big relations with lots of nodes and a single
>> role for all of them would be undesirable. Apps like the editor can
>> still make the "way" entity transparent to the user, so an API change
>> is not really required for a change in editor/mapper mindset. Still, I
>> raise this aspect because, in an abstract sense that mappers do need
>> to develop, ways are simply a "type of relation", and they could be
>> concretely so. Relations cannot be abolished (there is no other way to
>> represent bus/car/hiking/boat routes, or hollow polygons). Ways, in
>> theory, can.
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "Nullius in verba."
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."