Re: [Tagging] Feature Proposal - RFC - more parking types

[Alessandro Sarretta]

Hi Graeme,

On 09/08/20 01:12, Graeme Fitzpatrick wrote:
On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke > wrote:


We already have capacity and capacity=disabled, what's the problem
with adding more
capacity:*?


But what number do we show for "capacity"?

I started wondering about this after one of the carparks you mentioned 
in Quantico recently showed capacity 15, with 11 car spaces + 4 
motorbike spaces. Should that be =15, or =11 + 4?


So, do we have a shopping centre parking lot with capacity=100, or 
should we have capacity:"vehicle"=60; capacity:motorbike=10; 
capacity:disabled=10; capacity:prams***=6; capacity:ev_charging=4; 
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5


the wiki (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking) 
seems to me quite clear about this, defining "capacity" as "The amount 
of available parking spaces, /including/ all special parking spaces 
(e.g., disabled). Read talk 
 page on 
this."


If one has all the available information, I think that the tag 
capacity=* and tags capacity:*=* can and should stay together.


Ale

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - more parking types

[Graeme Fitzpatrick]

On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke 
wrote:

> We already have capacity and capacity=disabled, what's the problem with
> adding more
> capacity:*?
>

But what number do we show for "capacity"?

I started wondering about this after one of the carparks you mentioned in
Quantico recently showed capacity 15, with 11 car spaces + 4 motorbike
spaces. Should that be =15, or =11 + 4?

So, do we have a shopping centre parking lot with capacity=100, or should
we have capacity:"vehicle"=60; capacity:motorbike=10; capacity:disabled=10;
capacity:prams***=6; capacity:ev_charging=4;
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5

***=prams - I'm not sure if they're yet a thing in OSM?, but that's
carparks marked as reserved for parents with prams eg
https://www.google.com.au/maps/@-28.0997524,153.4253639,3a,64.7y,77.23h,72.17t/data=!3m6!1e1!3m4!1s3e6IiMfvLC7DrZq1RA4TUA!2e0!7i16384!8i8192

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - more parking types

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2020, at 19:37, Matthew Woehlke  wrote:
> 
> Well, perhaps it is clear to you and I, but I found a number of 
> amenity=parking_space with capacity > 1 and no associated amenity=parking. 
> *Someone* is using it wrong :-).


yes, what I intended was that amenity=parking_space implies capacity=1, and any 
other capacity are not defined. The current scheme says you can add capacities 
for amenity=parking (but it will not tell you where these specific parking 
types are located within the parking), and you can add single parking spaces, 
one by one.


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] parking:lane:left=no / parking:lane:right=no / parking:lane:both=no

[Paul Allen]

On Sat, 8 Aug 2020 at 18:15, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> I need a tag that could be used where distinguishing between
> "no parking allowed" and "no stopping allowed" is not possible,
> not wanted or extremely hard.
>
> In many cases in Poland one may easily say that parking in some location
> along road is not allowed, but deciding whatever stopping is allowed
> is tricky and may depend on day/vehicles/weather/whatever else
> or may require a lawyer to answer.
>

Lawyers not required (in theory) in the UK.  It is all set out here:
https://www.highwaycodeuk.co.uk/parking.html#
Search for the word "unload".

Probably won't help you much,, except for giving you an idea of what
sort of situations are encountered elsewhere.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - more parking types

[Matthew Woehlke]

On 07/08/2020 18.08, Martin Koppenhoefer wrote:

On 7. Aug 2020, at 15:47, Matthew Woehlke wrote:
However, it sounds like you have this backwards; you are using
amenity=parking_space to map lots and amenity=parking to map
individual spaces. There appears to be a modest amount of such
backwards mapping, and it isn't localized to one area.


it was really just a slip


Okay, but then I don't understand the (original) objection? We already 
have capacity and capacity=disabled, what's the problem with adding more 
capacity:*? (Note that these apply to amenity=parking, *not* to 
amenity=parking_space. There is capacity, and *just* capacity — no 
capacity:*, and none is being proposed — on amenity=parking_space, 
although personally I question whether there should be...)


Is it just unclear that the proposed capacity:* apply to amenity=parking?


It was always clear that parking_space was for a single parking space
and the back then already well established “parking” was for a bigger
site with multiple spaces.


Well, perhaps it is clear to you and I, but I found a number of 
amenity=parking_space with capacity > 1 and no associated 
amenity=parking. *Someone* is using it wrong :-).


There are also a bunch of parking_space=* on *buildings*, which 
similarly seems like poor tagging. (I guess the intent is to say "the 
parking *associated with* this facility is X, but I really don't care 
for that vs. actually mapping the parking.)


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Swappable parking side - parking:lane:left_right_switchable=yes ?

[Mateusz Konieczny via Tagging]

See https://wiki.openstreetmap.org/wiki/Key:parking:lane for
documented tagging

In some cases parallel parking is allowed on one side of the road,
only one but not specified which one (as there is enough space to
park a car parallel - without obstructing traffic, but next car will not fit).

As result on one week vehicles may park on left side of the road, next
week all on right, the situation may also change along road length.

Is there any existing tagging covering this?

I thought about

parking:lane:left=parallel
parking:lane:right=no_stopping
parking:lane:left_right_switchable=yes

as it would allow backward compatibility, 
with parking tagged on side where it happens more often

Or just ignoring this, and tagging

parking:lane:left=parallel
parking:lane:right=no_stopping

(my current solution, but I feel a bit guilty about it)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Mateusz Konieczny via Tagging]

And we have at least three amenity tags for parkings
amenity=parking
amenity=bicycle_parking
amenity=motorcycle_parking

Aug 8, 2020, 19:10 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 8. Aug 2020, at 17:58, Paul Johnson  wrote:
>>
>> Which honestly makes me surprised we have two separate amenities for parking 
>> already, since >> amenity=parking>> , >> access=no>> , >> 
>> bicycle=designated>>  would be equivalent to >> amenity=bicycle_parking>> , 
>> and would make it easier to describe unusual parking situations (like a 
>> parking area that only allowed bicycles and buses to park) more intuitively.
>>
>
>
> this tagging would probably exclude pedestrians from walking through the 
> parking. It is also inconsistent with the definition of amenity=> parking: “> 
>  A place for parking cars“
> It seems pointless to discuss these hypothetical alternative tagging 
> definitions when we all know that if is very unlikely that the definition of 
> a well established tag will be changed completely.
>
>
> Cheers Martin 
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] parking:lane:left=no / parking:lane:right=no / parking:lane:both=no

[Mateusz Konieczny via Tagging]

For people unfamiliar with parking lane tagging see
https://wiki.openstreetmap.org/wiki/Key:parking:lane

I need a tag that could be used where distinguishing between
"no parking allowed" and "no stopping allowed" is not possible,
not wanted or extremely hard.

In many cases in Poland one may easily say that parking in some location
along road is not allowed, but deciding whatever stopping is allowed
is tricky and may depend on day/vehicles/weather/whatever else
or may require a lawyer to answer.

Or someone may be simply not interested in answering
or should not be assumed to be able to answer (in case of not editing tags 
directly).

I started using 
parking:lane:left=no / parking:lane:right=no / parking:lane:both=no
instead of =no_stopping and =no_parking in such cases.

Is there a better alternative for such tags?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2020, at 17:58, Paul Johnson  wrote:
> 
> Which honestly makes me surprised we have two separate amenities for parking 
> already, since amenity=parking, access=no, bicycle=designated would be 
> equivalent to amenity=bicycle_parking, and would make it easier to describe 
> unusual parking situations (like a parking area that only allowed bicycles 
> and buses to park) more intuitively.


this tagging would probably exclude pedestrians from walking through the 
parking. It is also inconsistent with the definition of amenity=parking: “ A 
place for parking cars“
It seems pointless to discuss these hypothetical alternative tagging 
definitions when we all know that if is very unlikely that the definition of a 
well established tag will be changed completely.


Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Paul Johnson]

On Sat, Aug 8, 2020 at 6:13 AM Jan Michel  wrote:

> On 07.08.20 23:36, Martin Koppenhoefer wrote:
> >> On 7. Aug 2020, at 19:12, Paul Johnson  wrote:
> >> I feel like a data consumer unable to deal with access tagging is
> already broken in advance.
> > although we already use access like tags for parkings it should be noted
> that being allowed to access is different to being allowed to park, in
> general.
>
> The only use of an amenity=parking is to park there, so there is no
> other access that we have to consider. The situation may be different
> for ways and streets on the parking lot, but these are tagged separately
> anyhow. If the whole area is also used for other purposes (like street
> markets), then this is tagged on a spearate object with separate access
> tags.
>

Which honestly makes me surprised we have two separate amenities for
parking already, since amenity=parking, access=no, bicycle=designated would
be equivalent to amenity=bicycle_parking, and would make it easier to
describe unusual parking situations (like a parking area that only allowed
bicycles and buses to park) more intuitively.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 08.08.20 15:30, Martin Koppenhoefer wrote:



sent from a phone

On 8. Aug 2020, at 14:48, Jan Michel 
 wrote:

amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=ye
this doesn’t allow for bicycles to be parked. It also doesn’t seem to be 
a subtype of parking. If it would be just for motorcycles and 
kick_scooters, why not

amenity=motorcycle_parking
kick_scooter=yes ?


Because this gives too many options on how to tag parking for 
kick_scooters depending on what other vehicles are allowed as well:


amenity=parking + kick_scooter = yes
amenity=bicycle_parking + kick_scooter = yes
amenity=motorcycle_parking + kick_scooter = yes
and last but not least the scooter-only parking where none of the three 
options above applies.


That will just be a mess of tags nobody can actually use - orders of 
magnitude worse than having one common tag for all motorized vehicle 
parking and access tags for individual vehicle types.



amenity=small_vehicle_parking  + motorcycle=yes + kick_scooter(*)=yes



not sure what a “small vehicle” is supposed to be. 
Needs to be defined, like any other new tag. What is a 'kick_scooter'? 
With a motor? without a motor? with a tiny seat?
Most likely it will boil down to something like single-tracked, open 
vehicle for two people at most.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2020, at 14:26, Jo  wrote:
> 
> You could add all.


WRT mapping the stop position I agree that adding them all would make sense. 
For the connection  relation I believe it is not manageable to record and 
maintain this level of detail, and the practical gain is very limited because 
of dynamic variations in every day operations (might vary according to the 
railway company, maybe somewhere this is more stable).

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2020, at 14:48, Jan Michel  wrote:
> 
>> features, either bicycle or motorcycle and scooter parkings.
> 
> 
> I already proposed two options. You didn't like either.
> 
> amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=ye


this doesn’t allow for bicycles to be parked. It also doesn’t seem to be a 
subtype of parking. If it would be just for motorcycles and kick_scooters, why 
not
amenity=motorcycle_parking
kick_scooter=yes ?

that’s already established and there’s no need to make vehicle=no headstands.


> 
> amenity=small_vehicle_parking  + motorcycle=yes + kick_scooter(*)=yes


not sure what a “small vehicle” is supposed to be. Motorcycles with sidecars? 
Mofas? Cabin scooters? Three wheeled commercial vehicles? Golf carts? Electric 
wheelchairs? Snowmobiles? Small automobiles like smarts? Fiat 500? Will there 
be a definition which makes it possible to understand generically which kind of 
vehicles are permitted and banned, or would it require an infinite yes/no list 
for all kinds of vehicles? Is there a legal correspondence in highway codes 
that you are aware of?

Cheers Martin 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 08.08.20 14:22, Martin Koppenhoefer wrote:

On 8. Aug 2020, at 13:46, Jan Michel  wrote:
If I just enter 'scooter parking' into Google Image Search, I find plenty 
examples of designated parking areas for both bicycles and scooters combined. 
There are also some moped/mofa parkings that allow (kick-)scooters to be found.

then find a tag for them ;-) (de:Zweiradstellplatz), around here these are 
separate, distinct features, either bicycle or motorcycle and scooter parkings.


I already proposed two options. You didn't like either.

amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=yes

amenity=small_vehicle_parking  + motorcycle=yes + kick_scooter(*)=yes


(*) just a placeholder for the yet-to-be-defined proper tag


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Jo]

You could add all. My solution would be to add no stop_position nodes to
the route relations. I would suffice with a single platform node that
represents platform and has all the relevant details.

That's not how train stops are mapped atm though, and some platforms are
divided in zones. In that case I would have one such node per zone, but
again you might want to add each such zone to the train route relations.

Food for thought.

Polyglot (who is more into mapping buses than trains)

On Sat, Aug 8, 2020, 03:19 Jarek Piórkowski  wrote:

> On Fri, 7 Aug 2020 at 20:54, Andy Townsend  wrote:
> > https://www.openstreetmap.org/node/12004813 is a
> > "public_transport=stop_position" for a local station and is part of
> > https://www.openstreetmap.org/relation/6396491 among other relations.
> > The problem is that train lengths vary, and there are a number of stop
> > positions, each of which are actually signed on the platform for the
> > benefit of the drivers.  From memory I think that there's at least a
> > 2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is
> > that the current node doesn't correspond to any of them.
> >
> > As I asked on the changeset that added the one above
> > https://www.openstreetmap.org/changeset/40603523 , how should these be
> > mapped and how should the PTv2 relations be set up for the different
> > services that use them, given that different train services will use
> > different stop locations here depending on train length?  Should each
> > stop position be mapped and should there therefore be different copies
> > of each relation for all the possible train lengths?  Should a "pretend"
> > average stop position be added which is actually never correct but will
> > at least look nice to data consumers that use PTv2 data?  Given that we
> > don't know the actual stop position perhaps the railway=station object
> > (in this case https://www.openstreetmap.org/node/7154300845 ) should be
> > used instead?
>
> Neither of these seem like great options. Personally: if the stopping
> positions for trains of different lengths have actually been surveyed,
> I don't have a problem with adding several stop_position nodes with a
> note=* or description=* or even an invented
> stop_position:train:cars=10;12. Don't put any other tags on them and
> they won't render, and it's hardly the most cluttersome of our various
> micromappings.
>
> There is however a problem if the Midland Main Line trains come in
> different lengths. I suppose you could create a separate route
> relation for each set service (from, to, calling at, and train length)
> and add the stop_positions to the appropriate relation, but that's
> pretty extreme relationing.
>
> (As a bit of background, I believe this is a German influence in the
> original PTv2 proposal: a given train ref (e.g. "ICE 13") refers to a
> single train that will have the same amount of carriages
> (extraordinary circumstances excepted). That's more specific than a
> "Midland Main Line: Sheffield => London St Pancras" relation.)
>
> > Maybe the public_transport=stop position should be omitted entirely?
> > This last option seems extreme, but one reading of
> > https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
> > where it says "However, marking the stop position adds no information
> > whatsoever when it is placed on the road at the point closest to
> > highway=bus_stop or on the tram tracks closest to railway=tram_stop. In
> > that case it can be abandoned. " might actually support that (and that
> > seems to be the view of one side of the argument in the USA).
>
> Note that this sentence was added in various edits in 2020, well after
> the initial proposal was approved. "adds no information" might well be
> true (given enough computing power), but "it can be abandoned" is
> someone's opinion.
>
> I'm personally fine with not having stop_position unless the actual
> stopping position is ambiguous due to some very unusual geometry, but
> to be clear, this is against the initially approved proposal.
>
> > Maybe the "correct" answer is none of the above?  With a "local mapper"
> > hat on I've managed to avoid PTv2 since it basically isn't relevant
> > anywhere I normally map things, largely because I don't tend to do that
> > near any actual public transport infrastructure, but with a DWG hat on I
> > haven't been able to avoid the question, hence me asking here.
>
> I hope the DWG hat is fireproof :) ptv2 is a topic that arouses passions.
>
>
> --Jarek
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2020, at 13:46, Jan Michel  wrote:
> 
> If I just enter 'scooter parking' into Google Image Search, I find plenty 
> examples of designated parking areas for both bicycles and scooters combined. 
> There are also some moped/mofa parkings that allow (kick-)scooters to be 
> found.


then find a tag for them ;-) (de:Zweiradstellplatz), around here these are 
separate, distinct features, either bicycle or motorcycle and scooter parkings.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 07.08.20 23:33, Martin Koppenhoefer wrote:


sent from a phone


On 7. Aug 2020, at 17:57, Jan Michel  wrote:

I propose to not introduce new top-level keys because they are not flexible 
enough. I'm very well aware that we have parking, bicycle_parking and 
motorcycle_parking already, but it just doesn't scale with the amount of 
different vehicle types.


I don’t see why the tags should be flexible as the parkings aren’t. You cannot 
park a bicycle at a motorcycle parking nor the contrary.


If I just enter 'scooter parking' into Google Image Search, I find 
plenty examples of designated parking areas for both bicycles and 
scooters combined. There are also some moped/mofa parkings that allow 
(kick-)scooters to be found.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Mateusz Konieczny via Tagging]

At least one in Poland are described as parking, and at least in theory anyone 
may
park an electric scooter there, including private one.

Aug 8, 2020, 03:01 by graemefi...@gmail.com:

> Just to open a different semantic can of worms concerning the spots these 
> hire "scooters" are left ... :-)
>
> Are they "parked"?
>
> To me, I "park" my car in a parking space, come back to it after shopping & 
> drive home, or I "park" my bicycle in a rack at the beach, wrap a chain 
> around the wheel, then come back later, unlock it & ride away ie I retrieve 
> my own "vehicle" at a later stage.
>
> If you've used a hire "scooter" to get from A to B, do you "park" it at B, or 
> do you return it to a hire location / drop off spot? I think it's more 
> correct to say that you simply leave it in a spot where anybody else can use 
> it & when you come back later on, you hope there's one still there for you to 
> use!
>
> Should we possibly be looking at something similar to amentiy=bicycle_rental, 
> ie amenity=scooter_rental?
> https://wiki.openstreetmap.org/wiki/Tag:amenity=bicycle%20rental
>
> Thanks
>
> Graeme
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging