Szczególowe mapowanie elementy 3D wokól drogi

Mapujemy coraz wiecej elementów 3D.
Bylo by fajnie miec eementy tego typu:
http://3.bp.blogspot.com/-EPkc0xYD6b4/T60rqJdmDmI/AAAAAAAAFQ4/ClPYGbcHBrw/s1600/DSC02216.JPG

Mysle ze ze zdjec mozemy rysowac polozenie jako linie. Punkt poczatkowy i koncowy mialby tagi opisujace np. rodzaj slupa
Jkao punkty na linii mozna by umiesczac tablice z ich wysokoscia, szerokoscia i tekstem podajacym, co tam widac.

Macie jakis pomysl, jaki schemat taggingu do tego wymyslic?

Pozdrowienia,
Marek

Rozumiem, że to miałoby zastosowanie w programach do nawigacji. Jeśli tak to zawartość tablicy nie tylko na ozdobę ale jako dodatkowa pomoc (jazda we mgle ?). Podanie gołego tekstu dość słabo wyjdzie. Tagowanie samej tablicy musi wyprodukować obraz zbliżony do oryginału. Powinno być niezalezne od miejsca/kraju. Myślę, że kodowanie zawartosci nalezy upchać jako wartość jednego tagu ( rodzaj tablicy ,teksty, kierunki, numery dróg ). Na dzień dobry faktycznie można sam tekst tam trzymać a z czasem dopracować się specyfikacji zawartości

To ma isc dwutorowo:
Jedna rzecz to fajniejsze 3D, druga to podawanie informacji dla systemów nawigacji.

Tylko najlepiej by było, aby specyfikacja tego elementu była ustalona na starcie, aby było jak najmniej wątpliwości jak mapować takie elementy. Podobnie zresztą można dodać np. viatole, które są rozłożone na tego typu drogach. Tzn. warto specyfikację tak napisać, aby była możliwie elastyczna w przypadku podobnych elementów, będących elementami wyposażenia dróg.

Jeśli chodzi o treści drogowskazów to jest schemat, który może się przydać (a może nie :slight_smile: ) http://wiki.openstreetmap.org/wiki/Relation:destination_sign

Dzieki Royas,
Fajny schemat, trzeba rozbudowac tylko :wink:

Może coś w ten deseń, tak na szybko:
linia przecinająca drogę z dodatkowym punktem na przecięciu.
Całość jako highway=gantry, type=destination / toll / information, material= , height= itp.

A punkt na przecięciu analogicznie jak lanes drogi (bo powinny też tam na tej drodze już być) np:
highway:gantry=yes
city_destination:lanes:forward=Katowice;Wrocław|Kraków
ref_destination:lanes:forward=8|7

O, coś znalazłem:
http://wiki.openstreetmap.org/wiki/Key:destination

No to z tej koncepcji wynika, że drogowskazy (jako relacje wg już istnejących propozycji) mogłby po prostu zawierać nody mapujące tablice jako dodatkowych członków relacji (ew. odwrotnie bo przy kilku pasach będzie kilka tablic a jedna relacja drogowskazu W ten sposób wizualizacja 3D będzie mogła zbudować treść tablicy

W relacji drogowskazu już jest opisana rola “sign”, czyli znak. Tak że wszystko się zgadza. Ale w przypadku wielopasmowej drogi tablica drogowskazu powinna być pojedynczym węzłem, który w kilku relacjach drogowskazów pełni role “sign”.

http://wiki.openstreetmap.org/wiki/Relation:destination_sign

Punkt opisujacy tablice powinien miec tez swój height=value i width=value
A jak rozwiazac fakt z której strony znak widac?
Sa takie konstrukcje nad drogami dwukierunkowymi gdzie z jednej strony cos jest napisane i z drugiej tez.

Sa tez znaki o konstrukcji nosnej w ksztalcie odwróconej o 180 stopni litery L gdzie na wysiegniku jest prostokatna tablica…

Może jakąś wartość w stylu azymutu (kąta liczonego od kierunku północy), w odniesieniu do wybranej strony uznanej jako front (przód) znaku. Dla bardziej fikuśnych znaków mógłby być także kąt pionowy, choć na szczęście mały jest obiektów tak powyginanych.

Wtedy np mamy front:colour:back i kolor tła znaku ze strony frontowej (głównej), natomiast back:colour:back określałby kolor strony tylnej. W geodezji są symbole, które posiadają atrybuty kąta, który określa kierunek obrotu takiego obiektu. Ale myślę, że akurat azymut bardziej pasuje, bo jest to wartość bezwzględna. Ewentualnie możnaby dać pole kąt (względne, bo kąty zwykle liczone są od jednego kierunku do drugiego), ale w powiązaniu z drogą (np. relacją), aby można było azymut drogi określić i na podstawie tego wyznaczyć azymut znaku do rysowania (jeśli mielibyśmy tylko kąt pomiędzy drogą a kierunkiem frontu znaku).

W zasadzie to możnaby potraktować tak, iż domyślnie opisuje się stronę frontową, natomiast jeśli byłaby taka potrzeba do opisania strony tylnej, wówczas możnaby dać prefix back:

np.
kolor tła przedniej części znaku: colour:back
kolor tła tylnej części znaku: back:colour:back
orientacja (azymut) znaku: azimuth= (ew. direction=) ew. angle= ale w powiązaniu z angle:refA, angle:refB=ze wskazaniem kierunku (pary pktów A/B) wyznaczających kierunek od którego liczony jest kąt.

Za znaki drogowe w 3d dość poważnie zabrał się yopaseopor. Więcej szczegółów jest tutaj. Jego biblioteka odnosi się do tej propozycji. Niestety jego modele będą wymagały jeszcze dużo pracy.

Ciekawie rozwiązał problem indywidualnych tekstów na znakach. Po prostu wykonał indywidualne tekstury dla każdego z nich. Oczywiście jest to rozwiązanie mocno tymczasowe, jednak fajnie to wygląda.

Być może warto jakoś synchronizować prace?

W przypadku znaków odpowiednia tekstura jest niezbędnym minimum, aczkolwiek przy opisach tekstowych bywa różnie. Oczywiście najfajniejsze (najbardziej realistyczne) byłyby tekstury napisów odwzorowane z fotografii, ale to niepotrzebne zajmowanie miejsca. Wystarczy odwzorowanie koloru, opis, rozmiar znaku, byleby renderer składał to odpowiednio elegancko. Na dodatek można dodać, że tekstura jest szybszym wyjściem, bo tekst jest zwykle renderowany dłużej (szczególnie z obsługą przezroczystości).

A synchronizacja prac przydałaby się. My np. siedzimy teraz nad stworzeniem bazy opisów tagów/kluczy do naszego edytora, bo w specyfikacji OSM nie ma jednolitego pliku opisującego słowniki kluczy, potencjalne wartości i ich polskie odpowiedniki. Niestety oprócz polskiego opisu na stronie MapFeatures podobne legendy/słowniki danych niestety nie są dostępne. A szkoda, bo takie detale i wzory specyfikacji (słowniki) zdecydowanie ułatwiają sprawę. Co prawda w przypadku np. JOSM - są presety i zwykle załatwiają sprawę (nie trzeba się zastanawiać, jaki tag wpisać), ale konia z rzędem temu, kto zaczynając przygodę z OSM zacznie przeglądać klucze i wartości, które mają skrócone obcojęzyczne nazewnictwo.

Dla 3D warto by było zrobić jakieś presety dla renderera geometrii, aby można było zdefiniować styl generowania np. znaków. Webdeveloperzy mają swojego cssa, a tutaj możnaby wymyślić coś podobnego.