legGeometry simplifation

[Victor Chernetsky]

Hello,

I see that shape of the legGeometry in the response to /plan API is simplified/generalized. 

Is it possible to get that geometry that would match the OSM street shape without simplification?

I'm talking about this portion of the response:

1. plan: {date: 1441382400000,…}
   
1. date: 1441382400000
2. from: {name: "237 (eastbound)", lon: -121.95821665850262, lat: 37.41921832951065, orig: ""}
3. itineraries: [,…]
1. 0: {duration: 3809, startTime: 1441383742000, endTime: 1441387551000, walkTime: 667, transitTime: 2120,…}
1. duration: 3809
2. elevationGained: 0
3. elevationLost: 0
4. endTime: 1441387551000
5. fare: {fare: {,…}}
6. legs: [,…]
1. 0: {startTime: 1441383742000, endTime: 1441383863000, departureDelay: 0, arrivalDelay: 0, realTime: false,…}
1. agencyTimeZoneOffset: -25200000
2. arrivalDelay: 0
3. departureDelay: 0
4. distance: 1188.475
5. duration: 121
6. endTime: 1441383863000
7. from: {name: "237 (eastbound)", lon: -121.95821665850262, lat: 37.41921832951065, departure: 1441383742000,…}
8. interlineWithPreviousLeg: false
9. legGeometry: {points: "amkcFz}jgVEu@GsBC_C@qX@ep@", length: 6}

Thanks,

Victor

[Kyle Ingraham]

Hi Victor. You may have luck using the following:

https://github.com/jieter/Leaflet.encoded

It extends the Leaflet API and allows you to decode Google Maps polyline encoding. I haven't tried it myself yet but plan to. The syntax looks to be very simple.

[Marko Burjek]

Hello Victor,

LegGeometry isn't simplified it's just in Google maps polyline encoding format like Kyle said.

You can use his solution or look into the OTP code for decoding:
https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/client/js/otp/util/Geo.js#L33

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

[Laurent GRÉGOIRE]

Hello,

On 7 September 2015 at 11:02, Marko Burjek <email...@gmail.com> wrote:
> LegGeometry isn't simplified it's just in Google maps polyline encoding
> format like Kyle said.

Well, to be precise the encoding process truncate to 5 decimal places,
so we could call this a "simplification" :)

Also to save memory OTP encode the geometry internally to a
"packed-var-len-int-fixed-float-diff" format which also cause some
rounding approximation, but for most purposes this rounding should be
negligeable (0.11 meter max). As we use a diff-encoding, special care
is taken to not accumulate rounding errors on long segments.

But indeed, apart from that rounding, the original geometry should be preserved.

--Laurent

[Victor Chernetsky]

Hey Guys,

Thanks for the replies. I don't thing the issue is the encoding, or rounding the lat/lon values. Encoding/decoding does not simplifies the geometry. And rounding is negligible. Please look at the screenshot, the routes are skipping some vertices. I'm sure that the geometry comes from OSM data. The base layer is generated using the same OSM data. The question is: can I make the route geometry to be as detailed as OSM original street data?

[Kyle Ingraham]

Are you using Transitive.js? If so, might it be affecting the appearance of the polyline? Also, I've found if there are no shape files for routes in GTFS files OTP will draw a polyline from stop to stop instead of following the exact path of travel.

[Marco Flores]

Hi Kyle.

I'm working with Victor on this project and we are indeed using Transitive.js. The way Transitive draws the route is by using the data we get back from the OTP server. We can fork the library and modify it to work with different inputs, but the main question is more in line to your last comment. Is there a way we can get the actual OSM street shape for a plan instead of just a list of stops? The path drawn using that list of stops looks like a "generalized" geometry and we want a more detailed one (aka the OSM street shape).

Thank you so much for your input!

[Laurent GRÉGOIRE]

Hi Victor,

On 7 September 2015 at 19:20, Victor Chernetsky <vic...@amigocloud.com> wrote:
> Thanks for the replies. I don't thing the issue is the encoding, or rounding
> the lat/lon values. Encoding/decoding does not simplifies the geometry. And
> rounding is negligible. Please look at the screenshot, the routes are
> skipping some vertices. I'm sure that the geometry comes from OSM data. The
> base layer is generated using the same OSM data. The question is: can I make
> the route geometry to be as detailed as OSM original street data?

In that case, you're talking about *transit* segments. If there is no
shape data in the input GTFS, the geometry will indeed be a straight
line between stops from the pattern. This issue has already been
discussed here; from an architecture point of view this is better
handled at the data layer, ie adding shape data to the GTFS input.
There was talk of some projects doing that, reading data from
transit-tagged OSM ways.

HTH,

--Laurent

[Victor Chernetsky]

Hi Laurent,

Are you saying that route geometry comes from GTFS, and not from the OSM? In that case if we would improve the geometry in GTFS that would solve the problem? 

Thanks,

Victor 

[Laurent GRÉGOIRE]

Hi Victor,

On 7 September 2015 at 20:27, Victor Chernetsky <vic...@amigocloud.com> wrote:
> Are you saying that route geometry comes from GTFS, and not from the OSM?

Yes. Well, at least from OTP point of view (nothing prevent you from
generating GTFS shapes from OSM of course).

> In that case if we would improve the geometry in GTFS that would solve the
> problem?

Exactly. You "just have" to provide the shapes.txt in the GTFS with
the geometry for some or all trips.

HTH,

--Laurent

[Victor Chernetsky]

Thank you Laurent! Now I know what to do.

-Victor