Re: [Tagging] Feature Proposal - RFC - electricity=*

[Robert Delmenico]

I like the new options.

In Australia it would be beneficial to note which addresses don't have
power, rather than those that do so this would work well.

For remote communities in Australia, the off grid option would be good.

Many homes also have solar panels connected and this would be great for
firefighters as solar panels provide an electrocution risk in a house for
situation.

Rob

On Wed, 4 Nov 2020, 8:10 am Lukas Richert,  wrote:

> I also think the *electricity:grid=yes/no/backup* and
> *electricity:generator=yes/no/backup* tags are clearer and would allow
> for off-grid buildings to be tagged more distinctly.
>
> The electricity tag isn't used a lot yet. I have no experience with
> automated or semi-automated edits, but perhaps changing electricity=none
> and electricity=grid to electricity:grid=yes would be relatively
> straightforward? (This is unfortunately the problem with people adding
> major undiscussed/proposed tags to the main wiki. Especially power_supply
> is frustrating. )
>
> What do others think about the tag options
>
> electricity:grid=yes/no/backup
> electricity:generator=yes/no/backup
> electricity=yes
> electricity=no
>
> [electricity=yes would be used when grid or generator is unknown] instead
> of
>
> electricity=grid
> electricity=generator
> electricity=yes
> electricity=no
>
> Cheers Lukas
>
>
> On 03/11/2020 21:20, Andrew Harvey wrote:
>
>
>
> On Wed, 4 Nov 2020 at 00:13, Lukas Richert  wrote:
>
>> Hi,
>>
>> While the original proposal did specify that generators are usually
>> diesel, broadening the definition would only lead to a loss of detail, but
>> the tagging would still be correct. I'm hesitant to use *offgrid* as a
>> building that has, for example, a grid connection with solar panels on the
>> roof would then be tagged as *electricity=grid;offgrid* instead of
>> *electricity=grid;generator*. The former is illogical.
>>
>> However, I don't have any experience in developing countries: is it
>> easier to verify if something is off-grid compared to if it is connected to
>> a generator? And, would it be necessary to differentiate between local
>> grids (i.e. 2-3 generators, no substations, transfromers, etc.) and
>> national grids? Perhaps then a network tag would be useful, i.e.
>> network=national, local, regional similar to the way cycle networks are
>> mapped?
>>
>> A further suggestion was to change the tagging to
>> *electricity:grid=yes/no/backup* and/or
>> *electricity:generator=yes/no/backup*. This might be less ambiguous for
>> tagging amenities or buildings that get electricity from both sources and
>> would then be more consistent with tagging such as
>> *electricity:generator:origin=diesel* when, e.g. a building has a backup
>> diesel generator but is connected to the grid. Unfortunately, it would then
>> not be consistent with the use by the Healthsites Mapping Project, although
>> this already has the inconsistent *electricity=none* tag which should
>> probably be changed directly to *electricity=no.*
>>
> Here is the link to that suggestion I made
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#multiple_values
>  and
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#origin_of_different_sources
>
> The whole point of the proposal process is to identify these potential
> issues, resolve them, and get community agreement. If the goal is just to
> implement someone else's standard then we can't use the wisdom of the
> community here to improve the tag, therefore I'm not too fussed about
> making this match what another project is using, instead we should aim to
> have the best tags and documentation as the outcome of this proposal
> process. Then if that's different, other projects closely tied to OSM can
> migrate to the OSM community accepted schema.
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] entrance/door tagging, node not included in the building way

[Martin Koppenhoefer]

Am Di., 3. Nov. 2020 um 17:38 Uhr schrieb Samuel BRAIKEH <
samuel.brai...@uca.fr>:

> But writing to the "tagging" list, it is about a particular tagging case !
> :) Here is a concrete example with this node:
> https://www.openstreetmap.org/edit?node=3843013022#map=19/45.77457/3.08758
> (many nodes in this neighbourhood have similar characteristics).
>
>- It has a housenumber tag, and is associated with a street through a
>relationship (house).
>- However, the point is not part of the building way.
>
> We want to add the *entrance* and *door* attributes, and possibly address
> attributes if necessary.
>
> Which strategy do you think is the most relevant ?
>
>-
>
>give door / entrance tags to this point, leaving it free
>-
>
>integrate the point into the building way, keep the point-street
>relationship
>-
>
>integrate the point into the building way, remove the point-street
>relationship, complete with *addr:street*, *addr:city*, *addr:postcode*
>tags ...
>
>
I would integrate the node in the building-way (possibly at the position of
the entrance) and add an entrance=* tag. In the end it depends where the
housenumber and other addressing information is relating to. If it relates
to the whole building, you should integrate the address on the building
outline, if it refers to a specific point (e.g. an entrance door), it
should go on this point.

