[OSM-dev] dev Digest, Vol 157, Issue 12 - Instead of "Area datatype"

SandorS sandors39 at gmail.com
Tue May 8 06:30:33 UTC 2018

Suggestion: Instead of just evaluating area datatype, make a complete revision of basic/essential notions and rules in OSM Wiki documentation especially those related to “basic features”. 
There are many reasons and arguments for the suggestion. Let us look at some of them.
-Most if the notions and rules are ill-defined and inconsistent. This leads to wide spectrum of interpretations, speculative guesses and misunderstandings.  Consequently, there are different filings and statements what data errors are in OSM, what reparation models should be used and so on.
-When a person publishes a constructive critic in most of the cases this is considered as a kind of attack on OSM from majority of the authorities even when unbeatable arguments are provided. If critics and change suggestions come from a community like this, the situation is quite different.
-In the past, many of the fundamental notion definitions and descriptions have changed too frequently. In turn this may cause compatibility problems, uncertainty and dilemma both on the data mapping and usage side.     
As arguments, let us take some specific issues where we see the defective/ill definitions and descriptions. For that, let us read carefully (again and again) the OSM Wiki pages dedicated to way, relation, polygon, area and multipolygon basic notions (best in this order) and to some dependent notions like bay, fiord and so on.
-Way. Here we can read “A way is an ordered list of nodes...”. What ever the “ordered list” means still the way is just a sequence of isolated nodes and never a line object. Consequently, any use of the way notion as a line object is speculative and based on guesses, professionally wrong. Luckily, most of us guess the same thing but that is something else.
-Relation. Here we can read that “A relation...consists of...relation...”. A notion defined by itself, a serious scientific error because it says nothing. We can also read the confusing “which is used to define...relationship...” and should be quite the contrary, the relationship, the connection between the elements is used to impose certain order in a set of objects. Luckily, again, most of us have more or less the same speculative believe/guess what an OSM relation should be. However, there are many traps in these believes, for instance the issue – can in a relation exist isolated elements?
-Area. This notion is one of the most mentioned and for good reason. Unfortunately, what it is is left to any of us to speculate. It is a page dedicated to area where we can read “An area (or filled polygon) can be defined as an enclosed filled area defined as a closed way...”. If we apply the transitivity low an area is a way else area is defined by itself. In either case the definition is totally wrong. Besides, the “fill” is presentation (rendering) related and has nothing to do with the area notion (for instance, the area of a forest). 
-Polygon, Multipolygon. Searching for “osm polygon” we can read two concepts, a polygon is a line object and a polygon is an area object. Apart from the logical conflict of the two concepts, notions like intersection, self crossing, overlap, size... have radically different interpretations in the concepts (with consequences for models, methods, error definitions and so on). When it comes to the multipolygon, closest to a kind of definition we may come in the line “In short, a multipolygon relation can have nay number of...”. What an object may have or don’t should come after the object’s definition. Otherwise, it is a definition by example which is (again) a serious methodological error.
These notes are just some of the issues that have motivated the suggestion. Of cause, some of them (but not all) may be based on my misunderstandings, English is not my native language.

Sent from Mail for Windows 10

From: dev-request at openstreetmap.org
Sent: 27 April 2018 14:08
To: dev at openstreetmap.org
Subject: dev Digest, Vol 157, Issue 12

Send dev mailing list submissions to
	dev at openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	dev-request at openstreetmap.org

You can reach the person managing the list at
	dev-owner at openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."

Today's Topics:

   1. Top Ten Tasks (Tobias Knerr)


Message: 1
Date: Thu, 26 Apr 2018 17:08:07 +0200
From: Tobias Knerr <osm at tobias-knerr.de>
To: dev list <dev at openstreetmap.org>
Subject: [OSM-dev] Top Ten Tasks
Message-ID: <efa7ee42-f11e-5609-3c0e-63f6ab46415f at tobias-knerr.de>
Content-Type: text/plain; charset=utf-8

Some of you may remember the OSM wiki's "Top Ten Tasks" page. It
provides an overview of widely anticipated feature ideas for OSM's
software ecosystem, which could have a major positive influence on OSM
if they were implemented.


The page has recently been updated by the Engineering Working Group
based on suggestions gathered from the community. Although such lists
are inevitably subjective, we hope that it can still be useful: As a
quick overview for new developers, a place to find relevant previous
work, and as an impulse to finally tackle some of these issues.

Here's the tasks we chose to include (in no particular order):

* Moderation queue
* Localized map rendering
* OAuth login to wiki
* OSM API deleted items call
* List of changeset discussions for a user
* Better tools for welcoming new users
* Area datatype
* Improved activity/history tab
* Clickable POIs on the frontpage
* Pedestrian and bike routing on areas

To people who have been part of the community for a while, the tasks on
the list should not come as a surprise. That's by design, as it wasn't
our goal to present controversial new proposals. If you're looking for
things to work on, these tasks would be essentially guaranteed to earn
you the community's gratitude. :)

Tobias (on behalf of EWG)


Subject: Digest Footer

dev mailing list
dev at openstreetmap.org


End of dev Digest, Vol 157, Issue 12

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180508/08f09571/attachment.html>

More information about the dev mailing list