Plochy vod v OSM

16 zpráv
Zpět na přehled

Plochy vod v OSM

16 zpráv TPJMJBP 7 účastníků 14 min čtení
  1. Tomas Kolda kolda na web2net.cz #m00a72a
    Ahoj, muzete mi nekdo vyjasnit jak presne se rozpoznavaji plochy v OSM? Na strankach jsem se docetl, ze polygon je uzavrena Way, ktera ma definovanou Map feature jako polygon. Kdyz jsem ale koukal na vyrenderovane mapy, tak napr. riverbank Vltavy neni uzavrena cesta. Presto ji OSM generuje spravne jako Areu. Domnivam se tedy, ze riverbank je vzdy area, kde se spoji prvni a posledni bod. Jenze, Berounka mi toto vyvratila. OSM ji generuje spravne, proto to nechapu. Sklada se z riverbank a pak way, ktera by mela urcovat smer toku. Problem je v tom, ze obe jsou oznacene jako riverbank. Jak se tedy rozpozna, ze objekt je area nebo line? Dik moc Tomas
  2. Michal Grézl michal.grezl na gmail.com #m72bce2
    2008/5/16 Tomas Kolda <kolda na web2net.cz>:
    Ahoj, muzete mi nekdo vyjasnit jak presne se rozpoznavaji plochy v OSM? Na strankach jsem se docetl, ze polygon je uzavrena Way, ktera ma definovanou Map feature jako polygon.
    maji area=yes nebo jsou natural=water
    Kdyz jsem ale koukal na vyrenderovane mapy, tak napr. riverbank Vltavy neni uzavrena cesta. Presto ji OSM generuje spravne jako Areu. Domnivam se tedy, ze riverbank je vzdy area, kde se spoji prvni a posledni bod. Jenze, Berounka mi toto vyvratila. OSM ji generuje spravne, proto to nechapu. Sklada se z riverbank a pak way, ktera by mela urcovat smer toku. Problem je v tom, ze obe jsou oznacene jako riverbank. Jak se tedy rozpozna, ze objekt je area nebo line? Dik moc Tomas
    http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers riverbank byl puvodne zamyslen jako 2 neuzavrene cesty kopirujici brehy reky, tohle ovsem uz dlouho nefunguje a riverbank by se mel pouzivat jako uzavrena cesta, reka by se mela delat jako sled prekryvajicich se kousku riverbank, ta cesta uprostred reky oznacujici tok a slouzici pro navigaci ma byt waterway=river. Podle toho jak to popisujes to je cele spatne, a nekdo to musi opravit.
  3. Jiri Klement jiri.klement na gmail.com #m3a1988
    Podporuje mapnik waterway=riverbank? Zda se ze ne, cast Vltavy, ktera nema navic natural=water je vykreslena spatne. Berounka se v mapniku vykresli spravne proto, ze mapnik waterway=riverbank nepodporuje, takze vnitrni way ignoruje. Doporucuji porovnat renderovani s Osmarender.
  4. Tomas Kolda kolda na web2net.cz #mfbac4b
    No renderuje mi to stejne jako osmarender (asi). Nasel jsem toto: http://tah.openstreetmap.org/Browse/?x=4422&y=2778&z=13&layer=tile Kouknete na berounku, ktera je protnuta vodou... Co mam tedy udelat? Mam udelat nejaky workaround at je to podobne jako mapnik nebo to udelat jako standard OSM a opravit Berounku? Delam totiz na mini offline prohlizeci "plug and play" na (Win/Linux/WinCE) s proprietarnim formatem a kvalitou mapniku... Myslim, ze tak za 14 dni by to mohlo byt. V OSM se zatim zacinam orientovat, takze za kazdou radu dekuji. Tomas PS: Primlouvam se za import lesu (generalizovany), mapka bude mnohem hezci. Mam nejake algoritmy na generalizaci der a spojovani polygonu, takze pripadne muzu pomoct...
  5. Jiri Klement jiri.klement na gmail.com #ma2c21f
    Co mam tedy udelat? Mam udelat nejaky workaround at je to podobne jako mapnik nebo to udelat jako standard OSM a opravit Berounku?
    Urcite opravit Berounku.
    Delam totiz na mini offline prohlizeci "plug and play" na (Win/Linux/WinCE) s proprietarnim formatem a kvalitou mapniku... Myslim, ze tak za 14 dni by to mohlo byt.
    Neposles uz co mas, i kdyz to jeste neni hotove? Neco co by melo vystup kvalitni vystup a maly datovy soubor by se urcite hodilo.
  6. Tomas Kolda kolda na web2net.cz #m27613e
    Takze pre alpha je zde: http://www.web2net.cz/osm/dist.zip Zatim to neumi nazvy cehokoliv (v databazi jiz jsou), zoom maximalne 1:100000 (ostatni nejsou vygenerovany) a je tam naprosto zakladni nastaveni barvicek. Nejsou vsechny dle OSM, ale tak jak se to libi mne. Hlavne highways jsou uplne jinak. Pri nejvetsim zoomu (<1:10000) jsou cervene videt features, ktere nemaji nastaveny vzhled (barvy apod.). Je tam videt i ta chyba s Berounkou... Databaze je czechia_080510. Ovladani: Leve click - Zoom + Prave click - Zoom - Leve drzet a hybat -> pohyb Tomas
  7. Petr Nejedly Petr.Nejedly na Sun.COM #m43008c
    Takze pre alpha je zde: http://www.web2net.cz/osm/dist.zip
    nenik na book ~/dist $ wine viewer.exe wine: Unhandled page fault on read access to 0x00000040 at address 0x40acc8 (thr ead 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000040 in 32-bit code (0x0 040acc8). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0040acc8 ESP:006ef860 EBP:006efa58 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00144600 EDX:0011d630 ESI:006efad0 EDI:00010024 Stack dump: 0x006ef860: 006ef8ec 7ee88ff4 006ef8b8 7ef850ab 0x006ef870: 7ed48ee4 ffffffff 006ef8c8 7e86c285 0x006ef880: 7ffdc0cc 7efe3ff4 006ef898 7ef85068 0x006ef890: 7ed48ee4 7ee88ff4 006ef8e8 7ee605fe 0x006ef8a0: 7ed48ee0 006efad0 006ef8f8 7ed11de5 0x006ef8b0: 7ed40ff4 006efad0 006ef8f8 7ed11f82 Backtrace: =>1 0x0040acc8 in viewer (+0xacc8) (0x006efa58) 2 0x0040f846 in viewer (+0xf846) (0x006efb28) 3 0x7eb78c2a WINPROC_wrapper+0x1a() in user32 (0x006efb58) 4 0x7eb79308 WINPROC_wrapper+0x6f8() in user32 (0x006efba8) 5 0x7eb7f646 WINPROC_call_window+0xe4() in user32 (0x006efbf8) 6 0x7eb3dc01 in user32 (+0x8dc01) (0x006efc58) 7 0x7eb40132 in user32 (+0x90132) (0x006efca8) 8 0x7eb40532 SendMessageW+0x54() in user32 (0x006efcf8) 9 0x7eb4bfa8 in user32 (+0x9bfa8) (0x006efd28) 10 0x7eb4ca05 RedrawWindow+0x38d() in user32 (0x006efd98) 11 0x7eb4cad0 UpdateWindow+0x35() in user32 (0x006efdb8) 12 0x0040f47f in viewer (+0xf47f) (0x006efdf8) 13 0x0040f514 in viewer (+0xf514) (0x006efe38) 14 0x00486b28 in viewer (+0x86b28) (0x006efeb8) 15 0x0040124b in viewer (+0x124b) (0x006efee8) 16 0x004012b8 in viewer (+0x12b8) (0x006efef8) 17 0x7ee44a87 in kernel32 (+0x64a87) (0x006effe8) 18 0xb7e70c7b wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) [...] :-)
  8. Jiri Jakes jiri.jakes na gmail.com #mc68be4
    jiriczech na phoenix dist % wine viewer.exe jiriczech na phoenix dist % :-) Kompiluju primo z gitu...
  9. Petr Nejedly Petr.Nejedly na Sun.COM #m278966
    jiriczech na phoenix dist % wine viewer.exe jiriczech na phoenix dist %
    No dobre, po ACCEPT_KEYWORDS='~x86' emerge wine uz mi to taky funguje, i kdyz to nebyla uplne pointa... Renderuje to zajimave, nicmene prilis si toho nedela z multipolygonu ani z vrstev. Mimourovnove krizovatky maluje asi jako mapnik (cili napred vsechny outline, pak vsechny vnitrky), jen jeste mene prehledne kvuli tem vrstvam. Dale se mi zda, ze to nezvladne soubeh slinice a tramvaje (highway=*/railway=tram na jedne way) Datova struktura bude pekna, vse ve 2MB, ale zda se, ze komprimovane. Zkousel jsem v josm-ng jak by slapalo "hifi" renderovani a dokazu renderovat v realnem case (cili srovnatelne s josm-ng bez "hifi") v podobne kvalite a resim i vrstvy. Viz: http://stoupa.sh.cvut.cz/~nenik/josm-ng-hifi.png Hodill by se rozumny, mezi systemy sdilitelny popis renderovaciho stylu (zatim pouzivam mappainti + neco hardcoduju). Osmarendererova XSL transfromace neni, opakuji neni, takovym rozumnym popisem ;-) Pak bychom se mohli lepe bavit o implementaci renderovani. Coz mi pripomina, ze pro rozumne renderovani mimourovnovych krizovatek (jako ta na screenshotu*) potrebuje i pro osmarenderer mirne prizpusobit styl editace. Napojeni sjezdu z mostu je potreba udelat na stejne vrstve jako je most (obecne, krizovatky by mely mit vsechny cesty ve stejne layer), jinak se vyrenderuje okraj vyssi silnice a napojeni nevypada napojene, viz: http://www.openstreetmap.org/?lat=50.04047&lon=14.40705&zoom=17&layers=0BFT *) screenshot se renderoval z mirne upraveneho czechia.osm a ty skrty na sjezdech ted uz renderuju lepe...
  10. BH singularita na gmail.com #ma85068
    Pekne, jen tak dal. Jsem zvedav na dalsi verze :) Takova drobnost co to zda se neumi jsou relace mezi polygony, napr tady je to docela dost videt: http://www.openstreetmap.org/?lat=50.10088&lon=14.39586&zoom=16&layers=B0FT Budovy jsou tam vykousle (maji dvorek/nadvori), ale v tom prohlizeci jsou plne. Tusim na dalsich mistech jsou pomoci relaci delane treba ostrovy ve vodnich plochach. Jinak highway=service jsou velmi spatne videt, barva se blizi barve podkladu a nemaji sedy/cerny okraj jako "lepsi" silnice. Footway jsou zase mozna zbytecne moc vyrazne :) Martin
  11. Tomas Kolda kolda na web2net.cz #m147447
    Nemam na vyvoj moc casu, takze asi 4 mesice jsem vyvijel jen datovou zakladnu (komprimace, spatial indexy, konverze dat apod.). Posledni asi 3 tydny delam na grafice, takze tam jsou mouchy presne co pisete. Optimalizace na grafice je nulova, proto mate asi tu javu rychlejsi. Jinak ale myslim, ze 6MB v pameti by se s Javou dosahovalo tezko. Jsem Javista tak prosim nekamenovat za mou poznamku :), ale treba se mylim. zlib komprimaci na komplet data jsem zkousel, ale vychazi asi o 80% vetsi soubor. Jinak jak jsem psal. Filozofie programu je miniaturni aplikace, ktera by mela bezet na embedded zarizenich (WinCE apod.) a poskytovat sluzby jako napr. iGO. Pro OSMaky tam budou featury jako automaticke logovani, separace casti tracku, ktery jeste neni v mapach, warningy casti tracku, ktere se hodne lisi od mapy (silnice je zakreslena s chybou). Bude to freeware, ale otevirat kod se mi zatim nechce. Konfigurace apod. budou formou easy textaku, jak je to ted. Kdyz jsem zacinal s OSM hrozne mi stvalo, ze neco takoveho chybi. Bud se musi neco instalovat, databaze, mapnik, osmarender apod. a je hodne slozite s cimkoliv si pohrat bez webu. O tom, ze si to dam do PDA, smartphone ani nemluve. Hodne lidi by rado pomohlo (moje domnenka), ale nemaji cas. Proto tato aplikace. Na jedno tlacitko se poslou logy na server a pokud mozno automaticky zapracuji (to doufam uz nekdo kuti), pokud tedy clovek bude chtit prispivat do OSM. Jedno tlacitko je az az. Samozrejmne, ze spousta lidi ma uplne jiny nazor na tvorbu aplikaci, ale to je proste jejich cast uzivatelske zakladny. Ja doufam, ze muj pristup si take nekoho najde a snad to i k necemu pomuze, jak jsem psal vyse. Ted se jdu teda vrhnout na ty diry a zlevel, at si nedelam ostudu. Proste jsem se na ten brzky release nemel nechat ukecat :-) Tomas
  12. Petr Nejedly Petr.Nejedly na Sun.COM #m7971b5
    Nemam na vyvoj moc casu, takze asi 4 mesice jsem vyvijel jen datovou zakladnu (komprimace, spatial indexy, konverze dat apod.). Posledni asi 3 tydny delam na grafice, takze tam jsou mouchy presne co pisete. Optimalizace na grafice je nulova, proto mate asi tu javu rychlejsi.
    Nemyslim, ze mam tu javu rychlejsi. Mam josm-ng rychlejsi nez josm, dostatecne rychly pro beznou editaci datasetu velikosti czechia.osm, ale prerendrovani celoobrazovkoveho pohledu na Prahu pri nejnevhodnejsim zoomu jsou stale nejake stovky ms. Ale pisu editor a musim se rozumne vejit do pameti aniz bych stazena data poskodil (pro viewer bych napr. zahodil nody mimo krizovatky, pro editor je musim udrzovat vsechny kvuli tomu jednomu tagu (created_by) a kvuli IDcku). Zatim jsem se nevrhal ani do skutecnych indexu, josm-ng ma jen sesortovane nody podle jedne osy a hlida bboxy cest. To staci pro vyrazne rychlejsi renderovani velkych datasetu nez zvlada josm a luxusni editovani pri rozumnem zoomu.
    Jinak ale myslim, ze 6MB v pameti by se s Javou dosahovalo tezko. Jsem
    Ani smykem. 500k nodu x 16B souradnice + 8B ID je samo o sobe 12MB a to jeste ani nejsou vsechny informace z OSM. Ale to neni problem javy, tolik tech dat proste je a editor je musi udrzet. A OSM APIv0.6 to muze udelat jeste horsi.
    Javista tak prosim nekamenovat za mou poznamku :), ale treba se mylim. zlib komprimaci na komplet data jsem zkousel, ale vychazi asi o 80% vetsi soubor.
    Takze data nejsou komprimovana? V tom 2MB souboru jsem nenasel zadne texty.
    Jinak jak jsem psal. Filozofie programu je miniaturni aplikace, ktera by mela bezet na embedded zarizenich (WinCE apod.) a poskytovat sluzby jako napr. iGO. Pro OSMaky tam budou featury jako automaticke logovani, separace casti tracku, ktery jeste neni v mapach, warningy casti tracku, ktere se hodne lisi od mapy (silnice je zakreslena s chybou). Bude to freeware, ale otevirat kod se mi zatim nechce. Konfigurace apod. budou formou easy textaku, jak je to ted.
    [...]
    Ted se jdu teda vrhnout na ty diry a zlevel, at si nedelam ostudu. Proste jsem se na ten brzky release nemel nechat ukecat :-)
    Ale mel. Muj komentar neberte jako kritiku, ale spis jako motivaci. Resime spolecne problemy, komunikace neni nikdy na skodu. Josm-ng zatim take nemaluje diry a nebude uplne snadne je dodelat tak, aby spravne reagovaly na editaci (zmenim "nejakou" relaci a tim se zmeni renderovani nejake way. Nebo jeste hure, zmenim "nejakou" way (tu vnitrni) a zmeni se mi renderovani jine way (te vnejsi)). Vpodstate budu muset vymyslet obecne renderovani relaci, napr. kvuli relacnimu znaceni turistickych cest.
  13. Tomas Kolda kolda na web2net.cz #m5ed544
    Ani smykem. 500k nodu x 16B souradnice + 8B ID je samo o sobe 12MB a to jeste ani nejsou vsechny informace z OSM. Ale to neni problem javy, tolik tech dat proste je a editor je musi udrzet. A OSM APIv0.6 to muze udelat jeste horsi.
    Ja nacitam diky spatial indexum jen plochu co renderuji, takze v pameti se udrzuje jen aktualni pohled + do urcite meze nechavam to co uz jsem nacetl (kdyby se uzivak vratil). To zajistuje pomerne male pametove naroky. To je u toho XML horsi. Vy to muzete to take zkusit vyresit meziformatem. Pri konverzi XML jsem si musel udelat primitivni indexovane bin soubory, abych je nemusel mit cele v pameti a mohl tak pohodlne pracovat i s planet.osm. Importovat celou DB mi prislo silenstvi, kdyz tohle zabira se stejnou informaci uplne stejne jako planet.bz2. V pameti si pak muzete nechavat jen to co clovek zmenil a pri ulozeni to zmergovat.
    Takze data nejsou komprimovana? V tom 2MB souboru jsem nenasel zadne texty.
    No nevim presne jak je definovana komprimace, ale nejsou komprimovana stylem: zapisu souradnice napr v int32_t za sebe a pak ten blob zipnu... To prave neni tak efektivni. zlib se pouziva jen na pripady kdy je vyhodny (napr. nektere texty).
    Vpodstate budu muset vymyslet obecne renderovani relaci, napr. kvuli relacnimu znaceni turistickych cest.
    Zatim si to zjednodusim jen generovanim der polygonu. To je celkem lehka uloha. Zbytek relaci necham lezet dokud nekde nevykouknou. Tomas
  14. Pavel Machek pavel na suse.cz #m095592
    Ahoj!
    Jinak jak jsem psal. Filozofie programu je miniaturni aplikace, ktera by mela bezet na embedded zarizenich (WinCE apod.) a poskytovat sluzby jako napr. iGO. Pro OSMaky tam budou featury jako automaticke logovani,
    Takze vcetne navigace po krizovatkach? Wow.
    Bude to freeware, ale otevirat kod se mi zatim
    No, freeware ma IMNSHO vsechny nevyhody open source... a zadnou z jeho vyhod. Otevrit kod co nejdriv znamena ze s nim treba nekdo pomuze...
    Ted se jdu teda vrhnout na ty diry a zlevel, at si nedelam ostudu.
    Zadnej kod nedela ostudu kdyz je pod GPL :-). Pavel
  15. Petr Nejedly Petr.Nejedly na Sun.COM #m24c2ff
    Takze pre alpha je zde: http://www.web2net.cz/osm/dist.zip Zatim to neumi nazvy cehokoliv (v databazi jiz jsou), zoom maximalne 1:100000 (ostatni nejsou vygenerovany) a je tam naprosto zakladni nastaveni barvicek. Nejsou vsechny dle OSM, ale tak jak se to libi mne. Hlavne highways jsou uplne jinak. Pri nejvetsim zoomu (<1:10000) jsou cervene videt features, ktere nemaji nastaveny vzhled (barvy apod.). Je tam videt i ta chyba s Berounkou...
    Vratil bych se k tomuhle. Jak velky dataset zvladnete a jak by byla velka ta databaze pod tim. Germany.osm (7.5M nodes, 1M ways)? Planet.osm (>200M nodes, 20M ways)? Do josm-ng jsem udelal mirnou opravu smerem k moznosti prace s jeste vetsimi datasety - vyclenil jsem z DataSetu implementaci storage a od ni pozaduju zhruba nasledujici API: getNode(long) getWay(long) getRelation(long) getPrimitives(Bounds, DeailLevel) implementaci getPrimitives(Bounds, DetailLevel) zrejme mate (vicevrstvy spatial index), zbytek je vcelku trivialni (pridavny jednorozmerny index). Ja zatim na tuhle datovou strukturu nemam cas :-) tak vse drzim v pameti, coz se pro czechia.osm stale da....
  16. Tomas Kolda kolda na web2net.cz #m649dab
    No ja jsem se zbavil IDcek OSM, takze jsem usetril spoustu mista. IDcko s indexem by zabralo mnohdy vice nez cela geometrie a atributy. Proto mam vsechny primitiva precislovana (nova ID se pouzivaji v routingu) a tim usetrim hodne mista. Pokud by nekdo potreboval puvodni ID muze se pouzit nejaky prevod IDcek z novych na puvodni. Software je ale jako prohlizecka. Neni navrzen jako editor (i kdyz editovat geometrie jde) a tudiz jsem od tohoto oprosten. Moje priorita je minimalizace mista. Velikosti datasetu nejsem omezen. Myslim, ze by stejny model mohl postihnout cely svet bez ujmy na rychlost. Umi dynamicky pripojovat dalsi datasety, ktere se pri renderingu chovaji jako jeden. Pote se muze vygenerovat napr. CR, SK apod. A clovek si stahne mapy jen co potrebuje, nahraje do adresare data a ma je "spojene". Velikost se da odhadnout z bz2. Docela to vychazi, ze je to priblizne 25% osm.bz2 souboru. Nyni jsem s vyvojem casove na stiru, ale uz to aspon umi ty diry. Naportoval jsem na WinCE, kde vse bezi OK, ale neni moc rychle i presto, ze jsem zrychlil puvodni rendering. Delam tedy na rychlem draft rendereru, ktery bude pouzit pri tahani mysi a po zastaveni mapu vyhladi, vykresli detaily, pisma apod. Docela uz to chodi, ale ted nemam moc cas uklidit kod a udelat release. Jinak k josm-ng. Vas ani tak nepali velikost datoveho souboru, takze bych pouzil sqlite, ktery se na tohle hodi vyborne. Je rychly, maly, jednoduchy. Nad databazi si udelate abstrakci get..., set..., remove..., nebo klidne JPA, ale to uz je asi kanon na brabce.
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.