Regardless of this you can add addr:door tags to doors (where applying).

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

I also think the *electricity:grid=yes/no/backup* and 
*electricity:generator=yes/no/backup* tags are clearer and would allow 
for off-grid buildings to be tagged more distinctly.


The electricity tag isn't used a lot yet. I have no experience with 
automated or semi-automated edits, but perhaps changing electricity=none 
and electricity=grid to electricity:grid=yes would be relatively 
straightforward? (This is unfortunately the problem with people adding 
major undiscussed/proposed tags to the main wiki. Especially 
power_supply is frustrating. )


What do others think about the tag options

   electricity:grid=yes/no/backup
   electricity:generator=yes/no/backup
   electricity=yes
   electricity=no

[electricity=yes would be used when grid or generator is unknown] 
instead of


   electricity=grid
   electricity=generator
   electricity=yes
   electricity=no

Cheers Lukas


On 03/11/2020 21:20, Andrew Harvey wrote:



On Wed, 4 Nov 2020 at 00:13, Lukas Richert > wrote:


Hi,

While the original proposal did specify that generators are
usually diesel, broadening the definition would only lead to a
loss of detail, but the tagging would still be correct. I'm
hesitant to use *offgrid* as a building that has, for example, a
grid connection with solar panels on the roof would then be tagged
as *electricity=grid;offgrid* instead of
*electricity=grid;generator*. The former is illogical.

However, I don't have any experience in developing countries: is
it easier to verify if something is off-grid compared to if it is
connected to a generator? And, would it be necessary to
differentiate between local grids (i.e. 2-3 generators, no
substations, transfromers, etc.) and national grids? Perhaps then
a network tag would be useful, i.e. network=national, local,
regional similar to the way cycle networks are mapped?

A further suggestion was to change the tagging
to***electricity:grid=yes/no/backup* and/or
*electricity:generator=yes/no/backup*. This might be less
ambiguous for tagging amenities or buildings that get electricity
from both sources and would then be more consistent with tagging
such as *electricity:generator:origin=diesel* when, e.g. a
building has a backup diesel generator but is connected to the
grid. Unfortunately, it would then not be consistent with the use
by the Healthsites Mapping Project, although this already has the
inconsistent *electricity=none* tag which should probably be
changed directly to *electricity=no.*

Here is the link to that suggestion I made 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#multiple_values and 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#origin_of_different_sources


The whole point of the proposal process is to identify these potential 
issues, resolve them, and get community agreement. If the goal is just 
to implement someone else's standard then we can't use the wisdom of 
the community here to improve the tag, therefore I'm not too fussed 
about making this match what another project is using, instead we 
should aim to have the best tags and documentation as the outcome of 
this proposal process. Then if that's different, other projects 
closely tied to OSM can migrate to the OSM community accepted schema.


___
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] Feature Proposal - RFC - Rideshare Access

[Andrew Harvey]

On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:

> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>

But if such a dedicated pickup location is a carpark then it needs
amenity=parking, so it can't fit into the amenity key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Andrew Harvey]

On Wed, 4 Nov 2020 at 00:13, Lukas Richert  wrote:

> Hi,
>
> While the original proposal did specify that generators are usually
> diesel, broadening the definition would only lead to a loss of detail, but
> the tagging would still be correct. I'm hesitant to use *offgrid* as a
> building that has, for example, a grid connection with solar panels on the
> roof would then be tagged as *electricity=grid;offgrid* instead of
> *electricity=grid;generator*. The former is illogical.
>
> However, I don't have any experience in developing countries: is it easier
> to verify if something is off-grid compared to if it is connected to a
> generator? And, would it be necessary to differentiate between local grids
> (i.e. 2-3 generators, no substations, transfromers, etc.) and national
> grids? Perhaps then a network tag would be useful, i.e. network=national,
> local, regional similar to the way cycle networks are mapped?
>
> A further suggestion was to change the tagging to
> *electricity:grid=yes/no/backup* and/or
> *electricity:generator=yes/no/backup*. This might be less ambiguous for
> tagging amenities or buildings that get electricity from both sources and
> would then be more consistent with tagging such as
> *electricity:generator:origin=diesel* when, e.g. a building has a backup
> diesel generator but is connected to the grid. Unfortunately, it would then
> not be consistent with the use by the Healthsites Mapping Project, although
> this already has the inconsistent *electricity=none* tag which should
> probably be changed directly to *electricity=no.*
>
Here is the link to that suggestion I made
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#multiple_values
 and
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#origin_of_different_sources

