Merge pull request #4274 from stifoon/patch-2

Some typo on external URL

Author: azime

documentation/slate/source/includes/interface.md

@@ -4,7 +4,7 @@ Interface
 The base URL for **navitia.io** is:
 <https://api.navitia.io/v1/>
 
-We aim to implement [HATEOAS](http://en.wikipedia.org/wiki/HATEOAS)
+We aim to implement [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS)
 concept with Navitia.
 
 Every resource returns a response containing a links object, a paging

documentation/slate/source/includes/objects.md

@@ -538,7 +538,7 @@ Severity object can be used to make visual grouping.
 | Field         | Type       | Description
 |---------------|------------|---------------------------------------------
 | id            |string      |Identifier of the address
-| content_type  |string      |Like text/html, you know? Otherwise, take a look at <http://www.w3.org/Protocols/rfc1341/4_Content-Type.html>
+| content_type  |string      |Like text/html, you know? Otherwise, take a look at <https://www.w3.org/Protocols/rfc1341/4_Content-Type.html>
 | name          |string      |name of the Channel
 
 ### Period
@@ -666,7 +666,7 @@ You can find pathways in [journeys](#journeys) service, where there is some "via
 |zip_code|string|Zip code of the admin|
 
 Cities are mainly on the 8 level, dependant on the country
-(<http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative>)
+(<https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative>)
 
 
 ### <a name="equipment-reports"></a>Equipment reports

documentation/slate/source/includes/realtime.md

@@ -39,7 +39,7 @@ A disruption is present in the response of the endpoints described if the reques
 
 Several public transport objects have separate collections for `base_schedule` and `realtime`.<br>So the data_freshness parameter may affect the number of objects returned depending on the request.
 
-For example when looking for a specific circulation with the collection vehicle_journey using the request:<br>`http://api.navitia.io/v1/coverage/<toto>/vehicle_journeys?since=20191008T100000&until=20191008T200000&data_freshness=base_schedule`.
+For example when looking for a specific circulation with the collection vehicle_journey using the request:<br>`https://api.navitia.io/v1/coverage/<toto>/vehicle_journeys?since=20191008T100000&until=20191008T200000&data_freshness=base_schedule`.
 
 A vehicle_journey circulating between since and until that is **fully deleted** (NO_SERVICE) by a disruption will
 of course be **visible** if `data_freshness=base_schedule`.<br>But it **will not appear** with the parameter `data_freshness=realtime` as it does not exist in that collection.
@@ -85,7 +85,7 @@ See the [disruption](#disruption) objects section for its full content and descr
 
 ``` shell
 # Request example for /journeys
-http://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
 ```
 
 ``` shell
@@ -165,7 +165,7 @@ A list of the disruptions impacting the journey is also present at the root leve
 
 ``` shell
 # Request example for /departures (data_freshness=realtime by default)
-http://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/stop_areas/<stop_area>/departures?from_datetime=<from_date>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/stop_areas/<stop_area>/departures?from_datetime=<from_date>&data_freshness=realtime
 ```
 
 ``` shell
@@ -220,7 +220,7 @@ A list of the disruptions impacting the departures is also present at the root l
 
 ``` shell
 # Request example for /stop_schedules (data_freshness=realtime by default)
-http://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/stop_schedules?from_datetime=<from_date>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/stop_schedules?from_datetime=<from_date>&data_freshness=realtime
 ```
 
 ``` shell
@@ -365,7 +365,7 @@ In the disruption, new stop points can be found in the list of "impacted_stops"
 
 ``` shell
 # Request example for /journeys
-http://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
 ```
 
 ``` shell
@@ -464,7 +464,7 @@ In the disruption, every stops served by the new train can be found in the list
 
 ``` shell
 # Request example for /journeys
-http://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/journeys?from=<origin>&to=<destination>&data_freshness=realtime
 ```
 
 ``` shell
@@ -567,7 +567,7 @@ When requesting a journey that was previously disrupted and is now back to norma
 
 ``` shell
 # Request example for /departures (data_freshness=realtime by default)
-http://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/stop_areas/<stop_area>/departures?from_datetime=<from_date>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/stop_areas/<stop_area>/departures?from_datetime=<from_date>&data_freshness=realtime
 ```
 
 ``` shell
@@ -613,7 +613,7 @@ No disruption is present at the root level of the response and so, in the sectio
 
 ``` shell
 # Request example for /stop_schedules (data_freshness=realtime by default)
-http://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/stop_schedules?from_datetime=<from_date>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/stop_schedules?from_datetime=<from_date>&data_freshness=realtime
 ```
 
 ``` shell
@@ -651,7 +651,7 @@ No disruption is present at the root level of the response and so, in the sectio
 
 ``` shell
 # Request example for /terminus_schedules (data_freshness=base_schedule by default)
-http://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/terminus_schedules?from_datetime=<from_date>&data_freshness=realtime
+https://api.navitia.io/v1/coverage/<coverage>/physical_modes/<physical_mode>/lines/<line>/stop_areas/<stop_area>/terminus_schedules?from_datetime=<from_date>&data_freshness=realtime
 ```
 
 ``` shell

documentation/slate/source/includes/stuff.md

@@ -7,14 +7,14 @@ Multiple journeys
 Navitia can compute several kind of journeys with a journey query.
 
 The
-[RAPTOR](http://research.microsoft.com/apps/pubs/default.aspx?id=156567)
+[RAPTOR](https://www.microsoft.com/en-us/research/publication/round-based-public-transit-routing)
 algorithm used in Navitia is a multi-objective algorithm. Thus it might
 return multiple journeys if it cannot know that one is better than the
 other. For example it cannot decide that a one hour journey with no
 connection is better than a 45 minutes journey with one connection
 (it is called the [pareto front](http://en.wikipedia.org/wiki/Pareto_efficiency)).
-Navitia uses multiple objectives : arrival datetime, the number of transfers,
-the duration of "walking" (transfers and fallback), reliability of lines, crowd, etc.
+Navitia uses multiple objectives : arrival datetime, the number of transfers, 
+the duration of "walking" (transfers and fallback), reliability of lines, occupancy, etc.
 
 If the user asks for more journeys than the number of journeys given by
 RAPTOR (with the parameter `min_nb_journeys` or `count`), Navitia will