Vzhledem k tomu, ze lesu mame malo, tak to tam nahrnu cele a kdyz nekdo objevi kolizi, tak ji proste odstrani... Myslim, ze to neni nic proti nicemu.
K BH napsal(a): > Jo, neni to zcela presny, ale vzhledem k tomu, ze moc lesu v datech > neni, tak by to mohlo fungovat asi prijatelne. I kdyz by asi sly > pouzit lepsi obalova telesa s lepsi presnosti > > Pres ty bounding boxy by se jen rozdelily data na dve casti - tu co by > se tam nacpala automaticky (s nicim nekoliduje, tudiz neni treba zadny > rucni postprocessing) a tu co by se tam nacpala rucne (muze kolidovat > s tema par lesy co tam jsou). Pokud by se pak nekomu chtelo, mohl by > pak tu rucni cast dale automaticky tridit nejakym sofistikovanejsim > algoritmem aby bylo mene rucniho importu, ale v momentu, kdy se tam > naimportuje ten "zbytek" tak uz bychom 90% lesu meli :) > > Martin Petricek > > On 10/9/07, Jakub Sykora <[EMAIL PROTECTED]> wrote: > >> Bounding boxy muzou byt hodne nepresny. Predstav si treba les "na >> diagonale". Pak by se automaticky ignorovalo vse co lezi v danem >> ctverci/obdelniku. Nekdy je lidska prace rychlejsi. >> >> K >> >> BH napsal(a): >> >>> Kdyz jsou dve linie od ruznych lidi nebo generatoru na jednom miste, >>> tak obvykle se od sebe trochu lisi podle sve presnosti. Kdo v tom >>> arealu neco mapuje, tak si toho vetsinou vsimne. :) ale hledat to >>> nejak automaticky by bylo asi doost tezky. >>> >>> Jinak by to slo odfiltrovat trochu jednoduseji, nejdriv by se vyrizla >>> z planet.osm CR (na to by snad mohly byt nekde tooly ktery z toho >>> udelaji vyrez) a pak by se z kazdyho lesu co tam uz je udelal bounding >>> box (coz by melo byt pomerne jednoduchy, to by se dalo udelat malym >>> skriptikem :). Pak by se kazdy bod uz jen testoval jestli nelezi v >>> nekterym bouding boxu (zas tolik lesu tam myslim neni, takze i >>> porovnavani hrubou silou by melo byt snad prijatelne rychly :). Neni >>> to nejpresnejsi, ale je to vcelku rychly. Co neprojde, to se pak >>> odlozi stranou k rucnimu importu nebo dokud nekdo neprijde s lepsim >>> resenim konfliktu. Tipuju ze tak 80-90 procent lesu by tim mohlo >>> rovnou projit ... >>> >>> Martin Petricek >>> >>> >>> >>>> Jak se hleda takovy konfilktni les? To je jeste hnusnejsi a je mi predem >>>> jasne, ze by to nadelalo vic paseky nez uzitku (lehce se prekryvajici >>>> data). >>>> >>>> K >>>> >>>> BH wrote: >>>> >>>> >>>>>> Pro uhul-lesy bych se primlouval za import, i kdyz uz v dany oblasti >>>>>> lesy jsou. Je pravdepodobny ze data z uhulu budou lepsi. >>>>>> >>>>>> >>>>> Jo, to asi budou co jsem tak videl nekde ukazku, ale pak to zas bude >>>>> chtit ty stary data odstranit ... mozna to tam naimportovat a pak >>>>> nejak vypsat seznam konfliktnich lesu, ktery by pak nekdo prosel ;) >>>>> >>>>> Martin >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz@openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>> -- >>>> Jakub Sýkora >>>> email: [EMAIL PROTECTED] <') >>>> ICQ: 68976632 ( =- >>>> mobil: +420 777 594 201 '' >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz@openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz@openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
