Re: [Tagging] Proposal: Access Aisle
@Warin this could be said of sidewalks too - "they're just footways". Why is this any different? I personally think that my adding this new tag, which can easily be ignored by data consumers, we would add a new tool for consumers who want to, for example, study how accessable parking lots are. Also, even if this isn't all that useful, at least we'll have a clear way to map them to avoid inconsistencies in data. Leif Rasmussen On Thu, Oct 24, 2019, 7:04 PM Warin <61sundow...@gmail.com> wrote: > On 25/10/19 06:12, Clifford Snow wrote: > > I'd like to propose a tagging scheme to tag parking lot access aisle. > > Access aisles are marked areas often used between handicap parking > > spaces but also used to indicate pedestrian access between parking > > spaces. > > > > The proposal can be found on the wiki [1] > > > > [1] https://wiki.openstreetmap.org/wiki/Proposed_features/access_aisle > > > Sorry Clifford, but these are simply footways for pedestrians and can be > mapped as such. they should connect to other footways. > I don't see anything that makes it necessary for a new tag other than > convince of the mapper to imply a wider width and proximity to parking. > The width can be tagged and the proximity to parking would be obvious if > the parking is mapped. > > ___ > 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] Tagging forest parcels
I'd go with landuse=forestry on the property, a tag that was suggested here a while back. This isn't official or anything, but moving towards tagging forest parcels differently from the trees seems important. On Wed, Oct 9, 2019, 3:32 PM Mateusz Konieczny wrote: > > > > 9 Oct 2019, 18:11 by pene...@live.fr: > > Hello, there. > > My question is simple: how do we tag such things? The > boundary=forest_compartment relation is not rendered, and what is rendered > is tagging as landuse=forest both the forest and its parcels, which leads > to rendering it twice, as you can see here: > https://www.openstreetmap.org/relation/6086515 Besides, such forest are > often mistagged for the renderer: as the contributor wants the parcel > number rendered, he puts it in the name tag, not in the ref tag, to which I > assume it should belong. > > So, is there an "official"/recommended/widespread way to tag forest > parcels, their number and them belonging to a forest? > > boundary=forest_compartment? > > Is there anything wrong with this tagging > scheme (except that mapping this > kind of info seems a bit dubious to me). > > All problems that you mention are > about tagging for renderer. > > > ___ > 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] Tourist bus stop
My main concern is that some bus stops could be both for tourist buses and for public buses. Using ptv2 instead, with public_transport=platform + coach=designated or tourist_bus=designated would be easier. Leif Rasmussen On Tue, Sep 10, 2019, 8:35 PM Joseph Eisenberg wrote: > Thank you for making a proposal, Francesco. > > “A tourist bus stop is a stop reserved to tourist buses.” > > The main issue is describing the term “tourist bus” clearly. > > The related wiki page Key:tourist_bus says: > > “The key tourist_bus=* is used to tag legal access restrictions on roads > for buses that are not acting as public transport vehicle (for the latter > see bus <https://wiki.openstreetmap.org/wiki/Key:bus>=*).” > > “This tag originated from a literal translation of the Italian word Autobus > turistici[1] > <https://wiki.openstreetmap.org/wiki/Key:tourist_bus#cite_note-1>, which > can be understood to be synonymous to a coach.” > > https://wiki.openstreetmap.org/wiki/Key:tourist_bus > > So is “tourist_bus=yes” identical to “coach=yes”? > > Does this include “minibuses” and large “vans” used as vehicles for hire? > > I assume it excludes intercity buses or buses to national parks, if they > run on a regular schedule and sell tickets to the general public? > > https://wiki.openstreetmap.org/wiki/Key:coach > > - Joseph > > On Wed, Sep 11, 2019 at 3:09 AM Francesco Ansanelli > wrote: > >> Dear list, >> >> please find the proposal for the tag in subject: >> >> >> <https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:highway%3Dtourist_bus_stop> >> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:highway%3Dtourist_bus_stop >> >> the idea was born during a discussion on Talk-it and it is my first >> tagging attempt, be kind... :) >> >> Cheers >> Francesco >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://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] Turn lanes separated by road markings
I see two good options: 1) Split the two lanes into two ways where they first split apart (but aren't yet physically divided). This doesn't follow the "physical divider" rule, but since the road markings are acting as a physical divider, and they are much more than just a line, an exception to that rule seems fine. 2) Just pretend that the road markings are like any other line and tag change:lanes instead of two separate ways. Then, you could use a new tag like "width:dividers:backward=3" to mark that the lane divider is 3 meters wide. I would probably just go with the first one for now, since it's a bit difficult to physically cross that lane divider with a vehicle and the lane splits off anyway. ... I've been considering starting a proposal for mapping the widths of lane dividers recently, since there are many cases where they aren't just lines. Perhaps some tag like "width:dividers=0|0|4" or similar could work, where each number represents a divider between two lanes (that example would be for a one way road with 4 lanes, the right of which is separated by a 4 meter lane divider). What do people think of a new tag like this? I personally think something other than "|" should be used for dividers, so am looking for a better syntax. If people like the idea, I would be happy to start a new proposal. Leif Rasmussen On Fri, Sep 6, 2019 at 3:15 PM Markus wrote: > Hello everyone > > I'm unsure how to map the following situation: > > There are two lanes approaching a roundabout, both with different > destinations. The lanes are divided by a solid line (and later a panted > triangle with chevrons) for about 100 m before they are separated > physically: > > https://www.openstreetmap.org/way/430073056 > > Do we have a relation for storing the information that the left lane > continues on [way 394112487](https://www.openstreetmap.org/way/394112487) > and the right lane on [way 290130794]( > https://www.openstreetmap.org/way/290130794)? This information is > important in order that routers don't announce too late (i.e. when the > lanes can't be changed anymore) which lane one has to take. > > Or is turn:lanes + change:lanes enough? (And what if there were no turn > lane markings?) > > Thanks in advance for your help > > Regards > > Markus > ___ > 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 - footway=indoor
How is this different from highway=corridor? On Thu, Sep 5, 2019, 12:42 PM Jeremiah Rose wrote: > Here's a proposal for marking indoor routes within a building mapped with > Simple Indoor Tagging. > > footway=indoor: indoor pedestrian route > https://wiki.openstreetmap.org/wiki/Proposed_features/footway%3Dindoor > > Jeremiah Rose > > ___ > 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] landcover dune or land form dune
+1 Dunes can also have grasslands growing on the, which is a landcover, so dunes being landcover would not make much sense. Leif Rasmussen On Sun, Aug 25, 2019, 7:12 PM Warin <61sundow...@gmail.com> wrote: > Hi > > > There is a wiki entry for 'landcover=dune'. > > > https://wiki.openstreetmap.org/wiki/Proposed_features/landcover#Landcover_tags_and_related_tags > > > It has 0 uses in the data base. > > > There is an existing tag 'natural=dune'. > > > https://wiki.openstreetmap.org/wiki/Tag:natural%3Ddune > > > > To me dune is a land form. > > From the Oxford Dictionary "A mound or ridge of sand or other loose > sediment formed by the wind, especially on the sea coast or in a desert." > > > So it is a mound or ridge ...ie a land form like a hill or a valley. > > > ___ > 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] Is crop=yes tag completely and utterly useless?
But isn't that the definition of farmland in OSM? I would map meadows, farmyards, and orchards with their respective tags, not with landuse=farmland. Leif R On Sat, Aug 17, 2019 at 7:18 PM Joseph Eisenberg wrote: > Produce=crop would be worse, because “crop” is not a type of produce, and > produce= is only very rarely used for crop land ( crop= is the established > key for types of crops like rice, sugarcane, wheat, etc) > > As I mentioned on the Talk:Key:crop page, I suspect that this tag crop=yes > is sometimes used to say “this area of farmland is used as crop land”, that > is, to grow row crops like grains/sugarcane/other annuals. So at least we > know it probably isn’t a meadow or a farmyard or an orchard? > > Joseph > > On Sun, Aug 18, 2019 at 7:44 AM Warin <61sundow...@gmail.com> wrote: > >> >> Would produce=crop be better? >> As produce could be fish, cattle, sheep, wool, or crops. >> produce=crop would say that only crops are produced here. >> >> >> >> On 18/08/19 01:27, Martin Koppenhoefer wrote: >> > >> > sent from a phone >> > >> >> On 17. Aug 2019, at 17:09, Mateusz Konieczny >> wrote: >> >> >> >> 9326 of 9657 crop=yes is on landuse=farmland - it seems to me that it >> is >> >> not adding any information whatsoever. >> > >> > certainly removing them would be even less useful? You could read it as >> a way of stating that something is purposefully grown there. Someone else >> might refine it later ... >> > >> > Cheers Martin >> > ___ >> > Tagging mailing list >> > Tagging@openstreetmap.org >> > https://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 > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Where should
*Was Re: [Tagging] Definition of a Beach* *> that then clashes with OSM Coastline, which is taken as the High Tide mark* I was under the impression that the definition of the coastline was the average between high and low, not the high tide mark, based on what I had read on some wiki page. I think that there must be conflicting guidelines on the wiki since I've noticed two conflicting mapping styles. What style do people think is better? Is there an advantage to one over the other? Also, is there a good way to map the coastline as an area representing the low tide to high tide difference? Adding some tag like tidal=yes to areas representing that shape is the best I've found, but tidal=yes can also be used to mark that some water or marsh is tidal. Thanks, Leif Rasmussen On Thu, Aug 15, 2019, 8:02 AM Graeme Fitzpatrick wrote: > > On Thu, 15 Aug 2019 at 14:50, Warin <61sundow...@gmail.com> wrote: > >> On 15/08/19 14:16, Mateusz Konieczny wrote: >> >> Main problem with such definition is that strip of concrete/asphalt along >> shore >> is not a beach. >> >> I thought about dunes when I claimed that "beach is not >> always unvegetated" but now I see that dunes are not considered as part >> of the beach. >> >> I copied definition from Wikipedia as it seemed far better as it managed >> to >> exclude stuff like >> https://commons.wikimedia.org/wiki/File:Sea_defences_(21467789266).jpg >> >> >> https://commons.wikimedia.org/wiki/File:Mole_in_Funchal,_Ponta_do_Garajau,_statue_of_Cristo_Rei_and_Desertas_Islands._Madeira,_Portugal.jpg >> >> >> https://commons.wikimedia.org/wiki/File:Concrete_defences_by_the_Saxon_Shore_way_-_geograph.org.uk_-_1240179.jpg >> >> Maybe copying previous definition from natural=beach would be preferable. >> >> >> Don't know .. hence my question here .. any 'beach' 'experts'? >> > > Lived beside them all my life so I'll have a go! > > I'll agree with Mateusz that concrete & boulders aren't a beach - a couple > of those examples I'd probably call man_made=groyne + natural=rock (& yes, > that's because it then renders as rock!), however you can have (isolated) > boulders on a beach. > > What is a beach though is a bit tricky, especially for OSM. > > It would usually be "the area above the Low Tide mark" but that then > clashes with OSM Coastline, which is taken as the High Tide mark, so that > would then have to mean that the beach is > > "The area between the High Tide mark & any adjoining vegetation / > structures / landforms". It's usually largely unvegetated (but may have > isolated trees, clumps of grass etc), & is made up of natural materials > such as sand, pebbles, shells etc" > > How's that sound? > > Thanks > > Graeme > ___ > 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] Bicycle kitchens, community centres that offer bicycle repairs etc
Cafés^, not cages. Android swiping strikes again. On Wed, Aug 7, 2019, 10:19 PM Leif Rasmussen <354...@gmail.com> wrote: > I've seen cages that are also bike shops, so whatever tagging solution we > up with should work with any type of shop. > Leif Rasmussen > > On Wed, Aug 7, 2019, 9:38 PM Morten Lange via Tagging < > tagging@openstreetmap.org> wrote: > >> Hi, >> >> I wonder how I should tag bicycle shops that are not shops in the >> traditional "buy our products" sense. >> >> A community-centre that is also offers bicycle repairs / is a bicycle >> repair shop. >> Or a bicycle "shop" that primarily focuses on refurbishing disused bikes. >> Or a community-centre or similar that provides job training for various >> groups, and such training happens through running a bicycle repair service >> for the public. >> >> >> I have found a few such bicycle repair and maintenance "shops" on OSM. >> These are the searches I have used in overpass-turbo.eu: >> >> (shop=bicycle or service:bicycle:repair=yes) and >> ownership=private_nonprofit >> or >> community_centre=bicycle_maintenance >> or >> service:bicycle:repair=yes and amenity=community_centre >> >> >> Many of those that I described, to my eperience do not offer >> Do-it-yourself (more on DIY below). >> They still are something else than your "ordinary" bikeshop, and I think >> that is significant to reflect in tagging. >> So I wonder how best to tag those. My experience is that most of them >> are non-profit. >> >> >> My preliminary conclusion is to use this on the nodes I have mapped in >> Oslo and elsewhere in Norway: >> shop=bicycle >> service:bicycle:repair=yes >> ownership=private_nonprofit (or ownership=public_nonprofit) >> >> >> >> Some additinional thoughts : >> >> A. >> If the place is a Do-it-yourself shop it should be tagged as such. >> Searching for this tag and value I see the pair has been used quite a lot. >> For example for bicycle kitchens. >> service:bicycle:dyi=yes. >> >> B. >> Tagging primarily as a community centre? >> >> Some might suggest to use amenity=community_centre combined with >> community_centre=bicycle_maintenance >> >> But then the community centre feature will overshadow the bikeshop >> aspect. (And in current renderings the place would not pop up as a place >> where you can fix your bicycle/tricycle) >> I would like to have it the other way around, that is to emphasise the >> service offered to the public, rather than type of establishment. >> >> Is it OK to use >>community_centre=bicycle_maintenance >> together with >> shop=bicycle ? >> >> >> >> >> >> Any other comments? >> Could a single "freshly invented" value do the trick like >> service:bicycle:repair=work_training >> The downside is that if searching for the value =yes, those >> nodes/ways/relations are not found. >> >> >> Regards / Kveðja / Hilsen >> Morten Lange >> >> >> P.S >> >> Bicycle kitchens and bicycle librarier are somewhat different animals. >> >> Searching the web for bicycle kitchen, bicycle library etc turns up quite >> a few references. >> >> But I could not find them on OSM. >> That is until I specifically searched in overpass-turbo for >> >> shop=bicycle and service:bicycle:diy=yes >> >> Rome, Paris and Berlin are virtually peppered. >> >> >> And for the case of the bicycle library . >> Would this be a possibe way to tag them >> service:bicycle:rental=library >> ? >> >> -- >> Morten Lange, Oslo >> >> ___ >> 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] Bicycle kitchens, community centres that offer bicycle repairs etc
I've seen cages that are also bike shops, so whatever tagging solution we up with should work with any type of shop. Leif Rasmussen On Wed, Aug 7, 2019, 9:38 PM Morten Lange via Tagging < tagging@openstreetmap.org> wrote: > Hi, > > I wonder how I should tag bicycle shops that are not shops in the > traditional "buy our products" sense. > > A community-centre that is also offers bicycle repairs / is a bicycle > repair shop. > Or a bicycle "shop" that primarily focuses on refurbishing disused bikes. > Or a community-centre or similar that provides job training for various > groups, and such training happens through running a bicycle repair service > for the public. > > > I have found a few such bicycle repair and maintenance "shops" on OSM. > These are the searches I have used in overpass-turbo.eu: > > (shop=bicycle or service:bicycle:repair=yes) and > ownership=private_nonprofit > or > community_centre=bicycle_maintenance > or > service:bicycle:repair=yes and amenity=community_centre > > > Many of those that I described, to my eperience do not offer > Do-it-yourself (more on DIY below). > They still are something else than your "ordinary" bikeshop, and I think > that is significant to reflect in tagging. > So I wonder how best to tag those. My experience is that most of them are > non-profit. > > > My preliminary conclusion is to use this on the nodes I have mapped in > Oslo and elsewhere in Norway: > shop=bicycle > service:bicycle:repair=yes > ownership=private_nonprofit (or ownership=public_nonprofit) > > > > Some additinional thoughts : > > A. > If the place is a Do-it-yourself shop it should be tagged as such. > Searching for this tag and value I see the pair has been used quite a lot. > For example for bicycle kitchens. > service:bicycle:dyi=yes. > > B. > Tagging primarily as a community centre? > > Some might suggest to use amenity=community_centre combined with > community_centre=bicycle_maintenance > > But then the community centre feature will overshadow the bikeshop aspect. > (And in current renderings the place would not pop up as a place where you > can fix your bicycle/tricycle) > I would like to have it the other way around, that is to emphasise the > service offered to the public, rather than type of establishment. > > Is it OK to use >community_centre=bicycle_maintenance > together with > shop=bicycle ? > > > > > > Any other comments? > Could a single "freshly invented" value do the trick like > service:bicycle:repair=work_training > The downside is that if searching for the value =yes, those > nodes/ways/relations are not found. > > > Regards / Kveðja / Hilsen > Morten Lange > > > P.S > > Bicycle kitchens and bicycle librarier are somewhat different animals. > > Searching the web for bicycle kitchen, bicycle library etc turns up quite > a few references. > > But I could not find them on OSM. > That is until I specifically searched in overpass-turbo for > > shop=bicycle and service:bicycle:diy=yes > > Rome, Paris and Berlin are virtually peppered. > > > And for the case of the bicycle library . > Would this be a possibe way to tag them > service:bicycle:rental=library > ? > > -- > Morten Lange, Oslo > > ___ > 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] Was public_transport=platform intended to always be combined with highway=bus_stop?
> If you want a waiting area tag, name it like this. I *would* agree with this, but public_transport=platform is already quite established. Changing tags is worse than having badly named tags. Leif Rasmussen On Sun, Aug 4, 2019, 4:40 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 4. Aug 2019, at 15:03, Markus wrote: > > > > Unfortunately it doesn't mean a real platform, but a waiting area (see > > also Polyglot's message). If it would have meant a real platform, > > there were no PTv2 tag for the waiting area of a stop without > > platform, which is the normal situation for bus stops at many places. > > > it is just an excuse to insist on using pt=platform for things that aren’t > platforms and justify it with saying it means waiting area. > I don’t think we should define pt=platform for something different than a > public transport platform, it would be asking for trouble. > If you want a waiting area tag, name it like this. > > Cheers Martin > ___ > 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] 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
[Tagging] Connectivity relations - approved
Hi everyone, A few weeks ago, the new relation type "connectivity' was approved. I've updated the proposal, created a new page https://wiki.osm.org/Relation:connectivity , and updated relavent wiki pages to mention connectivity relations. Connectivity relations are a new relation type of relation that can be used to specify the lane connectivity between two ways when it's not already specified by placement=* or lane tags. They will allow mappers to clarify the majority of situations where lane connectivity couldn't previously be specified, and will allow for a whole new level of lane detail to be added to osm. They may also make change:lanes more useful in places where it's added, since data consumers will be able to tell how the lane dividers connect between ways. Thanks to everyone that voted or helped improve the proposal! Leif Rasmussen *** Sorry about the late email, but I've been traveling through Europe and have had much less time to work on the proposal than I usually would. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clashing access tags
I'd map the way as highway=cycleway + proposed:highway=*, since until the proposed highway is finished, it's effectivity a cycleway. Adding foot=yes could also be good if relevant. On Sun, Jul 14, 2019, 3:38 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 14. Jul 2019, at 14:07, Richard Fairhurst > wrote: > > > > 1. Is there any precedent for how to parse these contradictory tags? > > > not sure I follow your analysis that these are contradictory. One could > read bicycle=designated as a property (refines a feature), so in this case > highway=proposed defines a planned highway and bicycle=designated states it > will be explicitly for bicycles. No contradiction. > > > Cheers Martin > ___ > 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] New entry to the wiki pages leisure soccer golf
Yes, that would be better On Sun, Jul 14, 2019, 10:35 AM Warin <61sundow...@gmail.com> wrote: > Hi, > > Some 30 uses of the tag leisure=soccer_golf and 2 wiki pages on it - > English and Polish. > > https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsoccer_golf > > > Should this not be tagged leisure=pitch with sport=soccer_golf ??? > > Or are any sports related to golf to be tagged leisure=* only??? > > > ___ > 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] [OSM-talk] Ways divided by paint?
I personally like tagging the highway as one way with change:lanes until the line starts to split into two. This gives data consumers more power over what they show, and allows for a more accurate representation of reality. - Leif Rasmussen On Thu, Jul 4, 2019, 3:18 PM Snusmumriken wrote: > On Thu, 2019-07-04 at 10:11 +, Philip Barnes wrote: > > On Thursday, 4 July 2019, Snusmumriken wrote: > > > On Wed, 2019-07-03 at 14:03 -0600, Jack Armstrong Dancer--- via > > > talk > > > wrote: > > > > I've always had the impression we should not create separate > > > > traffic > > > > lanes unless "traffic flows are physically separated by a barrier > > > > (e.g., grass, concrete, steel), which prevents movements between > > > > said > > > > flows." > > > > > > A painted line that has the legal status of "do not cross" is a > > > perfectly fine reason to have a separate way. > > > > > I would strongly disagree with this statement, as others have said > > this is a place for lane mapping. > > > > As a map user I do not see a separate way, it results in confusing > > navigation instructions, turn instead of take the first exit from the > > roundabout. > > > > There are also times when lines are not visible due to snow, > > whiteover with frost or just salt turning the road white. > > Where I'm from that would be a poor excuse if caught crossing a solid > line. And wouldn't it be great if your favorite navigation software > could tell you how traffic can legally flow? Even if the weather > condition were such that you couldn't observe the solid line. > > Also I don't get how roundabouts are relevant for this discussion. > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Connectivity relations
Hi everyone, The connectivity relations proposal is now in the voting stage! Please feel free to vote on the proposal or provide any comments on the talk page. https://wiki.osm.org/Proposed_features/Connectivity Short summary of this proposal: This proposal adds a new type of from-via-to relation that connects the lanes of two highways together at a certain point. The relation can specify where drivers in each "from" lane will end up in in the "to" way after the "via" point. These relations will ... * Allow for much more accurate lane modelling in OpenStreetMap * Clear up any ambiguity that is left over after turn:lanes and similar has been added to every road. This relations will not ... * Replace turn:lanes * Provide information about what "turn" the connection is * Become broken like the tag "transit". Thanks so much to everyone who helped make the proposal as clear and comprehensive as possible! Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 117, Issue 36
> > Personally I would prefer a more inclusive definition which requires for > lanes to be recognizable, which could be either through lane markings or > through traffic observation (if the vehicles drive in two lanes it is a > 2-lane road also in absence of road markings). > > Cheers, Martin > I agree with this. "Only marked lanes" has been annoying for me several times. First, in my old United States neighborhood, many roads are unmarked, with about 10% having a double stripe down the middle. Those 10% are really no different from the rest, and often times the paint won't be reapplied when new asphalt is laid down. So really, there isn't any difference between these roads except for how I'm supposed to tag them. Second, when creating the connectivity relations proposal, people asked about what lane numbering system unmarked roads should be given. I thought that they should be assumed to have 1 lane in each direction, and should accordingly just contain the lane #1. The main thing that is hard here is deciding at which width 1 lane becomes 2. In the United States, unmarked roads are usually wide enough for 2 cars to easily pass each other, so are practically speaking 2 lanes. Here in Europe, many rural roads are only wide enough for 1 car, meaning that a car must pull off the road in order to let another one pass. I really like the "observable lanes" definition, but think that switching to this one would create the need for some extra tag to indicate that the lanes are not actually marked to help data consumers that care about that kind of detail. Best, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Connectivity
https://www.openstreetmap.org/#map=19/38.94280/-77.25527marc marc wrote: > in the rational, you said "there are many cases where turn:lanes=* > can't provide that information." > could you add a case where turn:lanes are included that more > clearly shows what the connectivity=* adds ? > ideally 2 examples that would have the same turn:lanes value for the > "from" way and the same number of lanes on the "to" way but not the > same connectivity=* value That was the original rationale, but as the proposal improved, I saw a much greater potential in these relations, which I have now documented in the rationale. There are still some cases where turn:lanes can't properly mark the connectivity of the intersection without the mapper going out of their way to make the intersection compatible. Most intersections are technically possible to map, but connectivity relations will make it cleaner and simpler to do so. * The main usage of this proposed relation will be to state which lanes connect to which when the number of lanes on a motorway changes. * The second most important usage of connectivity relations will be to document actual lane connectivity where lane markings don't actually represent reality - for example, a left turn lane might be able to turn left on to a residential road, but also continue straight to another left turn lane which turns left that the next intersection 100 m away. * The third usage is for representing a few complex intersections where lane mapping gets complicated. It is almost always possible to mark *node* intersections with turn:lanes, but when things get confusing (like https://www.osm.org/#map=19/38.94280/-77.25527), it's not always obvious what counts as what. There are likely many other places where it will be nice to have this tool for clarifying lane connectivity that I haven't heard of, since I'm always discovering more. So, to sum up the rationale, this proposal adds a whole new level of detail to osm lane data that will allow for new usage possibilities including better lane centered navigation. Thanks for the comments! Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Connectivity
Hi everyone, I emailed this list a month ago about my proposal (Connectivity relations), and received a lot of feedback. I have also contacted many other sources for feedback. I used all of the feedback to make the proposal much more comprehensive and able to store much richer data about lanes in OpenStreetMap. Some new features: * The possibility of stating whether connectivity is "default", aka "lane you will end up in if you don't change lanes, take an exit, turn, or leave an ending lane" * Conditional connectivity * Much more clear examples on the page * Support in iD for not breaking connectivity relations and other from-via-to relations that don't have type=restriction. https://wiki.openstreetmap.org/wiki/Proposed_features/Connectivity Please provide any final feedback for this proposal either here on this mailing list or on the talk page for the proposal. I will likely open up voting for this proposal in a week or so if I don't see any issues with the proposal. Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Connectivity (Mateusz Konieczny)
Thanks for the feedback Mateusz! I will add a section on way splitting, and make the two-way road examples more obviously not oneways. As for splitting, the relations could be handled in the exact same way as turn restrictions are currently handled. Any editor that knows how to not break turn restrictions will need to add type=connectivity as another type of relation that needs the same care. No new special code will need to be written. Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature proposal - RFC - Connectivity
Hi everyone! I have recently been mapping a lot of turn:lanes information on highways in my area, but ran into the issue that turn:lanes fails to store all of the necessary information in many junctions. Multi-lane roundabouts, single point urban interchanges, 5 way intersections with divided roads, and other cases are all too complex for turn:lanes to handle. Because of this, I have created a proposal for a simple type of from-via-to relation that would provide information about how lanes in the "from" way connect to those in the "to" way at any point where it isn't clear. These relations are very similar to turn restrictions, and like turn restrictions, wont be needed in most intersections. The relation would also be able to store the same information as could have been possible with transit:lanes, just without the many maintenance issues that came that system. https://wiki.osm.org/wiki/Proposed_features/Connectivity All feedback on how to potentially improve the proposal would be highly appreciated! Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC - Connectivity
Hi everyone! I have recently been mapping a lot of turn:lanes information on highways in my area, but ran into the issue that turn:lanes fails to store all of the necessary information in many junctions. Multi-lane roundabouts, single point urban interchanges, 5 way intersections with divided roads, and other cases are all too complex for turn:lanes to handle. Because of this, I have created a proposal for a simple type of from-via-to relation that would provide information about how lanes in the "from" way connect to those in the "to" way at any point where it isn't clear. These relations are very similar to turn restrictions, and like turn restrictions, wont be needed in most intersections. The relation would also be able to store the same information as could have been possible with transit:lanes, just without the many maintenance issues that came that system. https://wiki.osm.org/wiki/Proposed_features/Connectivity All feedback on how to potentially improve the proposal would be highly appreciated! Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] New Tag "Departures" voting results.
Hi everyone, The proposal for the tag "departures" has finished, and has a final vote of * 12 "Approve" * 22 "Reject" * 3 Comments without vote * 1 "Degree of incredulity" at the proposal . . . meaning that the proposal was rejected. Overall, the main idea voters expressed was that connecting with GTFS and others would be advantageous over adding the data to OpenStreetMap in the form of tags, as it would allow data consumers to just download the data from the original source, making storing the timetables directly in OpenStreetMap unnecessary. People living in regions without public GTFS feeds expressed concerns about cases where OpenStreetMap would be the only public source of timetable data, however. Many people agreed on the contrary that the data would still make sense on ferry routes, which are more essential to car navigation, and usually have simpler schedules. It seems like the best way forward now is for a proposal allowing OpenStreetMap data to be tightly integrated with outside sources (such as GTFS) to be created by someone. This would avoid the issues of maintainability in OpenStreetMap. Also, if anyone is interested, I can create a new proposal for adding departures times to ferry routes only, and not to bus / train routes. This would be easier to maintain, and as far as I am aware, no GTFS exists for ferries. Thank you to everyone who participated in the voting and discussion of this proposal! Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - new tag departures=*
Voting is open for the tag departures, which states the list of departure times in a public transport route. https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
> I didn't follow the discussion but this proposal is at least > helpful. > Why not map xx:xx in the same route relation? Role > examples: > stop@00:20, stop_exit_only@03:45, > stop_entry_only@00:25-00:31, and for > bus stops where the timetable is approximated (like in > Brazil) use "~" > for the usual times, examples: stop@~00:27-00:30, > stop_exit_only@~00:46 That was actually what I had originally proposed. My role format was stop:+00:32, though, which is only slightly different. People in this list noted that it would corrupt existing relation roles, so I redesigned the proposal to have no effect on existing data. I have since been trying to come up with other ways to encode this data, including separate relations, tags on the bus stops, and additional tags in the bus route relation. I have left those out of the current proposal, though, to keep it simple. Perhaps this is something that could be proposed later. Here is a link to the current proposal, which everyone with a wiki account can now vote on: https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures Thanks for your enthusiasm, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
Hi, Thanks for bringing up this discussion again! I have now opened up the departures tag proposal for voting, so please feel free to vote on the proposal if you would like. I had been tweaking it for a while, and it seems ready now. Thanks again, Leif Rasmussen On Tue, Feb 12, 2019, 4:54 PM Tijmen Stam wrote: > Jo, Leif, > > My sincerest apologies. > > I couldn't find a request to vote on this list's archives. Must have > overlooked it. > > Tijmen > > On 11-02-19 22:51, Jo wrote: > > The proposal was voted upon. > > > > On Mon, Feb 11, 2019 at 9:54 PM Tijmen Stam > <mailto:mailingli...@iivq.net>> wrote: > > > > On 31-10-18 00:54, Leif Rasmussen wrote: > > > Hello everyone! > > > I recently wrote up a proposal page for public transport schedule > > data. > > > This information would allow OpenStreetMap to store information > > about > > > when or how often certain buses or trains arrive at a platform. > > > > > > > > > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules > > > > > > Please feel free to look over the page and give feedback. I am > very > > > open to changing the proposal, so let me know if you have any > > ideas for > > > improvements to it. > > > Thanks, > > > Leif Rasmussen > > > > On January 3rd this year, Leif added the "Interval" and "duration" > tags > > to the wiki for bus route: > > > https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dbus=revision=1767271=1684316 > > > > I have sideways followed this discussion, but I had the idea there > was > > widespread opposition for having any timetable info added to OSM. > > > > I don't think we should have this on the wiki without proper proposal > > voting - or did I miss something? > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> > > https://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
[Tagging] Proposal Request for Comments: New Key "Departures"
The new key "interval" for adding the departure times interval of a public transport route was recently approved after two weeks of voting. I have created a new wiki page to document this key: https://wiki.openstreetmap.org/wiki/Key:interval Full schedule information, however, is still impossible. I originally proposed using "timetable relations" to add full schedule information to routes. I have since realized that this would be a disaster just waiting to happen. I have now simplified the proposal to be easier to add and maintain, while still keeping most of the same information in the database. The key "departures" is my solution to keeping timetables simple and easy to maintain. https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures Please provide feedback to help make this proposal work for everyone. I know that for many bus routes, it would be impossibly difficult to add (and maintain) full schedule information. Those routes should therefore only include the tag "interval". Others, however, including many ferry routes, would be very easy to add schedule information to. Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Voting for Public Transport Schedules/Interval
Hi everyone, I am now opening up voting for the tag "interval". Once approved, it will be used on bus routes, ferry routes, railway routes, and others to state the frequency at which buses, trains, or ferries arrive. This is a very simple addition that will not cause any data to be broken. The most this could really do is add an extra tag added on to existing relations. I will open up the other two proposals, Timetable relations and ferry routes, for voting after this voting is complete. Anyway, please vote on the proposal and share your thoughts! My goal is to create a system that is simple, yet useful, and serves everyone's needs. https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules/Interval Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables
Integrating GTFS seems like a much better idea than adding actual schedules to OpenStreetMap. I had not considered this previously because I did not understand how GTFS is used worldwide. Perhaps it would be possible to start something like a new gtfs.openstreetmap.org (which would be similar to transit.land and transitfeeds.com, but with a focus of OpenStreetMap integration) for hosting GTFS feeds that could be integrated into OSM. That would allow for much easier integration and maintenance. Copying what Google has done successfully seems like a better option than creating a big, out of date mess. I think that creating a new GTFS server would be better than using transit land or transitfeeds.com, because OSM would have full control over what happened to the servers and which licencing was used. Does anyone with experience in GTFS know how an integration like that could work? Also, is what I am imagining even possible? Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables
Polyglot: I think that having a timetable relation for each stop is less complicated than having one per route. There are several advantages to this: 1) People can easily add a single relation at a time, rather than having to do the entire line at one time. This could make it much easier to, for example, have a StreetComplete quest asking "What are the arrival times of bus X at this bus stop?" iD could also have a field at bus stops with "arrivals for each parent bus route" that would allow people to seamlessly create timetable relations. It also makes more features possible in the future, such as additional tags to each timetable. 2) The system is easier for newbies to learn to use. The disadvantage is that there are now a ton of relations per bus / train / subway route. Creating these could made easier by a new JOSM plugin. Also, if someone wanted to delete all timetable relations that are part of a route, they could simply use this overpass query to download the data into JOSM and then delete all of the timetable relations: https://overpass-turbo.eu/s/Dlf If people really prefer a single timetable relation for each route, then I will go with that. Julien: Why not have a "delay"="" tag instead of separate arrivals/departures tags? Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
The timetable proposal would not affect existing OSM data. It would simply add new relations having existing features as members of those relations. If timetables are out of date for a certain route, a contributor could simply delete all of the timetable relations that are parents of that route. Rather than maintainability being the issue, it would be actually re-adding the deleted data that would be hard. This type of data is more useful on train routes, which are better maintained than bus routes. Bus routes with complex or often changing schedules should just be given the tags "interval" and "interval:conditional" and not full schedule data. My main point is that no harm can be done by this proposal. If people don't like timetables, they can simply ignore them. If they are not being maintained, the relations can easily be deleted without affecting the routes in place. No harm done. In many cases, however, bus route and train route schedules are very simply, and it would be a shame to not be able to add schedule data to those routes. Before voting, I will split up the proposal into three different proposals. * The "interval" tag. * Full ferry route timetables. * Timetable relations. This way, people can choose to approve some of the new features and vote against others. What do people think of the ferry route schedules proposal? I have only heard feedback on bus routes so far, and I am not sure what people think of the ferry route system that I have come up with. It would simply just be a couple of new tags added to ferry route ways. Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
Graeme Fitzpatrick: I have changed the proposal, and the level of detail that you describe can now be added very easily. At the bus stop, the proposal now states to create one new relation for each bus route stopping at that stop and include both the stop and the route inside each of those new relations. Then, add the tag departures=* to mark the timetable. See this example: https://www.osm.org/relation/8873463 Thanks, Leif ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
Thanks for the feedback on this proposal! Maintainability and corruption of existing features seem to be the two biggest concerns, both of which I have reduced in the new version of the proposal. I really like the idea that Polyglot expressed on the talk page of the proposal of using a completely separate relation to represent a single timetable. It is a completely different system that is much more elegant, versatile, practical, and simple. By using a relation similar in design to turn restrictions, the complexity of this proposal has been reduced significantly. The new version of the proposal will not affect existing public transport routes in any way or form. They will remain unchanged and uncorrupted, similarly to how turn restrictions do not affect highways in any noticeable way. Data consumers will not have to worry about any changes to public transport details. https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules Please let me know what you all think about the improved proposal. Maintainability will still be difficult, but much easier than before. It may also be possible for these types of relations to be added by, and checked for currency by, StreetComplete without much trouble. Example of a timetable relation: https://www.openstreetmap.org/relation/8873463 Thank you, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Public Transport Timetables Proposal RFC
Hello everyone! I recently wrote up a proposal page for public transport schedule data. This information would allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a platform. https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules Please feel free to look over the page and give feedback. I am very open to changing the proposal, so let me know if you have any ideas for improvements to it. Thanks, Leif Rasmussen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
