Am Sa., 18. Jan. 2020 um 17:36 Uhr schrieb Lionel Giard <
lionel.gi...@gmail.com>:
> I wasn't speaking about disabled only here, even if it must exist
> countries where disabled are marked but not enforced by law, but i don't
> know any example. But for other dedicated parking space like "parent"
Allesandro,
I wasn't speaking about disabled only here, even if it must exist countries
where disabled are marked but not enforced by law, but i don't know any
example. But for other dedicated parking space like "parent" or "electric
charging", there are not many country enforcing them by law,
sent from a phone
> On 17. Jan 2020, at 19:57, Alessandro Sarretta
> wrote:
>
> If the parking_space with specific symbology is regulated by law and only
> accessible by disabled persons (like in Italy)
btw, in Italy disabled parking spaces are accessible by everyone, but only
disabled
sent from a phone
> On 17. Jan 2020, at 10:40, Joseph Eisenberg
> wrote:
>
> If you use capacity:disabled on both features, this might lead to
> double-counting
yes, on the other hand I would see parking_space as parallel to parking, so if
one is inside the other it would seem logical
Hi Lionel,
On 17/01/20 10:52, Lionel Giard wrote:
Alesandro,
The thing is that disabled=designated is an access (so regulated by
law), and would depend because each country's law vary (not every
country enforce restriction for disabled parking or other type of
vehicle...). Thus, it may be
Well this specific case is quite easy to detect : if a parking space is
contained in a wider parking, you subtract the amount of places in
parking space from larger parking. And it would be easier to handle if
capacity tags are using same naming on both instead of being different
and needing
Alesandro,
The thing is that disabled=designated is an access (so regulated by law),
and would depend because each country's law vary (not every country enforce
restriction for disabled parking or other type of vehicle...). Thus, it may
be wrong to tag an access when it doesn't exist. While a tag
According to the wiki documentations, amenity=parking_space was
intended to be used inside of a larger amenity=parking feature.
So if there larger amenity=parking has capacity:disabled=4, you would
expect to find 4 amenity=parking_space features inside of it which are
available for disabled
Hello Lionel,
I totally agree with that, I never understood this special treatment of
amenity=parking_space, and so I'm using capacity:*=* with that. My use
case is for disabled people parking spaces : just look for
capacity:disabled=* and you're good to go, whatever it is a parking or
Le 17.01.20 à 09:36, Lionel Giard a écrit :
> What do you think about this?
keep simple.
if a parking space is only for disabled ppl with access restriction,
why not using capacity=* on it ?
it's not wrong but useless to use namespace capacity:disable=*
in this case.
especially since
Hi Lionel,
from what I've understood, the parking_space tag is meant to identify
exactly one parking space, so the capacity whould be always 1...
In the specific case of parking spaces for disables persons,
unfortunately there are many way of tagging it... In this issue related
to the
Hello everyone,
I saw that on the parking_space wiki page it says that we shouldn't use
capacity:*=* on parking_space, and instead use the access tag. But why is
this the case? It seems logical to use capacity:disabled=* on a
parking_space for disabled people or capacity:charging=* on a
12 matches
Mail list logo
