Re: [OSM-dev] dev Digest, Vol 175, Issue 10

2019-10-30 Thread SandorS
Just a short note/suggestion.
>>
>>- Create darker river-color for river & canal areas and waterway lines (#3930)
>>
This will overwrite the global ocean lighter colour when the two objects 
overlap.
So, maybe, the overlaps should be rendered using a blue shade between the two 
colours.
By the way, in any anti-alias rendering, you get this for free.
This model could help us to see how far the ocean reaches up a river when high 
tide and how long the river is when low tide.
Regards, Sandor.

Sent from Mail for Windows 10

From: dev-requ...@openstreetmap.org
Sent: 26 October 2019 13:04
To: dev@openstreetmap.org
Subject: dev Digest, Vol 175, Issue 10

Send dev mailing list submissions to
dev@openstreetmap.org

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
dev-requ...@openstreetmap.org

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

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


Today's Topics:

   1. OpenStreetMap-Carto release v4.24.0 (Joseph Eisenberg)


--

Message: 1
Date: Fri, 25 Oct 2019 23:40:13 +0900
From: Joseph Eisenberg 
To: dev@openstreetmap.org, t...@openstreetmap.org
Subject: [OSM-dev] OpenStreetMap-Carto release v4.24.0
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Dear all,

Today, v4.24.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

- Create darker river-color for river & canal areas and waterway lines (#3930)

The color of river, canal, ditch and drain waterway lines
and river and canal areas is changed to #8fcadd (Lch78,21,227)

- Fix rendering of water body labels (#3919)

Restores rendering of water body labels on points (node features)
Fixes rendering of natural=bay to use italic font at all z levels
Cleans up duplicate natural=strait code in water.mss

- Precedence of junctions over POIs (#3915)

Junction=yes, =motorway and man_made=bridge labels now render before
amenity-points
This prevents icons from blocking the display of these text labels

- Remove rendering of waterway=wadi (#3931)

The tag waterway=wadi is deprecated, suggested replacement:
waterway=river/stream + intermittent=yes OR natural=valley

- Move parking to amenity-points layers, change way_pixels limit and
initial zoom level (#3923)

Moved parking features back to amenity-points layers
Changed parking text intial zoom to z14, as planned in PR #3612
Change way_pixels limit for parking icon (750) and text (3000)

- Don't use classes anymore (#3912)
- Convert state & country layers to ST_PointOnSurface (#3920)
- Convert addresses to use ST_PointOnSurface (#3898)
- Apply bbox to part of "addresses" query (#3942)

The 4 changes above are needed to allow use of vector tiles
ST_PointOnSurface is used to generate a point for labeling
Classes are removed, replaced with the layer id

- Documentation updates (#3911) & (#3910), Code clean-up (#3899) & (#3922)

Document inner line rendering, update docker documentation
Clean-up text-placement / marker-placement, remove natural=marsh

Thanks to all the contributors for this release, including Adrian
Piotrowicz (@nexces), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.23.0...v4.24.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

We would love to have new contributors who might be interested in
solving some of the
many open issues.



--

Subject: Digest Footer

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


--

End of dev Digest, Vol 175, Issue 10


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Coastline as part of other object types?

2019-03-23 Thread SandorS
About two weeks ago I asked a similar question on the Help Forum without 
getting any help.
More precisely, my question was this 
https://help.openstreetmap.org/questions/68275/coastline-as-part-of-a-multipolygon
 .
Of course, the notes related to the example/illustration are fully correct but 
have very little to do with the dilemma. I am convinced that this forum/list is 
much more appropriate to repeat the former question in the link. Some more 
arguments.
Users, like me, when processing the OSM source data, we see a large/huge number 
of cases where coastline objects are used as parts of other object types like 
lakes, rivers, fiords, sees, borders and so on. The large number of cases 
indicate that this is more a practice now than accident. In my opinion a (very) 
wrong practice. Let me present some illustrative arguments.
-There is still a large number of small coastline polygons inside the coastline 
defined continents. As discussed many times, these coastline errors are 
actually missing islands in lakes, or rivers or even missing lakes. Just 
recently, many mappers compensate for these missing objects by uploading area 
objects like place=island/islet, or lake directly referring to a coastline 
geometry. So, we get coastline objects in none coastline objects. It is worth 
noting that even if in some maps these compensations look correct, essentially 
it is still wrong. A standalone coastline object tagged as place=island is 
never part of a river or lake data. Very similar issues happen with the large 
number of natural=land objects.
-Many of us remember the confusion created with bay/fiord area objects. 
Especially when rendering of these was a requirement. Creating a large bay 
object is not a simple exercise. These objects often contain thousands of 
holes/islands and then it is easy ti miss some hundreds. The prototype example 
of the confusion was the Bothnia bay. Lacily, someone with a strong sense 
simply removed the whole bay object. However, there are still many other large 
bay area objects, probably ignored by most of the map-makers in rendering. Yet, 
these objects add huge redundancy to the source data. 
-Finally, the crown example of the unreasonable “coastline in other objects” is 
the recently uploaded/edited Barents Sea. It is a multipolygon monster tagged 
as place=sea somewhere here 
https://www.openstreetmap.org/relation/9382300#map=4/77.15/39.29 
Any trials to see this object or its geometry in OSM maps (usually I check some 
40) fails on my (really) robust machine. But then, what was the intention, the 
purpose, of creating and uploading such a monster object. Just to see the name 
variations and have a Wikipedia link? I am not sure whether the geometry 
definition in this object is legal or not but anyway it just adds a huge 
redundancy to the source data.
In advance thanks for the help/answer, Sandor

Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Detect and remove sharp angle/spiky configurations on buildings

2018-10-18 Thread SandorS
Some days ago there was a question on an OSM forum whether such algorithm 
exists and used by some of the OSM users. Honestly I even did not know that 
such an issue exists and probably I am not alone. The reason to that is either 
that the spiky configurations are hardly visible in maps or that robust users 
handle them as a special case when process tiny outgrowths in their data 
generalisation programs. A closer look at the issue has shown that the issue is 
real and rather general. Spiky configurations exist on most of the area 
borders, roads, roundabouts and so on, there is a huge number of them and 
almost all are errors. To provide strong arguments about the former statement I 
have made an algorithm, a simplified version of the tiny outgrowths detection 
and removal, and applied the corresponding program to the OSM UK buildings. The 
algorithm on a certain abstraction level, its use and the processing results 
are described in details in an article here 
https://drive.google.com/open?id=1MaLdnSnc454xKjn3eL95vDQKeoIW8zGU . There are 
around 120K spiky buildings in OSM and out of these 2834 in the UK. In 
addition, the paper presents many examples how the spiky buildings look before 
and after the correction. Also, the paper contains links to the output data of 
the demo/test processing and how these could be used for visual analyses. So, 
if interested, enjoy the paper.
Regards, Sandor.


Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] coastline-osm2pgsql, once agai

2018-06-27 Thread SandorS
Sven:
>>
Thus it has been decided a long time ago, that land polygons are rendered from
shapefiles proven to be mostly correct (e.g. all continents do exist) and
up-to-date stuff produced by osm2pgsql.
If you like to render your own map you can easily produse matching data from
the same planet file.
The coastline processing toolchain is available here:
https://github.com/osmcode/osmcoastlin
>>
Martin:
>>
you can also get precompiled (fixed, splitted and not, 4326 and 900913)
water polygons, land polygons and coastline shapefiles here:
http://openstreetmapdata.com/
>>

Of course.
Actually, all examples of the erroneous small holes in the outer land polygons 
in the paper referenced from my mail are taken/based on the polygons referenced 
by Martin. In turn, these polygons are created by the procedures referenced by 
Sven. This really large number of issues is equally reflected in the mentioned 
water polygons as well, being splitted or not. 
But, please, do not miss the essential message related to the large/huge number 
of logical errors caused by the uncoordinated, unsynchronised editing and 
processing of the different object classes or feature layers. Mappers uploading 
a new hole/island in a river never know whether this should be done to the 
Global Ocean (coastline) as well. Likewise, when uploading a river section it 
is never checked whether parts of the existing river line run outside the river 
(creating imaginary islands) or not, the same when uploading forests over water 
areas and so on. These errors are passing most/all today publicly available 
error detectors, inspectors or logical preparation procedures. They are present 
in most of the publicly accessible OSM maps. Fortunately, the OSM source data 
has the potential for control and reparation of these errors and that was my 
main focus and intention by the “coastline-osm2pgsql” example in the mentioned 
paper.
Sandor


Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Coastline – osm2pgsql

2018-06-12 Thread SandorS
As I understand the two involved processes are independent and the results are 
just mixed together at certain moment during the map-making process. This 
independence causes several serious issues. Let me mention some. 
Assume the coastline polygons are in classes {Pi}, i=0,1,2, where any from {P0} 
is strictly outside any other polygons, while any from the class {Pj}, j>0, is 
strictly inside one and only one polygon from classes {Pk}, khttps://goo.gl/zJ4vsz. The {Pj} polygons, with just a few 
exceptions, in most of the OSM based maps are rendered incorrectly.
Strictly taken, from the topology point of view, any of the polygons {P1} is a 
hole in one of the {P0} polygons no matter orientation or additional tags. 
Consequently, all these holes should be rendered by blue/water colour (at least 
up to the border of eventually enclosed P2 polygons) and should never be 
visible in OSM maps as islands (missing islands).
Some map-makers use the orientation of the hole polygons in rendering. What 
ever the result is, strictly taken it is wrong. The requirement “...the land is 
on the left side and the water is on the right side...” cannot be valid because 
these polygons are on/inside the land masses.
Other map-makers use the tag place=island/islet in rendering forcing the 
corresponding P1 polygons to land areas even if the requirement “...piece of 
land that is completely surrounded by water...” can not be valid because any P1 
is in/on the land. By the way, the latest Wiki text related to the tag 
natural=land is just a confusing and out-watered version of the former document 
where the natural=land tag was declared obsolete and suggested “not to be 
used”. Now, it is absolutely legal to use natural=land tag on coastline islands 
though this is obviously redundant. What more, interpreting the tag 
place=island/islet as an area-qualifier makes it logically equivalent to the 
obsolete natural=land tag.
Basically  there are two possible ways to minimize the described erroneous 
consequences. 
1.Users, in their data preparation, should keep only the {P0} polygons for 
creating the coastline land (or water) masses. The rest of the coastline 
polygons should be merged to lakes or rivers related data for further 
processing.
2.Perform the procedure under 1. but as a one/time action directly in the OSM 
source data.
Finally, it is worth noting that the absolute number of issues/errors caused by 
the uncoordinated coastline and osm2pgsql processing large, it is relatively 
moderate. However, the case indicates that there is a whole class of 
issues/errors that is rarely discussed and highlighted. This class of errors is 
caused by independent updates and processing of different object classes/layers 
like lakes and rivers, rivers and forests, lakes and coastline, coastline and 
roads and so on. The number of these anomalies is six-ciphered and they are 
passing any publicly available error “detectors” and “inspectors” today without 
being detected. While many map-makers may tolerate these erroors (especially in 
the raster colour-image based mapping, after all the errors are just logical) 
the situation is quite different in the OSM based GIS systems and vector 
map-making. For illustration just look at the coastline and lakes mismatch here 
https://osm.org/go/cjf3ZjVB-?layers=D . Of cause, it is possible to find many 
explanations why this happens but these do not help. The errors are already 
there and they are there in many years. Sandor
If interested in more arguments, examples or details of correction models 
mentioned under 1 and 2, you may visit the white paper here 
https://goo.gl/ECKBGJ.
Sandor

Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] dev Digest, Vol 158, Issue 3

2018-05-16 Thread SandorS
>>
>>Date: Thu, 3 May 2018 08:28:09 +0300
>>From: Tomas Straupis 
  >>Anyways, there is no point of talking about who first, last, only
>>etc. All approaches using closed commercial software are pointless for
>>OSM - it cannot be reused. Everything can be done with open source so
>>that all code/algorithms are open and clear and there is no need to
>>pay piles of money for nothing.
>>
The statement was not quite wise and in some aspects it is wrong. Blindly 
trusting open source solutions is not the best thing for a newcomer especially 
not for a developer. By experience I know that sometimes a hint, a simple 
warning may help a developer to change his way of thinking. Besides, reading 
someone’s complex and complicated source (like the generalisation related 
source) is not just a simple exercise. If you ever wrote a complex basic sw and 
tried to read it after several months of brake then you understand what is my 
point.
The vector data generalisation issue was many times up for discussion on this 
forum too, in years. Because the vector map-making is not in the OSM’s strategy 
(an official authority answer from some times ago) the issue may be of interest 
only to private persons and institutions. However, some generalization issues 
yet my be of interest for OSM. After all, the majority of the source data has 
vector interpretation.
If we agree that a vector data generalisation is a procedure applied to a 
downscaled source vector data that performs vector smoothing and object (or 
part of object) collapse, then we may add some comments to the referenced mail.
Generalisation of questions like first, best and so on might be incorrect. For 
instance, the vector smoothing (sometimes called simplification) algorithms are 
known from the end 1980s and beginning of 1990s. In many countries at that time 
started raster-to-vector transformation of the scanned data layer foils of the 
mapping authorities. These vector smoothing algorithms radically evolved in 
years by experimental adjustments of many parameters. The best ones are those 
using dynamic smoothing criterion - when to replace a series of consecutive 
vectors with a resultant vector. Obviously, if a smoothing algorithm works well 
on cadastre/land-office data (usually long vectors without fine detail 
curvatures) it those not necessarily mean that it will work well on data with 
many fine curvature details like hydrographic data.
However, my major point here is to underline the big difference between doing 
data generalisation on OSM data and government institution data. Namely, the 
natural object fragmentation in the OSM source data inevitably causes data 
generalization problems, no matter what kind and how advanced the applied model 
is. Simply, without a defragmentation (the whole object reconstruction) in the 
data preparation a correct and efficient collapse strategy is impossible. To 
avoid repetitions from related discussions in the past I will just present some 
illustrative arguments. Most of the examples are screen dump images from today 
(it is an important reason why images and not links).
Object and part-of-object collapse is an essential part of any data 
generalisation (even in pure raster imaging). There are three basic strategies: 
size based, (object) class based and dynamic collapse. Because the size of 
fragments vary arbitrarily (mapper filings dependent), this strategy causes 
inacceptable brakes. For instance look at the Lena river here 
https://osm.org/go/9pITX--  and take one step zoom-out on the same. The same is 
present in many other OSM based maps like here https://goo.gl/2n2ycU and here 
https://goo.gl/FLMZbZ . In case of the class collapse strategy the usual 
asynchronous collapse may create confusion (large objects in one class 
disappear while small objects in another class are still present) like here 
https://goo.gl/Qkvybr and here https://goo.gl/XiSvc7. Finally, just to mention 
again, fragmentation is a vector smoothing killer. As a rule, you cannot  avoid 
the famous stripe effect. This was discussed  and illustrated many times in the 
past and it is difficult to avoid it even in a pure raster rendering. For 
instance look at some stripes here https://goo.gl/T2rUXf (note that the stripes 
are not border/solid lines) or the same stripes in other maps like here 
https://goo.gl/4DkBPb or here https://goo.gl/FcBmhb or even if you do not see 
it the stripe is there, just zoom in like here https://goo.gl/wbmCy5 or here 
https://goo.gl/VaDwaQ. 
In conclusion, applying data generalization on fragmented data is full of traps 
and usually ends up with errors. 
Regards, Sandor.



___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


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

2018-05-08 Thread SandorS
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: dev-requ...@openstreetmap.org
Sent: 27 April 2018 14:08
To: dev@openstreetmap.org
Subject: dev Digest, Vol 157, Issue 12

Send dev mailing list submissions to
dev@openstreetmap.org

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
dev-requ...@openstreetmap.org

You can reach the person managing the list at
dev-ow...@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 
To: dev list 
Subject: [OSM-dev] Top Ten Tasks
Message-ID: 
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-dev] VECTOR TILING in applications

2018-04-02 Thread SandorS
Tiling strategies and models are very well known and developed today. 
Especially uniform raster and vector tiling models in services where the tiles 
are pre-generated for efficient transmission and rendering. However, vector 
tiling is much, mush more than that. It is a powerful tool in many application. 
Let us mention some of the applications where a special vector tiling radically 
increases the efficiency. The examples are selected based requests/interest on 
OSM forums.
1. Detecting objects being inside a large polygon from a large set of objects. 
The issue is illustrated by OSM buildings and the polygon of Africa. If a usual 
“objects in polygon” algorithm manages the task, it will probably use very long 
time. Using an efficient vector tiling based algorithm the task can be 
accomplished just in several seconds.
2. When we do visual inspection of the result in 1. we can see that many 
buildings are partly in the sea. Whether these cases are mapping errors or not 
is irrelevant here but the issue triggers a task to detect buildings in Africa 
being partly in the sea for further actions. By using the usual filtering 
models it is almost impossible to solve this task or it will last even longer 
than in 1. The progressive vector tiling, the multitiling procedure helps to 
solve this task in seconds.
3. When RW area estimates are needed for large areas in a projection (e.g. 
Mercator) we inevitably meet the accuracy problem. We need to create area 
fragments and apply known position based correction factors. Here, again, a 
progressive tiling helps us to solve the issue on-the-fly.
4. Sometimes, when using Polygon Algebra based operations with area arguments 
the results might be so complex and complicated that we could never be sure 
that what we see is really what we wanted. For instance, if we need the 
intersection, the common area of several highly complex areas. In similar cases 
we need a reliable, simple and fast verification model. Vector tiling might 
provide an excellent validation model for these cases.
The mentioned applications are described in details here https://goo.gl/tuR5Wr. 
In the paper there are many supporting illustrations, examples and explanations 
as well. There are many hints for interested that they could repeat the 
experiments in an arbitrary programming language. The progressive tiling, the 
multitiling is also described and illustrated. Its comparison to the usual 
vector tiling shows its pre-dominance and the reality of the on-the-fly tiling 
in vector based GIS systems and vector map making. 
Regards, Sandor.

Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] THE OSM RIVER SYSTEMS

2016-07-30 Thread SandorS
Probably the most complete river systems that is possible to create from the 
OSM source data.
The subject has been discussed several times from my side but mostly inside the 
river area object class. At that time, I was just indicating cross water-area 
object class problems. Now, here is one option that resolves these problems as 
well. The complete river systems is generated from the latest OSM dump and can 
be downloaded from here:
https://drive.google.com/file/d/0B6qGm3k2qWHqNERVWmtVQUxYTUE/view?usp=sharing 
You can use it as you like but please respect the OSM licencing rules. Note 
that in this presentation there are no missing objects caused by area overlaps 
and different contents (holes in one are not in the other one consequently not 
visible in any vector mapping system), no brakes caused by tagging river 
sections as lakes and so on.
The following notes indicate the major processing skeleton and might be of 
certain interest for vector map-makers and those interested in heavy topology 
and polygon algebra issues. 
The extracted and used object classes are rivers (waterway=riverbank and 
natural=water + water=river), riverlines (waterway=river), lakes (natural=water 
and natural=water + water=lake) and the planet_land (the natural=coastline 
based land/water area objects).
All these object classes are passing a robust data-preparation-tool-chain 
ending with simple objects. During this procedure more than 100K consecutive 
replicated nodes are removed, more than 10K corridor and exact replicated 
polylines are removed and so on. In addition, for area object classes, two 
polygon classes are extracted: P0 not being inside any other polygons and P1 
all the other polygons. E.g. rivers_P0 are all the outer disjunctive polygons 
from the rivers simple area class while the rivers_P1 contains all 
corresponding holes, holes-in- holes, holes-in-holes-in-…  After this, I have 
added to the rivers simple area class the following correction areas:
-planet_land_P1 (1119) being inside at least in one of the rivers_P0 (120 
cases),
-planet_land_P0 being inside in one of the rivers_P0 (490 cases),
-circular/closed riverlines, longish areas statistically similar to riverbanks 
(4645 cases),
-longish lakes crossed alongside by a riverline (28692 cases) and 
-longish lakes neighbouring similar riverbanks (5560 cases).
The recognition algorithms and especially the heuristic criteria used are 
complex and based on many, many experiments and on large samples.
Now, the extended river area set is input to the create-area-coverage 
algorithm, which is doing defragmentation and creates a perfect coverage. 
Instead of river-fragments there are now river systems like the Mississippi, 
Amazonas, Danube, Volga… river systems presented as huge and complex 
areas/relations yet any in a simple area structure. These objects are, if 
necessary, input to a data generalisation (scale levels), tiling and so on. 
Unfortunately, there are several brakes on large river systems where obvious 
river sections are connected to large lakes incorrectly (yes I know, it is 
legal, but that is something else). These cases need manual intervention. This 
is yet to be done.
Finally, just to mention, the lakes, riverlines, the planet_land/planet_sea are 
corrected in the similar way. E.g. the planet_land now contains only simple 
areas (with no holes at all) and from there the planet_sea (which is now the 
Global Ocean) is created just in several seconds.
Regards, Sandor.




___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] OSM WATER POLYGONS – again

2016-06-11 Thread SandorS
To my great satisfaction and surprise, in the mail from about the start of 
March we could read in the
“dev Digest, Vol 131, Issue 25,” the issue “2. Upcoming change in files on 
openstreetmapdata.com”.
The changes relate to the creation of regular tiles for land and water 
coastline based large areas instead of splitting up these areas onto irregular 
rectangular partly overlapping areas. This issue has been discussed (on this 
forum) in years and I think this is now the right direction
Arguments for changes, as well as examples, we could find in the documentation 
accessible via 
http://blog.imagico.de/on-slicing-the-world-news-from-openstreetmapdata-com/ 
link.
As stated there, many application developers use these “water/land polygons” 
and the interest for them and for the tools used is constantly growing. With 
large respect for that and for the effort invested by the authors, I would just 
like to add some (constructive) notes that could maybe help faster and more 
robust accomplishment of the changes.
1. The (coastline) data/input validator you use still has certain holes:
- There are areas in/over areas. These are probably missing islands in lakes or 
rivers.
- There are still many replicated consecutive points/nodes on borders.
- There are many open land border polygons (especially those crossing the World 
border) in the   coastline.
- There are also certain misalignments between the land border polygons and the 
World border rectangle (especially the east/south/west border segments of the 
Antarctica). Just to mention some.
2. The planet_sea and its (regular) tiled representation:
- There is a doubt in the documentation about the creation of the planet_sea. 
This doubt is unnecessary as my experience shows. For instance, in the Mercator 
projection, we can generate a perfect planet_sea by inversion of the 
planet_land and we can do it in some seconds (on my laptop).
- The z9 “simplified” and “slicing” water polygons creation seams OK. However, 
from the methodology point of view the planet_land 
scaling-simplifying-inverting is never the same as scaling-simplifying the 
planet_sea. Especially, the differences are obvious on the World border. Note 
that the World border/frame issue is complex and almost all mapping systems 
have problems with it.
- The tile overlaps should be obsolete. Correct rendering and tile/frame 
matching is a basic application responsibility.
- Using higher scale levels (z9) for rendering lower scale presentations (like 
z2, z3…) has many aesthetic, topological and performance related issues.
- The tiling of water areas is probably obsolete. I would suggest considering 
of on-the-fly tiling.
3. The “generalized” zoom z8-z1 map versions. 
- All small area borders (islands) appear as oval and consequently larger.
 - There are many unexpected breaks and connections on area objects and 
consequently many lakes appear on fiords, islands on peninsulas and so on.
- The production of the zi data is rather complex and time-consuming. 
- The re-vectorised (z8-z1) versions of the polynomial approximations contain 
4-5 times more vectors than the corresponding versions created by a robust 
cartographic generalization.
Finally, if interested, you may find many arguments, details and examples in 
the white paper here:
https://drive.google.com/file/d/0B6qGm3k2qWHqd1UtcXNVWUVtN3M/view?usp=sharing
Regards, Sandor.


Sent from Mail for Windows 10

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev