Przykłady OSM 3D

Dotevo · 2013-10-31 21:45:05

Ale jakie to dla nas ma znaczenie czy f4 jest komercyjne? Im wiecej projektow korzysta z 3d tym wiecej edytujacych i danych

marek kleciak · 2013-10-31 21:50:48

Korespondowalem z nimi. Wychodzi mi, ze na razie niezbyt maja zasoby osobowe, by robic cos wiecej.
Generalnie to proponowalem spotkanie na szczycie w sprawie 3D bo balagan troche jest w tym wszystkim a z doswiadczenia wiem, ze najlepiej sie spotkac inaczej dyskusje beda trwaly nastepny rok a i tak nie bedzie zgody w ielu sprawach. Przy osobistym spotkaniu latwiej jest przedyskutowac rozne kwestie.

skyraster · 2013-10-31 21:57:47

marek kleciak wrote:

2. Tordanika przestalem wspomagac gdy wyjawil mi ze mysli o zamianie swojego narzedzai na komercyjne.
3. Francuzi z f4 juz sa komercyjni.

A czy ta "komercyjność" to jakiś poważny problem, uniemożliwiający np. wsparcie merytoryczne ze strony społeczności OSM? Czy to oznacza, że aplikacje, które mają charakter "komercyjny" mają być traktowane jako "gorsze", bo nie są open-source i darmowe? Wspomniałeś "trzeba z czegoś żyć", a zastosowania komercyjne mogą umożliwić utrzymanie projektu/serwera..itd

kazadam · 2013-10-31 22:04:43

Włączę się do do dyskusji, choć jestem "kot" w mapowaniu.
Nie brakuje mi w Josm funkcji pecyzyjnego rysowania. Wspomniane Cad'y są do tego wyspecjalizowane i taki podkład łatwo zaimportowć i "dokończyć" w JOSM (Inkscape też się nadaje).
Przeszkadza mi natomiast złe zarządzanie pamięcią, pracuje na "wolnym" komputerze, który często się zawiesza (chyba z tego powodu). Być może jest jakaś sztuczka, która rozwiązuje ten problem, a ja jeszcze do niej nie dotarłem.
Związane z tymi tematami zadam pytanie: często zaimportowany z pdf okręg składa sie z dużej ilości nodów, czy powinienem ograniczać ich ilość, czy ważniejsza jest wierność kształtu?

marek kleciak · 2013-10-31 23:17:26

Czesc Skyraster! Nie, powazny problem to nie jest, jednak jestem zwolennikiem wolnego oprogramowania tam, gdzie sie da. Jesli nie bedzie alternatywy dla rozwiazan komercyjnych, to oczywiscie wole to, niz nic. Generalnie cale OSM zbliza sie do takiego stopnia kompleksowosci ze coraz trudniej bedzie to dalej rozwijac; albo przy pomocy organizacji (foundation) sterujacej rozwojem softu albo tez za pomoca czesciowo komercyjnych rozwiazac.

Kazadam,
jasnemozna tak robic. To dobra droga do uzyskania lepszej jakosci modeli.Jednak troche to utrudni na wejscie prace dla nowicjuszy.Bedamusieliopanowac jeszcze jeden pakiet software.
Co do wiernosci ksztaltu: 3Dgeneruje tak ogromnailoscpunktów, ze dobrze jest generalizowac. Mysle ze jesli zamienimy okrag na poligon majacy n- boków, to odejscie od ksztaltu okregu o 5 cm (max róznica odleglosci miedzy cieciwa a okregiem) to juz bedzie prawdziwy wyczyn a w 3D taki model bedzie wygladal super.

Przyszlosciowo bylbym jednak za wporwadzeniem kategorii okrag, spline, kula do definicji podstawowych elementów w OSM. No ale do tego droga daleka. Wlasnie z powodu rosnacej w wyniku takiej (ewetualnej) implementacji trudnosci na wejscie dla pakietów open source...

skyraster · 2013-11-01 00:40:27

marek kleciak wrote:

