Bez przesady z tym fizycznym rondem - wyspa centralna ma mały rozmiar, jest w całości z nawierzchni, po której można przejeżdżać, a jej krawężnik ma wysokość około 0 cm, więc ja bym wyrysował jako minirondo.
Ja przyjmuję trochę inną definicję, niż jest na wiki: jeśli rondo jest na tyle duże, że normalny TIR objeżdża takie rondo normalnie dookoła nawet przy skręcie w lewo (bez konieczności korzystania z przejezdnego środka z kostki brukowej), to rysuję normalne rondo. Jeśli TIRy/autobusy muszą jechać przez środek, bo się nie mieszczą (rondo jest za małe), to minirondo.
Zdefiniuj pojęcie “mały”.
Ja już nie przerabiam wyrysowanego przez kogoś ronda, gdy się okazuje, że to minirondo. Zmieniam tam tylko wartość w junction z roundabout na mini_roundabout i dodaję oneway, jeśli nie było.
Tagowanie minirond to jest powracający problem w OSM. Parę tygodni temu poruszony na liście Tagging - z propozycją tagowania poprzez junction=mini_roundabout lub mini_roundabout=yes jako alternatywą dla highway=mini_roundabout. Nie było odzewu.
Fajnie, że wreszcie pojawiły się ograniczenia prędkości, ale niestety nie do końca to działa. Jeśli zamiast tagu maxspped używane są maxspeed:forward=* oraz maxspeed:backward=* to są one ignorowane 
Poza tym jak przejeżdżałem pod wiaduktem ekspresówki to na chwilę jako ograniczenie prędkości pojawiło mi się 120 km/h.
To nowa funkcja, z czasem zostanie dopracowana.
Rzuć linką, lecę się odzywać.
No właśnie kolejna nawigacja, która nie radzi sobie z maxspeed:forward/backward. Czy taki sposób zapisu jest trudny dla programistów nawigacji, że nie radzą sobie i trzeba liczyć, że może w kolejnej wersji będzie?
Chyba, że takich odcinków jest tak mało (również w sensie kilometrów), że nie opłaca się na razie w to bawić.
Znacie, jakąś nawigację, która to poprawnie rozpoznaje i wyświetla?
W nowej wersji Yanosika, w łatwy sposób, można dodawać informacje o prędkości. Wystarczy dotknąć ikonki znaku i wybrać właściwą ikonkę prędkości. Ciekawe czy będą to wprowadzać na bieżąco, bo trzeba zweryfikować, gdzie się kończy/zmienia ograniczenie, które wcześniej zaznaczyliśmy.
Nie o to chodzi, że jest trudny, tylko raczej o to, że taki Yanosik cały czas uczy się korzystać z danych OSM, albo inaczej mówiąc - ciągle wyłapuje niuanse OSM, by działało to wszystko jeszcze lepiej. OSM to jest szeroki temat i nie da się ogarnąć wszystkiego od razu.
Yanosik wypuścił dzisiaj aktualizację, dodającą informowanie o przekraczaniu prędkości. Funkcja działa w oparciu o maxspeed= z danych OSM i działa, gdy przekroczymy prędkość o 5 km/h (IMO trochę za wcześnie).
Jadąc na święta testowałem poprzednią nową wersję Yanosika i właśnie miałem pisać sugestię, aby znak ograniczenia był wyświetlany inaczej, jeśli przekraczamy prędkość (np. normalnie na szaro, a jak przekraczamy to w kolorze), a tu już jest odpowiednia funkcjonalność.
Ktoś ma pomysł, jak przekonać Yanosika, aby wypowiadał komunikaty normalnie (przez telefon) nawet wtedy, kiedy urządzenie jest połączone z zestawem głośnomówiącym z radia (bo wtedy ów zestaw działa mi tylko w trakcie rozmów telefonicznych, a komunikatów Yanosika nie słychać wcale - zresztą chcę mieć możliwość normalnego słuchania radia). Ustawienia z sekcji bluetooth wydają się nie działać w tym kontekście…
Szkoda, że danych o prędkości wprowadzonych za pomocą Yanoskia nie wprowadzą do OSM. link do forum
Więc jak ktoś woli aby wprowadzone przez siebie dane dostępne było nie tylko w Yanosiku to najlepiej robić to nadal przez OSM.
Szkoda, bo myślałem, że korzystając z Yanosika będę na bieżąco uzupełniał braki w OSM.
Oj trochę się podziało. Nie żebym się czepiał, ale mapując za pieniądze to bym się osobiście starał tak nie robić.
Niestety na stronie facebook-owej Yanosika też mi odpisali, że nie będą danych o ograniczeniach prędkości zbieranych przez aplikację Yanosik nanosić do OSM. Przydałaby się w mojej ocenie jakaś reakcja ze strony Stowarzyszenia OSM Polska w tej sprawie, żeby jednak zmienili swoją decyzję. Przecież z danych osm korzystają przy swojej nawigacji, swoją bazę z danymi o ograniczeniach prędkości także tworzą m.in. na podstawie danych OSM, więc te dane dotyczące ograniczeń prędkości zbierane przez Yanosika także powinny się znaleźć na OSM, dlatego uważam, że warto zgłosić się do nich z uwagą mającą na celu ponowne przeanalizowanie tej decyzji o nie umieszczaniu tych danych na OSM.
A czy w tej chwili dane o ograniczeniach prędkości z OSM są prezentowane tak samo w aplikacji jak dane z Yanosika ?
Ale to chyba nie jest kwestia decyzji (tj. dobrej woli) Yanosika. Licencja OSM chyba wymaga tego, żeby te dane udostępnili?
O ile dobrze zrozumialem, takie EBdirigo uzupelnia dane o ograniczeniach na OSM.
Dane o ruchu, czy ostrzezenia o przeszkodach to osobna bajka i Yanosik moze z nimi robic, co chce (aczkolwiek sadze, ze zyskali by na wymianie z innymi systemami opartymi na OSM), ale ograniczenia sa w OSM i wypadaloby je uzupelniac na OSM.
To dobrze, że Yanosik korzysta z osm. Sądzę jednak, że wzajemna współpraca wyszłaby każdemu na dobre. Widać niestety, że Yanosikowej aplikacji nie można traktować, jako narzędzia do zbierania danych na potrzeby osm. Trochę szkoda, bo instalując Yanosika miałem nadzieję, że właśnie w ten sposób będzie go można wykorzystać, przy okazji wspomóc Yanosikową społeczność danymi z trasy. Ostrzeżenia o patrolach i nawigacja były dla mnie sprawą drugorzędną.
Jeśli Yanosik miksuje dane o prędkościach z OSM ze swoimi, to te drugie musza zostać udostępnione.
Jesli korzystają tylko ze swoich, to nic nie muszą.
Na forum yanosik pisze tak:
“Zbieramy dane z aplikacji, GDDKiA oraz z OSM i tworzymy własną bazę ograniczeń prędkości.”
To chyba muszą?