[Talk-cz] Podzimni uklid
Jak jsem tak zkousel pouzivat data pro navigaci, vsiml jsem si, ze spousta informaci neni v "modernim" formatu. Napr. se leckde pouziva restrictions="oneway" (z cehoz si navit pramalo dela), ale naslo vy se toho vic. Existuje nejaky rozumny nastroj, se kterym by se daly delat hromadne upravy tak, aby pak sly nahrat zpet na server? Pokud bych pouzil nejaky filtr proti czechia.osm, pridal do XMLka atribut "modified" a pak to nahral do JOSM a dal upload, asi by to proslo, ale predpokladam, ze neco uz existuje. Jaky uklid by byl potreba? *) restrictions="oneway" -> oneway=true (popr unifikace oneway=yes->true) *) smazat name=_$ref u naimpotrovanych cest z HELP SERVICE s.r.o. *) smazat author/source u nodu z importu - nedava to moc velky smysl a kdyz s budem pohnu, uz to stejne neni pravda. Dalsi napady? BTW: co se tyce me nekdejsi unahlenosti s node(highway=city_limit), tak studium wiki odhalilo, ze spravne je obec zabalit do polygonu(boundary=city). Je rozumne takovyto polygon naklikat dle UHULu s tim, ze by prijezdove komunikace protinal v pozici znacky, tedy implicitni padesatky? V routing howto je explicitne zmineno, ze ten polygon znamena patricne omezeni rychlosti. Pripadne, existuje svobodny zdroj lepsich dat na toto tema? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
[Talk-cz] czechia.osm v JOSM
FYI: Pujde to! JOSM neni prilis staven na rozsahle datasety (cimz czechia.osm bezesporu je), nicmene da se priohnout, aby se v nem dalo pouzitelne pracovat i s mnozstvim dat, ktere czechia.osm v soucasne dobe predstavuje. Pocatecni pozorovani: V normalnim modu neni schopen vykreslit celou CR (jakakoliv operace trva desitky sekund), prace s velkym priblizenim je na hranici pouzitelnosti. V mappaint modu si mnohem lepe poradi s celou CR (uz jen jednotky sekund), bohuzel potrebuje jednotky sekund i pri velkem priblizeni. Prvni upravy (zatim jen normalni mod): Vypnute malovani sipek vyrazne urychli celou CR. Overene patche: *) prepis malovaciho filtru z Point2D a rectangle.intersects(Line2D) na Point a rectangle.intersects(rectangle) vyrazne zrychli praci v priblizeni. *) filtrovani segmentu promitnutych do bodu (rectangle(0,0)) vyrazne zrychli celou CR (jsou videt jen node, ale i tak se clovek dobre orientuje). Sam ted takto upraveny a nastaveny JOSM provozuji a jsem schopen s nim vcelku normalne pracovat (pravda Core2Duo @2.4GHz, ale druhe jadro se flaka). Abych nezapomel, z duvodu spotreby pameti jsem musel zvetsit heap (-Xmx256m) pridat unifikaci (ne internovani, ale jako by to bylo) stringu (260MB->170MB) a nahradit tag HashMapy vlastni implementaci Mapy - pole a linearni prochazeni, coz pri <6 zaznamech neni problem (170MB->106MB) Dalsi moznosti: *) Filtrovat cele way dle bboxu *) Prejit na celociselnou aritmetiku Az to jeste trochu popoladim a doprofiluju, submitnu patche... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