The whole point of the proposal process is to identify these potential
issues, resolve them, and get community agreement. If the goal is just to
implement someone else's standard then we can't use the wisdom of the
community here to improve the tag, therefore I'm not too fussed about
making this match what another project is using, instead we should aim to
have the best tags and documentation as the outcome of this proposal
process. Then if that's different, other projects closely tied to OSM can
migrate to the OSM community accepted schema.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Update - RFC - Special Economic Zones

[Brian M. Sperlongano]

I appreciate the pointed questions offered here.  See responses in-line:

On Tue, Nov 3, 2020 at 4:37 AM Frederik Ramm  wrote:

> Hi,
>
> my opinion is that stuff that is not visible on the ground and not
> meaningfully editable by mappers needs a very strong reason to be mapped
> at all.
>
> 1. Are SEZ boundaries visible on the ground (signage, physical separation)?
>

Both types of SEZ boundaries exist.  Some are tagged with signage and
physical separation (as in the example photo in the proposal) and others
are legally-defined but invisible lines.  This is the exact same situation
as with all other values of boundary.  boundary=administrative,
boundary=postal_code, boundary=protected_area, and
boundary=aboriginal_lands are all examples of boundaries which sometimes do
and sometimes do not manifest in physical features on the ground.  Mapping
SEZs is consistent with this usage, and has been listed in the wiki under
the tag protect_class=23 for 10+ years.

If SEZs should not be mapped by this criterion, then all 2 million usages
of the key boundary= should also not be mapped.  We have formed a consensus
through usage that boundaries of various types should be mapped, regardless
of whether or not those boundaries physically manifest in features on the
ground.


> 2. If not, do SEZ boundaries usually coincide with existing
> administrative boundaries (counties X and Y as well as the city of Z
> together form the SEZ)?
>

Both cases exist.  Some SEZs are defined in terms of existing boundaries,
and others have dedicated boundaries.  This is similar to the case of
boundary=postal_code.


> 3. If not, how would you get your hands on the SEZ boundary?
>

By definition, an SEZ is an area in which laws are different from outside
the zone.  Implicit in that definition is the requirement that the boundary
be legally defined.  It is in those legal definitions that mappers can plot
such zones.  This is no different from the manner in which we are able to
map boundary=administrative and boundary=postal_code.

4. In how far is it useful for mappers to modify the SEZ boundary based
> on their knowledge or aerial imagery?


In places where the SEZ manifests in physical objects (signs, fences,
entrances, etc.), such knowledge or aerial imagery is indeed useful for
mapping such boundaries.  In the absence of these, mappers can use legal
definitions.  This is again no different from how we deal with
boundary=administrative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] entrance/door tagging, node not included in the building way

[Samuel BRAIKEH]

Hello all ! 



