3D - tematyka ogólna

Ponieważ wyszukiwarka na forum słabo działa np. nie wyszukuje krótkich fraz jak “3D”, chciałbym uporządkować pisanie o 3D.
W tym celu zakładam ten wątek jako ogólny gdzie można pisać wszystko o 3D, oraz założę drugi, w którym będą linki do starych postów traktujących o 3D czyli taki jakby spis treści aby się posty nie dublowały i aby nie szukać wiele lat wstecz czy nie można się podpiąć pod bliski tematycznie post.

Czy ktoś ma pozytywne doświadczenia z wykorzystaniem tagu ele=* w serwisach 3D?
demo.f4map.com ponoć wspiera tag ele ale dziwnie to działa i jeszcze nie skumałem .
Prawdopodobnie renderuje lekki wnios terenu na podstawie poziomic STRM co powoduje zmiany obiektów 3D o niskiej wysokości np. mniej niż pół metra.

Mnie bardziej interesuje jak maperzy dodają ele do samych obiektów czyli głównie budynków i czy w ten sposób udaje się wyeliminować konflikty, że np. teren z jednej strony budynku jest wyżej niż z drugiej albo, że pewne budowle są na nasypach czy rozmaitych skarpach, których uskoki czyli różnice wysokości bardzo mocno się zmieniają na krótkich odcinkach co powoduje, że trudno wybrać dla grupy budynków punkt odniesienia, do którego te budynki należałoby równać co do wysokości elementów budynku

Chodzi mi o użycie tego najwyższego przycisku w Graphic options /Ground elevations
http://demo.f4map.com/#camera.theta=0.9

Swego czasu bawiłem się budynkiem w Szczecinie który po części południowej jest “pod ziemią” na dwie kondygnacje. Niestety o tagu ele=* czytam tu pierwszy raz.

Co do ostatniego Graphic options/Ground elevations poziom ziemi lekko się podniósł po tej południowej stronie ale nie na tyle by ukazać to dokładniej na demo.f4map.com

http://demo.f4map.com/#lat=53.4320939&lon=14.5148616&zoom=20&camera.theta=77.659&camera.phi=-113.159

A to jest ten budynek u Googla: https://goo.gl/maps/ijEeUc5jgZG2

demo.f4 ładnie obsługuje tagi height i min_height nie tylko dla budynków ale jeszcze nie próbowałem z wartościami ujemnymi aby coś ukryć pod ziemią.
Ale łatwo ukryć jakieś obiekty 3D zagłębiając je częściowo w innej bryle.

Jest poważny mankament, że obiekty typu building:part renderują się tylko gdy znajdują się wewnątrz building=yes.
Gdyby do specyfikacji 3D dodać jakiś inny tag przypominający fundament/obrys ale nie będący buildung=yes można by tworzyć bryły imitujące rozmaite skarpy i w ten sposób wymodelować teren wokół budynku.

Sam tag ele=* jeśli będzie obsługiwany, nie jest w stanie odwzorować krzywizny gruntu.
Nie ma gdzie go dodawać, bo dodany do budynku będzie dotyczył całego obrysu czyli stanie się poziomem "podmurówki.

Trzeba by dodawać punktowo ele w kilku miejscach wokół budynku tylko pytanie do czego? W OSM nie ma obiektów związanych z poziomem gruntu poza szczytami górskimi.
Taka prosta sprawa a rozwala rysowanie osiedli na stokach górskich czy na nabrzeżach rzek. Jako podstawę brył 3D (nasypów ) można by przyjąć klucz man_made= i wymodelować bryłami nierówny poziom
Tu tez przydałaby się obsługa wysokości ujemnych od średniego poziomu grupy budynków aby nie trzeba było przeliczać brył budynkowych. Ułatwiłoby to rysowanie wjazdów do podziemnych budynków czy podejść do zamków na wzniesieniach. Wymagałoby to nowych tagów wysokości np. dla drzew aby nie mierzyć względem 0 n.p.m ale od szczytu zielonej bryły imitującej stok góry.
Mapa 3D koncentrująca się tylko na budynkach łatwo ukazuje absurdy gdy inne obiekty renderowane nie są umieszczane na właściwym poziomie.
Właśnie walczę z umieszczeniem torów na nadziemnych bezkolizyjnych estakadach.Podobny problem będzie gdy się wymodeluje wiadukty wiszące wysoko nad rzekami.

Prawdopodobnie demo.f4 stara się nasypać gruntu od strony wyższej poziomicy tzn., że grunt jest lekko ukośny.
Niewykluczone, że tam gdzie są strome “poziomice” np. wąwóz wycięty przez rzekę przy zamku na górze, render demo.f4 da ciekawy efekt.
Ciekawi mnie np. czy jeśli przy takim zamku będą tarasy z ogrodami to czy skosy gruntu wchłoną niskie elementy, czy też można będzie ręcznie sterować ele np. do poziomowania takich tarasów.

Pojawiła się nowa wersja programu blender-osm importującego poziom terenu https://gumroad.com/l/blender-osm

Gdzie lidar nie sięgnie tam gołębia pośle.
https://www.facebook.com/MGGPAero/photos/a.495921050428142.110379.379026668784248/1347018765318362/?type=3&theater

Dysponuję uwolnionymi przez UM danymi wysokościowymi wrocławskich budynków pochodzącymi ze skanu LIDAREM_ALS.
Jest to wysokość maksymalna zdaje się pomiaru ok 4-6 szt na m2. Mam to otwarte w JOSMIE jako shp (przez OpenData).
Dane umieszczone są jako centroidy czyli na jednym nodzie w środku budynku
ref jako OBIEKTID =xxxxx oraz zapis wysokości z separatorem z kropką (zgodne z osm) jako WYS_MAX=xx.yy

Dane dotyczą ok 120.000 budynków i są sprzed 2 lat.
Warunki wykorzystania i przetwarzania:brak ograniczeń.

Mogę to trzymać w oddzielnej warstwie i łączyć z obrysami ręcznie, dzięki czemu mogę dane z nodów usuwać i zapisywać na kompie warstwę bez danych z OSM aby nie było konfliktów przy przeciągającym się łączeniu danych.

Może dałoby się to połączyć automatem ale budynki z wyliczonymi centroidami nie zawsze zgadzają się z budynkami zaimportowanymi kilka lat temu do OSM.Jest też dużo budynków podzielonych na części, które mają różne wysokości nadane przy mapowaniu 3D więc tu automat miałby problem z czym łączyć.

Mógłbym zaznaczać w jednej warstwie(shp) i wysyłać po kilkaset a następnie ściągać je z bazy OSM do jednej warstwy z poligonami i po połączeniu nody usuwać .Wtedy nikt nie poprzestawia nodów poza centroidę właściwych budynków.
Drobne importy nie będą chyba wymagały zgody OSMF.

No chyba, że jest jakiś prosty sposób aby kopiować tagi z noda i łatwo przełączać się między warstwami lub scalać je kawałkami aby wysyłać te dane sukcesywnie w miarę łączenia

Znając realia OSM zanim ktoś napisze filtr importu, Ty już skończysz wprowadzanie ręcznie tych danych, tym bardziej że są problemy z obrysami jak sam piszesz. W sumie piękna sprawa, wysokości bydynków praktycznie się nie zmieniają, więc jest szansa że Wrocław będzie najlepiej zmapowany w 3D w całej Polsce.

Koledzy i koleżanki z Forum, być może ktoś ma ochotę wziąć udział w tym projekcie? Ja w tej chwili jestem skupiony na wschodniej części Nepalu.

Zrobię to tak, że wyślę w małych paczkach jako nody aby się OSMF nie pultało.
Nie będzie ingerencji w geometrię ani automatycznych przekształceń to OSMF nic do tego.Warunki korzystania z danych są na SIP Wrocławia więc chyba nie potrzeba pisemnej zgody.

Każdy będzie mógł kopiować tagi z noda i przenosić na obrys, bo mi ręcznie to trochę zajmie ale może to zaktywizować lokalusów do zainteresowania się 3D.

Zmienię tagi na nodzie położonym na centroidzie na:

OBJECTID_height_lidar=83043
building:colour=#ffe0a0
height=8.94
source:height=lidar_ALS-2015_UM_W-w_height-max

Nadanie uniwersalnego żółtego koloru dla fasad pozwoli mieć rozeznanie w serwisie 3D, które osiedla już mają przeniesione wysokości na obrys. Kolor to najczęściej używany w farbach elewacyjnych lekko wypłowiały.

Wystarczy kliknąć w noda potem skopiuj wszystkie klucze/wartości po czym “Wklej znaczniki”. Nie poddaję skrótów klawiaturowych, bo sobie poprzestawiałem i nie pamiętam jak ma JOSM oryginalnie.Wklejanie ma skrót ale kopiować trzeba myszką-prawoklikiem z okienka z tagami.

EDIT: Nie wiem tylko czy ref/ID noda pozostawić.

Nie polecam przenoszenia przy już zmapowanych w 3D budynkach, bo lidar może mierzyć nie kalenice a wystające kominy czy szczyty wieżyczek i wtedy rozjadą się proporcje budynku np. pozapadają się lukarny. Tam można height_max skopiować do description to w przyszłości budynek się przebuduje po sprawdzeniu dalmierzem. Spróbuję dopytać czy jakoś uśredniali aby kominy czy piorunochrony oraz krzyże szczytowe eliminować ale raczej nie.
Przy kościołach lidar mógł nie trafić w ostry szczyt skoro strzelał co 50 cm zatem pomiar może być zaniżony na ostrym ostrosłupie.
Podawałem linka do przetargu że niebawem będą nowe dane z lidara to się porówna w excelu czy nowy skaning różni się od starego.
Choć dane mają chyba dokładność około 10 cm to należy brać pod uwagę, że samolot nie zawsze jest idealnie nad obiektem a turbulencje zmieniają kąt lotu toteż pozycja GPS samolotu nie musi odpowiadać pozycji budynku zatem zapewne odrzucają dane 50-100 cm od obrysu budynku aby nie załapał się sąsiedni.
Zatem gdy wieżyczka jest na skraju albo jest to dach jednospadowy typu skillion to najwyższy punkt może nie być uchwycony.
Również dachy dzielone podwyższonymi ścianami szczytowymi czy świetliki lub anteny mogą zafałszować wynik

