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

[Mateusz Konieczny]

Mar 31, 2019, 5:40 PM by sandor...@gmail.com:

>
> >> 
>
>
> >>Can you link some objects that you consider as tagged in a wrong way and
>
>
> >>some similar ones tagged in way that you consider correct?
>
>
> >>Currently it is unclear to me what is the problem.
>
>
> >> 
>
>
> These notes have triggered my attention from the Re to my original mail. It 
> is hard to communicate if you really don not see the problem, though I think 
> you meant  something else. What more, whether the referenced issues are 
> problems or not, depends on the individual criteria. Anyway, I need to add 
> some notes and representative examples to clarify the dilemma: is the recent 
> practice referencing coastline objects from other objects correct or not?
>
>
> -Coastline object covered by a river > 
> https://osm.org/go/ZE6RWif_--?layers=T=22404175 
> >  . The object is in 
> the coastline data erroneously left there when the other object has been 
> moved out from the coastline data. This island in the river will never show 
> up in the maps unless it is moved out from the coastline and added to the 
> river data as a hole.
>
>
> -Similar example here > https://osm.org/go/0YQozaPCa?way=503202265 
> >  but with the additional tag 
> place=island. If a renderer assumes in addition that this place is an area 
> and renders the places it will properly show up un the map. But even then, 
> the object is actually never part of the river object. All tags should be 
> removed and the polygon should be moved to the river data as a hole.
>
>
Looks like something forgotten during creating 
https://www.openstreetmap.org/relation/3329487 

I now fixed this and yes - it made no sense here (it either should be within a 
water area represented
by natural=coastline or inner way of that multipolygon).

>
> -As I mentioned in the mail, we have similar issues here > 
> https://osm.org/go/55iNMeSpU-?layers=HD=482531057 
> >   with the 
> natural=land objects. Even if it is declared deprecated many years ago this 
> tag is still actively used and there is a large number of natural=land 
> objects in the source data. Note that logically the suggestion to use the 
> place=island tag instead is just an implicit reimplementation of the 
> natural=land objects.
>
>
I fixed this case. And yes, we still have many natural=land that should be 
removed. 
Fortunately this misuse of place=island is not supported by renderers, so it 
should discourage 
mistagging.

Is it possible to have correctly tagged place=island on a way that is not inner 
way of multipolygon
and without natural=coastline? Maybe validators can detect such cases as likely 
invalid.

>
> -There are also many coastline objects in lakes like here > 
> https://osm.org/go/JzzBB0Vmt--?layers=D=440616441 
> >  . The same comments 
> are valid as in case of rivers. The question whether this object is a lake or 
> river is something else.
>
>
For now I also updated it to be inner of the multipolygon.

>
> -A similar lake related example is here > 
> https://osm.org/go/e6GG5QpcE-?way=615864002 
> >  but the coastline object is 
> perfectly declared as a hole in a lake. Still there might be a problem. The 
> coastline tag will suggest that the object will primarily be processed in the 
> context of Planet land masses. And, because it is land-on-land it might be 
> easily removed from the coastline data. In the similar cases any tags should 
> be removed except the inner tag.
>
>
I removed natural=coastline.

>
> -Finally, the major issue that has motivated me to start this discussion, the 
> coastline referencing from objects like fiord/bay and sea. These, usually 
> monster sized objects, are difficult to understand. Why, who is using them, 
> what was the purpose to upload them? Even if someone uses them to see the 
> name variations or read the linked Wikipedia texts, the price is very high.
>
>
See also https://www.openstreetmap.org/user/imagico/diary/47432 
 and other imagico 
posts criticizing this tagging method from a bit different angle.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

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

[Mateusz Konieczny]

Mar 23, 2019, 7:31 AM by sandor...@gmail.com:

>
> 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.
>
>
Can you link some objects that you consider as tagged in a wrong way and
some similar ones tagged in way that you consider correct?

Currently it is unclear to me what is the problem.

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

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

[Gerd Petermann]

Hi Sandor,

for me the typical reason to use a coastline way in a multipolygon is this:
An island in the ocean with natural=bare_rock. The outline of the island is
described with the 
natural=coastline way and the multipolygon uses the same way with
role=outer.

The monster mp is probably wrong, AFAIK place=sea should be mapped as a
node.

Gerd



--
Sent from: http://gis.19327.n8.nabble.com/Developer-Discussion-f5233107.html

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

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

[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