Opakovaně se nám objevují problémy související s jedním kostlivcem bytujícím na dně naší RUIANové skříně. Občas se totiž v naší lokální geodatabázi GIS/RUIAN, vylíhne parcela s identifikátorem který na místo aby končil …….10, má nezaokrouhlenou hodnotu ……..09,99999.
Taková parcela se chová prapodivně. Jak patrno z ilustrace, může se jevit ve vyskakovacím okně maptipu zcela neškodně jako 53291511010, ale pokud takovouto parcelu zkusíme vyhledat, výsledek vyhledávání nám dá 53291511009,99999.
Důsledky to má bohužel fatální. Památkový Katalog, který si načítá ID RUIAN parcely z prostorových vazeb (spatial joinů) definičních a přírůstkových bodů zaokrouhluje hodnotu RUIAN ID směrem dolů, resp. odřezává všechny ty devítky za desetinnou částkou. Z parcely stavební č. 1 v katastru Bebáně nad Piplavou se tak rázem stane parcela pozemková č.1034/25 v katastru Úbic.
Podobný problém nastane při ručním kopírování parcely z mapové služby…
V Katalogu s tím do doby, než dodavatel geoportálu rozlouskne, v čem tkví problém, nic nenaděláme.
Editoři PaGIS by si však měli na tyto záludné hodnoty dávat pozor při kopírování atributů parcel pro věcné revize rozsahů KP.
VARS hádanku rozslouskl:
Problém je ten, že v databázi je Id ukládáno jako reálné číslo, jelikož definice Long nezvládne takto velké číslo uložit.
Různí klienti s tím číslem pak pracují různě, např.:
· ArcMap ho v tabulce zobrazí jako celé číslo 53291511010
· při načtení Pythonem je to jako 53291511010.0
· služba v REST rozhraní a operace Query u této konkrétní parcely potom 5.329151100999999E10
· služba v REST rozhraní a operace Identify vrátí 53291511009,999992
Z toho plyne, že každý klient se k tomu chová jinak.
Co s tím provede:
· Pro Aplikace (Widget RÚIAN) zaokrouhlí hodnotu v návratu dotazů na parcely
· Pro odesílání dat do Katalogu – provede zaokrouhlení – tím by se měl vyřešit problém se SJ
Ono se z toho čísla něco vypočítává? Dělají se průměry, inkrementuje se, řadí podle velikosti, nebo něco podobného? Pokud ne, mohlo se s tím zacházet jako s textem. Pochybuju, že VARS musel hádanku louskat, tohle je na první pohled chyba daná zaokrouhledním reálného čísla, které v takovémto případě není příliš vhodné používat.
Ovšem pokud se mi to při kopírování stalo (a to zcela určitě, když kopíruju přenosem atributů), dají se takovéto případy nějak hromadně vyfiltrovat?
Z čísla (unikátního identifikátoru parcely v RÚIAN) se odvozují všechny vazby mezi řečeným rejtříkem a našimi systémy. Nástroj pro synchronizaci změn na „naší“ straně z každodenních aktualizací z ČÚZK pohříchu „vyrábí “ numerickou hodnotu. S tím se skutečně nedá dělat nic jiného než expost zaokrouhlovat.
Co se týče přenosu takových nazaokrouhlených hodnot z prvkové služby (alias naší feature service RUAINu) – ano, přenese se „špatná“ hodnota. Při začleňování to kontrolujeme (a opravujeme), vyfiltrovat to jde, ale je to celkem zbytečné, neboť v tabulce jsou desetinná čísla zdálky viditelná…
Nicméně pokud bys to chtěl iniciativně dělat, tak humpolácká, ale účinná metoda je vybrat dle atributu, výrazem [parcelaID] NOT LIKE ‚%.%‘ a pak „switch selection“.
Kolega Eismann juž odpověděl.
Obecně, než odevzdá editor revizi, měl by si otevřít atributovou tabulku a podívat se, jaké v ní má vyplněny hodnoty. Ono by vše divné při té příležitosti ho mělo zaraziti.
Atributovou tabulku pochopitelně otvírám, protože ji vyplňuji. Číslo se ale vyplňuje Přenosem atributů, takže jsem předpokládal, že se přenese správně. Určitě jsem někdy viděl tu spoustu devítek za desetinnou tečkou, ovšem to je v počítačštině tak běžné, že mě nenapadlo, že by to mělo něčemu vadit. A myslím, že se to dá i ve stávajících datech opravit za pochodu, tj. při používání zaokrouhlovat správně matematicky, příp. přičíst 0,5 a za tečkou oříznout.
Protože pracuju v jedné (postupně v několika) pracovní vrstvě a z ní teprve vykopírovávám jednotlivé KP, napadlo mě vyfiltrovat to v této vrstvě, kde mám vše a věděl bych, kde se to stalo.