Popieram,
dobry pomysł! :slight_smile:

Moim zdaniem to jest idealne zadanie dla MapRoulette. Import punktów wysokościowych (w formie centroidów) zassanie ich do MapRoulette na podstawie jakiegoś tagu i łączenie tego w JOSM. Dzięki temu zostałby także ogląd ile z nich było trafionych a ile budynków przestało istnieć.

Powinno być na odwrót, należałoby nadawać kolor niespotykany w terenie, np. czarny. Jak inaczej zorientować się, że kolor jest domyślny, a nie rzeczywisty?
A i tak jest to zbędne, bo source:height będzie wprost wskazywał, które budynki mają przeniesione wysokości.

To, że jest naniesiona wysokość to nie znaczy, że obiekt jest w 3D.
Ja naniosłem dużo tagów wysokości, bo były dostępne z WMS’u, ale nic po za tym.

Oczywiście, że nadanie koloru fasady ma służyć wyłapaniu obiektów drugiej kategorii jak garaże czy też obiekty dla których pominięto nadanie wysokości czy to z braku danych czy przez przeoczenie.
Jednolity kolor dla całej ulicy czy dzielnicy dobrze wskazuje gdzie trzeba, najlepiej na podstawie wizyty dobrać kolor fasady, bo pobieranie kolorów ze zdjęć obdarzone jest dużym błędem.
Nie ma najmniejszej wątpliwości że na takim osiedlu nie nadano kolorów fasadom

http://demo.f4map.com/#lat=51.0829514&lon=17.0169122&zoom=17

Szczególnie, że zabrałem się za nanoszenie kolorów pasami tzn, innych dla każdego piętra czy strony budynku.

Ci co robili w 3D wiedzą jak to jest pracochłonne i że większym problemem jest trudność ze mapowaniem dachu, który rzadko kiedy ma podstawę kwadratową czy prostokątną. Dachy składają się z kilku do kilkunastu płaszczyzn. Składają się z kilku przenikających brył z których każda partiami pokryta jest dachówką i papą a z dołu wydaje się, że cały dach jest w dachówce.

Zatem mapowanie 3D przypomina mapowanie na OSM tzn przechodzenie od prostego tagowania bryły budynku i dachu do wielogodzinnego mapowania wielu drobnych szczegółów jak lukarny gdzie wyliczenie trygonometryczne z proporcji na zdjęciach rozmijają się z idealnymi punktami przecięć brył.Wynika to z tego, że choć są tagi do sterowania kątami płaszczyzn to jednak rendery przyjmują pewne kąty jak im wygodniej.
Do czasu pełnego wdrożenia specyfikacji tagów 3dr trzeba kombinować.Zatem gdy dach jest krzywy nadanie koloru fasady czy przybudówki to rzecz drugorzędna. Oprócz informacji dla mapera chodzi o wykorzystanie efektu skali aby dokładnie zmapowane budynki nie były odosobnione, lecz były na tle budynków zmapowanych pobieżnie.

Zresztą te dane z lidara bardzo mnie rozczarowały, bo często np. rząd garaży różni się wysokością ok 50 cm albo niższy budynek ma w bazie wyższą wysokość niż sąsiedni który jest wyższy.
Zatem te dane z lidara trzeba traktować jako tymczasowe do czasu pomiaru z dalmierza lub do porównania z przyszłym skaningiem laserowym który obnaży błędy lub pozwoli uśrednić.

Zasada na OSM jest taka, że tagujemy ogólnie aby mapa zaczęła czemuś służyć. Potem doszczegóławiamy.
Jeśli przez tyle lat budynki były białymi kostkami z przypadkowo nadanymi wysokościami to teraz będzie lepiej gdy budynki będą miały typowy jasnożółto-pomarańczowy kolor elewacji i bryłę dachu o właściwej wysokości(szczyt) .

Łączenie automatyczne nie miało sensu i mam obawy co do ręcznego łączenia przez osoby które nie mapowały w 3D.
Często zostawili kilka punktów na jednym budynku bo widzieli że algorytm uśredniania źle zadziałał
Te same dane są na mapie UM pod nazwą hipsometryczna. Wydawałoby się, że wysokość maksymalna jest najbardziej odporna na błędy uśredniania i wystarczy wyłapać tylko wartości ekstremalne jak kominy czy anteny aby je odrzucić do wyliczania wysokości średniej a jeszcze prościej do maksymalnej.

Prosty przykład. Budynek garażowy ze skośnym płaskim dachem skos 3,5-2,6 m ma wynik pomiaru ponad 7 m czyli więcej niż sąsiedni budynek który jest bez wątpienia wyższy a zmierzyli go na 7,17 m.

Można by sądzić że złapano uskok czyli krawędź między budynkami ale te krawędzie akurat są jednakowe i są najniższymi krawędziami które mogły to zafałszować gdyby nie to że to dach gabbled gdzie dolna jego krawędź jest jednocześnie krawędzią budynku, który źle zmierzyli
Zatem trzeba porównywać z mapą hipsometryczna bo tam podziały budynków są inne niż przy importach.Trzeba posługiwać się zdjęciami.
Jednak przyspiesza to mapowanie budynków wyglądających jakby były niskimi garażami do 3 m a mają naprawdę 6-7.
Lidar ma mniejszy błąd niż wynikający z uwzględniania pochyłości dachu przy pomiarach na zdjęciach.

