Zrobiłem tak kawałek pasa na próbę renderu no ale nie można tak rysować tak wiec nawet nie ma czym sie chwalić na zewnątrz bo jeszcze maperzy tak wrysują.
Nie widzę powodu aby nie renderować pasów rowerowych skoro renderujemy pasy awaryjne wyłączając je z powierzchni jezdni choć oddziela je tylko linia.Podobnie oddzielamy zatoczki autobusowe czy pasy autobusowe, choć nie odcinają sie tak jak czerwona infrastruktura rowerowa.
W liniowym rysowaniu przyjęto co przyjęto (np głupie liczenie pasów) i jeszcze żaden render nie wymyślił jak to zwizualizować.
A:h jest wieku niemowlęcym co można by je wykorzystać aby na stale oddzielić powierzchnie pasów rowerowych o reszty.Skro renderujemy często mikroskopijne emergency (SUR) to dlaczego nie renderować śluz i pasów gdy często skrzyżowanie ma połowę powierzchni zamalowanej na czerwono?
Który render ma wykorzystać liniowe mapowanie albo powierzchniowe skoro my pasów i śluz nie wrysowujemy?
Zatem ktoś musi zacząć renderować aby mapowali powierzchniowo bo OSM n zalecało śluzy mapować jako punkty wiec żaden render tego nie przeskoczy.Tyle już mamy osiągnięć z a:h że pozostąlo wstawić coś więcej niż tylko ddr.Dlaczego ddrip renderujemy jak chodniki skoro mamy je wrysowane i otagowane?
Ddr-y się tak ładnie renderują, że nie widzę pwodu dlaczego tam gdzie przechodzą w ddrip mają być dziury w infrze na mapie?
Nie o tym mówię.Tłumaczyłem ci już kiedyś że nie chodzi o te linie P11 i piktogramy roweru tylko o czekoladowo-czerwony render powierzchni przejazdów a Ty dalej pokazujesz przejazdy w kolorze czarnym.
Pisałem wyraźnie dodaj do obwodu tag bicycle=yes a zobaczysz efekt.
Też Ci kiedyś uwierzyłem, że to przestało działać ale działa i świetnie wygląda.
A teraz piszesz “pierwsze słyszę”
Zobacz to skrzyzowanie Widać, że zapomniałem tam dwóch przejazdów i jednej zebry.Jeszcze nie robiłem inwentaryzacji, bo usuwam błędy
Mam propozycję: skoro są dodatkowe pomysły pozwalające uzupełnić, ulepszyć rendering area:highway, to dodawajcie to do tej strony. To nie jest moja prywatna własność a każdy zdrowy rozwój potrzebuje pomysłów wielu ludzi.
Możemy podrzucać pomysły, ale czy jest osoba gotowa je wdrażać?
PS. Nadal jestem zainteresowany wspólnym działaniem nad testowaniem potencjalnych rozwiązań, które pozwalałyby na kompletne wyświetlanie obszarów mostów, tuneli czy też obiektów building=roof. Czy jest tu ktoś, kto mógłby pomóc w tej kwestii bardziej, niż poprzez dyskusję na forum?
Myślę, że to ważny temat do poruszenia na Walnym na które Cię tomku zapraszam.
Tak nawiasem: ten patent pokazuje możliwość zastosowania konturów drogi (lub pasów jezdni) do nawigacji autonomicznej: https://www.google.ch/patents/US8948954
Kontur drogi może być rozpoznawany przez pojazd co oznacza konieczność analizowania ogromnej ilości danych w przeciągu sekundy lub porównywać bazę danych z obrazem z kamerki a to drastycznie zmniejsza wymagania systemowe.
Czy jest mozliwość rozbudowania wizualizacji marimila o resztę infrastruktury rowerowej jak np śluzy czy pasy rowerowe?
Czy można wizualizować dddrip ?
Musimy to wspólnie przedyskutować na spotkaniu. Prawdopodobnie tak, technicznie nie ma problemu, tyle że to jest czas wolny Marimila, być może ktoś mógłby mu w tym pomóc?
Jak jest z odświeżaniem wizualizacji a:h? Pracowałem ostatnio nad Dziwnowem i jakby się część danych zawieruszyła albo coś bo mam masę dziur a sprawdzałem to teoretycznei a:h kompletne a jednak część się nie renderuje :(. http://osmapa.pl/w/area/?lat=54.02159&lon=14.74354&zoom=17&ol=QqABoPREFG
Czy tego, khem, wielowielokąta nie ma potrzeby rozdzielać na kilka obszarów? Inaczej mówiąc: czy takie przerobienie wcześniej zmapowanego jako multipoly obszaru chodnika na a:h jest wystarczające? Bo jeśli takie załatwienie sprawy jest OK, to ja zaraz…
@d3mol3k: dołączam się do pytania, w Poznaniu ta sama sytuacja @rmikke: a niby po co rozdzielać to na kilka części, czyżby tylko po to żeby nie było wielokątem złożonym? chodnik okrążający kwartał kamienic to nic innego jak chodnik z dziurą w środku (pierścień), więc dzielenie tego na części tylko po to żeby przestało być multipolygonem to jakieś kombinowanie na siłę
Pytam, bo nie znam się na a:h, a z tego co tu czytałem, to się jakoś wiąże obszary z liniami dla routingu i nie wiem, czy obszar może być opisany relacją, czy musi linią i jak się to wiąże.
A jeśli taka zamiana byłaby wystarczająca, to w okolicy jest sporo multipoly podobnych do tego przerobionego i tylko brak wiedzy, jak to przerobić, mnie powstrzymuje. W sensie, że nie chcę się wgłębiać w a:, nie chcę też popsuć czyjejś roboty, a przerobić tę robotę na a:h należy.
Rmikke, tak jak Tomek napisał. Jakkolwiek w specyfikacji nie opisałem explicite multipoligonów, to jednak już proste roundabout z trawnikiem w środku już jest multipoligonem…
Fajnie, a kwestia wiązania z linią? Przewijały się tu jakieś wymogi i widzę, że w zalinkowanym multipoly taka linia jest, ale żadnego powiązania nie widzę.
To co, wystarczy narysować linię, a do multipoly dodać odpowiednie area:highway=* i Bob jest moim wujkiem?
Rondo - w środku trawnik a dookoła niego serwisówka z brukowa szerokości 1,5 m (średnio) jak z tego zrobić take “fajne” rondo, Nadmienię że po bokach też czasami takowe są?
Tak. Z obszaru multipoligonu muszą jedynie wychodzić linie łączące, w tym przypadku footway, z innymi highway. Te linie łączące muszą mieć punkt przecięcia z multipoligonem. Tak jak np ten punkt: http://www.openstreetmap.org/node/4601208908
Edit:
Generalnie miałbym do Was, kolegów zaangażowanych w a:h pytanie czy nie dało by się pociągnąć najpierw jakiejś autostrady łączącej dwa ważne miasta w Polce?
Jakiś czas temu pisałem że najważniejsi niemieccy producenci samochodów jeżdżących autonomicznie (sorry uczących się tak jeździć) wykorzystali dane tworzone przez niemiecką geodezję do sttworzenia obrysów jednej z autostrad.
Najbardziej prawdopodobny wariant najbliższej przyszłości to tzw. pojazdy jeżdżące “wysoce autonomicznie” a nie całkowicie autonomicznie. Dla tańszych wersji pojazdów technologie te będą niedostępne. można będzie jednak tworyć systemy wspomagania kierowcy które będą alarmować gdy zbyt blisko zbliżymy się pobocza. Area:highway jest tu bardzo dobrym rozwiązaniem znacznie redukującym moc obliczeniową takich systemów. Polscy producenci będą technologicznie w stanie takich rozwiązań dostarczyć. Jednak najpierw trzeba mieć pokrycie danymi.
Dlatego brał bym na pierwszy ogień autostrady w całym kraju, tj. oczywiście tam, gdzie są one widoczne na aktualnych podkładach.
Dobrze mi mówić, sam siedzę w tej chwili nad projektem Ilam w Nepalu. Ale gdy skończę, przyłączę się do tej roboty również.
To poprawny przykład rysowania linii, ale te obszary pasów obrysowane jako chodniki, to ewidentny błąd. Powinna tam przechodzić tylko linia z tagami highway=footway + footway=crossing. Może ktoś zainteresowany Warszawą by to poprawił?
I przy okazji jeszcze chciałbym się upewnić, bo kiedyś o to pytałem, ale nie dostałem jasnej odpowiedzi - te obszary gdzie tory tramwajowe są nie wśród kamyków (natural=scree) tylko w warstwie betonu lub płyt betonowych (gdzie wjazd mają tylko pojazdy operatora i służb alarmowych), oznaczamy jako area:highway=tram, czy jakoś inaczej, Marek?
Co do mapowania autostrad to zdecydowanie byłbym za podejściem, żeby w projekcie a:h zaczynać od autostrad właśnie, a następnie schodzić na niższe poziomy. Czyli np. w przypadku miast, żeby najpierw mapować ramy komunikacyjne, a potem zwykłe ulice i drogi osiedlowe. Jeśli o mnie chodzi to najpierw chcę zamknąć moje aktualne cele, w tym zmapowanie jako obszary wszystkich wydzielonych ścieżek rowerowych w Poznaniu (szczególnie że Geopoz udostępnił ostatnio aktualną mapę rowerową http://195.216.117.150/sip/nmap/mapa/10/rowery)), a w Polsce z tego co wiem nie ma żadnego miasta które mogłoby się pochwalić w miarę kompletną mapą rowerową z obszarami, więc byłby to jakiś wyczyn i innowacja
Jak najbardziej. Schemat działania gdzie najpierw pracujemy nad najważnieszymi nitkami komunikacyjnymi potem mapując inne drogi to od zawsze schemat podejścia do mapowania. Dlaczego a:h miały by być tutaj wyjątkiem? Dokończ jednak najpierw projekt Poznań a potem możemy się zabrać za połączenie Poznań-Warszawa. Nie mam jednak zielonego pojęcia jak tutaj sytuacja z aktualnością podkładów wygląda…
Łeee, to czemu nikt mi nie powiedział, że to takie proste rok temu, kiedy była tu dyskutowana ta uwaga? To ja się tyle czasu niepotrzebnie cykam, żeby nie zepsuć komuś roboty i nie namieszać bardziej, niż było…
Co do pomysłów/potrzeb.
Mam “zonka” małego odnośnie Dziwnów - ulica Wybrzeże Kościuszkowskie - powstały miejsca parkingowe prostopadle do jezdni - jednak pomiędzy tymi miejscami a jezdnią jest zostawiony szerokości 1,5 m jakby ciąg pieszy dla użytkowników tych miejsc parkingowych by przeszli na chodnik nie przez trawnik. Pociągnąłem tam highway=footway ale krzyczy mi na niebiesko błąd że (jezdnie parkingu dodałem jako area:highway=service gryzą się rodzaje highway.
Czy warto pomyśleć nad tagiem area:highway=parking dla powierzchni parkingów kiedy nie biegnie po ich powierzchni żadna linia highway=xxx?
@marek kleciak - częściowo tak ale wtedy taka powierzchnia po której spokojnie może przejechać - ściąć łuk ronda/zjazdu z niego -samochód nawet osobowy. Ale pomiędzy jezdnia właściwą a tą"serwisową do ścinania łuków drogi" powstaje jakby bariera w stylu krawężnika barrier=kerb.
Ja dodałem w tym miejscu area:highway=service - wywala jednak błąd - “brak linii highway dla obszaru”. area
Odnośnie części rozdzielającej jezdnie w przeciwnym kierunku na które można wjechać w celu ominięcia unieruchomionego pojazdu oddzielona od jezdni linią ciągłą jak to wykonać poprawnie? Ja wstawiłem jak na grafice poniżej area:highway=service:
