Re: [Tagging] Aerialway stations

[Alexey Zakharenkov]

My imagination draws an aerialway that goes over a hill, with or without a mid-station at the top. So, potentially incline is not even a property of a route=aerialway relation, but of an aerialway way segment. 12.08.2020, 18:57, "Kevin Broderick" :In the case of Gaislachkoglbahn, it appears to be two separate tramways (and tagged as such), with adjacent terminals. If the carriers (gondola cabins, tram cars, chairs, etc) don't continue through the station, I think it would be a drive or return terminal, not a mid-station; that particular case would be two terminals (for two different tramways) housed in the same building. Bearing in mind subway mapping practice, this would rather be mapped as one station and two stop_area relationscombined into a transfer (stop_area_group), the two station objects being stop_positions instead. Best regards,Alexey Zakharenkov ___
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

[Alexey Zakharenkov]

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] Mapping Ecomuseum

[Alexey Zakharenkov]

It would be interesting to test if some existing boundary value means the same.https://taginfo.openstreetmap.org/keys/boundary#valuesMaybe "boundary=traditional" tag is mostly used in the same sense?Best regards,Alexey  03.06.2020, 15:05, "Lorenzo Stucchi" :I collected some data about one particular ecomuseum, the “Ecomuseo della resistenza” [1]. The ecomuseum is composed of 8 different municipalities (Aprica, Corteno Golgi [2], Edolo, Monno, Tirano, Villa di Tirano, Sonico e Malonno), so I will create a multipoligon and map it as:type = boundaryboundary = ecomuseumname = Ecomuseo della resistenza But it has also a location inside a building in the municipality of Corteno Golgi, close to this node [3] and map it as a node with the tag:tourism = museummuseum = ecomuseumname = Ecomuseo della resistenza It is ok? Are there other better options? Best,Lorenzo [1]  http://www.cortenogolgi.it/index.php/territorio/storia-e-tradizioni/ecomuseo-della-resistenza-in-mortirolo  this link is just for your knowledge I don’t take the data from here.[2]  https://www.openstreetmap.org/relation/46856 [3]  https://www.openstreetmap.org/node/892479645  Il giorno 31 mag 2020, alle ore 15:38, Martin Koppenhoefer  ha scritto: sent from a phone On 31. May 2020, at 14:45, Lorenzo Stucchi  wrote:But since the ecomuseum is not just a physical limited space but it is a sum of areas of different municipality, I should add the tag on that big area?you could create a multipolygon and make them one distributed museum or map them as distinct museums (and maybe connect them through a tag, maybe “network”). Should I use the tag museum=ecomuseum?it’s up to you, it isn’t an established tagCheers Martin___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging,___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Alexey Zakharenkov]

 04.05.2020, 13:54, "Valor Naram via Tagging" :  I request to replace all occurrence of the non-prefixed versions of the contact keys like Key:phone, Key:email. Key:website to be replaced with the prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website . The current situation harms our database in a way that makes our data less useful. In order to be successful we I agree that phone and contact:phone denote the same thing and should be collapsed into one. But a website doesn't always contain contact information like websites devoted natural/man-made features. IMO, noone should convert 'website' tag for this memorial https://www.openstreetmap.org/node/1416386078 into 'contact:website', so global automatic tag replacement would be an error in this case. Best regards,Alexey___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] city limit sign end

[Alexey Zakharenkov]

 14.04.2020, 13:19, "Martin Koppenhoefer" :  Am Di., 14. Apr. 2020 um 11:18 Uhr schrieb Volker Schmidt :OK, we seem to agree that city-limit-begin sign needs to have angle or cardinal direction values and not forward|backward, because it is often or nearly always, on a joining node of two ways due to the implied speed limit in agglomerations, which is the rule in many European countries,  it doesn't need to have these tags, it is sufficient to place them at the side of the highway and the direction will be implicit. If you make them part of the highway it is desirable to indicate the direction explicitly (and I agree that direction information for the node depending on the way direction of one or more ways at the time of tagging is not desirable). One more question arises. Should we accept "traffic_sign=city_limit + direction=S" as incorrect tag combination? It's equivalent to "traffic_sign=city_limit + city_limit=both + direction=S", but to which city_limit of "both" the direction tag refers: to city_limit=begin or city_limit=end? I've mapped many such signs implicitly supposing the direction attribute applies to "begin".  Best regards,Alexey ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] city limit sign end

[Alexey Zakharenkov]

 Hello. direction=backward is invalid value in this context. The road is often split at city_limit node to reflect the change in highway properties (primarily max_speed), and backward/forward notion is undefined for an endpoint of a segment. It has even less sense for a node aside a road. Please see https://wiki.openstreetmap.org/wiki/Key:direction You are looking for this:https://wiki.openstreetmap.org/wiki/Key:city_limitI.e. put also city_limit=begin/end (optional 'both' value is assumed) tag and direction=N/E/S/W/... tag to indicate how the sign is oriented. Best regards,Alexey   12.04.2020, 13:56, "Volker Schmidt" :Do we have a tagging convention for "city limit end" (example)for those cases where there is no "city limit start" sign in the opposite direction, for example on a one-way street leaving the agglomeration?Would it be correct to use the  traffic_sign=city_limit with direction=backward in this case? ,___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging