104 odpovědí na toto téma

[mpik]

Pokud by to někomu pomohlo, tak sekce PluginWork toho pluginu může vypadat takto:

var 
    seznamLogu:TGeoLogList;
    i:integer;  
begin
  seznamLogu := GC.logs;
  
  for i := 0 to seznamLogu.count-1 do
  begin
      if seznamLogu.Items[i].logType = 'Publish Listing' then 
 GC.TagAdd('DatePublished',formatDateTime('dd.mm.yyyy',seznamLogu.Items[i].date));
  end;

Ale uvědomte si, že musíte mít staženy VŠECHNY logy ze VŠEHO co máte staženo.
Já osobně jen PRO SEBE v tom pokračovat nebudu.

[VasaM]

Měl bych takový návrh, ale nevím jak je to složité. Co takhle vytvořit nějakou veřejnou databázi data publikování keší. Tato databáze by byla na online , a datum by se z ní v případě potřeby stahoval, přičemž, pokud by chyběl, tak by si ho uživatel musel stáhnout z logů, nebo napsat manuálně. Tento údaj by se pak nahrál do veřejné databáze pro ostatní. Ovšem záleží na složitosti tohoto procesu... Ovšem podle mě by to mělo být účinnější, teda až po třeba prvním měsíci fungování, kdy by se tam postupně nahrávali údaje. Ovšem stačilo by pár ochotných uživatelů, kteří třeba už nějaké publikační logy mají stažené a z nich by se to mohlo rovnou automaticky nahrát...

[mpik]

Na rozdíl od databáze finálek by tohle ničemu nevadilo, ale i tak je to dost proti pravidlům, co se týká strojového stahování z webu. Tohle asi neprojde, aby to někdo veřejně vystavil.

[VasaM]

Jo tak na to jsem nemyslel. Ale co by na tom vadilo. Pouze GC kód a datum, by stačilo. A nemuselo by se to stahovat strojově, ale uživatelsky přes plugin třeba z geogetu.

[mpik]

Tak to už mi skoro připadá jednodušší stáhnout si všechny logy. Jen si nechci zasvinit databázi, netuším, jak by to pak šlo rychle a nechce se mi to zkoušet. A logy může stahovat přes API i BM téměř bez omezení a poměrně rychle. Šlo by pochopitelně v pluginu stahnout logy, vybrat důležité, ostatní smazat a nechat jen pár posledních, ale do toho se mi opravdu nechce.

[VasaM]

Jasně to jo, ale já to myslel tak, že to udělá jeden uživatel a údaje poskytne dál - online. Takže další už nebude muset stahovat logy, ale stáhne rovnou datum... Ovšem nevím jak moc je to složité...

[mpik]

Nezdá se mi to tak důležitá informace, aby se do toho na webové úrovni někdo pouštěl a další aby to implementoval do geogetu. Pokud by to bylo, využil bych to a i bych tam svoje přidával. Ale je to flekování toho, co už dávno mohlo (mělo) být na oficiálním webu, proto si myslím, že to smysl nemá. Třeba nás GS překvapí a tu informaci tam přidá sám. Ale myslím si, že nás spíš překvapí další bezpečnostní dírou.

[VasaM]

No právě, pro těch pár uživatelů se to nevyplatí, ale to možnost, jak to udělat.

[mpik]

Dotaz na autory: Při stahování logů parametr Refine vyčistí logy - nechá jen omezený počet a důležité logy. Publish log je nebo není důležitý? Pokusně jsem zjistil, že se asi neuchová, ale nevím, jestli jsem něco nedělal špatně.

[gord]

Potvrzuji. Zda se, ze GG nepovazuje Publish za dulezity log. Pro bezne praktiky to neni zadny problem. Pro vas statistiky by mozna Haluma mohl tento log k dulezitym pridat

[HaLuMa]

To je tak jedine, co pro vas mohu udelat.

[mpik]

Předpokládám, že Refine pracuje tak, že stejně nejdřív stáhne všechny logy a pak přebytečné smaže. Takže to ušetří jen místo v databázi, ale ne síťový provoz.

[HaLuMa]

Pochopitelne. Dopredu nevim, jake logy ziskam. Tady jde o to, aby se v databazi logy nehromadily, protoze logy jsou nejobjemnejsi cast cele databaze. Nejsou velke, ale je jich hodne.

[pozorjed]

