> 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 _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz