Turistické známky

46 zpráv
Zpět na přehled

Turistické známky

46 zpráv MLHMJPTJ 12 účastníků 53 min čtení
  1. Marián Kyral mkyral na email.cz #maec656
    Zkouším poslat znovu, napoprvé neprošlo - prý spamuji :-( Marián
  2. LM_1 flukas.robot+osm na gmail.com #md91f1b
    I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým objektem, který v mapě už je - a turistická známka by měla být jen další informací o takovém objektu. Lukáš Matějka (LM_1)
  3. Marián Kyral mkyral na email.cz #m8fff65
    Ahoj,
  4. Karel Volný kavol na seznam.cz #m25ee37
    zdravím, když už jsme se tak rozkecali ... tak já to vidím takto:
    A dá se pak nějak zobrazit najednou daný objekt i TZ? Podporuje to nějaká mapa?
    pokud ne, piš na ně RFE :-)
    Většinou se vybere jen jedna vlastnost a ta se prezentuje. Proč jsou třeba čísla popisná separé? Ty se přece vždy přímo vážou k nějaké budově.
    to je z historických důvodů že proběhl import čísel (adresních bodů) bez návaznosti na budovy, ale wiki k tomu vázání na budovy zčásti nabádá: Addresses can be tagged with addr:housenumber=* and the other addr:* keys. Tags can be added to isolated nodes, to nodes that are parts of building polygons ( = entrance=*s ) or, building=* polygons or on polygons representing the perimeter of the site. http://wiki.openstreetmap.org/wiki/Addresses osobně se kloním k tomu dávat to primárně na ty vstupy
    A ještě mně napadá, jak by se řešilo, pokud má objekt tag website a budu chtít ještě přidat odkaz na TZ?
    i na toto má wiki odpověď :-) A link to ... additional resource can be created using url=*. http://wiki.openstreetmap.org/wiki/Key:website popř. se můžeme domluvit na nějakém rozšíření ve stylu url:cs_tzmista=... K.
  5. Marián Kyral mkyral na email.cz #me040b7
    Ahoj,
  6. LM_1 flukas.robot+osm na gmail.com #ma472d9
    Kromě toho turistické známky se neomezují na Česko ( http://turisticke-znamky.cz/tz/), takže by nebylo od věci pojmout návrh trochu globálněji - tím se zvýší šance na podporu i v jiných mapách než specificky zaměřených na české turistické známky.
  7. Marián Kyral mkyral na email.cz #medc98c
    Kromě toho turistické známky se neomezují na Česko (http://turisticke-znamky.cz/tz/), takže by nebylo od věci pojmout návrh trochu globálněji - tím se zvýší šance na podporu i v jiných mapách než specificky zaměřených na české turistické známky. No nikde jsem nepsal, že se chci zaměřit pouze na Česko, ale zatím je k dispozici jen seznam pro CZ. Asi jsem to měl explicitně zmínit. Taky čekám na kompletní seznam - jak bylo slíbeno. No a mezitím jsem to chtěl probrat tady. Víc hlav víc ví a mnohé tady jsou mnohem zkušenější než já. A někde se musí začít, tak proč ne doma? Navíc v CZ jsou TZ nejrozšířenější. V okolních zemích nejsou TZ až tak známé a většinou pokrývají jen některé oblasti. Je mi jasné, že i při nejlepší vůli to bude nějakou dobu trvat. Prvotní import jsem schopen udělat během pár hodin, ale to musí být nejprve jasno, jak TZ namapovat a co jsem koukal, je kolem toho celkem dost byrokracie. Tu já sice nerad, ale chápu, že bez toho to nejde. Uvítám rady, co a jak a kam se následně obrátit. Každá pomoc je vítána. Marián
  8. Marián Kyral mkyral na email.cz #m97b2b0
    Ještě oprava: SK taky celkem jede. Měl jsem dojem, že tam tolik známek není, ale asi to byl nějaký zastaralý dojem ;-) Marián No nikde jsem nepsal, že se chci zaměřit pouze na Česko, ale zatím je k dispozici jen seznam pro CZ. Asi jsem to měl explicitně zmínit. Taky čekám na kompletní seznam - jak bylo slíbeno. No a mezitím jsem to chtěl probrat tady. Víc hlav víc ví a mnohé tady jsou mnohem zkušenější než já. A někde se musí začít, tak proč ne doma? Navíc v CZ jsou TZ nejrozšířenější. V okolních zemích nejsou TZ až tak známé a většinou pokrývají jen některé oblasti. Je mi jasné, že i při nejlepší vůli to bude nějakou dobu trvat. Prvotní import jsem schopen udělat během pár hodin, ale to musí být nejprve jasno, jak TZ namapovat a co jsem koukal, je kolem toho celkem dost byrokracie. Tu já sice nerad, ale chápu, že bez toho to nejde. Uvítám rady, co a jak a kam se následně obrátit. Každá pomoc je vítána. Marián
  9. jzvc jzvc na tpfree.net #mb4e0f7
    Ahoj, ---------- Pu*vodní zpráva ---------- Pr(edme(t: Re: [Talk-cz] Turistické známky zdravím, kdyz( uz( jsme se tak rozkecali ... tak já to vidím takto:
    A dá se pak ne(jak zobrazit najednou daný objekt i TZ? Podporuje to ne(jaká mapa?
    pokud ne, pis( na ne( RFE :-) Velmi vtipné.
    Ve(ts(inou se vybere jen jedna vlastnost a ta se prezentuje. Proc( jsou tr(eba c(ísla popisná separé? Ty se pr(ece vz(dy pr(ímo váz(ou k ne(jaké budove(.
    to je z historických du*vodu* z(e probe(hl import c(ísel (adresních bodu*) bez návaznosti na budovy, ale wiki k tomu vázání na budovy zc(ásti nabádá: Addresses can be tagged with addr:housenumber=* and the other addr:* keys. Tags can be added to isolated nodes, to nodes that are parts of building polygons ( = entrance=*s ) or, building=* polygons or on polygons representing the perimeter of the site. http://wiki.openstreetmap.org/wiki/Addresses osobne( se kloním k tomu dávat to primárne( na ty vstupy Na wiki jsem nas(el toto: V C(R se pouz(ívají výhradne( Adresní body (Adresní místa) jako nody Node <http://wiki.openstreetmap.org/wiki/Elements#Node>, nebot( vazba mezi prvky "building" a "addr" je M:N.
    Tak tos nasel peknej nesmysl, du se mrknout kterej umelec to tam napsal. Nehlede na to, ze budov s vice cisly bude min nez promile. A uz vubec nemluve o tom, ze i z duvodu navigace a identifikace prave tech budov, je to blbost (navic vim o mapach, ktery adresu zobrazujou pouze pokud je na budove, adresni body je naprosto nezajimaj). Mimochodem, vstupy maji zcela samostatne tagovani (entrance).
  10. hanoj ehanoj na gmail.com #m29f1df
    Většinou se vybere jen jedna vlastnost a ta se prezentuje. Proč jsou třeba čísla popisná separé? Ty se přece vždy přímo vážou k nějaké
    budově.
    to je z historických důvodů že proběhl import čísel (adresních bodů) bez návaznosti na budovy, ale wiki k tomu vázání na budovy zčásti nabádá: Addresses can be tagged with addr:housenumber=* and the other addr:* keys. Tags can be added to isolated nodes, to nodes that are parts of building polygons ( = entrance=*s ) or, building=* polygons or on polygons
    representing
    the perimeter of the site. http://wiki.openstreetmap.org/wiki/Addresses osobně se kloním k tomu dávat to primárně na ty vstupy Na wiki jsem našel toto: V ČR se používají výhradně Adresní body (Adresní
    místa)
    jako nody , neboť vazba mezi prvky "building" a "addr" je M:N. Tak tos nasel peknej nesmysl, du se mrknout kterej umelec to tam napsal. Nehlede na to, ze budov s vice cisly bude min nez promile. A uz vubec
    nemluve o
    tom, ze i z duvodu navigace a identifikace prave tech budov, je to blbost
    (navic vim o
    mapach, ktery adresu zobrazujou pouze pokud je na budove, adresni body je naprosto nezajimaj). Mimochodem, vstupy maji zcela samostatne tagovani (entrance).
    *** Tady umělec. Vazby adres a budov M:N nejsou vazby chybové, ale zcela reálné přípustné a používané. Pro 1:N se stačí mrknou do katastru a způsobu zakreslování budov, pro M:1 stačí mrknout na addr Brna. Jak známo, to že to některá mapa nezobrazuje není chyba dat. Co se tyce asociace budovy s adresnim bodem, existuje nejjednodussi prostory dotaz: "Uvnitř které building:polygon lezi addr:nod?" ha hanoj
  11. Pavel Machek pavel na ucw.cz #md324d3
    Ahoj!
    I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým objektem, který v mapě už je - a turistická známka by měla být jen další informací o takovém objektu.
    No nevim, tohle zavani tim ze se import nikdy neudela. Myslim ze samostatne body nejsou zadny velky problem... jednodussi na import, jednodussi na udrzovani, nevyhody zadne. Pavel
  12. jzvc jzvc na tpfree.net #maa3eb1
    Ve(ts(inou se vybere jen jedna vlastnost a ta se prezentuje. Proc(
    jsou
    tr(eba c(ísla popisná separé? Ty se pr(ece vz(dy pr(ímo váz(ou k
    ne(jaké budove(.
    to je z historických du*vodu* z(e probe(hl import c(ísel (adresních
    bodu*) bez
    návaznosti na budovy, ale wiki k tomu vázání na budovy zc(ásti nabádá: Addresses can be tagged with addr:housenumber=* and the other addr:*
    keys.
    Tags can be added to isolated nodes, to nodes that are parts of building polygons ( = entrance=*s ) or, building=* polygons or on polygons
    representing
    the perimeter of the site. http://wiki.openstreetmap.org/wiki/Addresses osobne( se kloním k tomu dávat to primárne( na ty vstupy Na wiki jsem nas(el toto: V C(R se pouz(ívají výhradne( Adresní body
    (Adresní místa)
    jako nody , nebot( vazba mezi prvky "building" a "addr" je M:N. Tak tos nasel peknej nesmysl, du se mrknout kterej umelec to tam napsal. Nehlede na to, ze budov s vice cisly bude min nez promile. A uz
    vubec nemluve o
    tom, ze i z duvodu navigace a identifikace prave tech budov, je to
    blbost (navic vim o
    mapach, ktery adresu zobrazujou pouze pokud je na budove, adresni
    body je
    naprosto nezajimaj). Mimochodem, vstupy maji zcela samostatne tagovani (entrance).
    *** Tady ume(lec. Vazby adres a budov M:N nejsou vazby chybové, ale zcela reálné pr(ípustné a pouz(ívané. Pro 1:N se stac(í mrknou do katastru a zpu*sobu zakreslování budov, pro M:1 stac(í mrknout na addr Brna. Jak známo, to z(e to ne(která mapa nezobrazuje není chyba dat. Co se tyce asociace budovy s adresnim bodem, existuje nejjednodussi prostory dotaz: "Uvnitr( které building:polygon lezi addr:nod?"
    Ktery v 90% pripadu nebude knicemu, protoze adresni bod lezi zcela mimo nebo ve spatne budove. Jen v praglu letnanech sem co si pamatuju videl adresy klido o 100 a vic metru mimo. A to neni zadna vyjimka. Netvrdim pak, ze to je chybne, ale tvrdim, ze takovych budov je minimum, nehlede na to, ze i v tom katastru jsou ty adresy privazany k budovam a prave ta vazba je velmi podstatna informace. Ze nejde (zcela obecne) dat objektu vice stejnych tagu (mineno trebas vice tagu prave s adresou nebo vice tagu source, typ obchodu ...) je zasadni chyba OSM. A ne, strednikovani rozhodne neni dobrej napad, to je z hlediska tech dat tragedie.
  13. jzvc jzvc na tpfree.net #ma65152
    Ahoj!
    I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým objektem, který v mapě už je - a turistická známka by měla být jen další informací o takovém objektu.
    No nevim, tohle zavani tim ze se import nikdy neudela. Myslim ze samostatne body nejsou zadny velky problem... jednodussi na import, jednodussi na udrzovani, nevyhody zadne. Pavel
    Bordel v datech - nejsi schopen nijak logicky ani automaticky priradit tu informaci prislusnymu objektu. Rekneme ze se to vztahuje k hradu a rekneme, ze si sosnes do svy navigace vsechny hrady, s veskerejma informacema => tohle mit nebudes, protoze to tam proste neni. Za me lepsi zadna data nez zabordelena data.
  14. Marián Kyral mkyral na email.cz #m0cc63d
    Ahoj!
    I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým objektem, který v mapě už je - a turistická známka by měla být jen další informací o takovém objektu.
    No nevim, tohle zavani tim ze se import nikdy neudela. Myslim ze samostatne body nejsou zadny velky problem... jednodussi na import, jednodussi na udrzovani, nevyhody zadne. Pavel
    Bordel v datech - nejsi schopen nijak logicky ani automaticky priradit tu informaci prislusnymu objektu. Rekneme ze se to vztahuje k hradu a rekneme, ze si sosnes do svy navigace vsechny hrady, s veskerejma informacema => tohle mit nebudes, protoze to tam proste neni. Za me lepsi zadna data nez zabordelena data. _____________" Stejně tak tak nebudeš mít ani adresní body - nejsou součástí objektu. Když tak nad tím uvažuji, mně je nakonec celkem jedno, jestli budou TZ samostatně nebo součástí objektu. Import bych stejně udělal jako samostatné body a ty by se pak musely manuálně sloučit se souvisejícími objekty. Update by pak aktualizoval pouze data relevantní pro TZ, souřadnice objektu bych neupravoval. Výstupem aktualizace by pak byl seznam změněných objektů, který by mohl být automaticky zaslán do této konference na revizi. Konkrétně přiřazení objektů pro nově vytvořené TZ. Jediný problém mám s tagy. V podstatě všechny mohou kolidovat. Takže by TZ musely mít speciální tagy: name:tz= description:tz= ref:tz= source:tz= Jenže třeba description:tz v podstatě znamená, že description je v jazyce "tz". To zase může někde udělat zmatek. V tom lepším případě se to prostě na mapě nezobrazí, protože jazyk "tz" neexistuje. Marián "__________________________________
  15. LM_1 flukas.robot+osm na gmail.com #mf6be54
    Souhlasím, že sloučení může proběhnout manuálně a postupně - je to mnohem jednodušší činnost než dohledávat názvy a čísla - takto se jen zkopírují tagy. Ohledně name:tz apod bych se spíš přikláněl k tz:name a míst tz něco globálnějšího (tourist_stamp?, ts?) LM_1
  16. Václav Kubíček vase.k na centrum.cz #m27b5dd
    Já jsem pro body, když už někam jdu, tak si stáhnu spíš všechny TZ. Navíc k čemu pak navázat nenavázatelné, např. namátkou: Naučná stezka Prameny Morávky, Brněnské podzemí atd. Vašek
  17. Pavel Machek pavel na ucw.cz #ma5b0e0
    Ahoj!
    I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým objektem, který v mapě už je - a turistická známka by měla být jen další informací o takovém objektu.
    No nevim, tohle zavani tim ze se import nikdy neudela. Myslim ze samostatne body nejsou zadny velky problem... jednodussi na import, jednodussi na udrzovani, nevyhody zadne. Pavel
    Bordel v datech - nejsi schopen nijak logicky ani automaticky priradit tu informaci prislusnymu objektu.
    No, rekneme ze aktualne neni mozne logicky ani automaticky priradit ulici ke mestu do ktereho patri... coz mi prijde jako podstatne zavaznejsi nez to, ze stejny problem maji turisticke znamky. U tech stejne bude jedine vyuziti "zobrazi se v turisticke mape". A protoze to nejde automaticky, zjevne jsou nutne dva kroky, jak bylo psano v dalsim mailu... a prvni z nich je import jako body. Pavel
  18. Milan Vancura milan na ucw.cz #m38f7e0
    Ahoj všem. Přiznávám, překvapuje mě, že v tak základní věci (co se týče typu dat) není shoda ani po tolika letech projektu. Pořád jsem čekal, co napíší zkušenější, ale teď mám pocit, že už se téma začíná rozmělňovat do detailů, a tak se ozývám, než se úplně rozdrobí do ztracena (stejně jako např. téma tagování českých škol nedávno, toho je velká škoda).
    Rekneme ze se to vztahuje k hradu a rekneme, ze si sosnes do svy navigace vsechny hrady, s veskerejma informacema => tohle mit nebudes, protoze to tam proste neni. Za me lepsi zadna data nez zabordelena data.
    Stejně tak tak nebudeš mít ani adresní body - nejsou součástí objektu.
    Ano, a spousta dalších dotazů. Např. POI a jeho adresa, třeba obchody. Jsou separátní nody. A co teprve pokud je obchod celá budova. Ano, pak nelze udělat rozumný automatický dotaz ani tak základní a přirozený jako "adresa obchodu". Jenže, pokud se nepletu, tohle nevyřešíme globálně, protože to plyne ze samotného designu dat OSM:
    Jediný problém mám s tagy. V podstatě všechny mohou kolidovat. Takže by TZ musely mít speciální tagy: name:tz= description:tz= ref:tz= source:tz=
    To je přesně ono - v datovém modelu OSM nelze mít k jednomu objektu (jakémukoliv) více nezávislých _sad tagů_. Takže to musí skončit nějakou obezličkou. A než středníky, ":tz" apod., tak mi přijde jednoznačně lepší mít separátní nody pro separátní sady vlastností. A hlavně už je toto řešení použito v OSM (ve všech zemích) tolikrát, že ani nevidím smysl, proč pro jeden detail (turistické známky) se najednou tvářit, že zachráním svět. Pokud někdo touží zachránit/vylepšit OSM svět, ať prosadí standardní rozšíření datového modelu OSM. Pak na něj můžeme přecházet. A ne, to není odmítnutí dobrých snah a dobrých připomínek, to myslím zcela vážně. Hodnotu to má až standardizované. Plus samozřejmě pro turistické známky platí i všechny praktické argumenty zmíněné v minulých mailech ostatními: snadnost importu a jeho změn v budoucnu a hlavně že nebudeme muset řešit typy známkových míst - např. když nelze TZ místo přiřadit jednoznačně (Brněnské podzemí). Milan Vančura
  19. Marián Kyral mkyral na email.cz #mad5c43
    Ahoj, Milan Vančura
  20. Tomáš Tichý t.tichy na post.cz #mf08c83
    A co importovat známky jako relace? Jednak má známka obvykle vlastní objekt - zajímavost a pak několik prodejních míst, které by se dala také do relace přidat. A také by se tím vyřešil problém s dvojím tagováním, protože tagy tz by byly na relaci a nemusel by se vymýšlet žádný podivný prefix / sufix. TT
  21. LM_1 flukas.robot+osm na gmail.com #m30bcf3
    Adresy v cizině, které jsem zatím viděl, jsou obvykle přímo na budově - budova má jen jedno číslo, ne jak u nás popisné + 0-n orientačních čísel a 0-n ulic... Import známek jako relací by se mi osobně líbil. Akorát bych nevěděl, jaký objekt vložit hned při importu - musel by být hned označený přesný obchod/atrakce... LM_1
  22. Tomáš Tichý t.tichy na post.cz #m4ed164
    Při importu by mohl být v relaci jediný provizorní bod označený nějakým FIXME. TT
    Import známek jako relací by se mi osobně líbil. Akorát bych nevěděl,
    jaký objekt vložit hned při importu - musel by být hned označený přesný obchod/atrakce...
    LM_1
    A co importovat známky jako relace? Jednak má známka obvykle vlastní
    objekt - zajímavost a pak několik prodejních míst, které by se dala také do relace přidat. A také by se tím vyřešil problém s dvojím tagováním, protože tagy tz by byly na relaci a nemusel by se vymýšlet žádný podivný prefix / sufix.
    TT
    Ahoj,
    Ahoj všem. Přiznávám, překvapuje mě, že v tak základní věci (co se týče typu dat)
    není
    shoda ani po tolika letech projektu. Pořád jsem čekal, co napíší
    zkušenější,
    ale teď mám pocit, že už se téma začíná rozmělňovat do detailů, a tak
    se
    ozývám, než se úplně rozdrobí do ztracena (stejně jako např. téma
    tagování
    českých škol nedávno, toho je velká škoda).
    Abych řekl pravdu, tak pořád čekám, jak se k tomu vyjádří matadoři.
    Osobně jsem v OSM pořád nováček ;-)
    Má někdo přehled jak to je v okolních zemích? Zkoušel jsem nějaké
    dotazy před overpass turbo. Primárně sice zaměřené na Česko, ale do obdelníku se mi samozřejmě dostala i data z okolních zemí. Někde mají adresu přímo na budově.
    Pokud chci následně import TZ rozšířit na ostatní státy, tak by bylo
    dobré brát v potaz i tamní zvyklosti a výsledné řešení udělat jako kompromis těchto přístupů.
    Existuje něco jako talk-eu? Nebo mám na wiki založit stránku s návrhem
    importu? Jak říkám, nemám zkušenosti s tím, jak to funguje.
    Rekneme ze se to vztahuje k hradu a rekneme, ze si sosnes do svy navigace vsechny hrady, s veskerejma informacema => tohle mit
    nebudes,
    protoze to tam proste neni. Za me lepsi zadna data nez zabordelena data.
    Stejně tak tak nebudeš mít ani adresní body - nejsou součástí
    objektu.
    Ano, a spousta dalších dotazů. Např. POI a jeho adresa, třeba obchody.
    Jsou
    separátní nody. A co teprve pokud je obchod celá budova. Ano, pak
    nelze udělat
    rozumný automatický dotaz ani tak základní a přirozený jako "adresa
    obchodu".
    Jenže, pokud se nepletu, tohle nevyřešíme globálně, protože to plyne ze samotného designu dat OSM:
    Jediný problém mám s tagy. V podstatě všechny mohou kolidovat. Takže
    by TZ
    musely mít speciální tagy: name:tz= description:tz= ref:tz= source:tz=
    To je přesně ono - v datovém modelu OSM nelze mít k jednomu objektu (jakémukoliv) více nezávislých _sad tagů_. Takže to musí skončit
    nějakou
    obezličkou. A než středníky, ":tz" apod., tak mi přijde jednoznačně
    lepší mít
    separátní nody pro separátní sady vlastností. A hlavně už je toto
    řešení
    použito v OSM (ve všech zemích) tolikrát, že ani nevidím smysl, proč
    pro jeden
    detail (turistické známky) se najednou tvářit, že zachráním svět. Pokud někdo touží zachránit/vylepšit OSM svět, ať prosadí standardní
    rozšíření
    datového modelu OSM. Pak na něj můžeme přecházet. A ne, to není
    odmítnutí
    dobrých snah a dobrých připomínek, to myslím zcela vážně. Hodnotu to
    má až
    standardizované. Plus samozřejmě pro turistické známky platí i všechny praktické
    argumenty
    zmíněné v minulých mailech ostatními: snadnost importu a jeho změn v
    budoucnu a
    hlavně že nebudeme muset řešit typy známkových míst - např. když nelze
    TZ místo
    přiřadit jednoznačně (Brněnské podzemí).
    To by až takový problém nebyl. Pokud se známka nedá přiřadit ke
    konkrétnímu objektu, tak by prostě zůstala jako samostatný bod.
  23. Marián Kyral mkyral na email.cz #mf02940
    Při importu by mohl být v relaci jediný provizorní bod označený nějakým FIXME. TT Nějak takto? <?xml version='1.0' encoding='UTF-8'?> <osm version='0.6' upload='true' generator='JOSM'> <bounds minlat='49.6432347' minlon='18.2627535' maxlat='49.6524321' maxlon ='18.2799196' origin='CGImap 0.1.0' /> <node id='-1910' action='modify' visible='true' lat='49.6491222222' lon= '18.2709777778'> <tag k='fixme' v='Do této relace prosím vložte body relevantní pro turistickou známku 1472: Rozhledna Panorama a pak tento dočasný bod z relace smažte' /> </node> <relation id='-1918' action='modify' visible='true'> <member type='node' ref='-1910' role='fixme' /> <tag k='attraction' v='tourist_stamp' /> <tag k='description' v='ROZHLEDNY; Beskydské informační centrum Frýdek' /> <tag k='name' v='TZ 1472: Rozhledna Panorama' /> <tag k='ref' v='TSCZ:1472' /> <tag k='source' v='turisticke-znamky.cz' /> <tag k='tourism' v='attraction' /> <tag k='type' v='tourist_stamp' /> <tag k='website' v='http://www.turisticke-znamky.cz/znamka_.php?id=1472' /> </relation> </osm> Marián Dne 22.5.2013 17:26 "LM_1" <flukas.robot+osm na gmail.com
    Import známek jako relací by se mi osobně líbil. Akorát bych nevěděl, jaký
    objekt vložit hned při importu - musel by být hned označený přesný obchod/ atrakce...
    LM_1 Dne 22. května 2013 16:54 Tomáš Tichý <t.tichy na post.cz
    A co importovat známky jako relace? Jednak má známka obvykle vlastní
    objekt - zajímavost a pak několik prodejních míst, které by se dala také do relace přidat. A také by se tím vyřešil problém s dvojím tagováním, protože tagy tz by byly na relaci a nemusel by se vymýšlet žádný podivný prefix / sufix.
    TT Dne 22.5.2013 16:41 "Marián Kyral" <mkyral na email.cz
    Ahoj,
    Ahoj všem. Přiznávám, překvapuje mě, že v tak základní věci (co se týče typu dat)
    není
    shoda ani po tolika letech projektu. Pořád jsem čekal, co napíší
    zkušenější,
    ale teď mám pocit, že už se téma začíná rozmělňovat do detailů, a tak
    se
    ozývám, než se úplně rozdrobí do ztracena (stejně jako např. téma
    tagování
    českých škol nedávno, toho je velká škoda).
    Abych řekl pravdu, tak pořád čekám, jak se k tomu vyjádří matadoři.
    Osobně jsem v OSM pořád nováček ;-)
    Má někdo přehled jak to je v okolních zemích? Zkoušel jsem nějaké dotazy
    před overpass turbo. Primárně sice zaměřené na Česko, ale do obdelníku se mi samozřejmě dostala i data z okolních zemí. Někde mají adresu přímo na budově.
    Pokud chci následně import TZ rozšířit na ostatní státy, tak by bylo
    dobré brát v potaz i tamní zvyklosti a výsledné řešení udělat jako kompromis těchto přístupů.
    Existuje něco jako talk-eu? Nebo mám na wiki založit stránku s návrhem
    importu? Jak říkám, nemám zkušenosti s tím, jak to funguje.
    Rekneme ze se to vztahuje k hradu a rekneme, ze si sosnes do svy navigace vsechny hrady, s veskerejma informacema => tohle mit
    nebudes,
    protoze to tam proste neni. Za me lepsi zadna data nez zabordelena data.
    Stejně tak tak nebudeš mít ani adresní body - nejsou součástí
    objektu.
    Ano, a spousta dalších dotazů. Např. POI a jeho adresa, třeba obchody.
    Jsou
    separátní nody. A co teprve pokud je obchod celá budova. Ano, pak nelze
    udělat
    rozumný automatický dotaz ani tak základní a přirozený jako "adresa
    obchodu".
    Jenže, pokud se nepletu, tohle nevyřešíme globálně, protože to plyne ze samotného designu dat OSM:
    Jediný problém mám s tagy. V podstatě všechny mohou kolidovat. Takže
    by TZ
    musely mít speciální tagy: name:tz= description:tz= ref:tz= source:tz=
    To je přesně ono - v datovém modelu OSM nelze mít k jednomu objektu (jakémukoliv) více nezávislých _sad tagů_. Takže to musí skončit
    nějakou
    obezličkou. A než středníky, ":tz" apod., tak mi přijde jednoznačně
    lepší mít
    separátní nody pro separátní sady vlastností. A hlavně už je toto
    řešení
    použito v OSM (ve všech zemích) tolikrát, že ani nevidím smysl, proč
    pro jeden
    detail (turistické známky) se najednou tvářit, že zachráním svět. Pokud někdo touží zachránit/vylepšit OSM svět, ať prosadí standardní
    rozšíření
    datového modelu OSM. Pak na něj můžeme přecházet. A ne, to není
    odmítnutí
    dobrých snah a dobrých připomínek, to myslím zcela vážně. Hodnotu to má
    až
    standardizované. Plus samozřejmě pro turistické známky platí i všechny praktické
    argumenty
    zmíněné v minulých mailech ostatními: snadnost importu a jeho změn v
    budoucnu a
    hlavně že nebudeme muset řešit typy známkových míst - např. když nelze
    TZ místo
    přiřadit jednoznačně (Brněnské podzemí).
    To by až takový problém nebyl. Pokud se známka nedá přiřadit ke
    konkrétnímu objektu, tak by prostě zůstala jako samostatný bod.
  24. Marián Kyral mkyral na email.cz #m1f0515
    Tak jsem spáchal první verzi importního skriptu. Výstup pro kategorii BESKYDY lze stáhnout tady: http://www.kyralovi.cz/tmp/tz_beskydy.osm Stačí stáhnout a otevřít v josm. Následně pak jdou přidat další vrstvy a klasicky dotáhnout relevantní data z OSM. Můžete si třeba zkusit doplnit nějakou relaci. Otestuje a dejte vědět co vylepšit (a jestli to je vůbec ono). V souboru jsou následující kategorie: ARCHEO BEROUNKA BESKYDY BÍLÉ KARPATY BROUMOVSKÉ MEZIHOŘÍ CÍRKEVNÍ PAMÁTKY ČESKÉ STŘEDOHOŘÍ ČESKÝ LES ČESKÝ RÁJ (www.rajnet.cz) HISTORICKÁ MĚSTA HISTORICKÉ PIVOVARY HOSTÝNSKÉ VRCHY HRADY CHKO CHŘIBY JAVORNÍKY JESENÍKY JESKYNĚ A PROPASTI JESTŘEBÍ HORY JEŠTĚDSKÝ HŘBET JIHLAVSKÉ VRCHY JIZERSKÉ HORY Karviná KRKONOŠE KRUŠNÉ HORY LABSKÉ PÍSKOVCE LITOVELSKÉ POMORAVÍ LUŽICKÉ HORY LUŽNICE MORAVSKÝ KRAS NÁRODNÍ PARK ČESKÉ ŠVÝCARSKO NEZAŘAZENO NOVOHRADSKÉ HORY OHŘE ORLICKÉ HORY OTAVA PAMÁTNÍKY RALSKÁ PAHORKATINA ROZHLEDNY RYCHLEBSKÉ HORY SÁZAVA SKANZENY A MUZEA SKUPINA KRALICKÉHO SNĚŽNÍKU SLAVKOVSKÝ LES ŠUMAVA TECHNICKÉ PAMÁTKY VÁLEČNÉ PAMÁTNÍKY VINAŘSKÉ OBCE VLTAVA VSETÍNSKÉ VRCHY WESTERN ZÁMKY ZOOLOGICKÉ ZAHRADY ŽĎÁRSKÉ VRCHY ŽELEZNÉ HORY Předpokládám, že import se bude dělat po kategoriích. Zatím jsem nezjiťoval, kolik je v každé známek. Marián
  25. Marián Kyral mkyral na email.cz #mcc709c
    Na http://www.kyralovi.cz/tmp/all.zip lze stáhnout soubor obsahující všechny CZ známky. Když si to člověk otevře, dostane krásnou slepou mapu republiky ; -) Mám trochu problém s klíčem "description". Dle validátoru nesmí být jeho hodnota delší než 119 znaků. Takže zamýšlená konstrukce neprojde. description="CATEGORY; prodejní_místo_1 (www1); prodejní_místo_2 (www2);... prodejní_místo_13 (www13);" Potřebuji to nějak rozdělit do více řádků. Něco jako ts_category= ts_sales_point_1= ts_sales_point_2= ts_sales_point_3= ... ts_sales_point_13= Marián
  26. hanoj ehanoj na gmail.com #mc627c6
    Přiznávám, překvapuje mě, že v tak základní věci (co se týče typu dat) není shoda ani po tolika letech projektu. Pořád jsem čekal, co napíší zkušenější, ale teď mám pocit, že už se téma začíná rozmělňovat do detailů, a tak se ozývám, než se úplně rozdrobí do ztracena (stejně jako např. téma tagování českých škol nedávno, toho je velká škoda).
    *** Záleží co si představuješ za shodu, asi ne jednotné hlasování jako KSSS ;) Přesto "adresní body" fungují jako nody od počátku OSM (s menší přetržkou díky jednomu pluginu), třídění škol funguje beze změn od počátku OSM. hanoj
  27. Marián Kyral mkyral na email.cz #m2dd4ca
    Tak jsem teď čirou náhodou narazil na: http://wiki.openstreetmap.org/wiki/Proposed_features/Checkpoint_for_Tourism Ony vlastně turistické známky jsou v podstatě totéž. Dokládají, že turista na daném místě byl*, protože jinde daná známka nejde koupit a poštou ji zašlou pouze oproti nějakému důkazu (vstupenka, fotka). *) Ne vždy se daná známka prodává přímo na místě (například některé vrcholy bez chaty), takže někomu stačí dorazit na nejbližší prodejní místo a na místo samé už pak ani nejde. Ovšem tag by se musel rozšířit: checkpoint=tourist checkpoint:type=tourist_stamp checkpoint:category:cz=Pohoří checkpoint:sales_place_1=IC aa checkpoint:sales_place_web_13=http://ic.xx.cz .... checkpoint:sales_place_13=IC aa checkpoint:sales_place_web_13=http://ic.xx.cz Co myslíte? Marián
  28. Jakub Sykora kubajz na kbx.cz #ma0f829
    Za me dobry :-)
  29. Marián Kyral mkyral na email.cz #mefc579
    Sice teď nějak nestíhám, ale dovolil bych si to shrnout: Turistická známka bude zadávána jako relace (type=checkpoint). Uvnitř bude minimálně jeden člen definující turistickou atrakci (role=attraction), ke které se daná známka vztahuje. Další členové jsou nepovinní a označují prodejní místa (role=sales_point). Během importu se vytvoří relace popisující turistickou známku a dočasný bod, který bude následně ručně spárovat se skutečným objektem. Pokud konkrétní bod neexistuje, změní se dočasný bod na trvalý. Bude označen jako tourism= attraction. Pokud se známka neprodává nikde jinde než v místě, nebude prvek s rolí "sales_point" přiřazen. Předpokládá se, že známka se prodává na atrakci. (ekvivalent: checkpoint:sales_point=yes) (Případně neměl by být prvek přidán dvakrát, pokaždé s jinou rolí?. JOSM má sice námitky, ale nechá se přesvědčit a takovou relaci vytvoří.) Naopak, pokud se v místě atrakce turistická známka neprodává, bude prvku atrakce přiřazen klíč checkpoint:sales_point=no Shrnutí klíčů: 1) Relace type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=123. Rozhledna XYZ checkpoint:category:cz=Rozhledny checkpoint:sales_point:1=IC aa checkpoint:sales_point:web:1=http://ic.aa.cz .... checkpoint:sales_point:13=IC xx checkpoint:sales_point:web:13=http://ic.xx.cz ref=TSCZ:123 source=turisticke-znamky website=http://www.turisticke-znamky.cz/znamka_.php?id=123 2) Dočasný bod tourism=attraction name=Rozhledna XYZ source=turisticke-znamky fixme=Dočasný bod relace turistické známky 123. Rozhledna XYZ. Opravte prosim dle pokynů na http://wiki.openstreetmap.org/wiki/XXX Příklady: 1) Situace po importu Bod) tourism=attraction name=Praděd 1491m source=turisticke-znamky fixme=Dočasný bod relace turistické známky 1. Praděd 1491m. Opravte prosim dle pokynů na http://wiki.openstreetmap.org/wiki/XXX role=attraction (v relaci) Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=1. Praděd 1491m checkpoint:category:cz=Jeseníky checkpoint:sales_point:1=Restaurace Praděd checkpoint:sales_point:web:1=http://www.hotelpraded.cz/ref=TSCZ:1 source=turisticke-znamky website=http://www.turisticke-znamky.cz/znamka_.php?id=1 2) Známka se prodává v místě atrakce a na několika dalších místech Bod) tourism=attraction name=Karlova Studánka source=turisticke-znamky fixme=Dočasný bod relace turistické známky 3. Karlova Studánka. Opravte prosim dle pokynů na http://wiki.openstreetmap.org/wiki/XXX role=attraction (v relaci) Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky checkpoint:sales_point:1=Infocentrum Impuls, 793 24 Karlova Studánka 59 checkpoint:sales_point:web:1=http://www.k.studanka.cz checkpoint:sales_point:2=Občerstvení U vodopádu, Karlova Studánka checkpoint:sales_point:web:2=http://www.kstudanka.cz checkpoint:sales_point:3=Lázeňský dům Libuše - recepce, Karlova Studánka checkpoint:sales_point:web:3=http://k.studanka.cz checkpoint:sales_point:4=Cukrárna Roman Korytar checkpoint:sales_point:5=Minimarket Roja, Karlova Studánka checkpoint:sales_point:6=Geologická sbírka Jeseníků checkpoint:sales_point:web:6=http://www.ejeseniky.com ref=TSCZ:3 source=turisticke-znamky website=http://www.turisticke-znamky.cz/znamka_.php?id=3 3) Známka se prodává pouze v místě atrakce Bod) tourism=alpine_hut name=Chata Rozhled source=turisticke-znamky website=http://www.chatarozhled.cz role=attraction (v relaci) Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=14. Rozhled checkpoint:category:cz=Krkonoše ref=TSCZ:14 source=turisticke-znamky website=http://www.turisticke-znamky.cz/znamka_.php?id=14 4) Známka je dostupná pouze na prodejních místech, není v místě atrakce. Bod) tourism=attraction amenity=place_of_worship religion=christian building=chapel name=Lískovec u Frýdku - Místku, Kaplička v Hájku source=turisticke-znamky checkpoint:sales_point=no role=attraction (v relaci) Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=1512. Lískovec u Frýdku - Místku, Kaplička v Hájku checkpoint:category:cz=Církevní památky checkpoint:sales_point:1=Beskydské informační centrum Frýdek checkpoint:sales_point:2=Beskydské informační centrum Místek ref=TSCZ:1512 source=turisticke-znamky website=http://www.turisticke-znamky.cz/znamka_.php?id=1512 Mám dotaz: Nepřeháním to s těmi dvojtečkami? Není na to nějaké omezení? Přiznám se, že jsem moc nehledal, ale JOSM neprotestuje. checkpoint:sales_point:2=Občerstvení U vodopádu, Karlova Studánka checkpoint:sales_point:web:2=http://www.kstudanka.cz Zdrojové kódy skriptu pro prvotní import jsem dal na Github: https://github.com/mkyral/osm Určitě to není bezchybné, ale zatím to funguje ;-) Skript pro aktualizaci plánuji až po dokončení úvodního importu (nebo alespoň první části). Přece jen se lépe pracuje se skutečnými daty. Vygeneroval jsem .osm soubory s novým nastavením: http://www.kyralovi.cz/tmp/tscz_all.zip - úplně všechny CZ známky v jednom souboru http://www.kyralovi.cz/tmp/tscz_cat.zip - samostatný soubor pro každou kategorii plus extra Praha, Brno, Ostrava. Prosím o otestování. Stačí otevřít v josm a zkusit si namapování na konkrétní místa. Budu rád za každý feedback. Vypadá to dobře, ale třeba mohyla Ivančena v Beskydech celkem ustřelila: ve Frýdlantu n.O. rozhodně není ;-) Ale to se opraví při mapování. Možná by bylo dobré takovéto výrazné odlišnosti sepsat a poslat na turisticke-znamky.cz. Třeba to opraví. Další kroky: 1) Založit stránku s popisem importu na wiki 2) Kontaktovat osm_sk a zjistit, jak to vidí oni 3) Vytvořit vlákno na https://help.openstreetmap.org/ - totéž co SK. Marián
  30. hanoj ehanoj na gmail.com #mcb66ec
    Sice teď nějak nestíhám, ale dovolil bych si to shrnout: Turistická známka bude zadávána jako relace (type=checkpoint). Uvnitř bude minimálně jeden člen definující turistickou atrakci (role=attraction), ke které se daná známka vztahuje. Další členové jsou nepovinní a označují prodejní místa (role=sales_point). Během importu se vytvoří relace popisující turistickou známku a dočasný bod, který bude následně ručně spárovat se skutečným objektem. Pokud konkrétní bod neexistuje, změní se dočasný bod na trvalý. Bude označen jako tourism=attraction. Pokud se známka neprodává nikde jinde než v místě, nebude prvek s rolí "sales_point" přiřazen. Předpokládá se, že známka se prodává na atrakci. (ekvivalent: checkpoint:sales_point=yes) (Případně neměl by být prvek přidán dvakrát, pokaždé s jinou rolí?. JOSM má sice námitky, ale nechá se přesvědčit a takovou relaci vytvoří.)
    *** Zásadně se mi nelíbí, že 1) import má 2000 relací a v každé je jeden bod 2) každý bod má fixme Je třeba opustit iluzi, že "se to" postupně opraví a doplní. Netvařme se, že jsme schopni mít lepší data než sám původce turistických známek (TZ). To prostě nefunguje, dodnes je v OSM spousta roky nedotažených importů a import TZ prezentuje ani ne polotovar. Import TZ má mít 2000 bodů bez relací a má být natolik konzistentní, aby byl bez fixme. ha hanoj
  31. Marián Kyral mkyral na email.cz #m421f79
    Sice teď nějak nestíhám, ale dovolil bych si to shrnout: Turistická známka bude zadávána jako relace (type=checkpoint). Uvnitř bude minimálně jeden člen definující turistickou atrakci (role=attraction), ke které se daná známka vztahuje. Další členové jsou nepovinní a označují prodejní místa (role=sales_point). Během importu se vytvoří relace popisující turistickou známku a dočasný
    bod,
    který bude následně ručně spárovat se skutečným objektem. Pokud konkrétní bod neexistuje, změní se dočasný bod na trvalý. Bude označen jako tourism=attraction. Pokud se známka neprodává nikde jinde než v místě, nebude prvek s rolí "sales_point" přiřazen. Předpokládá se, že známka se prodává na atrakci. (ekvivalent: checkpoint:sales_point=yes) (Případně neměl by být prvek
    přidán
    dvakrát, pokaždé s jinou rolí?. JOSM má sice námitky, ale nechá se přesvědčit a takovou relaci vytvoří.)
    *** Zásadně se mi nelíbí, že 1) import má 2000 relací a v každé je jeden bod 2) každý bod má fixme Je třeba opustit iluzi, že "se to" postupně opraví a doplní. Netvařme se, že jsme schopni mít lepší data než sám původce turistických známek (TZ). To prostě nefunguje, dodnes je v OSM spousta roky nedotažených importů a import TZ prezentuje ani ne polotovar. OK. Toto je verze vzniklá na základě zdejší diskuze. Bohužel bez ručního spárování to nejde. Jméno TZ málokdy přesně souhlasí se jménem daného objektu. Nevím, jak bych to tedy automaticky dohledával. Navíc, jak bylo zmíněno v diskuzi, některé známky ani konkrétní bod nemají. Jak to ve skriptu zjistit? V seznamu jsou kategorie (třeba Hrady a zámky, rozhledny), ale taky tam jsou oblasti (Jeseníky, český ráj...), které obsahují všechny známky z dané oblasti a jsou různých typů. Takže tam jsou jak Prachovské skály, tak i hrad Kost nebo zámek Humprecht. Z kategorie "Český ráj" nelze vydedukovat, jaký typ bodu v okolí se má hledat. Navíc nápad s relacemi se mi líbí. Vyřeší se tím problém s kolizemi (name, website, ref, tourism...). A možnost mít v relaci i konkrétní místa prodeje je podle mně výhoda. To že TZ neposkytují  přesné souřadnice by nás přece nemělo zastavit. Pokud to naimportuji jako samostatné body a následně budu chtít přidat i místo kde se známka prodává? Musím pak tu relaci vytvořit manuálně? Nebo mám smůlu a relaci vytvořit nesmím, tedy tato informace nebude dostupná? U předchozích importů jsem nebyl a nevím jak probíhaly. Když jsem se ptal na zkušenosti s importy a jak to správně udělat, nikdo zkušený se neozval. Import TZ má mít 2000 bodů bez relací a má být natolik konzistentní, aby byl bez fixme. Když mi poradíš  jak, tak se to pokusím zrealizovat. Jak jsem psal, import můžu udělat po menších částech a postupně jej manuálně spárovat. V rámci testů jsem si pár bodu zkusil a jde to celkem dobře. U nějaké rozhledny jsem dokonce narazil na dva oddělené body kousek od sebe. Jeden tagovaný jako věž a druhý jako rozhledna. Ty by se určitě daly spojit (a data se tak i pročistí). Chci vylepšit OSM a myslím, že TZ je jedna z věcí, která hodně vylepší turistické mapy. Když jsem zjišťoval, jak takový import probíhá, nabyl jsem dojmu, že to bude fuška. No nemýlil jsem se. Abych řekl pravdu, vůbec se nedivím, že ty komíny nakonec nikdo nenaimportoval, i když zdroj a souhlas s užitím máme. Marián ha hanoj
  32. Milan Vancura milan na ucw.cz #mb9a081
    Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky checkpoint:sales_point:1=Infocentrum Impuls, 793 24 Karlova Studánka 59 checkpoint:sales_point:web:1=http://www.k.studanka.cz checkpoint:sales_point:2=Občerstvení U vodopádu, Karlova Studánka checkpoint:sales_point:web:2=http://www.kstudanka.cz checkpoint:sales_point:3=Lázeňský dům Libuše - recepce, Karlova Studánka checkpoint:sales_point:web:3=http://k.studanka.cz checkpoint:sales_point:4=Cukrárna Roman Korytar checkpoint:sales_point:5=Minimarket Roja, Karlova Studánka checkpoint:sales_point:6=Geologická sbírka Jeseníků checkpoint:sales_point:web:6=http://www.ejeseniky.com Mám dotaz: Nepřeháním to s těmi dvojtečkami? Není na to nějaké omezení? Přiznám se, že jsem moc nehledal, ale JOSM neprotestuje.
    Zdravím, mně se to s těmi dvojtečkami nelíbí. Vždyť je to relace a relace je tu od toho, aby měla členy, ne? Tak proč to nahrazovat spoustou dvojtečkovaných atributů? To bych chápal maximálně jako FIXME. A ve výsledku by objekty (výše tedy Infocentrum Impuls, Občerstvení U vodopádu, Lázeňský dům Libuše...) měly být členem relace, s typem "sales_point". Milan Vančura
  33. Marián Kyral mkyral na email.cz #m269f20
    Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky checkpoint:sales_point:1=Infocentrum Impuls, 793 24 Karlova Studánka 59 checkpoint:sales_point:web:1=http://www.k.studanka.cz checkpoint:sales_point:2=Občerstvení U vodopádu, Karlova Studánka checkpoint:sales_point:web:2=http://www.kstudanka.cz checkpoint:sales_point:3=Lázeňský dům Libuše - recepce, Karlova Studánka checkpoint:sales_point:web:3=http://k.studanka.cz checkpoint:sales_point:4=Cukrárna Roman Korytar checkpoint:sales_point:5=Minimarket Roja, Karlova Studánka checkpoint:sales_point:6=Geologická sbírka Jeseníků checkpoint:sales_point:web:6=http://www.ejeseniky.com Mám dotaz: Nepřeháním to s těmi dvojtečkami? Není na to nějaké omezení? Přiznám se, že jsem moc nehledal, ale JOSM neprotestuje.
    Zdravím, mně se to s těmi dvojtečkami nelíbí. Vždyť je to relace a relace je tu od toho, aby měla členy, ne? Tak proč to nahrazovat spoustou dvojtečkovaných atributů? To bych chápal maximálně jako FIXME. A ve výsledku by objekty (výše tedy Infocentrum Impuls, Občerstvení U vodopádu, Lázeňský dům Libuše...) měly být členem relace, s typem "sales_point". Milan Vančura No to mělo. Ovšem nějak tam ta data potřebuji napoprvé dostat abych následně mohl přiřadit (vytvořit) další členy relace. A stejně, pokud všechny tyto body převedu na skutečné objekty a zařadím je do relace, potřebuji je nějak identifikovat s ohledem na předpokládané aktualizace. Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu mít klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí "sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám. Muselo by to být nějak zakódováno přímo u daného prodejního místa, třeba ref =TSCZ:3:SP1, ale to by zase mohlo kolidovat s už existujícím ref. Stejně pak ale musím mít možnost poznat, že se třeba změnila adresa. A to buď tak, že tam bude celý řetězec ("Infocentrum Impuls, 793 24 Karlova Studánka 59"), nebo nějaký hash (třeba md5) či kontrolní číslici. A totéž musí být i pro web adresu (pokud existuje). To ale znamená, že jak ref, tak i hash pro jméno a website musí být přiřazeno danému objektu. A musí to být přiřazeno ručně -> práce navíc a dají se v tom udělat chyby. A třeba spočítat hash asi každý neumí. Navíc se pak kdokoli může rozhodnout, že ty podivné tagy se mu nelíbí a smaže je -> update skript to bude hlásit jako nový objekt. Nějaký nápad? Marián
  34. Marián Kyral mkyral na email.cz #m095463
    Je třeba opustit iluzi, že "se to" postupně opraví a doplní. Netvařme se, že jsme schopni mít lepší data než sám původce turistických známek (TZ). To prostě nefunguje, dodnes je v OSM spousta roky nedotažených importů a import TZ prezentuje ani ne polotovar. Ještě dodám, že na rozdíl od těch nedotažených importů, plánuji napsat update skript. Který bude hlídat změny (nové známky, zrušené známky, aktualizované známky). A výstupem bude report ukazující co se změnilo a co je potřeba zkontrolovat/opravit. K tomu ale potřebuji aby byly TZ zaintegrovány s jasnými pravidly. Pak bude proces aktualizace a vygenerování reportu relativně jednoduchý. Ad Fixme) Pomocí Overpass turbo není problém z OSM databáze vytáhnout seznam TZ, které zatím nebyly zkontrolovány (mají fixme). Z toho pak už je celkem jednoduché vygenerovat nějaký report: --------------------------------------------- Celkem: 2010 Potřebuje kontrolu: 236 Hotovo: 88% TZ: 3. Karlova studánka (50.11221, 18.4431) TZ: 999. XXX (51.9986, 18.1512) ... --------------------------------------------- No a tohle můžu každý týden posílat do konference. Myslíš, že by tady někdo neměl nutkání to číslo srazit na 0? BTW, je někde seznam těch nedotažených importů, nejlépe s popisem, co je ještě potřeba dodělat? Marián
  35. Milan Vancura milan na ucw.cz #m784a4e
    No to mělo. Ovšem nějak tam ta data potřebuji napoprvé dostat abych následně mohl přiřadit (vytvořit) další členy relace.
    Tomu rozumím, proto jsem navrhoval FIXME. Ale ještě lépe to udržovat mimo a nezaplevelovat mapu. Pak by se totiž mohlo snadno stát, že nějakou dobu bude malé procento převedeno na skutečné objekty a renderery už začnou brát data z FIXME tagů - a bordelbude dokonán.
    A stejně, pokud všechny tyto body převedu na skutečné objekty a zařadím je do relace, potřebuji je nějak identifikovat s ohledem na předpokládané aktualizace.
    Jasně. O důvod víc to držet mimo, pro ostatní dostupné třeba přes wiki, ve formátu pro to vhodném, třeba s těmi identifikátory, jak o nich píšeš níže.
    Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych
    Tak website a jiné atributy jsou záležitostí toho objektu, do toho se nemusí TZ míchat.
    nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu mít klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí "sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám.
    Tady nerozumím té argumentaci: jako že nebude tak snadno dostupná třeba adresa? Protože jinak v těch atributech nevidím žádnou výhodu. Akorát musíš navíc řešit pořadí a jeho změny. Takže souhlasím s tebou, že by bylo nejlepší vymyslet nějaký systém identifikátorů ("ID") a ten přiřadit členům relace, aby pro příště bylo snadné poznat, jestli se změnil objekt nebo ne. Rozhodně bych do toho identifikátoru nezapočítaval nic jako website z důvodů uvedených výše. Asi to chce promyslet víc pečlivě, ale přijde mi to rozhodně jako krok správným směrem. Vyrábět v OSM seznamy pomocí dvojteček je fakt nestandardní a jde to proti datovému modelu. Milan
  36. Marián Kyral mkyral na email.cz #m9f722d
    No to mělo. Ovšem nějak tam ta data potřebuji napoprvé dostat abych
    následně
    mohl přiřadit (vytvořit) další členy relace.
    Tomu rozumím, proto jsem navrhoval FIXME. Ale ještě lépe to udržovat mimo a nezaplevelovat mapu. Pak by se totiž mohlo snadno stát, že nějakou dobu bude malé procento převedeno na skutečné objekty a renderery už začnou brát data z FIXME tagů - a bordelbude dokonán. Jak mimo? Kde?
    A stejně, pokud všechny tyto body převedu na skutečné objekty a zařadím je
    do
    relace, potřebuji je nějak identifikovat s ohledem na předpokládané aktualizace.
    Jasně. O důvod víc to držet mimo, pro ostatní dostupné třeba přes wiki, ve formátu pro to vhodném, třeba s těmi identifikátory, jak o nich píšeš níže. Jako, že bych každá TZ měla wiki stránku s dalšími údaji? To stejné je na http://www.turisticke-znamky.cz/znamka.php?id=1 Na to není potřeba nic extra vytvářet.
    Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych
    Tak website a jiné atributy jsou záležitostí toho objektu, do toho se nemusí TZ míchat. To jo, ale jak chceš identifikovat změnu? Mám někde schovávat poslední zpracovaný soubor a změny zjistit porovnáním starého souboru s novým? Tomu bych se chtěl právě vyhnout. Nedovedu si představit, jak by se to chovalo, pokud by třeba někdo spustil update, aktualizoval starý soubor,  ale změny nenahrál do OSM..
    nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu
    mít
    klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí "sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám.
    Tady nerozumím té argumentaci: jako že nebude tak snadno dostupná třeba adresa? Protože jinak v těch atributech nevidím žádnou výhodu. Akorát musíš navíc řešit pořadí a jeho změny. Takže souhlasím s tebou, že by bylo nejlepší vymyslet nějaký systém identifikátorů ("ID") a ten přiřadit členům relace, aby pro příště bylo snadné poznat, jestli se změnil objekt nebo ne. Rozhodně bych do toho identifikátoru nezapočítaval nic jako website z důvodů uvedených výše. Asi to chce promyslet víc pečlivě, ale přijde mi to rozhodně jako krok správným směrem. Vyrábět v OSM seznamy pomocí dvojteček je fakt nestandardní a jde to proti datovému modelu. Nejedná se přímo o adresu. Jde o jakoukoli změnu v prodejním místě. To, že je součástí i adresa je spíše výjimka než pravidlo. Nedělal jsem analýzu, jak často se prodejní místa mění, ale určitě k tomu dochází. Samotný identifikátor nestačí. A použití nějakého třetího zdroje obsahující mapování bych se pokud možno vyhnul. Dle mých zkušeností jsou s tím spíše problémy. Dříve nebo později se to stejně rozjede a pak je potřeba dělat nějakou synchronizaci. Což v tomto případě nebude jen tak a už vidím, jak se do toho někdo hrne. Nebyl by odkaz na povídání o těch dvojtečkách? Je to toto: http://wiki.openstreetmap.org/wiki/Namespace ? Byl to jen takový momentální nápad. Zdálo se mi, že to je lepší než: checkpoint:sales_point_1 checkpoint:sales_point_2 checkpoint:sales_point_3 Marián Milan
  37. hanoj ehanoj na gmail.com #m5bb409
    Bohužel bez ručního spárování to nejde. Jméno TZ málokdy přesně souhlasí se jménem daného objektu. Nevím, jak bych to tedy automaticky dohledával. Navíc, jak bylo zmíněno v diskuzi, některé známky ani konkrétní bod nemají. Jak to ve skriptu zjistit?
    *** Neříkám, že to jde automaticky. Jestli všechn 2000 TZ jsi _ty_ schopen projít a do 1/4 roku opravit do finální podoby, nemám s tím problém.
    Navíc nápad s relacemi se mi líbí. Vyřeší se tím problém s kolizemi (name, website, ref, tourism...). A možnost mít v relaci i konkrétní místa prodeje je podle mně výhoda. To že TZ neposkytují přesné souřadnice by nás přece nemělo zastavit.
    *** Nevím jestli je to výhoda, já bych to třeba oželel. Nekopírujeme do OSM svět 1:1 ale modelujeme ho, zjednodušujeme, aby s ním šlo pracovat. Máme třeba v OSM linky a zastávky, ale už ne jízdní řády. Ale možná jsem s názorem osamocen...
    Pokud to naimportuji jako samostatné body a následně budu chtít přidat i místo kde se známka prodává? Musím pak tu relaci vytvořit manuálně? Nebo mám smůlu a relaci vytvořit nesmím, tedy tato informace nebude dostupná?
    *** Nemusíš nic... já jsem psal, že se mi některé věci nelíbí ;)
    U předchozích importů jsem nebyl a nevím jak probíhaly. Když jsem se ptal na zkušenosti s importy a jak to správně udělat, nikdo zkušený se neozval.
    *** zatím postupuješ jako u všech předchozích uděláš krok vpřed a dáš vědět, takže OK. Nikdo ti není schopen poradit předem tak, aniž by ten import za tebe připravil nebo si to s tebou nenastudoval od A-Z.
    Chci vylepšit OSM a myslím, že TZ je jedna z věcí, která hodně vylepší turistické mapy. Když jsem zjišťoval, jak takový import probíhá, nabyl jsem dojmu, že to bude fuška. No nemýlil jsem se. Abych řekl pravdu, vůbec se nedivím, že ty komíny nakonec nikdo nenaimportoval, i když zdroj a souhlas s užitím máme.
    *** určitě si tvé práce cením. Je dobře, že to je náročné, protože pak není potřeba revertovat. To se zatím dělalo hromadně snad jen dvakrát. Poněkud neslavně dopadly s dočištěním waterway. ha hanoj
  38. Marián Kyral mkyral na email.cz #m6c5e17
    Bohužel bez ručního spárování to nejde. Jméno TZ málokdy přesně souhlasí se jménem daného objektu. Nevím, jak bych to tedy automaticky dohledával. Navíc, jak bylo zmíněno v diskuzi, některé známky ani konkrétní bod nemají. Jak to ve skriptu zjistit?
    *** Neříkám, že to jde automaticky. Jestli všechn 2000 TZ jsi _ty_ schopen projít a do 1/4 roku opravit do finální podoby, nemám s tím problém.
    No taky bych mohl dělat import po částech přes josm. To znamená, že by se do OSM žádné FIXME nedostalo. Nevím, jestli to stihnu během čtvrt roku. Záleží, jak na tom budou data. Teď jsem třeba narazil na hvězdárnu Karlovy Vary - v nístě je jen číslo popisné. Bude třeba přidat budovu a většinou neskončím jen u toho ;-)
    Navíc nápad s relacemi se mi líbí. Vyřeší se tím problém s kolizemi (name, website, ref, tourism...). A možnost mít v relaci i konkrétní místa prodeje je podle mně výhoda. To že TZ neposkytují přesné souřadnice by nás přece nemělo zastavit.
    *** Nevím jestli je to výhoda, já bych to třeba oželel. Nekopírujeme do OSM svět 1:1 ale modelujeme ho, zjednodušujeme, aby s ním šlo pracovat. Máme třeba v OSM linky a zastávky, ale už ne jízdní řády. Ale možná jsem s názorem osamocen...
    No i kdyby to bylo bez těch prodejních míst, pořád tady jsou kolize. Daná atrakce se nějak jmenuje, ale TZ se může jmenovat úplně jinak, ale v každém případě se před jméno dává číslo TZ. Muselo by se to řešit třeba přes klíč checkpoint:name.
    Pokud to naimportuji jako samostatné body a následně budu chtít přidat i místo kde se známka prodává? Musím pak tu relaci vytvořit manuálně? Nebo mám smůlu a relaci vytvořit nesmím, tedy tato informace nebude dostupná?
    *** Nemusíš nic... já jsem psal, že se mi některé věci nelíbí ;)
    Aha, tak to jsem si oddychl ;-)
    U předchozích importů jsem nebyl a nevím jak probíhaly. Když jsem se ptal na zkušenosti s importy a jak to správně udělat, nikdo zkušený se neozval.
    *** zatím postupuješ jako u všech předchozích uděláš krok vpřed a dáš vědět, takže OK. Nikdo ti není schopen poradit předem tak, aniž by ten import za tebe připravil nebo si to s tebou nenastudoval od A-Z.
    OK. Pokusím se nezklamat.
    Chci vylepšit OSM a myslím, že TZ je jedna z věcí, která hodně vylepší turistické mapy. Když jsem zjišťoval, jak takový import probíhá, nabyl jsem dojmu, že to bude fuška. No nemýlil jsem se. Abych řekl pravdu, vůbec se nedivím, že ty komíny nakonec nikdo nenaimportoval, i když zdroj a souhlas s užitím máme.
    *** určitě si tvé práce cením. Je dobře, že to je náročné, protože pak není potřeba revertovat. To se zatím dělalo hromadně snad jen dvakrát. Poněkud neslavně dopadly s dočištěním waterway.
    Dobré vědět. Teď je pro mně priorita, najít způsob, jak TZ zanést do mapy. Každé řešení má svá pro a proti. Záleží co nakonec převáží. Marián
  39. Jan Kouba kouba.honza na gmail.com #mdef8e4
    Ahoj, a nebylo by lepší použít pro sales_point taky relaci? Vypadalo by to pak asi takhle: Relace turistické známky) tagy: type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky ref=<neco> členové: attraction -> <atrakce které se známka týká (pokud není známo, tak ten bod s fixme vytvořený při importu> sales_point -> r1 sales_point -> r2 sales_point -> r3 sales_point -> r4 sales_point -> r5 sales_point -> r6 Relace r1) tagy: type=tourist_stamp:sales_point name=Infocentrum Impuls, 793 24 Karlova Studánka 59 web=http://www.k.studanka.cz členové: (objekt kde se to prodává) atd. Jan Kouba
  40. Marián Kyral mkyral na email.cz #m7b41e7
    Ahoj, a nebylo by lepší použít pro sales_point taky relaci? Vypadalo by to pak asi takhle: Relace turistické známky) tagy: type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky ref=<neco> členové: attraction -> <atrakce které se známka týká (pokud není známo, tak ten bod s fixme vytvořený při importu> sales_point -> r1 sales_point -> r2 sales_point -> r3 sales_point -> r4 sales_point -> r5 sales_point -> r6 Relace r1) tagy: type=tourist_stamp:sales_point name=Infocentrum Impuls, 793 24 Karlova Studánka 59 web=http://www.k.studanka.cz členové: (objekt kde se to prodává) atd.
    No nevím, tohle se hanojovi určitě líbit nebude ;-) Pokud bude třeba 6 prodejních míst, tak to znamená, jedna relace pro samotnou TZ a dalších 6 relací pro prodejní místa. Přičemž to budou relace s pouhým jedním bodem. Zkusím udělat nějakou analýzu, kolik TZ má 1,2,3... prodejní místa. Marián
    Jan Kouba
    Relace) type=checkpoint checkpoint=tourism checkpoint:type=tourist_stamp name=3. Karlova Studánka checkpoint:category:cz=Jeseníky checkpoint:sales_point:1=Infocentrum Impuls, 793 24 Karlova Studánka 59 checkpoint:sales_point:web:1=http://www.k.studanka.cz checkpoint:sales_point:2=Občerstvení U vodopádu, Karlova Studánka checkpoint:sales_point:web:2=http://www.kstudanka.cz checkpoint:sales_point:3=Lázeňský dům Libuše - recepce, Karlova Studánka checkpoint:sales_point:web:3=http://k.studanka.cz checkpoint:sales_point:4=Cukrárna Roman Korytar checkpoint:sales_point:5=Minimarket Roja, Karlova Studánka checkpoint:sales_point:6=Geologická sbírka Jeseníků checkpoint:sales_point:web:6=http://www.ejeseniky.com Mám dotaz: Nepřeháním to s těmi dvojtečkami? Není na to nějaké omezení? Přiznám se, že jsem moc nehledal, ale JOSM neprotestuje.
    Zdravím, mně se to s těmi dvojtečkami nelíbí. Vždyť je to relace a relace je tu od toho, aby měla členy, ne? Tak proč to nahrazovat spoustou dvojtečkovaných atributů? To bych chápal maximálně jako FIXME. A ve výsledku by objekty (výše tedy Infocentrum Impuls, Občerstvení U vodopádu, Lázeňský dům Libuše...) měly být členem relace, s typem "sales_point". Milan Vančura No to mělo. Ovšem nějak tam ta data potřebuji napoprvé dostat abych následně mohl přiřadit (vytvořit) další členy relace. A stejně, pokud všechny tyto body převedu na skutečné objekty a zařadím je do relace, potřebuji je nějak identifikovat s ohledem na předpokládané aktualizace. Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu mít klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí "sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám. Muselo by to být nějak zakódováno přímo u daného prodejního místa, třeba ref=TSCZ:3:SP1, ale to by zase mohlo kolidovat s už existujícím ref. Stejně pak ale musím mít možnost poznat, že se třeba změnila adresa. A to buď tak, že tam bude celý řetězec ("Infocentrum Impuls, 793 24 Karlova Studánka 59"), nebo nějaký hash (třeba md5) či kontrolní číslici. A totéž musí být i pro web adresu (pokud existuje). To ale znamená, že jak ref, tak i hash pro jméno a website musí být přiřazeno danému objektu. A musí to být přiřazeno ručně -> práce navíc a dají se v tom udělat chyby. A třeba spočítat hash asi každý neumí. Navíc se pak kdokoli může rozhodnout, že ty podivné tagy se mu nelíbí a smaže je -> update skript to bude hlásit jako nový objekt. Nějaký nápad? Marián
    Links: ------
  41. Petr Kadlec petr.kadlec na gmail.com #m127eb3
    2013/5/30 Marián Kyral <mkyral na email.cz>
    Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu mít klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí " sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám.
    Jednak připomínám, že relace si pamatuje pořadí členů, tedy stačí všechny členy s rolí sales_point mít ve správném pořadí. Pokud se vám to zdá příliš křehké (či chcete mít možnost některá prodejní místa (prozatím) přeskočit), dá se pořadové číslo těch členů uvést i přímo do té role jako např. ?sales_point:1? (viz např. http://wiki.openstreetmap.org/wiki/Relation:route#Members). Rozhodně by to bylo mnohem lepší než množit atributy, to je naprosto proti jejich smyslu. -- Petr Kadlec / Mormegil
  42. Marián Kyral mkyral na email.cz #m5aa293
    2013/5/30 Marián Kyral <mkyral na email.cz> Prodejní místa se můžou změnit, website se může změnit. Potřeboval bych nějak identifikovat nově přidaná nebo smazaná prodejní místa. Pokud budu mít klíč checkpoint:sales_point:1 tak není problém zjistit, jestli se něco změnilo, nebo ne. Ovšem pokud budu mít x členů relace s rolí "sales_point" tak nevím jak poznám, který člen odpovídá "Infocentrum Impuls, 793 24 Karlova Studánka 59". No a pokud se infocentrum přestěhuje a bude tam nově třeba "... Karlova Studánka 77". tak už to vůbec nepoznám. Jednak připomínám, že relace si pamatuje pořadí členů, tedy stačí všechny členy s rolí sales_point mít ve správném pořadí. Pokud se vám to zdá příliš křehké (či chcete mít možnost některá prodejní místa (prozatím) přeskočit), dá se pořadové číslo těch členů uvést i přímo do té role jako např. ?sales_point:1" (viz např. http://wiki.openstreetmap.org/wiki/Relation:route#Members [1]). Rozhodně by to bylo mnohem lepší než množit atributy, to je naprosto proti jejich smyslu.
    Díky, to se asi bude hodit. Když už se o tom mluví, mám jednu off topic otázku: Pokud jsou součastí relace cesty (které na sebe navazují), dají se tyto v josm nějak automaticky seřadit? Když jsem posledně opravoval vedení turistické značky, nic takového jsem nenašel a musel jsem to řadit po jednom a manuálně. Díky, Marián
    -- Petr Kadlec / Mormegil
    Links: ------ [1] http://wiki.openstreetmap.org/wiki/Relation:route#Members
  43. Marián Kyral mkyral na email.cz #m381e99
    Díky, to se asi bude hodit. Když už se o tom mluví, mám jednu off topic otázku: Pokud jsou součastí relace cesty (které na sebe navazují), dají se tyto v josm nějak automaticky seřadit? Když jsem posledně opravoval vedení turistické značky, nic takového jsem nenašel a musel jsem to řadit po jednom a manuálně.
    Beru zpět, už jsem to našel. Sice někde úplně jinde, než jsem čekal, ale našel ;-) Marián
  44. Jan Kouba kouba.honza na gmail.com #meb94bf
    Ano, v josm se členové seřadit dají. V editoru relace je vedle seznamu členů tlačítko s popisem "Sort relation members.", které seřadí vybrané členy (nebo všechny členy, pokud není vybraný žádný, nebo jeden člen). Díky, to se asi bude hodit. Když už se o tom mluví, mám jednu off topic otázku: Pokud jsou součastí relace cesty (které na sebe navazují), dají se tyto v josm nějak automaticky seřadit? Když jsem posledně opravoval vedení turistické značky, nic takového jsem nenašel a musel jsem to řadit po jednom a manuálně. Díky, Marián -- Petr Kadlec / Mormegil
  45. Milan Vancura milan na ucw.cz #m624b31
    Relace r1) tagy: type=tourist_stamp:sales_point name=Infocentrum Impuls, 793 24 Karlova Studánka 59 web=http://www.k.studanka.cz členové: (objekt kde se to prodává) atd.
    No nevím, tohle se hanojovi určitě líbit nebude ;-) Pokud bude třeba 6 prodejních míst, tak to znamená, jedna relace pro samotnou TZ a dalších 6 relací pro prodejní místa. Přičemž to budou relace s pouhým jedním bodem.
    Jo, tohle se mi líbí. Je to svým způsobem ekvivalent toho seznamu bokem, ale mnohem lepší, je to celé v OSM a má to logiku. To důležité z mého pohledu je, že se zapojí skutečné objekty, nepřidávají se jim ale nesmyslné tagy a přitom je místo, kam zapsat metadata důležitá pro automatický update TZ. A počet relací je v pohodě. Stejným způsobem jsou dělané už linky a zastávky MHD, tam je také krom velké relace pro celou linku i relace pro zastávku, která jen slučuje zastávku a její nástupní ostrůvky. Na vysvětlenou můj nápad s externím seznamem, kdybys přeci jen nechtěl tolik relací: účelem je mít každou TZ jako relaci obsahující tagy patřicí TZ (jméno, ref...) a jako členy typu sales_point skutečné objekty v OSM. Externí seznam by pak obsahoval údaje pro updatovaci skript, aby poznal vazbu objekt_v_OSM<->identifikátor_podle_TZ. Např. 18374945 Infocentrum Impuls, 793 24 Karlova Studánka 59 kde 18374945 je ID objektu v OSM. Výsledná "velká" relace pro každou TZ by byla stejná jako v návrhu s relacemi, ale místo relace pro každé prodejní místo by byly členové přímo objekty v OSM a údaje v minulém návrhu uložené v těch malých relacích by byly v tom externím seznamu. Jelikož jde pouze o údaje pro účely importovacího/updatovacího automatu, bylo by to i účelné. Milan
  46. Marián Kyral mkyral na email.cz #m28d672
    Relace r1) tagy: type=tourist_stamp:sales_point name=Infocentrum Impuls, 793 24 Karlova Studánka 59 web=http://www.k.studanka.cz členové: (objekt kde se to prodává) atd.
    No nevím, tohle se hanojovi určitě líbit nebude ;-) Pokud bude třeba 6 prodejních míst, tak to znamená, jedna relace pro samotnou TZ a dalších 6 relací pro prodejní místa. Přičemž to budou relace s pouhým jedním bodem.
    Jo, tohle se mi líbí. Je to svým způsobem ekvivalent toho seznamu bokem, ale mnohem lepší, je to celé v OSM a má to logiku. To důležité z mého pohledu je, že se zapojí skutečné objekty, nepřidávají se jim ale nesmyslné tagy a přitom je místo, kam zapsat metadata důležitá pro automatický update TZ. A počet relací je v pohodě. Stejným způsobem jsou dělané už linky a zastávky MHD, tam je také krom velké relace pro celou linku i relace pro zastávku, která jen slučuje zastávku a její nástupní ostrůvky.
    Ovšem to znamená, že budu muset udělat pro každou relaci další fixme bod a ten pak následně ručně spárovat s nějakým skutečným objektem. Tohle ruční párování si dokáži u TZ představit (přece jem jsem schopen nějak dohledat, který objekt k dané známce patří), ale u prodejních míst to bude neskutečná piplačka, protože zjistit, kde na té bílé, nepopsané ploše je přesně "Občerstvení U hrocha" bude bez místní znalosti v podstatě nemožné. A taky se otevírá otázka, jaké mají mít ty fixme body souřadnice. V seznamu TZ je málokdy adresa, natož přesná poloha prodejního místa.
    Na vysvětlenou můj nápad s externím seznamem, kdybys přeci jen nechtěl tolik relací: účelem je mít každou TZ jako relaci obsahující tagy patřicí TZ (jméno, ref...) a jako členy typu sales_point skutečné objekty v OSM. Externí seznam by pak obsahoval údaje pro updatovaci skript, aby poznal vazbu objekt_v_OSM<->identifikátor_podle_TZ. Např. 18374945 Infocentrum Impuls, 793 24 Karlova Studánka 59 kde 18374945 je ID objektu v OSM. Výsledná "velká" relace pro každou TZ by byla stejná jako v návrhu s relacemi, ale místo relace pro každé prodejní místo by byly členové přímo objekty v OSM a údaje v minulém návrhu uložené v těch malých relacích by byly v tom externím seznamu. Jelikož jde pouze o údaje pro účely importovacího/updatovacího automatu, bylo by to i účelné.
    Problém je, kam to ukládat. Nadhodil jsi wiki. To by teoreticky šlo, ale nevím, jestli ji pro toto můžeme zneužít. Tady by hodně pomohlo, kdyby už to nějaký existující import takto používal. Ale myslím, že šance je minimální. Hlavní problém bude (ne)chtěné smazání objektu v OSM (smazání bodu a zkopírování tagu na budovu například). Na to by musel update skript nějak reagovat a znamenalo by to opětovné ruční párování. Když to vezmu kolem a kolem, tak se pomalu kloním k tomu, naimportovat TZ samotné a prodejní místa buď vynechat (dají se zjistit přímo ze stránky pro konkrétní TZ), nebo je doimportovat později (až bude jasné jak). V každém případě jsem pro TZ jako relace. Jednak se vyřeší problémy s kolizemi tagů a umožní to následné jednoduché rozšíření o prodejní místa. Ještě by mně zajímalo, jak se na toto dívají tvůrci turistických map. Co by pro ně bylo lepší a jaká data by je zajímala (jsou schopni nějak rozumně zobrazit). Marián
Napsat odpověď e-mailem… Odpovědět

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