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

[Tom MacWright]

An "onboarding guide" which explains relations to the extent that a mapper
could confidently edit them would be quite a bit more than that.



Welcome to OpenStreetMap! This is a visual editor which lets you define
things that you see in the world and their spatial component, specifically
in a map form. However, the most important part of the map is a non-visible
semantic relational attribute of the data. These relations are abstract
groups that can contain zero elements, or thousands. They can contain other
relations. Maybe they can even contain themselves.

Almost all of the time, a relation with zero members is a mistake, except
for one case where it isnt.[2] 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.

Cool: let's start editing relations. Well, first, earlier we said that
relations aren't spatial. Well, some are, some aren't. Maybe half and half.
Some are used to structure multipolygon geometries.

Okay, but most relations are invisible. 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. 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.

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.

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.

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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150627/818846c2/attachment-0001.html>