Dne 3.6.2013 15:25, Milan Vancura napsal:
> 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
Milan
_______________________________________________
Talk-cz mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-cz
_______________________________________________
Talk-cz mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-cz
