Czy ta Gryfa Pomorskiego musi być rozdzielona na dwie jezdnie? Skoro z każdej z jezdni można zjeżdżać na przyległe posesje, to aż się prosi aby zrobić tą drogę za pomocą 1 linii. Co daje to rozdzielenie oprócz dodatkowych skrzyżowań?
https://i.imgur.com/tojVtBa.png

Cześć, trochę napsułeś dróg rowerowych w Toruniu i zapomniałeś o temacie? Jak rozumiem Twoim planem jest rozdzielenie ciągów pieszo-rowerowych na oddzielne linie mimo braku ich fizycznego podziału. Nie wiem skąd masz pomysł, że takie rozwiązanie jest gdziekolwiek rekomendowane w Wiki? Wg tego co ja tam czytam, to jest raczej na odwrót:

'Należy zwrócić uwagę na fakt, że ten sposób tagowania w angielskiej wiki wywołuje kontrowersję, ponieważ nie istnieje fizyczne rozdzielenie między ścieżką rowerową a ciągiem pieszym'.

Dla przykładu ten węzeł node/11573972976 dodałeś w odległości 38cm od węzła node/11573941141

Później drobna edycja drogi staje się koszmarem, bo każdy taki węzełek trzeba dodatkowo edytować a niczego one nie wnoszą dobrego dla mapy.

Nie do końca jest to prawda. Oczywiście, że odzwierciedlamy rzeczywistość ale pewne fragmenty linii, które są niemal proste nie potrzebują węzła co 3 metry. Każdy taki węzeł później musi być przeliczany w routingach spowalniając wyliczanie trasy.

Odwzorowania krawężników można tworzyć innymi obiektami niż highway=* np. barrier=*, area:highway=*, landuse=*

Linie highway=* mają za zadanie oddać symbolicznie kształt drogi dla potrzeb routingu.

Cześć, na liniach highway nie ma potrzeby dodawać tak gęsto węzłów, bo nie są one do wyznaczania krawężników. W tej edycji pewnie kilkaset węzłów można spokojnie pominąć i sens dróg zostanie zachowany.
osm.wiki/Pl:Dobre_praktyki#Zachowaj_proste_linie_prosto

https://i.imgur.com/koEqVfc.png

Ta edycja była ogólnie prawidłowa i pożądana ze względu na to, że pasy ruchu były wrysowane oddzielnymi liniami.

Błędy tagowania już poprawiłem w https://overpass-api.de/achavi/?changeset=146940078

Cześć, ogólnie przyjęto w OSM, że place dla pieszych w takim stylu jak Ty tutaj utworzyłeś way/1244878846 są dopuszczalne aczkolwiek powinien on zawierać jeszcze tag area:highway=pedestrian.

Prawidłowo taki plac powinien mieć tylko klucz area:highway=pedestrian ale wtedy nie jest on renderowany na głównej mapie OSM.

Oprócz obszaru placu powinny być na mapę naniesione również trasy łączące poszczególne chodniki przy tym placu, bo bez nich nawigacje będą prowadzić pieszych po obwiedni placu.

Staraj się również nie łączyć linii highway z obszarami, szczególnie wzdłuż obszaru - tutaj chodnik ma wspólny fragment linii z placem:
https://i.imgur.com/czgWE9t.png

Tutaj jest changeset z moimi poprawkami: https://overpass-api.de/achavi/?changeset=146912342

Też pomyślałem o skrzyżowaniu T w tym miejscu i można to tak jszcze zmienić.

'Mapuj zakręty z odpowiednią liczbą węzłów' nie dotyczy skrzyżowań, bo to nie są zakręty chociaż czasami posiadają łuki jak w tym miejscu.

Link do węzła miałem popsuty. Powinien tak wyglądać:
node/1551110291

Cześć, proszę o nie dodawanie zbędnych węzłów na liniach highway. Ogólnie jeżeli prosta linia odzwierciedla układ drogowy, to dodatkowe punkty na niej są zbędne. Nie należy na pewno tworzyć highway w kształcie krawężnika, bo ta linia temu nie służy. Żadne cywilne nawigacje nie mają takiej rozdzielczości, żeby tak gęste punkty na drodze wykorzystywać a łączenie dróg na skrzyżowaniach łagodniejszymi kątami, które wynikają z zagęszczenia punktów mogą powodować, że nawigacje zamiast o manewrze skrętu poinformują użytkownika komunikatem w stylu 'trzymaj się prawej strony'.

Jedna z zasad OSM:
osm.wiki/Pl:Dobre_praktyki#Zachowaj_proste_linie_prosto

Dzisiaj np. poprawiałem taką sytuację przy węźle node/1551110291dpmv - jest to jedno z ekstremalnych rozwiązań na skrzyżowaniach ale nierzadko się takie coś spotyka.
https://i.imgur.com/rCbkMS1.png

Dzięki za odpowiedź. Ogólnie jeżeli prosta linia odzwierciedla układ drogowy, to dodatkowe punkty na niej są zbędne. Nie należy na pewno tworzyć highway w kształcie krawężnika, bo ta linia temu nie służy. Żadne cywilne nawigacje nie mają takiej rozdzielczości, żeby tak gęste punkty na drodze wykorzystywać a łączenie dróg na skrzyżowaniach łagodniejszymi kątami, które wynikają z zagęszczenia punktów mogą powodować, że nawigacje zamiast o manewrze skrętu poinformują użytkownika komunikatem w stylu 'trzymaj się prawej strony'.

Dzisiaj np. poprawiałem taką sytuację przy węźle node/1551110291 - jest to jedno z ekstremalnych rozwiązań na skrzyżowaniach ale nierzadko się takie coś spotyka.
https://i.imgur.com/rCbkMS1.png

Dzięki za poprawkę rond oraz tego wspólnego węzła. Teraz jest ok.

Jeżeli chodzi o relacje z restrykcją zakazu zawracania na zjazdach z ronda, to przy takim niedużym rondzie nie jest to może konieczne ale nieraz przy dłuższych zjazdach z ronda szybsze nawigacje potrafią zaproponować zawrotkę w takim miejscu (chyba OSMAnd tak robił).

Dzień dobry, czy jest dostępne jakieś źródło tej nazwy?

Dzień dobry, czy jest dostępne jakieś źródło tej nazwy?

Ok, zmienię na cycleway=track cycleway=track

Pewnie tak, albo podmienić na Orlenowskie.

osm.wiki/Pl:Dobre_praktyki#Zachowaj_proste_linie_prosto

Cześć,

Czy mógłbyś używać mniejszej ilości węzłów do tworzenia linii highway? Jeżeli fragment drogi jest niemal prosty (np. wjazdy na rondo), to nie trzeba highway=* układać zgodnie z krawężnikiem, bo nie do tego służy ta linia. W nawigacji nadmiar punktów na drogach wymusza więcej obliczeń. Jeżeli chcesz mieć kształt krawężnika w OSM, to używaj do tego klucza area:highway=*.

Dlaczego węzeł node/5060625085 zrobiłeś wspólny dla zjazdu i wjazdu z ronda? Routing będzie nieprawidłowo zliczał zjazdy z ronda dla kierowców wjeżdżających ulicą Wołkowyską od północy.

Przykład ronda ze zbędnymi węzłami na wjazdach oraz zaznaczony powyższy nieprawidłowy węzeł:
https://i.imgur.com/tF7cIzM.png

Sprawa jest wyjaśniona. Nie ma potrzeby dostarczać dodatkowych dowodów :) Dzięki za aktualizację danych.

Zmiana nazwy wydaje się prawidłowa - taka stacja jest do odnalezienia w serwisie www Orlen:
https://i.imgur.com/BOoerjF.png

Źródło danych zostało pewnie automatycznie wrzucone z załadowanych podkładów w JOSM - przy pojedynczej edycji czasami można zapomnieć o dopisaniu survey czy też innym źródle danych.

Zastosowań tego klucza man_made=chute_block nie jest dużo, bo może nie są to obiekty obligatoryjnie budowane przy tamach (tak mi się wydaje, ale nie jestem znawcą tematu).

Na pewno nie mogą to być obiekty typu waterway=dam, bo ktoś wyszukując tamy w bazie OSM dostanie w wyniku tysiące błędnych informacji z powodu tych bloków - tutaj koniecznie trzeba stosować zasadę 'Jeden obiekt, jeden element OSM' osm.wiki/Pl:Dobre_praktyki#Jeden_obiekt,_jeden_element_OSM

Wyszukiwanie barierek w OSM to mniej prawdopodobny scenariusz, który i tak wyrzuci wielkie liczby różnego typu danych, więc do klucza barrier można się zgodzić ale jednocześnie powinno dodawać się man_made=chute_block aby tag mógł się rozpowszechnić.