Re: [Tagging] Basic cartography features missing, why?
Toponym key Used at a import. https://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import Translation: Toponyms are used to still be able to apply a name = * to a large area, even if this has been divided into tens to hundreds of small pieces due to the import. The existing AND polygons with a name = * will remain, but will be tagged to toponym. landuse = forest of natural = wood with a name convert to toponym = forest + area = yes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway no, because the content of a bestemmingsplan is what is politically desired and legally permitted, it is a plan. Landuse is not about the zoning plan, it is about the actual current landuse, regardless of its compatibility with the legal situation. That's the irrevocable plan, then all is shaped. For Netherlands law https://wetten.overheid.nl/BWBR0006622/2020-10-01 describing what belongs to a road. " wegen: alle voor het openbaar verkeer openstaande wegen of paden met inbegrip van de daarin liggende bruggen en duikers en de tot die wegen behorende paden en bermen of zijkanten; " " roads: all roads or paths open to public traffic, including bridges and culverts situated therein and the paths and verges or sides belonging to those roads; " All landuse=highway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
For me, the value "parking_space" what key, single space problem must be fixed first to say something about "street_side". As it comes to a vote. Could you elaborate? amenity=parking_space can be used as usual within amenity=parking. This of course also works with amenity=parking/parking=street_side: https://www.openstreetmap.org/way/849745989 Our proposal doesn't affect the documented use of amenity=parking_space; you would use it just the same as with parking=surface. Reading parts over the years about parking. A lot of people do no see amenity=parking as a good tag for street side parking. Mainly prompted by wiki (image) en carto, the visualisation of P. https://wiki.openstreetmap.org/wiki/Parking street side parking is the only method in given on this page. The main tag covering most conventional car parks, coach parks etc. Many additional tags are listed on this page. We will always have that opposition. Also a question for me, must we split the tagging there, when we still can. amenity is mostly with a sign https://wiki.openstreetmap.org/w/images/thumb/8/80/NLE04.gif/60px-NLE04.gif amenity=parking_space can only be tagged on a amenity=parking? https://www.openstreetmap.org/relation/11650954#map=19/53.21448/5.80418 Why is this a relation and not only polygon tagging. (That is a other discussion, but rubs against it) If some, we, not use amenity=parking, how to tag the parking_space as a value? There spots, where people park in the verge, on the grass, or other surface grass_paver, what is permitted. In or outside the residential area. ( "bebouwde kom") https://wiki.openstreetmap.org/w/images/thumb/b/bc/NLE01.gif/60px-NLE01.gif have not a effect on the verge, the EU rule is no_parking on the carriageway. The operating force of a traffic sign may not be expanded. https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Nederlands_verkeersbord_B1.svg/60px-Nederlands_verkeersbord_B1.svg.png. Outside the residential area "bebouwde kom" it is prohibited to park on the carriageway, but not on the verge. How do we do that with parking, amenity=parking? Also the structure of the area:highway methodology, which needs to be further developed in detail. All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway, inside this polygon the objects are area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines There is area:highway=traffic_island https://overpass-turbo.eu/s/Znt there should be area:highway=verge, the busbay is also not well documented. https://wiki.openstreetmap.org/wiki/Key:shoulder the polygon equivalent is area:highway=shoulder. https://wiki.openstreetmap.org/wiki/Key:verge the polygon equivalent is area:highway=verge (verge:access:motorcar=no when parking on the verge is expressly prohibited.) But there is this used area:highway=parking_space, and not for only one space. What a space should be. https://wiki.openstreetmap.org/w/images/4/42/MarekXjunctionExampleWithTagging.jpg area:highway is a used key. All these parking area, should get a tag area:highway, but which? Or both amenity=parking. Or is amenity parking only for lots. https://overpass-turbo.eu/s/Zns ["area:highway"="parking_space"] or is it area:highway=service service=parking_space if it is one space, with multiple not drawn in space, service=parking. That is why I wrote. For me, The search for good cohesion. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
The two methods: 1. Tagging on the way line. When a road, highway=* 2. Tagging a polygon. When a road, area:highway=* Will always be used next to each other. We have to take that into account. New mappers, see a parking plot/space and want to draw that in, that is logical behaviour. It is obvious for them to draw a polygon. And want them to see on a map. It is not obvious for them to tag parking:lane on a highway=*, the method for wayline parking. Originated with the first development of Openstreetmap, then the system evolved, area:highway was developed later. We must give them the opportunity to do so, polygon mapping. Topographical mapping. Also for on the lane parking, we need the polygon to draw in, because space lines are painted on the road or different paving, indicating parking spaces, parking traffic signs refer to it. In the mind of general people there is no difference on the carriageway or beside, for them it is both street side parking. street_side is also on the lane parking. It is more a general term. (I think, maybe more for not native UK people). Do not make a difference between carriageway (painted, surfaced) and beside parking by choosing street_side value as a tag for one (beside). Polygon: Where the transportation modes can walk/ride/drive on a polygon, we tag area:highway=* , that is a base tag. On a way, highway=* we have residential and service and service=parking_aisle, this is on a amenity=parking. For a polygon on lane and beside we have area:highway=service, even when you draw in a amenity parking, you have area:highway, there the lane is area:highway=service service=parking_aisle, parking spaces are a kind of service. The plot/space on a amenity=parking, https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space , there is no much visual difference, when there is a parking_space on a amenity and or on the (marked parking) carriageway or beside parking. The value should/could also be used. There everywhere, places for disabled parking and electric parkin a spaces On the lane road with no marking, there is only the (1.) wayline tagging, parking:lane possible, A carriageway, can have, wayline tagging highway=residential with parking:lane=no_parking, polygon highway tagging area:highway=residential, the lane to walk/ride/drive polygon parking tagging area:highway=service service=parking parking=street_side on lane and beside parking:condition=free In this example there is a no_parking traffic_sign on both side of the road, EU rules, determine that such traffic_sign, no_parking only prohibited parking on the lane, and not the marked parking spaces or the verge. So w must have the opportunity to tag it properly, this is a example both methods of tagging are needed (line polygon). Use area:highway for polygon and parking! The combination area:highway=service and service=parking, should be enough indication for the render to not set a P. (Carto) Even when there is a amenity=parking is set. (wrongly?) parking= street_side could be used there is no conflict parking=* on amenity with parking https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking#Additional_Tags The only point for me is, can also the value "parking_space" be used, with what key? area:highway=service service=parking parking=parking_space(?) (Do we need street_side?) Or is it parking:street_side=parallel People, want to draw in a single space. We have to take that into account. But others draw in several spaces as a one object, parking_space, this is not correct. It must be clear that there is a single spot. Somewhere the value "parking_space" must fit in. parking_space=disabled, this must not be different then on a amenity=parking, if, that is confusing for a lot of people ( taggers), now with electric cars there lots op spaces where only they can park, traffic_sign prohibition next to the space, single space are more drawn in the future. Prohibited access on the space. Netherlands Government, are going to draw in all these spaces, each space get a ref, for linked data, the cost of electric charging, and more. Amenity parking and carriageway parking, space tagging must be with the same tags. If they look the same and the use is the same. So, we must prepared for more detailed mapping. This kind of tagging is almost impossible on a wayline, all these way cuts, visualisation and control the data. A polygon visualisation is more clear. For me, the value "parking_space" what key, single space problem must be fixed first to say something about "street_side". As it comes to a vote. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Link to stream of webcam
It is important to mention the website with the embedded stream. But also the stream itself for direct use. url:m3u8=* Sometimes multiple different extension streams are available for different kind off devices. Such as radio stations with a webcam stream. Live streams. Image streams with from time to time a update. From: Jmapb via Tagging Sent: Friday, September 4, 2020 11:16 PM To: tagging@openstreetmap.org Cc: Jmapb Subject: Re: [Tagging] Link to stream of webcam What's wrong with just url=*? To quote the url=* wiki page, "it is advised not to use this tag when more specific alternatives are available." Like website=*, it doesn't specify that it's a camera feed, so it might be used for other purposes. And in fact I happened to see a couple of nodes using url=* for picture *of* the camera, rather than pictures taken by the camera. https://www.openstreetmap.org/node/4163745929 https://www.openstreetmap.org/node/5979627352 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to map "piers" on land?
Could be a groundy path go over in a bridge=boardwalk, change material, change fixation to a pier, a pier could also be floating. https://wiki.openstreetmap.org/wiki/Tag:bridge%3Dboardwalk From: Paul Allen Sent: Tuesday, July 28, 2020 10:09 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] How to map "piers" on land? On Tue, 28 Jul 2020 at 20:44, Matthew Woehlke wrote: Please see https://www.openstreetmap.org/way/651244930. This is a pier with a platform on land that extends into the water. Carto cuts off the part that is on land. There is no part of a pier on land. Not according to the wiki: "A pier is a raised walkway over water..." and "Lastly, connect the pier with other ways on land, otherwise it will result in a "island" that can't be used for routing." The wiki then goes on to give a misleading or contradictory mention to connecting to the last node of the pier on land. Since your pier connects to a footpath, replace the bit of the pier on land with a closed way tagged area=yes + highway=pedestrian, or similar (I don't know if area=yes + highway=footway works). Just because the surface the person walks on is continuous doesn't make the bit that's on land a pier. -- Paul ___ 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 there a good way to indicate "pushing bicycle not allowed here"?
https://images.mapillary.com/8ErC5D9pxN0AzAJ8YVrEAw/thumb-2048.jpg with extra text, for pushing carry a bicycle. "fietsen meenemen niet toegestaan" "not allowed to bring bicycles" This is a privat acces_sign, guaranteed by access law, expressed by “access in an apparently way for him is prohibited by the rightholder”. They use look a like smaller traffic_sign images. To express, that you can not bring a bicycle. Traffic_signs have have agreed sizes. I mentioned bicycle=explicit_no, here is a sign that give the explicit reason on a sign. But I am now aware that does not fit every situation for a hard no, the combination, different laws working next to each other asked for a hard no. But it is not explicit on a sign. Need a better value for all transportation modes, I hope we do not get for each transportation mode a new key, this is not a decision only for bicycles. riding/driving, shuffling, carrying, transportation, inside vehicle, outside (roof, backside, trailer). (if possible) The earlier mentioned, bicycle=leave This is for me, leave the bicycle behind at the sign. More native English speakers can give a comment on that? So, now we need also a hard yes. That you must bring a bicycle with you. ___ 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 there a good way to indicate "pushing bicycle not allowed here"?
The image are traffic_signs, described in traffic law. Traffic_signs must have set dimensions. There is also property access rules mentioned in law. Art. 461 in Wetboek van Strafrecht. The owner can express by sign with text, images, sometimes they use familiar images. Like here. “Hij die, zonder daartoe gerechtigd te zijn, zich op eens anders grond waarvan de toegang op een voor hem blijkbare wijze door de rechthebbende is verboden, bevindt of daar vee laat lopen, wordt gestraft met geldboete van de eerste categorie.” express “access in an apparently way for him is prohibited by the rightholder”..“is punishable by a fine of the first category” This is a access_sign. NOT a traffic_sign. https://images.mapillary.com/8ErC5D9pxN0AzAJ8YVrEAw/thumb-2048.jpg https://www.mapillary.com/map/im/8ErC5D9pxN0AzAJ8YVrEAw “fietsen meenemen niet toegestaan” bicycles are not allowed here you need a hard bicycle=no. Other situation: Area rules, a access_sign, property access rules mentioned in law. Art. Wetboek van Strafrecht. owner express “in an apparently way for him” He choose the icons. free walking ( also next to the road ) https://pbs.twimg.com/media/ESsU0LrXgAMwTds?format=jpg=large https://pbs.twimg.com/media/ESsU0L0XsAM3oay?format=jpg=large The last not translated sentence. “In andere gevallen verboden toegang Art. 461 Wetboek van Strafrecht.” “In other cases prohibited access” With a horse, riders on designated path. Riders is mentioned, corresponding to the image With a horse, walk with a horse. I do not see such image. horse with a leash. It is forbidden. Where walking freely is allowed, everywhere, you can not walk with a horse, because “In other cases prohibited access” no horse with a leash, there the horse is a hard no. Even this asphalt road. When it is no designated path. The owner determined. Sometimes it doesn't make sense. We must follow, what he express,“in an apparently way for him”. Otherwise you are in violation. From: bkil Sent: Wednesday, July 22, 2020 10:49 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"? Although I think we've given enough evidence and _some_ of your quotes make sense, let me add another consideration. This is where bicycle=dismount could be used (although it is the default on highway=footway): https://commons.wikimedia.org/wiki/File:Opastemerkki.jpg bicycle=no is usually used on busy motorways where dismounting isn't feasible: https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C14.svg ___ 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 there a good way to indicate "pushing bicycle not allowed here"?
It is annoying for me too. A router discussion. https://github.com/abrensch/brouter/issues/79 Talk about a situation the use of use_sidepath and dismount. And the bicycle=no, which is not a hard no. Some qoutes. “Hm, but in very most cases, bicycle=no is used effectively in sense of bicycle=dismount, not in in sense No bicycles here.” “In my experience, bicycle=dismount is used very rarely, mostly if there is an explicit request to do it, in agreement with OSM intention for short way segments only, like e.g. narrow bridges, passes, collision danger etc.” “ The only relevant interpretation of bicycle=no is the OSM tagging intention, not what I or you think about it. And that is clear - red/white traffic sign with a black bicycle, or legal equivalent. The routing itself is for bikers, not bicycles. Pushing bicycle is a legal and frequent mode of bicycle transportation. Bikers may then use such profiles that either penalize it either forbide it ( CF=1 for total ignoring, or for navigation hint consideration )” Nothing changed. What they saying is, it is common accepted, OSM intention. bicycle=dismount is not often used, but very often should it be used, so routers take the common accepted. =no also = dismount. A hell of a job to set all these =dismount, tagging, what is really prohibited is better, OSM method. (new value?). Talking to route developers is now a past station! Conclusion: no is not a hard no. Unfortunately, we must go further. A new value! This not only a bicycle problem. . No, new access key dismounted_bicycle all others must also have a equivalent, unworkable, more typing. Better one value, that fits all, fits the access systematic hierarchy. You must always look at this hierarchy to make routing decisions. The choose for a key make everything more complicated. Also for visualization. From: Tod Fitch Sent: Wednesday, July 22, 2020 4:53 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"? This thread has been quite amazing to me. My impression is that it starts with some routers (a.k.a data consumers, a.k.a. “renderers”) treating a “no” as a “maybe” and now people are looking for a new term to indicate that “we really, really, mean NO!”. This is worse than tagging for the render, it is obsoleting a straight forward and explicit tag value for a broken renderer. Discussion devolves into “if I disassemble by bicycle and put into wheeled luggage is it okay now?”. Why not treat “no” as no? If I can push the bicycle through then we already have “dismount”. Is there some other way of getting a bicycle through? If so, then come up with a new value for that (“disassembled”?). In the meantime, file bug reports against any router that routes a bicycle over a “no”. At least where I am, “no really means no” and if you are caught with a bicycle at all then you are subject to a fine. Thousands of kilometers of paths are so marked and it really wouldn’t be nice to redefine an existing value. Cheers! Tod 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 there a good way to indicate "pushing bicycle not allowed here"?
https://images.mapillary.com/yQWkL-XX5eRN5A2j0JkKIA/thumb-2048.jpg Geen toegang: - met (brom)fietsen. No access: - with bicycles. This is written, grammatically and orthographly, in a way, that the "vehicle" is meant. explicit the bicycle no access. This is privat land, Staatsbosbeheer, owned or in control, all over the Netherlands, you see these type of signs, arranged in the same way, the layout. Mostly all of these roads/tracks path are permissive https://commons.wikimedia.org/wiki/File:Waterloopbos._Natuurgebied_van_Natuurmonumenten._Informatiebord.jpg - Fietsers op verharde fietspaden en wegen -Bicyclist on paved cycleway and roads. Here is written what is allowed. But more important: Overigens verboden toegang Artikel 461 W.v.S. Others prohibited access, article 461 Code criminal law. The word “Overigens” means: all the other which is not mentioned above on the sign Not pushing a bicycle on a unpaved cyclway, path, tracks. So others then “wegen” roads. A active Openmapstreet member got a ticket for pushing his bike on a not allowed “wegen” by a certified ranger (BOA) Community service officer. This sign with “Overigens” of the private organisation Natuurmonumenten, you find them all over the Netherlands, with the same layout. ‘' bicycle=explicit_no sounds to me like "there is an explicit sign forbidding this", Indeed. not "bicycle vehicle itself is prohibited, not just cycling". That sounds like bicycle=prohibited. :) ‘' Text on sign: “Overigens” and “- met fietsen” "bicycle vehicle itself is prohibited” I need a value .*=explicit_no for “the vehicle” or some other value that means the same. “the bicycle is not allowed” This is for all kind of transportation and vehicles. Pushing carry/not allowed. It seems highly strange that you wouldn't even be allowed to carry/push your bike, are you sure that was what it meant? Do you have a picture of the sign? ___ 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 there a good way to indicate "pushing bicycle not allowed here"?
There lots of forest roads/path, where the bicycle/pushed carried is prohibited. Mostly, private owned land with a access_sign. “the bicycle” “transportation vehicle” is prohibited. Because, navigation programs do not us bicycle=no, as a hard no, there is the need for a extra value. bicycle=explicit_no, means “the vehicle” is prohibited. Why a value? We need a one value, otherwise a lot of more keys, which makes it things complicated. At the end it means for all explicit no! bicycle_pushed=no motorcycle_pushed=no horse_pushed=no ;-) moped_pushed=no mofa_pushed=no etc. Better one value, key=explicit_no What do you think? If we do not solve this problem, this stays forever. On the wiki page dismount, this bicycle_pushed is mentioned. https://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddismount For me a wrong advise. The problem is wider for more transportation modes, even for other product to carry around. Private access_sign rules, can go much further then traffic_sign. In what is prohibited. What the owner think and write down on the sign is valid. The skateboard is prohibited, means you can not carry a skateboard around with you. skateboard=explicit_no I need this value to do it correctly. Where the bicycle is no allowed. Or a other value meaning the same. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source=RTK_GNSS
Thanks for the accuracy link “you should mark the approximate accuracy of the given measurement as returned by the instrument in the given instant.” That is also better. It is just, that you get a hint, source, accuracy, that the data is measured in. Before you drag a node.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] source=RTK_GNSS
There is data, what is measured. With RTK GNSS, there is 1cm accuracy possible. Should we tag this mapped data, so that we know the accurancy level of this data? Greetings Allroads.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc
+1 landcover +1 on a hierarchy index and a well and a thoughtful methodology. landuse, should describe more the use of the land. For example: A road, this include the footway, cycleway, the verge, the barriers, traffic_islands, the trees. The verge, that is a part of the use, landuse=highway, the area is area:highway=verge, landcover=grass, landcover fits in nicely. And how it is managed can be set. The hedge as, a separation between road parts, can be a part of landuse=highway, area:barrier=hedge, hedge_type=? landcover=shrubbery/or else, species. And how it is managed can be set. The hedges on traffic_island, roundabouts, is a part of the landuse=highway , is a part of a area:highway=traffic_island, is the area:barrier=hedge, hedge_type=? landcover=shrubbery/or else, species. The same for flowerbeds, etc. The apron at a roundabout. At the end all parts must be named. greenery versus shrubbery, is it the same or is the one a part of the other? hierarchy thinking. From: Peter Elderson Sent: Sunday, February 9, 2020 11:59 AM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc The landcover key covers this nicely. ___ 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] key, name, long or a partial abbreviation?
This is a question only about how to choose a new keyname. Is it possible to use a partial abbriviation? For example: There is motor_vehicle, with one underscore. to express a categrory with a more then one track or more then 2 wheels. We can choose for: multi_tracked_motor_vehicle, with 3 underscore, quite a long name to type in, must that be avoided? Avoid long names with multiple underscore. Which weighs heavier when considering a name. Is it allowed to choose for? mt_motor_vehicle partial abbriviation, “mt” stands for multi_tracked Does this express the category well enough? Do people understand that? When there is a mt_motor_vehicle, there is “st” partial abbriviation, single_tracked_motor_vehicle. Is it a “do” or is it a “don’t”. Give me your opinion. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] footway=crossing in detailed tagging
On 15/12/19 12:30, Mateusz Konieczny wrote: Let's say that we have footway mapped separately from the road, road has footways on both sides. Footway has surface=paving_stones, road has surface=asphalt. There is a crossing, made from three ways: - (1) highway=footway surface=paving_stones (for a bit from centerline of sidewalk to the curb) - (2) highway=footway surface=asphalt (for part on the carriageway) - (3) again highway=footway surface=paving_stones for part from curb to the centerline How footway=crossing tag should be applied? To all three or just carriageway surface - (2) segment? in my opinion there should be no doubt in assigning only to 2, from kerb to kerb. Ale Agree, from kerb to kerb. Is the most correct to do it. If people draw in (in the future) a area:highway=* inside this area:highway the surface on the highway and area must be equal. Because people started to draw in, I liked to see what is drawn in. (Experimental style) A image say, give you a hint, much more then a writing. https://i.postimg.cc/HLxskWqL/crossing.jpg https://i.postimg.cc/ht4K2PP0/crossing2.jpg https://i.postimg.cc/G2wNSqx1/crossing3.jpg dark red yes is crossing:island=yes Allroads ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Small electric vehicles
As I wrote earlier: >>So I must make a icon for speedpedelec, for use my style. >>This is needed because, government write speedpedelec with text on >>traffic_sign (undersigns). Even estate owners could make signs with >>.. At the bottom of the diagram speed_pedelec is needed, because govenment use then a text (or which icon) on traffic_sign. A direct translation is needed. Key is needed. In the Netherlands a speed_pedelec is a moped, by rule, follow the rules of moped, BUT, then the govenment can use the text speed_pedelec to express a other behavour, “uitgezonderd” except. The base tag speed_pedelec must be there. *: electric=* This have nothing to do with base tag of a vehicle. There could be speed_pedelec:electric=yes. Maybe in the future a other kind of power is used. So I did not say moped:electric= is a speed_pedelec, moped:electric can be a much bigger group. Earlier I posted a link with “special mopeds” https://www.rdw.nl/over-rdw/actueel/dossiers/bijzondere-bromfietsen In the Netherlands the speed_pedelec must know that they have to follow the moped rules, so also moped:electric=yes. He can use that road. So is a segway, is also a moped. Because in text or icon, prohibited. Key segway or a other key? Does a icon that looks like a segway mean a bigger group ( the motorcar problem, this mus be avoided ) Then there are hoverboards (self-ballancing scooter) All small electric vehicles. How to put them in a access diagram? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Small electric vehicles
>.>they? Why didn’t you do something about it? > (or are you asking for bicycles with sidecars?) >generally I agree, exceptions apply. In the motorcar example they are grounded >in real life particularities (best reason I’d say). >... I am a part of the they, then it was not within my area of focus, scope, in the given time range when it originated and was implemented, now after a while we all have more knowledge, then the question is how we can solve it in a way that does justice to, where the tagged does not be destroyed in such a way, that it remains applicable. That is my approach now. So leave motorcar as it is, people who want to use it, because it is used so much. Don't let us stop implementing the following. Give people the opportunity, to tag more correctly, this means for me the introduction of multi_tracked_motor_vehicle, /mt_motor_vehicle. This does justice to the principle “generally I agree”. Where I am working on: Traffic_sign translation. I miss keys for transportation, to make a tag combination. So I am interested in the access diagram. https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden Ended up to make a style, to see and control the tags. Get hints in Josm window. http://mijndev.openstreetmap.nl/~allroads/JOSM/Styles/Road_extended_JOSM_style_info.html Far from ready. Under construction. I must totally rewrite it, because of new insights, new wishes, things are not possible in mapcss and still learning, time as stumbling block. https://forum.openstreetmap.org/viewtopic.php?id=58694 Focus on road tagging. When it comes to a voting about a key/value. Give people the opportunity, to tag more correctly, at a voting, which arguments are more important. Saying “no” “yes”, the why is more important. When I make a proposal, multi_tracked_motor_vehicle. Many are fine with motorcar, If they do not see the need for others and there vote is “no”, this “no” has for me a lesser value. This could have a negative effect on the development of OSM. Which interest is greater than the others, what to decide. Lately I wrote down for myself some thoughts. 1. A traffic sign (combination) should preferably be tagged with as few tags as possible. 2. A traffic sign should preferably be tagged as directly as possible with tags. 3. Neutralizing, opposite tagging should be avoided as much as possible. 4. The diagram access hierarchy is not complete, missing keys. 5. When developing key value, the decision hierarchy must be considered. 6. Every way of transport must have equal opportunities to achieve good routing. 7. Possible conflicting keys/value must be solved. (Dual explanation). 8. A traffic signs wiki is very important. (Also combination signs on pages.) Carefully selected, customized for possibility of use in presets. multi_tracked_motor_vehicle, the possibility of use, used in presets, (it is a correct key) maybe over 10-15 years, we see, it is a established key, more important then motorcar. ;-) The life of a key. Mission accomplished. Give it a try? So I must make a icon for speedpedelec, for use my style. This is needed because, government write speedpedelec with text on traffic_sign (undersigns). Even estate owners could make signs with .. small electric vehicles, as a group, which vehicles, where is it placed in the hierachy, which icon should I use. hydrogen, ...must these vehicle have also their own group? (future) or is a key needed that gives which type of motor is used. moped=no and moped:electric=yes In the Nedertherlands on a G13 traffic_sign “not mandatory cycleway” a mofa can use it, BUT, .. “Bestuurders van snorfietsen uitgerust met een verbrandingsmotor mogen het onverplichte fietspad slechts gebruiken met uitgeschakelde motor.” “Drivers of light mopeds equipped with an internal combustion engine may only use the non-mandatory cycle path with the engine switched off.” https://wetten.overheid.nl/BWBR0004825/2019-07-01#HoofdstukII_Paragraaf1_Artikel5 This means that you can use it with a electric motor or bicycle pedals (if on it), manually. Then the access is mofa=no mofa:electric=yes mofa:manual=yes. This is a translation of a traffic_sign and law rules. *:electric=* is lower in hierarchy not used yet, https://taginfo.openstreetmap.org/keys/mofa:electric Is this better to appoint electric use? I think so it could also be used for all type of vehicles. See the practise of emission zones and rules, what we see translated on traffic_signs. https://forum.openstreetmap.org/viewtopic.php?id=60186 even the age of a vehicle is now used. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Small electric vehicles
>it really depends. I guess we agree that the meaning of tags in OSM is based >on their common usage, so motorcar=yes means an automobile (i.e. not including >for example busses or trucks), while motorcar=no means any multi-tracked >motorized vehicle is excluded (implies hgv=no, tourist_bus=no, etc.). >This is based on the legal meaning of the common traffic signs that get >translated into this tag (and may be different in some jurisdictions, I am >only referring to places I know, i.e. western / central Europe). I disagree. I used this as example, that a key must have distinct meaning, that is in OSM a common practice. The method is more decisive, more important. If you see the beginning of the key motorcar https://wiki.openstreetmap.org/wiki/Key:motorcar in the wiki, it was only automobiles, because of motorcar abuse, they wrote the controversy in it. A problem to be solved. We all know how a wiki developed, evaluates, a few can change the content. They did not want to solve the problem then. There are quite a few mappers, who are annoyed by this. Now you have a sidecar, it is a motorcycle but also multitracked vehicle. This get very complicated to write a routing and parking script for sidecars. This is a disadvantage for the sidecar group. I believe each category must have equivalent method of treatment. In particular, it should not work to a disadvantage. “The meaning of tags”, is a key/value combination, both key and value must be distinctive, so the combination can not mean something else, waht both say. Contradiction must be avoided. That is common method usage. If I ask a lot of people about the method, than the outcome is your right. So the motorcar usage is not common practice, it is a problem. It is a bit off topic, it is a example, how things can go wrong. That is my message in this topic. The development of new key / value tags, must meet certain method conditions. In the Netherlands, the Government have a group “Bijzondere bromfietsen” special moped https://www.rdw.nl/over-rdw/actueel/dossiers/bijzondere-bromfietsen See the links in the list Some of them are electric. How must they fit in the access hierarchy?___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
Why should we need to tag the part of the path inside road area specifically (e.g. as footway=connection), but not the part of the track inside the road area? (e.g. as path=connection) Yes, why, that I asked myself too! Why, use it everywhere. It could be used everywhere. That is why we discuss it here, to figure out, what is necessary or not and where. The original question for me was, what to use as a equivalent for a *=crossing, that is a T connection. From kerb to middle wayline. In other cases, is there the need to use it also? Openstreetmap, is always to find a balance, where to tag something or not. Not every tag have to be set everywhere, sometimes it is so obvious, in some cases it is useful, tagger decide where. I work as a volunteer tagging for a project "traveling independently" for people with an intellectual disability, people with a brain injury, people with a psychiatric disorder or seniors. "Learned early, gives confidence, gives independence". On their daily traveling, now there picked up by a privat (taxi) bus from home and bring to the accommodation, they often go to. This cost also a lot of money. Parents does not have they time often. Discussion. At kerb, what (voice) note, "step on the road" "step on the footway" both side of the kerb is a highway=footway. Which direction, which call. footway=connection is a option. Comparing with, at the area:highway=* inside the polygon, can I draw the conclusion, that we must split, not going for one value, because it's different in behavior, because, the carriageway and the sidepath, there is a hierarchy, how we look at them, use them. Cycleway and sidepath, also a hierarchy between them. Outside of the box: (mind triggering) We do not tag in a polygon area:highway=unclassified, the part inside the polygon, highway=track track=crossing crossing=unmarked. This is what I mean find the balance of using a value, where it is more appropriate, our decision have something to do with how we feel about the hierarchy. Allroads ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Small electric vehicles
Together with the introduction of the new tag, would it also be possible to have a new access category tag that contains all singe-tracked motorized vehicles? The hierarchy in access is important, very important for routing. (their scripts). Changing, hierarchy have a major impact!! The hierarchy in a diagram. https://wiki.openstreetmap.org/w/images/thumb/c/c5/Access_hierarchy_simple2.png/794px-Access_hierarchy_simple2.png From German access page. Now, where does it fit in. Speedpedelec Laws in countries are different. Does the speedpedelec gets its own icon by law, a own prohibition sign, or is it just text at a undersign. A undersign often tells by text or icon, that the above sign, leading sign, the rule for a group "does or does not" not apply to those mentioned on the bottom plate (undersign). The conclusion is that the mentioned is part of the category mentionedon the leading sign (prohibition sign) Netherlands https://www.rijksoverheid.nl/onderwerpen/bijzondere-voertuigen/vraag-en-antwoord/welke-regels-gelden-voor-speed-pedelec A yellow plate is a moped plate, so in the hierarchy the speedpedelec is a moped and then The Netherlands it is under de "bromfiets" moped icon in access. oneway:moped=no in the Netherlands, also applies to the speedpedelec, If you want a single_tracked_motor_vehicle, the logic says then there is also a double_tracked_motor_vehicle, long name dt_motor_verhicle. double_tracked_motor_vehicle os probably not right. Laws often speak about "more then two wheels" or "more then one tracked vehicles, a treewheeler https://en.wikipedia.org/wiki/Three-wheeler, then a tag like multi_tracked_motor_vehicle or mt_motor_vehicle would be appropriate. multi_tracked_motor_vehicle, solve the problem of abusive use of motorcar, which is a personal car. Not a total group of vehicles on two wheels. Major hierarchy impact for routing systems. Back to single_tracked_motor_vehicle, st_motor_vehicle, this also means a motorcycle, this key is good for inclusive motorcycle. motor_vehicle, include always, moped, mofa, motorcycle, and much more, also We also have disabled vehicles, like a wheelchair, but also motorized disabled vehicle, which are not a "bromfiets" moped. " RFC - Small electric vehicles" also included? Then you get disabled_vehicle and also disabled_motor_vehicle. Al must fit in the hierarchy of access. https://www.rijksoverheid.nl/onderwerpen/bijzondere-voertuigen/vraag-en-antwoord/wat-zijn-de-verkeersregels-voor-een-gehandicaptenvoertuig-met-een-motor These categories are mentioned on prohibitions traffic_signs C13 C15 https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring Find out in which countries a speedpedelec is a moped, where not, how this must be placed in the access diagram. C12 tagging: motor_vehicle=no & motorcycle=yes & moped=yes & mofa=yes & traffic_sign=NL:C6 The problem is the needed opposite tagging, to exclude from motor_vehicle, a multi_tracked_motor_vehicle would be welcome. Now we see, that often for small groups categories the tagging is not correct. A negative effect for those. Better to avoid "these needed opposite" tagging. This argument gives impulse to use good overthought collective categories, such as dt_motor_vehicle, st_motor_vehicles. A group for moped and mofa, difficult, these are low_speed_single_tracked_motor_vehicle. lsst_motor_vehicle. Just a thought. Overall it is not easy to place new categories in the middle of the access diagram. This have a major impact in routing scripts. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
https://i.postimg.cc/c43VzBtk/squarelivingstreet.jpg Took the wrong link. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
https://i.postimg.cc/J41D2GSJ/pedestriansquare.jpg [6]: https://www.openstreetmap.org/way/416303537 I made a mistake. i thought it was a pedestrian square, but it is a livingstreet, so a T connection from steps to middle livingstreet carriageway. This need a *=connection value tag. https://i.postimg.cc/9fMgcmSN/squarelivingstreet.jpg My mistake, there you see difference livingstreet and pedestrian area, handling. Mostly in a livingstreet there is a kind of lane created with different stones to guide the vehicles. Besides this lane, could we speak of a sidewalk or more a pedestrian zone. Difficult. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
Markus example: Let's use a nearby example: https://www.openstreetmap.org/way/86205950. It does not matter if the stairs are parallel or not! Draw this image over the example, JOSM changes (not uploaded) drawn in. https://i.postimg.cc/t70p6WXm/Neubr-ckcrossing.png The area:highway=footway is correctly drawn in, but the footway is all footway=sidewalk, your still walking on the sidewalk. In a area we draw lines like this highway=pedestrain area:yes example, area=yes should give area routing. https://wiki.openstreetmap.org/w/images/1/19/Line_area_connection-EN.png This image comes from this site: https://wiki.openstreetmap.org/wiki/Guidelines_for_pedestrian_navigation Only way lines inside a area:highway=*, which have "not" equivalent value, should get the value, *=connection or link. Nothing else. We need this tag only from kerb to middle wayline carriageway, and can be used for pedestrian, footway, path, cycleway if there is the need to use it. *=crossing value is cleary defined, *=connection must be the equivalent of *=crossing, at T connection on carriageways. This must also be clear defined! (We do not draw a crossing further then the kerb of the road, so not as far as the middle line of the sidewalk)!! Other perpendicular waylines inside a area:highway does not need that, if so then a other kind of value (I do not see the need for that) Be aware that some people think that at a wide sidewalk, also a polygon, highway=footway footway=sidewalk area=yes, can be used just like the pedestran example ( a polygon and a wayline drwans in for pedestrian.) When you are on a sidewalk, it feels you are on a sidewalk, then it called a sidewalk. I use my own style, far from complete, just working on sidewalk and crossing tags visualisation. I just missed a quick hint what is tagged. Where do you need it, I think where kerbs are it is more important, and when you use area:highway, *=connection we could render visualise it slightly different. https://i.postimg.cc/D0n5S70G/tpath.jpg [5]: https://www.openstreetmap.org/node/413988097 https://i.postimg.cc/J41D2GSJ/pedestriansquare.jpg [6]: https://www.openstreetmap.org/way/416303537 Like now, in Carto a polygon is rendered above the wayline, the example is area=yes pedestrian visualisation. Nick Bolten examples: Shelter crossing https://i.postimg.cc/bJQpcL1Y/sheltercrossing.jpg In front of the shelter (left) (busstop?) could a highway=platfrom be used as a tag. I never draw a line over a shelter. right of the shelter middle of the way the wayline. Steps building https://i.postimg.cc/WzfPvyYZ/areafootway.jpg steps, perpendicular footway to steps is footway=sidewalk, when you could draw the polygon area:highway=footway footway=sidewalk, this is inside the polygon, equivalent value. So =sidewalk. Allroads. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
Then there is a tag as placement=transition.
This have also a kind of connection link function.
When we split a road by a traffic island we use placement=transition for
that part from middle of the road to middle of the lane.
(1) placement
-- lane
/(1)
road ooo
\(1)
lane
I asked myself, when you go from a road to the designated cycleway, that
connection, is that also placement=transition.
\
\(1)
- - - - - - - - - cycleway
Or at a junction where cycleway have two oneway to connect.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - cycleway
||
\ /
\ / (1)
=== road
||
||
||
If we think about it further, where more does this tag fit?
Allroads
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
Was just a example, to make my situation description, more understandable. First drawn al the polygons, area:highway, then all what is inside this polygon. Kerb as a polygon, because it is a polygon, so a polygon. The more advanced mapping. People can choose. If they do we must think about, that how to fit in. This is not a lowered kerb, this is a driveway kerb and these kerbs are wheelchair=no, the incline of these driveway kerbs is to high. There are rules for that. From: Peter Elderson Sent: Saturday, November 23, 2019 1:07 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Feature Proposal - RFC - footway=link Looks good. I think mapping the lowered kerb separately for simple exits is a bit overdone. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
I worked out a visualisation image. >From the situation I linked in my earlier post. https://i.postimg.cc/jqJSxT1w/service-crosssing-text.png Allroads. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
Now your questions @ Markus. Your example: Example (to be displayed with a fixed-width font): ┃ ┆ ┃ ┃ ┆ ┃ <- driveway ┃ ┆ ┃ ━━┛ ┆ ┗━━ ┄┄┄1┄┄┄ <- sidewalk ─┆─ 2 2 ┈┈┈ <- residential road ━━━ >1: highway=service + service=driveway? In my example image, same as yours, (1 horizontal), it is highway=footway footway=sidewalk ( 1 vertical) for the service road is is highway=service service=crossing Why service=crossing, the driveway start at the private property, sidewalk is public, but could be highway=service service=driveway driveway=crossing, Inside that polygon. >2: highway=residential? highway=service, but is there also a *=connection possible? We must work things out. How to use *=connection or else. Allroads ___ 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=link
The variation of drawing and setting tags. 1. People draw in the carriageway road as a wayline. Wayline middle of the road. Exactly, where it is. 1.1 Then they decided that there is a sidewalk, on the right, tagging sidewalk=right, this says there is somewhere a sidewalk on the right next to the road. But not exactly, where it is. 2. People want to drawn in the sidewalk as a wayline next to the road, in the middle of the sidewalk, safe walking route. tag it: highway=footway footway=sidewalk. Best is to connect it !! correctly for routingpurpose!!, that was there goal. (kids routing on the sidewalk, the routing track line lays in the middle of the sidewalk, no complaints parrents.) 2.1 On the carriagewayline, the tag sidewalk=right is changed to sidewalk=separate. Because, routing is drawn in correctly on the sidewalk, routing could use that, then not on carriage road for pedestrian. 2.2 Also on the road wayline, foot=use_sidepath is set. !! All when routingconnections is well done !! Or when traffic_sign foot prohibited, foot= no. The routing know now it is more legal. 3. People want to draw in the sidewalk as a area. then the tag: area:highway=footway footway=sidewalk is set. Topographic visualisation. All these variation of drawing must fit together. What I wrote: inside the drawmethod 3 polygon: (area:highway=footway footway=sidewalk ) only drawmethod 2 lines can be drawn in with that specific tag: highway=footway footway=sidewalk, because the way line is drawn in the middle, there is a perpendicular part from the middlewayline to the outline of the polygon, where the barrier kerb is. At this point you step on the road, there comes this new tag in operation, tag: highway=footway footway=link or better *=connection, you walk further on the road. These are T connections !! There is one exception: A. When you have a cross X connection, we speak of a crossing. When the polygon is crossed with a wayline by a road crossing! (mind turning) Your problem drawing at a service (driveway). @ Markus The choice, at the polygon, is it an area:polygon =service or a area: polygon =footway. drawmethod 3 polygon: (area:highway=footway footway=sidewalk ) Now you must set your mind to a new thinking, 180 degrees, what we used to do. Normaly, the pedestrian crossed the road. We set footway=crossing. BUT, image example: https://images.mapillary.com/3qPJ4v8tao8cVmYzTbuoJg/thumb-2048.jpg location :https://www.mapillary.com/map/im/3qPJ4v8tao8cVmYzTbuoJg What you see is that the sidewalk footway surface at the driveway has been extended, on-going. Same paving as all the footway. 30x30 paving stones. It is the footway. Then the polygon is drawn in as a area:highway=footway footway=sidewalk But at a service (driveway), there the car crosses the footway. The car must always give priority to the pedestrian. The footway is more important then the service way. So the wayline highway=service gets “service=crossing” inside this polygon (area:highway=footway footway=sidewalk). That is the exception ! The driveway construction is here with a driveway kerb. But could be else too. Decision of the mapper. The on-going pavement of the footway but also on a cycleway, priority of way, gives a different relationship to each other, ending up in saying service=crossing In the Netherlands we have the privilege, to use Goverment data, license agreed with OSM. (Site under construction) Sitemap with layers where we have a agreement on. http://mijndev.openstreetmap.nl/~allroads/NLOSMOK/OSMOKNL/OSMOKNL.html Zoom in, then check on, BGT standaard V2, we could use these polygons for Openstreetmap. See the pink colors polygon these are mostly sidewalks in a village town. Then you see where sidewalks are on-going, and where a pedestrian must cross the road. We now use these BGT layers to line out Openstreetmap highways waylines, this is more accurate then doing it with aerial (note: use map overpass uncheck with much panning and zooming) Combining these variation of drawing in, these wayline footway=* connecting (link) could be used for T connections. From kerb to middle carriage road wayline. perpendicular: footway=sidewalk, go on the footway left to the kerb. The outline of the polygon. At the kerb a disabled person must get the message, step on the road and follow the road to the right. Is there, this new value helping? You do not want that a audio message say, step on the footway and follow the footway. (this is only at a crossing) ___ 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=link
When there should be a footway=link then there should also be a path=link cycleway=link This is then a new method to tag a virtual T connection on the road. This must be well thought out. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - footway=link
All waylines inside a area:highway=footway footway=sidewalk is a highway=footway footway=sidewalk When there is a connection to the road, inside the area:highway=footway, footwalk=sidewalk is till the barrier=kerb. Only on the road from barrier=kerb till the centerline of the road (wayline) could be highway=footway footway=link. When the footway crossed the total road, then footway=crossing is used. This is a example, where the highway=footway footway=sidewalk, is drawn till the barrier=kerb from a cycleway, then a unmarked crossing. https://josm.openstreetmap.de/raw-attachment/ticket/18213/noselectwayline.png ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Their are Government rules and landowner rules. These landowner rules are mostly expressed on the border of their land with a access_sign > access_sign rules >“typically not traffic rules but additional” equally important In the rural, their lots of these access_signs. Mostly written what is prohibited. Text: “Access on roads and paths” “Forbidden for bicycles” “Forbidden for motorvehicles” etc. Their access_sign, with written on it, what is allowed and end with “others prohibited”. To catch all these others in tags. Lately I was in contact with a landowner of a estate, because of financial benefits, he can open up the area for use, setting the rules by himself. (Their are regulations, what he can do or not). Then I asked, if it is allowed to push a bicycle. No, you are not. And this is very common on many nature reserves and natural environments. He also wanted only walking, not running. running=no? Area located next to a residential area, with sports accommodation in the nearby area. He did not want (organized) running groups to use his area. No, dogs. He expect from me to tag it right, I mentioned that OSM does not have that strict forbidden tags. He find that strange. That’s why, my thoughts, also other transportation modes are not allowed to push in the area. vehicle=no_vehicle, then I catch all the transportation mode in a one tag combination. If it is a key, I must have all these key variations. From: Martin Koppenhoefer Sent: Wednesday, November 6, 2019 3:17 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"? We need a hard and strict no. I would agree with this, altough these are typically not traffic rules but additional, arbitrary rules like dress codes, gender based restrictions, etc. People want to express those rules, so we should have a tag that unambigously expresses the rule. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?
Yes, indeed, and not only for motorcycle. also moped and mofa. There is law that says, pushing the mofa, moped, motorcycle, you must follow the rules of a pedestrian. It also says, where the pedestrian should walk, first on a footway, if that is not there, on cycleway, if that is not there, the verge or the side of the road. Trafficsign https://upload.wikimedia.org/wikipedia/commons/thumb/6/6b/Nederlands_verkeersbord_C11.svg/60px-Nederlands_verkeersbord_C11.svg.png Law says, the "vehicle" the "motorcycle" is forbidden to use the lane of the road after this sign, when passing the sign. The above rule overrules is, pushing is then allowed, rules of the pedestrian to follow. Or undersign, where in text "the vehicle" is mentioned/forbidden. Then there are these privat access_signs, with text, where mostly "the vehicle" is mentioned in text, not the mode of transportation. Not only for bicycle dismount is used. These mofa moped motorcycle, need also wiki pages. Where "the vehicle" is forbidden, by sign or by text. Take a value, that others can use too. ? Just a thought! bicycle=no_vehicle mofa=no_vehicle moped=no_vehicle motorcycle=no_vehicle ? If you can solve it with a value, do not use a new key! Otherwise the two keys can be used next to each other, we must avoid this. no_vehicle is a hard no. Easier to use for routers, I think, then checking multiple tags. My point is, which method to use, it should be useable for more kinds of transportation. If? use a new key, other transportation modes need also such a key. Do not vote for one key, make them all at once. to document why it is used and why it is anyway duplicate of bicycle=no. Routers, do not use the bicycle=no as strict as, because "OSM tagging intention". quote from Brouter discussion, 19/20 September Hm, but in very most cases, bicycle=no is used effectively in sense of bicycle=dismount, not in in sense No bicycles here. The only relevant interpretation of bicycle=no is the OSM tagging intention, not what I or you think about it. https://github.com/abrensch/brouter/issues/79 We need a hard and strict no. I need to express the access, so that routers do not use no as a dismount. I know it is the routers choice. But I want no bicycles there when i set a tag. People use also: bicycle=privat, what is the meaning of that? pushing a bike is allowed? Allroads. -Oorspronkelijk bericht- From: Martin Koppenhoefer Sent: Wednesday, November 6, 2019 8:05 AM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"? sent from a phone On 6. Nov 2019, at 01:25, Warin <61sundow...@gmail.com> wrote: Does motor_vehicle=no mean I can push one though there? I did think not ... at least not on a regular basis indeed, moto_vehicle=no does not prevent you from pushing your motorcycle. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
So there are lanes and virtual lanes. We must make a good distinction, I must be able to see immediately, whether I am dealing with a marked lane or a virtual lane, that has no marking. Do not expect from a mapper, at a marked lane, also to set marked = yes. (or else) to make the distinction. See wikipedia and else, there all marked. A two-way road without a marking in our country, does not have lanes! (law). Although, you can pass each other. There, we could have also a new tagcombination! But not lanes=* , these are marked! (law) To make a good distinction, it must be immediately clear. What do you think of: lanes: virtual = (number), lanes that have no markings. Not a second tag needed. The same method as there is used highway: virtual = pedestrian, to make a route line over a pedestrian area. Or over a field, a beach. You could say, lanes are created in the UK, lanes are created in OSM, these lanes where written down as marked lanes, to use lanes=* for virtual lanes was a abuse of the tag lanes=* , if you do use it, you make the definition unclear and that should be avoided, there is a new tag needed. Problem solved. Quote: yo_paseopor In Spain is easy: when there is no marks = lanes=1 Also when they are a passable, two way road? When there are no marking there are no lanes. lanes=1, like on a highway link, is indicating one way, one direction. A lot of lanes=1 are deleted in our country, because they are not a lane (rijstrook)(law). Allroads. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
First, the consensus in OSM is, that only the tag key lanes=* is used, when there is are visual markings for lanes. Then the question is, are there lanes? Yes or no. How many? lane_marking= no, we agreed (OSM), when no visual lanes there are no lanes, lane_marking, it is referring to lanes, that are not there, so useless tag. If lanes=no is not right, lanes=0 zero means, that there are no lanes, zero is nothing. I tagged a few , as you named two way road with no lane marking lanes=1, they told me that is wrong, I agree, it have no lanes/rijstroken/fahrstreifen, retagged them. Width tag is way to go. For roads without lanes. Estimation is difficult, maybe one day Mapillary can measure the width of the road. In JOSM you can measure the width of a road, drag a line and see width. Some countries, Goverment produce open data, look or agree with them if you can use it in OSM. (lisence) Here a third party, https://bgtviewer.nl/ visualise the data. We can use it. To realign roads. (A lot of the data is measured in, correct) We can not do better ;-). Wider use of lanes. We can not do that. Just read all the dictionaries, wikipedia, etc. according to lanes, it is always lanes/rijstrook/fahrstreifen (images with markings) First these must be rewritten, global accepted. This is not happening. So OSM stays, lanes are a part of a road with markings. lanes= is used for lanes, when there are no lanes, there should me a possibility to give a tag, lanes= is used, either it is lanes=no or lanes=0. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
A carriageway can have lanes or not. A lane is a part of a carriageway with visual markings. In Dutch law we have. rijbaan = roadway = fahrbahn and with visual marking, we have rijstrook = lane = fahrstreifen If there are no visual markings, there are no rijstroken / fahrstreifen / lanes. A two way roadway with no visual markings do not have lanes. lanes=no There could be lanes=yes, better is to give the number of lanes lanes=2 and set lanes:forward lanes:backward. Now, I do not set lanes=no, I like to, so that we can control, if on all roads lanes tags are set. To see, if there are data gaps. nolanes=yes is not logic for me. Are there lanes on a road? Yes or No. The answer is no, then the value must be, no, so it must be lanes=no. You do not ask: Are there no lanes on the road? People have problems with such a questions, mixed answers, failure rate is higher. Negative question, we must avoid that! Therefore, avoid nolanes. ___ 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] iD adding highway=footway to all railway/public_transport=platform ways and relations
For me it is highway=platform, ID, is doing it wrong. In a discussion, I drawn out a visualisation. https://i.postimg.cc/wxJcG6bH/bushaltehaltekominvulling1.png Allroads. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=crossing used on ways
As I used it On a node: highway=crossing This only say not so much, it could be also unmarked, crossing with a value. Mostly I tag a crossing_ref. Footway: On a way: highway=footway footway=crossing crossing=uncontrolled or else, this is for the whole crossing. (crossing=island can not be used, you can only use crossing once) if there is in the middle a crossing island, that little part, where pedestrian could wait, often there is a traffic light for pedestrian, tag crossing:island=yes but on this little part there can not be a crossing_ref=zebra That part as a polygon area area:highway=footway cycleway=crossing crossing=uncontrolled crossing:island=yes The last 3 tags could be retrieved from the way! Cycleway: On a way: highway=cycleway crossing=uncontrolled or else if there is in the middle a crossing island, that little part, where cyclist could wait. often there is a traffic light for bicycle ( more wider busy road), tag crossing:island=yes That part as a polygon area area:highway=cycleway cycleway=crossing crossing=uncontrolled crossing:island=yes The last 3 tags could be retrieved from the way! Path: highway=path path=crossing crossing=uncontrolled or else if there is in the middle a crossing island, that little part, where pedestrian could wait. often there is a traffic light for pedestrian, tag crossing:island=yes but on this little part there can not be crossing:ref=zebra That part as a polygon area area:highway=path cycleway=crossing crossing=uncontrolled crossing:island=yes The last 3 tags could be retrieved from the way! The other parts, where you do not walk/ride/drive. area:highway=traffic_island for the areas. On the polygon way barrier=kerb with no area=yes ( this should mean that the whole island is a kerb, it is not). Greetings Allroads From: Gerd Petermann Sent: Tuesday, October 16, 2018 7:24 AM To: Tagging@openstreetmap.org Subject: Re: [Tagging] highway=crossing used on ways I think I found one reason for the mistagged ways. The wiki page https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dtraffic_island proposes to use highway=crossing + crossing=island to map a traffic island. It says that this should be used on nodes but a mapper looking for a replacement of a landuse tag might miss that. It also claims to show numbers from taginfo for this combination, but in fact it shows the numbers for just crossing=island: https://taginfo.openstreetmap.org/tags/?key=crossing=island This tag can be used on ways, together with e.g. footway=crossing, but that would not be used to map the area of the traffic island. AFAIK taginfo doesn't allow to ask for tag combinations. No idea if this occurs on other wiki pages, if so, it is very misleading. I think the said wiki page should be changed so that highway=crossing is not mentioned at all. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html ___ 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] Opening hours too long for OSM
https://github.com/opening-hours/opening_hours.js/issues/270 Thinking loud, I like a set of subcategories. Basic set for a year, others for the fast change. I find this a practical understandable solution. From: OSMDoudou Sent: Friday, October 12, 2018 5:22 PM To: 'Tag discussion, strategy and related tools' Subject: Re: [Tagging] Opening hours too long for OSM As to improving (thinking out loud here...), .. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcar definition changed recently
It is time to give this twofold meaning a split, into two separate keys. Within openstreetmap it can not have a twofold meaning! The law in many countries also speaks of double tracked or more then two wheels. It is clear to me the new key must be double_tracked_motor_vehicle or short, dt_motor_vehicle, or else, give it a better name. Allready, fitted in the access hierarchy. With a OSM icon (front car) As explained here: https://wiki.openstreetmap.org/wiki/Talk:Key:motorcar All description and structure already indicate that a split has to be done! (includes all double-tracked motorised vehicles when used as restriction) this must be removed. It is unworkable. It is a monster. motorcar=no, meaning else. So many key conditions have to be investigated to find out what is meant by motorcar. if and or...is. I am working on a JOSM test style to express the access on highway and barriers in the road. For control/check reasons, better to see a icon then watch the written key, get the hint, that's why we make maps, make it more understandable. http://mijndev.openstreetmap.nl/~allroads/JOSM/Styles/Road_extended_JOSM_style_info.html A key must have one meaning. If not, it is almost impossible to express the access for one type of vehicle. Where can I ride or drive, where not, where conditional. Why could I not router there. Test site: http://mijndev.openstreetmap.nl/~allroads/mtmworld/?map=agriculturalways=14=49.79228=6.77223=B0FFTTTF Also working on a preset. Translating law to tags. There must be one more hierarchy step, in the lineup to motorcar. We make it hard for ourselves to deal with this developmental error, motorcar two meaning. Despite, what people give as a meaning to motorcar, Openstreetmap have to choose, one meaning, give the others a other key. Working on this style/site, translating traffic law to keys/value, more keys are needed. single_tracked_vehicle, non motorized vehicles, what keyname, see disabled vehicles. Small groups, maybe they have more benefits than others. A better hierarchy structure is needed. So the definition have to be changed once again. Regards Allroads From: SelfishSeahorse Sent: Wednesday, October 3, 2018 10:03 AM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] motorcar definition changed recently On Mon, 3 Sep 2018 at 17:58, Martin Koppenhoefer wrote: Thank you, I have now reverted the change wrt to motorcar. I've also reverted the change on the page https://wiki.openstreetmap.org/wiki/Key:motorcar and tried to make the different meanings of that tag when either used as permission or restriction clearer. 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] Traffic sign direction tagging..
Traffic_sign is on a node beside of above a road. There where, it is. This is the basis, the derivative is tagged on the road, as ... The direction=* says, the facing direction of the sign/shield. Important: indicates the direction in which the law applies. This could be various. Depends on sign and undersign. A combination of trafficsign and undersign is important, it indicates a combined rule, summarized in a value. But there could be more trafficsigns on a node even a highway=street_lamp, the direction=* can not be used. traffic_sign:1:direction=* facing direction is used. traffic_sign:2:direction=* street_lamp:direction=* Then the derivated on the way. This could be the whole way. motor_vehicle:forward=no But also on a node of a way ( not the first and last node) like give_way. The most directly derived tagging is tagging the traffic sign itself. First degree derived tagging. Second degree tagging are the access tags. If you have first degree tagging, the second degree could be controlled, if it is correct. In the Netherlands we started to tag the traffic_sign on a cycleway, then knowing which vehicle key/value is needed Now with overpass we can control if tagging is correct on the cycleway G11 (mofa designated), G12a (mofa mofa designated), G13. This way we get more qualitative data. http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF Then on a waynode. like give_way. C6 traffic_sign. https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring The working-out of the law, says, that goes into effect when you pass the shield at the front. And must be repeated after each crossing. This traffic sign can stand on one side of the road. If you come from the other side, there is no shield, drive in and you visit a house, a plot, or you decide to turn around, this is allowed by law. This you could do, for example 10 meters from the back of the shield, turn around. This place is a like a give-way construction on a node., with access traffic_sign:forward=NL:C6 (first derivated tagging, could used to control the other tags) motor_vehicle:forward=no motorcycle:forward=yes moped:forward=yes mofa:forward=yes some use a 10 meters way to set the tags. forward, indicates the direction of operation of the law in relation to the Openstreetmap drawing direction. `traffic_sign:direction=forward/backward` Here direction is facing direction on the sign. And can not be used a working-out direction of the law. traffic: forward= and traffic_sign:backward is correct. I do not agree! In combination with traffic_sign, direction can only be used on separated node besides the road (or above), given the facing direction, there are signs with undersign with a left or right arrow, indicating in which direction the sign works, then the facing direction must be correct, often this is 90 degrees on the driving direction, or on other side of a T junction. If the traffic_sign (first degree derivated) is not tagged it is almost impossible to control tagging. With all combinations and undersigns. Regards. Allroads -Oorspronkelijk bericht- From: Marc Gemis Sent: Tuesday, October 2, 2018 2:04 PM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Traffic sign direction tagging.. > To keep things simple, we'll do the same thing for traffic signs: `traffic_sign:direction=forward/backward` Please , for doing traffic_sign:direction is better to put direction=* tag. > I still highway=give_way and highway=stop with direction=forward/backward (which is used by OsmAnd AFAIK). And what about the other traffic signs. Are they not important? Why don't erase it...from the World if they are not important? I don't map other signs, for most other signs I map the result on the way (e.g. maxspeed sign, no overtaking). Why would I map the sign separately ? Give ways and stop signs are slightly different, because they usually indicate a single place on the road where one has to stop. The result of the sign is commonly mapped as a node, not as a tag on the way (yes, I know there are cases where a relation might be needed). So yes, for me the position of the other signs is not important. Feel free to add them if you feel they are important. regards m. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
