Inhoudstafel Context 2 Applicatie Projectmat 3 Werking van mintod 6 Opmaak van het projectfiche-bestand 9



Dovnload 91.86 Kb.
Datum20.08.2016
Grootte91.86 Kb.

N59.1 – Projectmat en projectfiches


Inhoudstafel

Context 2

Applicatie ProjectMAT 3

Werking van MINTOD 6

Opmaak van het projectfiche-bestand 9


Context


De strategische personenmodellen worden ingezet voor een breed spectrum aan mobiliteitsanalyses, zowel in de bestaande situatie als in een prognosejaar en –scenario Business-As-Usual 2020. In de meeste gevallen richten de oefeningen zich op specifieke maatregelen binnen het aanbodssysteem, bijvoorbeeld ringwegen voor gemotoriseerd verkeer of geoptimalizeerde of bijkomende OV-verbindingen. Er is echter een duidelijke tendens om ook gericht ruimtelijke projecten en invullingen mee te betrekken in deze oefeningen, en sommige analyses beperken zich enkel tot impact-inschatting op mobiliteit van bepaalde projecten.

De module BasMAT/GroeiMAT biedt de modelexperten een onderbouwd instrument om grootschalige ruimtelijke verkenningen door te voeren. Deze applicatie vertrekt van de grond af en verwerkt projecten op niveau van de sociodemografische en economische data, om zodoende via patroondoortrekking een meest plausibele, consistente en intern-gebalanseerde totale situatie te schetsen. Resolutie van dit systeem komt neer op de basis-bouwblokken van de modellen. De resulterende verplaatsingsmatrices per motief en tijdstip vormen een solide basis voor grootschalige scenario’s, en zijn daarom de beste vertrekbassisen voor ankerjaren en –situaties. Het is echter moeilijk om één specifiek project met vooropgestelde kenmerken rond distributie en tijdstipkeuze exact in het eindresultaat te krijgen.

Om die reden wordt een bijkomend instrument ontwikkeld om bovenop bestaande referentie-situaties gericht projecten toe te voegen in het kader van specifieke modelevaluaties en –varianten. De module ProjectMAT opereert dan ook op het operationele niveau en ondersteunt de modelgebruiker binnen de SM3+-context met de opmaak van extra vraagscenario’s waarbinnen de gewenste projecten volledig worden uitgewerkt. ProjectMAT opereert op model-matrixniveau, zijnde motief- en/of modepatronen, in plaats van op sociodemografische data, en verlaat de stringente eisen rond consistentie en balansering van de totale patronen die BasMAT/GroeiMAT aanbiedt. In de plaats daarvan zal ProjectmAT op de meest flexibele en efficiënte manier opgegeven projecten exact vertalen naar de correcte motief- en/of modematrices, waarbij in de opvolgende evaluaties de effecten van deze projecten correct begroot zijn. Via uitgebreide projectfiches kan de gebruiker normaliter de meest complexe projecten invoeren, waarbij een uitgebreid spectrum aan detaillering, of het ontbreken daarvan, automatisch zal verwerkt worden.

In volgende onderdelen wordt ingegaan op de applicatie ProjectMAT zelf, op MINTOD, het hart van ProjectMAT en op de syntax van de projectfiches.


Applicatie ProjectMAT

0.1.Catalog en sleutels


ProjectMAT wordt opgeleverd en gebruikt in een klassieke Catalog/Application combinatie, en draait in praktijk onder een SM3+-omgeving: dit betekent dat de benodigde data en de uitvoerresultaten klassiek in de SM3+-bibliotheek be-waard worden. Technisch gezien zal ProjectMAT vertrekken van een bepaalde vraagfolder onder de DoorrekenenSM3-folder, en zal die vraagmatrices verrijken met de projectpatronen en de resultaten in een nieuwe vraagfolder bewaren, zodanig dat de gebruiker in de SM3+ bepaalde varianten kan koppelen aan deze nieuwe vraag naar verplaatsingen.

Dit principe komt naar voor in 3 sleutels in de Catalog: de sleutel DataScen bepaalt naar welke SM3+-bibliotheek de gehele Applicatie verwijst. Binnen een standaard SM3+-bibliotheek wordt altijd een vaste structuur gevolgd, dus enkel de foldernaam van de bibliotheek volstaat. Op deze manier kan eenvoudig tussen bibliotheken geschakeld worden met de Applicatie, ofwel kan binnen de Catalog een scenario-structuur opgebouwd worden waarbij een eerste niveau naar verschillende bibliotheken verwijst. De tweede sleutel Bronvraagfolder stelt de vraagfolder in waarbij de opgegeven projecten zullen opgeladen worden: in deze folder staan, bij een correct functionerende SM3+-bibliotheek, een set matrices rond Herkomst-Bestemmingspatronen, Modematrices, Vrachtmatrices, alsook de kostenmatrices voor de diverse modi en een databank met de zonale socio-demografische gegevens. Al naargelang het functioneren van ProjectMAT worden bepaalde of alle bestanden gebruikt om een nieuwe vraagfolder op te bouwen waarbinnen de opgegeven projecten opgenomen zijn. Deze nieuwe vraagfolder wordt opgegeven in de derde sleutel Doelvraagfolder: deze is analoog aan de basis vraagfolder, en kan in eerste instantie nog onbestaande zijn. ProjectMAT zal in deze folder alle nieuwe bestanden en matrices wegschrijven, en er voor zorgen dat deze folder door SM3+ volledig zal herkend worden als een functionerende en operationele vraagfolder zodanig dat rekenvarianten hieraan kunnen gekoppeld worden. Indien noodzakelijk zal ProjectMAT deze folder aanmaken. De sleutel Specs geeft de omschrijving van deze nieuwe doelvraagfolder: deze omschrijving wordt in een apart ASCII-bestand onder doelvraagfolder weggeschreven, zodanig dat finaal de naamgeving en omschrijving in SM3+ duidelijk en werkbaar wordt.

De sleutel Projectfiches verwijst naar het bestand waarin alle te behandelen projecten beschreven staan. Dit bestand vormt de kern van het hele systeem ProjectMAT, en wordt in deze Catalog gelinkt via een directe bestandsnaam die kan gebladerd worden. Op zich hoeft dit bestand dan ook niet in de SM3+ DataScen-structuur opgenomen te worden, hoewel dit mogelijk wel aan te bevelen is. Het Projectfiche-bestand is een standaard ASCII-bestand met keywords die de projecten in meer of minder detail beschrijft. De inhoud ervan wordt beschreven in een volgend onderdeel.

De sleutel Zones geeft klassiek het aantal zones in het gekoppelde verkeersmodel op. Deze parameter is via omwegen wel uit de bronvraagfolder af te leiden, maar praktisch gebruik leert dat die data niet altijd intern consistent is, en daarom wordt uit voorzorg deze parameter in het project opgenomen.