HaLuMa napsal/a:
To je tak jedine, co pro vas mohu udelat.

nene, ještě by šlo rozšířit DB strukturu o nové pole DTPublic. Když to bude v základním modelu, bude se s tím lépe pracovat. Čím se bude plnit, to je až následná etapa, zde už si dovedu představit individuální řešení.

[HaLuMa]

Fakt se mi nechce delat dalsi verzi databaze jen kvuli takove pitomine. To si musi pockat na neco vetsiho.

[kolombo]

pozorjed napsal/a:

HaLuMa napsal/a:
To je tak jedine, co pro vas mohu udelat.

nene, ještě by šlo rozšířit DB strukturu o nové pole DTPublic. Když to bude v základním modelu, bude se s tím lépe pracovat. Čím se bude plnit, to je až následná etapa, zde už si dovedu představit individuální řešení.

Proč to nemůže být TAG ?

[mpik]

Chápu, že ve struktuře databáze je to lepší. Třeba pro to, že se s tím dá lépe pracovat. Ale zásah do struktury databáze je vždy potenciálně nebezpečný (musí se např. převést stará databáze do nové a musí se hlídat, jestli není rozpor mezi verzí databáze a verzí programu). Struktura databáze by se měla měnit jen pokud je pro to dostatečný důvod. Tohle - použitelné pro menšinu lidí - by měl být asi tag. Dělat jen kvůli tomu změnu databáze i programu asi nemá smysl.

[pozorjed]

Však neříkám, že bych to chtěl hned v nejbližší verzi, jen říkám, že by to pomohlo. Tedy někdy časem ... . Za ten čas, co jsme tu strávili jalovou diskusí, už to mohlo být v seznamu možných změn v GG, s tím, že bude součástí větší struktuální změny. Ad Kolombo: TAG = rychlé řešení. Nevýhoda, pokud se objeví 2 řešení stejného problému a názvy TAGů budou rozdílné. Následně je uzavřena cesta něco dodělat do GG (např. přidat do exportu GPX), protože mohou existovat 2 rozdílné TAGy pro totéž. Z tohoto důvodu je lepší mít jednoznačnou databázovou položku.

[mpik]

Možná jste mě přesvědčili, že ten plugin na přidání do tagu udělám. Nemuselo by to ani zasvinit databázi, pokud se budou uchovávat jen důležité logy. A proběhl by jednorázově, nebo jen občas na nově importované, takže ani ten síťový provoz by nebyl tak velký. Ale nebude to hned, jsem ve strašném skluzu v práci a tak minimálně týden až dva na programování čas mít nebudu.

[mpik]

Tak mi to nedalo a první verzi pluginu jsem udělal.
Je to na vlastní nebezpečí, očekávám betatest od těch, kdo o to měli zájem.
NESPOUŠTĚJTE TO NA OSTRÉ DATABÁZI, udělejte si kopii.
Funkce:
Pro všechny zobrazené v okně (aby se to dalo spouštět po částech) udělá toto:
- Pokud má keš tag DatePublished, přeskočí se (pokud chcete znovu zkoušet, smažte ten tag).
- Pokud má keš stažen publikační log, použije se.
- Pokud nemá, STÁHNOU SE VŠECHNY LOGY K NÍ přes LiveAPI, pak se všechny vymažou a nechá se nastavitelný počet (v Configu) a všechny důležité. Důležité jsou Vlastní logy, Publikační, archivační, změna souřadnic, zastavení, puštění...
- Z publikačního logu se vezme datum a nastaví do tagu.
- Pokud publikační log chybí, NEVYPLNÍ SE NIC. Bohužel zatím neumím odlišit chybějící Publish log a situaci, kdy uživatel předčasně zastavil stahování.
- Datum je ve tvaru 20121117. Je to formát, ještě čitelný očima a zpracovatelný automaticky, třeba se dá podle něj řadit. Pro zobrazení udělám ještě jednoduchý vizualizační plugin.
- Bez nastaveného tagu se zapisují do souboru jako seznam, ale ono je to vidět i na tom, že prostě datum chybí.
- Plugin běží pomalu, i když používá LiveAPI. J možno ho zastavit, při dalším spuštění se nastavené dříve přeskočí a pokračuje se dále.
Prozatím nedávám na Ararat, stáhněte si ho tady:
http://pikous.wz.cz/...ished-1.0.1.gip