[GraphHopper] Distances are 2x wrong?

[Peter K]

Hi Jaak,

cool, this is really great news! As I already wanted to look into this,
but hadn't the time so far.

Regarding 1) The returned value is as expected (normal) meters.
Hopefully I can digg into the code next week.

Regarding 2) ghz is a zipped folder and can be opened via the Helper.unzip

> mapsforge library

Oh, so the mapsforge data can be opened? Nice!

Regarding 3) This will be solved in issue-17. It is the problem of
mapping from "real world gps coordinates" to graph node ids.
You can partially work around this by increasing the precision of
Location2IDQuadtree index
or checkout the master (not really recommended yet, as incompatible file
layout and probably other minor issues)

Regards,
Peter.


> Hello,
>
>  I just pushed a sample with Graphhopper routing to Nutiteq 3D SDK
> AdvancedMap3D samples: https://github.com/nutiteq/hellomap3d/,
> see GraphhopperRouteActivity.java . Nutiteq SDK is quite similar to
> Mapsforge, just with 2.5D perspective and rotation capabilities. And
> with a lot of different data source Layer implementations, from
> geotiff and shapefiles to mapsforge library.
>
>  Issues with grasshopper:
>
> 1) major problem - all the routes in my area (Estonia) are a bit more
> than 2x too short. Instead of 100 km I have 45 or so. Could it be that
> it is so much north and calculations of distances become wrong? If the
> "meter" is really "mercator meter" then the value could be even right,
> but calculation of mercator meters to real meters, when the route is
> from south to north, is not trivial (or not possible at all). I
> created test dataset for Baltics 3
> countries: https://dl.dropbox.com/u/3573333/baltics.ghz , where it is
> observable. 
>
> 2) some minor issues. I did not figure out how to open properly .ghz
> file with the API. So the sample asks now for .map file inside
> <map>_gh folder, so the files must be uncompressed in SDCARD. But it
> would be nicer to enable just to open ghz file, and GH would
> uncompress it automatically.
>
> 3) start and endpoints are sometimes not optimal, quite far from
> clicked location, and there seem to be much closer nodes to given
> points. I added lines from clicked location to first and from last
> location to make it nicer. Maybe some tolerance in graph generation,
> or in routing?
>
>
> Your pull requests with fixes to the demo app are very welcome, quite
> possibly I just did something wrong
>
> Jaak
> Nutiteq.com <http://Nutiteq.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20130404/435174a9/attachment.html>