Een laatste sleutel Uur duidt het te modelleren uur aan waarvoor de matrices moeten opgebouwd worden. Het gehele systeem kan voor een reeks aan uren draaien, maar dit maakt het conceptueel moeilijker om met de juiste kostenmatrices voor de te modelleren uren te werken. Daarom wordt gekozen om steeds met geïsoleerde uren te rekenen, op deze manier wordt deze sleutel ook gehanteerd in de verwijzing naar de uurgerelateerde kostenmatrices, en kan geen verwarring ontstaan.

Via de gehele set van sleutels kan een efficiënte scenario-structuur in de Cube Scenario Manager opgebouwd worden, waarin een hiërarchie naar bibliotheken en/of modellen, projectpakketten en modelperiodes kan onderscheiden worden. De applicatie maakt geen gebruik van interne condities en feedbacks, dus het is mogelijk om een hele set van scenario’s op te lijsten en door te rekenen.


0.2.Opbouw en structuur


ProjectMAT wordt bijna volledig gedragen door MINTOD.EXE, een apart ontwikkelde module met alle nodige functionaliteiten om op meest performante en flexibele wijze met projectfiches om te gaan. Toch zijn enkele Cube Voyager-modules voor en na noodzakelijk.

0.2.1.Voorbereiden doelvraagfolder – rekenvolgorde 1


Een eerste module in PILOT bereidt de folderstructuur voor en zal bepaalde taken uitvoeren om de finale doelvraagfolder efficiënt op te maken.

Als de doelvraagfolder nog niet bestaat, wordt deze in deze stap opgemaakt. Het SM3+-omschrijvingsbestand voor de vraagfolder, SPECS.DAT, wordt opgemaakt, dit gebaseerd op de opgegeven sleutel.

Daarnaast worden alle matrices die niet veranderd zullen worden door ProjectMAT, vanuit de bronvraagfolder naar de doelvraagfolder gekopieerd, zodanig dat op het einde deze doelvraagfolder een volledig werkbaar geheel vormt voor de SM3+. Het betreft hier de kostenmatrices, de hulpmatrices, de correctiematrices en de databanken met socio-demografische gegevens. Deze bestanden dienen als invoer voor ProjectMAT, maar worden niet aangepast op basis van de bijkomende projecten.

0.2.2.Uitdumpen matrices – rekenvolgorde 2


De interne bestandsformaten van Cube Voyager-matrices worden niet vrijgegeven, en kunnen daarom niet rechtstreeks geadresseerd worden door MINTOD.EXE. Deze module dumpt alle nodige invoermatrices uit naar een DBF-formaat, dat wel publiek en efficiënt leesbaar is. Om redenen van stroomlijning en performantie, wordt deze dump niet gericht uitgevoerd, waarbij alleen cellen met een relevante waarde worden uitgeschreven. De matrices worden volledig uitgeschreven, dus ook met, een soms groot aantal, nul-cellen. De resulterende DBF-bestanden kunnen daarom een aanzienlijke omvang krijgen, maar door hun vast en repetitief formaat kunnen ze sneller verwerkt worden.

0.2.3.Uitvoeren projectgroei – rekenvolgorde 3


De module MINTOD behandelt de projectfiches en levert voor het opgegeven uur specifieke projectmatrices aan, voor motief, mode en vracht.

In een volgend hoofdstuk wordt de werking van MINTOD zelf beschreven.


0.2.4.Opbouwen projectmatrices – rekenvolgorde 4


Analoog aan de fase waarin de invoermatrices utigedumpt werden, volgt hier opnieuw de transformatie naar Voyager-formaat. In deze module worden de projectmatrices zelf weggeschreven als Voyager-matrices. Deze zijn dan ook in de doelvraagfolder als aparte matrices beschikbaar, dit onder de namen PROJECT-OD_Uur.MAT, PROJECT-MODE_Uur.MAT en PROJECT_FREIGHT_Uur.MAT. De interne opbouw van deze matrices in tabellen is gelijklopend aan de standaard-indeling die in de modelmatrices wordt gebruikt.

0.2.5.Afwerken matrices in doelvraagfolder – rekenvolgorde 5


In een laatste stap worden alle matrices waarin de bijkomende projecten opgenomen zijn, opnieuw samengesteld. Normaliter omvat deze stap het rechttoe-rechtaan optellen van de opgemaakte projectmatrices met de overeenkomstige modelmatrices. In deze oefening wordt bijkomend zorg gedragen voor eventuele bijkomende gesommeerde deelmatrices. Belangrijk te melden is dat, indien relevant, ook de HW-PREV-matrix wordt bijgewerkt met auto-bewegingen die uit de projectmatrices komen.

Werking van MINTOD

0.3.Opzet en bestandskoppeling


MINTOD past zich naadloos in in de Cube Application Manager via een zogenaamd resource-bestand. Hierin worden alle bestandskoppelingen gedefinieerd zodanig dat de modelontwikkelaar de module MINTOD kan inpassen in de gewenste modelstructuur, zoals ProjectMAT.

MINTOD werkt analoog aan Voyager-modules via een Script File waarin rekenopties en parameters gezet worden, beschreven in een volgende paragraaf. Omdat Cube Application Manager geen dynamische koppeling voorziet tussen de Script File enerzijds en bestandskoppeling anderzijds, wordt teruggevallen op een bijkomend stuurbestand, Control Data. Dit bestand wordt door Cube Application Manager wel correct onderhouden: wanneer de ontwikkelaar een bestand als invoer of uitvoer koppelt, wordt in het Control Data-bestand de correcte bestandsnaam gezet. Een derde bestand, aan de uitvoerkant, Print File vervolledigt de noodzakelijke stuurbestanden. Dit bestand rapporteert de feitelijke werking van MINTOD, en zal de nodige informatie geven over de uitgevoerde taken, deelresultaten en eventuele problemen. In dit bestand kan de gebruiker steeds nagaan of de berekening technisch correct en volgens wens uitgevoerd werd.

Aan de invoerkant worden een set bestandskoppelingen aangeboden. Niet alle bestanden zijn noodzakelijk: al naargelang de opgegeven instellingen kan MINTOD met een beperkte set aan invoer aan de slag. Steeds noodzakelijk echter is een projectfiche-bestand. In totaal kan de gebruiker 5 Project Files opgeven. Dikwijls zullen de opgegeven projecten in één bestand volstaan, maar het is mogelijk om verschillende projectfiche-bestanden te mengen, bijvoorbeeld als combinatie tussen verschillende project-scenario’s. MINTOD zal deze bestanden als één geheel afwerken.

