Proposal:Street area/pl

Strona zawiera propozycje szczegółowego rysowania geometrii ulic jako płaszczyzn w OpenStreetMap.

Autor: Marek Strassenburg-Kleciak

Uwagi wstępne

Ulice (highway),mogą być, podobnie jak np. rzeki, podwójnie rysowane w OSM:
1. Jako wektor,
2. Jako obszar (area) (szczegóły tagowania są obecnie dyskutowane).
Dzięki temu geometria ulic będzie mogła być przedstawiana w prawidłowy sposób także w najwyższych stopniach powiększenia mapy.

W szczególności precyzyjnie rysowane i renderowane w przyszłych wersjach map będą mogły być na przykład:

• skomplikowane skrzyżowania wraz z przejściami dla pieszych,
• miejsca parkingowe,
• przystanki autobusowe.

Narysowane już w dotychczasowej formie ulice muszą zostać uzupełnione o dodatkowe punkty w obszarach w których ulice są rysowane jako płaszczyzny. Dalszy opis w tekście poniżej.

Status quo: Ulice jako linie

Topologia ulicy nie jest rysowana w sposób odzwierciedlający rzeczywistość. Aby renderować ulice, przyjmuje się założenia dotyczące szerokości ulicy lub raz w jednym miejscu zmierzonej jej szerokości. Istnieje jednak dużo przypadków gdzie to podejście mija się z rzeczywistością.

Nowy schemat - area:highway

Ulice rysowane są jako area według pokazanego przykładu. Oczywiście jest to możliwe tylko w tych miejscach, gdzie dysponujemy szczegółową informacją o geometrii ulicy (np. zdjęcia lotnicze wysokiej rozdzielczości lub import krawężników).

Tagowanie

Podstawowe tagi

Tag	Stosowanie	Typ elementu	Wartość	Opis
area:highway	wymagane		<typ ulicy> np: residential / secondary / tertiary itd..	ogólnie dostępny dla ruchu obszar ulic
area:highway	wymagane		<typ ulicy> + junction=yes/roundabout, y_juncion	obszar skrzyżowania ulic ograniczony linią ciągłą lub zewnętrznym brzegiem przejścia dla pieszych gdy brak linii ciągłej.
area:highway	wymagane		traffic_island	nieprzejezdny obszar ulicy, wysepka
area:highway	wymagane		permissive	obszar ulic dostępny tylko dla autobusów lub taxi.
area:highway	wymagane		emergency	nieprzejezdny obszar ulicy (szrafura asfaltu w białe pasy),
amenity=*	pożądane		parking	obszar parkingowy przy poboczu ulicy.
name=*	pożądane		tekst	Nazwa ulicy identyczna z nazwa wektora ulicy
name2=*	pożądane		tekst	Nazwa ulicy identyczna z nazwa wektora ulicy. (1)
addr:postcode=*	pożądane		tekst	Kod pocztowy ulicy.
addr:city=*	pożądane		tekst	Nazwa miasta

(1) - Stosowane w przypadku skrzyżowań będących częścią dwóch ulic.Analogicznie name3, name4 itd. w przypadku skrzyżowań łączących w sobie wiele ulic. Dzięki tej technice renderer będzie mógł prawidłowo przedstawiać przebieg trasy w systemie nawigacji.

Warstwa logiczna

Niezbędne restrykcje:

• Sąsiadujące płaszczyzny MUSZĄ mieć punkty wspólne,

• Punkty, położone na osi ulic nazywane dalej w tekście dla wygody K (na rysunku powyżej punkty w kolorze czerwonym), są także punktami płaszczyzn area:highway, tagowanymi jako crossing:end=yes w przypadku gdy nie ma dla nich innego tagu np. highway=stop.

• Punkty leżące na obwodzie poligonu area:highway i sąsiadujące z każdym punktem K, tj. K+1 i K-1 MUSZĄ znajdować się na zewnętrznej krawędzi ulicy.

Pytanie: Dlaczego punkty K muszą być punktami wspólnymi dla highway:<value> i area:highway? Linie symbolizujące początek skrzyżowania można by przecież renderować pod kątem prostym do osi wektora highway:value w nowo dodanym punkcie?

Odpowiedz: Często zdarzają się skrzyżowania, przy których linie symbolizujące nakaz zatrzymania się nie są malowane pod kątem prostym do osi ulicy. Proponowane rozwiązanie umożliwia zgodny z rzeczywistością rendering tych linii.

Rendering

Znając liczbę pasów jezdni ( lanes=* ), oraz dysponując informacją o rodzaju linii miedzy nimi (konieczność otagowania, np.: none, solid_line, double_line, dashed_line itd.) można renderować zbliżony do rzeczywistości obraz obszaru jezdni i skrzyżowania. Przesłanką do tego jest także tagowanie punktów K. Tag dla każdego z tych punktów usuwa wartość tagów opisujących rodzaj brzegów ulicy dla danego area:highway na odcinku K-1 do K+1 i zastępuje je przez jeden bądź dwa tagi dla danego punktu K.

Schemat tagowania punktu K

Tag	Stosowanie	Typ elementu	Wartość	Opis
crossing:end=*	wymagane		yes	Punkt, gdzie zaczyna lub kończy się obszar skrzyżowania
left=*	pożądane		none, solid_line, double_line, dashed_line, giveway_line	Rodzaj linii ograniczającej malowanej na fragmencie skrzyżowania na asfalcie na lewo od osi ulicy patrząc w kierunku skrzyżowania
right=*	pożądane		none, solid_line, double_line, dashed_line, giveway_line	Rodzaj linii ograniczającej malowanej na fragmencie skrzyżowania na asfalcie na prawo od osi ulicy patrząc w kierunku skrzyżowania

