Moje wątpliwości wzbudził sam pomysł użycia tagu związanego z adresem, bo w końcu to niegłupi pomysł żeby nawigować do konkretnego wejścia (np. umawiamy się ze znajomymi że spotkamy się przy tym konkretnym wejściu na plażę). Może warto wypracować wspólną metodę tagowania takich punktów, i w taki sposób, aby zadziałały one z programami nawigacyjnymi?
Czy coś się zmienia w renderowaniu domyślnej skórki? Chodzi mi konkretnie o dach Dworca Centralnego w Warszawie. Myślałem, że zniknął, ale nie - tylko się schował pod chodnikiem… Do tej pory na tej skórce drażnił mnie sąsiedni Dworzec Śródmieście, bo tam chociaż podziemne tory wyświetlają się poniżej chodnika, to nad trawnikami i nie pamiętam, jak było dotąd, ale teraz budynki na powierzchni gruntu znalazły się poniżej podziemnych peronów. Dotychczasowe problemy z interpretacją warstw się pogłębiły, czy coś przeoczyłem?
Dlaczego podczas wyszukiwania jakiegokolwiek adresu, w mieście Ostrów Wielkopolski, na openstreetmap.org, oprócz adresu pojawia się “stara przepompownia”?
Istnieje taki obiekt w mieście, ale dlaczego jest on dodawany do każdego wyniku wyszukiwania?
A ja mam pytanie o ref:nid. Teoretycznie powinien zawierać numer decyzji - różnie wyglądający ale zazwyczaj trzycyfrowy, czasem z literką i myślnikiem, czasem z ukośnikiem a pojawia się tam czasem numer ID z wikipedii z projektu Wikipedia Lubi Zabytki. Łatwo to rozpoznać bo są to sześciocyfrowe numery. Poprawiać na numery decyzji czy zostawić jak jest?
Wysłałem zapytanie lecz bez odzewu więc pytam tutaj. Co to za potworek na terenie Helu jako wielokąt złożony, od chyba nastu dni rzekomo importowany. Pod nazwą “Poland sea area”. Gdybym nadal mapował i dodał obszary Parku Krajobrazowego oraz Natura2000 podkładu nie byłoby chyba wcale widać, przynajmniej na ID. https://www.openstreetmap.org/edit#map=18/54.60607/18.80478 -wybaczcie, nie wiem jak inaczej na to wskazać-. Chyba dobrze byłoby dla następców jakoś to okiełznać.
To jest numer drogi, który powinien być w tagu “ref”. Problem dotyczy sposobu prezentacji mapy i programu nawigacyjnego a nie tagu “ref”. W OSM obowiązuje dobry zwyczaj, że nie fałszuje się danych pod rendering czy nawigację.
Tu nie chodzi o fałszowanie danych ale o podniesienie jakości tych danych.
Co innego jest tag, który ma realację między rzeczywistością a mapą, czyli: znaki orientacyjne → mapa, mapa → znaki orientacyjne.
Co innego jest tag, który działa między rejestrami urzędniczymi a mapą, czyli: rejestr → mapa, mapa → rejestr.
Wyświetlanie na mapie numeru 1179E, którego nie jestem w stanie zobaczyć w rzeczywistości w terenie jest wprowadzaniem niepotrzebnego chaosu. Renderer i nawigacja nie wiedzą tego, czy ten podany numer jest kategorii pierwszej czy drugiej (z podanych wyżej) ponieważ obecnie wszystko jest w jednym tagu.
Owszem, ten numer powinien być wprowadzony w danych mapy, ale w tagu, który ma mniejsze znaczenie niż tag przechowujący na przykład numer drogi krajowej.
Albo wprowadzić coś w rodzaju “podtaga” dla taga ref, który mówiłby czy wartość ref jest pokazywana na tablicach drogowych.
to jest główna bolączka renderingu robionego pod cały świat. Ja np. w swoich mapach zrobiłem regułę, że na drogach typu tertiary nie wyświetlam ref, bo w Polsce psu na budę to jest potrzebne przeciętnemu użytkownikowi. Dlatego dobrym rozwiązaniem jest, jak każdy kraj ma własną stronę z renderingiem dopasowanym do lokalnych uwarunkowań.
IMHO “ref” dotyczy tej drugiej opcji, czyli jest to numer z rejestru urzędowego. Fizyczne znaki orientacyjne mogą mieć osobne własne reprezentacje.
Renderer i nawiagacja wiedzą, że drogi tertiary nie mają tabliczek z numerem. Jeżeli decydują się je wyświetlać dla ulicy w mieście, to moim zdaniem jest to problem prezentacji a nie danych OSM.
Nie wiedziałem, że istnieją takie zasady.
MapQuest też prezentuje numery na drogach tertiary.
Cytując Cie jeszcze raz:
Staram się uczyć dobrych zwyczajów. Ale czasem nauka idzie ciężko. W szczególności, kiedy pooglądałem sobie punty poboru opłat na naszych autostradach. Tutaj to jest dopiero zafałszowanie danych pod rendering: