Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace
Dne 15.2.2014 22:23, Václav Řehák napsal(a): Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na tolik, že má smysl kvůli tomu zdržovat celý import? Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že by to byl problém, když většina těch dat bude importována/udržována automaticky. Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár MB opravdu není argument ve světě OSM, kde se importují jednotlivé stromy v parku a další (pro mě až nesmyslné) detaily. O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i to rozsynchronizování si dovedu představit o dost realističtěji. V. Ahoj, však o addr:country už jsem psal dříve: Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je nějaký nesmysl). Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak addr:country a is_in házet do jednoho pytle - to proto, že se objevily názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné. is_in má oproti addr:country jeden zásadní problém - není jasné, co by tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli současný obsah na existujících bodech je blábol, nebo správná hodnota. A asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k čemu/kde se to používá. Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak: a) to bude i po importu fungovat ve stejné míře jako doteď b) je slušná šance, že si po importu někdo všimne (a ozve se), že software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile bude na stole konkrétní problém, tak bude rozhodování řádově snažší - buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne vyřešit i bez addr:country. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace
Ano, takto bych s tím souhlasil. V. Dne 16. února 2014 13:01 Petr Morávek [Xificurk] p...@pada.cz napsal(a): Dne 15.2.2014 22:23, Václav Řehák napsal(a): Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na tolik, že má smysl kvůli tomu zdržovat celý import? Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že by to byl problém, když většina těch dat bude importována/udržována automaticky. Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár MB opravdu není argument ve světě OSM, kde se importují jednotlivé stromy v parku a další (pro mě až nesmyslné) detaily. O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i to rozsynchronizování si dovedu představit o dost realističtěji. V. Ahoj, však o addr:country už jsem psal dříve: Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je nějaký nesmysl). Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak addr:country a is_in házet do jednoho pytle - to proto, že se objevily názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné. is_in má oproti addr:country jeden zásadní problém - není jasné, co by tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli současný obsah na existujících bodech je blábol, nebo správná hodnota. A asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k čemu/kde se to používá. Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak: a) to bude i po importu fungovat ve stejné míře jako doteď b) je slušná šance, že si po importu někdo všimne (a ozve se), že software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile bude na stole konkrétní problém, tak bude rozhodování řádově snažší - buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne vyřešit i bez addr:country. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Adresy z RUIAN - 2. rekapitulace
Ahoj, Xificurkovy připomínky jsou mi velmi blízké a sympatické, nelíbí se mi duplikace dat. To je ideální svět, ve kterém nejsme. Jedna věc je, rozhodnout se nějaký tag nepřidávat versus nějaký tag mazat. V případě addr:country a is_in by to bylo ve většině případů mazání, nikoli nepřidávání. Nechci nikomu rozbíjet Navit (příklad) ani nikoho nutit předělávat osm2navit. OSM snad není jen pro ajťáky a kartografy. Chybění tagů, které možná nějaký soft využívá, by mohlo stimulovat pokrok ve vývoji dotyčného software - vývojáři by byli nuceni svůj soft přizpůsobit novému obsahu databáze, jen si myslím, že zrovna nefunkční vyhledávání v CZ v Navitu (příklad) nezpůsobí, že vývojáři všeho nechají a vrhnou se na opravu Navitu. Proto se kloním k tomu zahrnout do importu i addr:country a is_in. Takže Přidávat, nahrazovat: addr:conscriptionnumber addr:provisionalnumber addr:streetnumber addr:housenumber addr:street addr:place addr:suburb addr:city addr:postcode addr:country=CZ is_in source:addr=cuzk:ruian ref:ruian:addr=nn Mazat: addr:provisional # cca 200 případů, asi záměna s addr:provisionalnumber addr:number # několik případů, asi omyl addr:alternatenumber # asi 300 případů, asi záměna s conscriptionnumber ref:ruian # Minimalis_import i jiné uir_adr:ADRESA_KOD či uir_adr:adresa_kod Jelikož j obecnému konsensu ohledně is_in a addr:country nejspíš nedojde, chci poprosit, abyste se už k přidávání těchto tagů nevyjadřovali, ledaže by nutkání či argumenty byly nepřekonatelně silné. Zato uvítám podněty k obsahu tagu is_in. K diskusi: - obsah tagu is_in - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově přidaných AM přidat, ? - cokoli dalšího ;) -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace
Dne 15.2.2014 18:57, Petr Vejsada napsal(a): Jelikož j obecnému konsensu ohledně is_in a addr:country nejspíš nedojde, chci poprosit, abyste se už k přidávání těchto tagů nevyjadřovali, ledaže by nutkání či argumenty byly nepřekonatelně silné. Zato uvítám podněty k obsahu tagu is_in. K diskusi: - obsah tagu is_in Ahoj, dokud nebude jasné čemu má obsah toho tagu sloužit, tak se těžko shodnem na jeho formátu. Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. Nominatim - umí polygony hranic, addr:country/is_in tedy není potřeba. Navit - resp. maptool, které převádí osm formát do binárního formátu pro navit, umí polygony hranic států i měst, is_in/addr:country tedy není potřeba. MoNav - sice neumí polygony hranic, ale neumí ani is_in/addr:country. OsmAnd - umí polygony hranic, is_in/addr:country tedy není potřeba. ... Ne opravdu jsem neprocházel všechen software, ale čistě ze statistik taginfo bych se fakt divil, kdyby na přítomnost těchto tagů něco opravdu spoléhalo. Zajímá mě nějaký příklad toho, kde jsou tyto tagy užitečné mj. i proto, abysme si vyjasnili, jaký formát/obsah by is_in mělo mít. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace
Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na tolik, že má smysl kvůli tomu zdržovat celý import? Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že by to byl problém, když většina těch dat bude importována/udržována automaticky. Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár MB opravdu není argument ve světě OSM, kde se importují jednotlivé stromy v parku a další (pro mě až nesmyslné) detaily. O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i to rozsynchronizování si dovedu představit o dost realističtěji. V. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
