« zpět na výpis měsíce |

[Talk-cz] Plochy vod v OSM

Vlákno 16.5. - 5.6.2008, počet zpráv: 16


16.5.2008 10:57:10 (#1)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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

17.5.2008 09:15:35 (#2)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2008/5/16 Tomas Kolda <kolda at web2net.cz>: zobrazit citaci
> 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 zobrazit citaci
> 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. zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >
-- Michal Gr?zl http://walley.org

17.5.2008 09:19:55 (#3)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
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. On 5/17/08, Michal Gr?zl <michal.grezl at gmail.com> wrote: zobrazit citaci
> 2008/5/16 Tomas Kolda <kolda at 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. > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > > > > -- > Michal Gr?zl > http://walley.org > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

18.5.2008 02:10:55 (#4)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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... Jiri Klement napsal(a): zobrazit citaci
> 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. > > On 5/17/08, Michal Gr?zl <michal.grezl at gmail.com> wrote: > >> 2008/5/16 Tomas Kolda <kolda at 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. >> >> >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz at openstreetmap.org >> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > >> >> >> >> >> -- >> Michal Gr?zl >> http://walley.org >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080518/6f1af913/attachment.html>

18.5.2008 02:42:44 (#5)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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... > > Jiri Klement napsal(a): > 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. > > On 5/17/08, Michal Gr?zl <michal.grezl at gmail.com> wrote: > > > 2008/5/16 Tomas Kolda <kolda at 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. > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > > > > -- > Michal Gr?zl > http://walley.org > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

18.5.2008 11:29:51 (#6)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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 Jiri Klement napsal(a): zobrazit citaci
>> 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. > > >> 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... >> >> Jiri Klement napsal(a): >> 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. >> >> On 5/17/08, Michal Gr?zl <michal.grezl at gmail.com> wrote: >> >> >> 2008/5/16 Tomas Kolda <kolda at 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. >> >> >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz at openstreetmap.org >> > >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > >> >> >> >> >> -- >> Michal Gr?zl >> http://walley.org >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080518/248de730/attachment.html>

18.5.2008 11:59:52 (#7)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> Takze pre alpha je zde: > > http://www.web2net.cz/osm/dist.zip
nenik at 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) [...] :-) -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

19.5.2008 08:28:44 (#8)
gravatar

Jiri Jakes

<jiri.jakes at gmail.com>
16
jiriczech at phoenix dist % wine viewer.exe jiriczech at phoenix dist % :-) Kompiluju primo z gitu... Petr Nejedly wrote: zobrazit citaci
> Tomas Kolda napsal(a): >> Takze pre alpha je zde: >> >> http://www.web2net.cz/osm/dist.zip > > nenik at 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) > [...] > > :-) >

19.5.2008 02:15:07 (#9)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Jiri Jakes napsal(a): zobrazit citaci
> jiriczech at phoenix dist % wine viewer.exe > jiriczech at 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... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

19.5.2008 02:18:45 (#10)
gravatar

BH

<singularita at gmail.com>
306
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 On 5/18/08, Tomas Kolda <kolda at web2net.cz> wrote: zobrazit citaci
> > Takze pre alpha je zde: > > http://www.web2net.cz/osm/dist.zip

19.5.2008 04:17:53 (#11)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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 Petr Nejedly napsal(a): zobrazit citaci
> Jiri Jakes napsal(a): > >> jiriczech at phoenix dist % wine viewer.exe >> jiriczech at 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... > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080519/3ceb1742/attachment.html>

19.5.2008 05:26:58 (#12)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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.
[...] zobrazit citaci
> 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. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

19.5.2008 05:55:04 (#13)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Petr Nejedly napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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). zobrazit citaci
> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080519/2139ddaa/attachment.html>

20.5.2008 12:54:03 (#14)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> 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. zobrazit citaci
> 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... zobrazit citaci
> Ted se jdu teda vrhnout na ty diry a zlevel, at si nedelam ostudu.
Zadnej kod nedela ostudu kdyz je pod GPL :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.6.2008 12:42:21 (#15)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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.... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.6.2008 09:57:01 (#16)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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. Petr Nejedly napsal(a): zobrazit citaci
> Tomas Kolda napsal(a): > >> 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.... > > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080605/ea780c90/attachment.html>

« zpět na výpis měsíce