Czesc Skyraster! Nie, powazny problem to nie jest, jednak jestem zwolennikiem wolnego oprogramowania tam, gdzie sie da. Jesli nie bedzie alternatywy dla rozwiazan komercyjnych, to oczywiscie wole to, niz nic. Generalnie cale OSM zbliza sie do takiego stopnia kompleksowosci ze coraz trudniej bedzie to dalej rozwijac; albo przy pomocy organizacji (foundation) sterujacej rozwojem softu albo tez za pomoca czesciowo komercyjnych rozwiazac.
(...)
Przyszlosciowo bylbym jednak za wporwadzeniem kategorii okrag, spline, kula do definicji podstawowych elementów w OSM. No ale do tego droga daleka. Wlasnie z powodu rosnacej w wyniku takiej (ewetualnej) implementacji trudnosci na wejscie dla pakietów open source...

Cześć No właśnie bo się trochę zastanawiałem o losie współpracy mojego softu z OSM (w założeniu ma być komercyjne, bo nie widzę innej sensownej metody utrzymania/prowadzenia projektu). Tyle że ja akurat miałem w planach udostępnić bezpłatnie część licencji osobom najbardziej zaangażowanym w projekt (dziwnie by było, aby ktoś kto przykłada się do edycji publicznie dostępnych danych miałby jeszcze płacić za edytor) - kiedyś to zapowiadałem (przy przystąpieniu przeze mnie do OSM) przy wczesnym etapie projektu i to dalej podtrzymuję. Mam nadzieję, że ludzie ze społeczności nie będą się krzywo patrzeć - że coś jest komercyjne to jest be, bo open-source jest lepsze

A te obiekty - to w sumie ciekawy temat poruszyłeś, bo sam ostatnio się z tym borykałem (dodatkowe obiekty). W programie przewiduję u siebie import danych (np. z DXF, DGN, XML)..itd i w niektórych formatach mamy zdefiniowane obiekty złożone. Z drugiej strony w OSM mamy do czynienia z liniami i punktami - nawet poligony są definiowane raczej ze stylu niż z konkretnego typu obiektu powierzchniowego. Gdybym np. chciał dodać rysowanie okręgów, kształtów, to nagle się okazuje że można je na potrzeby OSM zamienić w "drogi" (łamane / "polyline"), ale w drugą stronę to byłby problem (bo trzeba by zachowywać jakieś dane dot. kształtu, aby móc go odtworzyć jako obiekt a nie linie). Z drugiej strony implementacja OSM jest przez swój format prosta i dzięki temu generuje mniej problemów niż kwestie związane z kształtami (np. prostokąt w projekcji jednego układu w drugi nie musi wcale być prostokątem, podobnie łuki/okręgi.. - układy odniesienia potrafią nieźle skomplikować sytuację). Inna kwestia to np. opisy tekstowe (etykiety) - w takim Autocadzie mamy obiekt TEXT - w JOSM nie ma takiego typu - więc sporo racji w tym, że jest to temat na dłużej (szczególnie jeśli chodzi o globalną implementację i zmianę API).

Dobra bo już idę dookoła... chodzi o to, że robiąc pakiet tylko pod OSM ma się tę wolność, że można robić wyspecjalizowaną - dedykowaną aplikację - i nie ma takiego nacisku na różne szczegółowe specyfikacje. I tak powstał JOSM -z najprostszych pomysłów, które z reguły okazują się sprawdzone. Ale np. gdyby geodeta chciał wykorzystać taki program, to nagle pojawia się problem - z kompatybilnością obiektów/układów odniesienia/zastosowaniem..itd Tu z kolei wchodzę ja, bo chciałbym umożliwić choć częściowe przejście z jednych danych na drugie (i vice versa).

Bo np. taka sprawa z mapowaniem - geodeci mają swoje operaty, w których mają zawarte obliczenia jakie doprowadziły do uzyskania odpowiednich współrzędnych. W przypadku OSM nie ma takiego wymogu, a czasem przydałoby się wiedzieć, jakie punkty są oznaczone precyzyjnie (np. bazując na osnowie i dokładnym pomiarze), a jakie mniej dokładnie (i które mogą wymagać kiedyś poprawy). Jak np. w programie udostępniam możliwość wyznaczenia punktów pośrednich z wcięć liniowych lub przecięć, to jeśli z OSM miałbym dane, które punkty mamy określone z jaką precyzją, mógłbym oszacować czy np. obiekt jaki pomierzę - będzie miał wystarczającą dokładność. I fajnie by było gdyby takie dane były dostępne dla każdego, kogo to interesowałoby.

Szczególnie mogłoby to pomóc w sytuacjach, w której nieświadomi początkujący użytkownicy przesuwają już narysowane obiekty, ponieważ "nie pasują do podkładu". A tak mielibyśmy obiekty "zamrożone" (jakieś tagi typu freezed/fixed position), których nie dałoby się w prosty sposób przesuwać i psuć geometrii. Obiekty te mogłoby służyć także jako referencje / obiekty bazowe do wyznaczania innych (np. elementów w terenie - położenia drzew..itd).

Bo np. ja zakładam, że mając dalmierz laserowy (są coraz tańsze) można zrobić bardzo precyzyjne pomiary - także przydatne w 3D. Precyzja by się przydała także w przypadku gdyby OSM miał służyć do bardziej precyzyjnych celów (np. wspomaganie nawigacji i samoprowadzących samochodów). Większość pewnie i tak nie przykłada wagi do dużej precyzji, ale zakładam, że w przyszłości będzie się to zmieniać (dostępność sprzętu i metod pomiarowych) - i wtedy możliwość osadzenia takich danych byłaby pomocna. Podobnie kwestia pomiarów GPS - dziś można relatywnie tanio zmontować układy do pozycjonowania z dokł. centymetrową co możnaby wykorzystać w przypadku OSM. Nawet jeśli ktoś twierdzi że to mało istotne - to np. tagi dotyczące teksturowania obiektów są już nam bliższe, więc tak czy inaczej API/specyfikacja OSM musi być rozszerzona.

Władysław Komorek · 2013-11-01 08:02:43

Czy ktoś zna WMS budynków w Watykanie?
Zauważyłem, podczas rysowania w 3D, że obrysy Bazyliki są orientacyjne i nie szczegółowe.

Dotevo · 2013-11-01 08:06:52

No ale pamiętajcie też o openbuildingmodels czyli o modelach podpiętych do osm. Wg mnoe tagowanie jest mniej dokladne, ale za to szybsze. Wieże Eiffla można zribic w blenderze zamiast wymyslac specyficzne tagi

marek kleciak · 2013-11-01 10:50:35

Jasne ze tak, Dotevo. Inaczej sie nie da. Potrzebny jest jednak soft opensource, gdzie bedzie mozna te modele umieszczac. To jest mój argument przeciw Francuzom z f4: Stworzyli soft, jednak go nie udostepniaja i w konsekwencji sa jedyni ktorzy na dzien dzisiejszy to potrafia. Ludzie nie podpinaja wiec pod OSM wolnych modeli. Nie tedy droga.

kendzi · 2013-11-01 10:55:16

Dotevo wrote:

No ale pamiętajcie też o openbuildingmodels

Ale zaraz, czy ten serwis w końcu zaczął działać? Można tam wrzucić jakiś model? Można przez jakieś api pobrać modele dla danego regionu i wyświetlić w zewnętrznym programie?

Niestety ale ta strona została wykonana jako praca naukowa i pozostała w takim stanie. Czyli obecnie jest to jedynie niezbyt przydatna prezentacja kolejnej idei.

Dotevo · 2013-11-01 13:16:26

kendzi wrote:

Dotevo wrote:
No ale pamiętajcie też o openbuildingmodels
Ale zaraz, czy ten serwis w końcu zaczął działać? Można tam wrzucić jakiś model? Można przez jakieś api pobrać modele dla danego regionu i wyświetlić w zewnętrznym programie?
Niestety ale ta strona została wykonana jako praca naukowa i pozostała w takim stanie. Czyli obecnie jest to jedynie niezbyt przydatna prezentacja kolejnej idei.

Myslalem, ze cos ruszylo w tej kwestii, ale jesli nie to przeciez takie cos mozna zrobic samemu na dokladnie takiej samej zasadzie + generowanie paczek z modelami planet.tar.bz2 i wycinkow dla krajow, a potem reszta juz sama sie potoczy. Trzeba pamietac, ze zawsze znajdzie sie ksztalt, ktorego nie da sie opisac tagami bo jest zbyt wymyslny. Dodatkowo jest szansa na modele np. pomnikow i fontann.

kendzi · 2013-11-01 14:01:03

Dotevo wrote:

przecież takie coś można zrobić samemu na dokładnie takiej samej zasadzie + generowanie paczek z modelami planet.tar.bz2 i wycinków dla krajów

Zrobić to można absolutnie wszystko. Niestety musi się znaleźć osoba która taki temat pociągnie. Tego akurat tematu nikt przez tyle lat nie podjął na serio. Być może Ty jesteś w stanie się tym zająć?

Dotevo wrote:

potem reszta już sama się potoczy

Nic, nigdy, nie toczy się samo. Ktoś musi zająć się administracją, sprawami hostingu oraz obsługą bieżących zgłoszeń od użytkowników. Inaczej będzie to kolejna idea wisząca gdzieś w sieci...

Dotevo · 2013-11-01 14:59:44

Moze bym mogł, ale musze przyznac, ze nie jestem obeznany w temacie 3D.

skyraster · 2013-11-01 17:51:55

marek kleciak wrote:

Jasne ze tak, Dotevo. Inaczej sie nie da. Potrzebny jest jednak soft opensource, gdzie bedzie mozna te modele umieszczac. To jest mój argument przeciw Francuzom z f4: Stworzyli soft, jednak go nie udostepniaja i w konsekwencji sa jedyni ktorzy na dzien dzisiejszy to potrafia. Ludzie nie podpinaja wiec pod OSM wolnych modeli. Nie tedy droga.

A to F4 pozwala na umieszczanie modeli? Z tego co widzę to jest tylko przeglądarka (Viewer). Oni mają kod źródłowy do generowania 3D ale co użytkownikom po nim, skoro oni chcą łatwo modelować, a nie tylko pobierać i wyświetlać.

Inna sprawa - załóżmy że ktoś chciałby się pokusić o stworzenie bądź zaimportowanie teksturowanego modelu do OSM (takiego, którego nie da się w prosty sposób zrobić na dotychczasowych tagach do generowania w 3D). Podejrzewam, że jedyny sposób na to, to umieszczenie pliku z danymi i teksturami na serwerze i oznaczenie adresu tych miejsc w tagach. Powstaje jednak pytanie, w jakim formacie udostępnić model? DAE, X3D, VRML czy jeszcze jakiś inny? Z teksturami sprawa jest prosta (JPG/PNG wchodzą w grę), choć możnaby mieć format podobny do androidowego APK (spakowany zipem, w którym byłyby zarówno tekstury, jak i geometria 3D i rozpis co i jak). Faktycznie tutaj ideałem by była jakaś biblioteka opensource, którą możnaby wykorzystać do importu i przetwarzania tych danych w zoptymalizowaną geometrię. Nie wspominam już szerzej o wypracowaniu faq odnośnie sytuacji w których mamy podstawowe dane (np. wysokości) oraz szczegółowy model 3D - aplikacje wyświetlające powinny umiejętnie wybrać co wyświetlać - czy na szybko generowane 3D, czy też gotowy model.

Jednak istotniejsze by było wypracowanie jakiegoś minimum. Jaki format, gdzie składujemy modele i tekstury, API do wkładania/pobierania tych danych.

marek kleciak · 2013-11-01 17:54:01

Niejest az tak trudne. A jak w to byswszedl, moglbys pociagnac temat indoor mapping w 3D. Dospolki z Kendzimi jeszcze paroma ludzmimozna by przegonic f4. Wic polega na tym, ze f4 po prostu udoskonalil kod opensource jaki wzial z opensciencemap.org tworca mi powiedzial

skyraster · 2013-11-01 18:19:53

marek kleciak wrote:

Niejest az tak trudne. A jak w to byswszedl, moglbys pociagnac temat indoor mapping w 3D. Dospolki z Kendzimi jeszcze paroma ludzmimozna by przegonic f4. Wic polega na tym, ze f4 po prostu udoskonalil kod opensource jaki wzial z opensciencemap.org tworca mi powiedzial

W sumie to już siedzę w tym temacie od prawie roku, robiąc aplikację pod androida i windowsa - pierwotnym jej przeznaczeniem było modelowanie (inwentaryzacja) pomieszczeń, bazując na precyzyjnych pomiarach z wykorzystaniem np. dalmierza (ew. taśmy mierniczej). Tyle że aplikacja w zakresie modelowania indoor pracuje w trybie lokalnym XY (tak jest łatwiej modelować), natomiast otwartą pozostaje kwestia wkalibrowania planu w 3D i eksportu do OSM (a także importu) - bo jak wiemy OSM pracuje na globalnym ukłądzie WGS84 . To wszystko trzeba zrobić uwzględniając obecne tagi dla modelowania indoor (czyli aby było to kompatybilne z danymi, tworzonymi przez użytkowników w JOSM).
Np. nie wyobrażam sobie modelowania indoor na mapie we współrzędnych globalnych (geodezyjnych) gdy model jaki edytujemy jest obrócony - bawienie się z filtrami w JOSM jakoś do mnie nie trafia

Tyle że ja nie bazowałem na wytycznych OSM (ani też nie korzystałem z kodu opensource osm), lecz poszedłem trochę inną drogą, która by zapewniała odpowiedni zestaw danych do generowania precyzyjnych wymiarów + ich wizualizacji w 3D, uwzględniając specyficzne potrzeby użytkowników, którzy wykonują inwentaryzacje.
I teraz możnaby dorobić sposób ich eksportu do OSM, choć nie będzie to proste jak eksport danych płaskich - tutaj trzeba by siąść i ustalić szczegóły formatu ,tym bardziej aby opanować sytuacje typu import danych z indoor mappingu OSM do edytora (musiałby mieć z OSM wszystkie dane, jakich edytor wymaga, aby dane były prawidłowo obrabiane).

No i gdybym miał robić coś z w zakresie bibliotek - to ja siedzę praktycznie w C++, z javy korzystam tylko wtedy gdy muszę napisać jakiś kod obsługujący funkcje w androidzie (np. okna dialogowe lub współpracę z siecią) - ale to są drobnostki. A z tego co widziałem to sporo kodu związanego z OSM jest napisana w javie (np. JOSM).

W zasadzie, wracając do 3D i formatu - to mógłbym coś zaproponować, mam też u siebie trochę niewykorzystanego miejsca na wykupionym serwerze.Teoretycznie jest możliwe napisać coś, co pozwalałoby by na pobieranie danych z serwera i ich wizualizację (ale w programie nie na stronie web). Do tej pory mam już napisany moduł pobierający dane z serwera OSM dla danego widoku, więc nie ma większego problemu (no może poza czasem, z którym gorzej - bo jeszcze poprawiam pewne funkcje w programie), aby móc pociągnąć testowo taki model (albo tekstury) z mojego serwera - lub napisać wysyłanie gotowego modelu z teksturami na serwer.

Zdecydowanie bardziej problematyczne byłoby zakodowanie finalnego kodu serwera (API) ponieważ ja mam dostęp jedynie do skryptów PHP i nie mogę grzebać, ani umieszczać programów bezpośrednio na serwerze i zrobić to tak, aby było najwydajniej (tj. napisać usługę bezpośrednio umieszczaną na serwerze unixowym). Z drugiej strony skrypty w PHP są łatwe w przenoszeniu, więc każdy kto ma dostęp do FTP serwera mógłby takie pliki umieścić i skonfigurować, aby pracowały jako mini-serwery z modelami 3D.

