Bijlage 1
Opzet aanpak Navigatie iNowit Datum: augustus 2013 Versie 4
Pagina 1 van 7
Inhoud 1.
Stappen:........................................................................................................................................... 3 Stap 1: beheer kaartapplicatie / wegennetwerk ................................................................................. 3 Stap 2: CCS-M ingeven van (operationele) preparatieven data gegevens .......................................... 4 Stap 3: CCS-M ingeven dynamische data ............................................................................................ 4 Stap 4: Data verstrekt door overheden (RWS, Provincies en gemeenten) via webservices. .............. 5 Stap 5: Route berekening .................................................................................................................... 5 Stap 6: Communicatie: ................................................................. Fout! Bladwijzer niet gedefinieerd. Stap 7: Kaartmateriaal .................................................................. Fout! Bladwijzer niet gedefinieerd.
2.
Samenhang ...................................................................................................................................... 7
Pagina 2 van 7
1. De onderdelen: In het werkproces onderscheiden we een aantal onderdelen. Deze stappen kunnen op een of meerdere applicaties/ platformen impact hebben.
Onderdeel 1: beheer kaartapplicatie / wegennetwerk a. Basis wegenbestand Navteq. Dit bestand is routeerbaar. b. Aanpassingen basisbestand Navteq. Voor de doelstellingen van dit traject zullen er in het basisbestand attributen of lijnen van het basisbestand moeten worden aangepast. Voorbeeld de doorrijdhoogte wordt toegevoegd of dat een eenrichtingsverkeersweg kan door de hulpdiensten worden gebruikt. c. Er dienen wegen te kunnen worden toegevoegd die aansluiten bij het Navteq bestand en samen met het bestand van Navteq het routeerbare basisbestand vormen. Deze functies kunnen worden uitgevoerd door de NMPO web applicatie. Hierin kunnen naast het bestaande kaartmateriaal van Navteq (routeerbaar) ook eigen lijnsegmenten worden toegevoegd. (functies zijn: kaartupdates, toevoegen/ wijzigen/ verwijderen van vectoren en attribuut gegevens, exporteerbaar maken als kaartmateriaal voor het navigatiesysteem). Men kan zelf of samen met opdrachtnemer de route-informatie aanpassen aan de wensen van de hulpverlening. Hier kan ook de voertuig(type) de snelheid per wegfunctie worden ingesteld. De bestaande applicatie kan worden uitgebreid met attributen voor vrachtwagen restricties (doorrijhoogte/ as belasting). Dit kan worden verrijkt met eigen gegevens, die in de routering worden meegenomen. Aandachtpunt is het beheer van het basisbestand. Wat gebeurt er als er een update van navteq komt, hoe wordt een update van berijdbare bospaden verwerkt. Daarbij gaan we er van uit dat de parameters in het kaartmateriaal (navteq+ aanvullingen) worden bijgehouden door de brandweer zelf. Deze gegevens moeten naar de voertuigen worden gedistribueerd (vervanging/update?). Er wordt uitgegaan van een bestaand NMPO Programma: Winter Planning. Dit is een webbased programma (Postgis database, Dot net/ Java script front end, mapserver kaart handler. De source hiervan zal worden gekopieerd zodat aanpassingen alleen voor de Veiligheidsregio’s gelden. Tevens is het dan mogelijk specifieke (gebruikers)termen in de menu’s te plaatsen.
Pagina 3 van 7
Onderdeel 2: Ingeven van GEO informatie, preparatieve data Preparatieve data kan bijvoorbeeld in een centrale postgis database zijn opgenomen. Deze hebben weinig impact op de routenavigatie. Gegevens kunnen worden getoond in het navigatiesysteem. Deze data worden opgenomen als POI. Deze POI kunnen als aanrijdpunten worden geselecteerd. Deze kunnen als GPX of XML worden aangeleverd aan het navigatiesysteem. Een tweede aspect van preparatieve data is de data die gegenereerd wordt aan de hand evenementen en kunnen elementen bevatten voor routering. Ingeven van objecten zodat de operatie over de juiste gegevens beschikt , inclusief het distribueren van deze gegevens naar de voertuigen. Deze informatie heeft (vaak) een tijdelijk karakter (begindatum-einddatum). Bijvoorbeeld de rijdroutes op het evenemententerrein van de Zwarte Cross. Er wordt onderzocht of deze tijdelijke POI’s ook middels een zelfde format (GPX/ XML ) kunnen worden overgedragen. Er dient een goed protocol te komen zodat data goed gedistribueerd kan worden zodat het ook in de voertuigen up –to-date is. De impact op de routering zal bekeken moeten worden . Er dienen standaards te worden besproken zodat de route navigatie rekening kan houden met deze dynamische informatie (x/y. koppeling aan wegvak en effect (blokkade). Er moet onderscheid gemaakt worden tussen wegafzettingen, en wegafsluitingen met betrekking tot het berekenen van de route. Bij wegafzetting, er kan geen gebruik gemaakt worden van de doorgang (incident en preparatief), bij een wegafzetting kan er door hulpdiensten gebruik gemaakt worden van de doorgang (incident en preparatief). De wegafsluitingen mogen door de navigatie genegeerd worden. De preparatieve data wordt als GPX aangeboden aan de navigatie (dus als POI). Dit is al beschikbare functionaliteit, er zal alleen een juiste XML moeten worden opgebouwd.
Onderdeel 3: ingeven van GEO informatie, dynamische data Een incident begint met een(XML-)bericht van de meldkamer. Deze melding komt binnen bij het voertuig (en is niet altijd even accuraat wat betreft locatie). Hier wordt automatisch naartoe genavigeerd . De communicatie tussen meldkamer/voertuig is nog niet besproken, maar waar mogelijk wordt aangesloten op bestaande communicatiekanalen.
Pagina 4 van 7
Tijdens een incident kan geplot worden in een applicatie. Incidentdata die geplot wordt, bestaat uit een positie (X/Y) en attribuutdata. Deze objecten kunnen of POI’s zijn (bijvoorbeeld water inname punten/ voertuig opstelplaatsen) of blokkades (bijvoorbeeld blokkades/ gifwolk) zijn. Een deel van deze geografische gegevens kunnen impact hebben op de routering. Om dit te realiseren zullen manieren gevonden moeten worden om de verschillende objecttypen (punten/lijnen en vlakken) te verwerken in het routeerbare bestand. Bv puntblokkade op lijnsegment sluit lijnsegment uit van routering. Daarnaast kent het incident soms uitgangsstellingen (zie hiervoor) voor verschillende voertuigen. Vanaf deze uitgangsstellingen kunnen verschillende routes worden gecreëerd. Bijvoorbeeld aan- en afrijroutes naar waterpunten. Deze routes zijn verplicht voor de betreffende voertuigen en “overrulen” de navigatie. Een voertuig krijgt deze routes zodra het mogelijk is en anders niet. Deze navigatiefunctie is nu al aanwezig, het belangrijkste ontwikkelpunt is gelegen in het uitwisselen van de voorbereide route(tekenen) met de plotapplicatie.
Onderdeel 4: Data verstrekt door overheden (RWS, Provincies en gemeenten) via webservices. In toenemende mate zijn er sites waar wegopbrekingen en calamiteiten e.d. op vermeld zijn. Deze zijn te integreren in het routeringsbestand. (niet in fase 1)
Onderdeel 5: Route berekening Alle routeberekeningen worden aan de client side uitgevoerd (dus op het navigatie systeem). Als extra functie zal hiervoor worden ontwikkeld het tonen en kiezen van verschillende alternatieven. De routeberekening wordt gebaseerd op de input data (wegen/ objecten en obstakels). De route kan bestaan uit: • •
Veilige route Snelste route
Alle berekende routes zijn routes die dynamisch zijn. Dus ook bij afwijkingen worden herberekend. Aan de navigatiekant wordt de voorkeursroute geladen, en bij afwijkingen van de route wordt automatisch herberekend (is aan/uit te zetten). Of gedwongen naar de originele route teruggeleid.
Pagina 5 van 7
Onderdeel 6: applicatie
De chauffeur kan kiezen uit verschillende instellingen (User interface),, bijvoorbeeld: bijvoorbeeld • • • • •
Kaart met Auto zoom (afhankelijk van de rijsnelheid) Pijl en afstand als hoofdscherm/ mogelijk meerdere instructies onder elkaar (opeenvolgend), (opeenvolgend) soort roadbook, zonder kaart Maximaal toegestane rijsnelheid op basis van eigen info! Zelf kiezen tussen alternatieve routes (verwachting 99% van de routes zal zijn: rij van A naar B), met daarbij een keuze tussen de snelste en de veiligste manier. Eigen opbouw scherm, dus welke informatie wil de chauffeur zien!
De tablet dient een internet verbinding te hebben. (kan via de reeds aanwezige router) Bij voorkeur verbonden met een externe GPS (nauwkeuriger) Deze kan remote aanvullende data ontvangen (nieuwe opstelplaatsen/ of nieuwe (waterlaad) route) In onderling overleg dienen de randvoorwaarden voor de berekeningen te worden vastgesteld. De tablets kunnen remote beheerd worden (software (software updates / beperking van functionaliteiten) Pagina 6 van 7
De berekende route kan beschikbaar gesteld worden aan andere applicaties.
2. Samenhang Het is van belang dat de verschillende programma’s eenvoudig data onderling kunnen uitwisselen. Indien gewenst kan de functionaliteit worden uitgebreid zodat ook de daadwerkelijke aanrijtijden voor de objecten berekend kunnen worden op basis van het beschikbare kaartmateriaal. Het resultaat is: -
een kaartbeheer applicatie, waarin de branche specifieke attribuut data met betrekking tot het wegenbestand, kan worden ingevoerd en worden geëxporteerd naar het navigatie systeem;
-
een navigatiesysteem dat gebruikersvriendelijk is en verschillende alternatieve routes kan berekenen/ tonen;
-
koppelingen met GEO informatie om preparatieve data waarop genavigeerd kan worden toe te voegen, zoals ingangen terrein;
-
en koppelingen met GEO incidentdata waarop genavigeerd kan worden toe te voegen, zoals CoPI, WIP.
Pagina 7 van 7
