Pl:OSM-4D/Roof table
Uwaga, strona w budowie! Planowany jest dalszy rozwój tej techniki. Uwaga: Poniewaz strona jest obecnie przeladowana a pojawiaja sie nastepne propozycje, to wszystko co nie jest forma dachu lub lukarny zostanie przeniesione na strone Wiki 3D_building.
Zestawienie form dachów oraz lukarn do parametrycznego modelowania budynków w OSM. Wizualizacja form budynków odbywa sie obecnie w plugInie JOSM PlugIn Kendzi3D.
Dachy płaskie
(*a) = if only L1 then all other L parameters = L1
Dachy z jedną płaszczyzną
3D View
/ Top view + Sideviews |
||
---|---|---|
Typ | 1.0 | 1.1 |
Parameters | H1 | H1, H2, H3 |
Restrictions | none | none |
Implemented | yes | yes |
Dachy z dwoma płaszczyznami
3D View
/ Top view + Sideviews |
|||||
---|---|---|---|---|---|
Typ | 2.0 | 2.1 | 2.2 | 2.3 | 2.4 |
Parameters | H1, L1 | H1, H2, L1 | H1, L1, L2 | H1, H2, H3 | H1, H2, H3 |
Restrictions | L1< depth | L1< depth | L1< depth, L2<width | ||
Implemented |
3D View
/ Top view + Sideviews |
|||||
---|---|---|---|---|---|
Typ | 2.5 | 2.6 | 2.7 | 2.8 | 2.9 |
Parameters | H1, L1, L2 | H1, H2, L1 | H1, L1, L2 | H1, H2, H3 | H1, H2, H3 |
Restrictions | |||||
Implemented |
Dachy z wieloma plaszczyznami
Podtyp 3
3D View
/ Top view + Sideviews |
|||||
---|---|---|---|---|---|
Typ | 3.0 | 3.1 | 3.2 | 3.3 | 3.4 |
Parameters | H1, H2, L1 | ||||
Restrictions | L1<width | ||||
Implemented |
Often used examples 3.0 basic. 3.0 free outline.
Podtyp 4
(*) If Symmetry, then only L1, L2 necessary
Typ 4.2 wyglada w zaleznosci od przyjetej wielkosci parametrów inaczej niz tzw. dach mansardowy:
Przyklad budynku typ4.0 na wolnam rzucie prostokatnym:
Podtyp 5
(*a): Pólkula: Wysokosc polkuli to polowa srednicy, dodatkowy parametr zbyteczny
Podtyp 6
Podtyp 7
Podtyp opisuje dachy z powtarzalnymi strukturami płaszczyzn dachów. W chwili obecnej przewidziane jest 5 typów powtarzalnych struktur:
- Piła
- Trapez
- Piła z podwójnym nachyleniem
- Półokrag
- Fala
Ostatnia liczba w opisie pokazuje ile razy powtarza się dana struktura wzdłuż całego dachu.
3D View
/ Top view + Sideviews |
7.1.2 |
7.1.4 7.1.19 |
7.2.2 7.2.3 |
7.3.5 |
7.4.5 7.4.3 |
7.5.2. |
---|---|---|---|---|---|---|
Typ | 7.1.n | 7.1.n | 7.2.n | 7.3.n | 7.4.n | 7.5.n |
Parameters | H1 | H1 | H1 | H1 | H1 | H1 |
Restrictions | ||||||
Implemented |
Podtyp 8
8.A
Bryły obrotowe na rzucie okrągłym (jeszcze nie mamy tego w OSM ale będzie kiedyś na pewno), lub na regularnym wieloboku.
Typ 8.0.1 | Typ 8.0.2 | Typ 8.0.3 | Typ 8.0.4 | Typ 8.0.n |
H1 | H1,H2,L2 | H1,H2,H3,L2,L3 | H1,H2,H3,H4,L2,L3,L4 | Parametry opisujące formę
patrz przykład przekroju poprzecznego powyżej: |
(Stożek) | 1 x załamanie w przebiegu
przekroju poprzecznego |
2 x załamania w przebiegu
przekroju poprzecznego |
3 x załamania w przebiegu
przekroju poprzecznego |
n x załamań w przebiegu przekroju poprzecznego.
Modelowanie np.kopuły cebulowej. |
8.B
Powierzchnie wyższych stopni, m. in. drugiego stopnia
.. | ||||||
Typ 8.1 | Typ 8.2 | Typ 8.3 | Typ 8.4 | Typ 8.5 | Typ 8.6 | Typ 8.7 |
H1,H2,H3 | H1,H2,L1,L2,ResolutionH, ResolutionV | H1,D1, Twist, ResolutionH, ResolutionV | H1,D1,D2,ResolutionH, ResolutionV, Twist | H1,D1, ResolutionH, ResolutionV,Twist *a | H1, ResolutionH, ResolutionV, Twist *a | H1, D, alpha, ResolutionH, ResolutionV, Twist |
patrz: [1]
Any floor plan possible |
Jeśli H1=H2 i L1=L2 forma staje się
leżącym cylindrem parabolicznym (drugi szkic) Any floor plan possible |
Often used in industry | The same mathematical definition
like 8.3 but not cutted in the middle |
description soon | paraboloida eliptyczna | Konstrukcja namiotowa |
(*a) do sprawdzenia czy podane parametry są wystarczające do jednoznacznego opisu.
- Twist -rotation along z axis. Example see: [2]
- ResolutionH : number of segments of floor plan (when change to regular polygon with n sides wished)
- ResolutionV : number of segments of building height
Podtyp 9
Podtyp 9 opisuje tzw. formy generyczne dachów na dowolnym rzucie. Zalozeniem jest, ze wszystkie plaszczyzny dachowe rozpoczynajace sie na tej samej wysokosci maja ten sam kat nachylenia.
Type 9.0 | Type 9.1 | Type 9.2 |
Lukarny
Podstawowe geometrie dla lukarn:
Typ a | Typ b | Typ bR | Typ c | Typ d | Typ e | Typ f | Typ g ( tzw. wole oko ) |
Tagowanie rozmiarów lukarn:
Tagging
Nazwa atrybutu | Wartość atrybutu | Opis |
---|---|---|
building | yes, * | budynek dla obszaru |
building:roof:shape | 3dr | Ogólny kod tego schematu tagowania. (Nie wprowadzamy go!) |
3dr:type | Np. 2.0 | Określa typ dachu np. 2.0. Zapis dla szybkiego ręcznego wprowadzania może zostać uzupełniony o opis lukarny. W rozszerzonej wersji może wyglądać 3dr:type=2.0.a.a) |
Parametry dla typu dachu: | ||
3dr:height1 | [m, d] Domyślnie m | Parametr opisujący pierwszą wysokość dla danego typu dachu. . |
3dr:height2 | [m, d] | Parametr opisujący drugą wysokość dla danego typu dachu |
3dr:heightX | ||
3dr:length1 | [m, %] Domyślnie %. | Parametr opisujący pierwszą długość dla danego typu dachu. |
3dr:length2 | [m, %] Domyślnie %. | Parametr opisujący drugą długość dla danego typu dachu. |
3dr:lengthX | [m, %] | Parametr opisujący kolejne długości |
Lukarny | ||
3dr:dormer | Np. "aa.a" | Atrybut opisujący kolejne lukarny uporządkowane w grupy. Grupy lukarn rozdzielone są kropkami. Grupa mogą zostać przypisane do krawędzi obrysu budynku lub do boku prostokąta opisującego dany obrys. W przypadku przypisania do krawędzi numer grupy odpowiada numerowi krawędzi obrysu. Sposób przypisania określa atrybut 3dr:donor:type. Domyślnie grupy przypisane są do krawędzi.
Brak atrybutu oznacza przypisanie grup do krawędzi =rect Lukarny podane w tym atrybucie są nadrzędne względem tych podanych w atrybucie building:roof:3dr:type. Wartość dotycząca lukarn z atrybutu 3dr:type powinna zostać automatycznie przenoszona do tego pola po zakończeniu edycji. |
3dr:dormer:type | "rect" | Określa sposób przypisania grup lukarn. Wartości: Domyślne brak, rect - przypisanie grup do krawędzi prostokąta opisującego obrys budynku. |
3dr:dormer:width | [m] | Wartość domyślna dla wszystkich nadbudówek dla danego dachu. Opisuje szerokość nadbudówki [domyślnie m] |
3dr:dormer:heightX | [m, d] | Wartość domyślna dla wszystkich nadbudówek dla danego dachu. Wysokość nadbudówki [domyślnie m, dla niektórych dozwolone stopnie] |
3dr:dormer:lengthX | [m, %] | Parametr opisujący kolejne długości nadbudówki |
Jednostki
Kod jednostki | Opis |
---|---|
m | metry |
d | stopnie |
% | procenty |
Przykład
Prosty przykład dla zapisu dachu:
Atrybut | Opis |
---|---|
building = yes | |
3dr:type=2.0 | Dom z dachem dwuspadowym |
3dr:dormer=a.a | Jedna lukarna typu a |
3dr:height1=1m | |
3dr:length1=10% | |
3dr:dormer:width=2.5 | |
3dr:dormer:height1=2.5m |
Przykłady
Dachy oparte na kształcie prostokątnym
Część dachów bazuje na kształcie prostokątnym i tylko dla niego mają sens. Obrys budynku nie zawsze musi mieć cztery wierzchołki. Może nie być wcale prostokątem.
Przykład takiego obrysu:
Dachy bazujące na prostokącie to typy: 0.*, 1.*, 2.*, 3.*, 4.*, 5.* 6.*, 7.*
Przykłady
Typ 2_1 | Typ 5_2 | Typ 5_6 |
---|---|---|
3D view: |
W przypadku typu 5_6 znajdowany będzie największy możliwy okrąg wpisany w poligon rzutu i na nim generowana będzie półkula (czerwona powierzchnia na rysunku, punkty wspólne kopuły i okręgu w kolorze niebieskim) zaś pozostała powierzchnia będzie generowana domyślnie jako płaszczyzna typu 0.0 (kolor szary).
Generowanie bounding box budynku
Aby dla budynku o obrysach nie będących prostokątem mógł zostać wygenerowany model 3D w pierwszej kolejności musi zostać wygenerowany najmniejszy prostokąt zawierający ten obrys bounding box. Dla znalezionego prostokąta łatwo wygenerować kształt dachu oraz miejsca na lukarny.
Przykład generowania dachu dla nie trywialnego kształtu obrysu budynku:
Właściwości dachu
Ponieważ dachy te bazują na prostokącie, wymiary prostokąta zawierającego obrys są brane przy obliczaniu kształtu dachu. Każdy typ dachu ma parametry opisujące jego formę np. 3dr:lenght. Jeżeli wymiary te mogą zostać podane w postaci procentów, właściwe wymiary zostają obliczone biorąc pod uwagę długość lub szerokość prostokąta.
Czasami pożądany obrys (kolor zielony) nie jest jednoznaczny z algorytmicznie obliczonym bounding box (kolor czerwony)
Punkt startowy
W celu precyzyjnego opisania dachu konieczne jest określenie jego kierunku. Dotychczasowe propozycje opierają się o tag building:roof:orientation= along|across. Niestety tag ten nie jest wystarczający ponieważ:
1. Istnieją budynki na kwadratowym rzucie. W takim wypadku atrybut jest bezwartościowy bo software podejmuje decyzje przypadkowo.
2. Istnieją dachy które nie są symetryczne i mają więcej niż dwa kierunki np:
3. Dla opisu lukarn wymagane jest precyzyjne określenie „początku” dachu
poza tym wszelkie poprawki geometrii rzutu budynków zbliżonych do kwadratu niosą ze sobą ryzyko, ze along stanie się across i geometria dachu się zmieni.
W celu precyzyjnego określenia początku dachu należy ustalić jakiś punkt obrysu punktem początkowym. Nie ma potrzeby dodawania dodatkowych atrybutów dla wierzchołka ponieważ obrys budynku ma już zdefiniowaną kolejność wierzchołków. Można wykorzystać i przyjąć punkt startowy jako początek opisu kształtu dachu.
Uwaga. Punkt startowy dla obrysu nie jest widoczny w edytorach osm!
Kierunek obrysu
Domyślnie obrys zamykany jest wewnątrz prostokąta. Niestety nie w wszystkich sytuacjach położenie obliczonego prostokąta jest zgodne z oczekiwaniami. Należy dodać dodatkowe atrybuty określające położenie prostokąta opisującego budynek. Określenie kierunku prostokąta wpłynie również na położenie lukarn, ponieważ można za jego pomocą określić gdzie znajduje się 'przednia' ściana. Przykład:
Metoda 1
Opis za pomocą tagów przypisanych dla wierzchołków obrysu budynku. Dwa z wierzchołków obrysu otrzymują tag 3dr:direction=begin|end. Metoda ta sprawdzi się dla wolno stojących budynków które nie dzielą ścian z innymi budynkami.
Tag | Tag (alternatywnie) | Opis |
---|---|---|
3dr:direction=begin | Punkt początkowy obrysu. | Początek wektora opisującego kierunek dachu |
3dr:direction=end | 3dr:direction=yes | Koniec wektora opisującego kierunek dachu |
Metoda 2
Punkty określające kierunek można zapisać w postaci relacji. Pozwoli to definiować punkty kierunkowe również dla budynków mających wspólne ściany.
Typ relacji: 3dr
Dowolny początkowy punkt z rolą 3dr:direction:begin
Dowolny końcowy punkt z rolą 3dr:direction:end
lub
Punkt początkowy obrysu
Dowolny końcowy punkt z rolą 3dr:direction
Uwaga Może ulec zmianie.
Uwaga Nie zaimplementowane.
Miejsca na lukarny
Dla dachów bazujących na prostokącie są cztery obszary w których mogą zostać umieszczone lukarny. Miejsca te są związane z bokami prostokąta zawierającego obrys budynku. Ilustruje to rysunek:
Numer miejsca na dachu | Tag | Tag (alternatywnie) | Opis |
---|---|---|---|
miejsce 1 | 3dr:dormers:front | 3dr:dormers:1 | Przód |
miejsce 2 | 3dr:dormers:right | 3dr:dormers:2 | Prawa strona |
miejsce 3 | 3dr:dormers:back | 3dr:dormers:3 | Tył |
miejsce 4 | 3dr:dormers:left | 3dr:dormers:4 | Lewa strona |
Nie dla wszystkich kształtów dachu wszystkie cztery miejsca na lukarny są dostępne. W powyższym przykładzie dla typu 2.0 sens mają tylko dwa miejsca na lukarny. Są to miejsca numer 1 oraz 3. Pozostałe miejsca są ignorowane.
Uwaga. Obecnie nie jest zaimplementowane. Obecnie lukarny można opisać jedynie za pomocą parametru 3dr:type=2.0.aa.b
Opis lukarn
Dla dachów prostokątno podobnych
Metoda 1
Lukarny są zapisywane w postaci jednego ciągu znaków. Litera oznacza typ lukarny według tabeli [XXX]. Ciągi znaków rozdzielone kropkami opisują lukarny na kolejnych miejscach dachu.
Proponowany tag to: 3dr:dormers
Przykład:
Tagi:
3dr:type=2.0
3dr:dormers=aa.b
Dla typu 2.0 opis powyższy oznacza dwie lukarny typu 'a' na miejscu 1 (przednia ściana) oraz jedna lukarna typu b na miejscu 3 (tylna ściana)
Uwaga. Obecnie nie jest zaimplementowane. Obecnie lukarny można opisać jedynie za pomocą części parametru 3dr:type np. 3dr:type=2.0.aa.b
metoda ta jest mało czytelna (nie jest zalecana?)
Metoda 2
Zastosowanie osobnych tagów dla każdego miejsca na dachu. Miejsca są określane przez boki prostokąta zawierającego obrys. Dlatego istnieją cztery miejsca do których można przypisać lukarny na dachu.
Proponowane tagi to:
Numer miejsca na dachu | Tag | Tag (alternatywnie) | Opis |
---|---|---|---|
miejsce 1 | 3dr:dormers:front | 3dr:dormers:1 | Przód |
miejsce 2 | 3dr:dormers:right | 3dr:dormers:2 | Prawa strona |
miejsce 3 | 3dr:dormers:back | 3dr:dormers:3 | Tył |
miejsce 4 | 3dr:dormers:left | 3dr:dormers:4 | Lewa strona |
Przykład
Tagi
3dr:type=2.0
3dr:dormers:front=aa (lub 3dr:dormers:1=aa)
3dr:dormers:back=b (lub 3dr:dormers:3=b)
Dla typu 2.0 opis powyższy oznacza dwie lukarny typu 'a' na miejscu 1 (przednia ściana) oraz jedna lukarna typu b na miejscu 3 (tylna ściana)
Uwaga. Obecnie nie jest zaimplementowane. Obecnie lukarny można opisać jedynie za pomocą części parametru 3dr:type np. 3dr:type=2.0.aa.b
Złożone formy dachów
Metoda 1
Lukarny są zapisywane w postaci jednego ciągu znaków. Litera oznacza typ lukarny według tabeli XXX ciągi znaków rozdzielone kropkami opisują lukarny na kolejnych ścianach dachu. proponowany tag to 3dr:dormers
Przykład
tagi
3dr:type=9.0
3dr:dormers=aa..a..aa..a...aaaa.a.a.aaa...aaaaa.aaa.a.a.aaaa
Uwaga nieczytelne dla dużej liczby ścian.
Uwaga nieodporne na usuwanie wierzchołka
Uwaga niezalecane!
Metoda 2
Zapis budynku jako relacji gdzie każda ściana ma przypisane lukarny oraz np. okna
Zalety: Możliwość przypisania ścianie dodatkowych atrybutów np. okien.
Wady: Skomplikowane i nielubiane relacje …
Uwaga. Obecnie nie jest zaimplementowane.
Własne lukarny
Standardowo zostały zdefiniowane podstawowe lukarny w tabeli XXX. Lukarny te mają domyślne rozmiary oraz są położone w domyślnym miejscu dachu. Domyślnie umieszczane są one w równych odległościach od siebie oraz leżą na krawędzi obrysu. Nie zawsze jest to prawidłowe. Jeśli domyślne wartości nie odpowiadają rzeczywistym należy zdefiniować nowe lukarny z nowymi wartościami ich parametrów.
Przykład 1 Lukarny nie leżą na krawędzi dachu
Tag | Opis |
---|---|
3dr:type=2.0 | typ dachu |
3dr:dormer:1:type=a | typ lukarny dla pierwszej definicji |
3dr:dormer:1:depth=1m | jeden metr od krawędzi dachu. (inna propozycja tagu to 3dr:dormer:1:lenght0 (TODO) |
3dr:dormer:2:type=b | typ lukarny dla drugiej definicji |
3dr:dormer:2:depth=1m | jeden metr od krawędzi dachu. (inna propozycja tagu to 3dr:dormer:2:lenght0 (TODO) |
3dr:dormer:2:widh1=4m | Niestandardowa szerokość dla drugiej lukarny |
3dr:dormers:front=1 1 2 | Dla pierwszego miejsca na lukarny przypisujemy trzy zdefiniowane wcześniej lukarny. Zamiast literowych kodów podajemy ich indeksy rozdzielone spacją. |
Przykład 2 Lukarny leżą w różnych rzędach (wysokościach)
Sposób 1
Tagi | Opis |
---|---|
3dr:type=2.0 | typ dachu |
3dr:dormer:1:type=a | typ lukarny dla pierwszej definicji |
3dr:dormer:1:row=1 | poziom 1 lukarny dla pierwszej definicji (inna propozycja tagu to 3dr:dormer:1:level (TODO)) |
3dr:dormer:2:type=a | typ lukarny dla drugiej definicji |
3dr:dormer:2:row=2 | poziom 2 lukarny dla drugiej definicji (inna propozycja tagu to 3dr:dormer:2:level (TODO)) |
"3dr:dormers:front=1 1 1 2 2" | dla pierwszego miejsca na lukarnie przypisujemy trzy zdefiniowane wcześniej lukarnie. Zamiast literowych kodów podajemy ich indeksy rozdzielone spacją. |
Położenie lukarn dla każdego poziomu obliczane będzie automatycznie lub definiowane ręcznie w definicji lukarny. Kolejność lukarn z różnych poziomów nie ma znaczenia czyli zapis "3dr:dormers:front=1 1 1 2 2" jest równoznaczny z "3dr:dormers:front=1 2 1 1 2"
Sposób 2
Tagi | Opis |
---|---|
3dr:type=2.0 | typ dachu |
"3dr:dormers:front:row1=aaa"
"3dr:dormers:front:row2=aa" |
z przodu budynku przypisujemy trzy lukarnie typu a. Jeśli jest potrzeba można użyć zdefiniowanych samodzielnie lukarn. |
Położenie lukarn dla każdego poziomu obliczane będzie automatycznie lub definiowane ręcznie w definicji lukarny.
Przykład 3 Lukarny leżą w różnych rzędach (wysokościach)
Tagi | Opis |
---|---|
3dr:type=2.0 | typ dachu |
"3dr:dormers:front:row1=aaa"
"3dr:dormers:front:row2=aaa" |
dla przodu budynku przypisujemy w rzędzie pierwszym oraz w rzędzie drugim po trzy lukarnie typu a. Jeśli jest potrzeba można użyć zdefiniowanych samodzielnie lukarn. |
Położenie lukarn dla każdego poziomu obliczane będzie automatycznie lub definiowane ręcznie w definicji lukarny.
Uwaga. Nie zaimplementowane
Uwaga. Może ulec zmianie
Metoda 3
Jakieś propozycje ?
Porównanie
Porównanie atrybutu typu dachu (3dr:type) z atrybutem kształtu (building:roof:shape):
building:roof:shape | 3dr:type | Przykład |
---|---|---|
flat | 0.0 | |
pitched | 1.0 | |
gable | 2.0 | |
hipped | 2.4 | |
pyramidal | 2.5 | |
crosspitched | 6.2 | |
gambrel | 4.0 | |
?? | ?? |
Grubość dachu i rendering rzutu budynku w parterze
Kolejnymi planowanymi do implementacji funkcjami w modelowaniu dachów jest uwzględnienie grubości połaci dachowej oraz jego wystawania poza budynek w tagowaniu i renderingu 3D.
Tzw. nawis dachu
Proposal Proposed_features/Building_attributes proponuje już dach wystający poza płaszczyznę fasady ( Propozycja tagu to building:roof:extent )
Key | Description | Example values |
---|---|---|
building:roof:extent | to mark extent of a roof over building walls
|
Propozycja ta jest tutaj uzupełniona o grubość płaszczyzny dachu. Celem jest jeszcze bardziej zbliżone do stanu rzeczywistego modelowanie budynku w 3D. Często nie uświadamianym sobie dylematem tworzenia modeli 3D na podstawie zdjęć lotniczych jest fakt, że rysując na ich podstawie budynki, rysujemy tak naprawdę jako rzut budynku rzut płaszczyzn dachu który zazwyczaj jest większy niż rzut budynku w parterze.
Co prawda w zdecydowanej większości budynków w Polsce dach wystaje poza krawędź budynku jedynie o 10-50 cm, jednakże zdarzają się sytuacje gdzie mamy do czynienia z dużym, częściowym lub nietypowym zadaszeniem.
Aby móc rysować tego typu budynki bez konieczności używania skomplikowanego, parametrycznego opisu, proponujemy rysować ściany budynku jako odrębny poligon, który rysowany byłby w przypadku użycia parametru „building:roof:extent.
Ponieważ najbardziej rozpowszechnioną metodą szczegółowego modelowanie budynków w OSM jest obrysowywanie geometrii dachu ze zdjęcia pionowego (Bing lub inne) to faktyczny obrys budynku jest zazwyczaj mniejszy od narysowanego jako budynek mulitpoligonu.
(Częstym wyjątkiem w polskich realiach są bloki mieszkalne z wielkiej płyty z dachem płaskim. Widok ze zdjęcia lotniczego jest w nim identyczny z rzutem budynku).
Z tego powodu warta dyskusji jest propozycja, by rzut budynku w najwyższych stopniach zoomu przedstawiać w zrenderowanej mapie jako linię przerywaną. Pozwoliło by to np. na precyzyjniejsze rysowanie przejść do budynków w parterze.
Rendering tak narysowanych i otagowanych na klasycznej mapie OSM w 2D mógłby wyglądać mniej więcej tak:
Linia przerywana to rzut budynku w parterze. Jak widać jest on mniejszy niż obrys dachu uzyskany ze zdjęcia lotniczego.
Obrys budynku w parterze, powinien zostać odpowiednio otagowany, na przykład:
multipolygon:inner oraz ground_floor:yes
Poniżej wynik w 3D bez formy dachu:
oraz z możliwa formą dachu:
Grubość połaci dachowej i rysowanie rzutu budynku
Formy połaci dachowej
Przewidziane są dwie formy połaci dachowej:
parallel | flat |
---|---|
Tagging: roof:thickness:parallel:yes | Tagging: roof:thickness:flat:yes |
Przykład:
Obrys budynku otagowany za pomocą:
- roof:thickness:parallel:yes
- roof type 2.0
- building:roof:extent:yes
Wynik:
Model szkieletowy budynku | Model szkieletowy dachu | Kompletny model szkieletowy | Kompletny model bez tekstur po renderingu |
---|---|---|---|
Wykusz, balkon, ogród zimowy, komin
Korzystajac z mozliwosci parametrycznego opisu punktu na obrysie budynku mozemy uzywac takich form architektonicznych jak wejście, zadaszenie, ogród zimowy, wykusz, balkon, mur oporowy czy komin oraz przypisac im odpowiednie parametry sprawiajace ze beda rysowane jako trójwymiarowe formy w viewerze 3D.
Obiekty tego typu sa dosc czesto:
- Powtarzalne
- Nie rozpoczynaja sie w przyziemiu (dlatego nie sa w sensie prawnym np. obrebem budynku)
- Nie sa zazwyczaj czescia powierzchni dachu
Elementy te wraz z lukarnami sa typowymi elementami budynków a umieszczenie ich zwieksza optyczna rozpoznawalnosc danego budynku i ulatwia poprawne ich oteksturowanie.
z zastosowaniem wszystkich mozliwosci tagowania:
Przyklad:
Uwaga: Aby uproscic tagowanie ogród zimowy (w Polsce potoczna nazwa np. oszklonej werandy) oraz wykusz stanowiace odrebne formy architektoniczne nie beda rozrózniane zas do stosowania ich uzywany bedzie tag "winter garden"
Tabela form Ogród zimowy / wykusz
Tabela form kominy
Uwaga: Róznica w funkcjonowaniu elementu komin (chimney) w odróznieniu od lukarny:
Komin lezacy czesciowo poza powierzchnia dachu jest liczony i pokazywany w modelu 3D az do powierzchni ziemi.
Tabela form balkony
soon
Tabela form mur oporowy
Mury oporowe sa rysowane jako punkty z odpowienimi tagami. Kierunek muru oporowego to zawsze dwusieczna kata dwóch sasiadujacych wektorów, przy czym dlugosc muru oporowego "D" rysowana jest zawsze na zewnatrz. Jesli ktos zechce rysowac skomplikowany mur oporowy nie znajdujacy sie w ponizszym opisie, musi uzyc schematu taggingu uzytego dla elementu "Sciana" opisanego na stronie "OSM-4D"
Tagging
Key | Description | Example values |
---|---|---|
building:roof:oriel | to describe point as oriel or winter garden | soon |
building:roof:chimney | to describe point as chimney | soon |
building:roof:balcony | to describe point as balcony | soon |
Tabela translacji nazw
Numeryczny opis niektórych form dachów odpowiada tradycyjnemu opisowi slownemu np. ze strony:Proposed_features/Building_attributes:
"roof table" | "building attributes" |
---|---|
0.0 | flat |
1.0 | skillion |
2.0 | gabled |
2.3 | half-hipped |
2.4 | hipped |
2.5 | pyramidal |
3.0 | saltbox |
3.1 | double_saltbox |
3.2 | corner_saltbox |
3.3 | triple_saltbox |
3.4 | quadruple_saltbox |
4.0 | gambrel |
4.1 , 4.2 | mansard |
4.3 | helm |
5.0 | round |
5.2 | half_round |
5.6 | dome |
6.0 | three_aisled |
6.2 | crosspitched |
6.3 | five_aisled |
7.1.n | sawtooth |
7.2.n | trapeze |
7.3.n | gabled_row |
7.4.n | round_row |
7.5.n | wave |
Atrybuty te powinny byc w przyszlym viewerze traktowane tak samo, jak opis numeryczny.
Tabela porównawcza
szkice ze stronki - roof_table - atrybuty jako pdf: --Geri-oc 18:43, 7 Grudnia 2011 (UTC)