Nouveau sur ArcGIS et souhaitant calculer la distance entre deux points «lorsque le poisson nage»

Nous avons une couche nommée hydrographie qui est la zone d'eau pour une affectation donnée. J'ai un point station et un point cible. J'ai besoin de calculer la distance entre ces deux points mais à l'intérieur de l'hydrographie. (les bateaux ne peuvent pas traverser la terre)

Le calcul de la distance de DefenseService semble passable mais il semble être en ligne droite car il ne prend aucun raster en entrée. L'Euclidien semble presque être là, mais je ne trouve rien de simple.

J'utilise ArcGIS Explorer 2500, ArcGIS for Server 10.1 SP1 Enterprise, et nous écrivons nos services et outils en C #.

J'ai le chargement de l'hydrographie, la création des IPoints, mais sans savoir quoi faire ensuite!

Toute aide appréciée, s'il vous plaît.

Utilisez les outils Distance de coût et Chemin de coût de l'extension Spatial Analyst.

Vous pouvez créer un raster à partir de vos polygones d'hydrographie. Assurez-vous ensuite que les cellules raster qui représentent l'eau obtiennent une valeur faible (par exemple 1) et que les autres cellules raster obtiennent une valeur élevée (par exemple 1000). Vous pouvez ensuite utiliser ce raster comme raster de distance de coût dans l' outil Chemin de coût .

J'ai fait quelque chose de similaire pour les lignes centrales sur les canaux et les cours d'eau naturels. L'approche que j'ai utilisée était de TIN les points, de bissecter le TIN puis de créer un deuxième TIN à partir des sommets d'origine et les bissectrices puis de traverser en utilisant un algorithme de Dijkstra modifié en éliminant les options dès qu'il est évident qu'elles ne formeront pas la solution la plus simple . La modification était que la ligne pouvait se terminer au point «solution» ou sur un chemin précédent s'il en existait déjà un. Il n'y a pas de solution prête à l'emploi pour cela et si vous n'êtes pas un programmeur ou au moins en mesure de vous mettre du bon côté d'une seule option est de tracer avec un décalage dans une géodatabase et de regarder le champ forme_longueur.

TIN = Triangular Irregular Network, un réseau de points et de lignes de connexion tel que chaque point est connecté à ses voisins les plus proches et qu'aucune ligne ne se croise. Pour cela, voir http://en.wikipedia.org/wiki/Delaunay_triangulation . Je n'ai pas utilisé les objets ESRI TIN, mais j'ai trouvé du code pour la triangulation et les ai gardés en mémoire, quelque chose comme http://www.codeproject.com/Articles/492435/Delaunay-Triangulation-For-Fast-Mesh-Generation .

Pour l'algorithme de chemin le plus court, voir http://en.wikipedia.org/wiki/Dijkstra's_algorithm , il a une belle image; malgré le nom compliqué, c'est vraiment assez simple.

À partir des points formant les lignes, j'ai fait une triangulation de Delaunay, puis trouvé le point médian de chaque bord du triangle (géométrie de base ... moyenne X, moyenne Y), puis inséré les points qui tombaient dans les polygones dans le maillage, ce qui donne un chemin central et liens vers tous les sommets de la frontière. Ensuite, en excluant les facettes qui suivent les rives du cours d'eau, tracez le réseau à l'aide de l'algorithme de Dijkstra et vous finirez par trouver un chemin du point A au point B passant approximativement au centre des cours d'eau. Il y aura beaucoup de chemins possibles, j'ai donc gardé un poids sur chaque sommet et arrêté un chemin lorsque la longueur cumulée dépassait la longueur déjà enregistrée, et si elle était inférieure, mettez à jour l'apex avec la longueur cumulée la plus courte - cela réduit la quantité de des chemins tracés, et il peut y en avoir beaucoup;

