Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length
On Sun, Aug 9, 2020 at 9:06 AM 80hnhtv4agou--- via Tagging < tagging@openstreetmap.org> wrote: > in the chicago area we have 3 railway company’s operating the system, and > one had signs left up from the old days > > which in watching the train come into the stations platform did not stop > at the sign based on the number of cars + the > > diesel engines or engines. which could be 5, 6, 7, or 8 cars, we stop at 8 > here. 1 or 2 engines. > > to that end a california editor tagged all 200+ stations with the stop tag > that is 400 + unverified platforms. > You can refer to me by my name if you want :) Part of my rationale for adding the stop_position nodes and stop_area relations to all North American train stations was to prevent many of the errors Alexey brought up. If the ptv2 elements of a station are completely mapped, nobody is tempted to change stop_positions to stations, etc. Other North American rail mappers seem to have appreciated my work doing this, though I'm open to criticism. i would say more but you people do not like that. > Say more, as long as your criticism is constructive. -Clay ___ 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
in the chicago area we have 3 railway company’s operating the system, and one had signs left up from the old days which in watching the train come into the stations platform did not stop at the sign based on the number of cars + the diesel engines or engines. which could be 5, 6, 7, or 8 cars, we stop at 8 here. 1 or 2 engines. to that end a california editor tagged all 200+ stations with the stop tag that is 400 + unverified platforms. i would say more but you people do not like that. with no checks and balances, editorial board etc. they will stay there forever. >Sunday, August 9, 2020 9:40 AM -05:00 from Alexey Zakharenkov < >a-z...@yandex.ru >: > >As a person who have been monitoring and fixing rapid transit networks >(primarity subways) for long I can say that railway stop_positions make more >headache than advantage. Most of stop_positions look like here: >https://www.openstreetmap.org/relation/7966822#map=19/35.70290/139.74568 >i.e. they reside on rails near the station node (adding no information) and >carry bunch of station's tags like wikipedia and name translations (adding >info duplication or triplication). Mappers' eagerness to conform PTv2 in >respect of adding stop_positions here and there results in many errors: >*) stop_positions are created and not added to stop_area relations >*) stop_positions are erroneously converted to stations and vice versa >*) stop_position tags are transferred to another nearby node ignoring its >membership in routes and stop_areas >*) stop_position duplicates corresponding railway station object >(public_transport=stop_position + railway=station) >*) and so on. > >All this makes subway maintenance (in state that allows routing) tenfold >costly. > >BTW, I could not find the definition where is the point of stop of a 150-meter >train. In practice, the position of head or center is used. > >Best regards, >Alexey > 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 > > >08.08.2020, 03:55, "Andy Townsend" < ajt1...@gmail.com >: >>Hello, >> >>This is a question that actually arose out of a "how to tag" argument >>that's come to the attention of the DWG in the USA, but it's actually >>easy to describe in terms of data in the UK that I'm familiar with, so >>I'll do that. >> >>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? >> >>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). >> >>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. >> >>Best Regards, >>Andy >> >>
Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length
On Sun, 9 Aug 2020 at 10:51, Philip Barnes wrote: > One local station has different stop positions for different classes of > train. Basically it has a low platform to which a raised section has been > added so the stop position ensures one door is at this postition. This could be one of the cases where stop_position is legitimately useful. (Or arguably you could instead map two platforms, one for the low-level one and one for the raised one, connected by a ramp or steps.) --Jarek ___ 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
On Sun, 2020-08-09 at 17:38 +0300, Alexey Zakharenkov wrote: > As a person who have been monitoring and fixing rapid transit > networks (primarity subways) for long I can say that railway > stop_positions make more headache than advantage. Most of > stop_positions look like here: > https://www.openstreetmap.org/relation/7966822#map=19/35.70290/139.74568 > i.e. they reside on rails near the station node (adding no > information) and carry bunch of station's tags like wikipedia and > name translations (adding info duplication or triplication). Mappers' > eagerness to conform PTv2 in respect of adding stop_positions here > and there results in many errors: > *) stop_positions are created and not added to stop_area relations > *) stop_positions are erroneously converted to stations and vice > versa > *) stop_position tags are transferred to another nearby node ignoring > its membership in routes and stop_areas > *) stop_position duplicates corresponding railway station object > (public_transport=stop_position + railway=station) > *) and so on. > > All this makes subway maintenance (in state that allows routing) > tenfold costly. > > BTW, I could not find the definition where is the point of stop of a > 150-meter train. In practice, the position of head or center is used. > It is the front, that is where stop position signs are placed on the platform. and are usually based on the number of coaches. Some platforms have a single stop position, usually where the entrance is at that end of the platform. Others have stop positions based on the length of the train which ensures that the rear of the train is close to the entrance. One local station has different stop positions for different classes of train. Basically it has a low platform to which a raised section has been added so the stop position ensures one door is at this postition. Phil (trigpoint) ___ 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
As a person who have been monitoring and fixing rapid transit networks (primarity subways) for long I can say that railway stop_positions make more headache than advantage. Most of stop_positions look like here: https://www.openstreetmap.org/relation/7966822#map=19/35.70290/139.74568i.e. they reside on rails near the station node (adding no information) and carry bunch of station's tags like wikipedia and name translations (adding info duplication or triplication). Mappers' eagerness to conform PTv2 in respect of adding stop_positions here and there results in many errors:*) stop_positions are created and not added to stop_area relations*) stop_positions are erroneously converted to stations and vice versa*) stop_position tags are transferred to another nearby node ignoring its membership in routes and stop_areas*) stop_position duplicates corresponding railway station object (public_transport=stop_position + railway=station)*) and so on. All this makes subway maintenance (in state that allows routing) tenfold costly. BTW, I could not find the definition where is the point of stop of a 150-meter train. In practice, the position of head or center is used. Best regards,Alexey 08.08.2020, 03:55, "Andy Townsend" :Hello,This is a question that actually arose out of a "how to tag" argumentthat's come to the attention of the DWG in the USA, but it's actuallyeasy to describe in terms of data in the UK that I'm familiar with, soI'll do that.https://www.openstreetmap.org/node/12004813 is a"public_transport=stop_position" for a local station and is part ofhttps://www.openstreetmap.org/relation/6396491 among other relations. The problem is that train lengths vary, and there are a number of stoppositions, each of which are actually signed on the platform for thebenefit of the drivers. From memory I think that there's at least a2-car stop, a 4 car stop and 6/8 and 10/12 car stops. The problem isthat the current node doesn't correspond to any of them.As I asked on the changeset that added the one abovehttps://www.openstreetmap.org/changeset/40603523 , how should these bemapped and how should the PTv2 relations be set up for the differentservices that use them, given that different train services will usedifferent stop locations here depending on train length? Should eachstop position be mapped and should there therefore be different copiesof each relation for all the possible train lengths? Should a "pretend"average stop position be added which is actually never correct but willat least look nice to data consumers that use PTv2 data? Given that wedon't know the actual stop position perhaps the railway=station object(in this case https://www.openstreetmap.org/node/7154300845 ) should beused instead?Maybe the public_transport=stop position should be omitted entirely? This last option seems extreme, but one reading ofhttps://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_positionwhere it says "However, marking the stop position adds no informationwhatsoever when it is placed on the road at the point closest tohighway=bus_stop or on the tram tracks closest to railway=tram_stop. Inthat case it can be abandoned. " might actually support that (and thatseems to be the view of one side of the argument in the USA).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 relevantanywhere I normally map things, largely because I don't tend to do thatnear any actual public transport infrastructure, but with a DWG hat on Ihaven't been able to avoid the question, hence me asking here.Best Regards,Andy___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___ 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
Aug 8, 2020, 20:08 by pla16...@gmail.com: > 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. > Yes, this tag would not be needed/useful in all cases. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
