Przykłady OSM 3D

Czyli jak?.. :smiley: W każdym razie brzmi groźnie! :wink:

Gdzie można zgłosić coś takiego by gościa wyprostować? Do DWG?

Na szczęście widzę że jesteś odporny ale jak coś takiego komuś innemu wyśle to może go trwale zrazić do OSM.

Wspominam o tym w tym wątku, bo to się zaczęło od budynków 3D, na dodatek w błahej skali 5-6 lokalizacji, które on nieopatrznie lekko ‘uszkodził’. Wiem, że niespecjalnie, taki ma styl pracy, niezważający na innych mapowiczów (już wcześniej miałem z nim przygody). Teraz stosuje building:part i nie zostawia już po sobie taki tworów jak wyżej wskazałem. Problemem jest, że on nigdy nie odpowiada na uwagi, ani nigdy nie poprawia po sobie. Jak widać, nawet zostawiona uwaga nie skłoniła go do tego. I tak jak wcześniej bywało, ktoś po nim poprawi. Nie będzie tu wojny.

Ja nie wątpię, że to nie był jednorazowy wybryk. Nikt tak z siebie nie pisze listu będącego jedną wielką próbą manipulacji psychologicznej. Musiał robić wcześniej i to z sukcesem. Kiedyś pisał, że zjechał jakiegoś mapowicza tak, że ten przestał się odzywać.
Postanowiłem to zasygnalizować, bo nie chcę, by sytuacja się zaogniała.

Nie wiem, ale… zauważyliście, że się nie odzywa?

Panowie, proszę o umiarkowanie. Nie oceniajmy publicznie innych mapowiczów na podstawie własnych doświadczeń.
Osobiście widzę tutaj świetne modele 3D a z innej beczki odwalony kawał pracy przy area:highway przez kolegę rowers2.

Patrząc retrospektywnie OSM jest pełne bardzo różnych ludzi i przyciąga orginałów do których sam mam nadzieję się zaliczać :wink:
Ważne jest nasz wkład w projekt. Wyciągnijcie do siebie rękę.

http://demo.f4map.com/#lat=51.0190944&lon=17.1024947&zoom=17&camera.theta=26.952&camera.phi=80.501

Z całym szacunkiem dla kolegi rowers2, ale takie rzeczy za długo wiszą już.

Dodałem (kiedyś) generowanie siatek dachów do stylu osmapa.pl i od niedawna dopiero mam zaimportowane odpowiednie tagi na serwerze kafelków w związku z czym mogłem zacząć testować i poprawiać. Mam kilka pytań o tagowanie do ekspertów od 3D. Nie wszystkie typu dachów są obsługiwane, ale według http://taginfo.openstreetmap.org/keys/?key=roof%3Ashape#values wystarczająco aby obsłużyć 98% wystąpień. Część brył wygląda inaczej niż w F4map między innymi z braku Z-bufferingu. Według wiki należy unikać rysowania w taki sposób gdzie robiłoby to różnicę, ale widać, że w aktualnym modelu często nie da się inaczej.

  • dla dachów skillion jak ostatecznie wyznaczany jest kierunek? Wg. https://wiki.openstreetmap.org/wiki/Simple_3D_buildings szczyt dachu domyślnie jest równoległy do najdłuższej krawędzi, ale to nie jest pełna informacja w przypadku skillion. Wg. http://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table ma też znaczenie która krawędź jest pierwsza w obrysie ale rozumiem, że to dotyczy tylko schematu z tagami 3dr:*. Według http://wiki.openstreetmap.org/wiki/Talk:Simple_3D_buildings#roof:direction_.2F_roof:slope:direction z kolei w przypadku braku tagów roof:direction i roof:orientation (lub ich wariantów poprzedzonych “building:” lub ze “slope:” lub “ridge:” w środku… eh) ma znaczenie położenie prostokąta opisanego na budynku.

  • Ten prostokąt też jest wspomniany w http://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table ale nie jest nigdzie zdefiniowany… to ma być prostokąt o najmniejszym polu? najkrótszej krawędzi? najkrótszej przekątnej? najdłużeszj długiej krawędzi?

  • A jak ma działać przyciąganie kierunków geograficznych do najlbiższej krawędzi? Ma to szukać krawędzi najbardziej równoległej do kierunku z [building:]roof:[slope:]direction (tak aktualnie mam to zaimplementowane w SQLu) czy najbardziej prostopadłej?

  • Dobrze rozumiem, że jeśli wektor jest wyznaczony przez 3dr:direction lub roof:ridge:direction to trzeba go przed zastosowaniem obrócić o 90 stopni w lewo w stosunku do innych tagów?

  • W przypadku tego ozdobnego daszku: http://demo.f4map.com/#lat=52.2502282&lon=21.0116574&zoom=21&camera.theta=66.103&camera.phi=40.394 na jakiej podstawie F4map wnioskuje, że to jest dach gable? A może to bug w F4map?

  • Na warszawskim Starym Mieście są dwa budynki z roof:shape=hipped i roof:orientation=across, co wydaje się błędem z definicji, bo (o ile dach nie ma niestandardowych kątów wynikających z 3dr:length*=*, a nie ma) to szczyt dachu musi być równoległy do dłuższego boku prostokąta jesli ma mieć nieujemną długość. W związku z tym ignoruję roof:orientation w tym przypadku.

