Najwyraźniej a:h staje się trendy, bo nie tylko jest już ponad 26 tys. zastosowań, ale także mapka rozkładu wygląda na dość równo rozsianą po Europie (która jest ogólnie najmocniejsza w OSM) i zdobywa przyczółki w reszcie świata:
Myślę, że fajnie by teraz było pociągnąć to tagowanie po najważniejszych trasach komunikacyjnych (typu np. primary w dużych miastach tudzież trasy łączące np. lotniska z centrum), bo mamy już chyba najważniejsze rzeczy poustalane i można bez większego ryzyka tworzyć takie “szkieletowe” sieci zamiast osobnych “wysepek”.
Czemu właściwie nie?
Rozwiązało by to obszary dyskusyjne przynajmniej. Na długich nitkach autostrady było by to zbędne bo możliwe do rysowania generycznie.
Pytanie do Was: Musimy zdecydować, jak postępować drogami dla rowerów jako obszary, ich skrzyżowaniami, śluzami rowerowymi, drogami dla rowerów i pieszych gdzie nie ma informacji po której stronie jest droga rowerowa a gdzie piesza.
Wydaje się lepsze jeśli bierze się tylko pod uwagę rendering a:h, ogólnie rzecz biorąc jest gorszym rozwiązaniem. Należy pamiętać, że OpenStreetMap nie jest projektem graficznym, tylko kartograficznym. Celem nadrzędnym jest użyteczność danych dla różnych zastosowań, a nie próba graficznego odwzorowania ortofotomapy.
Punkty K są bardzo dobrym rozwiązaniem, ponieważ wykorzystują już istniejące punkty sygnalizacji świetlnej, linii stop lub ustąp pierwszeństwa. Te punkty są wykorzystywane w nawigacjach np. do szacowania czasu przejazdu, mogą również służyć do renderowania linii na jezdni.
Projekt a:h nie jest osobną gałęzią OSM, tylko jednym z elementów. Z tego powodu powinien być spójny z całym projektem i jak najwięcej czerpać z danych, które już istnieją. Nie powinno się tworzyć udziwnień specyficznych tylko dla a:h tylko po to, żeby się ładnie renderowało.
Z innej beczki - zastanawiam się, czemu do tego schematu area:highway wcisnęliście tę nieszczęsną uznaniowość, czyli klasy dróg? Mam na myśli np. area:highway=tertiary, area:highway=secondary itd… Nie można było dać po prostu area:highway=yes + ewentualnie surface=?
Wiesz Zbigniewie, większość tak chciała. Na początku miałem właśnie propozycję a:h=yes, bo wychodziłem z założenia że te dane można wyciągnąć z drogi będącej na danym obszarze.
Ja myślę, że w a:h powinno być trzymane jak najmniej a dane pobierać z linii (klasa, nawierzchnia, itd.). Problem powraca. Darek-J, jak wygląda sprawa wyciągania danych z linii?
Jeśli będę rysował jakieś a:h to będę dawał właśnie area:highway=yes + surface. Nie widzę potrzeby klasowania obszarów, bo siatki routingu nie da się z tego zrobić.
Jeśli chodzi o wyciąganie danych z linii to próbuję to jeszcze trochę zoptymalizować, bo trwałoby to zbyt długo.
Mógłbyś napisać coś więcej o tym w jaki sposób obecnie renderujesz te warstwy? Ja do przekształcenia danych xml (.osm) na bazę sql używam osm2pgsql w trybie slim (potrzebuję tabel ze strukturą logiczną linii i węzłów). Dodatkowo korzystam z typu danych hstore, czyli baza musi to rozszerzenie obsługiwać. W jakiej formie tych danych byśmy potrzebowali aby je wyświetlić?
Dobrze by było jakbym sobie skonfigurował takie samo środowisko jak na serwerze, żeby mniej było roboty z dopasowywaniem skryptów.
Drogi dla rowerów jako obszary i ich skrzyżowania to przecież oczywiste:
-droga a:h=cycleway
-skrzyżowanie dróg rowerowych i żadnej innej o wyższym priorytecie:a:h=cycleway + junction=yes
Pod tym względem ścieżki rowerowe niczym się nie różnią od jezdni. (nawiasem mówiąc chodników też dotyczy ta sama zasada, łącznie z junction=yes)
Na śluzy nie mam w tej chwili pomysłu, ale być może analogicznie jak obecne a:h=bus
Ścieżki pieszo-rowerowe: dla linii highway dodać: lanes=2 + bicycle:lanes=no|designated + foot:lanes=designated|no
Przecież to wszystko już jest w specyfikacji, nie ma sensu “wymyślać koła” od nowa.
Zrobiłem taki na razie odcinek ze skrzyżowaniami: http://osmapa.pl/w/area/?lat=53.43036&lon=14.50665&zoom=16&ol=PEFGABR zapoznałem się tez z przykładem przygotowanym przez Javnika - widzę kilka błędów u siebie nad którymi będę musiał chyba popracować. Prosiłbym też o uwagi odnośnie mojej pracy na tym fragmencie mapy.
Co do dróg rowerowych to dobrze by były czerwone - co z kontrapasami rowerowymi na ulicach jednokierunkowych.
Jak rozwiązać sytuację kiedy: Szczecin - Brzozowskiego/Mickiewicza/Łukasińskiego - mamy jadąc z Brzozowskiego nakaz jazdy samochodem lewo/prawo a rowery także prosto z tego jednego pasa i wjeżdżają w Łukasińskiego pod prąd swoim kontrapasem, Na jezdni mamy jeden pas dla samochodów jeden dla rowerów (oba pod górę zgodnie z kierunkiem ruchu) i jeden właśnie kontrapas w dół od Mickiewicza. Z Mickiewicza także rowery jako jedyne mogą skręcić w prawo jadąc od Żołnierskiej: http://osmapa.pl/w/area/?lat=53.44317&lon=14.50169&zoom=18&ol=PEFGABR
Ale zdajesz sobie sprawę, że formalnie nawet jeśli jeśli DDRiP jest podzielona na część pieszą i rowerową, to piesi nie powinni, ale WOLNO IM łazić po części rowerowej i vice versa? Czyli powinno być:
Moim zdaniem, dużo by pomogło, gdyby a:h było powiązane relacją z linią, którą opisuje. Powinno to dramatycznie uprościć złożoność obliczeniową problemu.
Na mój gust, proposal nie będzie dobry, dopóki nie zostanie jakoś sprawdzony w boju - tj. przez nawigację semi-autonomiczną, czy inne takie. Do tego czasu wiemy tylko tyle, że ładnie to wygląda (czyli mapujemy pod renderer?)
Tu nie ma jeszcze co głosować, tu jest masa nieścisłości i straszny bałagan.
Zacznijmy od a:h=bus. Skoro jest highway=bus_stop to czemu dla zaznaczania zatok przystankowych używamy a:h=bus? Czy nie powinno być a:h=bus_stop?
highway=footway, footway=yes (czy highway=footway, footway=crossing) mapowałem trochę przejść, niestety metoda jest strasznie pracochłonna. A efekty wyglądają marnie. A h:footway przypominają zygzaki. Już wolałbym robić obszar, dać tagi typu a:h=crossing, footway=crossing, direction=*. Wyglądało by lepiej i robiło by się szybciej.
To samo tyczy się a:h=steps, mamy obszar a męczymy się z linią?
a:h=steps, depth_step=, direction=
Listę skrzyżowań bym rozszerzył:
Oprócz aktualnych junction=yes, roundabout, y_junction,
dodał by inne motorway_junction, mini_roundabout
czy
railway=level_crossing, ford=yes
Nie mówiąc o mniej popularnych, które nie przychodzą mi aktualnie do głowy.
Ronda. W każdy przykładzie widzę że rondo jest jednym obszarem. Jak może być jednym obszarem, skoro rondo jest szeregiem małych skrzyżowań. Przykład tu, gdzie mamy 8 punktów zatrzymania i 4 obszary a:h:crossing https://www.openstreetmap.org/#map=19/52.22982/21.01188
Jak dla mnie jest to dobrze zmapowane, tylko nico ma się do przykładu.
To i tak jest prosty przykład, bo to rondo https://www.openstreetmap.org/#map=18/52.25504/20.98286 mogło by się składać spokojnie z 8 obszarów a:h:crossing.
Przykład ronda. Podobna uwaga. Czy obszary nie powinny zaczynać się przed przejściami dla pieszych? Tak jak jest to w dwóch przykładach wyżej.
Korzystając z przykładów. Jak mapować mało przydatny odcinek jezdni? Patrząc na przykład z Aleją Wilanowską. Przed przystankami i za skrzyżowaniem, między krawężnikiem, a linią przerywaną jest kawałek jezdni, który nie pasuje ani pod a:h=emergency, ani pod a:h=*.
Opis powinien być rozszerzony też o inne tagi z highway:
a:h=escape
a:h=passing_place
a:h=turning_circle
a:h=turning_loop
itd. Można powiedzieć że to jest nie potrzebne, ale w takim razie co te tagi robią w opisie highway?
Tych co uważają że a:h jest mapowaniem pod render. Pieprzyć ich! Jeśli osm ma być popularne, to musi też ładnie wyglądać, to jest marketing. Większości i tak nie obchodzi funkcjonalność tylko wygląd. OSM jest produktem, który trzeba sprzedać. Jak chcemy sprzedać, to musi to łanie wyglądać. Jakby nie było tak ładnego renderingu jaki mamy, to a:h nadal by leżało i kwiczało, tak jak przez ostatnie 4 lata! To wygląd sprawił że wszystko ruszyło, a nie jakaś tam funkcjonalność.
