Hi,

The depth option is a really important and useful feature but it's missing from the doc.
I wanted to get all stops from a specfic route and find out about this option by someone on IRC.

Exemple of the depth option :
https://api.navitia.io/v1/coverage/fr-idf/routes/route:RTP:1093630?depth=3

Can you please update the doc ?

On some versions of log4cplus the logger macros must be explicitely included

19:32 < skywavenl> Question:
19:32 < skywavenl> https://github.com/CanalTP/navitia/blob/a64fff0548091ab5257239342d2302275797e828/source/ed/data.cpp#L72
19:32 < skywavenl> Is stop_times_list actually sorted?
19:32 < skywavenl> I'm trying to figure out why it links the wrong journeys
20:53 < skywavenl> Figured it out
20:53 < skywavenl> It's the DST offset interfering with it
20:54 < skywavenl> I got a hack-fix not i'm note sure if there is a better solution which allows a blocktransfer across the DST change.

After the UTC shifting, multiple trips are no longer sorted rightly ordered within the block, thus navitia makes transfers across timezones.
Quick hackfix: but i think there are better solutions, possible by also checking whether the validitypattern overlaps before setting the block-transfers

diff --git a/source/ed/data.cpp b/source/ed/data.cpp
index eb2191a..b4dfe29 100644
--- a/source/ed/data.cpp
+++ b/source/ed/data.cpp
@@ -73,6 +73,8 @@ void Data::build_block_id() {
             [](const types::VehicleJourney* vj1, const types::VehicleJourney* vj2) {
             if(vj1->block_id != vj2->block_id) {
                 return vj1->block_id < vj2->block_id;
+            }else if (vj1->utc_to_local_offset != vj2->utc_to_local_offset){
+                return vj1->utc_to_local_offset < vj2->utc_to_local_offset;
             } else {
                 return vj1->stop_time_list.back()->arrival_time <=
                         vj2->stop_time_list.front()->departure_time;

Hello,

In our process of timetable generation we, sometimes, add some comments on a vehicle_journey. It's mainly used to add an information about something we can't describe in the data.

It's working well with route_schedules but when we made some stop_schedules requests we were expecting to have those comments linked to the stop times, it was not the case.

I don't know if it's something you don't use or if you're proceeding differently. Since the vehicle_journey id is in the links, maybe you are doing another request to get the comments?

Since we were a little bit in a rush I have patched the code to have something like this :

But before doing a PR I want to have your opinion on this.

Patch below (it's really simple) :

diff --git a/source/type/pb_converter.cpp b/source/type/pb_converter.cpp
index 33a3dab..37c5692 100644
--- a/source/type/pb_converter.cpp
+++ b/source/type/pb_converter.cpp
@@ -1313,6 +1313,9 @@ void fill_pb_object(const navitia::type::StopTime* stop_time,
         if(!stop_time->vehicle_journey->odt_message.empty()){
             fill_pb_object(stop_time->vehicle_journey->odt_message, data, hn->add_notes(),max_depth,now,action_period);
         }
+        for (const auto& comment: data.pt_data->comments.get(*stop_time->vehicle_journey)) {
+            fill_pb_object(comment, data, hn->add_notes(), max_depth, now, action_period);
+        }
         rs_date_time->mutable_properties()->set_vehicle_journey_id(stop_time->vehicle_journey->uri);
     }

[Switching to Thread 0x7fffef7a4700 (LWP 26919)]
handle_vj<navitia::routing::VisitorFinalJppAndDate> (current_jpp_idx=<optimized out>, accessibilite_params=..., raptor_=...)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/bits/stl_iterator.h:728
728           __normal_iterator(const _Iterator& __i) : _M_current(__i) { }

Isochrones in combination with the latest dev snapshot results in segfaults.

http://osm.org/go/0E6Ub7Ut3
For example in this situation, to link the stoppoint for foot/bicycle the public_transport=platform way should be preferred above the car road, instead of just looking at distance.

On dev (0.101.2) @ a8a71fa

A request: /v1/coverage/benelux/journeys?from=coord&to=stop_area:9764&datetime=20140812T125802&type=all&max_duration_to_pt=1800&first_section_mode=walking&last_section_mode=walking&datetime_represents=departure

with a lengthy street_network section gives a response 2 minutes before the requested departure-time. This breaks the next/prev functionality.

{
    "journeys": [
        {
            "fare": {},
            "sections": [
                {
                    "links": [],
                    "departure_date_time": "20140812T125604",
                    "duration": 921,
                    "path": [],
                    "id": "section_21_1",
                    "from": {},
                    "arrival_date_time": "20140812T131125",
                    "additional_informations": [
                        "regular"
                    ],
                    "geojson": {},
                    "to": {},
                    "mode": "walking",
                    "type": "street_network"
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T131300",
                    "duration": 540,
                    "id": "section_22_1",
                    "from": {},
                    "arrival_date_time": "20140812T132200",
                    "additional_informations": [],
                    "geojson": {},
                    "display_informations": {},
                    "to": {},
                    "type": "public_transport",
                    "stop_date_times": []
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T132200",
                    "duration": 213,
                    "id": "section_23_1",
                    "from": {},
                    "arrival_date_time": "20140812T132533",
                    "additional_informations": [],
                    "geojson": {},
                    "to": {},
                    "transfer_type": "walking",
                    "type": "transfer"
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T132533",
                    "duration": 927,
                    "id": "section_24_1",
                    "arrival_date_time": "20140812T134100",
                    "additional_informations": [
                        "regular"
                    ],
                    "type": "waiting"
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T134100",
                    "duration": 4500,
                    "id": "section_25_1",
                    "from": {},
                    "arrival_date_time": "20140812T145600",
                    "additional_informations": [],
                    "geojson": {},
                    "display_informations": {},
                    "to": {},
                    "type": "public_transport",
                    "stop_date_times": []
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T145600",
                    "duration": 294,
                    "id": "section_26_1",
                    "from": {},
                    "arrival_date_time": "20140812T150054",
                    "additional_informations": [
                        "regular"
                    ],
                    "geojson": {},
                    "to": {},
                    "transfer_type": "walking",
                    "type": "transfer"
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T150054",
                    "duration": 906,
                    "id": "section_27_1",
                    "arrival_date_time": "20140812T151600",
                    "additional_informations": [
                        "regular"
                    ],
                    "type": "waiting"
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T151600",
                    "duration": 1380,
                    "id": "section_28_1",
                    "from": {},
                    "arrival_date_time": "20140812T153900",
                    "additional_informations": [
                        "has_date_time_estimated",
                        "regular"
                    ],
                    "geojson": {},
                    "display_informations": {},
                    "to": {},
                    "type": "public_transport",
                    "stop_date_times": []
                },
                {
                    "links": [],
                    "departure_date_time": "20140812T153900",
                    "duration": 18,
                    "id": "section_29_1",
                    "from": {},
                    "arrival_date_time": "20140812T153918",
                    "additional_informations": [
                        "regular"
                    ],
                    "geojson": {},
                    "to": {},
                    "mode": "walking",
                    "type": "crow_fly"
                }
            ],
            "tags": [],
            "departure_date_time": "20140812T125604",
            "requested_date_time": "20140812T125802",
            "duration": 9794,
            "nb_transfers": 2,
            "arrival_date_time": "20140812T153918",
            "type": "best"
        }
    ]
}

As I'm reading through the source I notice that there is a mix of French and English comments. Has a decision been made to use English as the Navitia working language? If so are you interested in comment translation pull requests?

In thermometer of the following

{1,2},{3,2},{0,1,2},{0,3,2}

is

{0,1,3,2}

But thermometer of (two last are inverted)

  {1,2},{3,2},{0,3,2},{0,1,2}

is

{1,0,1,3,2}

The last one cause bad things in route_schedules (same stop displayed twice)

The thermometer algorithm looks touchy, so I would like to agree with you that this behaviour is wrong before doing something.

My proof, these tests pass :

BOOST_AUTO_TEST_CASE(t16) {
    Thermometer t;
    std::vector<vector_idx> req;
    req.push_back({1,2});
    req.push_back({3,2});
    req.push_back({0,3,2});
    req.push_back({0,1,2});

    t.generate_thermometer(req);
    auto result = t.get_thermometer();

    BOOST_REQUIRE_EQUAL(result[0], 1);
    BOOST_REQUIRE_EQUAL(result[1], 0);
    BOOST_REQUIRE_EQUAL(result[2], 1);
    BOOST_REQUIRE_EQUAL(result[3], 3);
    BOOST_REQUIRE_EQUAL(result[4], 2);
}

BOOST_AUTO_TEST_CASE(t17) {
    Thermometer t;
    std::vector<vector_idx> req;
    req.push_back({1,2});
    req.push_back({3,2});
    req.push_back({0,1,2});
    req.push_back({0,3,2});

    t.generate_thermometer(req);
    auto result = t.get_thermometer();

    BOOST_REQUIRE_EQUAL(result[0], 0);
    BOOST_REQUIRE_EQUAL(result[1], 1);
    BOOST_REQUIRE_EQUAL(result[2], 3);
    BOOST_REQUIRE_EQUAL(result[3], 2);
}

In a routes_schedules request, comment (notes) on lines are displayed at service level instead of line level.
This seems to be a bug (accordingly to Stephan Simart :-)

I would like to correct this myself, but I am waiting for exact instruction about what should be the correct behaviour.

cmake must check about the presence of postgres headers.

Package libpq-dev and libpqxx-dev on debian.

When trying to build Navitia, I have this error:

CMake Error at type/CMakeLists.txt:118 (add_executable):
Cannot find source file:

tests/code_container_test.cpp

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

Could you have a look at this?

Thanks.

Some parts call log4cplus instead of going throug the small wrapper in utils

Hi !

As discussed on IRC, libgoogle-perftools-dev on Ubuntu 12.04 is in version 1.7 and use deprecated headers since version 2.0.

navitia/source/kraken/data_manager.hy:37:41: fatal error: gperftools/malloc_extension.h: No such file or directory
The right path for this version is google/malloc_extension.h

Thanks !

README is out of date. Could it be updated? Right now I cannot understand how to get a GTFS dataset into kraken

Hi!
One question. The doc page (https://github.com/CanalTP/navitia/blob/dev/documentation/navitia.io/source/integration.rst) states:
get /coverage/lon;lat/collection_name > Collection of objects of a region
and Collections are

• lines
• ...
• stop_points
• stop_areas

However, I cannot seem to be able to get e.g. https://api.navitia.io/v1/coverage/2.6667;48.7667/stop_areas or https://api.navitia.io/v1/coverage/2.6667;48.7667/stop_points to work. I get the error: "No region nor coordinates given"
It should also work with https://api.navitia.io/v1/coverage/2.6667;48.7667/lines.

In the meanwhile, i can use https://api.navitia.io/v1/coverage/2.6667;48.7667/places_nearby?type[]=stop_area&distance=10000 but it is less graceful :D

cmake must check about the presence of zeromq headers.

Package libzmq-dev on debian.

In the routes.txt file, the school_vehicle_type field is precising if a bus is a regular one, a school bus or both (with the possible values 0,1,2).
It may be more explicit to rename the field "transport_type", and eventually to have a string enumeration list (with restricted values).
Any comment ?

On the latest dev snapshot, some occurrence results in a segfault:

[Switching to Thread 0x7ffff2fab700 (LWP 13411)]
0x000000000061c51d in navitia::routing::get_walking_solutions (clockwise=false, departs=std::vector of length 94, capacity 94 = {...}, 
    destinations=std::vector of length 117, capacity 117 = {...}, best=..., disruption_active=false, accessibilite_params=..., raptor=...)
    at /opt/navitia/source/routing/raptor_solutions.cpp:229
229                                         if(raptor.data.pt_data->journey_pattern_points[final_rpidx]->stop_point->idx == spid_dep.first) {

print final_rpidx
$1 = 4294967295

final_rpidx looks dodgy, will investigate later

For all requests with counter-clockwise searches a response is given with a very long crow_fly (hours) where 0 seconds is expected.

It deletes all the stoppoints with stoparea, resulting in not being able to find stops for a lot of records in stop_times.txt.
Reading at the code, i think this is only a issue with feeds that do not contain a stoparea for all stops.

In order to manage cross-reference to note, we want to add a new field to the "Comment" object : comment_label

This text field contains the letter(s) or symbol used in the cross-reference, for instance to comment a trip in Timetable. This allows the data provider to choose the label reffering to a certain kind of note.

This issue concerns the NTFS file : comment.txt and the note API object.

E.g.
{

• id:114
• type:note
• label:'e'
• value:'Except wednesday'

}

A simple install.txt at root should be enough.

A tutorial to get every thing running would also be useuful

https://github.com/CanalTP/navitia/blob/dev/source/routing/raptor.cpp#L105
Here a 120 is pulled from out of nowhere, my interpretation of it is that it sets what we call at Bliksem slacktime. An extra buffer time between the arrival and any departure, even at the same stop.

If that's the case a feature request: allow the slacktime to be configured by the request. This allows passengers to request extra transfer time, for example if they have lots of baggage.

Bonjour à tous,

http://api.navitia.io/v1/coverage/paris/stop_points/stop_point:RTP:SP:3952734/departures

Est-ce que vous pouvez mettre des - et : dans les datetimes? C'est la seule format de iso8601 qui est bien supporté par le javascript des navigateurs.

To be discussed? :)

Especially on long streets, it's desirable to enable exact search on housenumbers.

Some parameters (like "${CMAKE_BINARY_DIR}/config.h" and "${CMAKE_SOURCE_DIR}/type") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like semicolons.

I would recommend to apply advices from a Wiki article.

A new version of eos should be used

https://github.com/CanalTP/navitia/blob/dev/source/georef/street_network.h#L41

The work done in SpeedDistanceCombiner is significant, and 10% of the total computation time of the kraken program.

The broker mechanism in https://github.com/CanalTP/navitia/blob/dev/source/kraken/kraken_zmq.cpp is connecting a ROUTER socket to a DEALER socket via a ZMQ_QUEUE device. This may not be the optimal load balancing approach.

The DEALER socket's outgoing routing strategy is round-robin: one message is sent to each worker 1..N, then the DEALER starts over again at worker 1. Conceptually, if not internally, the messages are pre-assigned to a worker where they queue up. For a request/response based system (like Navitia or RRRR) this can work well enough if each work unit takes almost the same amount of time to complete. However, if there is significant variance in computation time per work unit and/or a limited number of worker processes, clients will perceive unnecessary latency when their request is stuck in line behind a slow calculation on their assigned worker. In this case, there is an advantage to using a load-balancing pattern where the workers signal the broker that they are available, and work units are handed out to the workers in the order that the workers become available.

By way of analogy, compare a store where separate queues form at each cash register (and there is no 10-items or less register), versus a public administration or railway ticket office where an agent is dynamically assigned to each client as the agents become available (using paper tickets and screens). The second option gives clients faster service when some operations take much longer than others.

Note 1: I am more familiar with the ZMQ C API, so it is possible you have already accounted for this and I am misunderstanding something about zmq::device.

Note 2: If there are no outlier requests that take significantly longer than the mean processing time, then there is no need for a more sophisticated load balancing mechanism.

Comment associated to a vehicule_journey does not appears in route_schedules responses.

In route_schedules header section we see that there is no comment (nor notes) for id "vehicle_journey:15692620"

request

http://srv-dev03/v1/coverage/tisseo_fh/routes/route:96_A/route_schedules?from_datetime=20150413T040000&calendar=Y2FsZW5kYXI6NDI&show_codes=true

response

{"display_informations": 
{"direction": "Fenouillet Ctre Cial",
"code": "30",
"description": "",
"color": "26ceff",
"physical_mode": "Bus",
"headsign": "Fenouillet Ctre Cial",
"commercial_mode": "Bus",
"equipments": [ ],
"network": "Tisséo",
"label": "30"},
"additional_informations": 
["has_date_time_estimated"],
"links": [
{"type": "line",
"id": "line:30"},
{"type": "vehicle_journey",
"id": "vehicle_journey:15692620"},
{"type": "route",
"id": "route:96_A"},
{"type": "commercial_mode",
"id": "commercial_mode:3"},
{"type": "physical_mode",
"id": "physical_mode:3"},
{"type": "network",
"id": "network:1"}]},

As you can see a direct request to the given vehicule journey return correctly the comment (m - Uniquement le mercredi)

http://srv-dev03/v1/coverage/tisseo_fh/vehicle_journeys/vehicle_journey:15692620

{"vehicle_journeys": [
{
"comment": "m - Uniquement le mercredi",
"validity_pattern": 
{"beginning_date": "20150407",
"days": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000100000010000001000000100000010000001000000100000010000001000000100000010"},
"name": "Fenouillet Ctre Cial",
"journey_pattern": 
{"name": "Fenouillet Ctre Cial",
"id": "journey_pattern:30-42"},
"id": "vehicle_journey:15692620",
"stop_times": [
{
...

So please add comment or notes section in links of vehicule_journey on route_schedule header

Bonjour,

les geojson retournés par l'API journeys ne sont pas vraiment tout à fait exploitables facilement ...
La latitude et la longitude sont inversées.

[[2.3762837213091883, 48.84680772319328], [2.3762837213091883, 48.84680772319328], [2.376169, 48.846863], [2.376187, 48.846921], [2.375306, 48.847345], [2.373996, 48.847983], [2.373851, 48.848052], [2.373122125174149, 48.848405130285556], [2.373124, 48.848409]]

https://github.com/CanalTP/navitia/blob/dev/source/ed/data.cpp#L65 segfaults if a trip doesn't have any stop_times.

https://github.com/CanalTP/navitia/blob/dev/source/cmake_modules/FindProtoc.cmake#L13

    if(NOT LOG4CPLUS_FIND_QUIETLY)

Looks very out of place, copy/paste error?

I'm trying to remove the PHP dependency of navitia-explorer : https://github.com/CanalTP/navitia-explorer/issues/15
No problem with the navitia end point, but Tyr won't let me make a JS call.
Please, help ^^

With all the dependencies that are listed installed, getting this linker error at 48% of the compile:

/usr/bin/ld: CMakeFiles/osm2ed.dir/osm2ed.cpp.o: undefined reference to symbol 'inflate'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line

Currently a geocoded name is used as the starting/end point of any streetnetwork section.
If for the request from stop_area:orig to stop_area_dest the street_network is used from stop_area:orig to stop_area:boarding then it would be desirable to also use the names of those two stop_area's for the from/to in the section
Same applies for the last section

Hello,

We talked a little bit about it with @stifoon and @kinnou02 this morning on the phone.
If I do a request on api.navitia.io for the line 22bis with a filter on the code (https://api.navitia.io/v1/coverage/fr-idf/lines?filter=line.code=22bis&depth=0) I have a result :

{
    code: "22bis",
    name: "22bis Marché",
    closing_time: "112500",
    opening_time: "083500",
    id: "line:OIF:067067022:22bisOIF376"
}

But if I want to filter on the name (https://api.navitia.io/v1/coverage/fr-idf/lines?filter=line.name="22bis%20March%C3%A9"&depth=0) I have an error :

{
    message: "'ascii' codec can't encode character u'\xe9' in position 21: ordinal not in range(128)"
}

I have the same problem on my local navitia instance, mainly when I want to filter by network name, since our network is called Tisséo. I use python 2.7.
In https://github.com/CanalTP/navitia/blob/dev/source/jormungandr/jormungandr/interfaces/v1/Uri.py#L106 I tried to change :

if is_collection:
    parser.add_argument("filter", type=str, default="", description="The filter parameter")

To :

if is_collection:
    parser.add_argument("filter", type=unicode, default="", description="The filter parameter")

It seems to work, I just need to use double quotes, but I think it's normal :
http:///v1/coverage/tisseo/lines?filter=network.name=Tisséo => doesn't work (Unable to parse :Filter: Unable to parse the whole string. Not parsed: >>éo<<")
http:///v1/coverage/tisseo/lines?filter=network.name="Tisséo" => 👍

I'm not sure the fix is that simple, but that is what I found :).

The GTFS specification allows stop times to be empty as long as the first and the last stop have a time associated. This is currently not possible with Navitia. Stop times defined this way are just deleted with this warning:

sorting stoptimes of vehicle_journeys
invalid vj 4446_dst_1, the stop times are not correcly ordered stop time 1 [76500, 76500] stop time 2 [10799, 10799] we erase the VJ
invalid vj 4446_dst_2, the stop times are not correcly ordered stop time 1 [72900, 72900] stop time 2 [7199, 7199] we erase the VJ

This is what the GTFS specification says about stop_times.txt:

If this stop isn't a time point, use an empty string value for the
arrival_time and departure_time fields. Stops without arrival times
will be scheduled based on the nearest preceding timed stop. To ensure
accurate routing, please provide arrival and departure times for all stops
that are time points. Do not interpolate stops.

You must specify arrival and departure times for the first and last stops in a trip.

So in order to properly implement the GTFS format, Navitia should be able to handle empty stop times and interpolate the times as best as it can. A sample python implementation is available from google/transitfeed.

Hi guys,

I've a problem with API journeys:

• The parameter count is not used, but it's checked:

  http://api.navitia.io/v1/journeys?from=stop_point:ONA:SP:COME3&datetime=20140322100000&count=10
  http://api.navitia.io/v1/journeys?from=stop_point:ONA:SP:COME3&datetime=20140322100000&count=toto

• This API is not paginated ?

Sorry for my English, I prefer the French ;-)

Say hello to everyone for me

Hi,

According to the documentation, the journey API requires that a datetime is provided in the call.

But the truth is that the journey API will silently proceed even without any datetime, returning some default datetime for departure: 13:XX.

I didn't try to see what can be done with this bug.
EDIT: https://github.com/CanalTP/navitia/blob/df3523038e601b1472551141f90d6ba303ed4145/source/jormungandr/jormungandr/interfaces/v1/Journeys.py#L517
It seems to be the line which cause this bug. A required attribute might be missing here?

But it would be cool to return an error that the parameter required is not provided.

OpenTripPlanner generates custom names for ways without names based on the tags applied, to still allow some form of directions over paths without name.
Ideally this would be done in a way it allows for localization at the end-point level.

For example: https://github.com/opentripplanner/OpenTripPlanner/blob/master/otp-core/src/main/java/org/opentripplanner/graph_builder/impl/osm/DefaultWayPropertySetSource.java#L479

Several persons told me that the format name "NTFS" colides with the File System and that we should change the name.
Do you agree ?

Since #309 clang (3.4) no longer compiles.

In file included from /opt/navitia/source/ed/data.cpp:31:
In file included from /opt/navitia/source/ed/data.h:32:
In file included from /opt/navitia/source/ed/types.h:38:
In file included from /opt/navitia/source/type/type.h:33:
/opt/navitia/source/type/datetime.h:103:17: error: overloaded 'operator+' must have at least one parameter of class or enumeration type
inline DateTime operator+(DateTime time, duration dur) {
                ^
/opt/navitia/source/type/datetime.h:103:17: note: in instantiation of function template specialization 'navitia::operator+<const char *>' requested here
inline DateTime operator+(DateTime time, duration dur) {
                ^
In file included from /opt/navitia/source/type/type.cpp:31:
In file included from /opt/navitia/source/type/type.h:33:
/opt/navitia/source/type/datetime.h:103:17: error: overloaded 'operator+' must have at least one parameter of class or enumeration type
inline DateTime operator+(DateTime time, duration dur) {
                ^
/opt/navitia/source/type/datetime.h:103:17: note: in instantiation of function template specialization 'navitia::operator+<const char *>' requested here
inline DateTime operator+(DateTime time, duration dur) {
                ^
In file included from /opt/navitia/source/routing/routing.cpp:31:
In file included from /opt/navitia/source/routing/routing.h:33:
In file included from /opt/navitia/source/type/pt_data.h:32:
In file included from /opt/navitia/source/type/type.h:33:
/opt/navitia/source/type/datetime.h:103:17: error: overloaded 'operator+' must have at least one parameter of class or enumeration type
inline DateTime operator+(DateTime time, duration dur) {
                ^
/opt/navitia/source/type/datetime.h:103:17: note: in instantiation of function template specialization 'navitia::operator+<const char *>' requested here
inline DateTime operator+(DateTime time, duration dur) {
                ^
In file included from /opt/navitia/source/fare/fare.cpp:31:
In file included from /opt/navitia/source/fare/fare.h:34:
In file included from /opt/navitia/source/routing/routing.h:33:
In file included from /opt/navitia/source/type/pt_data.h:32:
In file included from /opt/navitia/source/type/type.h:33:
/opt/navitia/source/type/datetime.h:103:17: error: overloaded 'operator+' must have at least one parameter of class or enumeration type
inline DateTime operator+(DateTime time, duration dur) {
                ^
/opt/navitia/source/type/datetime.h:103:17: note: in instantiation of function template specialization 'navitia::operator+<const char *>' requested here
inline DateTime operator+(DateTime time, duration dur) {
                ^

En été, en France, nous sommes en temps GMT+2.

Nous avons des services "Noctambus" qui roule de 1h à 4h du matin.
Nous avons découvert une anomalie dans les résultats de routes_schedules avec ces services.

J'ai un peu regardé le code (voir mes idées sur la correction à la fin) et Stephan m'a dit de vous passer le bébé car il y a plein d'effet de bord, notament sur les lignes à fréquence que je voudrais éviter.
Donc j'ai reproduit un use case simplifié dans un NTFS et je vous le décrit ci dessous :

Description de l'anomalie

Contexte

Voici le lien du NTFS utilisé : http://web31srv.tisseo.fr/NTFS_GMT2.zip

En gros il n'y a qu'une ligne, qu'une route avec 3 trips passant sur un unique calendrier WE valable du 1/7/2016 au 31/7/2016.
Il y a seulement 3 arrêts 1, 2 et 3.

Ces trips partent à 0h50, 1h50, et 2h50 (ci dessous les stop_times)

`trip_id,stop_id,stop_sequence,arrival_time,departure_time,stop_headsign,pickup_type,drop_off_type,date_time_estimated
2,1,1,00:50:00,00:50:00,,0,0,1
2,2,2,01:05:00,01:05:00,,0,0,1
2,3,3,01:15:00,01:15:00,,0,0,1
3,1,1,01:50:00,01:50:00,,0,0,1
3,2,2,02:05:00,02:05:00,,0,0,1
3,3,3,02:15:00,02:15:00,,0,0,1
4,1,1,02:50:00,02:50:00,,0,0,1
4,2,2,03:05:00,03:05:00,,0,0,1
4,3,3,03:15:00,03:15:00,,0,0,1

Ce qui se passe

Quand on appelle route_schedules sur l'unique route

http://srv-dev04/v1/coverage/tisseo_fh/routes/route:1_A/route_schedules?from_datetime=20160704&calendar=Y2FsZW5kYXI6OA&show_codes=true

on obtient:

date_times": [
{
    "date_time": "20160702T025000",
},
{
    "date_time": "20160703T005000",
},
{
    "date_time": "20160703T015000",
}

Vous avez bien vu : le service de 2h50 est en premier et les services suivants ont été décalés d'un jour.

Ce qui devrait se passer

On devrait obtenir la réponse suivante

date_times": [
{
    "date_time": "20160702T005000",
},
{
    "date_time": "20160702T015000",
},
{
    "date_time": "20160702T025000",
},

J'espère qu'on est d'accord :-)

Suggestion de correction

J'ai compris que route_schedules avait deux manière différente de répondre suivant qu'on lui passe un calendar ou pas.
Le problème a lieu avec le calendar.

Dans ce contexte, il n'y a pas de référence à de véritables jours.
Or quand le NTFS est lu et enregistré dans ED on stocke le nombre de seconde après minuit + GMT offset

ed_fh=# select vehicle_journey_id, departure_time from stop_time;
 vehicle_journey_id | departure_time
--------------------+----------------
                  0 |          82200
                  1 |          85800
                  2 |           3000

Or à l'import on ne veut pas que ça dépasse 86400 pour le premier stop du trip.
Donc 2h50 su mat devient 3000s au lieu de 89400
Et pour que le calculateur sache bien le jour d'application, il y a un décallage du bitmask du calendrier associé au vehicule_journey (via shift_times de types.h).

Et ensuite quand le calculateur est démarré, on d'afficher les heures sans lire le décallage de bitmask.
Comme on a pas de référence jour (puisqu'on a demandé les passage pour un grid_calendar donné) on se vautre.

J'avais commencé un patch, mais ça ne marche pas et je me suis arrêté après avoir parlé à Stephan.
Mais ça permet de voir ou est le code à toucher :

J'essayait de recaler tous les résultats sur la même date.

diff --git a/source/time_tables/get_stop_times.cpp b/source/time_tables/get_stop_times.cpp
index ac43c79..5324506 100644
--- a/source/time_tables/get_stop_times.cpp
+++ b/source/time_tables/get_stop_times.cpp
@@ -160,12 +160,22 @@ get_all_stop_times(const type::JourneyPatternPoint* jpp,
     }

     std::vector<std::pair<DateTime, const type::StopTime*>> res;
+    boost::gregorian::date first_vj_date;
+    bool is_first_vj = true;
     for (const auto vj: vjs) {
         //loop through stop times for stop jpp->stop_point
         const auto& st = *(vj->stop_time_list.begin() + jpp->order);
         if (! st.vehicle_journey->accessible(vehicle_properties)) {
             continue; //the stop time must be accessible
         }
+       if(is_first_vj) {
+            first_vj_date = vj->validity_pattern->beginning_date;
+            is_first_vj = false;
+        }
         if (st.is_frequency()) {
             //if it is a frequency, we got to expand the timetable

@@ -183,11 +193,17 @@ get_all_stop_times(const type::JourneyPatternPoint* jpp,
                 }

                 //we need to convert this to local there since we do not have a precise date (just a period)
-                res.push_back({time + freq_vj->utc_to_local_offset, &st});
+                if(first_vj_date < vj->validity_pattern->beginning_date)
+                    res.push_back({(time + freq_vj->utc_to_local_offset)%DateTimeUtils::SECONDS_PER_DAY, &st});
+                else
+                    res.push_back({time + freq_vj->utc_to_local_offset, &st});
             }
         } else {
             //same utc tranformation
-            res.push_back({st.departure_time + vj->utc_to_local_offset, &st});
+            if(first_vj_date < vj->validity_pattern->beginning_date)
+                res.push_back({(st.departure_time + vj->utc_to_local_offset)%DateTimeUtils::SECONDS_PER_DAY, &st});
+            else
+                res.push_back({st.departure_time + vj->utc_to_local_offset, &st});
         }
     }

Bon courage à Antoine (je crois que c'est lui qui a gagné le gros lot)

Hello,

Currently a JSON route object contains information about the route name, id and associated line, e.g.

route: {
  name: "Pont Neuf - Porte de Pantin",
  is_frequence: "False",
  line: {
  comment: "",
  code: "75",
  name: "Pont Neuf - Porte de Pantin",
  color: "ffcd02",
  id: "line:RTP:1125156"
  },
  id: "route:RTP:1125156"
}

When using the routes or departures API, it can be very useful to get information about the last stop point of the route, aka terminus.

Would it be possible to provide at least the terminus name in the route object?

Cheers.

Error in rtree when loading OpenStreetMap data

Error from Debian stable, gcc version 4.9.2.
The error occur with file greater than very small file. Any where the pbf come from (geofabrik, mapzen, metro.teczno.com)

X:~/navitia/gtfs$ ../release/ed/osm2ed --connection-string "user=fred dbname=navitia password=123" --input paris.osm.pbf
NOTICE:  TRUNCATE cascade sur la table « edge »
NOTICE:  TRUNCATE cascade sur la table « rel_admin_admin »
NOTICE:  TRUNCATE cascade sur la table « rel_way_admin »
NOTICE:  TRUNCATE cascade sur la table « poi_properties »
[INFO] Reading the fileparis.osm.pbf
[INFO] We finished reading the file
[INFO] Reading the fileparis.osm.pbf
I don't know what to do with: foot=yes; designated
I don't know what to do with: bicycle=dismounted
[INFO] We finished reading the file
[INFO] Reading the fileparis.osm.pbf
[INFO] We finished reading the file
osm2ed: /home/fred/navitia/source/third_party/RTree/RTree.h:1390: void RTree<DATATYPE, ELEMTYPE, NUMDIMS, ELEMTYPEREAL, TMAXNODES, TMINNODES>::Classify(int, int, RTree<DATATYPE, ELEMTYPE, NUMDIMS, ELEMTYPEREAL, TMAXNODES, TMINNODES>::PartitionVars*) [with DATATYPE = const ed::connectors::OSMRelation*; ELEMTYPE = double; int NUMDIMS = 2; ELEMTYPEREAL = double; int TMAXNODES = 8; int TMINNODES = 4]: Assertion `PartitionVars::NOT_TAKEN == a_parVars->m_partition[a_index]' failed.
FATAL - We received signal: 6, so it's time to die!! version: v1.22.4-24-ga14338f
ERROR - ../release/ed/osm2ed(navitia::get_backtrace()+0x27) [0xd78a94]
../release/ed/osm2ed(navitia::print_backtrace()+0x9f) [0xd7d3cb]
../release/ed/osm2ed() [0xd6bc93]
/lib/x86_64-linux-gnu/libc.so.6(+0x35180) [0x7002059bc180]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7002059bc107]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7002059bd4e8]
/lib/x86_64-linux-gnu/libc.so.6(+0x2e226) [0x7002059b5226]
/lib/x86_64-linux-gnu/libc.so.6(+0x2e2d2) [0x7002059b52d2]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Classify(int, int, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::PartitionVars*)+0x62) [0xdadc24]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::PickSeeds(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::PartitionVars*)+0x217) [0xdadbbf]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::ChoosePartition(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::PartitionVars*, int)+0x99) [0xda7f27]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::SplitNode(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**)+0xb4) [0xda0552]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::AddBranch(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**)+0x102) [0xd92e5a]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::InsertRectRec(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const&, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**, int)+0x281) [0xd92c5d]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::InsertRectRec(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const&, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**, int)+0xd8) [0xd92ab4]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::InsertRectRec(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const&, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**, int)+0xd8) [0xd92ab4]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::InsertRectRec(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const&, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node*, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**, int)+0xd8) [0xd92ab4]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::InsertRect(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Branch const&, RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Node**, int)+0x86) [0xd889d8]
../release/ed/osm2ed(RTree<ed::connectors::OSMRelation const*, double, 2, double, 8, 4>::Insert(double const*, double const*, ed::connectors::OSMRelation const* const&)+0xa3) [0xd81cf7]
../release/ed/osm2ed(ed::connectors::OSMCache::build_relations_geometries()+0x17a) [0xd6de56]
../release/ed/osm2ed(main+0x4c7) [0xd77491]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7002059a8b45]
../release/ed/osm2ed() [0xd6b96e]

Abandon

When querying for departures I need to know the physical mode of each departure to show it properly in my app.

Would it be possible to include a physical_mode object in the response to departures and stop_schedules queries?

Alternatively, I could of course make separate requests to get the physical mode for each
departure. But I guess it is also in your interest to not require users to make unnecessary excessive queries to your service.