Transformácia rozpoznaných entít typu lokácia na súradnice

[bodnarIQ]

Požiadavka: "Badatel si z mapy vybere zájmovou oblast. Na základě rozpoznaných entit se vyhledají texty obsahující uvedené informace."

Pre implementovanie takejto funkcionality budeme musieť rozpoznané entity typu lokalita indexovať pod ich súradnicami. Toto zahŕňa hneď niekoľko problémov.

1. Konvertovanie textu na súradnice

   • potrebujeme previesť textové reťazce rozpoznané nástrojom NameTag na ich súradnice. Pre toto existuje niekoľko nástrojov, väčšina z nich sú platené. Tu by mohol nastať problém ešte s českým/slovenským názvom, ktoré nemusí nástroj byť schopný rozpoznať.
   • nástroj od Googlu, Geocoding API dokáže prevádzať aj české/slovenské názvy(napr. ako Solúň) a vrátiť ich geografickú šírku a dĺžku, prípadne Border(obdĺžnik s 4 súradnicami). Stojí 5$/1000 requests

2. Vyjadrovanie lokalit s väčšou rozlohou

   • ak by sme všetky lokality konvertovali na body, nedalo by sa spätne z bodu určiť, aká lokalita sa tým zamýšľala. To by spôsobilo, že ak by sme narazili na rozoznanu lokalitu "Česká republika", zaindexovalo by sa to pod zemepisnými súradnicami 49.8175° N, 15.4730° E. Ak by badateľ chcel nájsť publikácie, v ktorých sa spomína lokalita v 30km okruhu dediny "Golčův Jeníkov", bol by zahltený výsledkami o zmienkach "Českej republiky", ktoré sú preňho irrelevantné, a tých pár výsledkov pre "Golčův Jeníkov" by sa medzi toľkými nerelevantnými výsledkami stratilo. Toto by sa dalo vyriešiť tak, že by sme evidovali pri každej rozoznanej entite jej podtyp(typy rozpoznanych geolokalit tu) a buď indexovali iba niektoré typy, alebo dávali užívateľovi ešte na výber, aký typ geolokality chce vyhľadávať.

3. Použitý súradnicový systém

   • pre správne fungovanie potrebujeme ukladať súradnice v Solre ako zemepisnú šírku a výšku. V ukážke z dokumentu Pomocná databáza sa používa súradnicový systém EPSG:5514, ktorý dokáže vyjadrovať iba územie CR/SK. Budeme potrebovať detekovať, či ide o lokalitu v rámci tohto územia, a ak áno, prevádzať do iného súradnicového systému do výsledného TEI formátu? A čo s ostatnými lokalitami, ktoré nespadajú do tohto územia? Alebo budeme túto informáciu evidovať iba o lokalitách v rámci tohto územia?

[motyc]

