[Talk-cz] Turistické známky

[Marián Kyral]

---------- Původní zpráva ----------
Od: Milan Vancura <milan na ucw.cz>
Datum: 30. 5. 2013
Předmět: Re: [Talk-cz] Turistické známky

"On Thu 30-05-13 14:45:07, Marián Kyral wrote:
> 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

_______________________________________________
Talk-cz mailing list
Talk-cz na openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130530/811ce772/attachment.html>