Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

Yes, the only thing that needs to be changed is the documentation, in my opinion. We don't need more tags, and it's not even necessary to officially "deprecate" anything. Right now some pages suggest that a bus stop needs to be tagged highway=bus_stop + public_transport=platform + bus=yes at the l

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On 03/08/19 11:03, Daniel Koć wrote: W dniu 03.08.2019 o 02:28, Joseph Eisenberg pisze: Consider also how you would route someone from a amenity=cafe node in a building to a shop=* area in another building across the city, by car. You have to jump from the node to the nearest highway, follow the

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 03.08.2019 o 02:28, Joseph Eisenberg pisze: > Consider also how you would route someone from a amenity=cafe node in > a building to a shop=* area in another building across the city, by > car. You have to jump from the node to the nearest highway, follow the > highways to the other side of t

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On 03/08/19 10:28, Joseph Eisenberg wrote: Many transit routing services use the GTFS standard for transit, which includes bus stops placed at the side of the road, not directly connected to any road line features. The routing engine just has to find the closest point on the transit routing graph

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

Many transit routing services use the GTFS standard for transit, which includes bus stops placed at the side of the road, not directly connected to any road line features. The routing engine just has to find the closest point on the transit routing graph by following highway=* ways. Consider also

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 02.08.2019 o 17:07, Markus pisze: > On Friday, August 2, 2019, Daniel Koć > wrote: > > Without using stop_positions, updating public transport routes in > a (semi-)automated way in a big city (like Warsaw) would be > impossible: > > https://wiki.op

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

I don't see an issue either. The stop positions, if needed, can just be generated from bus stops / platforms. -Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On Friday, August 2, 2019, Daniel Koć wrote: > Without using stop_positions, updating public transport routes in a > (semi-)automated way in a big city (like Warsaw) would be impossible: > > https://wiki.openstreetmap.org/wiki/User:MARC13/easy-routes > Sorry, but i don't understand why this is im

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On Friday, August 2, 2019, Joseph Eisenberg wrote: > See "One Feature, One OSM Element" - separate feature tags should not > be added to the same database object, if at all possible. > > [...] > > I also consider "bus, tram and train stations could all be tagged > alike" as a disadvantage since i

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 02.08.2019 o 15:53, Janko Mihelić pisze: > If we removed stop_positions, that makes creating public transport > relations much easier. I'm not involved in this detailed discussion, so I apologise if I don't get everyting, but better be safe than sorry... Without using stop_positions, upda

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

pet, 2. kol 2019. u 15:34 Markus napisao je: > I still see these solutions: > > 1. To rename public_transport=platform into public_transport=stop (or > public_transport=waiting_area) and to abandon > public_transport=stop_position as well as the PTv1 tags. This would have > the advantage that bus

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

> "only need one element even if there is a platform" See "One Feature, One OSM Element" - separate feature tags should not be added to the same database object, if at all possible. This is particularly a problem with platforms, which can be mapped as nodes, lines or areas. That means a way could

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On Friday, August 2, 2019, yo paseopor wrote: > > The only negative point for public transport v2 scheme was the > no-deprecation of the old scheme to avoid duplicities (surely was done this > to don't uncomfort people) > Salut i transport públic (Health and public_transport) > yopaseopor > IMHO

Re: [Tagging] Rethinking Map Features

Andrew, I now think it is a good idea to switch to taglists for all of the Map Feature page templates. It will make it much easier to keep the pages consistent and to a reasonable length if all of the descriptions are pulled from the wiki pages directly (just as is done for descriptions used by Ta

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Won't work in the US, as values have a size limit of 255 bytes, and there are more *insurance plans* than that in the US. You might be able to pack everything in by treating the value as a bitfield. -- Mark On Fri, 2 Aug 2019 16:52:22 +0900 Joseph Eisenberg wrote: > I’m normally not in favor

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

Yes, one ring (one key=one value) for all kind of public transports because it is easier to say this key and then what kind of transport do you have in. It's better: public_transport=stop_position or public_transport=platform and then bus,tram,train,subway,ferry,helicopter,UFO, future's vehicles.

Re: [Tagging] Feature Proposal - Voting - Tag:insurance:health

I think this tag is useless for Belgium, but that does not mean it is useful in other countries. Let me explain the Belgian situation, so perhaps you can help me here to decide whether it should be used or not. Everybody in Belgium has public health insurance by one of the 4 "ziekenfondsen". Every

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

On Thursday, August 1, 2019, Philip Barnes wrote: > > It is probably true that for a particular train, at a particular time, > will normally use the same platform you cannot assume that all trains > to a particular destination will always use the same platform. > > [...] > > As a regular rail user

Re: [Tagging] Tagging of bullrings

sent from a phone > On 2. Aug 2019, at 08:41, dcapillae wrote: > > Then, tagging of bullrings might be something like this: > > leisure=stadium > + sport=bullfighting > + name=* > > For the pitch (ruedo), > leisure=pitch > + sport=bullfighting > + surface=sand > > For the building, > buildi

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

sent from a phone > On 2. Aug 2019, at 09:40, Simon Poole wrote: > > The problem with this, just as with payment, that it creates a > (practically) unbounded list of keys, that rely on being able to do a > search on keys to be discoverable. yes, but in practical terms you would know the nam

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

On 02/08/19 17:40, Simon Poole wrote: Am 02.08.2019 um 09:26 schrieb Rory McCann: On 02/08/2019 08:42, Warin wrote: It is possibly that some will only accept certain insurance firms and reject others. I am thinking of insurance firms that run some medical facilities. We use subkeys for payment

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

I’m normally not in favor of semi-colon separated values, but this seems like a situation where it is better, since there would be hundreds or thousands of keys otherwise. eg =Medicare;Medicaid;Blue_Cross (USA) =BPJS_Kesehatan;Papua_Sehat (Indonesia) It will still be hard to keep this sort of dat

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Am 02.08.2019 um 09:26 schrieb Rory McCann: > On 02/08/2019 08:42, Warin wrote: >> It is possibly that some will only accept certain insurance firms and >> reject others. I am thinking of insurance firms that run some medical >> facilities. > > We use subkeys for payment types (`payment:american_e

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

On 02/08/19 17:26, Rory McCann wrote: On 02/08/2019 08:42, Warin wrote: It is possibly that some will only accept certain insurance firms and reject others. I am thinking of insurance firms that run some medical facilities. We use subkeys for payment types (`payment:american_express=no`), wou

[Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

On 02/08/2019 08:42, Warin wrote: It is possibly that some will only accept certain insurance firms and reject others. I am thinking of insurance firms that run some medical facilities. We use subkeys for payment types (`payment:american_express=no`), wouldn't this work for insurance companies