Dobry projekt, fajnie że ktoś się za to wziął :) Kibicuję, aczkolwiek na tę chwilę dwie rzeczy mi się nie podobają: pierwszą jest ref=Wisła. Ref nie powinien być w ten sposób stosowany (https://wiki.openstreetmap.org/wiki/Key:ref) - on powinien dotyczyć indywidualnego kodu/numeru referencyjnego obiektu, o ile obiekt taki posiada. Tablice kilometrażu ich nie posiadają. Sposób w jaki używasz tu refa wygląda na swoisty sposób na spięcie pikietażu w relację dotyczącą danej rzeki. Druga sprawa to wartość not_installed, którą wprowadzasz do klucza seamark:distance_mark:category. Seamarki to, co do zasady fizyczne obiekty nawigacyjne obecne lub w jakiś sposób oznaczone w terenie. Jeżeli nie ma tablicy, to w istocie nie ma seamarka, więc takie tagowanie (które jak rozumiem ma wymuszać renderowanie kilometrażu na OpenSeaMap) zaprzecza samemu sobie i może wprowadzać w błąd - ktoś, będąc na szlaku żeglownym i widząc seamarka oznaczonego na mapie może chcieć go odszukać w terenie dla lepszej orientacji - i oczywiście nie znajdzie. Te dwie rzeczy powinny IMHO zostać ponownie przemyślane i/lub przedyskutowane ze społecznością. Robiłeś jakiś research jak to zostało rozpracowane na innych rzekach? Przy okazji, jak już robisz kompleksowo, to do tablic kilometrażu możnaby jeszcze dodawać tagi opisujące fizyczny wygląd tablic - tak jak przykładowo tu na Zalewie Wiślanym: https://www.openstreetmap.org/node/9098858363 i info o jednostkach (seamark:distance_mark:units=kilomtres) - w nawigacji wodnej, zwłaszcza morskiej, nie zawsze są one oczywiste.

Indeed, the result looks nice at first glance. However the way you obtain it is totally incorrect, at least where street areas goes.

Forcing the street areas to be rendered by using combination “highway=*” + “area=yes” is definitely the wrong approach, since “highway” objects corresponds to the road centerlines and they are navigable routes by definition. So used this way will cause weird and unpredictable behavior of routers which will try to navigate along such highway boundaries (an example).

This is typical tagging for the renderer (you sacrifice data quality just to obtain nice-looking picture) and should be replaced with the correct area:highway tagging scheme. Tagging railroad areas as natural=bare_rock has the same drawback - it does not refer to the reality.

So, concluding, micro-mapping - YES, but the data entered should represent features as they really are on the ground.

I must admit that You strongly inspired me to implement such an approach, regarding the name origins, in the neibourghood. Thanks for sharing the methodology, as I wasn’t even aware of the “name:etymology:*” tags. It’s only a pity that the aforementioned guidelines for Dusseldorf are only available in German, as they could give even more helpful information.

If I can have some small suggestion about the “old_name” plans for the future, I would suggest using the language namespace as a rule of thumb, i.e. old_name:de:1933. This is because country boundaries in the past very often were different than they are now and this prefix could be helpful to explicitly indicate the administrative affiliation of the place back in the days. Even if this is not applicable for all places, it would make the tagging scheme more versatile.