Volgende bestanden betreffen allemaal klassieke modelmatrices:



  • OD Matrix: de motiefpatroon-matrices, met daarin oplijsting van de verplaatsingspatronen voor werk, school, winkel, recreatief en overige;

  • Mode Matrix: de modematrices, met daarin de verplaatsingen voor de modi bestuurder, passagier, OV, fiets en te voet;

  • Freight Matrix: de vrachtmatrices, met daarin de verplaatsingen voor de modi zware en lichte vrachtwagen;

  • LOS HW Matrix: de kostenmatrix voor gemotoriseerd vervoer, met daarin de reistijden in-voertuig, fileverlies, queueing verlies, afstand en tol;

  • LOS PT Matrix: de kostenmatrix voor openbaar vervoer, met daarin de in-voertuig reistijden, wachten, opstappen en non-transit;

  • LOS ST Matrix: de kostenmatrix voor langzaam verkeer, met daarin de reistijden voor fiets en te voet.

Alle aangereikte matrices moeten in DBF-formaat ingevoerd worden, en bevatten een vast aantal records, namelijk het aantal zones, opgegeven als Catalog-sleutel, in het kwadraat.

Een laatste invoerbestand betreft de databank van de socio-demografische gegevens, de SDD File. Het betreft hier de volledige verrijkte zonale dataset, en niet de beperkte databank die ook door MM gebruikt wordt. Voor sommige DataScens moet deze bijkomend ingevoerd worden in de vraagfolders, het bestand zelf is steeds aanwezig in de modelinstrumenten waarin de strategische personenmodellen geïmplementeerd worden.

Aan de uitvoerkant wordt een beperktere set aan bestanden aangeboden: niet alle invoerbestanden worden bijgestuurd door de projectinvulling. Enkel volgende bestanden worden specifiek en geïsoleerd voor de opgegeven projecten opgemaakt, met gelijkaardige invulling als de invoerbestanden:


  • OD Matrix: de motiefpatroon-matrices voor de projecten, met daarin oplijsting van de verplaatsingspatronen voor werk, school, winkel, recreatief en overige;

  • Mode Matrix: de modematrices voor de projecten, met daarin de verplaatsingen voor de modi bestuurder, passagier, OV, fiets en te voet;

  • Freight Matrix: de vrachtmatrices voor de projecten, met daarin de verplaatsingen voor de modi zware en lichte vrachtwagen;

De matrices moeten niet allemaal opgegeven worden: enkel de gekoppelde bestanden worden door MINTOD ingevuld, wanneer bijvoorbeeld de uitvoer Mode Matrix niet benoemd wordt, zal MINTOD geen vervoerwijzekeuze uitvoeren. Logischerwijze moet er minstens één uitvoermatrix aangereikt worden.

Een laatste bestand is de Report File, waarvan er in totaal ook 5 naar keuze kunnen opgegeven worden. De gebruiker kan zelf instellen welke rapportage MINTOD moet uitvoeren. Ook dit bestand is optioneel.


0.4.Sturing van MINTOD


Zoals gesteld worden de functionaliteiten van MINTOD gestuurd vanuit het Script-bestand. Dit bestand volgt de klassieke opmaak zoals andere Voyager-modules, waarbinnen keywords en parameters bepalen hoe MINTOD te werk gaat.

In de huidige versie van MINTOD wordt in praktijk voorlopig weinig sturing in het Script-bestand opgegeven, het merendeel van de functies wordt uiteindelijk in de projectfiches aangestuurd. Momenteel zijn volgende keywords voorzien:



ZONES (integer |1-9999| geen default): het aantal zones in het geselecteerde model;

MODELPERIOD (integer |0-23| geen default): het gekozen modeluur;

BUCKET (single |0.0001-10| default géén waarde): door de parameter BUCKET in te vullen, zal MINTOD de resultaatmatrices op de opgegeven waarde gaan bucket-rounden. Elke mogelijke zinvolle waarde kan opgegeven worden. Wanneer deze parameter niet opgegeven wordt, zal MINTOD niet afronden en op een dynamische manier de resultaten wegschrijven;

FULLREPORT (boolean default false): wanneer de optie FULLREPORT ingeschakeld wordt, zal MINTOD in het printbestand een samenvatting van de resultaten per project opgeven. Daarenboven wordt een uitgebreid CSV-rapport opgemaakt indien één van de uitvoer-rapporten benoemd is;

CALCULATION (string |BASMAT/CROW| default BASMAT): dit keyword kiest de intern te hanteren rekenregels. Standaard zal de BASMAT-methodiek van de Vlaamse modelstructuur gevolgd worden, maar de gebruiker kan kiezen om de interne rekenregels te schakelen naar de CROW-richtcijfers. Deze instelling kan per project in het projectfiche-bestand worden overroepen: standaard kan de BASMAT-methodiek geschakeld zijn, maar een bepaald project kan toch de CROW-rekenregels inroepen, en vice versa.

Opmaak van het projectfiche-bestand

0.5.Algemene principes


MINTOD behandelt de te verwerken projecten via een projectfiche-bestand met vooropgestelde syntax: elke project wordt beschreven met een set keywords en parameters op dusdanige manier dat alle informatie die gekend is door MINTOD kan gebruikt worden als randvoorwaarde. Ontbrekende informatie wordt door MINTOD ingevuld op basis van gekende rekenregels. Een heel uitgebreide set aan keywords en parameters is beschikbaar om de meest gedetailleerde info in te voeren indien noodzakelijk, maar in praktijk zullen deze zelden allemaal gebruikt worden. Het belangrijkste principe van MINTOD is dan ook dat de gebruiker de maximale vrijheid heeft om een project te beschrijven tot op het detail dat de gebruiker wenst, en dat MINTOD daarna de onbekende data zelf aanvult.

De projectfiche waarin de projecten beschreven worden, wordt per uniform project opgesteld, en dit volgens een aanpak zoals het Voyager kruispuntbestand: een keyword triggert een nieuw project, en vervolgens wordt dat project met opvolgende keywords verder beschreven. Een eerste deel bepaalt enkele algemene projectkenmerken die voor alle thema’s gelden, zoals bijvoorbeeld oppervlakte, een tweede deel beschrijft per thema een set kenmerken. De huidige versie van MINTOD onderscheidt 7 thema’s:



  • Werk: alle verplaatsingen die gerelateerd zijn aan tewerkstellingsprojecten;

  • School: alle verplaatsingen die gerelateerd zijn aan schoolprojecten;

  • Winkel: alle verplaatsingen die gerelateerd zijn aan commerciële en/of winkelprojecten;

  • Recreatief: alle verplaatsingen die gerelateerd zijn aan recreatieve projecten;

  • Bewoning: alle verplaatsingen die gerelateerd zijn bewoningsprojecten.De vorige 4 thema’s spelen elk respectievelijk in op één motief, bewoningsprojecten duiden op de ‘passieve’ kant van de modelverplaatsingen, en genereren een breed gamma aan motiefverplaatsingen;

  • Vracht zwaar: alle zware vrachtverplaatsingen die gerelateerd zijn aan economische projecten;

  • Vracht licht: alle lichte vrachtverplaatsingen die gerelateerd zijn aan economische projecten.

