odbo?ovac? pruhy

20 zpráv
Zpět na přehled

odbo?ovac? pruhy

20 zpráv PJMPHST 7 účastníků 15 min čtení
  1. Pavel Machek pavel na ucw.cz #mbfa454
    Na takovehle detailni modelovani se, myslim, OSM prilis nehodi. Pro vyuziti v navigaci bych spis byl pro to, aby se zdrojova data pro navigaci brala z vice zdroju. Napriklad databaze krizovatek by byla pomerne hezky projekt sam o sobe.
    Ja nevim ale.... kde by to melo byt jinde nez v osm? Spojovat v navigaci vic databazi je slusna nocni mura... uz jsem to delal s mhd. Pavel
  2. Jakub Sýkora kubajz na kbx.cz #m0d7e6f
    Ahoj Pavle,
    Na takovehle detailni modelovani se, myslim, OSM prilis nehodi. Pro vyuziti v navigaci bych spis byl pro to, aby se zdrojova data pro navigaci brala z vice zdroju. Napriklad databaze krizovatek by byla pomerne hezky projekt sam o sobe.
    Ja nevim ale.... kde by to melo byt jinde nez v osm?
    V OSM muze byt u krizovatky treba tag s odkazem do nejake jine databaze. Proste z principu se OSM na tohle nehodi. Pokud nebude obsahovat nejake vrstvy nebo jiny aparat, tak by z toho byl takovy gulas, ze by to proste neslo. Staci se podivat na nektere nastroje pro modelovani krizovatek a zjistis, ze to zdaleka neni takova legrace namodelovat krizovatku, aby to k necemu bylo. A na to je potreba taky celkem dobry editor. Je to podobna situace, jakou jsme resili s lesama - zda importovat jen hranice nebo i poddruhy lesu a jine pytloviny. Umim si ale predstavit, ze na nodu krizovatky bude crossing_ref=crossdb:12345 a ta databaze krizovatek bude samostatna a popsana jinym zpusobem. Kazda navigace stejne vnitrne pouziva uplne jiny format, takze potom udelat automaticky build skript, ktery tyhle dve informace bude umet vyuzit a vhodne sloucit je uz hracka... A koneckoncu, proc by databaze krizovatek nemohla existovat jako druhy projekt nebo podprojekt OSM? Ve vysledku by to treba dopadlo tak, ze by sis v JOSM oznacil bod krizovatky a prepnul by ses do rezimu kresleni krizovatky. To bys pak ulozil a vratil se zpatky. Nicmene v OSM databazi by to zustalo porad bodem.
  3. Michal Grézl michal.grezl na openstreetmap.cz #md76057
    2009/8/12 Jakub Sýkora <kubajz na kbx.cz>:
    Umim si ale predstavit, ze na nodu krizovatky bude crossing_ref=crossdb:12345 a ta databaze krizovatek bude samostatna a popsana jinym zpusobem. Kazda navigace stejne vnitrne pouziva uplne jiny format, takze potom udelat automaticky build skript, ktery tyhle dve informace bude umet vyuzit a vhodne sloucit je uz hracka...
    Krasny, nerealny, sen. Kdo bude udrzovat kozistenci? Popis krizovatky patri do osm, pokud tam jeste neni (jakoze ta relace na odbocovani je docela propracovana), tak je potreba ho tam dopsat vhodnym zpusobem. Zatim to nikoho moc netrapi tak to nikdo neudelal. Zatim lidi trapi jen nesmyslny rozdil mezi path a footway, pokud vim uz se to resi na 3 mailinglistech;)))
  4. Kubajz kubajz na kbx.cz #mc18f38
    Konzistence bude zajistena uplne stejne jako je treba ted zajistena konzistence bodu a ways. Ja jen rikam, ze nad stavajici strukturou databaze proste odbocovaci pruhy neudelame. K
  5. Pavel Machek pavel na ucw.cz #md9661a
    Ahoj Pavle,
    Na takovehle detailni modelovani se, myslim, OSM prilis nehodi. Pro vyuziti v navigaci bych spis byl pro to, aby se zdrojova data pro navigaci brala z vice zdroju. Napriklad databaze krizovatek by byla pomerne hezky projekt sam o sobe.
    Ja nevim ale.... kde by to melo byt jinde nez v osm?
    V OSM muze byt u krizovatky treba tag s odkazem do nejake jine databaze. Proste z principu se OSM na tohle nehodi. Pokud nebude obsahovat nejake vrstvy nebo jiny aparat, tak by z toho byl takovy gulas, ze by to proste neslo. Staci se podivat na nektere nastroje pro modelovani krizovatek a zjistis, ze to zdaleka neni takova legrace namodelovat krizovatku, aby to k necemu bylo. A na to je potreba taky celkem dobry editor. Je to podobna situace, jakou jsme resili s lesama - zda importovat jen hranice nebo i poddruhy lesu a jine pytloviny. Umim si ale predstavit, ze na nodu krizovatky bude crossing_ref=crossdb:12345 a ta databaze krizovatek bude samostatna a popsana jinym zpusobem. Kazda navigace stejne vnitrne pouziva uplne jiny format, takze potom udelat automaticky build skript, ktery tyhle dve informace bude umet vyuzit a vhodne sloucit je uz hracka...
    Jestli se osm na neco *opravdu* nehodi tak jsou to odkazy do externich databazi. (A ne, jeden odkaz na uzlu fakt neni dostatecna informace).
  6. Pavel Machek pavel na ucw.cz #m02142f
    Ahoj!
    Jen?e nen? k?i?ovatka jako k?i?ovata. u M?K je z?hodn? i mo?n? nakrest v?echny rampy a kolektory, holt pr?pletov? ?seky a p??dtn? pruhy bu? ned?lqt nebo zjednodu?it Ale zde by se jedalo o datab?zi mal?ch ?rov?ov?ch k?i?ovatek.
    Ja myslim ze relace 'tohle je na stejnym asfaltu, ale cara na zemi zakazuje prujezd' a 'tohle jsou pruhy vedle sebe na stejny silnici, prujezd povolen' to resi, ne? Pavel
  7. Michal Grézl michal.grezl na openstreetmap.cz #m18a98d
    2009/8/13 Kubajz <kubajz na kbx.cz>:
    Konzistence bude zajistena uplne stejne jako je treba ted zajistena konzistence bodu a ways. Ja jen rikam, ze nad stavajici strukturou databaze proste odbocovaci pruhy neudelame. K
    konzistence bodu a ways je zajistena pomoci api, a taky pomoci nastroju dbms. Pokud nasi novou krasnou databazi zamontujeme do techto dvou udrzovacich mechanizmu, stava se soucasti databaze puvodni a uz o ni nelze hovorit jako o nove. Urcite by sel vymyslet slovni popis krizovatky, a takovy popis rozsekat do nejakeho systemu tagu. Treba: lanes=4 lanes_from_left_to_right=left,straight,straight_and_right,right - a mame odbocovaci pruhy. Urcite by to slo namontovat na soucasny datamodel. Musel by ovsem nekdo vyrobit nejaky navigator co to pouzije, ponevadz teoreticke tlachani nema zadny vyznam v projektu, ktery ma jako fundamentalni soucast modelu funkcnosti vizi "co se pouziva, to je spravne, cim vic se to pouziva, tim vic je to spravne". Mate nekdo garmini navigaci? Umi to ten nahled na pruhy na krizovatce vubec?
  8. Petr Stehlik pstehlik na sophics.cz #m853ad6
    Michal Grézl píše v Čt 13. 08. 2009 v 10:36 +0200:
    Urcite by sel vymyslet slovni popis krizovatky, a takovy popis rozsekat do nejakeho systemu tagu. Treba: lanes=4 lanes_from_left_to_right=left,straight,straight_and_right,right - a mame odbocovaci pruhy. Urcite by to slo namontovat na soucasny datamodel.
    Asi jsem mel hned ve svem puvodnim dotazu uvest nasledujici odkaz do wiki (jak jsem rikal, ze jsem na to videl nejake proposaly): http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane
    Musel by ovsem nekdo vyrobit nejaky navigator co to pouzije, ponevadz teoreticke tlachani nema zadny vyznam v projektu, ktery ma jako fundamentalni soucast modelu funkcnosti vizi "co se pouziva, to je spravne, cim vic se to pouziva, tim vic je to spravne". Mate nekdo garmini navigaci? Umi to ten nahled na pruhy na krizovatce vubec?
    Muzu promluvit s lidmi od Navitu, vypadaji velmi pruzne, ale nejdriv jsem chtel vedet, jak je na tom OSM. Petr
  9. Petr Stehlik pstehlik na sophics.cz #mcd8396
    Petr Stehlik píše v Čt 13. 08. 2009 v 10:41 +0200:
    Michal Grézl píše v Čt 13. 08. 2009 v 10:36 +0200:
    Urcite by sel vymyslet slovni popis krizovatky, a takovy popis rozsekat do nejakeho systemu tagu. Treba: lanes=4 lanes_from_left_to_right=left,straight,straight_and_right,right - a mame odbocovaci pruhy. Urcite by to slo namontovat na soucasny datamodel.
    Asi jsem mel hned ve svem puvodnim dotazu uvest nasledujici odkaz do wiki (jak jsem rikal, ze jsem na to videl nejake proposaly): http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane
    A tady je ten druhy: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group A muj puvodni dotaz byl v podstate o tom, jestli se tohle uz pouziva. Petr
  10. Michal Grézl michal.grezl na openstreetmap.cz #m1a300c
    2009/8/13 Petr Stehlik <pstehlik na sophics.cz>:
    Muzu promluvit s lidmi od Navitu, vypadaji velmi pruzne, ale nejdriv jsem chtel vedet, jak je na tom OSM. Petr
    To by nebylo spatne. Ja tvrdim ze pokud neco vymysli, naprogramuji a udelaji z toho hezke obrazky, zbytek lidi to zacne automaticky (vice ci mene) pouzivat. Protoze bude dokazana smysluplnost a hlavne funkcnost takoveho reseni. Chci tim rict, ze by bylo lepsi kdyby to vymysleli oni a pak by se to aplikovalo na zbytek osm, protoze opacne to moc nefunguje:)
  11. Petr Stehlik pstehlik na sophics.cz #me26c77
    Michal Grézl píše v Čt 13. 08. 2009 v 11:02 +0200:
    2009/8/13 Petr Stehlik <pstehlik na sophics.cz>:
    Muzu promluvit s lidmi od Navitu, vypadaji velmi pruzne, ale nejdriv jsem chtel vedet, jak je na tom OSM. Petr
    To by nebylo spatne. Ja tvrdim ze pokud neco vymysli, naprogramuji a udelaji z toho hezke obrazky, zbytek lidi to zacne automaticky (vice ci mene) pouzivat. Protoze bude dokazana smysluplnost a hlavne funkcnost takoveho reseni. Chci tim rict, ze by bylo lepsi kdyby to vymysleli oni a pak by se to aplikovalo na zbytek osm, protoze opacne to moc nefunguje:)
    Dostal jsem se sem (po vysvetleni cele situace): Cp15> I as navigation developer say: It makes no sense to support tags which are not widely used. Especially if it is non trivial to support them. But I am willing to work out a solution together with you if you can convince the mappers to use it... A potom konstruktivne prisel s napadem jak znacit jednotlive lajny a ted vymysli, jak je propojit. Petr
  12. Jakub Sýkora kubajz na kbx.cz #m3cf096
    To zalezi na uhlu pohledu. V momente, kdy do stavajici db pridas haldy dalsich tabulek a zmodifikujes API, aby to fungovalo, tak uz je to podle me proste zase uplne jina databaze. Na soucasne to proste nejde elegantne vyresit.
  13. Jakub Sýkora kubajz na kbx.cz #m336dae
    Prosim o vysvetleni, ze se OSM nehodi na odkaz do cizi databaze. Tomu fakt nerozumim. Kdyz porovnam dve reseni stejne naprd s konzistenci, jako je tagovani lanes left from right a podobne ptakoviny, s odkazem do jine databaze/tabulky/cehokoliv, tak mi prijde, ze jsme na tom uplne stejne spatne... Samozrejme se nebranim tomu, aby to nekdo vymyslel nad stavajici infrastrukturou, ale obavam se, ze se nepodari vyresit uspesne nasledujici: - problem se smerem - co je smerem tam a co smerem zpet a zachovani konzistence - u way se jeste castecne da, ale u bodu? To uz asi vubec ne - tam se o smeru nejak neda hovorit -nutnost rozsekavat way pri zmene razeni pruhu Napadlo me resit to nejakym zpusobem from-to, kde from by bylo cislo nodu z a to by bylo cislo nodu do - problem je, jak udrzet konzistenci, kdyz nekdo smaze/prida bod. Bylo by asi nutne to renderovat primo v JOSM a Potlachu, aby si toho lidi pri editaci vubec vsimli a vizualne taky videli, jak to vypada... K
  14. Petr Stehlik pstehlik na sophics.cz #m64884e
    Jakub Sýkora píše v Pá 14. 08. 2009 v 09:20 +0200:
    Prosim o vysvetleni, ze se OSM nehodi na odkaz do cizi databaze.
    mezi dvema databazemi se neudrzi sync.
    - problem se smerem - co je smerem tam a co smerem zpet a zachovani konzistence - u way se jeste castecne da, ale u bodu?
    u way se smer da urcit plne (ne jen castecne), bod smer nema a neni potreba, aby nejaky mel, protoze se jezdi po cestach a ne po bodech.
    -nutnost rozsekavat way pri zmene razeni pruhu
    myslite nutnost rozdelit way, kdyz se ze dvou pruhu stanou treba tri? To mi prijde jako mala cena za mozne vyhody.
    Napadlo me resit to nejakym zpusobem from-to, kde from by bylo cislo nodu z a to by bylo cislo nodu do
    autor Navitu navrhuje from_lane -> to_lane relaci, ktera se opira o cesty, ne o body. Myslim, ze by to mohlo fungovat, akorat se ho chci jeste zeptat, jestli je opravdu nezbytne mit to_lane, jestli nestaci to_way. Petr
  15. hanoj ehanoj na gmail.com #mcf48c8
    mezi dvema databazemi se neudrzi sync.
    *** to je vec tech. reseni
    - problem se smerem - co je smerem tam a co smerem zpet a zachovani konzistence - u way se jeste castecne da, ale u bodu?
    u way se smer da urcit plne (ne jen castecne), bod smer nema a neni potreba, aby nejaky mel, protoze se jezdi po cestach a ne po bodech.
    *** problem je s konzistenci smeru pri editaci geometrie. Ta totiz neni staticka a uzivatel do ni volne zasahuje aniz by ho to tlouklo do oci, ze je nekde nejaka vazba. Uz mesto s jednosmerkami, relation:route a maxspeed dava trochu hokej do editace.
    -nutnost rozsekavat way pri zmene razeni pruhu
    myslite nutnost rozdelit way, kdyz se ze dvou pruhu stanou treba tri? To mi prijde jako mala cena za mozne vyhody.
    *** dnesni renderery kresli na mape kazdou way samostatne (bez ohledu na pouziti opakovanych nazvu ulice). Tudiz by se jednou museli predelat tak, aby si umeli vlastnosti seskupovat do vetsich celku. To uz muze byt zajimavejsi zavest nejake relativni negeometricke nody.
    Napadlo me resit to nejakym zpusobem from-to, kde from by bylo cislo nodu z a to by bylo cislo nodu do
    autor Navitu navrhuje from_lane -> to_lane relaci, ktera se opira o cesty, ne o body. Myslim, ze by to mohlo fungovat, akorat se ho chci jeste zeptat, jestli je opravdu nezbytne mit to_lane, jestli nestaci to_way.
    *** kde je ten navrh popsany? from_lane -> to_way se pouziva v softwarech pro kapacitni vypocty krizovatek. from_lane -> to_lane je asi pro navigaci vyhodnejsi, vi kterym pruhem ma auto protlacovat na dalsi kriz. hanoj
  16. Petr Stehlik pstehlik na sophics.cz #m2d2535
    hanoj píše v Pá 14. 08. 2009 v 10:05 +0200:
    u way se smer da urcit plne (ne jen castecne), bod smer nema a neni potreba, aby nejaky mel, protoze se jezdi po cestach a ne po bodech.
    *** problem je s konzistenci smeru pri editaci geometrie. Ta totiz neni staticka a uzivatel do ni volne zasahuje aniz by ho to tlouklo do oci, ze je nekde nejaka vazba.
    vizualni zpetna vazba v editorech by asi opravdu byla nezbytna.
    -nutnost rozsekavat way pri zmene razeni pruhu
    myslite nutnost rozdelit way, kdyz se ze dvou pruhu stanou treba tri? To mi prijde jako mala cena za mozne vyhody.
    *** dnesni renderery kresli na mape kazdou way samostatne (bez ohledu na pouziti opakovanych nazvu ulice).
    coz vypada opravdu hloupe a melo by se to spravit.
    autor Navitu navrhuje from_lane -> to_lane relaci, ktera se opira o cesty, ne o body. Myslim, ze by to mohlo fungovat, akorat se ho chci jeste zeptat, jestli je opravdu nezbytne mit to_lane, jestli nestaci to_way.
    *** kde je ten navrh popsany?
    v IRC logu navit#irc.freenode.org, ale napsal tam v podstate jen 3 vety. Nejdriv vymyslel pocitani pruhu od vnejsiho ve smeru cesty (vnejsi podle toho, na ktere strane se v tom danem statu jezdi), pak definovani smeru tech pruhu (lane:1:oneway="1" znaci pruh ve smeru cesty, lane:2:oneway="-1" znaci pruh orientovany proti smeru cesty - podle me by stacil i jednodussi boolean, neco jako lane:1:thisdirection="true") a nakonec prujezd krizovatkou pomoci from_lane="list;of;lanes" a to_lane="list;of;lanes". Jako naprostemu amateru bez sirsiho rozhledu v OSM mi to prijde jako jednoduche reseni, ktere by slo implementovat dostatecne jednoduse na to, aby to lidi zacali opravdu pouzivat.
    from_lane -> to_way se pouziva v softwarech pro kapacitni vypocty krizovatek. from_lane -> to_lane je asi pro navigaci vyhodnejsi, vi kterym pruhem ma auto protlacovat na dalsi kriz.
    to ano, ale neumim si tak docela predstavit mappera, jak u bezneho X krizeni s lanes=4 dela rucne 24 relaci. I kdyz slusne zjednoduseni predstavuje vicero lanes pohromade: from_lane=1;2 to_lane=4;3 - pak jsme vlastne u toho meho to_way - tak to se ho uz ani nemusim ptat. Dalsi malicka otazka je, jestli by tohle castecne (nebo uplne) nenahradilo soucasne turn restrictions (ktere jsou v Navitu pry "temer hotove"). Petr
  17. Michal Grézl michal.grezl na openstreetmap.cz #meb1350
    2009/8/14 Jakub Sýkora <kubajz na kbx.cz>:
    Prosim o vysvetleni, ze se OSM nehodi na odkaz do cizi databaze.
    Hodi, treba do wikipedie, to se i pouziva, ale clanek na wikipedii muze zaniknout a nebo nekdo zmeni odkaz v osm na jiny, lepsi clanek. Kde je kozistence? v trapu.
  18. Stanislav Brabec utx na penguin.cz #m8ac3cf
    hanoj píše v Pá 14. 08. 2009 v 10:05 +0200:
    myslite nutnost rozdelit way, kdyz se ze dvou pruhu stanou treba tri? To mi prijde jako mala cena za mozne vyhody.
    *** dnesni renderery kresli na mape kazdou way samostatne (bez ohledu na pouziti opakovanych nazvu ulice). Tudiz by se jednou museli predelat tak, aby si umeli vlastnosti seskupovat do vetsich celku. To uz muze byt zajimavejsi zavest nejake relativni negeometricke nody.
    Na OSM Wiki existuje návrh to samé řešit již v databázi pomocí relace (tuším že segmented). Nevím, jestli to už renderery umí, ale podobně funguje route nebo multypolygon, a popisky se nemnoží (jedna budova, více polygonů, jeden popisek). Program na sloučení několika cest do relace segmented by nemusel být až tak komplikovaný.
  19. hanoj ehanoj na gmail.com #m829984
    to ano, ale neumim si tak docela predstavit mappera, jak u bezneho X krizeni s lanes=4 dela rucne 24 relaci. I kdyz slusne zjednoduseni predstavuje vicero lanes pohromade: from_lane=1;2 to_lane=4;3 - pak jsme vlastne u toho meho to_way - tak to se ho uz ani nemusim ptat.
    *** uz by k tomu asi chtelo wysiwyg editor (i restriction si o to rikaji) *** nemusi to by 24 relaci, ale jedna relace udelana podobne jako linka MHD: zast1 zast2 zast3... ha hanoj
  20. Tomáš Tichý t.tichy na post.cz #ma0da18
    2009/8/15 hanoj <ehanoj na gmail.com>:
    to ano, ale neumim si tak docela predstavit mappera, jak u bezneho X krizeni s lanes=4 dela rucne 24 relaci. I kdyz slusne zjednoduseni predstavuje vicero lanes pohromade: from_lane=1;2 to_lane=4;3 - pak jsme vlastne u toho meho to_way - tak to se ho uz ani nemusim ptat.
    *** uz by k tomu asi chtelo wysiwyg editor (i restriction si o to rikaji)
    Na turning restrictions už se něco chystá, viz http://blog.cloudmade.com/2009/07/22/mapzen-an-easy-to-use-editor-for-openstreetmap/ =TT=
Napsat odpověď e-mailem… Odpovědět

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