Notre projet VB.NET utilise une bibliothèque Java de Vivid Solutoins (com.vividsolutions.jts.geom.geométrie) pour effectuer des calculs de géométrie. L'aide est ici: http://tsusiatsoftware.net/jts/ Javadoc / COM / Vividsolutions / JTS / GEOM / GEOMETRY.HTML
Ce que je ne peux pas comprendre, ce sont les unités spécifiquement pour la propriété tampon, ou une autre distance à ce sujet. Mon programme traite avec des milles nautiques et la documentation ne donne aucune indication si les unités sont degrés, milles, milles marins, kilomètres, pouces, etc.
Quelqu'un a-t-il utilisé cette bibliothèque qui connaît la réponse? Merci d'avance.
4 Réponses :
juger par les Javadocs pour coordonner , il dit:
[Coordonnée est une classe légère utilisée pour stocker des coordonnées sur le plan cartésien à 2 dimensions. Il est distinct du point, qui est une sous-classe de géométrie. Contrairement aux objets de type de type (contenant des informations supplémentaires telles qu'une enveloppe, un modèle de précision et des informations de système de référence spatiales)
Donc, il serait que la géométrie n'a aucune unité en tant que telle, mais point, sa sous-classe, le fait et vous pouvez les spécifier.
Je ne serais pas surpris si la classe de géométrie n'a pas d'unités en tant que telles, et représente simplement le concept de point d'espace dans un système de coordonnées particulier.
Je tire à moi comme celle-ci représente le concept d'un point dans l'espace dans un système de coordonnées 2-D cartésien . Cela ira bien, tant que le programme d'Andy ne traite que de très petites distances dans des milles nautiques. Sinon, la nature ronde de la terre va contrarier les calculs.
Riche - cela ne répond pas au fait que la méthode tampon () prend un double comme un paramètre - c'est un nombre, mais je ne vois pas quelles unités spécifier le numéro de. Markj - je suis d'accord et malheureuse que je fais besoin de gérer à la fois de grandes distances et des zones près des pôles.
Ceci est un ancien poste, mais voici la réponse de quiconque qui cherche, car incroyablement les documents Java n'indiquent pas les unités renvoyées par la méthode. La distance revenue est en degrés d'angle central. Vous pouvez ensuite utiliser n'importe quel nombre de formules pour convertir à votre unité de mesure requise. Le plus simple est de se convertir en radians. 1 radian = 180 degrés divisé par PI (RAD = 180DEG / PI). De là, vous pouvez multiplier les radians par le rayon moyen de la Terre dans votre choix d'unités (6371 km par exemple) pour obtenir une distance entre deux points. Des méthodes plus précises sont également disponibles, mais vous pouvez les regarder sur le net.
Merci tim. Pouvez-vous clarifier une chose que j'étais concernée? En supposant que la Terre soit une sphère parfaite (je sais que cela n'est-ce pas), l'angle de la formule de distance fonctionnerait-il pour n'importe quel emplacement sur Terre? Ou les angles proches des pôles (dans les orientations est-ouest) correspondent-ils à des distances plus petites comme les mêmes angles à l'équateur? Je suppose que les "degrés d'angle central" désigne le premier - et que les angles sont de nombreux degrés appart Les points sont sur le grand cercle qu'ils se distinguent tous les deux. Ce serait génial si vous pouviez confirmer cela. Merci.
Si nous supposons que la Terre est une sphère parfaite, l'angle de la formule de distance fonctionne pour tout point sur Terre. L'angle central est l'angle du Cetner d'un grand cercle à chaque point du cercle. Par conséquent, l'angle central est cohérent à travers la sphère. De là, nous utilisons simplement la géométrie standard pour calculer la longueur de l'arc. Je travaille avec les outils JTS en supposant que l'angle central est présenté d'un modèle sphérique et que les résultats que j'ai réalisés ont été compatibles avec cela.
Étant donné que la Terre est une ellipse, la simplification d'une sphère introduit des erreurs à l'aide de la méthode décrite ci-dessus. Pratiquement, la Terre n'est pas trop loin d'une sphère. Le plus grand et le plus petit rayon de la Terre est de 6378 à l'équateur et 6356 aux pôles. Les petits angles centraux produiront des divergences relativement faibles. Des angles plus grands peuvent produire plus d'erreurs, en fonction du grand cercle mesuré. Pour plus de précision, je suggérerais d'utiliser quelque chose comme la formule Vincingy: Mobile -type.co.uk/scripts/latlong-vincenty.html
Tim, ce n'est pas clair que c'est vrai. J'ai trouvé un certain nombre d'autres docteurs qui affirment que le résultat dépend du système de coordonnées de la GEOM sous-jacente.
-1, je suis d'accord avec @kpw ..C'est-ce que c'est trompeur..jts utilise réellement des coordonnées de cartésion 2D pour la plupart des opérations..z Valeur existent pour certaines opérations. degrés d'angle
Cette réponse n'est pas correcte. Selon leur FAQ, les unités utilisées dépendent de la CRS des fichiers d'entrée: emplacementTech. github.io/jts/jts-faq.html#b5
J'ai confirmé avec l'un des auteur de la bibliothèque et en le testant moi-même en utilisant des fichiers géospatiaux avec différentes prévisions, que les unités de distance dépendent du SRS du fichier source. Ceci est couvert dans leur FAQ ici: https://locationtech.github.io/ JTS / JTS-FAQ.HTML # B5
Un moyen rapide de trouver ceci est de rechercher le code EPSG chez http://epsg.io/ et trouver les unités. Par exemple, EPSG 3347 a des unités de mètres.
Comme je travaillais récemment sur cette bibliothèque ( http: / /tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/geometry.html ) et après enquête, j'ai constaté que la distance de l'unité renvoyée lors de l'appel des méthodes de calcul de la distance avec cette API sera degré unité. Pour le convertir en kilomètre, suppose que la valeur renvoyée est
Pourrait être préférable de leur demander directement