Zatem wiele informacji na temat jakości danych maper wyciąga porównując wysokości kilku sąsiadujących budynków szczególnie gdy widać ze są jednakowe a lidar wykazuje różnice może nawet 2 m. Nie wypowiadam się bo dopiero się temu przyglądam .Lidar z pomiarami h_max bardzo się przydaje do wyznaczania wysokości kościołów

Inny przykład to przy wieżowcach jakieś automaty wydzieliły jako oddzielne budynki daszki nad wejściami.
Mimo to nadano in wysokości ok 35 m.

Zatem wszytko będzie wymagało sprawdzenia na miejscu a do tego czasu dane trzeba traktować jako zgrubne które pokazują charakter osiedla tzn ilupiętrowe są kamienice, czy piętra są wyższe niż 3 m, jakie są tam typowe dachy, jaka kolorystyka budynków czyli czy tynki brudne czy kamienice odmalowane.

Nie ma się co skupiać nad kolorystyką fasad bo w większości są połączeniem wielu różnokolorowych płaszczyzn,.
Tam gdzie stosowano najtańszą i najbardziej odporną na płowienie emulsyjną farbę żółto-pamarańczową, elewacje są najbardziej jednolite bo gdzie się robi tanio to się nie rysowało pasków.

Tak samo jak przyjąłem najbardziej typowy kolor elewacji, przy zgrubnym mapowaniu nadaje się dachom jednolity kolor dachówki bo informacja jest zawarta w proporcjach i kształtach dachów wielu sąsiadujących budynków a nie to który ma najnowszą dachówkę.

Serwisy słabo obsługiwały kolory bo np. demo.f4 kolory sam zmienia mieszając je np z cieniami czy nasłonecznieniem.Inne serwisy i tak dachy robią jednym czerwonym kolorkiem

Dlatego każdy kto przegląda miasta mapowane w 3D widzi, że trudno wskazać miejsce gdzie te dachy są w realistycznych kolorach

Są dla kilku miast tworzone serwisy 3D przez firmy komercyjne (aero) na podstawie zdjęć orto czy do serwisów “ukośne”.
Podzielili budynki na wiele trójkątnych brył i naciągali na to tekstury ze zdjęć.
Koszmarnie to wygląda. Zatem musimy się spieszyć aby mapa 3D do czegoś służyła, bo gdy opracują technologie teksturowania to nikt naszych map nie będzie chciał.
Certolić to się można z jednym budynkiem czy z 50, a nie ze 100.000.
Wszystkie narzędzia do 3D jak zdjęcia ukośne, pipety do pobierania kolorów itp nie działają.
Na dodatek gdyby robić zgodnie ze specyfikacja to się 70-80 % nie wyrenderuje jak się chciało.

Powiem w skrócie że ten samy tag nie działa zawsze tak samo.Wystarczy ze występuje w kombinacji z innymi tagami i już działa inaczej.
Albo jak się tag renderuje zależy od tego jaka jest odległość do innych obiektów.
Ten sam tag inaczej się wyrenderuje gdy zmienimy gabaryty obiektu.
Bardzo trudno dobrać kolor, który jest albo kolorem brudnym (zakurzonym) albo wypłowiałym. Brakuje kanału alfa dla RGB.
Może to tylko kwestia monitora LCD.
Zatem tak jak w 2D nie jest ważne czy track jest przesunięty 2 m czy nawet 20 m, ale to czy przecina rzekę tam gdzie jest most.Rzut oka na mapę 2D mówi z ilości tracków czy to mapa dokładna, a nie to czy orto było dobrze skalibrowane.Tak samo na 3D potrzebny jest efekt skali (tło) bo inaczej dłubanie przez kilka dni w jednym budynku traci sens, bo do czego taką mapę poza mapowaniem wykorzystać gdy zmapowane jest mniej niż 1% budynków?

Gdy się patrzy na mapę 3D to widać że są pogięte dachy a nie że kolor elewacji jest niewłaściwy.W dużym oddaleniu patrzy się ile jest budynków 3-wymiarowych a w dużym przybliżeniu patrzy się jakie szczegóły są odwzorowane.Są nieźle zmapowane miasta gdzie całkowicie odstąpiono od kolorowanie fasad a nawet dachów.
Proszę sprawdzić np. kreml i okolice jak dobrano kolory mimo koszmarnie żmudnej roboty z bryłami.
OSm to mapa publikowana w trakcie tworzenia i trzeba właściwie wybrać kolejność zadań aby uzyskć efekt albo aby spełnić oczekiwania ogladajacych. Oglądający chcą zobaczyć coś czego jeszcze nie widzieli.To jak scenografia w teatrze, gdzie wszystko z tektury a liczy się nastrój i i ekspresja.Mózg pracuje skojarzeniami i ponoć 85% tego co mózg prezentuje nie jest tym co widzimy ale tym co kiedyś zapisano w nim,.Dlatego wspaniałą efekty można uzyskać iluzją.
Na OSM taka iluzja jest w 2D gdzie na kiepsko zmapowanych obszarach mapa wydaje się dobra dzięki lasom bo mózg widzi precyzyjną linię lasu a nie to czego brakuje stad wrażenie dokładności i szczegółowości.

