Re: [OSM-talk] A forest ... what?

[Martin Ždila]

On Mon, Apr 10, 2017 at 12:27 PM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

>
> 2017-04-10 12:16 GMT+02:00 Warin <61sundow...@gmail.com>:
>
>> In JOSM there is a tool to simplify ways with errors of less than 3
>> metres in order to reduce the data base size.
>> This amount of error is judged acceptable.
>>
>

there is also Simplify Area plugin which I am mostly using on buildings
with redundant nodes.

https://github.com/openstreetmap/josm-plugins/tree/master/simplifyarea


-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A forest ... what?

[Martin Koppenhoefer]

2017-04-10 12:16 GMT+02:00 Warin <61sundow...@gmail.com>:

> In JOSM there is a tool to simplify ways with errors of less than 3 metres
> in order to reduce the data base size.
> This amount of error is judged acceptable.
>


you can use the algorithm with any acceptable error margin set, but please
not on _other_ people's work. It will lead to problems for the angles (e.g.
sharp turns) and generally only regards distances and not angles. The
algorithm doesn't know about crossing ways which still have to be mapped
(and which may make currently superfluous nodes still reasonably placed).
The 3m default in JOSM (or is it less) does not mean it is generally
accepted to simplify ways with this setting and re-upload them. If you do a
good manual drawing, you won't improve anything by applying douglas peucker
to the result (the algorithm used in "simplify ways"), all you will do is
introduce problems, maybe tiny and in few occassions, but still problems.

Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A forest ... what?

[Warin]

The subject question ...

To me:

An OSM forest is what?

OSM uses landuse=forest ... so the and is used for forestRy (note the R) 
... to grow trees and use them for some human productive activity ... 
like eventually making paper.



An OSM wood ?

Here OSM uses 'natural=wood' so a place where a wood occurs naturally .. 
but OSM also uses the key 'natural' for things that are impacted by 
humans .. so 'unnatural' too.
I'd much rather that OSM would use 'landcover=wood' as that is much 
clear as to what is mean .. what is is this area covered with? Trees.


-
As for crossing polygons/ways ...
In JOSM there is a tool to simplify ways with errors of less than 3 
metres in order to reduce the data base size.

This amount of error is judged acceptable.
So using that 3 meter error as being acceptable many crossing things can 
be eliminated ... I use errors of < 0.4m.
While technically incorrect, misleading and wrong... the impact on the 
practical map?

Very few people will find it.
The number who would have a problem with it will probably need to use a 
legal source anyway.


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

Re: [OSM-talk] A forest ... what?

[Martin Koppenhoefer]

2017-04-10 10:45 GMT+02:00 Walter Nordmann :

> Hi sandor:
>
> to long - did not read it.
>



+1, make it a diary entry and provide a management summary here ;-)

http://www.openstreetmap.org/diary

Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A forest ... what?

[Walter Nordmann]

Hi sandor:

to long - did not read it.

keep it simple please,

regards
walter


Am 10.04.2017 um 10:04 schrieb Sandor Seres:


Three weeks ago I posted some multipolygon related notes. This mail 
is, in a way, an addition to that former mail.


My first note was triggered by some user worries about poorer maps if 
they use data from the osm2ogsql preparation. Dropping “broken 
multipolygons” will result in many and large empty/white places with 
long reparation period. Strengthening the preparation on the subject 
might be a better option in my opinion (I know, I was there). However, 
at the end, how this subject will be handled is perfectly up to the 
authors of the osm2pgsql application.  Users starting from the OSM 
source data will not be affected whatever strategy will be selected.


The second note was related to the mass/programmatic correction of the 
source data. This could have dangerous/damaging impact on many OSM 
users. Fortunately, the replays say that programmatic correction is 
not a strategy in the “fixing multypolygons” actions. I have mentioned 
the “self-crossings” issue which is not an error for many users 
(depending on what notion interpretations and tools one uses). To 
clean up the confusion, this note needs some additional words. Assume 
someone would correct all polygon self-crossings in the source data. 
Assume, the selected fixing model is the popular dividing model (the 
polygon is divided into new polygons between self-crossings). The 
“fix” will be correct but the consequences damaging. Namely, in 
scaling and rendering the new small areas quickly  reach 
ignorable/collapsing size causing brakes. Here, it is worth noting, 
that the self-crossing issue is a topic in the modern vector based 
digital mapping even if all self-crossings are somehow resolved in the 
source data. Namely, while scaling and doing edge-smoothing in data 
generalisation, self-crossings on thin area sections (like fiords, 
peninsulas, rivers and so on) are unavoidable and dividing produces 
many tiny areas. High fragmentation of the source data and freedom of 
tag selection (river sections tagged as lakes) make the issue even 
worse. Just look  at the Amazonas river-system rendering from a 
popular vector map-maker her http://goo.gl/bT1Bu9


(the screen dump is from yesterday, from a demo system, in roughly 
1:6.7 mill scale). There are really many and large unacceptable 
breaks. However, from the same data source, using topology geometry as 
suggested in my former mail, it is possible to create a compact 
minimal coverage for the same river system like this 
https://goo.gl/pNQwDm . Note that the river system her is one simple 
area (one outer and many inner borders never touching each other) from 
Peru to the Atlantic. To be on the fair side the last image should be 
rendered from a zoom/scale level that corresponds to the 1:6.7 mill 
scale. This is done here https://goo.gl/eaAWNy and the zoom level 
contains approximately 250 times less nodes than the level used for 
the previous image. The area connectivity is still perfectly preserved 
and the image is much cleaner in this scale extract. Finally, if a 
user is still insist on fixing the polygon self-crossings, exchanging 
 and reversing the poly-lines between two consecutive self-crossings 
