Przykłady OSM 3D

miklobit · 2013-10-17 10:11:54

kocio wrote:

ale to niestety nie jest Open Source, tylko freeware - przynajmniej tak jest napisane na stronie pobierania, ale może gdzieś jest dostępny kod?

Jak klikniesz na atrybucje to przejdziesz do
https://github.com/hjanetzek/vtm
https://github.com/opensciencemap/TileS … e/OSciMap4

marcin_b · 2013-10-17 10:15:36

Ważne, że się coś dzieje

kocio wrote:

Tak gwoli informacji: mapka OpenMapSurfer (http://www.openmapsurfer.uni-hd.de/) na poziomach przybliżenia 17 i 18 pokazuje widoki 3D, ale są one statyczne, tzn. są już wyrenderowane na obrazkach kafelków. Oczywiście ten serwis też ma problemy z wyświetlaniem niektórych budynków...

Rendering 2D tego OpenMapSurfera (OSM Roads - New) najbardziej mi się podoba z wszystkich mi znanych.

kocio · 2013-10-17 11:46:48

miklobit wrote:

Jak klikniesz na atrybucje to przejdziesz do
https://github.com/hjanetzek/vtm
https://github.com/opensciencemap/TileS … e/OSciMap4

Sam kod widoczny publicznie nadal jeszcze nie świadczy o licencji FLOSS. W obu tych miejscach nie widzę informacji o licencji, ani w wyświetlanych domyślnie README.md, ani (zwyczajowego) osobnego pliczku LICENSE, a domyślnie wszystko, co zostało opublikowane, znajduje się pod najsilniejszą ochroną prawa autorskiego.

Ale napisałem do Falko z pytaniem o licencję i zobaczymy co odpowie.

Last edited by kocio (2013-10-17 11:53:30)

miklobit · 2013-10-17 12:22:35

Trochę podglądam od środka te projekty OSM-3D które mają otwarte źródła i taka myśl mi przychodzi:
Jeśli na obecnym etapie (prostej specyfikacji) są spore rozbieżności w interpretacji i renderowaniu danych ( przez każdy projekt) to przy wprowadzeniu bardziej złożonych modeli to się jeszcze pogłębi. Zmierzam do tego, że w tej chwili nie istnieje żadna wspólna biblioteka do generowania z danych OSM warstwy pośredniej (danych 3D dla rendera). Kaźdy to robi po swojemu mimo, że używane silniki renderujące są podobne (przeważnie oparte na OpenGL). Stworzenie takiej biblioteki z pewnością przyśpieszyłoby dalszy rozwój tematu, bo zarówno edytory jak i programy do wizualizacji mogłby mieć najważniejszy element wspólny. Nie mówiąc już o tym, że nakład pracy przy dodawaniu nowych funkcji byłby podzielony między większą liczbę osób.
Czy taki pomysł był w ogóle podejmowany przez deweloperów ?

marek kleciak · 2013-10-17 14:34:29

Czy taki pomysł był w ogóle podejmowany przez deweloperów ?

Jeszcze nie. Temat jest "nowy" w obszarze open source..

miklobit · 2013-10-17 18:15:05

kocio wrote:

Sam kod widoczny publicznie nadal jeszcze nie świadczy o licencji FLOSS (....) a domyślnie wszystko, co zostało opublikowane, znajduje się pod najsilniejszą ochroną prawa autorskiego.

Literalnie patrząc to oczywiście masz rację, ale to raczej "zasługa" Github'a że nie wymusza określenia żadnej licencji mimo, że tworząc repozytorium każdy inny może zrobić swoją wersje tego kodu.
Jak ja coś zaczynam dłubać to ostatnią rzeczą o której myślę jest licencja...

kendzi · 2013-10-17 18:53:26

miklobit wrote:

Jak ja coś zaczynam dłubać to ostatnią rzeczą o której myślę jest licencja...

To jest zawsze pierwsza rzecz od której się zaczyna...

kocio wrote:

Sam kod widoczny publicznie nadal jeszcze nie świadczy o licencji FLOSS

Napisz pytanie do hjanetzek'a pewnie po prostu zapomniał dodać.

miklobit wrote:

Czy taki pomysł był w ogóle podejmowany przez deweloperów ?

Jasne. Swego czasu Tordanik próbował mnie przekonać do swojego projektu, a ja go do mojego. Niestety oba projekty wtedy kładły nacisk na zupełnie inne aspekty. Obecnie oba mają zaimplementowaną bardzo podobną funkcjonalność. Oczywiście nie ma żadnych problemów aby wykorzystać moje biblioteki w innym projekcie. Są one zupełnie nie zależne od samego plugina. Pewnie podobnie prosto można wybebeszyć kod z O2W.

Swoją drogą hjanetzek planuje rozbudować mapę o lepsze budynki. Sprawdzał zarówno O2W jak i mój plugin pod kontem wykorzystania przy generowaniu budynków. Niestety nie wiem czy już wybrał jakieś konkretne rozwiązanie.

kocio · 2013-10-17 20:24:35

kendzi wrote:

Napisz pytanie do hjanetzek'a pewnie po prostu zapomniał dodać.

A to kto, to ksywa czy jest ich dwóch? Bo ze strony zrozumiałem, że wszystkim zajmuje się tylko Falko.

kendzi · 2013-10-17 21:50:18

kocio wrote:

A to kto, to ksywa czy jest ich dwóch? Bo ze strony zrozumiałem, że wszystkim zajmuje się tylko Falko.

Nie mam pojęcia jak się na prawdę nazywa. To jest nazwa konta na githubie. Więc zakładam że to ksywa

https://github.com/hjanetzek

kocio · 2013-10-17 22:20:16

kendzi wrote:

https://github.com/hjanetzek

Hannes Janetzek - czyli pewnikiem drugi jakiś. Ciekawe jak wobec tego wygląda struktura projektu.

Polimerek · 2013-10-18 00:29:04

kocio wrote:

OpenScienceMap wydaje mi się bardzo przyszłościowe - przypomina F4 (podłoże z mapy 2D, wygodna nawigacja myszką, dość duża możliwość zbliżenia), ale startuje od razu i znacznie szybciej odświeża widok po zmianie położenia lub kąta kamery. Poza brakiem dachów i kolorów ma problemy z elementami "wiszącymi" (min_level>0) , nie wyświetla też dodatkowych elementów zwiększających realizm, typu drzewa, tory, murki czy barierki. Ma też bardzo wysokie domyślne kondygnacje (przynajmniej pierwszą), przez co wszystkie budki/kioski/wiaty wychodzą nieproporcjonalnie duże - z drugiej strony pewnie dzięki temu ORCO Tower odzyskał właściwe proporcje wieżyczek.
Generalnie ciekawy projekt, lepiej wykorzystuje 3D niż OSMB, ale to niestety nie jest Open Source, tylko freeware - przynajmniej tak jest napisane na stronie pobierania, ale może gdzieś jest dostępny kod?

W apce na Adroida, w "about" jest napisane, że jest na LGPL. Ale nie ma linku do kodu źródłowego.

kocio · 2013-10-18 11:59:23

Falko odpisał, że generalnie LGPL, przy czym nie chwalą się tym kodem z powodu słabego kodu, ale też kwestii serwera. Nie zrozumiałem tego do końca, więc może zacytuję fragment naszej wymiany zdań:

we have a server running serving all the data of OpenScienceMap and we do not want it commercially abused as we are a scientific project and do not have the resources for it (and did not decide on a usage license yet)

But I don't understand what exactly are you afraid of. LGPL means they can do (almost) whatever they want with the code anyway, but it has nothing to do with your server - having the code they can just run their own server. What point am I missing?

Running a fully fledged vector tile server is a resource intensive task. Not everybody can afford it. If we get requests from commercial services we will run in trouble here. And not everybody is understanding and respecting this matter.

Ktoś z was rozumie w czym właściwie widzi problem? Czego niby mogą od nich "zażądać" podmioty komercyjne?

Tak czy owak wkrótce szykują nową, znacznie ulepszoną wersję kodu, z tym że akurat w części związanej z wyświetlaniem na razie nie będzie większych zmian. Ja w każdym razie chętnie poczekam - jak nadrobią głównie dachy i kolory, to dla mnie będą lepsi niż F4. Szkoda, że z Kendzi3D nie da się korzystać równie łatwo, ale poprawione OpenScienceMap to już będzie coś, co można ludziom pokazywać.

marek kleciak · 2013-10-18 12:45:58

Ciesze sie, ze Falko cos tam dlubie i chcialbym zeby byli lepsi od f4..
Zadzwonie do niego i sie spytam...

skyraster · 2013-10-18 12:58:45

kocio wrote:

Ktoś z was rozumie w czym właściwie widzi problem? Czego niby mogą od nich "zażądać" podmioty komercyjne?

Ja to zrozumiałem tak, iż ich usługa (na ich serwerze) może przy komercyjnych zastosowaniach (masówce) wymagać większych mocy serwera i będzie dla nich zbyt dużym obciążeniem. Wówczas mamy requesty danych (pobrania) i nagle okazuje się, że serwer nie wyrabia. Serwer tile wektorów jest niestety bardziej problematyczny w obsłudze niż rastrowe przygotowane tile, które można po prostu wyrenderować i wstawić do ściągania (wiem bo sam pisałem taki serwer wcześniej). Poza tym jeśli udostępnią kod komuś, kto chce dostarczać komercyjne narzędzie, to wiadomo, że przy ew. problemach będzie do nich słał zapytania - a pytanie czy oni mają czas na reakcję. Chyba raczej nie, bo to scientific i pewnie mają sporo roboty i tak

kocio wrote:

Szkoda, że z Kendzi3D nie da się korzystać równie łatwo, ale poprawione OpenScienceMap to już będzie coś, co można ludziom pokazywać.

U mnie Kendzi3D działa, ale na tyle wolno, że nie wiem, czy to konfiguracja kompa, czy prostu tak ma być... Jeśli np. chcę załadować podgląd większego obiektu (np. PL Radio Warszawa), to muszę wyłączyć moduł 3D, załadować plik i włączyć ponownie, aby się JOSM nie zwiesił.

Je ze swojej strony testuję u siebie własny renederer 3D, na razie mam screeny z wyświetlania podkładów rastrowych TMS oraz WMS.

Podkład Mapnika + fragment wektora z pliku OSM (WGS84)

Podkład Geoportal (układ 92) + fragment wektora z pliku OSM (WGS84)

Podgląd PC, ale na Android działa identycznie.

kocio · 2013-10-18 13:20:34

skyraster wrote:

Ja to zrozumiałem tak, iż ich usługa (na ich serwerze) może przy komercyjnych zastosowaniach (masówce) wymagać większych mocy serwera i będzie dla nich zbyt dużym obciążeniem. Wówczas mamy requesty danych (pobrania) i nagle okazuje się, że serwer nie wyrabia. Serwer tile wektorów jest

Też tak mi się zdawało, ale nadal nie rozumiem dlaczego to niby ma wisieć na ich sprzęcie serwerowym? Nie ma możliwości pobierania danych bezpośrednio z serwerów OpenStreetMap - przecież tak to robi Kendzi3D? A, w ogóle co to są "tile wektory", jakieś specjalne kafelki?

skyraster wrote:

U mnie Kendzi3D działa, ale na tyle wolno, że nie wiem, czy to konfiguracja kompa, czy prostu tak ma być... Jeśli np. chcę załadować podgląd większego obiektu (np. PL Radio Warszawa), to muszę wyłączyć moduł 3D, załadować plik i włączyć ponownie, aby się JOSM nie zwiesił.

Ja mam w domu dość słaby sprzęt (taki HP dla firm z demobilu), co czuję wyraźnie pod F4, bo trwa jakieś kilkadziesiąt sekund albo kilka minut zanim ruszy, ale Kendzi3D rusza bez problemu, nawet jak pobieram całą okolicę radia - najwyżej prędkość renderowania spada (czasem tylko do 3 FPS), ale się nawet nie zacina. Wolniej wtedy się porusza kamera, ale obrót nadal jest szybki.

skyraster · 2013-10-18 13:32:42

kocio wrote:

Też tak mi się zdawało, ale nadal nie rozumiem dlaczego to niby ma wisieć na ich sprzęcie serwerowym? Nie ma możliwości pobierania danych bezpośrednio z serwerów OpenStreetMap - przecież tak to robi Kendzi3D? A, w ogóle co to są "tile wektory", jakieś specjalne kafelki?

Ich serwer zapewne przygotowuje dane do renderera, aby mógł optymalnie renderować dane.

Tile wektory to po prostu kafelki zawierające dane wektorowe (albo przycięte albo nie, ale zawierające dane dla tego konkretnego obszaru). Jeśli renderer ma coś wyświetlać to najwygodniej jest wyświetlać to kafelkami, ale przy wektorze jest problem, bo trzeba wcześniej je przygotować (np. przyciąć). Najlepiej to zrobić offline i zostawić wyłącznie rezultaty, bo przycinanie danych na bieżąco - przy pobieraniu (requestach) będzie mocno obciążało serwer i nie jest to zbyt eleganckie rozwiązanie.

Problem z kafelkami wektorowymi jest taki, że serwer przy przygotowaniu danych musi sensownie wybrać dane, jakie mają być w danym kaflu. Można patrzeć na to analogicznie jak w JOSM. Jeśli pobieramy dane z OSM możemy traktować wskazany zakres jako 1 kafel, wówczas pobierane jest nie tylko to co leży w kaflu, ale też wszystko co powiązane jest z tym obszarem (np.relacjami, liniami). W przypadku małych kafli pobieranie innych zakresów spowodowałoby duże opóźnienia bo dużo danych byłoby nadmiarowych. Przycięcie jest wskazane, aczkolwiek w przypadku jego stosowania dane możnaby wykorzystać wyłącznie do renderingu, ich wykorzystanie np. przy edycji wymagałoby sklejania z powrotem i ogólnie byłoby niezbyt dobrym pomysłem.

Wyobraź sobie np. budynek, którego element wystaje i np. znajduje się w obszarze innego kafla (czyli np. w pierwszym kaflu jest budynek, w drugim jego wystający element). Jeśli stosować przycinanie danych, trzeba by to zrobić na tyle umiejętnie, aby moduł przekazujący dane rendererowi potrafił wszystko skleić i prawidłowo wyświetlić. Dlatego łatwiej jest pobrać jakiś zakres i go rendererować, niż bawić się w serwery tile-vector i sklejać je w całość po stronie renderera.

Last edited by skyraster (2013-10-18 13:36:15)

marcin_b · 2013-10-18 15:12:49

kocio wrote:

skyraster wrote:
U mnie Kendzi3D działa, ale na tyle wolno, że nie wiem, czy to konfiguracja kompa, czy prostu tak ma być... Jeśli np. chcę załadować podgląd większego obiektu (np. PL Radio Warszawa), to muszę wyłączyć moduł 3D, załadować plik i włączyć ponownie, aby się JOSM nie zwiesił.
Ja mam w domu dość słaby sprzęt (taki HP dla firm z demobilu), co czuję wyraźnie pod F4, bo trwa jakieś kilkadziesiąt sekund albo kilka minut zanim ruszy, ale Kendzi3D rusza bez problemu, nawet jak pobieram całą okolicę radia - najwyżej prędkość renderowania spada (czasem tylko do 3 FPS), ale się nawet nie zacina. Wolniej wtedy się porusza kamera, ale obrót nadal jest szybki.

U mnie też niemiłosiernie muliło. Zanim otworzę okno kendzi3D wyłączam "texture filter" i jest już dobrze. Przy czym jakość jest tylko trochę gorsza - nie przeszkadza w "modelowaniu".

Javnik · 2013-10-18 15:32:22

kazadam wrote:

Wiatm wszystkich !
Jestem nowym uczestnikiem OSM.
Proszę o weryfikację i uwagi Ratusza w Białymstoku. Nie podaję linku, ale obiekt jest na tagu centrum miasta.
Dziękuję jeśli ktoś znajdzie chwilę czasu.

Całkiem zgrabnie! Tylko coś tam z tą wieżą nie gra...w K3D wisi w powietrzu ponad niższą częścią.

kocio wrote:

OpenScienceMap wydaje mi się bardzo przyszłościowe - przypomina F4 (podłoże z mapy 2D, wygodna nawigacja myszką, dość duża możliwość zbliżenia), ale startuje od razu i znacznie szybciej odświeża widok po zmianie położenia lub kąta kamery. Poza brakiem dachów i kolorów ma problemy z elementami "wiszącymi" (min_level>0) , nie wyświetla też dodatkowych elementów zwiększających realizm, typu drzewa, tory, murki czy barierki. Ma też bardzo wysokie domyślne kondygnacje (przynajmniej pierwszą), przez co wszystkie budki/kioski/wiaty wychodzą nieproporcjonalnie duże - z drugiej strony pewnie dzięki temu ORCO Tower odzyskał właściwe proporcje wieżyczek.

Mi też przypadł do gustu. Najbardziej z rendererów webowych widać na nim moją ciężką pracę z mini obiektami[tu i tu] (chociaż aż kusi żeby dało się o 1-2 st. bardziej przybliżyć )

Ale to ciekawe, bo są przypadki gdzie rendering spisuje się znakomicie (IBM-wszystkie szczegóły ładniutkie) i gdzie nie daje rady (Zebra Tower-naprzeciwko pogubiła słupy )

kendzi · 2013-10-18 18:41:45

kocio wrote:

Szkoda, że z Kendzi3D nie da się korzystać równie łatwo

Czego dokładnie brakuje? Co jest problemem?

skyraster wrote:

U mnie Kendzi3D działa, ale na tyle wolno, że nie wiem, czy to konfiguracja kompa, czy prostu tak ma być... Jeśli np. chcę załadować podgląd większego obiektu (np. PL Radio Warszawa), to muszę wyłączyć moduł 3D, załadować plik i włączyć ponownie, aby się JOSM nie zwiesił.

Zdecydowanie tak nie powinno być. Możesz powiedzieć coś więcej? Jaka konfiguracja, java, komputer. Możesz dokładnie krok po kroku podać co robisz? Możesz podesłać na maila plik którego ładowanie wywala plugin?

marcin_b wrote:

U mnie też niemiłosiernie muliło. Zanim otworzę okno kendzi3D wyłączam "texture filter" i jest już dobrze

Jedyny powód dla takiego zachowania to naprawdę bardzo mała ilość pamięci na karcie graficznej. Generalnie filtrowanie wykonywane jest sprzętowo od lat. W dzisiejszych czasach nie powinno mieć żadnego wpływu na wydajność.

skyraster · 2013-10-18 18:55:42

kocio wrote:

OpenScienceMap wydaje mi się bardzo przyszłościowe - przypomina F4 (podłoże z mapy 2D, wygodna nawigacja myszką, dość duża możliwość zbliżenia), ale startuje od razu i znacznie szybciej odświeża widok po zmianie położenia lub kąta kamery. Poza brakiem dachów i kolorów ma problemy z elementami "wiszącymi" (min_level>0) , nie wyświetla też dodatkowych elementów zwiększających realizm, typu drzewa, tory, murki czy barierki. Ma też bardzo wysokie domyślne kondygnacje (przynajmniej pierwszą), przez co wszystkie budki/kioski/wiaty wychodzą nieproporcjonalnie duże - z drugiej strony pewnie dzięki temu ORCO Tower odzyskał właściwe proporcje wieżyczek.

Na Webie tak tego nie czuć, ale OpenScience na Androidzie bardzo zgrabnie działa, doczytywanie danych nie jest mocno odczuwalne, jedyne mankamenty moim zdaniem to kwestia zmiany kąta patrzenia - dość nieintuicyjnie to rozwiązali oraz szybkie wygaszanie modeli 3d przy trochę większym widoku. Natomiast pomysł na obracanie i zoomowanie bardzo fajny i użyteczny.

skyraster · 2013-10-18 19:06:42

kendzi wrote:

Zdecydowanie tak nie powinno być. Możesz powiedzieć coś więcej? Jaka konfiguracja, java, komputer. Możesz dokładnie krok po kroku podać co robisz? Możesz podesłać na maila plik którego ładowanie wywala plugin?
marcin_b wrote:
U mnie też niemiłosiernie muliło. Zanim otworzę okno kendzi3D wyłączam "texture filter" i jest już dobrze
Jedyny powód dla takiego zachowania to naprawdę bardzo mała ilość pamięci na karcie graficznej. Generalnie filtrowanie wykonywane jest sprzętowo od lat. W dzisiejszych czasach nie powinno mieć żadnego wpływu na wydajność.

Karta graficzna łącznie prawie 1GB, ramu też nie brakuje, więc to nie to. Może sterownik graficzny słabo radzi sobie z filtrowaniem? Faktycznie sprawdziłem przed chwilą, opcja texture filter wyłączona powoduje powrót do normalności (czyli komputer odpowiada i grafika jest płynna) i trzeba przyznać, że graficznie widok 3D prezentuje się bardzo fajnie i śmiga na poziomie 30fps. Przy włączonej opcji przywieszał mi JOSMa już przy ładowaniu (przygotowaniu zestawu danych) tak, że musiałem go ubijać, ale wygląda na to, że to nie tyle plik jest problemem co ilość danych (tekstur) przy włączonym filtrowaniu. Będę musiał sprawdzić czy przy OpenGL sytuacja jest podobna, jeśli się to filtrowanie włączy.

Last edited by skyraster (2013-10-18 19:07:12)

skyraster · 2013-10-18 19:23:48

miklobit wrote:

Trochę podglądam od środka te projekty OSM-3D które mają otwarte źródła i taka myśl mi przychodzi:
Jeśli na obecnym etapie (prostej specyfikacji) są spore rozbieżności w interpretacji i renderowaniu danych ( przez każdy projekt) to przy wprowadzeniu bardziej złożonych modeli to się jeszcze pogłębi. Zmierzam do tego, że w tej chwili nie istnieje żadna wspólna biblioteka do generowania z danych OSM warstwy pośredniej (danych 3D dla rendera).

Kwestia renderera to jedno, ale przygotowywanie danych to druga sprawa. W OSM jest rozpowszechniony schemat danych oparty o rastrowe kafelki, tyle że nie zawierają one tego, co pozwala na wykorzystanie przy renderingu 3D. Najlepszym wyjściem byłyby kafle wektorowe, ale tutaj trzeba by wypracować jakiś uniwersalny sposób podawania danych.

W zasadzie mógłby on być w idei identyczny z tym rastrowym (np. zoomy, rozkład katalogów), ale chodzi o to, aby podczas aktualizacji danych na serwerach OSM robić również aktualizację i przycinanie kafli wektorowych. OScience z tego co widziałem wykorzystuje jakiś format binarny, co jest całkiem dobrym wyjściem w przypadku większej ilości danych. Ostatecznie mógłby być xml (albo zipowany xml), ale musiałby mieć format odpowiedni dla renderera, aby system w zasadzie renderował, a nie zastanawiał się na jakiej wysokości renderować dany obiekt. Takie rzeczy powinny być załatwione już przy przetwarzaniu (przyjmowaniu i opracowaniu kafli) tak, aby renderer nie musiał np. interpretować osm-xml tylko od razu generował model na podstawie otrzymanych danych. Wówczas nie będzie miejsca na różną interpretację, ponieważ po stronie serwera będzie leżeć interpretacja, natomiast po stronie renderera ich pobieranie i wyświetlanie.

Myślę, że jeśli taki format (vector-tile) będzie znany i będą takie dane na serwerze, to developerzy widząc chociażby prekursorów (Kendzi3D, OsmScience), będą bardziej zaangażowani, niż jak obecnie, gdy trzeba to robić na swój sposób. Druga sprawa to doprecyzowanie specyfikacji, tak by nie było wątpliwości, np. na jakich wysokościach należy np. renderować obiekty (np. piętra). Dla mnie jako programisty np. liczy się konkretna wartość (np. piętro od, do, albo piętro od + wysokość piętra) - wtedy mam konkret. Jak ktoś daje sam poziom (+1, +2, +3), to bez informacji o rozmiarze piętra niewiele to daje, jeśli chce się mieć w miarę wierne odwzorowanie geometrii.

kazadam · 2013-10-18 19:33:15

Javnik wrote:

Całkiem zgrabnie! Tylko coś tam z tą wieżą nie gra...w K3D wisi w powietrzu ponad niższą częścią.

Dziękuję za zainteresowanie. U mnie (Kendzi3D) wydaje się Ok. ! Te wyższe połacie zrobione z ridge i edge.
Jak dojdę sposobu, to wkleję jpega.

kocio · 2013-10-18 21:13:47

@skyraster:

Dzięki za wyjaśnienia! Jeszcze musi mi się w mózgu ułożyć, bo nie wpadło mi do głowy, że można wykorzystać coś pośredniego i jakie to może mieć zalety i wady w porównaniu do zasysania bezpośrednio.

@Kendzi:

Mam na myśli sposób uruchomienia. Ostatnio znajomemu wspomniałem o OSM 3D i się podniecił jak to, więc szybko...:
1. Pobrałem i zainstalowałem Javę (akurat była zainstalowana, ale chodzi mi o problem =} )
2. Pobrałem i zainstalowałem JOSM (a już wiedziałem, że przez WebStart może nie chcieć ruszyć K3D)
3. Zainstalowałem Kendzi3D
4. Umiałem pobrać obszar w JOSM i poruszać się po nim w K3D

Trwało to dłużej, niż chciałem, ale akurat znajomy cierpliwie czekał. Większość użytkowników polegnie gdzieś w 2 punkcie nie doświadczając cudów wirtualnego spaceru.

Chociaż pod względem realizmu K3D wydaje mi się najlepsze, to stawiam na gotowe mapki 3D typu "fire and forget". OpenScienceMap nie udało mi się jeszcze pobrać na Androida, więc nie mam porównania, ale w przeglądarce naprawdę świetnie sobie radzi, w każdym razie szybciej niż F4 i elastyczniej niż OSMB. Jeśli nie chcemy się ograniczać do wąskiego grona bieżących użytkowników JOSM, to najpierw trzeba mieć jakieś demo (np. nasza Warszawa w 3D) no i móc je łatwo oraz efektownie pokazać. Dlatego choć mam najwięcej satysfakcji z K3D, to najwięcej uwagi poświęcam mapkom WWW+3D.

skyraster · 2013-10-18 21:39:43

kocio wrote:

Mam na myśli sposób uruchomienia. Ostatnio znajomemu wspomniałem o OSM 3D i się podniecił jak to, więc szybko...:
1. Pobrałem i zainstalowałem Javę (akurat była zainstalowana, ale chodzi mi o problem =} )
2. Pobrałem i zainstalowałem JOSM (a już wiedziałem, że przez WebStart może nie chcieć ruszyć K3D)
3. Zainstalowałem Kendzi3D
4. Umiałem pobrać obszar w JOSM i poruszać się po nim w K3D
Trwało to dłużej, niż chciałem, ale akurat znajomy cierpliwie czekał. Większość użytkowników polegnie gdzieś w 2 punkcie nie doświadczając cudów wirtualnego spaceru.

