Absolutnie nie chodzi mi o dostosowywanie tagów pod nawigację. Po prostu dobrych kilka lat temu dojazdy do gospodarstw, przysiółków i wszelkich małych skupisk ludzkich, gdzie prowadziła droga bez asfaltu (nawet najbardziej podłego) były masowo tagowane jako track. Widocznie taka była konwencja, że track to po prostu droga polna, szutrowa, piaszczysta i już. Jak już wspomniałem jest to niezgodne (przynajmniej z angielskim) opisem tagu highway=track. I ja się z tym zgadzam. Droga do chałupy z numerem, w której mieszkają ludzie nie powinna być znakowana jako track. Dlatego warto coś w tej sprawie zacząć robić. W międzyczasie przetestowałem zapytanie do Overpass’a podane przez RicoElectrico. Rzeczywiście wyłapuje prawie wszystkie przypadki. Będę stosował.
Grelus, jeśli jest to ruina bez dostępu jakąkolwiek drogą lub wiemy, że nikt tam nie mieszka, to wystarczy tag validate:ants:pink=ignore i mrówka znika. Takich tagów jest ok. 250 w Polsce. Rysowanie drogi na siłę nie ma sensu. Chyba, że jakaś tam jednak biegnie, to wtedy rzeczywiście tag track może zostać.
Właśnie o takie ćwiczenie prosiłem powyżej. Spróbuj wbić w aplikację adres np. Mirowice 4 i zobacz, gdzie jest punkt końcowy nawigowania, a teraz porównaj to z układem dróg w OSM. Piszesz o “last mile” i właśnie tego last mile brakuje w Yanosiku, jeśli do zabudowania prowadzi track. Ale już np. do adresu Mirowice 15 Yanosik nawiguje pod sam dom, bo jest tam highway=service, service=driveway.
Akurat Yanosik nawiguje po drogach highway=service. Przykład powyżej.
W takim razie, dlaczego Yanosik nie może wyznaczyć dojazdu do miejscowości np. Bębnikąt? Albo wyznaczyć drogę przez ten parking kościelny. Inne nawigacje w tym przypadku chyba działają podobnie.
Yanosik nie prowadzi do m. Bębnikąt dlatego, że jest źle otagowany dojazd. Tracktype jest tagiem dla dróg highway=track. Tu jest unclassified. Ponadto, jak widać w wiki, grade 4 to już nie bardzo jest droga. Yanosik nie chce prowadzić kierowców po takich duktach. Prowadzi maksymalnie do grade 3. Niżej nie.
Dziękuję za wyjaśnienie.
Tracktype jest jednym z ważniejszych tagów opisujących drogi (nie tylko tracków) w przypadku kiedy nie ma trwałej nawierzchni w postaci litego asfaltu, betonu lub skały. Nie ma zaleceń niestosowania tracktype dla innych kategorii dróg.
W tym przypadku oczekiwałbym komunikatu informującego, z jakiego powodu droga nie może być wyznaczona, tym bardziej że taka reakcja nawigacji jest znana.
Nazwa jest, z powodów historycznych, nieco mylącą - ale tracktype można stosować do dowolnej drogi gruntowej.
No i tam jest surface=ground oraz tracktype=grade3, powinien więc prowadzić.
Załącz sobie starsze orto, nawet sprzed 10 lat, to w wielu przypadkach te wyrysowane drogi zobaczysz.
Czy mamy jakiś sposób tagowania wjazdu na parking, który Yanosik rozumie?
Dziś jechałem w miejsce, gdzie kilka wieżowców, o kilku adresach, przy różnych ulicach wręcz, ma wspólny parking. I fajnie by było, gdyby dało się tak oznaczyć wjazd na parking, żeby Yanosik wiedział, że pod ten adres jest wjazd z zupełnie innej ulicy, a nie kazał mi stawać na Marszałkowskiej koło komendy policji i ganiać dookoła budynku.
Tak myślę, że skoro mowa o różnych adresach, to pewnie jakoś relacją byłoby to najlepiej załatwić…
Niewiele możemy zrobić. Parking od Granicznej jest oznaczony jako prywatny i nie poprowadzimy na niego.
Wjazd na niego jest na tyle daleko od budynku, że nawigacja nie uzna tego miejsca za miejsce docelowe do adresu.
Mamy pewien pomysł ale to gigantyczny projekt i kosztowny, nie mający uzasadnienia.
Tak więc jeżeli ktoś miałby jakieś sugestie to jesteśmy otwarci.
No to wracamy na pole nr 1 - a gdyby tak ustalić jakiś sposób oznaczania tego w OSM i dorobić w Yanosiku interpretację tego?
Eleganckim rozwiązaniem byłoby użycie relacji, ale można też zrobić to prosto. Na podanym przykładzie, do tagów
addr:street=Marszałkowska
addr:housenumber=111A
dodać np.:
addr:parking_street=Graniczna //ten tag można by pomijać jeśli adresy są przy tej samej ulicy
addr:parking_number=4
i Yanosik na widok addr:parking_number używałby tych danych zamiast standardowych danych adresowych
Najchętniej widzielibyśmy taki mechanizm, że do poi parkingu dopisywana będzie informacja (osobny tag) dla jakich adresów jest on dedykowany.
Taką formę zapisu można zastosować również w przypadku tagowania bram/wjazdów na zamknięte osiedla żeby wskazywać do jakich adresów ta brama jest przewidziana. Oczywiście nie ma to sensu w przypadku grodzonego osiedla z jednym wjazdem.
Jeżeli możliwe byłoby wprowadzenie takiego sposobu oznaczania to bardzo sprecyzowałoby prowadzenie pod odpowiednią bramę czy do odpowiedniego parkingu. Yanosik chętnie włączy się w uzupełnianie takich danych.
A nie będzie problemu z interpretacją takiego tagowania?
Bo jeśli dodamy tagowanie do wjazdu np. do siedmiu budynków, to albo trzeba dać siedem zestawów tagów dla adresów, albo jedno pole z siedmioma adresami w postaci opisu słowno-muzycznego, który Yanosik będzie musiał rozebrać na składniki. A użytkownicy na mur-beton nie będą się trzymać jednolitego standardu i jakieś wypracowania tam będą…
EDIT:
A jeśli dodamy do wjazdu siedem zestawów tagów typu:
target_addr:1:street=, target_addr:1:housenumber=
target_addr:2:street=, target_addr:2:housenumber=
target_addr:3:street=, target_addr:3:housenumber=
…
to skąd Yanosik będzie wiedzieć w jakich tagach szukać adresu, żeby doprowadzić pod ten wjazd, a nie na tyły budynku pod właściwym adresem?
Natomiast dodanie do adresu namiaru na preferowany wjazd to jest jeden dodatkowy zestaw tagów adresowych.
Bardzo chętnie, tylko co w przypadku parkingów, które nie mają adresu? W jakiej formie dodamy namiar? Najchętniej widzielibyśmy współrzędne wjazdu na taki parking.
Jeżeli w tą stronę przyjęlibyśmy oznaczanie to analogicznie w przypadku adresów na grodzonym osiedlu dla określonych grup adresów wskazywane byłyby współrzędne konkretnej bramy?
Czy takie tagowanie jest w OSM możliwe?