(eventually just reversing the end loop after a self-crossing) should 
be a much better strategy.


However, the third, the last note was my major point. Just to remind. 
There is a large set of area related anomalies caused by relations 
between objects from different classes (between seas, forests, lakes, 
rivers…). The extent and complexity of this set is far beyond the 
“broken polygons” issue  and should be more in the development focus. 
Even if the areas/multipolygons within a class are in perfect 
conformity with the strongest OSM and OGC rules, still these anomalies 
are there, though sometimes hardly visible in maps. Therefor many 
map-makers tolerate them but in GIS systems they appear as strong 
limitations and should not be tolerated. In the former mail  I have 
presented many examples and some hints how these anomalies could be 
resolved. Unfortunately, the discussion went in a wrong direction, 
about the Scandinavian forests, while the region selection is 
irrelevant for the subject. To avoid much repetition I will present 
further examples without details in procedures. The illustrations are 
from the area of Japan (one of the best mapped areas) and the source 
is the standard OSM dump from some week ago.


Honestly, I am not sure what a forest is. More precisely, if you ask 
me – I know, if you ask me to tell what it is – I do not know. 
However, among the many interpretations, I am closest to accept the 
topology interpretation of the notion. The green area in the front 
page map (or in other OSM based maps) usually covering the areas 
tagged as forest and/or wood. In Japan, as everywhere, forests are 
uploaded highly fragmented, they overlap 

[OSM-talk] A forest ... what?

[Sandor Seres]

Three weeks ago I posted some multipolygon related notes. This mail is, in a
way, an addition to that former mail.

My first note was triggered by some user worries about poorer maps if they
use data from the osm2ogsql preparation. Dropping "broken multipolygons"
will result in many and large empty/white places with long reparation
period. Strengthening the preparation on the subject might be a better
option in my opinion (I know, I was there). However, at the end, how this
subject will be handled is perfectly up to the authors of the osm2pgsql
application.  Users starting from the OSM source data will not be affected
whatever strategy will be selected.

The second note was related to the mass/programmatic correction of the
source data. This could have dangerous/damaging impact on many OSM users.
Fortunately, the replays say that programmatic correction is not a strategy
in the "fixing multypolygons" actions. I have mentioned the "self-crossings"
issue which is not an error for many users (depending on what notion
interpretations and tools one uses). To clean up the confusion, this note
needs some additional words. Assume someone would correct all polygon
self-crossings in the source data. Assume, the selected fixing model is the
popular dividing model (the polygon is divided into new polygons between
self-crossings). The "fix" will be correct but the consequences damaging.
Namely, in scaling and rendering the new small areas quickly  reach
ignorable/collapsing size causing brakes. Here, it is worth noting, that the
self-crossing issue is a topic in the modern vector based digital mapping
even if all self-crossings are somehow resolved in the source data. Namely,
while scaling and doing edge-smoothing in data generalisation,
self-crossings on thin area sections (like fiords, peninsulas, rivers and so
on) are unavoidable and dividing produces many tiny areas. High
fragmentation of the source data and freedom of tag selection (river
sections tagged as lakes) make the issue even worse. Just look  at the
Amazonas river-system rendering from a popular vector map-maker her
 http://goo.gl/bT1Bu9

(the screen dump is from yesterday, from a demo system, in roughly 1:6.7
mill scale). There are really many and large unacceptable breaks. However,
from the same data source, using topology geometry as suggested in my former
mail, it is possible to create a compact minimal coverage for the same river
system like this    https://goo.gl/pNQwDm . Note that
the river system her is one simple area (one outer and many inner borders
never touching each other) from Peru to the Atlantic. To be on the fair side
the last image should be rendered from a zoom/scale level that corresponds
to the 1:6.7 mill scale. This is done here  
https://goo.gl/eaAWNy and the zoom level contains approximately 250 times
less nodes than the level used for the previous image. The area connectivity
is still perfectly preserved and the image is much cleaner in this scale
extract. Finally, if a user is still insist on fixing the polygon
self-crossings, exchanging  and reversing the poly-lines between two
consecutive self-crossings (eventually just reversing the end loop after a
self-crossing) should be a much better strategy. 

However, the third, the last note was my major point. Just to remind. There
is a large set of area related anomalies caused by relations between objects
from different classes (between seas, forests, lakes, rivers.). The extent
and complexity of this set is far beyond the "broken polygons" issue  and
should be more in the development focus. Even if the areas/multipolygons
within a class are in perfect conformity with the strongest OSM and OGC
rules, still these anomalies are there, though sometimes hardly visible in
maps. Therefor many map-makers tolerate them but in GIS systems they appear
as strong limitations and should not be tolerated. In the former mail  I
have presented many examples and some hints how these anomalies could be
resolved. Unfortunately, the discussion went in a wrong direction, about the
Scandinavian forests, while the region selection is irrelevant for the
subject. To avoid much repetition I will present further examples without
details in procedures. The illustrations are from the area of Japan (one of
the best mapped areas) and the source is the standard OSM dump from some
week ago.

Honestly, I am not sure what a forest is. More precisely, if you ask me - I
know, if you ask me to tell what it is - I do not know. However, among the
many interpretations, I am closest to accept the topology interpretation of
the notion. The green area in the front page map (or in other OSM based
maps) usually covering the areas tagged as forest and/or wood. In Japan, as
everywhere, forests are uploaded highly fragmented, they overlap in the most
strange combinations, the same with river and lake area objects. The most
common case is when borders of