[OSM-talk] Mappers and apps should focus on relations at the very start
fernando.trebien at gmail.com
Sat Jun 27 16:58:00 UTC 2015
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
+55 (51) 9962-5409
"Nullius in verba."
More information about the talk