Specyfikacja Full 3D Building

Zacząłem pisać stronkę http://wiki.openstreetmap.org/wiki/F3DB

To początek i jest tam wiele do zrobienia, jednak pytanko do Was:
Czy sposób w jaki to ostaram się opisać jest zrozumiały?

Czego brak, co budzi wątpliwości?

ogólnie jest bardzo dobrze. Mam tylko wątpliwości co do opisu drzwi. Bo z obecnego wychodzi coś dokładnie odwrotnego do standardowego opisu drzwi tj. coś co jest opisane jako opening.direction=right to sa drzwi lewe :). To oczywiście ma sens w momencie uwzględnienia kierunku ściany ale może powodować nieporozumienia. Nie mam na razie dobrego pomysłu na opis.

Też mam z tym zgryz i to od paru miesięcy.
Dodaem inną propozycję. Jeśli wyda się sensowniejsza, wywalę tą starą.
Dodałem też działy:

Dachy i
Zones

Myślę, że to jest bardzo zdrowe podejście do tego problemu: http://www.youtube.com/watch?v=_Rf9yfrO0ZQ

A bardziej serio - nie widzę w tym proposalu na razie możliwości tagowania indoor dla budynków wielopiętrowych, jeśli na poszczególnych piętrach nie jest identycznie to samo (a jeśli chcemy to tagować, to jednak zwykle nie będzie). Nawet jeśli ściany wewnętrzne byłyby rozmieszczone identycznie (co nie zawsze jest regułą), to jednak funkcje (nazwy) pomieszczeń na poszczególnych piętrach będą różne (np. w centrum handlowym będą różne sklepy, w urzędzie różne wydziały w poszczególnych pomieszczeniach, na uczelni różne numery sal itd. itp.).

Prosi sie o uzycie tagu level http://wiki.openstreetmap.org/wiki/Level

Masz rację, pisałem o tym jedynie na forum niemieckim nie umieszczając na Wiki. Poprawione.
filmik o drzwiach jest niezły :stuck_out_tongue:

Tag level jest używany dla określenia logicznego położenia elementów nad sobą, np. przejazdu kolejowego nad rzeką. Dlatego propozycja building:level (być może lepiej indoor:level?) Propozycja ze szkicu dopuszcza także tagownaie półpięter jako np. building:level=1.5

Dorzuciłem alternatywny sposób opisu drzwi pod głosowanie.
Pojawiła się propozycja tagowania obszarów nie ograniczonych ścianami, np. poczekalni w dużym hallu.
Opisałem tagging dachów, dodałemlink do tagowania okien (podstrona).

No i mam prośbę: jeśłi zuważycie jakieś rażące błędy językowe w obecnej, angielskiej wersji proposalu, dajcie mi znać.

Przy tej okazji ogromne podziękowania dla Kocia za świetnie zrobiony Dworzec Centralny w Warszawie.
Przoduje w Indoor na razie …Poznań. W Krakowie nie ma nic. Może ktoś spróbuje zrobić choćby jeden budynek z indoor?

Indoor zrobił tam głównie Javnik, o ile pamiętam. Ja tam też dłubałem, ale inne rzeczy, a indoor tylko szlifowałem w paru miejscach.

Ok. Skoro myslimy o tym aby specyfikacja była pełna to wrzucam kilka pomyslow:
-jak oznaczy np. kase w sklepie? Dla mnie to POI, ktore oznaczy sie punktem, ale powinno sie znalezc w samej relacji sklepu lub z odpowiednimi tagami.
-toalete dla klientow sklepu. To chyba tez w relacji sklepu
-Jak np. wrzucilbys sklep odziezowy do galerii handlowej i zaznaczylbys strefy odziez dziecieca, damska itp
-Strefy powinny byc multilang czyli warto wpsomniec o indoor:zone:LANG=
-osobiscie nie podoba mi sie indoor:zone poniewaz przyzwyczailem sie, ze tego typu tagi to raczej name. Proponuje wiec name:pl=Strefa dla palacych barrier=no indoor:wall=no

Ogolnie przeraza mnie ta liczba przedrostkow “indoor:” ktore sa czesto niepotrzebne.

Generalnie to dobluje tagi wiec jest klopotliwe.
Chodzi glównie o to, by usunac z glownej strony osm dziesiatki footway znajdujacych sie w budynku. Przedrostek indoor pozwala bez zmiany regul wielu istniejacych renderingów rysowac drogi wenatrz budynku. Co do innych elementów to byc moze da sie je filtrowac poprzez sprawdzynie czy leza wewnatrz budynku.

Wrzuc do proposalu Twoje pomysly, w koncu po to ta strona jest.
Wklepuje tam na koncu dzial: suggestions

I utrudni życie innym konsumentom danych.

Niby czemu? Jakim, i w jaki sposób?

Na przykład edytory bez odpowiednich zmian nie będą traktowały indoor:footway tak jak footway, indoor:steps jak steps itd.

Równolegle do specyfikacji w Berlinie rozwijany jest plugIn pod JOSM i po fazie testowej ma to wejść do kernela.

W iD najprawdopodobniej też to trafi po jakims czasie. Potlatch się do tego nie nadaje a o Merkaatorze przyznam bez bicia nawet nie myślałem.
I tak nie da się niestety inaczej przeciąć tego węzła gordyjskiego. Decyzja była po długich rozmowach z wieloma ludźmi.

O wiele łatwiej poprawić wymienione przez Ciebie mechanizmy w kluczowych edytorach niż w dziesiątkach apek czy stron które zaczęły by robić zły routing lub rendering.

To zawsze będzie problem typu: lepszy użytkownik dodający marnie dane (dane z dziwnymi tagami, ale z jakimiś konkretnymi informacjami terenowymi) niż ten, który chce coś naprawić/ulepszyć i będzie usuwał dane “według niego” nic nie znaczące.
Na to się nic nie poradzi.

Z ciekawostek, dzisiaj widziałem “smoking=outside” :slight_smile: w obrysie budynku.
Trochę mnie to zdziwiło, bo sądziłem że wystarczy proste no, ale spojrzenie na taginfo pozwala mi zrozumieć istotę tego problemu (ja akurat nie palę):
http://taginfo.openstreetmap.pl/keys/smoking#values

Pracowaliśmy dziś ostro z Thomasem Greichenem nad szlifowaniem specyfikacji F3DB. Za kilka dni pojawią się uzupełnienia.
Jako temat uboczny wyskoczyła sprawa mostów i pierwszy szkic:
https://wiki.openstreetmap.org/wiki/Bridge3D

Wrzuciłem na wiki rezultaty spotkania kodyfikacyjnego w Erlangen:

http://wiki.openstreetmap.org/wiki/F3DB_Workshop_Erlangen#Minutes