Co sądzicie o faszerowaniu obiektów na mapie dodatkowymi tagami, których wartością jest no i można powiedzieć, że jest ona domyślna?
Takie przykłady:
leśna droga w środku niczego z tagiem cycleway:both=no
przejście dla pieszych ze światłami, do niego doklejone już trzy tagi z no
Przystanek autobusowy, zwykły słupek z tabliczką rozkładu. 10 tagów, z czego 4 mają wartość no
Z jednej strony rozumiem, że ktoś był, widział i stwierdził że czegoś tam nie ma, ale z drugiej miejscami zaczyna to wyglądać jak “nie byłem w Rzymie, nie byłem w Paryżu, nie byłem w Londynie… Paaaanie gdzie to ja nie byłem!” Takie no można mnożyć niemal w nieskończoność, baza przy tym puchnie, a czytelność maleje…
Kiedy się nie dodaje tych tagów, to nie wiadomo czy obiekt zawiera podaną cechę czy nie. Po to istnieje wartość no dla większości tagów.
Jak można zauważyć, prawie wszystkie te tagi są dodawane przez StreetComplete, więc przy usunięciu ich aplikacja będzie od nowa pytać o ich dodanie.
Może dodawanie cycleway:*=no na ścieżce pośrodku lasu raczej nie ma sensu, ale dodawanie dodatkowych tagów na przejściach przez jezdnię i przystankach jest jak najbardziej przydatną informacją dla aplikacji opartych na OSM.
Pierwszy przypadek brzmi jak sprawa do zgłoszenia deweloperom StreetComplete. To nie jest ok, jeśli aplikacja próbuje wciskać na leśną ścieżkę tag z informacją o tym, czy z obu stron są ścieżki rowerowe, a tym bardziej, gdy ich nie ma, bo to nie jest normalne.
Wymowne jest to, że ok. 91% obiektów z tym tagiem ma wartość no xD https://taginfo.openstreetmap.org/keys/cycleway:both#values
Wypadało by jednak, by taka aplikacja weryfikowała potrzebę zapytania na podstawie obecnych tagów oraz analizy zdjęć satelitarnych. Mi się osobiście odechciało raz dwa bawić StreetComplete, jak ten powiela zapytania o podobne obiekty stojące obok siebie tylko dlatego, że są oddzielnymi obiektami, przez co miałem od groma punktów. Widoczność notek, które zawierają informacje które wystarczyły by apce do samodzielnego dokonania zmian w tagowaniu, wymuszając dokonanie tego przez kogoś innego, dodatkowo potęguje tę niechęć. A ktoś po prostu chce odhaczyć questa w apce i nie interesuje go, co dokladnie zostanie wysłane do OSM. Fajnie, że jest taka aplikacja, ale jednak za bardzo generuje coś, co można nazwać floodem.
Drugi i trzeci punkt są z kolei lepszymi przykładami tego, że OSM w wartwie metadanych jest bazą znanych danych tekstowych, będących w kontekście obiektu. Brak przycisku czy wibracji dla niewidomych na słupie sygnalizacji świetlnej na przejściu dla pieszych nie może być dodane jako domyślne, bo np. StreetComplete nie widziało by potrzeby zapytania, czy na pewno ten słup nie ma przycisku, bo zwrócenie uwagi, że stan z losowej obserwacji nie zgadza się z tym co jest na OSM leży całkowicie po stronie użytkowników.
Przechodząc natomiast do twojego problemu. Gdzie zauważasz problem z czytelnością? Aby ograniczyć puchnięcie bazy, trzeba dusić w zarodku masowe wtłoczenia bezsensownych tagów, co już omówiłem. Zapoznaj się z dokumentacją dowolnego obiektu, gdzie masz zastrzeżenia, że tych tagów jest za dużo. Pokazany przez ciebie przystanek autobusowy ma 10 tagów, natomiast taki obiekt może mieć wg Tag:highway=bus_stop - OpenStreetMap Wiki nawet 22. Problem byłby faktycznie wtedy, gdyby pojawiły się nadmiarowe tagi, bo jakaś aplikacja sobie ubzdura np. że skoro jakiś przystanek autobusowy ma tag shelter=yes, to zapyta się, czy to obiekt military=bunker, dodając i tak ten tag z wartością zależną od odpowiedzi.
Akurat Changeset: 157246529 | OpenStreetMap było dodane z CyclewayOverlay - warstwa ta pokazuje tam gdzie nie ma informacji, ale takie linie nie pokazują się jako zadania
highway=track nawet nie pokazują się jako brakujące dane (nie sa zaznaczone na czerwono)
See SC FAQ: Why does StreetComplete often tag the absence of features? and linked issue for details. I think that is makes sense in vast majority of the cases where StreetComplete Quests tag it (which is only a very tiny subset of all no values that might theoretically be tagged).
Well, it was not added by StreetComplete Quest (which only asks for cycleways where it makes sense, see here), but is manually inserted by that specific user using Overlay functionality.
Overlay in SC is something which works by manual user request, i.e. just like if the user opened iD or JOSM or Vespucci and added cycleway:both=no; so I would handle it in mostly the same way as if some user were using those other editors.
If some user adds cycleway:both=noconsistently on places where it does not make much sense (like tagging missing cycleway on tracks in forests), I’d contact them via Changeset Discussions and point out that why it is not needed / helpful, and ask what they meant to accomplish?
Maybe they instead wanted to indicate bicycle=no (e.g. if there is sign prohibiting bicycles from using that track?). Maybe it was a mistake and they wanted to tag nearby road and their GPS had weak signal. Maybe they were trying to game the gamification system. Maybe some forest tracks in their area actually have cycleways so they wanted to make a distinction? Or something completely different.
It’s impossible to know what was the case without contacting them.
I find those ones adding by StreetComplete Quests on crossings and bus stations very useful. Looking at taginfo for e.g. button_operated , one can see that it is 55% yes and 44% no values.
If nothing was tagged, one would not know which one of those it is, as missing value only means unknown (and the reason for missing tag is usually far more likely because “nobody mapped the feature in such detail yet”, rather then because “somebody though that no is implied default for everything, so doesn’t need to be mapped”).
For that first issue (Way: 912838234) of tagging cycleway:both=no on highway=track, that does indeed sound unneeded, even if user explicitly manually selected they wished to tag that.
If anyone knows of counterexample (i.e. highway=track which has explicit cycleway infrastructure that could be tagged with cycleway:*=lane/track/...), preferably with a picture (or an explanation), it would be appreciated if they can leave a comment (either here on that GitHub tracker). Thanks!
Dopóki ograniczamy się do tych sensownych właściwości to chyba jest w porządku.
Z drugiej strony ten jeden konkretny przykład pokazuje że dodawanie do highway=track tagu cycleway:both=no za wiele nie wnosi. Jak niby ma wyglądać ścieżka leśna z wyznaczonymi pasami dla rowerów?
Można by przejrzeć czy te przykłady są w ogóle poprawne: overpass turbo
Some involving bridge=yes (like e.g. 1115259556) are probably OK (bridge standards sometimes require that they always have a footway/cycleway), even if they are tagged highway=track (due to highway=track being on both sides of the bridge, it is common that just existence of the bridge does not change highway value).
Also, paved tracks (i.e. those tagged like highway=track + e.g. surface=concrete|asphalt like 127629041 might be fine.
For others, I agree - I have hard time imagining cycleway infrastructure on an unpaved track (thus my comment was a minute faster than yours )
Dziękuję wam za wypowiedzi. Może się z tymi światłami i przystankami rozpędziłem. Nie zamierzam z nikim w temacie walczyć, zaciekawiło mnie to raczej i chciałem poznać wasze opinie. Przy okazji dowiedziałem się skąd takie rzeczy mogą się brać. @dzamper No i właśnie pytanie co jest sensowne. Z jednej strony możemy założyć, że jeśli jakiegoś tagu nie ma, to nie mamy wiedzy na jego temat, a z drugiej jego wartość dla danego obiektu może być obligatoryjna, bądź oczywista. Przykład – shoulder:right=yes na drogach szybkiego ruchu. Tu z kolei użycie go z no na fragmentach A4 ma uzasadnienie, właśnie bo jest anomalią. Kiedyś trafiłem w jakimś lesie na piaszczyste ledwie widoczne w terenie drogi z tagiem noname=yes Niby wszystko OK, ale wyglądało tam dziwnie
)