Retrieving lat/long in 0.3.0

[Michele Mondelli]

Hi all.

I'm using mapsforge 0.3.0.

I'm handling touchevent to get the coordinate (lat/long) of the point.

My code is something like this:

@Override 

public boolean onTouchEvent(MotionEvent motionEvent) {

super.onTouchEvent(motionEvent);

float x = motionEvent.getX();

float y = motionEvent.getY();

Projection proj = this.getProjection();

GeoPoint gpoint = proj.fromPixels((int) x, (int) y);

float latitude = (float) gpoint.getLatitude();

float longitude = (float) gpoint.getLongitude();

}

This way, I get a precision of six decimal.

It's possible to have an higher precision?

Thanks

[Ludwig]

The GeoPoint actually stores latitude and longitude as double, so the first step to get a higher precision would be not to cast to (single precision) float.

But then, the higher precision does not actually mean higher accuracy, it just means junk data. OSM data certainly is not sub-meter accurate, nor is your device's GPS, nor your user's fingertip.

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michele Mondelli]

Yes, I've cast to float because I noticed that nothing changed using a double.

Looking in org.mapsforge.core.GeoPoint, I've seen that this class store lat/long information in two integer value (latitudeE6, longitudeE6).

When creating a GeoPoint object from two double value, the class does the follow:

public GeoPoint(double latitude, double longitude) {

  double limitLatitude = MercatorProjection.limitLatitude(latitude);

  this.latitudeE6 = (int) (limitLatitude * CONVERSION_FACTOR);

  double limitLongitude = MercatorProjection.limitLongitude(longitude);

  this.longitudeE6 = (int) (limitLongitude * CONVERSION_FACTOR);

  this.hashCodeValue = calculateHashCode();

}

The value of CONVERSION_FACTOR is 1000000d, so here is where the class loss the precision. 

Why lat/long values are store in the class as int?

[Ludwig]

Sorry, I was looking at the current master, where the GeoPoint stores lat/lon as double, as does the new LatLong class in rewrite that will replace the GeoPoint in 0.4.

I think the reason for this used to be to avoid floating point operations as much as possible and actually using this much precision is, for general mapping purposes, enough to store the available accuracy: unless you are working with high differential GPS your accuracy will never be that much better than 10m and often much worse (even if your device pretends otherwise: try it by waypointing a point on different days).

Ludwig

[Thilo Mühlberg]

There were actually three reasons why the old GeoPoint implementation
used integers instead of doubles:

1) compatibility with the API of the Google Map Add-On
2) avoid floating point operations and save main memory
3) the binary map format, which stores coordinates as microdegrees

After the 0.3.0 release the GeoPoint class had already been changed to
doubles which is also the implementation in the corresponding LatLong
class in the rewrite branch. As geographical coordinates are degrees, it
makes no sense to store them as integer. Even if our map file format
does (currently) not offer a higher precision, the performance benefit
is negligible. Having coordinates in degrees allows you to easily copy
and paste them into any other map application (e.g. Google Maps) and
avoids confusion and potential bugs. So changing to doubles was really
an improvement and I promise you to never go back to integers again. :-)

Greetings,
Thilo

On 14/06/13 08:19, Ludwig wrote:
> Sorry, I was looking at the current master, where the GeoPoint stores
> lat/lon as double, as does the new LatLong class in rewrite that will
> replace the GeoPoint in 0.4.
>
> I think the reason for this used to be to avoid floating point
> operations as much as possible and actually using this much precision
> is, for general mapping purposes, enough to store the available
> accuracy: unless you are working with high differential GPS your
> accuracy will never be that much better than 10m and often much worse
> (even if your device pretends otherwise: try it by waypointing a point
> on different days).
>
> Ludwig
>
>
>
> On 13 June 2013 20:59, Michele Mondelli <mithe...@gmail.com

> <mailto:mapsforge-dev%2Bunsu...@googlegroups.com>.