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 <[email protected]> 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
_______________________________________________
sumo-user mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
