I am trying to integrate hibernate spatial with JPA for Geo searches. I have been referencing the tutorial on the official site (I am not associated with hibernatespatial).
The tutorial, unfortunately, does not cover how to create a Point instance from a latitude/longitude pair. I'm attempting to do this here, but I am still not sure if this is this the right way to convert a latitude/longitude pair to a JTS Point instance:
import com.vividsolutions.jts.geom.Coordinate;
import com.vividsolutions.jts.geom.GeometryFactory;
import com.vividsolutions.jts.geom.Point;
import org.geotools.geometry.jts.JTSFactoryFinder;
import org.hibernate.annotations.Type;
import javax.persistence.*;
@Entity
public class Location {
private Double latitude;
private Double longitude;
@Type(type = "org.hibernatespatial.GeometryUserType")
private Point coordinates;
private final GeometryFactory geometryFactory = JTSFactoryFinder.getGeometryFactory(null);
@PrePersist
@PreUpdate
public void updateCoordinate() {
if (this.latitude == null || this.longitude == null) {
this.coordinates = null;
} else {
this.coordinates = geometryFactory.createPoint(new Coordinate(latitude, longitude));
}
}
public Double getLatitude() {
return latitude;
}
public void setLatitude(Double latitude) {
this.latitude = latitude;
}
public Double getLongitude() {
return longitude;
}
public void setLongitude(Double longitude) {
this.longitude = longitude;
}
}
JTS doesn't care what your point's units or coordinate system is.
However, it does assume that the coordinates are on a Cartesian plane, so some geometry operations such as distance calculations may be inaccurate over long distances. (They don't yet support geodetic calculations.)
It should be fine for simple storage uses.
However, an important point to note is that the longitude is the X value and the latitude the Y value. So we say "lat/long", but JTS will expect it in the order "long/lat". So you should be using geometryFactory.createPoint(new Coordinate(longitude, latitude))
Here is how to create your coordinate in WGS-84 :
double EARTH_RADIUS = 6378137.0;
double x = longitude * EARTH_RADIUS * Math.PI / 180.;
double y = EARTH_RADIUS * Math.sin(Math.toRadians(latitude));
return new Coordinate(x,y,0.);
Cheers
To sum up what others said, when converting to Coordinate there are 3 main things to take care of:
- Projection. JTS works in a Cartesian plane, so all distortion from e.g. Mercator propagates into your calculation. Thus, you should only use it on quite short-ranged area. I'm not sure about the precise magnitude, but I think everything below a degree of expansion should be fine. Stay below 0.1 degree and you're definitely on the safe side.
- Units. You can put perfectly any unit into JTS. The trouble is you can't tell JTS whether you're using meters, or degrees, or anything else. So you must take care yourself that you either stick to one unit, or convert wherever necessary.
- Standard. The ISO standard states that geospatial coordinates are provided lat first. However, it competes with the GeoJSON/WKT standards which both state lon first, so reverse. Both standard groups have applications sticking to them (for instance, Apache Lucene switched standards between releases without changing the method signature, thus causing headaches to hundreds of users wondering why their maps all of a sudden were flipped), and JTS is holding on the GeoJSON/WKT version. Pay attention to that wherever you pass the data from another library - it may follow GeoJSON and WKT, or ISO, you should inform yourself in advance. (Believe me. I already had trouble with this, and it can be really annoying going through the entire code and flipping the order.)
So, no that's not right. You're straight walking into the third problem. JTS is lon first.
Also, you might consider using Neo4j Spatial instead of hibernate. It uses the graph querying speed of Neo4j, and has built-in JTS support. It also has one of the most comfortable Java APIs around IMHO.
I have had the same problem here and I translated the coords from Lat/Long to UTM (see http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system).
Basically you convert from Lat/Long to an (X,Y) pair, but the interesting fact is that those X and Y are real meters, so you can make accurate calculations which depend on distance. (Actually, you must account for a small distortion, but negligible when talking about meter-scale accuracy).
I wasn't really happy with the LatLong2UTM functions that existing Java frameworks provided, so I rolled out my own. I ported one from some online javascript converter without much trouble.