Ale nasuwa się jednak pytanie - czy rozproszenie danych 3D na pomniejsze serwery będzie dobre? Myślę, że docelowo najlepszym wyjściem byłoby składowanie model i tekstur na serwerze globalnym OSM, aby nie było zbyt dużego rozproszenia i wynikających z problematycznych sytuacji typu zbyt duże obciążenie lokalnych serwerów przechowujących część modeli, albo odłączenie usługi.

Last edited by skyraster (2013-11-01 18:45:11)

Dotevo · 2013-11-01 18:53:29

Na same modele nie ma miejsca w bazie OSM ponieważ jeśli ktoś ich nie potrzebuje to ściągnięcie poland.osm.bz2 byłoby zbyt uciążliwe. Dlatego wg mnie to powinno wyglądać tak jak API OpenStreetMap czyli wersje, changesety itp. dla modeli. Modele powinny być w formacie tekstowym, a nie binarnym i jaki to format będzie to powinien wybrać ktoś kto się na tym dobrze zna. Mogę zaprojektować API i bazę w kilka dni, ale pytanie czy to ma sens, czy znajdzie się osoba chętna do dodawania modeli (no i najlepiej nie jedna bo robienie serwisu dla jednej osoby nie ma sensu) i czy ktokolwiek to w jakiś sposób wykorzysta. Mam obecnie na głowie kilka innych projektów, w których widzę perspektywy, a ten na obecną chwilę wydaje mi się nieco zbędny.

skyraster · 2013-11-01 19:19:16

Dotevo wrote:

Na same modele nie ma miejsca w bazie OSM ponieważ jeśli ktoś ich nie potrzebuje to ściągnięcie poland.osm.bz2 byłoby zbyt uciążliwe. Dlatego wg mnie to powinno wyglądać tak jak API OpenStreetMap czyli wersje, changesety itp. dla modeli. Modele powinny być w formacie tekstowym, a nie binarnym i jaki to format będzie to powinien wybrać ktoś kto się na tym dobrze zna. Mogę zaprojektować API i bazę w kilka dni, ale pytanie czy to ma sens, czy znajdzie się osoba chętna do dodawania modeli (no i najlepiej nie jedna bo robienie serwisu dla jednej osoby nie ma sensu) i czy ktokolwiek to w jakiś sposób wykorzysta. Mam obecnie na głowie kilka innych projektów, w których widzę perspektywy, a ten na obecną chwilę wydaje mi się nieco zbędny.

No i coś w tym jest - jeśli chodzi o bardziej złożone modele to zostaje np. blender albo inne pakiety do modelowania w 3D. Tyle, że to nie jest na tyle proste, aby początkujący mógł to opanować w mig. Łatwiej jest po prostu doszkolić się w tagach 3D i robić je w przybliżony sposób w JOSMie (a przynajmniej efekty można obserwować choćby w serwisach typu F4). Choć tutaj wciąż brakuje sposobu mapowania tekstur - a takie dane mogłyby teoretycznie być w tagach, aby można było umieścić własną pełną teksturę (np. frontu budynku - a nie bawić się w kompletowanie elementów z dotychczasowej biblioteki elementów tekstur).
Z drugiej strony - do szczegółowego teksturowania wciąż wykorzystuje się pakiety 3D, więc dla zwykłego, niezbyt zaangażowanego użytkownika temat na razie odpada.

A co do modeli - mogłyby być w innej części bazy - tak aby dociągać je, w miarę możliwości, a nie razem z danymi wektorowymi OSM (jako inne zapytanie). Tekstowy format zapisu modeli - są łatwiejsze do ewentualnej edycji i sprawdzenia przez człowieka (a to się przydaje). Binarki możnaby zastosować w przypadku cache, gdzie danych się nie edytuje, natomiast liczy się szybkość pobrania i wyświetlania (w końcu tekst i tak trzeba sparsować, a dane z binarki można wrzucić bez parsowania).

