Propozycja indoor wg. kolegi Gomar1985 jest nie do konca przemyslana a to z tego powodu, ze pojawiaja sie tam problemy typu np. drzwi. Pomyslmy teraz chocby o routingu: jesli drzwi musimy rysowac do kazdego pomieszczenia dwukrotnie bo obszary nie przylegaja do siebie, to powoduje to koniecznosc laczenia tych punktów ze soba wektorami dróg.
Rozwiazanie o którym teraz krótko pisze czeka spisania na wiki: Wektor bedacy “sciana” miedzy dwoma pomieszczeniami otrzymuje kategorie grubosc i wysokosc. Suma wybranych scian jest laczona w pomieszczenia przy pomocy relacji. Umozliwia to robienie takich elementów jak: wneka, elementy pólotwarte (np. w restauracji, muzeum), swietliki. Takze powierzchnie pólotwarte które chcemy policzyc jako obszar ale nie zamkniete ze wszystkich stron “scianami” moga byc opisane przy pomocy relacji. Wlasciwie powinnismy sie teraz spotkac z Dotevo i omówic bardziej szczególowo temat.
Nie uważam, aby była nieprzemyślana. W większości przypadków się sprawdzi. Nie powinniśmy na siłę szukać problemów bo wtedy się już nikt w tym nie połapie, a skończy się na tym, że nikt nie doda danych bo nie jest pewien jaki rodzaj glazury jest w toalecie.
Ten schemat jest prosty w wykonaniu, łatwy w implementacji. Uważam, że routing mógłby tu bazować na zwykłych drogach tak aby aplikacja nie obsługująca indoor mogła nas przeprowadzić przez galerię, a drzwi to wektor łączący 2 pomieszczenia w przypadku gdy nie znamy ich szerokości (czyli prawie zawsze) lub area gdy potrafimy określić ich rozmiar. W każdym bądź razie możemy to dopracowywać.
Cóz, dla 2D na tym poziomie zoomu który jest obecnie specyfikacja dziala. Damy zoom level 20 i wyjdzie ze to nieelegancko wyglada. Bez zadnej zlosliwosci bo wiem, ze chlopak sie staral, znam go: to jest przemyslane przez geografa znajacego troche informatyke jak rysowac budynki. Koncepcja musi sprawdzac sie uniwersalnie a nie tylko w przypadku architektury modernistycznej o w miare cienkich scianach wewnetrznach. No ale jak na dzis to faktycznie myslenie na przyszlosc. Zeby nie wygladalo to na madrzenie sie powinienem jednak przedstawic uzupelniona koncepcje. W tej chwili rozmawialibysmy tylko na temat czegos, czego jeszcze nie ma.
Czyli wszystko wychodzi na to, że nie ma gotowego i prawidłowego standardu jak tworzyć mapy wewnętrzne. Ktoś wpadł na pomysł, żeby stworzyć taki schemat, ale tak naprawdę to każdy rysuje jak chce - niektórzy nie rozdzielają ścian w pomieszczeniach i nie muszą martwić się problemem z drzwiami. Kolejnym aspektem są schody. Inni rozdzielają odpowiednie pomieszczenia tak, że ściany się nie nakładają. Chciałem jakoś poprawnie otagować schody, ale tak naprawdę to nie wiem jak. Wiki pisze, że http://wiki.openstreetmap.org/wiki/IndoorOSM#Modeling_connections_between_different_levels co w przypadku mojego budynku o niestandardowych schodach nie przejdzie. Z drugiej strony jest pomysł http://wiki.openstreetmap.org/wiki/Proposed_features/indoor#Revision_1, który osobiście bardzo przypadł mi do gustu. Dopóki nie będzie określonego sposobu tworzenia podstawowych rzeczy, takich jak drzwi, schody, a niewartościowe (według mnie) informacje takie jak rodzaj dachu czy rozmieszczenie okien to ludzie nie będą chcieli się tym zająć.
Widzę to w ten sposób:
- Zwykła nawigacja powinna sobie chociaż w minimalny sposób radzić z indoor. Dlatego powinniśmy prowadzić wewnątrz budynków drogi. Jaki typ? To warto ustalić. http://wiki.openstreetmap.org/wiki/File:Indoor_room.png
- Jeśli mamy już sieć routingu to mamy 2 możliwości postawienia drzwi:
a) Pomiędzy pomieszczeniami jako node (lub na lini jeśli pomieszczenia są połączone w OSM)
b) Jako wektor pomiędzy pomieszczeniami.
Punkt, a wygląda rozsądniej ponieważ routing nie musi sprawdzać czy drzwi są szerokie, a do wizualizacji wnętrza i tak to nic nie wnosi. Więc w przypadku kompletnych danych widzę to jako area w obszarze pomiędzy pomieszczeniami + węzeł na środku tego obszaru z tagiem room=entrance, który należeć będzie do drogi routingowej. - Schody tak samo:
Jako obrys powinno być http://wiki.openstreetmap.org/wiki/IndoorOSM#Modeling_connections_between_different_levels, a do routingu stosować możemy http://wiki.openstreetmap.org/wiki/Proposed_features/indoor#Revision_1 jako np. highway=steps z odpowiednimi tagami.
Myślę, że od samego początku powinniśmy oddzielić warstwę routingu od warstwy renderowanej.
A są już jakieś nawigacje dla pieszych? Bo taka nawigacja samochodowa nie doprowadzi nas do celu ponieważ bierze ona pod uwagę drogi. My musielibyśmy wymyślić coś w rodzaju highway:indoor_footway, które to drogi tworzyły by siatkę połączeń pomiędzy piętrami, dochodziły do drzwi danego pokoju i do chodnika przy ulicy, po to aby możliwe było poruszanie się nie tylko po budynku ale po całym mieście.
OsmAnd ma możliwość nawigowania pieszych. Nie bierze pod uwagę level więc pewnie wyznaczyłby drogę po highway=footway bie biorąc pod uwagę piętra. Ale podesłanie łatki jest prostrze niż napisanie całego programu od nowa 
No ale żeby takie coś przepchnąć musimy mieć przynajmniej w samej Polsce ze 40 budynków zmapowanych.
W takim razie musimy zdecydować jaką wartość nadać dla takiej drogi. Może już ktoś wprowadził jaką propozycję dotyczącą tego.
na pewno musi mieć tag określający poziom (level), aby aplikacje mogły skojarzyć wyrysowane pomieszczenie z końcem trasy. Myślę, że highway może być jakiś standardowy (footway/steps).
Nie wystarczyłoby, że te drogi należałyby do relacji danego piętra, a schody do 2 relacji? Jeśli ustawimy highway:footway to na OSM będzie to wyglądało okropnie - dziesiątki przecinających się lini.
Udało mi się znaleść tag:
via http://wiki.openstreetmap.org/wiki/Indoor
Nikt nie rozwijał tego tematu. Nie było żadnego głosowania.
Może zrobimy tutorial po polsku na wiki jak to widzimy? Tak aby zebrać wszystkie potrzebne tagi w jednym miejscu. Myślę, że Pl:Indoor będzie do tego odpowiednim miejscem.
Edit: Ok… Zauważyłem że już jest http://wiki.openstreetmap.org/wiki/Pl:IndoorOSM
Wrzucam już bardziej oficjalnie własną stronę do przeglądania indoor mappingu:
http://osmtools.org/indoor/#lat=51.09447&lon=17.01945&z=18 (tutaj przykład Sky Tower)
Strona operuje na danych z overpass api, czyli to co wyrysowane pojawia się na niej po niedługim czasie. Strona oczywiście w rozwoju, uwagi mile widziane.
Moja pierwsza sugestia. Proponuję, aby na sklepach renderowały się loga sklepów (jeśli nie ma to tekst) można zrobić specjalną bazę z ikonkami. “House” w każdej galerii będzie miał nazwę House. Więc mogłyby to być pliki w stylu “logo/House.png”
Druga. Pokazywanie sklepów wg typów (podział: piętra lub typy)
Trzecia. Wyszukiwarka.
Czwarta. Masz to na jakimś github?
Jaką rolę w relacji powinno mieć patio? Jest to otwarta przestrzeń poza budynkiem, choć jednocześnie w jego środku, ale pod gołym niebem, więc buildingpart=hall nie pasuje Mam na myśli ten przypadek.
No to ja się przyłączę do rozważań na temat tagów. Jak tagować parking? A szczególnie taki na którym można wprowadzać pojedyncze miejsca parkingowe.
Co do patio to myślę, że buildingpart=patio się nadaje lub możemy coś w stylu buildingpart=outdoor z outdoor=patio/balcony. Co o tym myślicie?
Dla mnie patio nie należy do budynku, a co za tym idzie nie powinno być tagowane jako buildingpart. Tutaj znowu powstaje problem tak jak z niestandardowymi pomieszczeniami, np. korytarzami. Bardziej byłbym za rozwiązaniem dodania takiego obiektu to relacji jako shell_inner.
patio może być też częścią restauracji, Dotevo -a co z parkingiem? Możesz szerzej problem naświetlić?
Załóżmy, że mamy 2 poziomowy parking. Chciałbym zmapować cały wraz z miejscami. To będzie buildingpart=room amenity=parking z miejscami parkingowymi w relacji? Jeśli tak to jak rozwiązać problem 2 pięter, które powinny być raczej widoczne jako jeden parking.
A tak, rozumiem. W tym CH Klif który robiłem, jedną z kilku rzeczy, które zostawiłem to właśnie parking
Nie znalazłem nigdzie żadnego sensownego rozwiązania, patrzyłem u Niemców i u Anglików jak to wygląda.
buildingpart=room to średnio wygląda… Trochę za duża przestrzeń.
Może jako: type=building, building:use=
czyli normalnie i dodać to do głównej relacji centrum.
Do tego jeszcze dochodzi cała infrastruktura:
- automaty za bilety parkingowe
- kamery
- wjazd/wyjazd, wyjście do galerii
- plan (?)
- infobox (ile miejsc wolnych, ile zajętych)
- drogi (no to wiadomo, ale jak tagi dodatkowe, przecież droga na poziomie załóżmy II nie będzie ‘tunnel=yes’ bo to komedia… itp)
- z poszczególnymi miejscami, to ja bym się skupił głównie na polach dla rodzin i inwalidów
tweant, shell_inner pasowałby raczej do tego nieszczęsnego patio (albo dodać je do relacji shell jako inner), a do korytarzy wystarczy corridor.