Ja u?ywam w?a?nie mapnika dla celów mapy WWW dla UMP i mog? powiedzie?, ?e przygotowanie pliku OSM to dopiero pocz?tek . Du?o wi?cej pracy by?o ze stylami, mimo ?e korzysta?em z istniej?cych (prawie 500KB w >20 plikach xml). No i jeszcze by?o sporo patchowania mapnika, ale najnowsza wersja 0.6.0 zawiera ju? poprawki, które przygotowa?em.
Pod tym “nieoficjalnym” linkiem (120MB): http://marcom.homeip.net/ump-www/ump.osm.gz
jest podlinkowana wersja pliku, która idzie do bazy postgres+postgis, jednak moje ??cze ma ma?y upload na zewn?trz(0.5MBit), wi?c nie zalecam cz?stego ?ci?gania, bo jak zauwa?? zbyt cz?ste/du?e obci??enie, to usun? symlinka
Je?li potrzeba jednorazowo i nie przeszkadza u?ywany przeze mnie styl, to mog? wygenerowa? jaki? fragment w wybranym bbox i formacie(jpg, png, svg), chyba ?e to jaki? wi?kszy projekt z tym mapnikiem.
Moje trzy grosze - rzeczywi?cie txt2osm.py z?era zasoby jak szalony - zarówno pami??, jak i procesor.
Da si? go zmieni? na co?, co dzia?a z podobn? pr?dko?ci?, jak program mar_rud, ale to wymaga sporych zmian w kodzie - w?z?y s? zapisane w ma?o wydajny sposób. Przy okazji zyska?oby si? troch? wi?cej mo?liwo?ci dopasowywania wyniku do potrzeb, np. wcze?niej wspomniane obcinanie.
Co do zuzycia pami?ci, to te? da si? to ?atwo zrobi?, bez ?adnej straty wydajno?ci, a mo?e nawet z zyskiem, ale to te? wi??e si? pewnie z przepisaniem du?ego kawa?ka. Jedyna niedogodno??, która z tego wyniknie, to przemieszanie w?z?ów, dróg i relacji.
Sam si? za to nie zabior?, ale je?li b?dzie wi?cej ch?tnych, to pomog?.
My?l?, ?e dobrze by?oby przyjrze? temu drugiemu programowi i zobaczy?, co mo?na z niego wzi??.
Dzieki mar_rud
No ja juz mapnika i postgres hula. Stylami rowniez sie pobawilem , cala makpa swiato - planet.osm zajmuje w bazie ponad 40gb.
Chcialem wyciac mape polski (osm) i podmienic w jej miejsce UMP.
A zamianst tile_mod uzywam tile_cache bo jest bardziej uniwersalny i dziala na wielu platformach… a tile_moda nie mozna dodac jako modułu apacha pod winem
Co do predkosci to bylbym sceptyczny (o ile mowa o pythonie). Najwiekszy kawal czasu zajmuje dodawanie kolejnych punktow ze sprawdzaniem czy juz sa – i nie ma na to sposobu szybszego niz nlog(n) bez robienia dodatkowych zalozen. txt2osm.py podobnie potrzbuje u mnie kolo 30min na przekonwertowanie danych z UMP bez kompresji etc.
Natomiast szkoda byloby czasu na dopracowywanie skryptu ktory tak naprawde jest jednorazowego uzytku, bo tez import jest jednorazowa czynnoscia, (ktorej 90% to i tak manualna edycja). Wszyscy maja ograniczone zasoby czasowe i trzeba pomyslec czy zautomatyzowanie konkretnej czynnosci rzeczywiscie zaoszczedzi te zasoby.
Zgoda, ale da si? zrobi? ca?e zadanie w O(n), je?li nieco zmienimy podej?cie do tematu. Te? bez dodatkowych za?o?e?. Dojdzie brzydki fragment zale?ny od ilo?ci dróg, ale i tak b?dzie na plus.
Tu sprawa jest ciekawsza. Mo?emy mówi?, ?e zaimportujemy raz i na tym koniec, ale tak naprawd? UMP ci?gle si? zmienia. Chyba, ?e w pewnym momencie zaimportujemy “wszystko” i odetniemy si? od kolejnych zmian.
Poza tym lekka przebudowa mo?e umo?liwi? ?atwiejsze podej?cie do kolejnego problemu, czyli ci?g?ej synchronizacji mi?dzy projektami - je?li oczywi?cie mamy takie ambicje
W ka?dym razie na takim etapie, jaki jest teraz, to b?dzie rzeczywi?cie do?? niepewne inwestowanie czasu.
To jest zlozonosc czasowa czy obliczeniowa …?
Bo jak wiemy, nie mozna tak podchodzic do problemu zakladajacze to O(n), ale to O(n) moze byc przemnozone przez stala . A w tym przypadku stała jest mowimy o zlozonosci pamieciowej!!! .Dla jezyka wysokiego poziomu moze byc duza… . Python nie jest chyba zbyt oszczedny jesli chodzi o operacje na danych:P To taka mala notka ktora i tak nic nie wnosi do tematu:) Bo jest to problem NP-zupelny:P:P
Mo?e ustalcie o czym mowa? Jaki problem jest tu NP-zupe?ny?
Je?li chodzi o operacj? przypisywania osm_id punktom (jest ich ok 10mln), czyli wyszukiwanie czy punkt o danych wspó?rz?dnych ju? ma przypisany osm_id, to jest to O(n ln n), bo dla ka?dego punktu trzeba wykona? przeszukanie w zbiorze ju? przypisanych. Nie widz? bardziej z?o?onych problemów ni? to dopasowanie (ew. wykorzystane na ró?ne sposoby).
Kod który poda?em u?ywa mapy stl’owej, gdzie wspó?rz?dne zosta?y zapisane sta?oprzecinkowo (zaokr?glenie do 6 miejsc po przecinku). Poza tym do wszystkich sta?ych tekstowych (nazwy tagów i rozpoznawalnych parametrów w pliku MP) s? mapowania, które zamieniaj? je na id w s?ownikach, przez co nie ma marnotrawienia pami?ci na przechowywanie ca?y czas tych samych stringów. Pewnie mo?na by operowa? na wska?nikach char * itp, (w Javie mo?na na referencjach), ale nie widzia?em potrzeby, jak istniej?ce rozwi?zanie si? sprawdza.
Poza tym program stara si? usuwa? z pami?ci dane, które nie b?d? ju? potrzebne po zapisaniu do xml’a:
punkty POI s? zapisywane jako pierwsze i w pami?ci zostaje tylko odwzorowanie wspó?rz?dnych (2 x integer) na osm_id.
obiekty s? wst?pnie parsowane (zapisanie tre?ci bloku w pliku MP) i pe?na obs?uga dopiero na koniec (wyliczenie pami?cioch?onnych parametrów), a po zapisaniu do xml’a, usuniecie z pami?ci
(opcjonalnie) wst?pnie wczytane obiekty s? serializowane do pliku, by przetwarza? po zapisaniu POI wczytuj?c ju? ze wst?pnie obrobionego formatu, bez potrzeby trzymania tego w pami?ci: deserializacja obiektu, przetworzenie, zapisanie do xml, delete. Bez tego potrzeba 300MB pami?ci wi?cej.
zapisuj?c w?z?y podobnie jak POI, w pami?ci na sta?e zostaje jedynie mapowanie wspó?rz?dnych na osm_id (2 x int → long)
Kod jest w C++. ??cznie sam proces konwersji mp->osm to jakie? kilka minut dla ca?ego UMP i jak pisa?em ~700MB RAM, wi?c nie mam ju? potrzeby wi?cej optymalizowa?.
Pewnie cz??? z “trików” da si? przenie?? do skryptu python, ale mam wi?ksze do?wiadczenie w C++, Java ni? j?zykach skryptowych, wi?c nie podam szczegó?ów co i jak poprawia?.
Rzeczywi?cie, to O(n log n). Zapomnia?em o tym, ?e w UMP punkty si? powtarzaj?.
Mysl?, ?e nie ma sensu tego teraz roztrz?sa?. Przepisywanie jednego programu czy dopasowywanie drugiego przez pojedy?cze osoby nie ma sensu. Gdy znajdzie si? wi?cej ludzi ch?tnych do pisania, mo?e b?dzie zgoda co do tego, w jakim kierunku nale?y i??.
No wybor pythona napewno nie byl optymalnym jesli chodzi o czas dzialania programu, ale prawdopodobnie byl optymalny jesli chodzi o czas pisania programu (i to mowie ja ktory nie przepadam za jezykami skryptowymi a pythona nadal nie znam)
Zlozonoscia pamieciowa w ogole sie nie przejalem i nadal mysle ze dobrze zrobilem (np. zauwazysz ze kazdy punkt jest trzymany w dwoch slownikach zamiast w jednym – w ten sposob zduplikowalem ilosc zuzytej pamieci jednym machnieciem reki ale przyspieszylem konwersje prawie kwadratowo (dla 1 mln punktow, 1mln razy szybciej)), skoro caly podkatalog z UMP daje sie przekonwertowac w 1GB, i tak to za duzo do edycji.
Dodatkow? motywacj? by? fakt, ?e w przypadku poprzedniego txt2osm, pisanego w C (bodaj?e) “zgubi? si?” kod ?ród?owy… IMO szybko?? dzia?ania nie jest a? taka wa?na; import robi si? w ko?cu tylko raz… Mo?na po?wi?ci? na to troch? zasobów.
Anyway, s?dz?, ?e to by? dobry wybór, bior?c pod uwag?, co z tego uros?o:)
Smieszna sprawa, o podobnej porze zrobi?em to samo Ca?kiem spory kawa?ek osiedla. Zastanawia?em si?, z jakiego ?ród?a brane s? te przepowiednie z przysz?o?ci - wygl?da na to, ?e kto? zosta? oszukany przez tablic? informacyjn?.
Oszukany, nie oszukany. Z tego co widz? usun??e? ulic? Prusa i jeszcze inny kawa?eczek drogi. Na oficjalnej mapie miasta te ulice widniej?, na rozporz?dzeniach rady miasta s? wymieniane (chocia?by to http://bip.um.sokolka.wrotapodlasia.pl/przet_zam/47cac52c6f2e811/3bc208bfc6197bc/gr_72241_40_07_08_w.htm), na mapach katastralnych dost?pnych na geoportalu te dzia?ki istniej?. Tak wi?c jedynym b??dem UMP by?o to ?e te drogi by?y narysowane typem rutowalnym, co by?o b??dem bo one w rzeczywisto?ci jeszcze nie istniej?. Teraz poprawi?em na drogi planowane. Jak wida? wi?c, rzeczywisto?? nie jest do ko?ca tak jednoznaczna.
Wychodzi?em z za?o?enia, ?e istotne s? jedynie drogi, które istniej?.. Rzadko, ale zdarza si?, ?e id? troch? nie t? tras?, gdzie powinny.
Tu znowu wchodzi problem ró?nic mi?dzy tym, co jest formalnie, a tym, co jest w praktyce.
Domy?la?em si?, ?e te drogi maj? powsta?, ale nie przysz?o mi na my?l, ?eby je wpisywa?, dopóki ich nie ma.
D?ugi ten w?tek, ca?ego nie przeczyta?em, tylko ko?cówk? ?ledz?… ale si? dopisz?.
Dzisiaj zauwa?y?em, ?e kto? zaimportowa? z UMP dane w okolicach ?wierkla?ca, gdzie niedawno rozrysowa?em kawa?ek parku, po wycieczce z rodzink?. I co z tego importu wynik?o? Masa dróg do niczego nie pod??czonych, fragment dubluj?cy ?adnie opisany kawa?ek ?cie?ki rowerowej. I chocia?by takie “cudo”: http://www.openstreetmap.org/?lat=50.43586&lon=18.94651&zoom=17&layers=B000FTF (zapewniam was, ?e to skrzy?owanie tak nie wygl?da, ale ju? sam nie wiem jak to prawid?owo po??czy?). W wielu przypadkach ju? nawet JOSM krzyczy, ?e jest ?le (skrzy?owane drogi, w?z?y podejrzanie blisko siebie itp.).
Wcze?niej, zaraz po wspomnianej wycieczce, przegl?da?em DK78 i tam te? by?y “dziury” dwa fragmenty krzy?uj?ce si? na ko?cach, zamiast ??czy?.
Czy kto? to w ogóle przegl?da? Jaki sens ma taki import, bez zachowania jakiejkolwiek spójno?ci w danych OSM? Co jak kto? b?dzie chcia? wykorzysta? mapy OSM do wyznaczenia jakiej? trasy, jak nawet w drogach krajowych, które na mapie mog? wygl?da? ok, s? dziury?
Niejaki Vasc. Poza tym UMP_Level i debug są nieusunięte.
Ja wczoraj robiłem relację DK25 przez Konin, a dziś już musiałem poprawiać, bo ktoś zaimportował nowe drogi nawet nie usuwając starych i się zrobiły czterojezdniowe.
No ale co Pan zrobisz? Nic Pan nie zrobisz…
. Du?o wi?cej pracy by?o ze stylami, mimo ?e korzysta?em z istniej?cych (prawie 500KB w >20 plikach xml). No i jeszcze by?o sporo patchowania mapnika, ale najnowsza wersja 0.6.0 zawiera ju? poprawki, które przygotowa?em.
