Pl:Relacja
| Pomoc |
|---|
|
Relacje to zbiory obiektów z opisami ról jakie te obiekty pełnią w stosunku do siebie i do całości zbioru. Relacje służą do opisu obiektów złożonych, które składają się z fragmentów, które pozostają w jakimś stosunku do siebie. Same relacje są również obiektami, choć szczególnego rodzaju.
Przykładowo: aby narysować jezioro z wyspą pośrodku, trzeba stworzyć dwa wielokąty: jeden zewnętrzny obrysowujący brzeg jeziora i drugi, wewnętrzny "wycinający" z jeziora obszar wyspy. W takim przypadku relacja "jezioro z wyspą" musi się składać z dwóch wielokątów, z których jeden ma przypisaną role bycia "zewnętrznym", a drugi "wewnętrznym".
Inny przykład: Szlak turystyczny prowadzi kilkoma drogami: najpierw asfaltową drogą lokalną, potem ścieżką przez las, a następnie drogą leśną. Relacja opisująca szlak będzie obiektem "zewnętrznym", składającym się z trzech wybranych fragmentów innych obiektów, powiązanych w odpowiednich punktach z sobą w jeden ciąg.
Inaczej mówiąc, relacje są specjalnym typem obiektów, które grupują inne obiekty nadając im w ramach całości określone role. Jako, że relacje też są obiektami - mogą one mieć własne tagi, inne niż obiekty wchodzące w ich skład.
Ten artykuł jest punktem wyjścia do dyskusji i wreszcie dokumentacją metod obecnie zwykłych, takich jak artykuł Map Features dla znaczników. Wprowadzenie w relacje znajduje się w artykule Wprowadzenie_w_relacje.
Contents
Użycie
Relacje są używane do tworzenia logicznego modelu (zazwyczaj lokalnego) lub geograficznej relacji między obiektami. Nie są one przeznaczone do przechowywania luźno związanych, ale rozrzuconych obiektów. Niewłaściwe byłoby, na przykład, aby użyć relacji do tworzenia grupy "Wszystkie chodniki w zachodniej Polsce". Jest to szerzej opisane relacje nie sa kategoriami.
Obiekty
- szkoły - gdzie węzeł lub budynek jako Zespół Szkół jest type=site, a poszczególne szkoły są relacjami.
- szpitale/przychodnie lekarskie, gdzie węzeł lub budynek jest type=site a poszczególne oddziały lub gabinety jako relacje.
- groby/grobowce/krypty - gdzie miejsce pochówku jest type=tomb a poszczególni zmarli jako relacje do danego grobu.
Rozmiar
Zaleca się, aby stosować nie więcej niż około 300 zależnych elementów. Jeśli mamy objąć więcej elementów, to można stworzyć kilka relacji i połączyć je w Super-Relation. Powód: im więcej obiektów składa się na jedną relację, tym trudniej jest ją obsługiwać, łatwiej popełnić błędy oraz bardziej obciąża zasoby w bazie danych i serwer.
Jadnak warto zauważyć że super-relacje nie są wspierane przez jakiekolwiek konsumentów danych a z upływem czasu i poprawą typowego sprzetu możliwe jest wygodne edytowanie coraz większych relacji.
Oznaczanie
Tagi
| Klucz | Wartość | Opis |
|---|---|---|
| type | typ relacji | Wskazuje, że ta relacja reprezentuje trasę. (obowiązkowe) |
| name | nazwa | Nazwa miejsca , szkoły, obiektu ... |
| typ relacji | * | (opcjonalnie) Typ miejsca (np. szkoła lub szpital). To może być zbędne, biorąc pod uwagę, że mamy już amenity=*, leisure=*, railway=*, itd. |
Elementy
| Way lub Node | Role | Ilość | Opis |
|---|---|---|---|
 |
label | zero lub więcej | Definiuje gdzie umieścić etykietę. |
  |
perimeter | zero lub więcej | Powierzchnia lub relacja multipolygon. Definiuje obwód obiektu. |
| |
outline | zero lub więcej | Obszary, które tworzą ściany budynku. Inne nazwy? Może po prostu "wall"? |
|
entrance | zero lub więcej | Węzeł lub węzły na obwodzie określające wejście do obiektu. |
 |
