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. Sandor.
Sent from Mail for Windows 10 From: [email protected] Sent: 27 April 2018 14:08 To: [email protected] Subject: dev Digest, Vol 157, Issue 12 Send dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: dev list <[email protected]> Subject: [OSM-dev] Top Ten Tasks Message-ID: <[email protected]> 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. https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks 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 [email protected] https://lists.openstreetmap.org/listinfo/dev ------------------------------ End of dev Digest, Vol 157, Issue 12 ************************************
_______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