As part of the COMPAS project (Cartographie et Outils Multisensoriels Pour 
l'Accessibilité Spatiale - which means Mapping and Multisensory Tools for 
Spatial Accessibility), we developed a tool to add doors / entrances to 
buildings. [ https://wiki.openstreetmap.org/wiki/Compas | 
https://wiki.openstreetmap.org/wiki/Compas ] 

It is still a work in progress (and it's in French), but it works for the 
simplest cases. Feel free to try it out and give us feedback! [ 
https://od4m.limos.fr/build/ | https://od4m.limos.fr/build/  ] 





But writing to the "tagging" list, it is about a particular tagging case ! :) 
Here is a concrete example with this node: [ 
https://www.openstreetmap.org/edit?node=3843013022#map=19/45.77457/3.08758 | 
https://www.openstreetmap.org/edit?node=3843013022#map=19/45.77457/3.08758 ] 
(many nodes in this neighbourhood have similar characteristics). 

* It has a housenumber tag, and is associated with a street through a 
relationship (house). 
* However, the point is not part of the building way. 



We want to add the entrance and door attributes, and possibly address 
attributes if necessary. 

Which strategy do you think is the most relevant ? 

* 

give door / entrance tags to this point, leaving it free 
* 

integrate the point into the building way, keep the point-street relationship 
* 

integrate the point into the building way, remove the point-street 
relationship, complete with addr:street , addr:city , addr:postcode tags ... 



Thank you for your advices, 

See you 




Samuel, Jean-Marie, Jeremy 

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Mateusz Konieczny via Tagging]

Note in some regions where blackout are often happening it
is quite typical to have both grid connection and backup 
generator.

Is it also typical in hospitals, some factories and other places
where power loss would be especially problematic (what includes
also for example dams, even ones with their own hydro-power generators).

Nov 3, 2020, 14:08 by lrich...@posteo.de:

>
> Hi,
>
>
> While the original proposal did specify that generators are  usually 
> diesel, broadening the definition would only lead to a  loss of detail, 
> but the tagging would still be correct. I'm  hesitant to use > offgrid>  
> as a building that has, for  example, a grid connection with solar panels 
> on the roof would  then be tagged as > electricity=grid;offgrid>  instead 
> of > electricity=grid;generator> .  The former is illogical. 
>
>
> However, I don't have any experience in developing countries: is  it 
> easier to verify if something is off-grid compared to if it is  connected 
> to a generator? And, would it be necessary to  differentiate between 
> local grids (i.e. 2-3 generators, no  substations, transfromers, etc.) 
> and national grids? Perhaps then  a network tag would be useful, i.e. 
> network=national, local,  regional similar to the way cycle networks are 
> mapped?
>
>
> A further suggestion was to change the tagging to>  > 
> electricity:grid=yes/no/backup>  and/or > 
> electricity:generator=yes/no/backup> . This might be  less ambiguous for 
> tagging amenities or buildings that get  electricity from both sources 
> and would then be more consistent  with tagging such as > 
> electricity:generator:origin=diesel>  when, e.g. a building has a backup 
> diesel generator but is  connected to the grid. Unfortunately, it would 
> then not be  consistent with the use by the Healthsites Mapping Project,  
> although this already has the inconsistent > electricity=none>  tag which 
> should probably be changed directly to > electricity=no.>  
>
>
> Cheers, Lukas
>
>
>
>
> On 03/11/2020 07:14, Dolly  Andriatsiferana wrote:
>
>> Hi all, 
>>
>> Thanks a lot Lukas for reworking this proposal.
>>
>> I like Joseph's idea of >> electricity=grid/offgrid/yes/no>>  if  
>> you're introducing >> electricity:origin=>> *. 
>> I'd suggest dropping the generator value as it brings  confusion and 
>> can be difficult to verify. Originally  electricity=generator seemed 
>> to be intended for diesel  devices, but I think we should use 
>> something like  electricity:origin=diesel for it instead.
>>
>> @Volker, I understand the tag might be less relevant in  developed 
>> countries where it is normal to have electricity.  But electricity 
>> availability is an important information in  many developing 
>> countries (like mine) where most of the  population is not connected 
>> to the electricity grid. It would  be useful for health facilities 
>> and accommodation buildings...  - See Healthsites' data model at >> 
>> https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project>>  
>> where the tag is used.
>>
>> Good job, Lukas!
>>
>> -->>  
>> Dolly Andriatsiferana
>>
>> On Tue, Nov 3, 2020 at 4:11 AM  Lukas Richert <>> 
>> lrich...@posteo.de>> > wrote:
>>
>>>
>>> And, final email, I reworked the proposal page to include  
>>> tagged examples and explained some implicit defintions in  more 
>>> detail.
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/electricity
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>>
>>> On 30/10/2020 13:44, Lukas Richert wrote:
>>>

 Since a lot of people apparently didnt see the RFC the
 first time, I'll go back to RFC status for now. (Ithought 
 the threads were sorted by subject title of theemail and 
 didnt check online if it was actually visible.)


 --


 The original message: 



 Hello all, 
  
  after the comments on the confusing nature of the word
 'source' in my original proposal of'electricity:source', I 
 have now changed the name to'electricity:origin' as 
 suggested on the discussionpage. Furthermore, I would like 
 to revive and extend theproposal of the key 'electricity' 
 as this previouslyconflicted with parts of the 
 electricity:source proposaland was not consistent. 
  
  Both proposal pages: 
  
  [1]  
 https://wiki.openstreetmap.org/wiki/Proposed_features/electricity  
  
  [2]  
 https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/electricity:so

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi,

While the original proposal did specify that generators are usually 
diesel, broadening the definition would only lead to a loss of detail, 
but the tagging would still be correct. I'm hesitant to use *offgrid* as 
a building that has, for example, a grid connection with solar panels on 
the roof would then be tagged as *electricity=grid;offgrid* instead of 
*electricity=grid;generator*. The former is illogical.


However, I don't have any experience in developing countries: is it 
easier to verify if something is off-grid compared to if it is connected 
to a generator? And, would it be necessary to differentiate between 
local grids (i.e. 2-3 generators, no substations, transfromers, etc.) 
and national grids? Perhaps then a network tag would be useful, i.e. 
network=national, local, regional similar to the way cycle networks are 
mapped?


A further suggestion was to change the tagging 
to***electricity:grid=yes/no/backup* and/or 
*electricity:generator=yes/no/backup*. This might be less ambiguous for 
tagging amenities or buildings that get electricity from both sources 
and would then be more consistent with tagging such as 
*electricity:generator:origin=diesel* when, e.g. a building has a backup 
diesel generator but is connected to the grid. Unfortunately, it would 
then not be consistent with the use by the Healthsites Mapping Project, 
although this already has the inconsistent *electricity=none* tag which 
should probably be changed directly to *electricity=no.*


Cheers, Lukas


On 03/11/2020 07:14, Dolly Andriatsiferana wrote:

Hi all,

Thanks a lot Lukas for reworking this proposal.

I like Joseph's idea of *electricity=grid/offgrid/yes/no* if you're 
introducing *electricity:origin=**.
I'd suggest dropping the generator value as it brings confusion and 
can be difficult to verify. Originally electricity=generator seemed to 
be intended for diesel devices, but I think we should use something 
like electricity:origin=diesel for it instead.


@Volker, I understand the tag might be less relevant in developed 
countries where it is normal to have electricity. But electricity 
availability is an important information in many developing countries 
(like mine) where most of the population is not connected to the 
electricity grid. It would be useful for health facilities 
and accommodation buildings... - See Healthsites' data model at 
https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project 
 
where the tag is used.


Good job, Lukas!

--
Dolly Andriatsiferana


On Tue, Nov 3, 2020 at 4:11 AM Lukas Richert > wrote:


And, final email, I reworked the proposal page to include tagged
examples and explained some implicit defintions in more detail.

https://wiki.openstreetmap.org/wiki/Proposed_features/electricity


Cheers


On 30/10/2020 13:44, Lukas Richert wrote:


Since a lot of people apparently didnt see the RFC the first
time, I'll go back to RFC status for now. (I thought the threads
were sorted by subject title of the email and didnt check online
if it was actually visible. )


