SpoilerCe blog décrit les fonctionnalités de Pro 2.9 (non publié au moment de la rédaction) - demandez à votre représentant Esri à propos d'ArcGIS Knowledge !
Certaines choses en technologie de l'information semblent être des exemples perpétuels de fournir des données, pas de l'information, et si vous voulez être guidé par les données, c'est l'information que vous voulez. Mon exemple ici est visualiser et analyser les relations parmi des ensembles de données géorélationnelles, un domaine clé qu'ArcGIS occupe et quelque chose avec lequel j'ai toujours eu du mal au-delà des bases. Vous pouvez appliquer des jointures et des relations aux couches de carte mais celles-ci semblent rapidement perdre en puissance et en utilisabilité, comme comment visualiser la cardinalité et comment faire des requêtes performantes. De plus, si vos ensembles de données proviennent de sources différentes, cela devient encore plus difficile. J'ai pris des détours vers des approches codées mais j'ai appris qu'elles ne sont pas évolutives.
ArcGIS Data Interoperability et ArcGIS Knowledge à la rescousse !
Pourquoi ce duo ? Eh bien, Data Interoperability dans Pro 2.8+ inclut la version Tech Preview du lecteur/écrivain de base de données Esri Knowledge graph et résout le problème 'toutes sources' pour construire et maintenir des bases de données Knowledge graph. Non seulement le lecteur/écrivain est flexible, il est aussi rapide. Au moment de la rédaction, Knowledge est encore en construction et j'utilise le logiciel alpha Pro 2.9, mais le sujet est tellement adapté à une approche guidée par les données que je n'ai pas pu résister.
Voici quelques graphiques issus de mon travail ETL pour peupler un graphe, les espaces de travail sont dans le téléchargement du post. Le graphe que je construis concerne les données immobilières, les nœuds sont les centroïdes des titres cadastraux plus d'autres entités pour les propriétaires et charges (généralement baux et hypothèques), avec des relations comme 'possède' et 'greve'.
Chargement des Entités (Nœuds)
Chargement des Relations
Nœuds Source Propriété
Il y a plus de 10 millions d'entités et plus de 10 millions de relations dans le graphe. J'ai simplifié mon modèle de données un peu pour ignorer certains détails juridiques (il existe une chose appelée un estate qui permet des relations plus complexes entre titres et propriétaires) pour me donner un graphe où les points de titre immobilier (les points bleus) ont une ou plusieurs parts de propriété sur eux et les parts de propriété ont zéro ou plusieurs charges. Les points de titre sont évidemment spatiaux, les propriétaires et charges sont tabulaires. Voici quelques comptes d'entités :
Modèle de Données
Vous verrez que le chargement des données s'est fait en deux parties, d'abord les entités puis les relations. C'est parce que les relations entre entités sont faites en utilisant des champs GlobalID générés automatiquement, donc les entités doivent être créées en premier, vous comprendrez à partir des espaces de travail. Les GlobalIDs d'entité deviennent les GlobalIDs d'origine et destination des relations.
Les graphes vivent dans un Enterprise Portal, j'utilise Enterprise 10.9.1/Pro 2.9 comme portail et client.
Il y a d'innombrables requêtes que vous pourriez faire sur votre graphe, cela est facilité interactivement soit en utilisant une chose appelée Link Chart soit en utilisant le langage de requête Cypher .
D'abord un simple link chart. Mes données ne sont pas vraiment du type où les connexions seront découvertes fraîchement via l'exploration interactive du link chart, toutes les relations sont déjà connues, mais vous pouvez sélectionner et ajouter des entités à un link chart pour enquêter sur vos données. C'est ma première incursion dans Knowledge donc je reste simple. Voici qui possède certains titres quelque part :
Link Chart Basique
Je n'ai pas utilisé les outils interactifs pour construire les entités du graphique, j'ai utilisé une requête Cypher :
match (ee:Encumbrancee {name:'Her Majesty The Queen'})-[oe:owns_encumbrance]-(e:Encumbrance)-[he:has_encumbrance]-(t:Title {land_district:'Otago'}) return ee,oe,e,he,t limit 5
Cela a trouvé 5 titres dans un district foncier spécifique grevés par un seul encumbrancee. Je vais laisser derrière moi les link charts à ce stade, mais ils viennent avec des outils pour les peupler et sont un excellent moyen d'explorer les connexions.
Il y a des motifs plus grands à découvrir ! Par exemple où se trouvent beaucoup de titres grevés ?
Titres non grevés (verts) et grevés (rouges)
Si je faisais cela sérieusement, je pourrais joindre des variables démographiques à mes points de titre avant de les charger dans mon graphe, ce qui me permettrait d'analyser des segments de population.
Il y a des choses intéressantes à apprendre sans étudier la démographie. Un avantage des bases de données graphes est qu'elles sont rapides pour interroger des statistiques agrégées comparées aux équivalents SQL, par exemple regardons la répartition du marché des encumbrancee (institution financière ou bailleur).
Détentions d'Encumbrance par Institution
Ce résultat est sorti de mon graphe en quelques secondes en utilisant la requête que vous pouvez voir dans le contrôle :
match (e:Encumbrance) where e.name is not null return e.name, count(*) as book order by book desc
Les données du détenteur d'encumbrance ont une longue traîne, disons que nous sommes intéressés par les grands prêteurs commerciaux qui ont selon moi 10 000 encumbrances ou plus et sont des entreprises.
Grands Prêteurs
Cet résumé couvre l'ensemble du jeu de données, vous remarquerez que trois institutions sont au coude-à-coude sur le marché, puis la part du marché chute rapidement et il y en a 12 qui correspondent à mes critères. Y a-t-il quelque chose de différent dans ma zone d'étude ? J'ai fait une requête pour le savoir :
match (e:Encumbrance)
with e.name as lender , count(*) as book where book > 10000 and lender contains 'Limited'
with collect(lender) as biglenders
match (t:Title {land_district:'Otago'})-[:has_encumbrance]-(e:Encumbrance) where e.name in biglenders
return t, e
Voici la carte et un graphique :
Le Paysage du Prêt
Je pourrais être capable d'étayer un cas pour les points chauds où certaines institutions font mieux que d'autres, mais c'est le graphique qui est intéressant, les avoirs des quatre principales institutions ne suivent pas la répartition nationale.<\/P>
Nous pouvons examiner les avoirs grevés dans une zone d'étude :<\/P>
match (o:Owner)-[:has_owner]-(t:Title {land_district:'Otago'})-[:has_encumbrance]-(e:Encumbrance) where e.name contains 'Limited'<\/STRONG>
with o.prime_other_names + ' ' + o.prime_surname as owner, o.corporate_name as company, count(*) as holdings<\/STRONG>
return owner, company,holdings order by holdings desc<\/STRONG><\/P> <\/P>
Avoirs<\/span><\/span><\/P> <\/P>Ou une requête connexe, quels titres non agricoles sont grevés par les grands prêteurs ?<\/P>match (e:Encumbrance)<\/STRONG>
with e.name as lender , count(*) as book where book > 10000 and lender contains 'Limited'<\/STRONG>
with collect(lender) as biglenders<\/STRONG>
match (t:Title {land_district:'Otago'})-[:has_encumbrance]-(e:Encumbrance)<\/STRONG>
where e.name in biglenders<\/STRONG>
with t,e<\/STRONG>
match (o:Owner)-[:has_owner]-(t)-[:has_encumbrance]-(e)<\/STRONG>
where not (o.corporate_name contains 'Farm' or o.corporate_name contains 'Pasture')<\/STRONG>
return o,t,e<\/STRONG><\/P>Je me hâte d'ajouter que cela a quand même attrapé beaucoup de fermes car le modèle de données ne supporte pas vraiment les requêtes de classification de l'utilisation des terres mais bien sûr si j'ai des zones d'utilisation des terres je pourrais faire une superposition des points de titre au préalable et le faire pour de vrai.<\/P> <\/P>
Charges non agricoles par banque<\/span><\/span><\/P>Ainsi, bien qu'au moment de l'écriture je sois en avance sur la version logicielle requise, j'espère que cela vous donne une idée de l'art du possible avec ArcGIS Knowledge<\/STRONG> pour rendre la requête de relations complexes dans les big data simple et rapide. Ce fut ma première incursion dans Knowledge et j'ai beaucoup appris, y compris les bases du langage de requête graphique OpenCypher<\/STRONG> que vous voyez ci-dessus. Comme je le dis dans l'alerte spoiler, contactez votre représentant Esri à propos des plans de sortie (Pro 2.9) et si vous êtes vraiment motivé la Early Adopter Community à Pro 2.8.<\/P> <\/P> <\/P>