puste | zero lub więcej | Cokolwiek chcemy oznaczyć jako część obiektu. Np. budynki, pasy startowe, parkingi, boiska itp. |
| |
contains | zero lub więcej | Powinno być używane dla POI wewnątrz budynku. Jeśli mamy szczegółowe informacje o takim POI (oddzielne wejście, inny adres, czy coś w tym stylu), byłoby lepiej zbudować oddzielną relację dla każdego POI i następnie umieścić to jako członek tutaj. |
| |
address | zero lub więcej | To powinno być stosowane dla węzłów i relacji, które zawierały informacje adresowe. Więcej na ten temat w Proposed features/House numbers/Karlsruhe Schema |
Role
Role jest opcjonalnym polem tekstowym opisującym rolę elementu relacji. Na przykład, w zakresie relacji dla Wieloboku: role = inner (wewnętrzna) i role = outer (zewnętrzna) są używane do określania, czy wielokąt tworzy wewnętrzną lub zewnętrzną część tego wieloboku.
Typ relacji
| Typ | Element | Opis | Grafika |
|---|---|---|---|
| associatedStreet |
|
Grupowanie elementów związanych z ulicą. Patrz Karlsruhe scheme | |
| boundary |
|
Grupowanie granic i oznaczanie enklaw i eksklaw. | |
| land_area |
|
Grupowanie granic i oznaczanie enklaw i eksklaw. | |
| bridge |
|
Grupowanie wszystkich elementów mostu. | |
| destination_sign |
|
Grupowanie znaków kierunkowych na lub przed skrzyżowaniami. | 
|
| enforcement |
|
Grupowanie urządzeń do kontroli ruchu; fotoradary, kamery na podczerwień, wagi, ... | |
| multipolygon |
|
Obszary, których obwód składa się z wielu dróg, lub które mają w sobie wewnętrzne obszary. Używane np. do rysowania obrysu domów lub granic. | |
| network |
|
Relacje opisujące sieci z członkami będącymi także członkami tej sieci. | |
| person |
|
Proponowana relacja do grupowania elementów związanych z osobą, takich jak data urodzenia, data śmierci, zawód, strona na Wikipedii, itd | |
| public_transport |
|
Część OSM schematu komunikacji publicznej. Głównie używany jako public_transport=stop_area. | |
| restriction |
|
Wszelkiego rodzaju ograniczenia skrętu. | |
| route |
|
Trasy autobusów, trasy rowerowe, szlaki piesze i numerowane ulice. | |
| route_master |
|
Zawiera tylko (parallel, opposite, variant, …) trasy; bardzo często używany do grupowania wariantów tras w transporcie publicznym. | |
| site |
|
Relacja do grupowania elementów terenu/węzła, takich jak szkoły, obiekty biurowe ... site=stop_area został zmieniony na public_transport=stop_area | |
| street |
|
Relations/Proposed/Street, Relations/Proposed/Collected_Ways i Relations/Proposed/Collected_Ways_Simple dążą do poprawy relacji associatedStreet | |
| superroute |
|
Należy unikać gdyż superroute zawiera tylko (spójne) trasy.
|
|
| tunnel |
|
Grupowanie elementów tunelu. | |
| waterway |
|
Grupowanie odcinków cieków wodnych w cale rzeki, strumienie, kanały... |
Rendering
Jeśli etykieta label jest obecna, należy umieścić etykietę w miejscu tego węzła. Jeżeli więcej niż jedna etykieta węzła istnieje (np. bardzo duże obiekty), należy wtedy umieścić etykiety na każdym węźle, jak tylko poziom powiększenia pozwala. Jeśli nie istnieje label, należy użyć środek strefy obszaru obwodowej. Jeżeli to niemożliwe, należy użyć środka strefy wszystkich obiektów powiązanych.
Na niższych poziomach powiększenia renderuj tylko powierzchnię obwodową i węzeł etykiety, ukrywając wszystkie inne elementy, aby zmniejszyć zagęszczenie.
Przykłady
Wielokąt
W relacji dla wielokąta, inner i outer są używane do określenia, w jaki sposób zarys tworzy wewnętrzną lub zewnętrzną część powierzchni wielokąta.
Na przykład, wewnętrzna droga może być zdefiniowana jako wyspa na jeziorze (odwzorowywana jako "relacja").
Trasy autobusowe
Trasa autobusu może mieć relacje type=route, route=bus i ref=* and operator=* tags. Trasy po których jeżdżą autobusy mogą być elementami, łącznie z węzłami przedstawiającymi przystanki. Trasy mogą mieć Rolę forward lub backward, zależnie od tego czy autobusy jeżdżą zgodnie w kierunkiem danego odcinka drogi, lub w przeciwną stronę.
(role może być pusta, co oznacza, że trasę autobusu przebiega w obu kierunkach danego odcinka drogi, na tej samej trasie).
Proponowane relacje
(Uwaga: niektóre propozycje mogą być przestarzałe lub być w sprzeczności z definicją!)
Łączenie i dzielenie tras i węzłów
- Relations/Proposed/Composite Tag często wykorzystywane gdzie restrykcje są ze względu na klasę pojazdu lub czas.
- Relations/Proposed/Segmented Tag stosuje się jesli znacznik lub ich zestaw, dotyczy elementu trasy.
- Relations/Proposed/Collected Ways dla grupowania tras w kompletne ulice, rzeki, linie kolejowe itp.
- Relations/Proposed/Dual carriageways dla grupowania przyległych dróg tworzących przeciwległe jezdnie drogi dwujezdniowej.
- Relations/Proposed/Circuit oznaczanie szczególnych fragmentów drogi np. dla sportów motocyklowych.
- Relations/Proposed/Street grupowanie tras w kompletne ulice, jak również przyłączać inne elementy do nich.
- Relations/Proposed/Curvature do określenia krzywych i prostych części tras.
- Relations/Proposed/boundary_segment do grupowania tras w liniowy obszar.
Skrzyżowania, przecięcia dróg o różnej klasie i nasypy
- Relations/Proposed/Junctions wszystkie drogi, tworzące skrzyżowanie, np krzyżówka na autostradzie.
- Relations/Proposed/Bridges and Tunnels mosty i tumele
- Relations/Proposed/Embankment nasypy
- Relations/Proposed/Turn hints wskazówki dotyczące skrętu: lekko w lewo, ostro w lewo, widelec, itp.
- Relations/Proposed/turn lanes które skręty są dozwolone z danego pasa ruchu.
Ograniczenia skrętu i prawo pierwszeństwa ruchu
- Relations/Proposed/Right of way dla zdefiniowania prawa pierwszeństwa i priorytet/głównych dróg na skrzyżowaniach
- Proposed_features/Relation:type=stop dla zdefiniowania znaku stopu, bardziej elastyczny niż Tag:highway=stop
Hierarchie obszarów i inne relacje dla obszarów
- Relations/Proposed/Region reprezentacja wielu hierarchii na mapie, jak na przykład dzielnic tworzących miasto, itp.
- Relations/Proposed/Level dla pięter w 3D-obiektach (stacje metra, budynki, etc.)
- Relations/Proposed/Is In wszystkie miejsca, które tworzą większe miejsce (np. wszystkie miasta w kraju)
- Relations/Proposed/Buildings dla budynków, w którym chcemy zapisać jego kontur, wejścia, ogrodzenia, itd.
- Relations/Proposed/Site dla grupowania elementów budynku jako całość obiektu.
- Relations/Proposed/Hint wskazówki dla dla osób renderujących i/lub API dużych obszarów.
- Relations/Proposed/Label ręczne umieszczone etykiety lub ikony w obszarach,
- Relations/Proposed/Country gromadzenie danych o kraju.
- Relations/Proposed/Associated_Entrance kojarzenie obiektów z wejściami budynku.
Adresowanie
- Karlsruhe-Schema – Użycie relacji w celu zbierania numerów domów
- Relations/Proposed/House numbers: odrzucone, należy używać addr.
- Relations/Proposed/Postal Addresses
- Relation:postal code
- Relations/Proposed/Street grupowanie tras w kompletną ulicę, jak również inne elementy połączone z nią.
Inne
- Relations/Proposed/Lane (pasy drogowe)dostarcza dodatkowe informacje dla pasa jezdni i drogi (linia dla autobusów, 2-liniowa jezdnia, ścieżka, ścieżka rowerowa, itd)
- Relations/Proposed/Area (teren między liniami) określa obszar między trasami i ścieżkami (przecinanie się liniowe), wirtualne i fizyczne podziały oraz możliwości przejść, itp.
- Relations/Proposed/Rivers (rzeki)dla szerokich rzek, gdzie oba brzegi zostały opisane.
- Relations/Proposed/Traffic Lights światła regulujące ruch drogowy.
- Relations/Proposed/Height Weight Length Restrictions ponieważ relacja ograniczenia, koncentruje się jedynie na ograniczenia skrętu.
(podzielony trasa)
- Relations/Proposed/Overtaking opisuje bezpieczne sekcje wyprzedzania.
- Relations/Proposed/Operators łączenie oddziałów i inne organizacyjnych działów do ich organizacji.
- Relations/Proposed/Sled grupuje wszystkie istotne elementy zjazdów narciarskich.
- Relations/Proposed/Surveillance do grupowania ze sobą kamer bezpieczeństwa oraz obszarów objętych kontrolą.
- Relations/Proposed/Directional node węzły, które wskazują określony kierunek.
- Relations/Proposed/Defaults określa zbiór wartości domyślnych (ograniczenia prędkości, oneways, dostęp) dla danego kraju, stanu.
- Relations/Proposed/Health opisujące złożone relacje dotyczące obiektów służby zdrowia, związanych z nią dziedzin, budynków, biur, osób i usług.
Projekty
- Low emission zone: Strefy miejskie z wymuszeniem obniżonego zanieczyszczenia powietrza spalinami.
Projekty w Niemczech
Narzędzia
- JOSM/Advanced_editing#Relations - Relacji w JOSM
- Potlatch 2/relations - Relacje Potlatch
- example id=11 - Relacje
- example id=11 - Historia relacji
- Beispiel id=11 - Rendering relacji
- http://ra.osmsurround.org - Szukanie relacji
- OSM Relation Analyzer
- Relation Check
- Relation Diff
- Relation lists
- Wizualizacja relacji na mapie
- Rel2gpx