Alternativement, une fois triangulé, vous pouvez transformer les arêtes des triangles en deux lignes de points en tant que classe d'entités, construire un réseau, puis faire une trace. Je suis sûr que les routines de traçage ESRI sont beaucoup plus rapides que les miennes, mais j'avais un besoin spécifique et je ne pouvais pas le résoudre en utilisant des réseaux géométriques.

J'ajoute ceci pour quiconque à l'avenir lira ce fil.

Voici tout ce que j'ai appris en creusant ce problème et en obtenant une distance complète entre les points d'appel.

Notre premier problème provenait de la nature statique de RasterCatalog. La modification des rasters sur lesquels cela est basé ne modifie PAS le raster dans le RasterCatalog. Il s'est avéré que la nôtre avait une version ancienne qui n'était nulle part près d'une carte du littoral. Leçon apprise: Reconstruisez le RasterCatalog CHAQUE FOIS que vous modifiez les rasters sur lesquels il est basé.

Le raster de distance avec des poids ajoutés devient une chose assez lourde à utiliser. Regardez le scénario suivant: La valeur d'origine du raster est 1 distance totale que je veux regarder est de 117 km. La taille des cellules est de 1 mètre. Si le raster est maintenant une valeur pondérée de 48, alors la distance totale que je veux regarder devient 117 km * 48 !!! Ainsi, la distance dans la méthode CostDistance n'est pas la distance des cellules mais la distance pondérée, apparemment en ajoutant la valeur dans chaque cellule jusqu'à ce que la somme de chaque cellule = la valeur transmise pour la distance totale. Même si la taille de la cellule elle-même est de 1 mètre !!!

Le raster de distance est concentré sur un point d'origine. Ainsi, lorsque vous appelez la routine CostDistance, vous ne souhaitez pas inclure le point d'origine dans cette liste. si vous le faites, vous obtiendrez un point avec une distance de 0. (ce support ESRI même perplexe)

Alors que de nombreuses méthodes utilisent l'enveloppe pour restreindre leur processus, les deux plus coûteuses, en définissant une valeur pour le raster et en extrayant un raster sans zone dans un polygone, ignorent tous les paramètres d'enveloppe et l'appliquent toujours automatiquement à l'ensemble du raster. Malheureusement pour nous, nous ne pouvons que raccourcir cela en créant des segments qui se chevauchent massivement et en affectant un segment à une zone spécifique. Mais ce faisant, nous devons faire attention (ce qui est difficile) à ce qu'une zone d'opération principale n'existe pas dans la mauvaise zone de chevauchement. (en d'autres termes, tous nos chevauchements doivent être soigneusement choisis pour ne contenir aucun point d'intérêt principal!) La raison en est que nous naviguons dans le RasterCatalog en choisissant le raster correct en fonction de l'emplacement du poste de garde côtière choisi. Pour compliquer davantage notre processus, le chevauchement doit nous permettre de naviguer jusqu'à 120 km de notre point d'origine sans sortir du bord de la carte et ne pas chevaucher d'autres points d'intérêt principaux. Sheesh.

La seule autre chose que j'ai apprise est qu'il est facile de faire des calculs mathématiques sur le raster, mais lorsque vous voulez `` percer un trou '' dans le raster (blocages) ou définir un beignet avec une valeur et l'intérieur du beignet ayant un valeur de 1 (retards comme un verrou) vous vous retrouvez avec une combinaison complexe d'outils et d'appels ArcObject. Ce qui conduit à la dernière leçon apprise: ArcObjects ne peut pas tout faire. Je suis donc parfois obligé de faire des choses dans les outils lents et lourds qui étaient tous écrits en python. J'ai également appris que les développeurs d'outils ESRI ne savaient rien du maintien de la cohérence. Parfois, ils prenaient une base de données raster à d'autres moments, ils avaient besoin d'un raster et parfois ils avaient besoin d'un ensemble de fonctionnalités. Et ils ne renvoient pas les données dans le même format dont ils ont besoin en entrée!

Confus? Ne vous inquiétez pas, c'est ESRI.