Ad 1 - jak psal jinde Pavel Straňák, lze využívat zdarma Wikidata. Pokud vím, přinejmenším v základu zdarma by měly být i Geonames (https://www.geonames.org/). Mohli bychom se také pokusit dohodnout s ČÚZK na využití https://geoportal.cuzk.cz/(S(fbewhh1i2gdfxyofxhfeiyfk))/default.aspx?mode=TextMeta&side=Geonames&metadataID=CZ-CUZK-GEONAMES-V&menu=261

Ad 2 - to je skutečně obtíž; souhlasím, že jediným rozumným řešením je kategorizace prvků. Ve chvíli, kdy budeme mít prostorová data napojená na nějaký gazeteer, lze z něj obvykle získat i informaci o hierarchii a příliš obecné záznamy uživatelskou volbou vyloučit.

Ad 3 - To byla skutečně jen ukázka. Vzhledem k univerzalitě bych nativně pracoval se systémem WGS-84 (EPSG:4326). Jediné, co bychom se ještě mohli pokusit řešit, jsou situace, kdy jsou v textu přímo zmiňovány souřadnice - ty mohou být v různých formátech a musely by se transformovat. To už by ale asi bylo až příliš složité a jde o samostatný problém.

[bukovskyIQ]

Výše specifikované body budeme dále analyzovat.

[zabak]

Ad 2 - toto je problém, na který narážím opakovaně. Existují nějaká použitelná data, která by alespoň místa s větší rozlohou definovala ne bodem ale obrysem? Vím že kdysi na to měli projekt švédové a tuším estonci, tam takhle geokódovali i různá historická územní členění. Možná by se dalo pracovat s hierarchií i tak, že na mapě vyberu ne bod, ale území a pak bych hledal v hierarchii takové celky, které na daném území mají i většinu středů svých "podcelků". Ad 3 - jednoznačně WGS-84. Souřadnice uvedené v textu jsou opravdu samostatný problém. Už jen určit ke kterému nultému poledníku by se ve starších textech (případně mapách) vztahovaly není úplně triviální.

[motyc]

@zabak Ad 2 - Pokud vím, tak žádný světový gazeteer se správními hranicemi neexistuje, nebo rozhodně není volně dostupný. Wikidata to např. řeší pomocí evidence několika bodů na obvodu (např. https://www.wikidata.org/wiki/Q213), čímž vznikne alespoň rámcový polygon. Využité jsem to viděl např. tady: https://client.perio.do/?page=backend-home&backendID=web-https%3A%2F%2Fdata.perio.do%2F (když vybíráte podle Spatial coverage, tak se v mapě zobrazí právě ty rámcové polygony z Wikidat). Pokud bychom se bavili jen o EU, pak existuje harmonizovaná sada administrativních hranic podle direktivy INSPIRE, která by mohla jít pro podobné potřeby také použít (https://inspire-geoportal.ec.europa.eu/overview.html?view=themeOverview&theme=au). Nikde jsem to ale nenašel již sloučené, pouze rozdělené po jednotlivých státech, takže by se to muselo sklidit a sloučit. Ad 3 - Ano, je to tak. A to se nebavíme o rovinných souřadnicích...

[JanMeritus]

@adammertel vedel by si nam k tomu pripadne nieco napisat z tvojho vonkajsieho pohladu? diki moc

[adammertel]

Ahoj, skúsim niečo k diskusii pridať, ale v podstate súhlasím s @motyc.

Na geokódovanie na úrovni obcí stačí geonames, pre historické lokality a exonymá sú často dobre použiteľné API od wikipedia alebo TGN, prípadne ďalšie regionálne alebo tématické gazetteery ako histograph, pleiades alebo ChGIS. Zaujímavou novinkou je World historical gazetteer. Dajte si ale pozor nato, že v mnohých prípadoch nie je prvý výsledok, ktorý API vypluje presne to, čo chcete získať (preklepy, chyby, podobné/rovnaké názvy, neexistujúce lokality...), je preto skoro nutné používať poloautomatické metódy. Tzn, ukázať editorovi výstupy z rôznych API a nechať ho vybrať (ideálne na mape), ktroré koordináty sú správne / najlepšie. Je tiež dobrý štandard udržiavať linky na id v gazetteeroch, nie iba preberať koordináty.

Presnosť regiónov je všeobecne problém, pokiaľ sa pohybujete v historických dátach - asi nikto vám nenakreslí geodetickú hranicu historického regiónu. Hranica regiónu môže byť fuzzy, môže presahovať do iného regiónu a v čase sa môže výrazne meniť. Je preto nutné definovať vzťahy medzi regiónmi a inými entitami a hranice regiónov prípadne odhadovať až následne alebo riešiť pomocou nejakej fuzzy logiky. Pokiaľ vám stačia aktuálne hranice, tak skúste OSM alebo naturalearth.

[bodnarIQ]

Adam vďaka za doplnenie, uzavrel by som to teda nasledujúcimi bodmi:

1. Konvertovanie textu na súradnice
   • nameTag rozozná v texte geografické lokácie tagom g. Podľa podtypu tohto tagu sa entita obohatí o ďalšie metadáta získané z externého nástroja (primárne súradnice) Geonames. Ak teda pôjde o entitu typu gq(urban parts)|gs(streets, squares)|gu(citites/towns) - zavolá sa API geonames s daným rozoznaným textom a buď sa automaticky strojovo uloží prvý výsledok, alebo sa dá správcovi/pracovníkovi zoznam výsledkov, z ktorého vyberie ten správny. Tento proces môže byť pomerne náročný pri počte stránok v K.
2. Vyjadrovanie lokalít s väčšou rozlohou
   • ak pôjde o väčšie územné celky(regióny, štáty, kontinenty), môžeme sa pokúsiť získať z nejakého externého zdroja Bounding Box - hranice územia. Pri vyhľadávaní by sme do výstupu zahrnuli väčšie územné celky iba v prípade, že by si o ne užívateľ explicitne požiadal, inak by sa by default nezahrňovali.
3. Použitý súradnicový systém
   • pre podporu spatial search budeme všetky súradnice ukladat vo formáte WGS-84, pri transformácií do TEI formátu sa môžu tieto súradnice prípadne previesť do iného formátu, ak to bude možné.

[bukovskyIQ]

Po společné diskuzi považuji toto issue za vyřešeno. Zavírám.