Wiem co mówię jako osoba jedna z tych co najwięcej zmapowali w 3D choć gro czasu przeznaczyłem na inne kategorie.
Można sobie narzucić inne tempo i inną metodę pracy ale wiem jak długo się wózek pociągnie gdy efekty nie będą zachwycać a pojawią się problemy, które będą niemożliwe do przeskoczenia lub będą generować ogromną stratę czasu na pierdołki.

Z drugiej strony to jak w kawale o żydzie i kozie.Kto mapował w 3D to potem widzi że mapowanie w 2D to fraszka i idzie piorunem :slight_smile:

Skomplikowany budynek wymaga kilkunastu tagów.Wymaga kilkunastu brył a czasem kilkudziesięciu. Wymaga pomiarów lub porównań wzrokowych kilkudziesięciu lub kilkuset punktów.
Wymaga cofania się i zaczynania prawie od zera.W sumie wymaga podjęcia kilkuset czy nawet ponad tysiąca decyzji poprzedzonych próbami i eksperymentami aby zrozumieć ograniczenia renderu, przetestować różne kolory no i wybrać kompromis między dokładnością pojedynczego budynku a zmapowaniem większej ilości.Nakład pracy nigdy by mnie nie zachęcił do tej roboty gdyby nie obserwacja reakcji ludzi i sprawdzenie na co zwracają uwagę. Odpowiedź jest prosta.Ludzi szokuje wszystko co nowe.
Mapa musi nabrać jakiegoś kształtu (kompletności) aby ocenić czy to będzie do czegoś przydatne. Potem nastąpi druga faza czyli szlifowanie.

A co do kolorków to dziś oglądałem w realu ulice całkowicie przemalowane w ostatnim roku gdy ja je zmapowałem 2 lata temu.
W realu budynków się nie zaczyna od malowania a zostawia się to na koniec.Najlepiej gdy się zrobi foty tych budynków w dobrym oświetleniu ale najpierw trzeba mieć co kolorować, czyli co pokazać.

Materia jest skomplikowana i słabo opisana co sprawę znacznie pogarsza zwiększając pracochłonność co najmniej 3 krotnie.
Codziennie się czegoś uczę np. wczoraj dlaczego ten sam obiekt raz się renderuje a raz nie. Okazało się, że nie lubi sąsiedztwa pewnych obiektów.Kto by na to wpadł skoro w 2D takiego efektu nie ma? Ja kombinowałem zmieniając wiele cech tego obiektu i wnioski zaskakiwały, bo się skupiałem tylko na tym co modyfikowałem a nie na tym, że zmiana geometrii zbliżała obiekt do innych czyli przekraczała strefy zakazane/ochronne.

Albo zaskakiwało mnie, że render rozpoznał kolory HTML, których nie znalazłem nawet w googlach a wczoraj zauważyłem, że nie rozpoznaje prostego koloru brązowego.
Lidar pewnie jeszcze nie raz mnie zaskoczy, bo w 2 dni się o nim dowiedziałem więcej niż przez kilka lat.

I taka dygresja OT. Lidar potrafi mapować do kilkudziesięciu metrów pod wodą.

Kolejność nodów (ID) w bazie OSM

Zaskoczyło mnie dziś, że kolejność nodów w bazie osm jest odwrotna od kolejności wprowadzania. Ma to związek z tym, że specyfikacja 3D budynków ma się odnosić względem punktu początkowego nazwanego na wiki “S”
http://wiki.openstreetmap.org/wiki/Pl:OSM-4D/Roof_table

Dotąd nie sprawdzałem czy to działa więc przeprowadziłem test numeracji ID, w tym jaka jest kolejność gdy budynek rysujemy wtyczką buildings_tools gdzie to wygląda tak, że klikamy w punt startowy, przeciągamy myszką wzdłuż jednej krawędzi budynku tam klikamy drugi raz i ciągniemy w poprzek narysowanej linii gdzie klikamy 3 raz i mamy już budynek z 4 narożnikami.
Jest jeszcze metoda rysowania budynku za pomocą 2 kliknięć polegająca zdaje się na zaznaczeniu ulicy, do której równamy fasady, czyli ma to być i szybciej i równiej.

Okazuje się, że gdy wyślemy 4 nodowy budynek wrysowany ręcznie punkt po punkcie lub wtyczką to numeracja nodów jest odwrotna niż kolejność wprowadzania. Przy wtyczce gdy zaczniemy od górnego lewego narożnika to numeracja maleje w kierunku obrotu wskazówek zegara.

Już nie sprawdzam czy przy otwartych way jak drogi jest ta sama zasada ale to trochę dziwne. Mnie interesowało czy jeśli w 3D punkt S nie jest jeszcze wykorzystywany to czy nie dlatego, że wtyczka b_t numeruje nie po kolei lub nie można ustalić punktu początkowego, bo id są nadawane losowo.
To tylko jako ciekawostka, bo jeśli to sztywna reguła to nic nie możemy tu pokierować, no chyba że komuś będzie potrzeba wstawić same nody a potem je łączyć w nietypowej kolejności co może okazać się niewykonalne, bo JOSM może dać priorytet poligonowi przed nodami.