Per thema wordt een projectmodellering uitgevoerd, waarbinnen volgende deelfasen desgevallend uitgevoerd worden:

  • Ritgeneratie op dagniveau: berekening van het aantal verwachte relaties op dagbasis;

  • Distributie: verdeling van de berekende relaties over herkomst of bestemming al naargelang het thema;

  • Tijdstipkeuze: transformatie van de gedistribueerde relaties naar feitelijke verplaatsingen in het opgegeven uur;

  • Vervoerwijzekeuze: opdeling van de verplaatsingen op celniveau naar de verschillende modi.

Niet alle stappen worden voor elk project of thema uitgevoerd, er zijn verschillende redenen en omstandigheden die bepaalde deelfasen uitsluit. Standaard geldt dat wanneer voor een bepaalde deelfase de oplossing of het resultaat wordt opgegeven, de feitelijke berekening kan vervallen: wanneer bijvoorbeeld voor een werkproject vooropgesteld wordt dat 20 procent van de verplaatsingen tussen 8 en 9 moet aankomen, wordt de tijdstipkeuze niet meer uitgevoerd. Gelijkaardig zorgt de opgave van het aantal ritten per dag van een project er voor dat ritgeneratie niet meer nodig is. Niet elke deelfase kan even eenvoudig opgevangen worden door de oplossing of het resultaat hard te coderen in de projectfiche: het resultaat van het distributieproces is een verdeling over alle zones, en dit kan niet zomaar als oplossing aangereikt worden, distributie zal dan ook altijd uitgevoerd worden. Typisch worden dikwijls de resultaten van ritgeneratie en vervoerwijzekeuze opgegeven.

Een andere reden om bepaalde stappen niet uit te voeren is om de uitvoer niet als bestand te voorzien in MINTOD: wanneer enkel de motiefmatrices als resultaat gevraagd worden, en de modematrices niet benoemd is, zal de vervoerwijzekeuze niet gebeuren !

Als laatste reden kan de specifiteit van het thema leiden naar een niet-uitvoeren van een deelfase, voor vrachtverkeer moet bijvoorbeeld nooit vervoerwijzekeuze uitgevoerd worden aangezien de mode zelf in het thema zit.

0.6.Syntax van de projectfiche


In deze paragraaf worden alle keywords en parameters beschreven die door de huidige versie van MINTOD worden opgenomen.

Een projectfiche is een ASCII-bestand met specifieke extensie PJF. Elk project wordt individueel beschreven met keywords en parameters, en alle regels horen bij een bepaald project zolang op het eind van de regel een komma gecodeerd wordt: deze komma zorgt er voor dat de volgende regel ook nog bij de geldende definitie hoort.

Keywords en parameters worden geschreven door ze te coderen, gevolgd door een ‘=’-teken en vervolgens de waarde van het keyword of parameter op te geven.

De syntax is niet hoofdlettergevoelig, ook spaties of tabs spelen geen rol. Het is evenwel aan te bevelen om met hoofd- of kleine letters leesbare gehelen te vormen, en voldoende spaties of uitlijningen te voorzien om op een overzichtelijke manier de projecten te coderen.

Het punt-komma teken duidt op commentaar, alle tekst rechts van een punt-komma wordt door MINTOD niet behandeld. Ook deze commentariëring zorgt voor duidelijkere en beter begrijpbare beschrijvingen.

Zoals gezegd vormt elk project een eigen geheel van aaneengesloten coderegels. Keywords en parameters kunnen echter wel thema-gevoelig zijn: eenzelfde keyword kan meerdere functies hebben, en dit afhankelijk van het thema dat op die moment geldig is in de projectbeschrijving.