miklobit · 2013-11-01 19:46:34

Dotevo wrote:

Modele powinny być w formacie tekstowym, a nie binarnym i jaki to format będzie to powinien wybrać ktoś kto się na tym dobrze zna.

Z otwartych formatów które są tekstowe oraz przechowywane w XML to mamy np X3D i XML3D.
Ten ostatni wydaje się bardziej obiecujący (pod kątem OSM3D ) przynajmniej z dwóch powodów: przeglądarki z obsługą webGL mogą bezpośrednio renderować obiekty xml3d (przez bibliotekę js), jest również mocno zawansowany projekt który łączy repozytorium, system kontroli wersji oraz API do zdalnego przechowywania oraz grupowej edycji obiektów w tym formacie.
Jest też konwerter opensource VRML/X3D/XML3D. A sam format ma duże szanse na standaryzaję przez W3C.

Tak zupełnie przy okazji, to Google właśnie wypięło sie na społeczność modelującą 3D i zablokowało w październiku publikację nowych obiektów z 3Dwarehouse na GoogleEarth:
https://groups.google.com/forum/?hl=pl# … pXUQA2bJ2s.
Z tłumaczeń wynika, że idą w stronę technologi automatycznego zbierania danych dla modeli 3D.
OSM z pewnością przyciągnie część ludzi, którzy będą chcieli gdzieś przenieść/kontynuować swoją pracę :-)

Last edited by miklobit (2013-11-01 19:48:43)

Dotevo · 2013-11-01 19:53:04

a nie da się tego projektu jakoś wykorzystać? Na jakiej licencji są modele zawarte w bazie? Może odpowiedni tag typu data:3drepo=ID_MODELU

Edit: Doczytałem. Rozumiem, że to komercyjna aplikacja, która pozwala taki serwer postawić. Wszystko fajnie, ale myślę, że opieranie się na komercyjnym projekcie jako trzon jest słabe. API/serwer powinny być otwarte, a aplikacja do edycji może być zamknięta.

Władysław Komorek · 2013-11-01 19:54:45

Na życzenie Kendzi zrobiłem wstępnie listę tagów potrzebnych do modelowania podstawowych obiektów w 3D.
Template:Map Features:3D - https://wiki.openstreetmap.org/wiki/Tem … eatures:3D

balrog-kun · 2013-11-01 20:24:15

Na openstreetmap.pl jest miejsce na repozytorium modeli jesli potrzeba, i postawienie jakiegos interfejsu w dowolnej technologii. Nie jestem pewien czy format tekstowy ma tu zalety bo diffowanie takich plikow i tak nie ma sensu. A binarnym mozna od razu zawrzec tekstury. Jesli ktos ambitny chcialby to zrobic (np. Dotevo) to mozna sie pokusic o konwersje z dowolnego formatu na docelowy po stronie serwera, tak zeby uzytkownicy mogli rysowac w sketczupie czy blenderze, ew. tez jakims webowym edytorze, albo nawet pluginie dla JOSMa. Przydalby sie interfejs w stylu wiki, taki gdzie mozna podgladac historie zmian. Gdzies widzialem funkcje wizualizacji zmian w modelu za pomoca kolorow (moze w thingiverse).

miklobit · 2013-11-01 20:25:14

Dotevo wrote:

a nie da się tego projektu jakoś wykorzystać? Na jakiej licencji są modele zawarte w bazie? Może odpowiedni tag typu data:3drepo=ID_MODELU
Edit: Doczytałem. Rozumiem, że to komercyjna aplikacja, która pozwala taki serwer postawić. Wszystko fajnie, ale myślę, że opieranie się na komercyjnym projekcie jako trzon jest słabe. API/serwer powinny być otwarte, a aplikacja do edycji może być zamknięta.

No właśnie nie wydaje mi się, że to komercyjny projekt, mimo , że znaczek TM to sugeruje.
Napisałem pytanie do autorów, bo informacje na stronie wskazują, że kod żródłowy będzie dostępny, a uzyte baza/biblioteki są opensource.
Ciekawą funkcją jest jednoczesna obsługa wielu formatów 3D - czyli wewnętrzna reprezentacja w bazie umozliwia konwersję na żądany format w momencie pobierania/zapisu obiektów .

Last edited by miklobit (2013-11-01 20:29:32)

marek kleciak · 2013-11-01 21:05:13

Sluchajcie,
jak tak to wszystko czytam, to dochodze do wniosku, ze trzeba by sie spotkac, pogadac i cos wspolnie z tym zrobic.
Chetnie wezme troche urlopu i przyjade do Polski. Moglibyscie wybrac sie do Poznania? Ewentualnie Lodz bo wtedy Prof Sankowski moglby z pewnoscia jakis nocleg zorganizowac a u niegosa ludzie, którzy juz nad tym tematem ze mna siedzieli a maja obecnie przerwe techniczna z powodu konczenia doktoratów (inaczej stypendia do zwrotu).
Zrobienie czegos tak mocnego w Polsce to bylo by cos wspanialego! Jestem pewien, ze wszyscy by sie na to przesiedli.

Edit: Wlodku, wielkie dzieki za zrobienie zestawienia!

Last edited by marek kleciak (2013-11-01 21:09:18)

kendzi · 2013-11-01 21:55:08

Github również posiada prosty mechanizm dla wizualizacji zmian w modelach 3d:
https://help.github.com/articles/3d-file-viewer

Z moich doświadczeń wynika że obecnie jedyny format w miarę wspierany przez różne edytory 3D to niestety OBJ. Jednak sam format ma drugorzędne znaczenie. W razie potrzeby można go skonwertować na na inny. Najważniejsze aby mieć centralny serwis gdzie takie modele można by wgrywać i nimi zarządzać, wraz z api które pozwoli pobrać i wyświetlić je w różnych aplikacjach.

Announcement

#176 2013-10-31 21:45:05

Re: Przykłady OSM 3D

#177 2013-10-31 21:50:48

Re: Przykłady OSM 3D

#178 2013-10-31 21:57:47

Re: Przykłady OSM 3D

#179 2013-10-31 22:04:43

Re: Przykłady OSM 3D

#180 2013-10-31 23:17:26

Re: Przykłady OSM 3D

#181 2013-11-01 00:40:27

Re: Przykłady OSM 3D

#182 2013-11-01 08:02:43

Re: Przykłady OSM 3D

#183 2013-11-01 08:06:52

Re: Przykłady OSM 3D

#184 2013-11-01 10:50:35

Re: Przykłady OSM 3D

#185 2013-11-01 10:55:16

Re: Przykłady OSM 3D

#186 2013-11-01 13:16:26

Re: Przykłady OSM 3D

#187 2013-11-01 14:01:03

Re: Przykłady OSM 3D

#188 2013-11-01 14:59:44

Re: Przykłady OSM 3D

#189 2013-11-01 17:51:55

Re: Przykłady OSM 3D

#190 2013-11-01 17:54:01

Re: Przykłady OSM 3D

#191 2013-11-01 18:19:53

Re: Przykłady OSM 3D

#192 2013-11-01 18:53:29

Re: Przykłady OSM 3D

#193 2013-11-01 19:19:16

Re: Przykłady OSM 3D

#194 2013-11-01 19:46:34

Re: Przykłady OSM 3D

#195 2013-11-01 19:53:04

Re: Przykłady OSM 3D

#196 2013-11-01 19:54:45

Re: Przykłady OSM 3D

#197 2013-11-01 20:24:15

Re: Przykłady OSM 3D

#198 2013-11-01 20:25:14

Re: Przykłady OSM 3D

#199 2013-11-01 21:05:13

Re: Przykłady OSM 3D

#200 2013-11-01 21:55:08

Re: Przykłady OSM 3D

Board footer