No właśnie z tą javą różnie bywa. U jednych działa OK, u innych będzie zacinać. Choć np. OSMScience na Andka jest napisany głównie w javie i działa całkiem szybko (ale ma wstawki natywne C++,więc w sumie czysta java to nie jest).

Edytor, który nie odstraszałby użytkowników musiałby być możliwie prosty w obsłudze, tak by tych klików było jak najmniej. Najlepiej aby wyglądał podobnie na zwykłych PCtach jak i na jednostkach mobilnych (np. tabletach, które są całkiem wygodne w obsłudze i mapowaniu w terenie). Z drugiej strony warto by było, aby profesjonaliści (np. geodeci) również mogli wykorzystać go do edycji (czyli konfigurowalność/mnogość opcji/obsługa sprzętu pomiarowego..itd). Poza tym nie ma się co oszukiwać - dopiero jak opanujemy mapowanie tekstur (nie mówię o prostych teksturach z bibliotek, tylko dedykowanych dla danych obiektów) i przechowywanie ich na serwerach + indoor (mapowanie wnętrz), wówczas będzie coś rewelacyjnego i podkręcającego uwagę innych.

Bo 3D wyglądające jak proste modele kartonowe w 2013 to jednak trochę za mało....

Announcement

#126 2013-10-17 10:11:54

