Re: [sumo-user] Modelling Parking Areas and Parking Spaces in SUMO

[The div <div@xxxxxxxx>]

hi,

I've been looking at parking simulation recently because I wanted to model the behavior within a surface parking lot - my observations in the context of your questions are:

> Does every parking space has to have a parent element of a Parking Area

yes - the parking area defines the effective entry / exit points for a <space>

>What’s the difference between parking space definitions, using the attribute tags of a <parkingArea> instead of modelling it as child tags, with separate <space …/>-tags. Is there a logical or semantical difference?

<parkingArea> tags provide the simplest approach to configuring spaces alongside or 'on' a lane. The angle parameter allowing easy representation of chevron bays - whether acute or obtuse angled.  I understand that <space> bays were intended to represent roadside 'lots' and as such each individual <space> needs to be positioned.   ( A <space> can be positioned on top of a lane but will not impact traffic in any way - roadsideCapacity with _onRoad_="true" will impede traffic - once a vehicle is in a <space> it is off the network as far as the simulation is concerned.)

By default the 'parking' behaviour is the same for a <space> and a tag area where   _onRoad_="false"   A vehicle scheduled to park enters a bay and is removed from the lane in the simulation step after the vehicle has reached the start of the parking area.

>When should which parking spaces be combined into a common parking area? Is it meant to be used row-, or even level-wise

I do not know if there is any specific guideline - a <parkingArea> can be as 'long' as the lane - if the lane turns corners then so does the <parkingArea> and associated 'roadsideCapacity'  spaces. 

<space> entries are positioned independently of the lane and can be anywhere in the model.  ( Where these are positioned well away from the lane the GUI appearance is surreal in that vehicles "leap" from lane to parking space.)  If appearances matter then you may wish to position multiple smaller parkingAreas. This also permits you to configure rerouting between these discrete areas - more closely matching behaviour of a driver noting the lane in front is full and driving on to another rather than waiting for a space.

I do not believe there is any sanity checking in area/space configurations. eg you can have a roadsideCapacity of 100 6m spaces in a lane length of 20m and all spaces will be 'squeezed' in with vehicles parking on top of each other. This is great if you just want to model capacity in eg a multi-level park that is adjacent to the road because the entry/exit to the park will be relative to the length of the <parkingArea>.  (equally a <parkingArea> can overlap another.)

I perceive that <space> tags are only relevant when you want the UI to illustrate the layout. There is nothing in the default simulation that illustrates vehicle behaviour within a 'lot' containing <space> areas - the appearance depends on where you position the spaces. For bays adjacent to a straight lane I cannot think of an advantage to using <space> whatever the angle.

>How are Parking Spaces and Parking Areas handled in SUMO logically?

A <space> must always be an element of a <parkingArea>

If you have roadsideCapacity > 0  and <space> tags, the simulation will fill the roadsideCapacity bays before the <space> bays.

The initial population of <space> bays will be in the order in which they appear in the declaration file. This has the "advantage", for UI behaviour, that you can manually arrange <space> bays to approximate to the most desirable spaces - with the caveat that the first <space> in the list should be positioned nearest the beginning of the <parkingArea> to avoid some jam scenarios.

My specific interest was in modelling behaviour within a surface lot and I wanted to follow blocking impacts associated with entry and exit to each space incorporating the different timings associated with bays aligned for reverse parking versus 'drive-in' parking. The default simulation in release 1.3 does not provide that. There are some updates in the current development release that begin to address this - if you are looking at this level of micro simulation I can provide more details.

good luck

div

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Sunday, 15 September 2019 21:39, Marc Zofka <zofka@xxxxxx> wrote:

Dear Sumo-Community,

 

we are currently modelling a parking garage level in sumo. This floor or level is made up of several rows of parking spaces, at each side of a driveable passage. During the modelling we came across the definition of Parking Areas, see [1]. Therefore, the question arose, to what extent a Parking Area is meant semantically and logically:

·         Does every parking space has to have a parent element of a Parking Area?

·         What’s the difference between parking space definitions, using the attribute tags of a <parkingArea> instead of modelling it as child tags, with separate <space …/>-tags. Is there a logical or semantical difference?

·         When should which parking spaces be combined into a common parking area? Is it meant to be used row-, or even level-wise?

·         How are Parking Spaces and Parking Areas handled in SUMO logically?

 

Thanks for your support.

 

Best regards,

Marc

 

[1] https://sumo.dlr.de/docs/Simulation/ParkingArea.html