Ponieważ zakończyłem mapowanie gminy praktycznie w całości (budynki, obrysy obszarów zabudowanych, lasy, POI, drogi gruntowe, dojazdowe etc.) pozostały mnie kwestie zaawansowane i przynajmniej na mój obecny stan wiedzy trudniejsze do wykonania czyli zabawy w multipolygony i relacje za pomocą których należy wyrysować linie autobusowe, ścieżki, części budynków etc
Mam otwarte chyba z 10 zakładek z wiki o tym jak oznaczać budynki i relacje i za przeproszeniem wiem z tego tyle co o kupie kamieni Dla przykładu http://wiki.openstreetmap.org/wiki/Relation:building pisze by oznaczać części budynku jako [outline/part] gdzie JOSM mnie krzyczy, że to błąd i powinno być [outer/inner]. Gdyby ktoś mógł poprawić te błędnie renderujące się budynki byłbym wdzięczny. Z pewnością pozwoliło by mnie to iść dalej na bazie tych prostych przykładów, gdyż wzorowanie się na Złotych Tarasach czy Pałacu Kultury to póki co dla mnie pewien kosmos
Wiesz co, będę w Górznie przez 2 tygodnie : 4 do 18 sierpnia. Na Forum to trudno nieco tłumaczyć, ale można by zrobić małe wprowadzenie w mapowanie 3D.
Jeśli Ci nie pasuje, poprawię Ci te przykłady…
Ja już 1 dom poprawiłem (Siedliska 300)…nie wiem czy o to chodziło ale wyszło coś takiego: http://i.imgur.com/wGhyHwX.png
Zobacz sobie, może to coś pomoże. Generalnie rzeczy, które zauważyłem:
-wysokość budynku przechowujemy w tagu height (bez przedrostka building:)
-były problemy głównie z wysokością dachu (tzn. podajemy wysokość samego dachu)
A jeśli chodzi o relację to tagi takie jak na wiki (outline i part), josm krzyczy tak na wszelki wypadek I polecam zaintalować kendzi3d, ułatwia sprawę…można sobie ładnie podejrzeć efekty. Na f4 uważaj, nie zawsze dobrze renderuje.
Nie chodzi o to by mnie tylko wytłumaczyć, ale generalnie jak ktoś się za coś ma brać to by się nie zniechęcił jednak dość przydatny byłby opis “krok po kroku” przykładowego budynku zawierający wszystko to co konieczne by prawidłowo go przedstawić. Najlepiej na wiki, gdyż wątek z forum siłą rzeczy wcześniej czy później ucieknie do strony o takim numerze, że nawet wyszukiwanie go nie znajdzie
no i bomba dokładnie o to chodziło, choć ten daszek to powinien się jeszcze na całkiem sporym słupku wpierać, ale to zakładam powinienem już dodać dorysowując kolejny element budynku, gdyż siłą rzeczy jest on mniejszy niż sam daszek
dokładnie z tym miałem problemy. Widać źle to rozumiałem. Teraz rozumiem, że wystarczy tym samym samo “height=” oraz “roof:height” a “building:height” to ono sobie z tych dwóch wartości już policzy
Pewnie się nie obejdzie. Dzięki za podpowiedź.
EDIT: Siedliska 300 na F4 na chwilę obecną w ogóle jest niewidoczne Generalnie liczę by tak budynki otagować by na możliwie największej ilości renderów były widoczne
generalnie zawsze dobrze podpowiadał przy innych rzeczach, więc nie zakładałem problemu z aplikacją a raczej swoją niewiedzą pomyślę nad zgłoszeniem jak już trochę na wyższym stopniu opanuję rysowanie 3D
zastanawiam się jak powinienem przedstawić daszek dwuspadowy na zwykłej płaszczyźnie prostokąta z tym, że najwyższy punkt ma w jednym z rogów a kalenicę idącą do przeciwległego rogu. Biorąc zwykłe typy nijak nie chiał się on prawidłowo utworzyć. Wymyśliłem, że konieczne jest opisanie jako czterospadowy, ale ze szczytem w rogu (wartości lenght1 i 2 ustawić na 0)
Musimy to zaimplementować
S3DB to dla mnie etap pośredni.Ma jedynie… pokazać że coś może działać.
Za najprostsze i obywające się bez żadnych tagów uważam podejscie opisane pod koniec działu F3DB.
Dajmi parę dni na wrzucenie tam paru prościutkich przykładów.
Myślę że dla Kendziego zaimplementowanie tego będzie o wiele prostsze niż babranie się w parametryczne opisy geometrii dachów.
Podany przez Ciebie przykład zadziała w Kendzi3d. Niestety żadna inna aplikacja nie obsługuje Roof_table. Dach mógłby zostać opisany za pomocą Roof lines. Uproszczoną wersje wspierają zarówno O2W jak i Kendzi3d. Więc nie jest to dużo lepiej. Pozostaje jeszcze możliwość podzielenie dachu na dwie części i opisania obu spadów osobno. Jednak nie jest to eleganckie rozwiązanie.
Trochę z tagowaniem 3D budynków przystopowałem, gdyż wymaga to dużo więcej pracy niż zwykłe obrysy ale powrócę i do tego. Zapewne jak wieczory zrobią się dłuższe a już na pewno jak będzie można prosto otagować daszki jakich w sumie jest co kawałek, czyli taki jak podany przeze mnie w przykładzie
pole dachu na podstawie kwadratu
wierzchołek o wysokości h w jednym z rogów
dwuspadowy dach idący do przeciwległego rogu
przeciwległy róg jak i pozostałe rogi o wysokości h równiej zero
nieeleganckie rozwiązanie odpuszczę gdyż tylko podwaja ono ilość pracy, choć CTRL+C i CTRL+V na pewno będą tu pomocne
Nie chcę zakładać nowego wątku, bo sprawa w zasadzie dotyczy tego samego. Potrzebowałbym tagu, który da możliwość przesunięcia kalenicy dachu typu “gabled” o konkretną wartość w prawo lub lewo w stosunku do dłuższej osi budynku, a w przypadku zastosowania tagu roof:orientation= w prawo lub lewo od podanej wartości. Nie wiem czy taki sposób tagowania istnieje (czytaj - czy jest gdzieś zaimplementowany), ale w moim rejonie jest sporo budynków, które można by w prosty sposób przy zastosowaniu tego rozwiązania opisać. Gdzieś na forum spotkałem się z propozycją tagu roof:ridge:offset, która w tamtym wątku padła, ale została źle sformułowana (opisana). Natomiast przy dachach typu “gabled” miałaby pełne uzasadnienie.
Dołączam rysunek propozycji:
Jak rozumiem, to całość została zrobiona pod mapowanie 3d, tylko dlaczego korzystamy z nigdzie nieudokumentowanych ról part oraz outline? W sumie, to zgodnie ze specyfikacją multipolygonu, można dodać 3 sąsiadujące obiekty, każdy jako outer, i porządny algorytm powinien dodać te 3 obiekty, a o to chyba chodziło.
@ WiktorN
Podchodzę do poprawy tego już jakiś czas. Poprosiłem również o pomoc w poprawieniu tego oraz również dla innych dwóch budynków w tej ulicy http://forum.openstreetmap.org/viewtopic.php?id=22306&p=19 post 465. Uzyskałem co prawda podpowiedź jak to zrobić, ale jest to jakaś większa magia dla mnie i do kwestii multipolygonów podchodzę jak do jeża. Nie zgodzę się natomiast z tym że part/outline nie są nigdzie nie udokumentowane. Są co prawda w jedynie jako "proposed’, ale jednak są http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings
Będę wdzięczny za ogarnięcie tematu wspominanych trzech budynków tak jak powinien być. Z pewnością posłużą mnie jako wzorzec dla kolejnych w przyszłości
Uznałem, że po prostu to powinna być relacja type=building a nie type=multipolygon i tak zmieniłem na dwóch budynkach w okolicy. Jeden miał relation type=building i jego już nie dotykałem. JOSM tej relacji nie zna, ale nie ma problemu by go nauczyć
jeśli tak ma być to ok, choć mnogość tagów pod 3D przytłacza i łatwo się pogubić. Pytanie jeszcze pozostaje gdzie powinny być przypisane adresy w takiej sytuacji gdyż na mapie się nie wyświetlają na chwilę obecną