Tu pojawia się proste przykłady na zastosowanie: ....

Typy linii planowane do renderingu lane dividers

• none - Brak jakiejkolwiek linii między pasami.
• solid_line - Linia ciągła

• double_line - Linia podwójna ciągła

• solid_dashed_line - Linia ciągła/przerywana (analogicznie odbicie lustrzane)

• dashed_line - linie przerywana

• giveway_line - zatrzymanie z ustąpieniem pierwszeństwa (nie jest typem line divider dotyczącym lines)

Brak tagu dla Left: i Right: oznacza: na lewo i prawo od K do renderingu może być używany ten sam kolor (lub tekstura) co nawierzchnia ulicy dając w ten sposób np. ciągłą nawierzchnie asfaltu.

Przykład współzależności rysowania osi, płaszczyzn i taggingu pasów jezdni

Osie ulic

Powierzchnia ulicy

Podział powierzchni na segmenty

Tagowanie poszczególnych directions (uwaga na szkicu są błędy w kierunku strzałek zewnętrznych pasów w segmencie 3 i 4, powinny być tam proste strzałki)

Poszczególne segmenty z podziałem na directions.

Symulacja wyniku w rendererze kafelków OSM / możliwej warstwie graficznej nawigacji.

Inne

Dyskutowane dodatkowe parametry dla area:highway . Przypisywanie kategorii ulicy do obszaru.

Pytanie: Które wartości area:highway są w przypadku skrzyżowania nadrzędne, jeśli zetkną się ze sobą różne rodzajów dróg np. secondary i residential? Czy rozdzielić area dla residential? Lub wprowadzić nowy value dla skrzyżowania?

Odpowiedz: Jeśli ktoś chce przypisywać kategorie do ulicy zamiast używać "yes" - generalnie, tak jak w przypadku "klasycznego" atrybutowania wydaje się, że ważniejsza ulica powinna być "NADRZĘDNA" i to właśnie tak powinno być atrybutowane skrzyżowanie.

Niezależnie od tego warto prowadzić dyskusje na temat tego, czy tego typu dodatkowe atrybutowanie jest w ogóle niezbędne, zwłaszcza że dotychczasowa warstwa logiczna w której ulice rysowane są jako osie, już zawiera informacje o kategorii ulicy!. Bardziej sensowna wydaje się taka atrybutacja wtedy, gdy skrzyżowanie dwóch ulic jest np. placem.

Atrybutowanie ulic za pomocą np.: secondary, residential zostało poza tym wprowadzone w dwóch celach:

• dla polepszenia routingu,
• by móc odpowiednio rysować dane kategorie ulic na mapie.

Rysowanie ulicy dodatkowo jako "area" nie potrzebuje zasadniczo tej informacji, jako że dokładna geometria ulicy będzie i tak rysowana jedynie w najwyższych stopniach powiększenia na podstawie geometrii ulicy i ma inne cele niż nawigacja która i tak będzie opierać się na osiach ulic.

Skomplikowane skrzyżowania a nawigacja pod OSM

A. Początek rysowania mapy, silna generalizacja, nadaje się do prostej kalkulacji przebiegu trasy.

B. Uwzględnienie oddzielonych od siebie, np pasem zieleni, przystankiem tramwajowym itd., pasów jezdni. Bardziej realistyczny routing.

C. Uwzględnienie manewru skrętu w prawo. W porę podany komunikat skręć w prawo

D. Uwzględnienie manewru skrętu w lewo. W porę podany komunikat skręć w lewo

E. Uwzględnienie wszystkich manewrów skrętu w lewo

Dotychczasowy paradygmat rysowania tego typu skrzyżowań w najwyższym stopniu szczegółowości jest dziełem przypadku. Stało się tak, ponieważ programy typu Keepright pokazują błąd wszędzie tam, gdzie przecinają się ze sobą dwie drogi bez punktu wspólnego. Wprowadzając punkty przecięcia także tutaj musimy w konsekwencji w celu uzyskania prawidłowego routingu, umieszczać wszędzie na nich restrykcje only straight on. Technika powoduje większy nakład pracy i jest podatna na błędy.

F. Nowy paradygmat: Brak punktów przecięcia na liniach typu link z innymi drogami.

UWAGA: Nowy paradygmat będzie wkrótce tj. jesień 2013, poddany dyskusji z OSMF i Data Working Group! Aby można go było używać potrzeba jest nowa kategoria dróg, nazwijmy ją po polsku "łącznik". Umożliwi ona precyzyjne pokazanie kierowcy jak należy jechać, ale nie będzie renderowana na standardowej mapie jako highway, ponieważ w większości zastosowań zaciemnia ona renderowaną mapę zbyt dużą ilością szczegółów.

Możliwy rendering skrzyżowań

A. Raw data.

B. Example rendering, surfaces only.

C. Example rendering, additionally parking areas and trees with diameter.

C. Example rendering, additionally pedestrian crossing.

D. Example rendering now...

Przykład możliwości zaawansowanego renderingu mapy: przejścia dla pieszych

Jeśli przejście dla pieszych to droga pod kątem prostym do osi ulicy, to nie jest konieczne rysowanie jej jako footway=yes a jedynie zaznaczenia highway=crossing. W renderingu pasy zebry będą mogły być wtedy generowane automatycznie w sposób pokazany poniżej:

A. Pp - Punkt otagowany jako highway=crossing

B. Punkty 1 i 2. łączą prostą prostopadłą do osi ulicy.

C. Wynik renderingu.

Inaczej ma się sprawa, gdy przejście dla pieszych przebiega pod kątem lub jest w bardzo rzadkich przypadkach linią łamaną:

D. Linia 1-2 to narysowany na mapie wektor otagowany jako highway=footway plus footway=crossing

E. Wynik renderingu.