--

The original message:

Hello all,

after the comments on the confusing nature of the word 'source'
in my original proposal of 'electricity:source', I have now
changed the name to 'electricity:origin' as suggested on the
discussion page. Furthermore, I would like to revive and extend
the proposal of the key 'electricity' as this previously
conflicted with parts of the electricity:source proposal and was
not consistent.

Both proposal pages:

[1]
https://wiki.openstreetmap.org/wiki/Proposed_features/electricity


[2]

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/electricity:source




The idea now is to allow for the tagging of buildings or
amenities that have electricity. The rationale is described in
more detail at [1]. Tags such as access, fee, schedule and origin
can then narrow down the availability to the public and the
question of financial or direct origin of the electricity.

This is distinct from the drafted tag power_supply as it is used
to describe the type of sockets used at a specific outlet. The
values for that tag are still currently under discussion.

I would also not tag this as a subset of power=* as this maps the
facilities and features that relate to the generation and
distribution of electrical power and should not be used to map
the consumers of electricity.


I am eager to hear t

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

[Simon Poole]

We don't seem to have a tagging currently for dedicated pickup locations 
in this kind of context, bus stops etc are naturally taggable), if 
considered really useful I don't see why we couldn't introduce a 
amenity=...pickup... tag.


Am 31.10.2020 um 23:50 schrieb Brian M. Sperlongano:
The use of the proposed access tagging on roads to indicate whether or 
not a private hire/rideshare can drive on them I think we can all 
agree is straightforward, but it gets muddy when talking about other 
types of infrastructure that this might apply to.


