Manières d'exprimer des questions géographiques sous une forme lisible par machine

22

Un concept fondamental du SIG consiste à répondre aux questions sur les ensembles de données. Du point de vue d'une base de données; SQL avec des extensions spatiales est un moyen de poser de telles questions. De quelles autres manières les questions peuvent-elles être exprimées sous forme de texte lisible par machine? Quels sont les avantages des différentes approches?

geoprocessing analysis Matthew Snape
la source
2
+1 Serait intéressé à entendre des alternatives aux opérateurs Clementini
Kirk Kuykendall
1
@Kirk sciencedirect.com/science/article/pii/0031320390900045 , springerlink.com/content/74g53h7rt4424410 , sciencedirect.com/science/article/pii/S0306437902000418 , springerlink.com/content/p427149717224725ee , ieeexplore.p freeabs_all.jsp? arnumber = 273029 , springerlink.com/content/2bpk5g7exh13mpc3 , portal.acm.org/citation.cfm?id=182640 . Pour en savoir plus, effectuez une recherche Google Scholar
whuber
@whuber, j'aurais dû être plus précis. Je suis intéressé par les alternatives aux opérateurs Clementini dans les requêtes ArcGIS ou les requêtes sur des bases de données auxquelles ArcGIS peut se connecter. Alors qu'à première vue, Clementini semble à la fois humain et lisible par machine, en tant qu'humain j'ai souvent du mal .
Kirk Kuykendall,
1
@Kirk OK, mais il semble qu'ArcGIS rencontre des difficultés, pas vous! :-) Il est intéressant que Clemintini et al terminent leur article original avec la remarque "Un autre point dans notre liste de souhaits est lié au test si la méthode basée sur le calcul convient vraiment aux utilisateurs finaux."
whuber
1
@Matthew Pourriez-vous être un peu plus clair sur la portée des "questions" qui vous intéressent? Par exemple, êtes-vous principalement intéressé par les questions auxquelles on répond en découvrant et en traitant les relations spatiales entre les entités (qui auraient probablement besoin de la puissance du SIG pour effectuer) ou suffirait-il simplement de rechercher des attributs statiques d'entités ou d'emplacements nommés individuels ( qui ne nécessitent aucun traitement spatial)?
whuber

Réponses:

7

Je ne peux penser qu'à 3 types de requêtes spatiales, en ignorant tout attribut ou requête basée sur le hachage.

  1. Les requêtes spatiales basées sur la géométrie, et sont utilisées pour trouver les relations entre les entités vectorielles. Les requêtes spatiales SQL ne sont en réalité que des alogorithmes API de bas niveau tels que Bentley-Ottmann - utilisés dans OpenLayers pour vérifier si deux lignes se croisent.

    Comme Kirk l'a mentionné, les types de relations entre les entités se sont normalisés sur le modèle à neuf intersections dimensionnellement étendu :

    • Équivaut à
    • Disjoint
    • Intersecte
    • Touches (rencontre)
    • Des croix
    • À l'intérieur (à l'intérieur)
    • Contient
    • Chevauchements
    • Housses
    • Couvert par

    On peut soutenir que les requêtes spatiales basées sur des index sont une forme simplifiée de requêtes géométriques. La plupart des requêtes de géométrie utilisent un index spatial comme première requête de passage pour filtrer les entités non pertinentes avant de comparer des géométries individuelles, ce qui prend plus de temps. Celles-ci sont également implémentées dans des bases de données NoSQL telles que MongoDB .

  2. Requêtes spatiales basées sur la théorie des graphes . Ces types de requête sont implémentés dans le SIG via des outils tels que Network Analyst , et encore à un bas niveau sont des algorithmes .
  3. Requêtes spatiales basées sur des grilles raster et la théorie des ensembles (et la théorie des ensembles flous ).

Il existe quelques implémentations qui combinent ce qui précède, comme StarSpan qui combine les requêtes raster et vectorielles - bien qu'il masque vraiment une étape de prétraitement.

Il existe de nombreuses API qui implémentent ces types de requêtes lisibles à la fois par machine et par texte. Il y a une bonne discussion sur les différentes implémentations et leurs problèmes ici .

L'article Vers un langage de requête spatiale 3D divise les opérateurs spatiaux en 4 types, basés sur la requête plutôt que sur le type de données (ce qui est peut-être plus logique):

  1. opérateurs directionnels (tels que ci-dessus, ci-dessous, northOf, southOf)
  2. opérateurs topologiques (tels que toucher, contenir, égal, intérieur)
  3. opérateurs métriques (tels que la distance)
  4. Opérateurs booléens (tels que union, intersection)

Il apporte également une terminologie pour traiter des fonctionnalités 3D (corps et surface), qui ne sont pas incluses dans DE-I9M.

geographika
la source
Ainsi, au-delà du modèle dimensionnellement étendu à neuf intersections, nous ne pouvons exprimer des questions que sous des formes empruntées à d'autres domaines?
Matthew Snape
1
Définissez votre question dans n'importe quelle langue spécifique au domaine SIG que vous souhaitez, mais à la fin, la machine interrogera en utilisant l'une des méthodes ci-dessus (bien que j'en manque peut-être quelques-unes).
geographika
7

1 - Il existe des études avec ce logiciel: http://nlp.uned.es/MLQA06/papers/ferres.pdf
Bien qu'il soit plus lié aux recherches sur Internet, il pourrait fournir des conseils sur la façon de traduire le langage humain en langage informatique.
Googler 'GeoTALP-Q' fournit également plus d'articles sur le sujet.

2- GeoDjango fournit une API pour les requêtes spatiales, c'est une traduction de SQL vers un langage orienté objet qui peut accélérer beaucoup de travail fastidieux comme l'écriture de fonctions PL / python pour des requêtes spatiales complexes. Il est limité par la base de données que vous utilisez.

Pablo
la source
Voilà une découverte intéressante. Parce que nous aimons que ce site soit autonome et fournisse des réponses immédiatement utiles, il est préférable d'accompagner une référence comme celle-ci avec votre propre résumé de ses conclusions pertinentes. Pourriez-vous faire cela ici? Ma lecture très rapide de l'article suggère qu'il peut se concentrer davantage sur l'extraction d' attributs géographiques à partir de données Web plutôt que sur le traitement de requêtes sur les relations
whuber
@whuber. Ok, merci pour l'astuce. Je vais en tenir compte pour les réponses futures.
Pablo
2
+1 Ce qui est malheureux à propos de SQL, c'est que tant de ses mots réservés à consonance spatiale ont peu ou rien à voir avec l'espace: OERE, DE, EN etc.
Kirk Kuykendall
@Kirk Drôle, je n'y ai jamais pensé de cette façon. La différence entre l'emplacement et l'espace est suffisante pour donner mal à la tête à un gars. :)
Nathanus
@nathanus Ouais, et puis il y a même la notion de distance lexicale entre deux soundexes qui peut être utilisée par un dbms pour trouver la rue correspondante la plus proche .
Kirk Kuykendall,