Twee essentiële keywords duiden deze thema’s aan:


  • PROJECT (string, verplicht, geen default): dit keyword triggert een nieuw project, met als waarde de naam van dit project tussen enkelvoudige quotes. De naam moet niet uniek zijn, maar dit helpt de transparantie achteraf wel. Logischerwijze kan de regel voor het keyword PROJECT niet op een komma eindigen. Dit keyword zorgt ervoor dat MINTOD bij het inlezen het thema rond generieke projectkenmerken opstart: alle volgende keywords en parameters worden geïnterpreteerd als algemeen attribuut, tot een volgend keyword volgt dat specifiek het thema wijzigt;

  • TYPE (string |WORK/SCHOOL/COMMERCIAL/RECREATION/HOUSING/FREIGHT-HEAVY/ FREIGHTLIGHT| geen default: het keyword TYPE wisselt het thema bij het inlezen door MINTOD naar één van de 7 mogelijke thema’s, elk gekenmerkt door één van de 7 vaste waarden. Er is geen default voorzien, foutieve of niet bestaande waardes voor dit keyword worden niet verwerkt. Dit keyword is niet verplicht, maar projecten zonder TYPE zullen geen verplaatsingen genereren. Per project kunnen meerdere types voorkomen, mogelijks hanteren ze intern dezelfde keywords, dus een duidelijk onderscheid naar deze thema’s is zeer belangrijk.

Op de volgende pagina’s worden verder alle keywords en parameters opgelijst, waarbij telkens vermeld wordt welk datatype ze verwachten, bij welke thema’s ze ingrijpen, wat het spectrum is en of er een default geldt.

CATEGORY (string, algemeen |vooropgestelde categorieën, zie verder| geen default): dit keyword bepaalt de inhoudelijke invulling van het project, waardoor de kencijfers op een bepaalde manier ingevuld worden. In vele gevallen zijn ze belangrijk voor de opvolgende thema’s, voor werk bijvoorbeeld is het belangrijk om te weten of het project mikt op diensten of industrie, voor winkel is het onderscheid tussen detailhandel of dagelijkse goederen relevant. Een hele reeks categorieën kunnen aangeduid worden, en niet alle categorieën zijn voor elk thema onderscheidend: het aantal winkelverplaatsingen gegenereerd door de categorieën logistiek en industrie is irrelevant. Intern zal MINTOD dan ook in vele gevallen voor een groep categorieën gemeenschappelijke parameters inschakelen, het is enkel een zekerheid dat géén van de opgenomen categorieën identiek zijn, maar zich dus telkens met minstens een parameter onderscheiden. MINTOD is intern dusdanig opgemaakt dat op eenvoudige manier nieuwe categorieën kunnen toegevoegd worden, waarbij ze standaard gemeenschappelijke parameters krijgen en efficiënt net die afwijkende parameters kunnen gecodeerd worden.

Volgende categorieën, letterlijk te hanteren in de projectfiches, worden door de huidige versie van MINTOD herkend en toegepast:



  • BUSINESS PARK: activiteiten binnen een wetenschaps- of businesspark;

  • SERVICES: dienstensector;

  • ADMINISTRATION: activiteiten in de administratie;

  • EDUCATION: onderwijs;

  • MEDICAL: gezondheidszorg;

  • LOGISTICS: logistiek en distributie;

  • RETAIL: grootschalige winkelactiviteiten;

  • CONSTRUCTION: bouwsector;

  • INDUSTRIAL: industriële activiteiten;

  • MARITIME: havengebaseerde activiteiten;

  • AGRICULTURAL: landbouwsector;

  • MIXED: gemengde activiteiten;

  • LOCAL: locaal KMO-terrein;

  • REGIONAL: regionaal bedrijventerrein.

De huidige oplijsting is op zich niet ‘uitsluitend’ noch ‘complementair’: sommige categorieën zijn subgroepen van andere, andere categorieën zijn eerder verzamelnamen of vaag. Dit illustreert duidelijk dat deze categorieën, en hun bijhorende kencijfers, doelgericht in MINTOD worden geprogrammeerd om enkele bepalende en afwijkende parameters beschikbaar te stellen.

ZONE (integer, algemeen |1-9999| geen default): dit keyword wordt gehanteerd om in eerste plaats de berekende bewegingen op deze rij en kolom in de resulterende matrices te bewaren. Het is aan te bevelen om voor ingevoerde projecten ook in het netwerk een aparte zone te voorzien, het is dan essentieel om de consistentie tussen netwerk en projectfiche te bewaren, aangezien deze laatste leidt naar een projectmatrix. In tweede instantie wordt dit zonenummer gebruikt om in de aangereikte kostenmatrices alle nodige reis-indicatoren op te halen wanneer het keyword COSTZONE niet gedefinieerd is.

Dit keyword is steeds verplicht.



COSTZONE (integer, algemeen |1-9999| default gelijk aan ZONE): in vele gevallen is het niet praktisch om een nieuwe lege zone voor het project te gebruiken aangezien de bestaande kostenskims hier nog geen reis-inicatoren voor aanreiken. Met dit keyword kan voor deze kosten verwezen worden naar een nabijgelegen zone die zo goed mogelijk de bereikbaarheid van het project weergeeft.

AREA (single, algemeen |0.01-9999.0| geen default): de bruto-oppervlakte van het opgegeven project in hectare. Deze oppervlakte wordt gebruikt per categorie een netto-oppervlakte te berekenen van waaruit de ritgeneratie uitgevoerd wordt.

NETAREA (single, algemeen |0.01-9999.0| geen default): de netto-oppervlakte van het opgegeven project in hectare. Deze netto-oppervlakte wordt direct gebruikt per categorie om de ritgeneratie te berekenen. Deze waarde zal, indien opgegeven en niet gelijk aan nul, steeds het keyword AREA overbodig maken.

CALCULATION (string, algemeen |BASMAT/CROW| default de waarde uit het MINTOD-script): dit keyword is gelijkaardig aan het keyword dat gebruikt wordt in het script van MINTOD en laat hier toe om per project de BASMAT-methodiek ofwel de CROW-richtcijfers in te schakelen, eventueel afwijkend van het gehele rekenproces.

EMPLOYEES (single, werk |0.01-9999.0| geen default): het aantal voltijds-equivalenten in het opgegeven project. Wanneer deze waarde opgegeven wordt, zal MINTOD zelf geen berekening uitvoeren gebaseerd op oppervlaktes en categorie.

PRESENCE (single, werk |0.1-100.0| geen default): dagelijks aanwezigheidspercentage van het opgegeven of berekende aantal werknemers. Het product van het aanwezigheidspercentage en het aantal werknemers komt neer op het dagelijks aantal relaties voor werk voor het opgegeven project.

TRIPS (single, werk |0.01-9999.0| geen default): het totaal aantal aan dagelijkse relaties naar het project. Becijferd is dit het product van het aantal werknemers en het aanwezigheidspercentages. Deze waarde stelt het aantal dagelijks af te leggen relaties voor, en kent intrinsiek nog geen richting: pas bij de tijdstipkeuze wordt de verrekening naar echte verplaatsingen uitgevoerd. Op deze plaats is dus één relatie nog niet gelijk aan twee ritten.

LAMBDA (single, alle motieven |-10.0-10.0| geen default) en POWER (single, alle motieven |0.0-10| geen default): de parameters voor de volgende distributiefunctie:

Rit i,p = exp(LAMBDA * kost i,p) * balansfactor i ^ POWER

Het distributiemodel neemt de rekenvorm van een discreet keuzemodel over: op relatieniveau worden alle mogelijke herkomsten naar het project als discrete en onafhankelijke alternatieven beschouwd. De kans dat vanuit een bepaalde herkomst een relatie naar de projectzone gelegd wordt, is afhankelijk van het relatieve nut van die herkomst in vergelijking met alle andere herkomstzones. Dit nut wordt berekend als een product van een kostenfactor en een balansfactor: een kosten-indicator, tijd of afstand, wordt in exponent gezet, en met negatieve LAMBDA betekent dit dat herkomsten die beter in tijd of afstand naar de projectzone liggen, meer kans hebben om als herkomst gekozen te worden. De balans-indicator neemt de aantrekkelijkheid van de herkomstzone in de functie op, en deze mate van aantrekkelijkheid kan naar keuze worden gekoppeld aan socio-demografische kenmerken of reeds bestaand gebruik naar motieven of modi van de herkomstzones. De POWER parameter bepaalt het gewicht van deze balansfactor tegenover de kostenfactor: grotere waardes leiden naar een distributiemodel dat meer belang hecht aan de geselecteerde invulling van de zones dan aan de kostencomponent van de verplaatsing.

Deze parameters hebben geen default-waardes op zich: wanneer in de projectfiche voor het gekozen thema geen keywords rond distributie opgegeven worden, zal MINTOD al naargelang het thema zelf invulling geven aan deze distributiefunctie. De default-waarden van deze parameters zijn in praktijk dan ook thema-afhankelijk. Er wordt verwezen naar de tabulaire oplijsting van alle kencijfers.

AVTRIPLENGTH (single, werk, vracht zwaar en licht |0.01-999.0| geen default): gemiddelde ritlengte van de rit voor het distributie-proces. Deze waarde activeert de automatische zelfkalibratie van het distributieproces, waarbij de kostindicator gelijk gezet wordt aan de afstand van en naar het project. Deze automatische kalibratie volgt een numerisch zoekalgoritme dat de distributie-factoren LAMBDA en POWER zodanig optimaliseert dat het relatie-patroon een gemiddelde ritlengte resulteert zoals opgegeven. Dit zoekalgoritme wordt gebonden door bepaalde drempels zodanig dat de distributie-parameters geen theoretisch zinloze waarden kunnen aannemen.

AVTRIPDURATION (single, werk, vracht zwaar en licht |0.01-999.0| geen default): deze parameter is analoog aan de vorige parameter AVTRIPLENGTH, maar zet de focus op reistijd in plaats van afstand. Dezelfde auto-kalibratie wordt uitgevoerd om de distributie-parameters zodanig te schalen dat de gewenste gemiddelde reistijd resulteert.

BALANCEFACTORS (string, werk, vracht zwaar en licht |formulering| geen default): zoals gesteld incorporeert MINTOD een discreet keuzemodel voor distributie, gebaseerd op een combinatie van kosten en balansfactoren. De kost-indicator kan gevormd worden door afstand of tijd, voor de balansindicator kan gekozen worden uit verschillende zonale kenmerken die een maat vormen voor aantrekkelijkheid in het keuzemodel. In globo kan een onderscheid gemaakt worden naar indicatoren op gebied van socio-demografische data, ofwel op vlak van bestaande vervoersprestaties in de zones. Voor beide invullingen geldt dat de parameter BALANCEFACTORS kan opgegeven worden als een vrije formulering, waarbij in de projectfiche gebruik kan gemaakt worden van de standaard wiskundige operatoren +, -, * en /. Op deze manier is een beperkte verrekening van aparte indicatoren mogelijk indien de gewenste indicator nergens rechtstreeks in de invoerbestanden beschikbaar is.

Bij opgave van een set socio-demografische gegevens dient de naamgeving van de aparte zonale attributen, zoals opgenomen in het invoer SDG-bestand, gehanteerd te worden met toevoegen van het prefix SDD_ dat door MINTOD ook gebruikt wordt om dit SDG-bestand te kenmerken.

Wanneer indicatoren gekoppeld worden naar bestaande vervoersprestaties, worden per zone de gesommeerde rij- en kolomtotalen van de opgegeven matrices, zowel trip als mode, overgenomen. Op deze manier kan naar de bestaande patronen verwezen worden, en zal de projectdistributie aansluiten bij het huidige gebruik zoals geselecteerd in bestaande matrices. Verwijzing naar deze matrices kan liggen naar bestaande modematrices, motiefmatrices of eventueel de vrachtmatrices. Ook hier zijn suffixen noodzakelijk om de juiste koppeling te leggen, alle verwijzingen worden opgegeven in onderstaande tabel:

Naar totalen of deeltotalen van deze matrices kan niet verwezen worden, maar MINTOD biedt via de aangereikte rekenregels alle mogelijkheden om de nodige totalen te bereken en gebruiken als balansfactor.



SHIFT (single, werk |0.1-100.0| geen default): het procentuele aandeel van werknemers dat in een shift-regime actief is. In het tijdstipverdelingsmodel schuift dit aandeel op naar andere verdelingen over de dag, het aandeel werknemers niet in het shift-regime, blijft de normale tijdsverdeling hanteren.

INTIME (array van singles, alle motieven |0.1-100.0| geen default) en OUTTIME (array van singles, alle motieven |0.1-100.0| geen default): MINTOD hanteert voor elk thema en categorie een vooropgestelde tijdstipverdeling voor de heen- en terugritten, waarmee de relaties of trips vertaald worden naar feitelijke ritverplaatsingen. Indien gewenst kan hiervan afgeweken worden door in de projectfiche deze procentuele verdeling over de dag op te geven, en dit apart voor zowel de heenrichting naar het project, als de terugrichting weg van het project. Codering verloopt via uitgeschreven arrays van singles, waardoor het mogelijk is deze verdeling tamelijk compact uit te schrijven. Pragmatisch moet normaliter de som van alle aparte percentages optellen tot 100 procent, maar technisch mag er van afgeweken worden om toe te laten dat gericht enkel de vereiste waardes worden gecodeerd. Het is dan ook niet verplicht per array om 24 percentages op te geven.

TRESHOLDCOST (string, werk |DISTANCE/TIME/CONGESTEDTIME| DISTANCE): binnen MINTOD wordt een vervoerwijzekeuze uitgevoerd voor de bekomen verplaatsingen voor het opgegeven modeluur. Standaard wordt per thema de parameterset gehanteerd zoals deze in de modelstructuur versie 3.6.0. Indien vanuit de projectinformatie andere inzichten in verwachte of geplande modale verdeling bekend is, kan deze extra informatie ingevoerd worden. In vele gevallen is deze modale verdeling niet vast over alle verplaatsingen, meestal worden er strata of bandbreedtes voorzien waarbinnen bepaalde modale verdelingen gelden. Deze strata kunnen op diverse manier opgesteld worden, en het keyword TRESHOLDCOST bepaalt welke maatvoering ingeschakeld wordt om deze bandbreedtes af te bakenen. In vele gevallen zal de maatvoering de tripafstand zijn, maar varianten met reistijd en operationeel gecongesteerde reistijd zijn ook mogelijk. Intern zal MINTOD deze opgegeven maatvoering uit de kostenmatrices voor gemotoriseerd verkeer halen en gebruiken.

SPLITTRESHOLD (array van singles, alle motieven |0.1-999.0| geen default): indien geopteerd wordt om zelf de modale verdeling voor een project op te geven, en deze opgegeven modale verdelingen per bandbreedte te laten variëren, bepaalt deze parameter de randen van deze bandbreedtes. Elke opgegeven absolute waarde, waarvan de dimensie door keyword TRESHOLDCOST wordt bepaald, zet een drempel waarmee onderscheid in modale verdeling gemaakt wordt voor waardes onder of gelijk aan en boven deze waarde. Het aantal effectieve bandbreedtes is gelijk aan het aantal opgegeven drempels vermeerderd met één. Het is noodzakelijk dat de opgegeven array aan absolute waardes continu oploopt.

SPLITCAR (array van singles, alle motieven |0.1-100.0| geen default): de expliciet gecodeerde aandelen aan autobestuurders voor de opgegeven bandbreedtes worden opnieuw via een array van percentages opgenomen. Het aantal percentages is gelijk aan het aantal gehanteerde banden, en komt overeen met het aantal drempels aangereikt met parameter SPLITTRESHOLD vermeerderd met één.

SPLITPASS, SPLITPT, SPLITCC en SPLITWK: deze parameters zijn analoog aan SPLITCAR, en verwijzen respectievelijk naar de relatieve aandelen voor autopassagier, openbaar vervoer, fiets en te voet, en dit voor dezelfde geldende bandbreedtes. Theoretisch moeten per bandbreedte de opgetelde aandelen over de vijf modi gelijk zijn aan 100 procent, maar eventueel kan hiervan afgeweken worden indien enkel de relevante modi aangereikt worden.

ASCCARDELTA (single, werk |-10.0-10.0| 0): MINTOD laat ook toe om op een directe manier in het geïntegreerde discrete keuzemodel voor vervoerwijze in te grijpen. Het logitmodel overgenomen uit de modelstructuur versie 3.6.0 combineert alle kostcomponenten met hun respectievelijke sensitiviteitsparameters enerzijds en de alternatief-specifieke constanten als waardering voor foutieve metingen of onkennis over componenten anderzijds. Deze constanten bieden een efficiënte sturing van aantrekkelijkheid of afkeer van een mode, en manipulatie van deze constanten laat toe om gericht bepaalde modi voor het geselecteerde project meer of minder aantrekkelijker te maken, zonder in complexe bijtrekking van de sensitiviteitsparameters te belanden. De parameter ASCCARDELTA wordt in absolute term opgeteld bij de alternatief-specifieke constante voor het betrokken verplaatsingsmotief, en zal, bij positieve waarde en onveranderde constanten van de andere modi, het aandeel autobestuurder verhogen. Negatieve waardes zullen andersom de mode autobestuurder minder aantrekkelijk maken en het aandeel verminderen. Technisch gezien zijn er geen grenzen aan deze waarde, maar gegeven de normale invulling van vervoerwijzekeuzeparameters zijn waardes rond 0 meest voor de hand liggend, een amplitude van plus of min tien is extreem groot. De standaardwaarde staat logischerwijze op 0.1

ASCPASSDELTA, ASCPTDELTA, ASCCCDELTA en ASCWKDELTA: ook hier wordt de parameter per mode apart ingesteld, analoog aan ASCCARDELTA, met als invulling de absolute bijsturing van de alternatief-specifieke constante voor de refererende mode.

CAR (single, werk |0.01-9999.0| geen default): de algemene werkwijze van MINTOD komt neer op een doorlopen van verschillende deelfasen om, indien gewenst, finale modale verplaatsingsmatrices voor het geselecteerde uur te bekomen. Ritgeneratie, tijdstipkeuze en vervoerwijzekeuze leiden generiek naar de volumes auto’s, OV-reizigers, … Distributie op zich bepaalt de verdeling over herkomsten en bestemmingen, maar bepaalt op zich niet direct het aantal modale verplaatsingen voor het project. Dikwijls echter wordt vanuit de projectinformatie rechtstreeks ingevuld welke volumes auto’s of OV-reizigers het project aantrekt en genereert voor de te modelleren periode. De parameter CAR wordt daarom aangeboden om op de meest directe manier dit resultaat in te voeren, als zijnde het totaal aantal autobestuurders gerelateerd aan het project voor het gemodelleerde uur. De processen generatie, tijdstipkeuze en vervoerwijzekeuze worden dan buiten werking gesteld, enkel distributie zal dit opgegeven volume verdelen over herkomsten en bestemmingen. Technisch gezien worden binnen MINTOD voor het bewuste project alle andere variabelen dusdanig geschakeld dat het normale totale proces op het opgegeven aantal autobestuurders komt.

PASS, PT, CC en WK: naast de parameter voor autobestuurders kunnen ook voor de 4 andere modi passagier, OV, fiets en te voet de totale volumes van en naar het project samen opgegeven worden.

VEHICLES (single, vracht zwaar en vracht licht |0.01-9999.0| geen default): analoog aan de volumes modale ritten uit voorgaande parameters, kan ook voor zwaar en licht vrachtverkeer het aantal vrachtwagens als voertuigen van en naar het project voor het gemodelleerde uur rechtstreeks opgegeven worden. De opgegeven waardes betreffen voertuigen, en worden dus in geen vorm van personenauto-equivalenten gewaardeerd.

SHAREIN (single, alle motieven |0.01-100.0| 50) en SHAREOUT (single, alle motieven |0.01-100.0| 50): de parameters CAR, PT, … en VEHICLES laten toe om per mode het exact aantal ritten voor het gemodelleerde uur op te geven. Dit modale totaal betreft de som van alle toekomende en vertrekkende ritten, standaard gaat MINTOD uit van een symmetrische verdeling tussen vertrekkende en aankomende stromen. Dit uitgangspunt is niet altijd wenselijk. De parameters SHAREIN en SHAREOUT laten toe om per project deze verdeling asymmetrisch in te stellen, en één bepaalde richting meer of minder zwaar te laten doorwegen. Normaliter dient de som van deze twee parameters 100 te zijn, maar in afwijkende gevallen wordt de relatieve verdeling tussen de twee parameters gehanteerd. Indien slechts één van deze twee parameters opgegeven wordt, wordt verondersteld dat de andere richting een aandeel van 0 procent heeft !

De relatieve verdeling naar vertrekkend en aankomend verkeer wordt over de opgegeven modi identiek beschouwd: het is in normale omstandigheden niet gewenst een afwijkende modale verdeling te verkrijgen tussen in- en uitgaande verplaatsingen. Indien dit toch noodzakelijk is, kan rond deze conditie gecodeerd worden door de verschillende modi geïsoleerd per project op te geven.


0.7.Overzichtstabel keywords en parameters


Onderstaande tabel geeft een synthese van alle keywords en parameters die in voorgaand onderdeel werden beschreven, met daarbij een indicatie van het type, voor welk thema ze gelden en ook een indicatieve oplijsting van het interne proces in MINTOD waarin de keywords of parameters sturen:


0.8.Verduidelijkende voorbeelden van projectfiches


Volgende onderdelen illustreren verschillende manieren om projecten door te rekenen en duiden de gekozen keywords en parameters.

0.8.1.Voorbeeld 1


PROJECT = "Bedrijventerrein A",

;Algemene kenmerken

CATEGORY = INDUSTRIAL,

ZONE = 1500,

COSTZONE = 610,

AREA = 75,

NETAREA = 0,

TYPE = WORK,

EMPLOYEES = 0,

;Distributie

AVTRIPLENGTH = 15,

;Tijdstipkeuze

SHIFT = 30,

;Vervoerwijzekeuze

SPLITTRESHOLD = 5,10,

TRESHOLDCOST = DISTANCE,

SPLITCAR = 50,60,80,

SPLITPASS = 5,5,10,

SPLITPT = 15,20,10,

SPLITCC = 15,15,0,

SPLITWK = 15,0,0,

TYPE = FREIGHTHEAVY,

AVTRIPLENGTH = 40,

BALANCEFACTORS = FREIGHT_HEAVY


Dit project bevat een industrieterrein in een nieuwe zone 1500, voor de kosten van en naar dit gebied wordt verwezen naar de kosten van zone 610 waarvoor alle informatie reeds aanwezig is. De totale bruto-oppervlakte bedraagt 75 ha, de netto-oppervlakte wordt niet opgegeven. Resultaten rond werkverplaatsingen en zware vracht worden opgevraagd door hun respectievelijke thematische keywords. Voor werk wordt geen informatie rond generatie en tijdstipvoorkeur opgegeven, en zal MINTOD eigen interne functies gebruiken. De rekenmethodiek wordt niet gespecifieerd, dus deze valt op de standaard-methodiek die in het script gecodeerd is. Inzake distributie is wel bekend dat de gemiddelde triplengte 15 kilometer is, dit roept de zelfkalibratie van MINTOD aan, en zorgt voor een distributie op basis van afstand eerder dan tijd. Voor tijdstipkeuze worden ook geen verdelingen opgegeven, enkel wordt gesteld dat 30 procent van de werknemers in een shift-regime zit, en dus valt onder een afwijkende tijdstipverdeling. Voor vervoerwijzekeuze wordt een boel informatie aangereikt: splitverdelingen worden opgegeven in bandbreedtes van afstand. Een onderscheid wordt gemaakt naar trips korter dan 5 kilometer, tussen 5 en 10 en boven de 10 kilometer: de mode te voet is alleen opgegeven voor de kortere trips, fiets loopt tot maximaal 10 kilometer, en autobestuurder wordt belangrijkst voor langere trips.

Ook voor vrachtverkeer wordt geen info rond ritgeneratie of tijdstipverdeling aangereikt, en worden de interne kencijfers gebruikt. Voor de distributie wordt zelfkalibratie op gemiddelde afstand van 40 kilometer opgelegd. De balansfactoren worden wel expliciet vermeld, en de distributie zal zich voor aantrekkelijkheid van herkomsten en bestemmingen baseren op het huidige belang van deze zones voor het zware vrachtverkeer: de gesommeerde producties en aankomsten van alle andere zones dient als polariteit.


0.8.2.Voorbeeld 2


PROJECT = "Bedrijventerrein B",

CATEGORY = REGIONAL,

ZONE = 1505,

COSTZONE = 874,

AREA = 0,

NETAREA = 0,

TYPE = WORK,

EMPLOYEES = 450,

PRESENCE = 90,

;Tijdstipkeuze

INTIME=6*0,5,20,50,15,2*5,

OUTTIME=12*0,2*10,0,20,50,5,5,

;Distributie

LAMBDA = -0.175,

POWER = 1.3,

;Vervoerwijzekeuze

ASCPASSDELTA = 1.5

Een gelijkaardig voorbeeld betreft een regionaal bedrijventerrein. Voor dit project wordt het generatiemodel gevoed met een verwacht aantal werknemers van 450, waarvoor een dagelijks aanwezigheidspercentage van 90 procent voorop gesteld wordt. Ook de tijdstipverdeling is op voorhand bekend, en wordt ingevoerd. Om 6 uur ’s ochtends komt 5 procent van de dagelijkse relaties in het project aan, om 7 uur is dat 20 en om 8 uur is dat 50 procent. Vanaf 12 uur worden geen aankomsten meer opgegeven. Om 12 uur en om 13 uur vertrekken telkens 10 procent van de dagelijkse relaties, de rest komt later op gang. Voor de distributie van alle verplaatsingen zijn de factoren voor de formulering op miraculeuze wijze bekend ! De vervoerwijzekeuze is niet bekend en wordt berekend met het interne discrete keuzemodel. Wel wordt een bonus gegeven aan de mode autopassagier waardoor deze een relatief hoger aandeel zal krijgen.


0.8.3.Voorbeeld 3


PROJECT = "Bedrijventerrein C",

CALCULATION = CROW,

CATEGORY = LOGISTICS,

ZONE = 1510,

COSTZONE = 225,

NETAREA = 20,

TYPE = WORK,

TRIPS = 400,

;Distributie

BALANCEFACTORS = SDD_BEVOLKING + SDD_WRKZ_TOTL,

AVTRIPDURATION = 30,

TYPE = FREIGHTHEAVY,

TYPE = FREIGHTLIGHT
Een logistiek project wordt ingepland in zone 1510. Een netto-oppervalkte van 20 hectare wordt voorbehouden voor deze functie. De rekenmethodiek wordt voor dit project gedwongen volgens de CROW-richtlijnen. Voor de werkverplaatsingen wordt echter welk het aantal dagelijkse relaties opgegeven, waardoor het generatiemodel niet hoeft te rekenen. Tijdstipkeuze en vervoerwijzekeuze worden volledig vrijgelaten. Inzake de distributie van de woon-werkrelaties wordt een gemiddelde ritduur van 30 minuten vooropgesteld, eerder dan een gemiddelde afstand. De balansfactoren worden ook afwijkend opgegeven, de aantrekkelijkheid van alle zones wordt berekend als zijnde de som van de totale bevolking en de werkzamen vanuit de sociodemografische databank.

Ook verplaatsingsmatrices voor zware en lichte vrachtwagens worden opgevraagd. Er wordt geen enkele informatie aangereikt, MINTOD zal enkel op basis van kencijfers rond logistieke projecten met een bruikbare oppervlakte van 20 hectaren gaan rekenen.


0.8.4.Voorbeeld 4


PROJECT = "Bedrijventerrein D",

CATEGORY = SERVICES,

ZONE = 1515,

COSTZONE = 120,

TYPE = WORK,

BALANCEFACTORS = MODE_CAR + MODE_PASSENGER,

AVTRIPLENGTH = 40,

CAR = 210


Op bedrijventerrein D in zone 1515 wordt een dienstenproject gerealiseerd. Er worden voor het gemodelleerde uur 210 autobestuurders opgelegd, zonder verdeling inkomend of vertrekkend, waardoor MINTOD een symmetrische verdeling zal hanteren. De gemiddelde ritlengte naar het project wordt op 40 kilometer gekalibreerd. Het distributiepatroon wordt gebaseerd op huidige volumes van autobestuurders en –passagiers, dit uit de aangereikte mode-matrices.

0.8.5.Voorbeeld 5


PROJECT = "Bedrijventerrein E",

;Algemene kenmerken

CATEGORY = LOCAL,

ZONE = 1454,

COSTZONE = 936,

TYPE = WORK,

BALANCEFACTORS = MODE_CAR + MODE_PASSENGER,

CAR=400,


PT=100,

SHAREIN=75,

SHAREOUT=25

Voor een lokaal bedrijventerrein in zone 1454, waarvan de kosten voorgesteld worden door zone 936, worden de werkmatrices berekend. Ritgeneratie, tijdstip- en vervoerwijzekeuze worden kort gesloten, voor het project wordt opgelegd dat er in het gemodelleerde uur 400 autobestuurders en 100 OV-reizigers zich verplaatsen. Van deze volumes wordt drie kwart verwacht aan te komen in het project, en één kwart te vertrekken. Voor de distributie wordt gesteld dat huidige verplaatsingspatronen voor autobestuurders en –passagiers maatgevend zijn.



Verdere Ontwikkeling Vlaamse Verkeersmodellen






De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina