Rough polyline to calculate sinuosity

My main target is to get the sinuosity of the root: straights paths, curves radius and curves angles and lengths.
Using Graphhopper Directions API I’m facing an issue that doesn’t satisfy my customer: the polyline returned by GHRequest in GHResponse is too much rough and imprecise.
I’m facing very often these problems:

  1. sometimes the polyline comes out of the street borders i.e. it doesn’t follow the actual line of the street.
  2. curves are represented by too few segments. That doesn’t allow me to measure accurately the curve radius
  3. on long straight paths (more than 100mt), sometimes the polyline reports curves that don’t actually exist.

Do you have some suggestions to get a more precise polyline?
To get my target the polyline should be more accurate.
Do you have some suggestions to get that in a more precise way?

The polyline should be very precise. E.g. look here

Keep in mind that it is important to have up-to-date maps as we update every 1 or 2 days. Also you can try to use the undocumented parameter &wayPointMaxDistance=0.5 and see if this improves the situation.

Do you have examples for these issues either via image or GraphHopper Maps link?

Do you have enabled the response geometry simplification in the GH ?

Also polyline not agreeing with map roads can happen in cases of not concurrent map and graph data (they should be updated simultaneously).

Emux

as @ugochirico is asking about the GH Directions API I’ll answer :slight_smile: (see also the category ‘Directions API’):

we have the defaults enabled (1m for import & routing) which should be precise enough and not causing this trouble I think

Oh sorry about that! :slightly_smiling:

Emux

Oh sorry about that!

Really no problem. Always appreciate your help :slight_smile: !

Hi @karussell,
many thanks for your reply.
here you can see a long and large curve with too few points:
https://graphhopper.com/maps/?point=44.102271%2C10.393099&point=44.102691%2C10.388271&locale=de&vehicle=car&weighting=fastest&elevation=true&layer=Omniscale

Here you can see a polyline that goes out of street borders:
https://graphhopper.com/maps/?point=46.195796%2C13.335777&point=46.195978%2C13.338304&locale=de&vehicle=car&weighting=fastest&elevation=true&layer=Omniscale

Then, in your API (i’m working on iOS) I see:
/**
@brief This parameter specifies how to reduce points via douglas peucker while OSM import.
Higher value means more details, unit is meter. Default is 1. Disable via 0.
*/

  • (GraphHopper *)setWayPointMaxDistanceWithDouble:(jdouble)wayPointMaxDistance;

It seems as default is 1, that is better than 0.5 as you suggest.
is it correct?

@devemux86, the differences in the polyline are not only against the map I used, but they are also against the actual street path.

here you can see a long and large curve with too few points:

The points are probably fewer than the original OSM nodes but not much precision is lost (?) as we remove only points if we can keep the precision within 1m boundary.

Here you can see a polyline that goes out of street borders:

How do you define ‘street border’ :slight_smile: E.g. in the OSM style this is not the case: https://graphhopper.com/maps/?point=46.195788%2C13.335739&point=46.195978%2C13.338304&locale=de&vehicle=car&weighting=fastest&elevation=true&layer=OpenStreetMap

So are you sure you have the precision problem in real world? What exactly is your use case?

Hmmh, I think the documentation is incorrect, but I might be wrong. Please just try and let me know :slight_smile:
also keep in mind that you can (or have to) disable simplification for routing too in your case

but they are also against the actual street path.

In real world? But did you double check that the OSM data is according to real world? I mean we reduce really only a few points within the 1m limit and I would find it strange that a big error is added (but I might be wrong here). Again, your use case would be interesting

BTW: So, you are not working with the Directions API? Then I’ll move then to core->mobile

Many thanks @karussell
I’m working with both web directions API and mobile API
Let me try with simplification disabled and with 0.5 as you suggested.

In my case I see that the polyline I get from Directions API often describes curves and lines that are different from the actual curves and straight lines.

But what exactly does mean WayPointMaxDistance?
in the first link I sent before I see a large curve with distances longer that 1m

OSM stores nodes as they were mapped but often the number of them is too much and does not add precision. Therefor we remove some of them but only if they are within WayPointMaxDistance=1m

I thought a bit about this issue and I still think that 1m should be more than enough (except there is a bug) as most ways are >3m width itself. Also you should consider that the OSM data itself can have offsets or inaccuracy, maybe compare with the Aerial view instead?

Checking your examples with the underlying data, one can see that the Graphhopper polyline points are at the very same position as the nodes that define the ways. What you get is as good as it gets. Graphhopper gives the information back it has and does not add anything to it. (Which I would expect)

If you want a smoother line, you have to interpolate the segments by fitting a spline through the points.
The same way as all the map renderer do it.

If you want it exacter you have to edit the nodes it self. But be aware about the accuracy of areial images: http://wiki.openstreetmap.org/wiki/Accuracy
and
http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Accuracy
there are also discussion on the appropriate number of nodes.

1 Like

Many Thanks, @PassRacer and @karussell.
I understood the real problem now with your help. on some routes, OSM data doesn’t have enough precision to comply with what my customer want. I tried also with other directions api and the precision is similar or worse than graphhopper.
Using spline seems a good suggestion. Do you have an example?
I have a question: using spline may I introduce paths that doesn’t exist?

splinings creates just a smoother curvature via a mathmatical function (where you then could introduce new points or use it as it is): https://en.wikipedia.org/wiki/Spline_(mathematics) or https://en.wikipedia.org/wiki/Spline_interpolation

OSM data doesn’t have enough precision to comply with what my customer want.

Again: I still believe this is already very precise and what you are looking for might be the ‘smoothing’ … but without knowing what you try to do we cannot suggest any meaningful :slight_smile:

Many thanks @karussell,
I agree with you, OSM is precise but I need to smooth the polyline to get more points in order to have a final polyline that approximate better the real route.
I’m going to try with a spline using the web Directions API.
I’ll let you know.

Hi @karussell,
I’m trying to smooth the path by using a spline.
My idea is the following:

  1. get the set of coordinates of the polyline from Directions API
  2. set a spline to get more points by using interpolation
  3. convert the new set of points into a polyline

I know how to get a spline by a given array of points on a 2D space, but I don’t understand how to get a spline from a path formed by a set of geo coordinates like the one I get from Directions API.
You said that this is similar to what navigators do to get smooth paths.
Do you have some suggestions?

I think for a small area you can assume geo coordinates are in a “flat” 2D space. But never tried it myself.

This topic was automatically closed after 12 days. New replies are no longer allowed.