[Tagging] Way inside riverbank

Janko Mihelić janjko at gmail.com
Tue Apr 14 09:51:46 UTC 2015


Now I see you said that the direction is not necesarry. I can't agree with
this, it's a pretty important fact.

Anyway, I don't see a problem with you just importing incomplete data and
waiting for someone else down the line to complete the ways inside areas.

Janko.

uto, 14. tra 2015. 11:48 Janko Mihelić <janjko at gmail.com> je napisao:

> How do you know the direction of water flow if you don't have the way?
>
> Janko
>
> uto, 14. tra 2015. 11:45 Torstein Ingebrigtsen Bø <torsteinibo at gmail.com>
> je napisao:
>
>> Hi,
>>
>> I'm currently importing topological data of Norway to OSM. From the data
>> set we have riverbanks; however, we do not have the deepest middle way as
>> required by the wiki [1]. This middle line is therefore drawn manually.
>> This is a time consuming (and dull) job. For one municipal it takes around
>> 5-10 hours to draw all these lines, in Norway we have 428 municipals.
>> Drawing all these middle lines will slow down the time to import everything
>> dramatical. I am therefore curious of what is the benefits of this line. Is
>> it really necessary or is it a "nice to have"?
>>
>> Some disadvantages with this middle way are:
>> - The line add redundancy. I guess that many add this line such that it
>> is inside the multipolygon of the riverbank. Doing so the added data is
>> only the direction of the river. (Other tags may be added to the
>> multipolygon.)
>> - Sometimes people draw the line wrong or forget to update it when
>> updating the multipolygon. I have seen "middle" lines outside of the
>> multipolygon (either inside islands or outside of the multipolygon). This
>> gives false islands and splitting of islands when rendered.
>> - A similar way can be generated, if direction and deepest point is not
>> required. This comes as a fact of the first point and removes the
>> previously mentioned problem.
>> - For routing purposes this is not needed. (I have not seen any practical
>> marine navigation/routing implementations yet, either.) Routing algorithms
>> may also represent a riverbank as a node (or multiple nodes). The same
>> problem occurs for lakes where it is not required to have a middle way for
>> routing.
>> - The direction of the river is seldom used. The direction of a river is
>> seldom (or never?) rendered in any map. It is implicitly shown (e.g., by
>> contour lines).
>> - Specifically for the import of Kartverket N50 [2], this requirement is
>> slowing down the import process dramatical and import of other data of more
>> current value are delayed. This is therefore also a question of
>> prioritizing data to be imported.
>>
>> I therefore propose to make this middle way in riverbanks recommended
>> (when the deepest way is known), not required.
>>
>> [1] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>> <http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank#Old_tagging>
>> [2]
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/N50_import_(Norway)
>>
>> Best regards,
>> Torstein I. Bø
>> tibnor
>>  _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150414/8072ffb2/attachment.html>


More information about the Tagging mailing list