Użytkownik Win32netsky trochę się wyżył.
Oto przykłady:
http://wiki.openstreetmap.org/wiki/File:Haus3D-7.png
http://ubuntuone.com/1NLZ3VgIQJcsEe5vGspmQt
http://ubuntuone.com/3GMDm2L5yXJadMczdhzvqH
Warto by tą usługę także w Polsce uruchomić!!
Oczywiście bez błędów z-buffer… jak w osm2world… 
Zapowiadaja sie za jakis czas zmiany w Mapniku:
Jesli chodzi o Styles prowadzone sa prace nad nowa Carto Version.
Wtedy bedzie mozliwe zintegrowanie ulic jako obszarów. Przyda sie to tez do 3D.
Konsekwencja bedzie taka, ze nawet chodniki bedzie mozna rysowac jako obszary, podobnie jak teraz czesto robia to ludzie z pedestrian street z area=yes…
Można prosić o jakieś źródło tego?
Niejaki Simon Poole z OSMF informowal wczoraj na forum niemieckim o pracach Andy Allana który przetlumaczyl Style Sheets z Mapnik .xml.
http://wiki.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-04-29
Oprócz tego dlubie nad sprawa user Tordanik. Ma to byc praca dyplomowa i odwiedza mnie od czasu do czasu na konsultacje wiec jestem w miare na biezaco. Wic polega na tym, ze prosty rendering jakiegos area=value to nie problem. Problem sie zaczyna, gdy chce sie np. rysowac ilosc pasów jezdni wpasowujacych sie w area.
Próbuję ugryźć temat 3D w OSM i jednak nie jest lekko. Ale fajnie 
Oprócz dokonań niemieckich (zapodawanych przez Marka), moc OpenStreetMap ukazuje wersja OSM z WebGL. Wujek Gugiel ze swoją wersją niech się chowa a i tak OSM jest nieprecyzyjnie otagowana, a i niektóre renderowania są jeszcze niedopracowane. Moja próba z warszawskim Marriottem, Intraco i Dworcem Centralnym → uwaga trzeba mieć przeglądarkę obsługującą Web GL, tak z 3D mapami od Google’a (a więc Chrome lub Firefox).
Podpatruję sobie różne tagowania 3D, podglądam w Kendzi3D, widoczek na osmapa.pl i na wspomnianym F4 Map… i różnie to bywa. Np. dając budynek w częściach (building:part=yes) do relacji - nie była renderowana najważniejsza część opisująca całość. Metodą prób i błędów jakoś doszedłem, żeby to wyszło jak widać. Czy ktoś z oblatanych w 3D mógłby zajrzeć w te budynki, a potem byśmy sobie podyskutowali o modelowaniu. Porobiłem też trochę budynków 3D w Starachowicach, więc może być dodatkowy materiał.
PS. Zauważyłem również, że Kendzi3D nie robi płaszczyzny dolnej - np. w spodzie uproszczonego dachu Centralnego 
Poprawię przy najbliższej okazji.
Jeśli chodzi o Mariot to wydaje mi się że ten fragment powinien mieć wysokość 5m a nie 15m. Pozatym ostatnio raczej używa się tagów building:part do oznaczania fragmentów jednego budynku, oczywiście trzeba później te fragmenty oraz obrys budynku dodać do relacji. Żuć okiem na Simple 3D Buildings zwłaszcza na zakładkę dyskusji.
Możesz przesłać lub udostępnić przykład?
A czy ma to znaczenie, jeśli to jest wycofany parter a nad nim się nadwiesza większa kondygnacja od wysokości 5m? Owszem może być 15m - bo się ten mniejszy parter schowa w bryle z nadwieszeniem od 5 do 15m. A może “pudełko” piętra leżeć na “pudełku” parteru. Z drugiej strony, w wieży hotelu oprócz building:part= dałem normalny building= (a chyba nie jest to w 100% poprawnie) z prozaicznego powodu → żeby bryłę było widać zarówno na Mapniku jak i osmapie turystycznej.
Tak też postąpiłem z Centralnym. Dach ma przesłonić wszystko co pod nim? Czy zostawić sam parter? Z tego wychodzi dodatkowa dyskusja renderowania, a więc pokazania tego co się godzinami rzeźbi, nie tylko do bazy danych, ale użytkownikom korzystającym z OSM, zwłaszcza że to są istotne informacje przestrzenne.
Pewnie zauważyłeś to o czym napisałem wyżej, że oprócz :part=, dodałem building=.
Teraz trudno o przykład - może gdzieś coś jest. Ale proponuję (sprawdziłem przed chwilą) taką opcję:
Robiłem odwrotnie. Taka zabawa w kotka i myszkę 
Tu jest nietypowa sprawa - parterem nie obejmę wszystkich części, bo jest mniejszy - wypadałoby otagować dach jako dworzec z wejściami w środku. Dlatego dałem relację (tak jak się to zaleca), choć w Rostoku (nie wszędzie) podstawowym buildingiem zaznaczali cały budynek (tak też można). A tu dałem relację i zonk Może robić jakieś numery jak na dworcu w Lubece, że dają budynki wysokości 0.1… W każdym razie jest kombinowanie, ale trzeba też tak kombinować, żeby nie zepsuć widoku Mapnika…
Moim zdaniem powinno to wyglądać w taki sposób
Brakowało tam relacji type=building.
Samo pudełko się schowa jednak dachy obu brył będą nachodziły na siebie i spowodują złe wyświetlanie tekstury. Więc dużo lepiej jest układać „pudełka” jedno na drugim.
Również uważam że sama wieża nie powinna mieć tagu building=yes, niestety wtedy nie będzie widoczna w mapinku. Osmapa również niestety nie obsługuje building:part.
Wydaje się że teraz ten budynek wygląda poprawnie.
Algorytm wyświetlania budynków jest następujący:
Jeśli istnieje relacja type=building i posiada on jakąś drogę z tagiem building:part=*
=> Wyświetl same części (building:part) z relacji.
Jeśli istnieje relacja type=building i NIE posiada ona tagów building:part=*
=> Wyświetl same obrysy budynków (building=) z relacji.
Jeśli brak relacji
=> wyświetlaj zarówno obrysy (building=) jak i fragmenty (building:part).
Obecnie takie zachowanie jest jedynie w mojej aplikacji. F4 Map jak i Osm2world próbują automatycznie wykryć która z nakładających się dróg jest fragmentem budynku a która obrysem i w zależności od tej detekcji część z fragmentów ukrywają przy renderingu. Dlatego wymagają one aby obrys budynku (building=*) zawsze był większy niż suma składowych fragmentów (building:part). Moim zdaniem przy renderowaniu skomplikowanych budynków powinna być wykorzystywana relacja zamiast auto detekcji.
Tak było robiono dawniej. Teraz z wykorzystaniem relacji powinno wyświetlać się poprawnie u mnie. Inni korzystają z auto-detekcji i również powinno się wygenerować poprawnie.
Uzupełniłęm polską wiki. Udało mi sie przekonać międzynarodową społeczność do przyjęcia w poczet podstawowych form także dachu beczkowego.
Ciekawosta:
Pierwszy model 3D zrobiony spolecznosciowo:
http://wiki.openstreetmap.org/wiki/File:MarekKrzywinPolandCityCentre1998.jpg
Zrobily go czternastolatki w liceum w Krzywiniu w Wielkopolsce w 1998 roku.
Uzywana wtedy do pracy specyfikacja modeli jest prawie identyczny z ta, która uzywa teraz OSM. Ot przypadek.
To proste jest.
Przykładowo ta “stodoła” jeśli by była sfotografowana 31 marca 2012
http://umap.openstreetmap.fr/en/map/openstreetmap-pret-pour-roland-garros_275#20/54.34587/22.81230
to zdjęcie wykonano o godz 12:14 a szczyt kalenicy ma wysokość 6,03 m.
Co ciekawe krawędź wschodnia dachu jest wyższa niż zachodnia.
Mogę wyliczyć kąt dachu albo lepiej garażu
Garaż ma wysokość 2,48 m.
Można tez wyliczyć (z jakiejś dużej symetrycznej hali) kąt patrzenia satelity i wykorzystać to aby JOSM, automatycznie korygował geometrię prostokąta domu , czyli likwidował zniekształcenia romboidalne (patrzenia na prostokąt pod kątem).
Można po długości cienia orientować się jaka jest wysokość budynku, dzięki czemu klikając np w narożnik dachu budynku i odpowiadający mu koniec cienia spowodować, że automat cofnie o odpowiednią wartość wysoki dach (rysujemy po dachach), czyli wyrówna dach niski z sąsiadującym wysokim.
Dało by to efekt taki jakby satelita był pionowo nad budynkiem.Inny sposób to przełączenie się w JOSM na innego WMS klawiszem np Alt+2 i jeśli drugi satelita patrzyłby pod innym kątem niż pierwszy to automat sam by wyliczał wysokość budynku i przesuwał dach.Czyli jeśli po wyrysowaniu wysokiego dachu nastąpiłoby Alt+2 i chwycenie za obrys i przesuniecie na nowego WMS , to po puszczeniu dach jechałby automatycznie na właściwe miejsce.
Kalibracja mechanizmu byłaby bardzo prosta i jednorazowa na na danym obszarze, bo wymagałaby po przełączeniu WMS przesunięcia ręcznie obu dachów.
Z różnic ręcznego przesunięcia (innego dla obu dachów), JOSM by sam wyliczył zarówno kąty patrzenia satelitów jak i różnice wysokości dachów.Czyli nawet cień nie byłby potrzebny a zatem i data zdjęcia.
Stąd już krótka droga do 3D.
Datę można przyjąć na oko po wegetacji roślinności, albo wyliczyć ją w procesie odwrotnym do kalibracji wykorzystując obiekt o standardowej wysokości np. standardowa jest zdaje się wysokość słupa energetycznego.
Podawane są wysokości masztów nadajników, pylonów mostów, kościołów itd.
Wysokość latarni czy budynku do kalibracji arkusza można wziąć ze StreetView .
Np. Nokia robi foty zdaje się co 6 m, więc wystarczy wyliczyć zmiany kąta ze zmiany wielkości budynku na ekranie w kilku krokach SV.
Robilismy testy tego typu w 2003 roku uzyskujac dokladnosc pomiaru rzedu 5-8% w zaleznosci od tego, gdzie budynek ten stoi. Teren nigdy nie jest idealine plaski a to zmienia dlugosc cienia. Do tego dochodzi jeszcze niedokladnosc okreslenia dlugosci cienia przez operatora który robi to manualnie. Metoda jest jednak bardzo dobra gdyz pozwala na szybkie uzyskiwanie wyników w 3D.
Zanim Navteq przesiadl sie na zewnetrznych dostawców danych wykorzystujacych do budowy 3D skalibrowana pare zdjec plus odpowiednie oprogramowanie, modele byly uzyskiwane wlasnie w ten sposób.
Notabene: Mimo ze metoda jest bardzo praktyczna, nalezy podkreslic, ze nic nie zastapi kontroli modeli przez osobe znajaca dane otoczenie.
Nawet wsród modeli testowych robionych przez bodaj najlepszych specjalistów (jedna firma fotogrametryczna ze Szwajcarii, druga wojskowej proweniencje ze Szwecji) znajdowalismy z zespolem interpretacje zdjec której wynikiem byl model o nieprawidlowek wyskosci. Podpada to wtedy gdy dwa lezace w poblizu budynki interpretowane sa w ten sposób ze jeden jest wyzszy od drugiego a w rzeczywistosci jest odwrotnie.
I takie rzeczy sie zdarzaly. Nawet specjalistom. Koniec uwagi.
Cóz, nie zrobimy z tym nic, poki ktos nie napisze kawalka oprogramowania…
Spadek terenu rzadko kiedy jest większy niż 5 %
Dla kąta 5 stopni cos=0,9961 zatem błąd jest mniejszy niż 0,4%,zatem przy sporym błędzie klikania w koniec cienia nie ma co o nim wspominać.
Dokładność wyznaczania końca cienia ma związek z rozdzielczością zdjęć, a ta będzie systematycznie wzrastać.
Zatem zejście z błędem poniżej 5% będzie bardzo łatwe, jeśli powiększy się budynek w JOSM do rozmiaru np.250x100 pix. Wtedy błąd wskazania 1-2 pix da błąd około 1%.
Ale nam na potrzeby przesuwania dachów do mapy 2D,wystarczy dokładność 30% aby wyłapać,liczbę kondygnacji i aby i o proporcjonalny wektor do kąta satelity i liczby kondygnacji wyrównać automatem dach do dachu sąsiedniego, niższego o 1-2 kondygnacje.
Czyli dachy jak puzzle przesuwane są proporcjonalnie do liczby kondygnacji, a to może błąd “paralaksy” zmniejszyć nawet 10 krotnie, do tak małej różnicy między narożnikami dwóch budynków, że program może uznać, iż skoro błąd jest mniejszy niż 1 m to budynki mają wspólną ścianę i połączy nody likwidując przerwę tam gdzie jest ona spowodowana błędem rysowania i błędem perspektywy.
Zalezy gdzie mieszkasz.
Chwileczke. Zdjecia satelitarne robi sie wiosna lub latem zas tam gdzie jest wiele drzew zima.
Pytanie: Jali jest sredni kat nachylenia slonca w poludnie w np. Warszawie dnia 1kwietnia, 1 sierpnia 1 pazdziernika?
Dajmy dla ulatwienia 45 stopni.
Przy kacie nachylenia terenu wynoszacym 5 stopni daje to 8,7155%!
Dla trzypietrowego budynku o sredniej wysokosci pietra 2,80m daje to 9,132m zamiast 8,4.
Liczysz sam blad wysokosci wynikajacy z nachylenia terenu, tymczasem musisz mierzyc róznice wynikajace z dlugosci cienia.
Zerknij na ten szkic:
http://wiki.openstreetmap.org/w/images/6/65/MhightDifferenceShadowAngle45to5degreeTerrain.jpg
Zajrzałem na F4 Map i generalnie bardzo pysznie wygląda centrum Warszawy po uwzględnieniu wysokości części budynków (Osmapa nie jest chyba aktualna)!
Najbardziej rzuca mi się w oczy brak charakterystycznych kopuł na Złotych Tarasach oraz uproszczona bryła ORCO Tower. Sam ostatnio poprawiałem okolice ORCO, bo nikt wcześniej się za to nie zabrał, a to przecież centrum stolicy - i na razie tylko na tyle wystarczyło mi umiejętności (chociaż drzewka w Pasażu Łopieńskich też bardzo fajnie wyszły i dodały realizmu). Czy ktoś bardziej sprawny w 3D może się tym zaopiekować?
Osobna sprawa to wiadukt na Chałubińskiego - to nie budynek, ale zdecydowanie charakterystyczny kształt 3D dla tego miejsca.
Spróbuj uruchomić JOSM z plugin-em kendzi3d. Powinien Ci pomóc z edycją w 3D. Dodatkowo nie będziesz musiał czekać na update mapy F4.
Dzięki, a czy ta wtyczka pozwala na edycję, czy służy tylko do podglądu? I jak należy przesuwać kamerę (na razie potrafię ją tylko obracać, przesuwania nie opanowałem dobrze)?
Tak czy owak z ORCO nie będzie prosto, bo to skomplikowany kształt złożony z wielu brył (także z ukośnym brzegiem), inny w kształcie na dole, pośrodku i na górze (i nie składa się tylko z trzech warstw o różnym przekroju):
A w animacji obrotowej (choć dół jest tu akurat uproszczony):
Ciekawe, że Kendzi3D patrząc na obecne ORCO nie pokazuje nawet wieży, która jest widoczna w F4.
Roznica jest taka, ze f4 jest komercyjne i z zamknetym kodem a Kandzi sam to tworzy po pracy zas jego kod jest ogólnodostepny.
Cieszyl bym sie, gdyby ktos mu troche pomógl bo robote tworzy swietna ale na to trzeba czasu. Jest pomysl na ukosnosci i na bardzo dokladne modelowanie, no ale do tego trzeba ludzi. Az sie tak glupio mi o tym pisze: Jest gotowa specyfikacja bo od czasu spotkania na jesieni linuksowej w zeszlym roku ( czy tez juz 2 lata temu) projekt znacznie sie rozrósl.
Wic polega na tym, ze jak to puscic w szczególach w siecie to piorunem pojawi sie u google. Dlatego wole to najpierw z jakas grupa stworzyc.
Jesli troche programujesz, moglbys pomóc.
Jesli nie Ty to moze ktos inny z naszego forum?
Wieża nie wyświetlała się poprawnie, ponieważ zamiast tagu „height” został użyty tag „hight”. Dodatkowo mapy F4 i O2W próbują automatycznie wykrywać sytuację gdy części budynków nachodzą na obrysy, aplikacja kendzi3d do takiego wiązania zgodnie z specyfikacją Simple 3D Buildings wymaga aby wszystkie części i obrys znajdowały się w relacji type=buidling. Zamiast tagu „levels” raczej powinno zostać użyte „building:levels”. Aby ułatwić sobie edycje możesz ściągnąć preset dla budynków:
F12 > Map settings (3 zakładka) > Tagging Presets (3 zakładka) > 3D Simple Buildings (w nazwach presetów).
Są w nim zdefiniowane podstawowe tagi z strony S3DB
Obecnie plugin umożliwia edycje wysokości budynków. Możesz zaznaczyć budynek a wtedy pojawi się nad nim strzałka, którą możesz przesuwać. Niestety jest to jeszcze mocno niedopracowane i nie działa dla budynków dodanych do relacji. Kamerę możesz przesuwać korzystając z klawiszy: q,w,e,a,s,d oraz myszki.
Na razie dzięki poprawieniu struktury budynku (budynek jako master relacja i części zawarte w nim) udało mi się dokonać zasadniczego odwzorowania obrysu ORCO i okolicznych budynków. Dzięki podglądowi w Kendzi3D z kolei miałem żywą pomoc w konstruowaniu wysokości - podstawowe 4 prostopadłościany ładnie wystają nad ziemię - jak dla mnie to spore osiągnięcie w kwestii OSM 3D, tym bardziej, że JOSM-a dopiero zaczynam używać.
Nad dodaniem pozostałych brył na górze (4 na bazie trójkąta i banalny prostopadłościan na dachu) popracuję później, bo to dosyć czasochłonne i wymaga skupienia, a potem zobaczę jak zrobić porządek z parterem i piętrami 2-3, które mają inne obrysy niż reszta budynku. Presety też zostawiam sobie na potem.
W tej chwili widzę jeden duży problem z wizualizacją w Kendzi3D: dopóki na głównej wieży jest sam tag dotyczący kondygnacji, to wszystko wygląda dobrze, ale tag “height=115” wydłuża budynek znacząco i pięter naliczyłem wizualnie ze 40, a nie zadeklarowane 26. Proszę o pomoc w wyjaśnieniu skąd ten problem, bo może znów zrobiłem jakiś głupi błąd w rodzaju tamtej literówki? Dwa mniejsze problemy tej wtyczki to niewidoczne mury (“barrier=wall”), choć ogrodzenia (“barrier=fence”) są widoczne, oraz nieuwzględnianie tagu “area=yes” (np. na placyku pod tym wieżowcem).
Przychodzi mi też do głowy jak można zrobić wiadukty 3D - wystarczy zadeklarować powierzchnię pod nimi jako budynek z dachem łukowym i poprowadzić jezdnie po tym dachu. Choć na pewno lepiej by było, gdyby wiadukty dawało się wyginać w łuk same z siebie, bez oszukiwania (budowle to nie budynki).
Widzę też jeszcze, że na Pałacu Kultury brakuje iglicy.
PS: jak dodałem nowo utworzony prostopadłościan ORCO do reszty budynku (tzn. do relacji), to Kendzi3D przestał go renderować, choć na oko wszystkie tagi ma tak samo jak druga boczna wieżyczka - ki czort? Dopiero w edycji relacji widzę, że ta część (którą zdeklarowałem jako part w relacji) jest widoczna jako budynek, a nie jako numer ścieżki, jak pozostałe części. Podejrzewam, że to jest ten problem, ale nie wiem, jak to zmienić ani skąd się wzięło. Proszę o korektę i wyjaśnienie. [Załatwione - był to jednak błędny tag “building=part” zamiast “building:part=yes”]
