FTTH : visite surprise d’Orange

Hier soir j’écrivais ceci : FTTH : et maintenant, les règles J3M ARCEP pour ralentir le tout

Et ce matin, coïncidence, appel surprise d’un technicien Orange qui passait faire sa visite de repérage pour ajouter l’arrivée fibre Orange sur le point de mutualisation.

Il m’a dit n’avoir reçu qu’hier soir un document SFR du 26 juin 2013 indiquant que l’immeuble serait fibré.

Orange passera installer son arrivée fibre selon lui « dans le courant du mois de février » pour une disponibilité à l’abonnement « peu après, une ou deux semaines ».

Il ne manque plus que Free à l’appel, c’est dommage car leur arrivée horizontale est déjà là depuis un bon moment…

FTTH : et maintenant, les règles J3M ARCEP pour ralentir le tout

(Suite de Le FTTH à Paris : on touche au but !)

Toujours en attente de la mise en service de la fibre dans l’immeuble, plus d’un mois après le passage du technicien selon qui le délai n’était que de 2 à 3 jours.

Mais c’était compter sans le “J3M”, je cite le site ARCEP :

l’opérateur d’immeuble est tenu d’envoyer 3 mois avant la mise en service commerciale du point de mutualisation (PM) un certain nombre d’informations à la liste des opérateurs destinataires des informations concernant l’installation de lignes de communications électroniques à très haut débit en fibre optique dans les immeubles prévue à l’article R. 9-2 du CPCE (tenue à jour sur le site de l’ARCEP)

Autrement dit, l’intervention fin décembre visait à valider la disponibilité du point de mutualisation, et l’opérateur a décidé de ne faire courir le délai de 3 mois qu’à partir de ce moment, et pas avant (il aurait probablement pu décider d’anticiper la notification de mise en service, mais cela nécessiterait de prendre un petit risque : s’imposer en interne des contraintes de délai pour respecter les 3 mois).

Voilà donc la mise en service qu’on croyait imminente repoussée, au plus tôt, au 21 mars 2014…

Routage ferroviaire pour raildar.fr avec Openstreetmap et OSRM

Pour fêter la nouvelle année, que je vous souhaite à toutes et tous joyeuse et heureuse, voici une petite application web que j’ai écrite récemment pour aider au débogage des trajets de raildar.fr, qui permet d’identifier plus rapidement les problèmes à corriger dans openstreetmap.org. Voir plus bas pour des précisions de fond.

Ça se révèle assez ludique (pour les amateurs de trains).

Voici l’URL temporaire “de travail” chez moi avec un exemple de trajet Londres-Amsterdam :

https://signal.eu.org/osm/?fromto=51.534377,-0.128574,52.379018,4.899988

Pour demander un trajet, on déplace simplement les deux marqueurs et le logiciel de routage se débrouille, et affiche la distance résultante.

En voici une copie d’écran (cliquer pour agrandir) :

LondresAmsterdam

Attention, ne bourrinez pas trop sur le serveur, le calcul des routes prend quelques secondes et utilise l’instance OSRM de raildar.fr.

L’application est aussi déployée sur les serveurs de @Turblog (Bruno Spiquel) dans une version un peu moins à jour.

Quelques précisions pour ceux qui ne connaissent pas : raildar.fr utilise les données SNCF de retard, ainsi que la base cartographique openstreetmap.org. openstreetmap.org est en quelque sorte le Wikipédia de la cartographie. Chacun peut y apporter des corrections. En complément, OSRM (Open Source Routing Machine) extrait les différents graphes (routiers, ferroviaires, etc) afin de calculer des trajets de toutes sortes dans le graphe.

Mon application est éhontément dérivée du code initial de raildar.fr (écrit par , basé sur leaflet et jQuery) auquel j’ai ajouté le décodage de la sortie OSRM.