[ruian] novy zdroj

[pavelzbornik]

Pridavam process na stazeni adresnich mist z RUIAN

[pavelzbornik]

Dík za comment a review. Souhlasím se všemi poznatky z review, osobně jsem chtěl udělat novou branch a pak ji vypilovat, což mi nešlo a pak jsme měl second thought, že nevím jaká bude reakce na PR, že to testnu s quick and dirty MVP a podle reakce upravím.

Myslím, že tento dataset může být dost zajímavý při analýze zdrojů co mají adresní kód místa a tím získat více info či extrémně přesné koordináty. V použití ruain id a informace v registru jsou český open data skoro "golden mine", alespoň z evropského pohledu.

Než to začnu upravovat, mám dotaz v jakém formátu je preference na GPS souřadnice? Po konverzi je zapisuji jak standardní geometrický bod POINT(), nevím jak je to přívětivé, hlavně pro užití v Postgres bez PostGIS extenderu (osobně nemám žádnou zkušenost), možná bude jednodušší to rozdělit na zeměpisnou výšku a šířku?

Ohledně dependence na pyproj, teoreticky je možné přepočítat souřadnice pomocí funkce s dlouhým matematickým výpočtem, který bude trvat asi tak 10x déle než současný proces (nevylučuji že to jde rychleji) s pyproj je ta konverze souřadnic 2 řádky.

[kokes]

Tu závislost neřešte, to bylo jen kdyby náhodou, hlavně ať se ta konverze provede korektně.

Co se týče POINTů... zpravidla uvádíme GPS souřadnice jako dva decimal sloupce, protože nepředpokládáme, že má uživatel PostGIS nainstalováno. A předpokládám, že překlad z dvou decimalů na point či jiný PostGIS datový typy bude triviální.

[pavelzbornik]

Fixnul jsem ty hlavni poznatky. Jeste jsem chtel pridat jednu vec, ale radsi se zeptam predem, aby to nerozbouralo neco jineho.

Myslim, ze by bylo dobre, aby u definece schema byl i popis daneho sloupecku pomoci comment atributu. Profesionalni deformace z aplikace data governance :).

[kokes]

Jo, comment se hodí - používám ho v případech, kdy mám dobrý zdroj z originální dokumentace - nebývá to často, dokumentace bývají v PDF, a mně se to nechce vysekávat.

https://github.com/kokes/od/blob/7396c3c83018e2c2f0a49b61da3ac958a05875e8/data/psp/schema.py#L37

Na PR mrknu.

[kokes]

Tak super, tři velmi malý poznámky:

1. Padá to na blacku, budou to asi jen ty apostrofy. Naštěstí black umí sám opravovat kód, takže to bude snadný.
2. Název tabulky ve schema.py má překlep - adreseni misto adresni
3. Ta tabulka nejde nahrát do DB, protože se jmenuje ruian.csv, ale my nahráváme podle názvu souboru - takže jen prosím změnit target filename na adresni_mista.csv a poběží to.

Právě jsem to nahrál do Postgresy a běží to dobře 👍 Takže jen opravit ty tři maličkosti a můžem mergovat. Dík!

[pavelzbornik]

Opravil jsem dane problemy, objevil jsem diky tomu par novych veci co se tyce lintovani kodu v VS Code, to se bude urcite hodit do budoucna. Snad mam ted nastaveno lintovani stejne jak v GitHub Actions.

Taky jsem pres camelot-py vyexportoval popis sloupecku a za dokumentoval v schema.py

Snad je hotovo :)

[kokes]

Super, je to zelený, vypadá to dobře, merguju, dík.

Jen takovej nitpick bokem:

Když to člověk nahrává do DB, tak ještě aplikačně kontroluju, jestli sedí nastavení nullability ve schématu a v datech a případně to ručně sladím (pokud to dává smysl - někdy v datech něco není null, ale teoreticky být může).

/Users/okokes/git/od2/main.py:166: UserWarning: NULL neshoda v adresni_mista (kod_casti_obce): data (False) vs. DB (True)
/Users/okokes/git/od2/main.py:166: UserWarning: NULL neshoda v adresni_mista (nazev_casti_obce): data (False) vs. DB (True)
/Users/okokes/git/od2/main.py:166: UserWarning: NULL neshoda v adresni_mista (typ_so): data (False) vs. DB (True)
/Users/okokes/git/od2/main.py:166: UserWarning: NULL neshoda v adresni_mista (cislo_domovni): data (False) vs. DB (True)
/Users/okokes/git/od2/main.py:166: UserWarning: NULL neshoda v adresni_mista (psc): data (False) vs. DB (True)

Tohle zkrátká říká, že v datech není žádné null PSČ, ale ve schématu je nullable.

select count(psc), count(*) from ruian.adresni_mista

Můžem to ale nechat, není to big deal.

[pavelzbornik]

Super že to prošlo.

Ohledně těch db constraints jsem to tam dal podle oka jelikož zas tak nemám zkušenosti s těmi daty tak nevím jak v delší časové řadě jsou kvalitní, aby se tam dalo natvrdo not null.

Bych počkal pár měsíčních updatu a pak upravím constraints.