Re: Przykłady OSM 3D

#127 2013-10-17 10:15:36

Re: Przykłady OSM 3D

#128 2013-10-17 11:46:48

Re: Przykłady OSM 3D

#129 2013-10-17 12:22:35

Re: Przykłady OSM 3D

#130 2013-10-17 14:34:29

Re: Przykłady OSM 3D

#131 2013-10-17 18:15:05

Re: Przykłady OSM 3D

#132 2013-10-17 18:53:26

Re: Przykłady OSM 3D

#133 2013-10-17 20:24:35

Re: Przykłady OSM 3D

#134 2013-10-17 21:50:18

Re: Przykłady OSM 3D

#135 2013-10-17 22:20:16

Re: Przykłady OSM 3D

#136 2013-10-18 00:29:04

Re: Przykłady OSM 3D

#137 2013-10-18 11:59:23

Re: Przykłady OSM 3D

#138 2013-10-18 12:45:58

Re: Przykłady OSM 3D

#139 2013-10-18 12:58:45

Re: Przykłady OSM 3D

#140 2013-10-18 13:20:34

Re: Przykłady OSM 3D

#141 2013-10-18 13:32:42

Re: Przykłady OSM 3D

#142 2013-10-18 15:12:49

Re: Przykłady OSM 3D

#143 2013-10-18 15:32:22

Re: Przykłady OSM 3D

#144 2013-10-18 18:41:45

Re: Przykłady OSM 3D

#145 2013-10-18 18:55:42

Re: Przykłady OSM 3D

#146 2013-10-18 19:06:42

Re: Przykłady OSM 3D

#147 2013-10-18 19:23:48

Re: Przykłady OSM 3D

#148 2013-10-18 19:33:15

Re: Przykłady OSM 3D

#149 2013-10-18 21:13:47

Re: Przykłady OSM 3D

#150 2013-10-18 21:39:43

Re: Przykłady OSM 3D

Board footer