[Talk-cz] Plochy vod v OSM
Vlákno 16.5. - 5.6.2008, počet zpráv: 16
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
2008/5/16 Tomas Kolda <kolda na 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 na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
--
Michal Grézl
http://walley.org
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 na gmail.com> wrote:
zobrazit citaci
> 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.
>
>
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz na openstreetmap.org
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
> >
>
>
>
>
> --
> Michal Grézl
> http://walley.org
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
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 na gmail.com> wrote:
>
>> 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.
>>
>>
>> > _______________________________________________
>> > Talk-cz mailing list
>> > Talk-cz na openstreetmap.org
>> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>> >
>>
>>
>>
>>
>> --
>> Michal Grézl
>> http://walley.org
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
>
------------- dal?í ?ást ---------------
HTML p?íloha byla odstran?na...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080518/6f1af913/attachment.html>
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 na gmail.com> wrote:
>
>
> 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.
>
>
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz na openstreetmap.org
> >
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
> >
>
>
>
>
> --
> Michal Grézl
> http://walley.org
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
>
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 na gmail.com> wrote:
>>
>>
>> 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.
>>
>>
>> > _______________________________________________
>> > Talk-cz mailing list
>> > Talk-cz na openstreetmap.org
>> >
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>> >
>>
>>
>>
>>
>> --
>> Michal Grézl
>> http://walley.org
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>
>>
>>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080518/248de730/attachment.html>
Tomas Kolda napsal(a):
zobrazit citaci
> 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)
[...]
:-)
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
jiriczech na phoenix dist % wine viewer.exe
jiriczech na 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 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)
> [...]
>
> :-)
>
Jiri Jakes napsal(a):
zobrazit citaci
> 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...
--
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!
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 na web2net.cz> wrote:
zobrazit citaci
>
> Takze pre alpha je zde:
>
> http://www.web2net.cz/osm/dist.zip
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 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...
>
>
------------- dal?í ?ást ---------------
HTML p?íloha byla odstran?na...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080519/3ceb1742/attachment.html>
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!
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
------------- dal?í ?ást ---------------
HTML p?íloha byla odstran?na...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080519/2139ddaa/attachment.html>
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
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!
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....
>
>
>
------------- dal?í ?ást ---------------
HTML p?íloha byla odstran?na...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080605/ea780c90/attachment.html>« zpět na výpis měsíce