Proste odpowiedzi na początku:

= To wydaje się być bug.

  • Na warszawskim Starym Mieście są dwa budynki z roof:shape=hipped i roof:orientation=across, co wydaje się błędem z definicji, bo (o ile dach nie ma niestandardowych kątów wynikających z 3dr:length*=*, a nie ma) to szczyt dachu musi być równoległy do dłuższego boku prostokąta jesli ma mieć nieujemną długość. W związku z tym ignoruję roof:orientation w tym przypadku.

= Słusznie! Jest dokładnie tak, jak piszesz.

  • dla dachów skillion jak ostatecznie wyznaczany jest kierunek?
    = Zrobiłem kiedyś taki szkic, ale zniknął z głównej stronki wiki :http://wiki.openstreetmap.org/wiki/File:MarekRoofSlopeDirection.JPG

  • Ten prostokąt też jest wspomniany w http://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table ale nie jest nigdzie zdefiniowany… to ma być prostokąt o najmniejszym polu? najkrótszej krawędzi? najkrótszej przekątnej? najdłużeszj długiej krawędzi?
    = O najmniejszym polu.

  • A jak ma działać przyciąganie kierunków geograficznych do najlbiższej krawędzi? Ma to szukać krawędzi najbardziej równoległej do kierunku z [building:]roof:[slope:]direction (tak aktualnie mam to zaimplementowane w SQLu) czy najbardziej prostopadłej?
    = Możesz to opisać innymi słowami bo nie jestem pewien czy dobrze interpretuję pytanie.

  • Dobrze rozumiem, że jeśli wektor jest wyznaczony przez 3dr:direction lub roof:ridge:direction to trzeba go przed zastosowaniem obrócić o 90 stopni w lewo w stosunku do innych tagów?
    = Tu proszę by kolega Kendzi się wypowiedział.

Mam genialny (oczywiście) pomysł w związku z: http://www.openstreetmap.org/note/428474#map=19/52.24127/21.01314&layers=N .

A gdyby tak zaadaptować jakiś format modeli 3D, żeby zawierał również orientację geograficzną, żeby można było zrobić model dowolnego obiektu nie będącego budynkiem i specjalnym tagiem przypiąć go do obiektu w OSM?
Wtedy programy do renderingu 3D mogłyby sięgać po ten model i wyświetlać go w odpowiednim miejscu.

Pomysł był już w 2010 roku. Można wziąć np format obj i umieścić punkt będący linkiem do modelu który musiał by byc w określonej bazie danych. Id tego punktu w OSM mogło by być nazwą modelu 3D w formacie OBJ tak by uniknąć dyskusji o nazewnictwie i redundancji danych. Punkt jako atrybuty zawierał by skalę i obrót (rotation) danego modelu.

Tyle że to jest OSM: Ktoś to musi zaimplementować… O to się sprawa rozbija.

Widzę drobne różnice między tymi pomysłami. Ten z 2010 ma lepsze to, że nic nie trzeba adaptować, dane, które chciałem dodawać do modelu są w OSM (skala i obrót). Mój ma lepsze to, że w zasadzie poza trzymaniem się określonego formatu danych nic nie narzuca - żadnej określonej bazy danych, wymagań co do nazwy obiektu - można umieścić plik gdzie bądź i w tagu podać link. Jestem głeboko przekonany, że i tak powstałoby jakieś repozytorium tych plików, ale nie jest to wstępnie wymagane, nie trzeba tworzyć jakiejś bazy - to bardzo ułatwia na wstępie.

Można te dwa pomysły skrzyżować.

Taki pomysł był zgłaszany w ramach GSoC 2015:
Web application for sharing 3D-Models to use in OSM-related 3D-Applications

(http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2015/Project_Ideas)

Jeżeli dobrze Was rozumiem. Można zastanowić się nad definicją projektu pod kątem GSoC 2016.

@rmikke Pomysł na repozytorium modeli pojawiał się już bardzo wiele razy. W sumie to omawiane były chyba wszystkie możliwe sposoby jak to zrobić ich wady i zalety. Niestety jak zawsze dyskusja zaczynała się i kończyła ponieważ poza ciągle tymi samymi pomysłami nikt tego nie wykonał i nie utrzymał na produkcji.

Formaty dla przechowywania modelu wraz z współdłużnymi istnieją od dawna dzięki uprzejmości googla, i zwie się np. KMZ. Ostatnia dyskusja na temat repozytorium była chyba tu, ale jak poszukasz na wiki znajdziesz dużo więcej informacji.

Orientacja dachu względem along, across jest wyznaczana względem prostokąta o najmniejszym polu. Roof table definiuje coś takiego jak punkt startowy jednak to się zupełnie nie przyjęło. W kendzi3d jest jeszcze używane ale chyba nie warto sobie zawracać głowy. Generalnie Roof table o ile wiem jest wspierane częściowo tylko w mojej aplikacji. Więc skup się na początku głównie na definicji z S3DB.

Dla mnie przód budynku z dachem typu sillion jest tam gdzie jest jego niższa krawędź. I to na nią powinien wskazywać tag direction.

Każdy typ dachu powinien mieć określone gdzie jest jego przód, tył, prawa oraz lewa strona. W ten sposób dużo łatwiej dyskutować jak taki budynek obrócić. Niestety chyba poza kilkoma dyskusjami nikt nigdy nie pozbierał tego w ładną tabelkę.

Zerknij tu

U mnie stara się najlepiej dopasować „przód” lub „tył” budynku. Czyli szukam krawędzi najbardziej prostopadłej do kierunku. Jednak chyba nigdzie nie zostało to oficjalnie tak „zdefiniowane”.

Implementacja

Jak dla mnie to może istnieć, tylko trzeba dwa boki domyślnie jako leżące w 1/4 szerokości budynku (l2). Oczywiście nie zadziała jeśli do generowania tego dachu używasz algorytmu szkieletowego :wink:

A przy okazji, o ile wiem to tag „3dr:length*=*” jest tylko wspierany przez moją aplikację…

Dzięki, dobra ilustracja, przydałaby sie na wiki, chociaż konkretnie chodziło mi o przypadek kiedy brak roof:slope:direction. Ale już widzę, że takie przypadki są raczej beznadziejne.

Kendzi to wyraźniej napisal niz ja - chodziło mi o to, czy przyciągane mają być kąty przodu/tyłu budynku, czy boków.

Dzięki za jasne odpowiedzi. Przy okazji, w bazie są całe Niemcy ale 1. nie są aktualizowane i 2. pewnie nie są zcache’owane w związku z czym będą się wyświetlać po kilkunastu - kilkudziesięciu sekundach.

Polska jest aktualizowana co 10 minut.

Na Stadion Narodowy w W-wie narazie nie patrzcie bo nie przewidziałem możliwości, że ktoś jednocześnie da roof:slope:direction i roof:orientation, w weekend poprawię.

Ok, bardzo mnie to cieszy.

Bardzo dobry obrazek, generalnie dokumentacja S3DB ma dobre ilustracje mimo, że miejscami jest nieścisła.

Ok, czyli w prawo.

Ok, może dodam. Jeśli już to robić, to przy okazji równie dobrze można obsłużyc 3dr:length1.

Nawet go sobie nie wyobrażam implementować w SQLu.

Wygląda na trochę rozleglejsze i bardziej ogólnikowo opisane, ale tak.

W sumie, nie spodziewałem się, że odkryję Amerykę :smiley:

We Wrocławiu można mierzyć wysokości budynków na http://ukosne.gis.um.wroc.pl (nie dotyczy SkyTowera).

Na liście talk skarżą się na testy na potrzeby 3D przeprowadzone w Afryce przez jednego z naszych:
http://www.openstreetmap.org/#map=17/7.45832/15.59789

Wypadałoby skasować.