No to musi być bardzo inteligentna nawigacja. Na razie Yanosik ma problem z placami (może już nie), a co dopiero takie złożone rzeczy. Yanosik w sensie przykładu dość znanej nawigacji, inne nawigacje mogą jeszcze mniej rozumieć. A na razie nie wiem nawet czy terminal wylotów, przylotów i cargo są inaczej tagowane - ale wątpię.
Wystarczy zamiast centroidu wybrać współrzędne miejsca, które najlepiej pasują. Wybrać ręcznie, umieścić w osobnej bazie, powiazać z obiektem w OSM jakoś -np. poprzez id lub nazwę i po wykonaniu importu z osm nadpisać.
Proste, skuteczne i nie trzeba się użerać z regułami OSM.
Ale nie muszą być inaczej tagowane, wystarczy że będą osobne obiekty. Użytkownik wybiera obiekt z zaproponowanej listy, jak wybierze to z “przyloty” w nazwie, to go pokieruje na przyloty.
Prawda, ale efektem ubocznym będzie tyle wersji mapy, ile jest nawigacji. A w sumie fajnie by było, gdyby mapa była jednak wspólna.
Bo to jest rozwiązanie dla nawigacji, którym nie chce się ustalać, jakie elementy są wewnątrz obszaru i robić opcji wyboru dla użytkownika.
Yanosik i tak robi teraz w ten sposób maxspeedy.
Tak, i wyrażałem już na tym forum opinię, ze lepiej by było gdyby raczej korygowali maxspeedy w OSM. I tak się nimi potem nie kierują za bardzo, tylko czasami przejazdów.
Doczytałem w wiki i w sumie wystarczyłoby rozszerzyć relację typu building o rolę parking. Rola entrance już jest, można też nawet według obecnej definicji zrobić osobne relacje dla przylotów, odlotów itd i je włączyć do ogólnej relacji budynku.
Co z lotniskiem, na którym nie ma żadnego budynku 
Może lepiej relacja site? Można by w niej umieścić też parkingi prywatne wokół lotniska nastawione na pasażerów. Z tego co widzę u siebie, są bardzo popularne.
To raczej nie będzie mieć również parkingów i doprowadzanie do najbliższego punktu na drodze będzie działać świetnie…
To może być w sumie lepsza propozycja, roboty z rozszerzeniem o dodatkowe role niewiele więcej (trzy zamiast jednej), a byłoby bardziej ogólnie.
Jeśli ma być ogólna, to koniecznie pogadajcie o tym na liście Tagging. Wydaje mi się to sensowny pomysł na rozszerzenie standardu tagowania lotnisk:
W ramach tzw. dekomunizacji ulic zmieniono w Wąsoszu ulicę Karola Świerczewskiego na Świętego Jana Pawła II. Uaktualniłem nazwę ulicy ok. 7 miesięcy temu. Jadąc ta okolicą we wtorek zauważyłem że na podkładzie w Yanosiku wciąż wyświetla się stara nazwa ulicy (załączam screena).
Stąd moje pytanie - jak długo trwa aktualizacja podkładów do Yanosika?
Da rady zapuścić w tej okolicy jakiś ręczny import, bo w międzyczasie zdążono już wymienić nawet tabliczki uliczne na nowe zatem osoba nieobeznana w tym terenie może być nieco wygłupiona przy wyszukiwaniu tam adresu…
Czy oni nie biorą przypadkiem kafli z Mapboxa?
Mapbox jest znany z tego, że obecnie strasznie przedłuża update danych. “Bo wandalizmy”. To oczywiście pic na wodę, coś tam sobie wykryją, ale ja nie widziałem, żeby w Polsce nam pomogli.
Cześć,
Z tego co zauważyliśmy korzystasz ze starej wersji mapy, która już od wielu miesięcy nie jest wspierana. Aby móc korzystać z aktualnych informacji, wykonaj następujące kroki w aplikacji:
Ustawienia > Mapa > Nowa mapa
Po włączeniu nowej mapy i ponownym uruchomieniu aplikacji, prezentowane informacje powinny być aktualne, zgodnie ze stanem w bazie OSM.
Ooo, to smuteczek… Raz że przyzwyczaiłem się mocno do starej wersji mapy a dwa że po przełączeniu na nową wersję mam w aplikacji niestety tylko czarny ekran 
No właśnie, czy można już pozdejmować nazwy z tych uliczek parkingowych? Yanosik powinien już umieć obsłużyć place jako takie od kilku miesięcy, a w wyniku aktualizacji Mapnika na serwerach fundacji nazwa placu już się odpowiednio wcześnie wyświetla - to wprawdzie efekt uboczny, ale może warto już przejść do nowej rzeczywistości, gdzie place=square jest normalnym elementem OSM:
Możemy, z dziką rozkoszą. I zobaczymy, kto jeszcze siedzi w jaskini i będzie narzekać…
Cześć. Odnosząc się do ostatniego zapytania o prowadzenia do terenów lotnisk, nie jestem pewny jaka jest decyzja
Właśnie o to chodzi, że chcemy to zrobić z godnie z regułami, aby i nasza i nawigacja OSM działały lepiej 
Spotkaliśmy się również z taką sytuacją:
Gdzie jak widzimy jedyny wjazd do osiedla jest zaznaczony na dole czerwoną linią, niestety nawigacje doprowadzają do najbliższego punktu.
Czy możemy przyjąć tą zasade?:
Wyglądało by to mniej więcej tak: (zrzut dla przykładu, póki co nic nie dodajemy)
Co sądzicie?
To jest inny przypadek - tutaj nawigacje powinny umieć wjechać na osiedle, nawet gdy jest brama i drogi wewnątrz są oznaczone jako private.
Być może rozwiązaniem byłoby traktowanie takich restrykcji jak access=destination.
To po co wtedy private?
Może tak - jeśli przy celu jest private, niech założy że nie jest i spróbuje wyznaczyć trasę, a pokaże jako koniec trasy punkt gdzie wjeżdża w private. Czy takie rozwiązanie ma jakieś potencjalne problemy?
Private wynika z reguł osm i oznacza, że dostęp jest limitowany do pewnej grupy osób, a przygodna osoba się do tej grupy nie załapie.
Natomiast nawigacja powinna wziąć pod pod uwagę, że jej użytkownik może należeć do tej grupy.
Do tego właśnie sprowadza się access=destination. Przy czym nie namawiam do zamiany private na destination w czasie importu, a jedynie na takim użyciu w trakcie wyznaczania trasy.
Jawne wskazanie punktu dojazdu do danego obiektu sprawia, że nie ma żadnych wątpliwości - chcę dojechać do bloku na zamkniętym osiedlu, muszę dojechać do bramy - tyle. Poniższy przypadek pokazuje, że nawet przy przeszukiwaniu access=private podczas wyznaczania trasy mogą pojawić się błędy i poprowadzić do budynku inna droga, która defacto znajduje się bliżej budynku.
