
Envoyé par
kolodz
Pour rappel un Point en AWT (et donc Swing) les cordonnées sont stocké sous forme d'int Ton "POI" prends en entrée des doubles. Il y a donc au minimum un problème de conversion.
Hum hum hum...

Envoyé par
Javadoc
Class Point2D
java.lang.Object
java.awt.geom.Point2D
All Implemented Interfaces:
Cloneable
Direct Known Subclasses:
Point, Point2D.Double, Point2D.Float
[...]
abstract double
getX()
Returns the X coordinate of this Point2D in double precision.
abstract double
getY()
Returns the Y coordinate of this Point2D in double precision.
abstract void
setLocation(double x, double y)
Sets the location of this Point2D to the specified double coordinates.

Envoyé par
Javadoc
Class Point
java.lang.Object
java.awt.geom.Point2D
java.awt.Point
[...]
getX
public double getX()
Returns the X coordinate of this Point2D in double precision.
Specified by:
getX in class Point2D
Returns:
the X coordinate of this Point2D.
Since:
1.2
getY
public double getY()
Returns the Y coordinate of this Point2D in double precision.
Specified by:
getY in class Point2D
Returns:
the Y coordinate of this Point2D.
Since:
1.2
Bien qu'historiquement AWT et Swing après lui travaillent avec des points contenant des coordonnées entières pour les positionnements à l’écran ou dans des images, Java2D (et donc Graphics2D) supporte les coordonnées en nombre flottant (ce qui a une influence sur le rendu quand les rendering hints appropriés sont bien settés).
Quand tu cliques avec ta souris, tu récupérés des coordonnées écran. Or ton poi dispose a la fois d'un set de coordonnées géographiques (accessibles par getLocation()) et d'un set de coordonnées écran (accessibles par getLocationXY()). Donc tu dois, lors d'un clic, parcourir ta liste de poi et trouver celui en dessous de la souris en comparant les coordonnées écran du curseur et les coordonnées écran des poi. Ensuite tu afficheras les coordonnées géographiques du poi sélectionné.
De plus, le code source de la classe POI montre bien que la lon et la lat sont récupérables via les méthodes getLon() et getLat(). On peut voir également que pour certains constructeurs, la lon et la lat passées en paramètres sont convertis (normalisées ?) avant d’être stockées et surtout avant d'appeler setLocation(). Ce qui est retourné par getLocation() peut donc varier si les coordonnées raw lon et lat on été normalisées auparavant.
Conclusion : -> go lire la doc (et les sources) !
EDIT - mise a jour du lien vers la version la plus récente du code source, je crois.
PS : je trouve sa conversion des coordonnées géographiques en coordonnées écran assez... arbitraire... 
EDIT 2
Note : le code source de la classe Radar semble indiquer qu'il y a en plus une autre transformation effectuée par le rendu, par rapport au point central du radar et également une mise à l’échelle par rapport au facteur de zoom (voir affichage des poi dans paintComponent()). Il faut aussi tenir compte du décalage du aux Insets du composant dans le système de coordonnées (comme d'hab quoi). Il faudra donc faire quelques transformations des coordonnées souris reçues avant de pouvoir les comparer aux coordonnées écran des poi.
1 2 3 4 5 6
|
G2.translate(getFramelessOffset().getX(), getFramelessOffset().getY());
[...]
G2.drawImage(poi.getPoiImage(), (int) (CENTER.getX() - poi.getPoiImage().getWidth() / 2.0 + (poi.getLocationXY().getX() - CENTER_XY.getX()) / pixelScaleX), (int) (CENTER.getY() - poi.getPoiImage().getWidth() / 2.0 + (poi.getLocationXY().getY() - CENTER_XY.getY()) / pixelScaleY), null); |
EDIT 3 - une dernière petite précision par rapport à ce que j'ai écrit au dessus : les coordonnées écran des poi (ce qui inclue le centre du radar qui est également un poi) sont situées dans l'espace de coordonnées virtuelles définies par l'objet WORLD_MAP présent dans chaque poi :
private final Rectangle WORLD_MAP = new Rectangle(0, 0, 40000, 20000);
Il ne s'agit donc pas du même système de coordonnées écran que celles de la souris d’où le fait qu'il faille appliquer des transformations (les transformations inverses de celles effectuées lors de l'affichage) pour passer de l'un a l'autre.
Note : compte tenu des transformations très simplistes qui sont effectuées pour passer des coordonnées géographiques en coordonnées virtuelles écran puis en coordonnées réelles écran, ce radar doit totalement déconner s'il couvre une surface trop grande ou si son centre est situe trop près d'un des deux pôles. Attention lors d'utilisation dans le cadre aéronautique ou lorsque la précision est critique. Il manque un vrai SIG derrière pour faire les bonnes transformations entre les repères.
Partager