[Talk-cz] odbo?ovac? pruhy

hanoj ehanoj na gmail.com
Pátek Srpen 14 08:05:36 UTC 2009


> mezi dvema databazemi se neudrzi sync.
*** to je vec tech. reseni

>> - problem se smerem - co je smerem tam a co smerem zpet a zachovani
>> konzistence - u way se jeste castecne da, ale u bodu?
>
> u way se smer da urcit plne (ne jen castecne), bod smer nema a neni
> potreba, aby nejaky mel, protoze se jezdi po cestach a ne po bodech.
*** problem je s konzistenci smeru pri editaci geometrie. Ta totiz
neni staticka a uzivatel do ni volne zasahuje aniz by ho to tlouklo do
oci, ze je nekde nejaka vazba. Uz mesto s jednosmerkami,
relation:route a maxspeed dava trochu hokej do editace.

>> -nutnost rozsekavat way pri zmene razeni pruhu
>
> myslite nutnost rozdelit way, kdyz se ze dvou pruhu stanou treba tri? To
> mi prijde jako mala cena za mozne vyhody.
*** dnesni renderery kresli na mape kazdou way samostatne (bez ohledu
na pouziti opakovanych nazvu ulice). Tudiz by se jednou museli
predelat tak, aby si umeli vlastnosti seskupovat do vetsich celku. To
uz muze byt zajimavejsi zavest nejake relativni negeometricke nody.


>> Napadlo me resit to nejakym zpusobem from-to, kde from by bylo cislo
>> nodu z a to by bylo cislo nodu do
>
> autor Navitu navrhuje from_lane -> to_lane relaci, ktera se opira o
> cesty, ne o body. Myslim, ze by to mohlo fungovat, akorat se ho chci
> jeste zeptat, jestli je opravdu nezbytne mit to_lane, jestli nestaci
> to_way.
*** kde je ten navrh popsany?
from_lane -> to_way se pouziva v softwarech pro kapacitni vypocty krizovatek.
from_lane -> to_lane je asi pro navigaci vyhodnejsi, vi kterym pruhem
ma auto protlacovat na dalsi kriz.

hanoj




Další informace o konferenci talk-cz