Transaction id a inkrementální aktualizace

xificurk commented 10 years ago

https://lists.openstreetmap.org/pipermail/talk-cz/2014-May/009876.html

Zdá se, že kontrola transaction id při inkrementálních aktualizacích nefunguje úplně, jak by měla.

Ještě to bude potřeba prošetřit, ale zatím se zdá, že jediným rozumným work-aroundem je prostě transaction id ignorovat a data tam vždy nahrát znova celá.

shr3k commented 10 years ago

To mi připomíná, Config.ignoreInvalidGML resp. isValidGML v GMLUtils by měl asi i vyhodit ty nevalidní hranice ZSJ v Praze, o kterých píše Petr Vejsada v listu, přesto to do PostGISu pustí, resp. na tom havaruje.

xificurk commented 10 years ago

Tak jsem si konečně našel chvilku, abych se na tohle podíval...

Izoloval jsem jeden objekt, na kterém se chyba projevuje - stavební objekt 78092353.

V posledním úplném dumpu z 30.6. nemá geometrii hranice, id transakce je 615041 (https://gist.github.com/xificurk/accb14e610e82be19e73).
3.7. obdržel tento objekt aktualizaci (https://gist.github.com/xificurk/9bf1de6624f1b9921262), ta přidává geometrii hranice, ale id transakce se nezměnilo a zůstalo na 615041.

Tím pádem je ta aktualizace ignorována, jediným work-aroundem je použít přepínač --reset-transaction-ids, aby se idčka v databázi vyresetovala (ale trvá to mrtě dlouho).

Otázka je, jak toto opravit... a jestli to je vůbec chyba v ruian2pgsql nebo přímo v RÚIAN.

pedro042 commented 10 years ago

Já navrhuji namísto --reset-transaction-ids použít --ignore-transaction-ids. To nebude trápit databázi a prostě se objekt pokaždé zaktualizuje (když bude ve změnovém souboru).

Patch jsem posílal Xificurkovi, jelikož Javu neumím tak jsem do toho nechtěl vrtat a patchnul jsem natvrdo. Patch je na http://pedro.poloha.net/osm/ruian2pgsql-ignore-transactions-ids.patch.xz . Je tam taková konstrukce typu "WHERE true" a tam by samozřejmě měla být nějaká proměnná, když je použit parametr --ignore-transaction-ids.

Koukal jsem na uvedený stavební objekt a zdá se, že s tímto patchem jeho aktualizace prošla:

   item_timestamp       |  plati_od  | ?column? ; to je hranice is not NULL

----------------------------+------------+---------- 07.07.2014 09:22:41.075879 | 03.06.2014 | t

Možná jsem někde něco přehlédl - když jsme srovnávali moji í DB, kterou si aktualizuji s Xificurkovou, kterou si nahrává čistou, tak v adresních místech byla shoda, ale ve stavebních objektech ne. Netuším proč.

xificurk commented 10 years ago

@pedro042 ono by asi v principu stačilo změnit tu ostrou nerovnost na <=.

Mezitím jsem napsal dotaz na ČÚZK, abysme zjistili, na čí straně je problém.

shr3k commented 10 years ago

Já bych tam všude nasázel <= a nepáral se s tím...

xificurk commented 10 years ago

Tak podle ČÚZK je to takhle v pořádku:

IdTransakce se skutečně u většiny změn prvku mění. Uvedené pravidlo ale neplatí absolutně. Ve VFR se údaje o některých prvcích mohou skládat z více částí, které se mohou měnit nezávisle, pak může dojít ke změně některých podřízených údajů, aniž by se u prvku změnilo IdTransakce. V tomto konkrétním případě došlo v ISKN ke změně polygonu stavebního objektu (SO) nebo případně k novému přiřazení existujícího polygonu budovy k SO, aniž by byly v ISUI měněny nějaké údaje SO. Důsledkem je změna polygonu SO ve VFR beze změny IdTransakce.

Takže jako řešení tedy vidím opravdu nahradit tu ostrou nerovnost.

fordfrog commented 10 years ago

díky za vyřešení a opravu

fordfrog / ruian2pgsql

Transaction id a inkrementální aktualizace #24