Pytanie istotne to takie czy ktoś zauważył czy punt S działa tzn. czy warto się nim kierować?
demo.f4map dla większości dachów ustala kierunek wzdłuż dłuższego boku ale przy skillion zdaje się kieruje spadkiem w stronę najbliższej drogi (nie testowałem) a spadek dostaje domyślnie 25% wysokości budynku (nie testowałem).

Tak więc punkt S byłby przydatny przy skillion, szczególnie przy odmianie gdzie każdy narożnik ma inną wysokość.

Tu musimy chyba pociągnąć za język Marka autora większości specyfikacji budynków 3D, bo przy mojej pamięci do języków nie chce mi się wdawać w dyskusje na forum międzynarodowym. Zatem Marku jeśli nie pamiętasz to będzie prośba o przekładanie pytań na forum 3D bo czas tę wiedzę odsiać i żebrać do kupy praktyczne informacje, bo teoretyczne i nie działające mocno zniechęcają

Chcę tu zrobić poradnik co działa a co nie nie działa (szczególnie w demo.f4 które obejmuje Polskę) bo wygląda że 70-80% specyfikacji nie działa.

Mając wiedzę co działa można zaoszczędzić wiele czasu na eksperymenty co może da impuls do postępów w 3D to zaś może zachęcić sewisy renderujące do wdrożeń.

Mam trudne pytanie do informatyków.
Ile trzeba kasy na wdrożenie polskiego serwisu 3D, bo miasta płacą za zdjęcia orto oraz pomiary NMT i to odświeżając te dane co kilka lat?
Z tego co słyszałem nie istnieje żadna baza danych wysokościowych więc niejedna instytucja chciałaby do tego jakieś dane wnieść. Rozmawiałem wczoraj o tym pobieżnie z członkiem Stowarzyszenia Architektów Polskich.Znam zaangażowanych w portale społecznościowe osoby z nadzoru budowlanego i można sprawdzić jaki byłby dostęp do planów budowlanych.
Opracowanie kodu dla funkcji 3D które w amatorskich serwisach jeszcze nie działają, to zadanie na zajęcia dla studentów. Który student architektury nie chciałby zaprezentować swoich modeli w 3D?
Rozwija się druk 3D a nie ma portalu gdzie by można magazynować realizacje i projekty aby uwolnione modele drukować w formie makiet np. osiedla np. przy sprzedaży domu przez dewelopera. Architekci mogliby szybko prezentować projekty domków do sprzedaży.Zatem środki na utrzymanie serwisu by się znalazły ale obecny stan renderu jest tragiczny wobec rozwoju technik komputerowych i pomiarowych.
Komercyjny serwis F4map pewnie dotychczasowego kodu nie uwolni ale można by zrezygnować z wodotrysków jak cieniowanie a zając się przeliczaniem brył.
Nie orientuję się czy technologia WebGL ma ograniczenia, że brakuje możliwości renderu wnęk, ażurów czy nawet prostych dachów.
Tyle osób pracuje nad darmowym softem w wielu dziedzinach w tym CAD a nie można wdrożyć specyfikacji 3D?

Stąd pytaniem gdyby zaproponować 3D urzędnikom do promocji miasta to na ile spełnienie ich oczekiwań popartych sponsorowaniem miałoby szanse na realizację w jakiś małych krokach lub w utrzymaniu serwisu z gwarancją, że nie będzie wyłączony.

Mamy przeciecz 3D na osmapie. Mamy implementację od kendzi-ego.
Jak to jest, że kiedyś był zapal aby coś stworzyć a nie ciągnie się tego dalej aby to upowszechnić i stało się praktyczne?
Przez dwa lata jak miałem przerwę w mapowaniu w 3D chyba nic się nie rozwinęło.

Sądzę, ze wobec potanienia dalmierzy uda mi się porobić jakieś testy. Może potestuję też teodolity, sekstanty czy inne narzędzia wychodzące z użycia więc możliwe do kupienia za grosze. Może opracuję jakieś arkusze kalkulacyjne do przeliczania danych z serwisów ukośne czy z pomiarów kątów takimi optycznymi przyrządami.
Może zrobię poradnik 3D co działa a co nie, z poradami jak przyspieszyć robotę.

Np. wczoraj robiąc zdjęcia pomyślałem o wzorach przeliczających ogniskową i rozdzielczość itp. aby wykorzystywać do pomiarów wysokości zwykły aparat.
To banalnie proste, bo jeśli zrobimy fotkę i podejdziemy do budynku o 10 m to porównując dwa zdjęcia możemy wyliczyć wysokości podkładając te zdjęcia do JOSMa.