I would like to better understand how such access tagging would work 
in practice for an example at my local airport.  In that instance, the 
designated Uber pickup/dropoff location is a particular spot within a 
specific parking garage (tagged with amenity=parking + building=yes).  
Do I add private_hire=designated to the building?  Okay, that can 
work.  But then, adding operator=Uber doesn't work -- after all, Uber 
isn't operating the parking garage, they just have permission to make 
pickups at a particular signed location. This tells me that a POI 
that's separate from the parking garage object is needed to indicate 
the precise pickup location within the garage.  Are we saying that's 
amenity=taxi + private_hire=designated?  That doesn't work because a 
taxi stand implies on-demand transportation.  I would just ask that we 
consider the full picture of how designated private hire/rideshare 
tagging should be done at airports and other transportation hubs; 
without that "big picture", merely focusing very narrowly on the 
access attribute feels incomplete.


On Sat, Oct 31, 2020 at 4:03 PM Simon Poole > wrote:


I think there is a bit of a misunderstanding here.

This is not about taxi stands or anything similar, but about
access for Lyfts, Ubers, Grabs employees to streets and
infrastructure that they would not be able to utilize if they were
driving for themselves (including actual ride sharing :-)).
Example pick up and drop off access at airports and similar, this
might include access to taxi dedicated infrastructure too. This is
quite legit and no beef with the companies wanting to be able to
model this to improve routing for their drivers and customers.

Simon

Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:

In the United States at least, there is a very real difference in
meaning between "rideshare" and "taxi" services when it comes
*specifically* to access at airports.  And I believe that is the
intent of this proposal: how do I tag the special area in the
airport where I must go in order to be picked up by XYZ rideshare
company?

At an airport, if you wish to take a taxi, you walk up to a taxi
stand (amenity=taxi), where the taxi cabs line up, and you take
the first taxi cab in line. This is an explicit area where only
taxis queue up.

Alternately, if you wish to take a "ride share", you are using an
app to make an arrangement with a specific vehicle and driver to
be picked up at a specific location.  In this case, airports
often (at this point, probably "usually") have a specified
location where such ride shares are allowed to pick up and/or
drop off passengers.

In some cases, the ride share pickup/drop-off locations have
specific areas that are different for different ride share
providers.  For example, at my local airport, due to
disagreements about how much these companies should pay the
airport for curb access (really), there is one location where you
can pick up a Lyft, and a separate location 100 meters away off
the airport property where you can pick up an Uber!

The point here is that in the US there is a very real distinction
between these two classes of objects, and the information someone
traveling through the airport looking for ground transportation
would want to know is:
1. Is it a ride share (pre-arranged pickup) or taxi stand
(on-demand pickup)
2. Is it limited to only specific ride share companies?
3. Is it pickup only, dropoff only, or both?



On Sat, Oct 31, 2020 at 6:36 AM Simon Poole mailto:si...@poole.ch>> wrote:

For starters I would oppose using the term "rideshare" for
what is a taxi/chauffeur service. It should be noted that
there are actual rideshare organisations and services out
there, but uber, grab, lyft etc. are not among them, they are
simply trying to co-opt a term with positive associations for
their operations.

Further, real rideshare services don't get special access
treatment anywhere I know of, outside of vehicle occupancy
regulations, which isn't surprising as real ride sharing
simply involves sharing costs and car on a trip that the
driver was going to make anyway.

If there are actual legal differences between taxi a

Re: [Tagging] Update - RFC - Special Economic Zones

[Frederik Ramm]

Hi,

my opinion is that stuff that is not visible on the ground and not
meaningfully editable by mappers needs a very strong reason to be mapped
at all.

1. Are SEZ boundaries visible on the ground (signage, physical separation)?

2. If not, do SEZ boundaries usually coincide with existing
administrative boundaries (counties X and Y as well as the city of Z
together form the SEZ)?

3. If not, how would you get your hands on the SEZ boundary?

4. In how far is it useful for mappers to modify the SEZ boundary based
on their knowledge or aerial imagery?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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