Albo można zoomować aż obiekt wypełni kadr a w domu odczytać ogniskową z EXIFa.
Jest wiele charakterystycznych punktów jak latarnie czy narożniki trawników jako miejsce stania. Wystarczy mieć starą wojskową lornetką z podziałką kątową a wysokości dachów można sobie wyliczyć.
Nawet na tanią chińską lornetkę za 30 zł można nakleić folię z kilkoma znacznikami. Jeśli linie będą nieprecyzyjnie naniesione to wystarczy zbliżać się do budynku i znaleźć punkt stania gdzie dach czy budynek mieści się między znacznikami.
Znając punkt stania i kalibrując lornetkę do znanej wysokości można w JOSMIE prosto wyliczać wysokości.
Kiedyś Chińczycy na aliexpress oferowali długopisy z kątomierzem do pomiarów wysokości drzew. Patrzyło się przez taki długopis pusty w środku jak przez lunetkę i na ruchomym kątomierzu odczytywało kąt. Chwilowo nie znalazłem ale to kosztowało pewnie 10-20 zł.
Wiele statywów do aparatów ma podziałkę kątową więc wystarczy celować skrajem kadru lub ramką jaka się wyświetla pokazując obszar łapania ostrości, a w josmie znaleźć miejsce stania i wysokość liczy się w kilka sekund.Tak patrzyłem sobie wczoraj z oddali że typowa wysokość dachów to 4-6 stopni kątowych więc dokładność 1 stopnia w dalmierzach nie jest powalająca i można nawet palcami wysokość zmierzyć, bo np szerokość pięści to około 8 stopni.
Zatem można sobie zrobić prostą laskę Jakuba wykorzystując kijek długi na 50 cm przypinając do niego pineską kawałek papieru milimetrowego.Starożytni mierzyli odległości gwiazd, wyznaczali pozycję na morzu, mierzyli rozmiar ziemi czy odległości od księżyca czy słońca, a my nie możemy zmierzyć wysokości budynków gdy kalkulator z tangensami można kupić za 5 zł?

Pewnie niejeden przechodzień by się zdziwił jak a pomocą tip-topków do odmierzania 10 m i dwóch zdjęć z aparatu można wyliczać wysokości wielu punktów na budynku.

Skoro będą dane wysokościowe to pytanie czy można usprawnić render aby maperzy widzieli efekty swej pracy, bo nic tak nie demobilizuje jak zastój?
Tyle stowarzyszeń dostaje kasę na pierdołkowe akcje np wyświetlanie filmów na ścianie budynku.
Tak przed chwilą kliknąłem na bliski nam projekt.Kasa leży na ulicy a informatycy otwierają warzywniaki.

http://www.wroclaw.sarp.org.pl/pl/news/konkursy/open-call-konkurs-na-wydarzenia-z-programu-dofa-17

Jest kasa na domki z tektury
http://www.sarp.org.pl/pokaz/program_brimee,2393/

Wcale bym się nie zdziwił gdyby były jakieś projekty 3D skoro świat się cyfryzuje. Np. operatorzy komórkowi mają bardzo precyzyjne dane wysokości gruntu, bo od tego zależy ich zasięg.
Powinniśmy nawiązać kontakty z GISowcami , bo możliwości są a nowe będą się otwierać.
Np. u mnie SIP szuka człowieka do “mapowania”.
Jak to jest, że OSMF to tak liczne stowarzyszenie a tak mało dotacji unijnych? Żadnych konkursów na rozwój OSM.
Byle konkurs na wydziale architektury czy w UM i ludzie zgłaszają za friko do samej nagrody (zwykle 5- 15 tys zł), dziesiątki czy setki projektów.

Czy problem leży w braku pieniędzy czy braku w Polsce ludzi z zapałem?
Nie było danych był zapał, są dane to brakuje rozwoju wizualizacji. Powinno być odwrotnie tzn. gdy już trudniej coś znaleźć niezmapowanego to informatycy powinni realizować się w sofcie.

@Rowers2 - zadziwia mnie Twoje podejście (na plus) i objętość postów, widzę, że bardzo pasjonuje Cię ten temat.

Stworzenie specyfikacji do szybkiego tworzenia obiektów w 3D obejmującą rozwiązanie różnych problemów modelarskich nie jest trywialne - moim zdaniem rozwój takiej specyfikacji musi iść w parze z rozwojem aplikacji bazującej na niej. Wymyślanie teorii to jedno, ale zastosowanie w praktyce - to drugie.

Technologie renderu moim zdaniem nie mają tu większego znaczenia - prawidłowo skonstruowany system i tak stworzy model bazujący na trójkątach, który może być wyświetlany przez dowolny silnik graficzny 3D, czy to będzie WebGL czy OpenGL/DirectX w natywnej aplikacji - nie ma większego znaczenia.

Paręnaście lat temu (zacząłem na studiach) pracowałem nad systemem do rekonstrukcji (BluePrint Modeler) z planów architektonicznych - porzuciłem jego rozwój, bo nie widziałem większego zainteresowania modelingiem 3D i widziałem że aby zrobić coś ekstra trzeba mieć naprawdę sporo czasu i kasy. Zresztą zrobić aplikację to jedno, sprzedać ją i rozwijać - to inna kwestia. Do tego potrzebne są i pieniądze i całe zaplecze reklamowo, marketingowe. A i tak ręczny modeling marketingowo przegrywa z automatyką, gdzie duże firmy stosujące taki (często przybliżony i niezbyt dokładny) modeling idą na ilość i nie pokażą rekonstrukcji kilku budynków lecz całe miasta. Całe wymodelowane miasto zresztą można sprzedać większym firmom (np. tworzącym nawigacje czy robiącym złożone analizy), sprzedaż pojedynczych modeli nie będzie pożądany.

W ciągu tego czasu trochę się zmieniło, firmy są trochę bardziej otwarte na rozwiązania modelowania w 3D, ale nie jest to temat generujący jakieś sensowne przychody dla szerszej rzeszy ludzi - więc jak ktoś ma inwestować i widzi, że 3D nie daje jakiś wielkich korzyści - to na tej samej zasadzie firmy tworzące oprogramowanie do modelowania również nie są skłonne w lepsze rozwiązania, skoro na rynku jest sporo skomercjalizowanych rozwiązań, nastawionych na ilość (automatyka) lub droższych i dopracowywanych przez duże firmy.
A w przypadku wolontariatu i hobbystów - trudno zaoferować im płatny produkt i zarobić na ich wsparciu (reklamy?) więc mnie osobiście sytuacja z 3D nie dziwi.

Z technologicznego punktu widzenia zrobienie systemu rozbija się też o kompatybilność. Inaczej będzie wyglądał system, który ma być ściśle dostosowany do jakiejś technologii i obsługiwanych formatów, a inaczej jak ma być w miarę uniwersalny. Z moich obecnych (świeższych) doświadczeń w rozwoju aplikacji CADowo-pomiarowych mogę wysnuć wniosek, iż często zrobienie czegoś, co będzie: proste w obsłudze, intuicyjne i dobrze wyglądające w odbiorze, elastyczne we wsparciu, dające duże możliwości wymaga sporej ilości iteracji przy tworzeniu takiego rozwiązania. Często jest tak, że zamiast koncentrować się na rozwoju wsparcia nowych funkcji, koncentrujesz się na rzeczach bardziej przyziemnych, związanych ze wsparciem użytkowników, poprawkami, zmianami lub dostosowaniem kodu tak, by był bardziej elastyczny lub przejrzysty i pasujący do zmieniającej się specyfikacji.

Chcesz systemu do prezentacji 3D, ale przede wszystkim musi mieć bazę modeli - ktoś musi nad tym pracować, ktoś świadczyć wsparcie.
Nawet najlepszy system modelowania padnie, jeśli zabraknie użytkowników i co za tym idzie wsparcia - także finansowego. Więc musisz technicznie mieć i ludzi z większym zapałem, zapewnić finansowanie na cały czas rozwoju, mieć budżet i strategię reklamy. Patrząc ogólnie trudne będzie w ogóle określenie widełek jeśli nie ma określonych z góry wszystkich wymogów.
Myślę, że mając budżet mniejszy niż 1 mln. zł i mniej niż 2 lata trudno oczekiwać rewelacji. Zresztą nawet przy budżecie tego rodzaju, gdy zatrudniasz większą ilość osób, wciąż pozostaje pole do potencjalnych zgrzytów odnośnie specyfikacji (jeden ekspert powie Ci - “zróbmy to tak”, drugi - “nie, zróbmy inaczej”), której opracowanie nie jest trywialne.

Z moich ostatnich wyliczeń (z kwietnia) związanych z PowerGPS, wyceniłem koszt modernizacji PowerGPS (w wersji dla WindowsPC i Androida), aby odpowiadał potrzebom wygodnego i kompletnego modelingu 3D i aby opierał się o optymalną specyfikację - z użyciem różnych metod pomiarowych i ustalania ich dokładności na min. 50-60 tys. zł netto (60-75 tys. zł brutto) przy założeniu min. 6-8 miesięcy prac (gdzie na końcu będzie i specyfikacja i odpowiedni moduł do aplikacji). Jest to realne, ale zdobycie takiego finansowania gorzej - bo właśnie chodzi o odbiorców i kwestie skąd pozyskać fundusze i czy w ogóle się to opłaci (obojętnie czy inwestorowi, który wyłoży kasę, czy mnie, jeśli miałbym to realizować na kredyt) - nie lubię takiego “zimnego” myślenia, ale takie niestety są realia.

Jeśli jesteś zainteresowany szczegółem prostych pomiarów z fotografii, odsyłam do swojej pracy (Photogrammetric Reconstruction Systems for VR), znajdziesz tam odpowiednie wzory i ustalenie dokładności takich pomiarów:

http://skyraster.com/firma/portfolio/fotogrametria-modelowanie

Narzędzia dla 3D i połączenia OSM-3D z kształtem terenu.
blender-osm - https://gumroad.com/l/blender-osm#
Forum => OpenStreetMap 3D => Adding elevation to osm - https://forum.openstreetmap.org/viewtopic.php?id=57920

Ciekawy projekt 3D rozwijany w ramach GSoC:

http://www.openstreetmap.org/user/n42k/diary

Fajnie by było zaimplementować styl mapki 3D w WebVR:

https://blog.mozilla.org/blog/2017/08/08/webvr-new-speedy-features/

Może kogoś zainteresuje to ogłoszenie i ankieta (najciekawsza jest próba zdefiniowania w 3D obiektów ze zdjęć po zakończeniu ankiety):

https://forum.openstreetmap.org/viewtopic.php?id=59480

A może ja poscalam wątki o 3D?
Bo z tą wyszukiwarką to nadal nie bangla. Scalać?