Re: [Tagging] Straw pole Temperature=objective default unit?
John Willis wrote: If it's 42 f, you'd go into hypothermia almost instantly. =} Not instantly, it's a popular hobby in some countries to swim in a hole in the ice. Look up: http://en.wikipedia.org/wiki/Winter_swimming Assuming c unless explicit should be enough for mapping. Agree. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
Greg Troxel wrote: Bryce Nesbitt bry...@obviously.com writes: https://www.openstreetmap.org/#map=17/37.64529/-118.97450 There's a big difference between transmission and distribution. Those may be US terms, but I think the concept is pretty universal: there are fairly high-voltage pretty serious lines connecting generation and substations in towns/etc. and then a network from teh power=minor_line renders already and describes these better. Physically smaller things than those thicker wires on big towers with long spans and high voltage. -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
Jan van Bekkum wrote: There are two fundamental approaches to this and I believe that in this discussion the two are mixed: 1. The physical status of the road is described 2. The tagger determines how hard it will be to use Over the years, I've seen the different assessment ideas and tagging ideas on the wiki and on this list. I believe these try to integrate too many variables into a single grade; and measuring 30 different physical characteristics is also too slow and quite hard for the consumers trying to calculate if they should suggest using or avoiding that way for any given transport mode. So far, nobody has proposed what I have come to think would be the most exact and most usable bit of information a _mapper_ can provide: Did you get through with transport mode x? Possible answers are: - no - just barely - with extra effort/concentration/some difficulty - yes What constitutes some difficulty for each mode can be discussed more easily; i.e. for roller skates (never have) ruts, sett, tram tracks(?), but not curbs as such? These can be tabularized in the wiki later. If you're in a regular sedan, you can steer around the potholes and slow down (i.e. concentration), but if the wheels have to follow a very narrow path or the bottom of the vehicle would hit the ground, it's just barely for regular sedans. Or whatever local conditions the mapper comes across. Surely, if the track is just barely traversable in a highly modified off road vehicle of brand Y with extras from brands Z and W, the driver of any other vehicle can assume they won't be able to use the track. I haven't drafted the actual tags in detail, but I do have used - police:mondeo=yes (originally as here I saw a Mondeo use the footway, but later also I've seen other vehicles drive here or it's obvious a normal car could physically use this) - police:mondeo=no - police:transporter:conditional=no @ (winter 2wd) ( as in here I saw a VW Transporter fail to get up the incline on a footway) The keys for a more general suitable for use tagging would have a prefix, a separator character (probably ':'), the general vehicle category possibly followed by more details (either a model, or something like high clearance), and the optional accessories would use the :conditional syntax. known_suitable:motorcar = barely known_suitable:motorcar:911 = no known_suitable:motorcar:high_clearance = effort known_suitable:Range_Rover = yes The first driver can always add just the one tag that applies to their vehicle. This might seem like a lot of work, but we have time, and mappers; enough data will accumulate with patience. -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways
Now that the arguments on both sides have been repeated a couple of times, I'd like to offer my solution; me and some nearby have been using this for some years already. First, I believe, why the points mentioned are incompatible: There's two ways to look at the keys (not just this key): 1) anything with railway=* is some sort of railway right now; the humanitarian map layer seems to consider the key like that, every way with railway=* is rendered equal. If the track is abandoned, the soil and right to use the land is intact, and new tracks could be laid down relatively easily; not a usable railway, but a big portion of the structure is still there. In this case, a railway=dismantled is internally invalid; it's no longer some sort of railway right now. 2) things tagged with the key railway are somehow intrisically related to the rail tracks; signalling, water points for steam locomotives etc. The same viewpoint is used sometimes even with the key highway: highway=street_lamp is not a highway, but it was considered so essentially related to the highway, that it would have been possible to just fetch all objects with highway=* to have the important parts of the highway environment. Even barrier=gate's were highway=gate in the beginning. If one uses this viewpoint in all their interpretations, the former course of a railway, even if only verifiable from old documents, is somehow related to the current day rail network, i.e. belonging to the key railway=*. Neither of 1 and 2, above, are always correct. I have some insight on bits of old track in urban environments, so I'll use them as examples. Near me, there's a straight opening in the wood, somewhat elevated from the surroundings. There's no visible path on it, and there could be buildings on it in the future. The rails were removed in 2000, and one might find some remains of the auxiliary structures. Clearly, a railway=abandoned on that section. Where that track used to connect with the present day tracks, a road for buses only was built in its place (in the center!); the old railroad bridge even remains standing as a part of the road. The tracks were actually left behind for several years, and it was changed from disused to abandoned just last summer: the embankments, cuttings and the layout still remains. Near the cemetery, a long straight cycleway across some fields etc. turned out to have been built on a former railbed. Only where it crosses a small stream, one might be able to visually identify the past. None of the other cycleways in the area are that straight, and the orientation of the straight seems out of place; the fact that it was a railway is great knowledge. Elsewhere, there's a long curved cutting in the rocky hillside near the former harbour. The curve turns out to be such because a freight rail track used to run there 60+ years ago; for all I know, the curve is likely to stay in place for decades. In the city center, there's a building with an exceptionally high loading dock, because the building used to be harbour warehouse with a freight track for loading and unloading right where the present day sidewalk is. As long as the building is standing (and it's likely to be protected, if it hasn't been protected already), there are visual signs that there used to be a railroad. moltonel 3x Combo wrote: railway=abandoned without glancing at the satellite imagery (no, Also, if an abandoned railway has evolved into something else, then it's not an abandoned railway anymore. If you add a highway=cycleway The solution: Tags are cheap. I have mentioned the idea in the past, that when any feature is removed because it was destroyed, one could first prepend was: to every key, set end_date=*, upload to server, and only then delete the object from the database. That way it would be at least stored somewhere that the object was removed because it no longer exists. Hidden in the full history dump, but it didn't vanish without a trace. Some have used the prefix historic:, but I prefer was: because it's shorter, clearly indicates it no longer is that, and is almost at the end of the alphabetic sort order. Extending this, when there's nothing left of the rail track, change railway=rail (or railway=abandoned/disused) into was:railway=rail (or was:railway=abandoned etc.), set end_date if you know it. Now, it doesn't anymore try to claim it's a some sort of railway right now - it's not tagged railway=* anymore - but it conveys the past, no matter whether the relevant parts of the ways are reused for footways or whatever, or whether the ways run through a void. If the area gets extensive reuse in some other form, and the ways get in the way of editing, the next editor might remove them. If not, they don't then do no harm. Elsewhere near the center, a cycleway was built in a deep trench, right where the tracks used to run; the existence of the trench can be explained with one or two simple tags on the cycleway: *
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Tobias Knerr wrote: The odd one out is clearly that introduction of the Key:maxheight page. And that also used to clearly state that the key refers to legal limits, until this edit: http://wiki.openstreetmap.org/w/index.php?title=Key%3Amaxheightdiff=806806oldid=762233 The history of the descriptions is scattered among several pages, including at least: Key:access Key:maxheight Map Features In 2006 (17 March), the original Map Features listed these tags as table rows: Linear, Restrictions, maxheight, Num, height limit in metres and so on, linking to the Key:access page. Created on that same day in 2006, the original Key:access read just Section General statutory restrictions and later changed to Size and statutory restrictions, included all max* and min* keys, i.e. also maxspeed and minspeed, The restricted width limit in metres, eg 2m / The restricted headroom limit in metres, eg 2.5m Even the page introduction didn't refer to legal accessibility. Later the infobox one sentence description was written as who may access an element, and this was changed on 10 July 2008 to the legal accessibility of ..., here: http://wiki.openstreetmap.org/w/index.php?title=Key:accessdiff=122326oldid=122039 The examples of maxheight / maxwidth, a couple of lines above this, were changed only once, on 22 June 2011, link below, and are still ambiguous for the outcome of this discussion: the maximum vehicle height is 2.5 meters - this doesn't refer to physical nor legal. http://wiki.openstreetmap.org/w/index.php?title=Key:accessdiff=649233oldid=649213 The page Key:maxheight at first (April 2008) just redirected to Key:access, and the legal bit was added on 31 July 2009: http://wiki.openstreetmap.org/w/index.php?title=Key:maxheightdiff=prevoldid=312926 This edit summary does refer to some recent discussion in talk-mailinglist for the change. It IMO comes down to the different views of two starting points for the modelling: 1) are you legally allowed to crash a too tall vehicle to the bridge, if there's no height limit sign? 2) which is more important, the existence of traffic signs or whether a driver of a vehicle of height x can use that section of the road. No matter what one answers to these, the keys *:legal= and *:physical= are explicit. And mappers can measure the clearance, e.g. with an ultrasound distance meter, even when it's not signposted. If there's (I seem to have written these with maxheight, but the statements apply equally to width): maxheight:legal=x, maxheight=x, one knows that x is a signposted limit. maxheight:legal=x, maxheight=y (but y is smaller than x), then one knows there has to be something physical preventing taller vehicles passing maxheight:legal=x, maxheight:physical=z (and z is larger than x), then one knows there's a sign, but even taller vehicles could get through if they have a permission, or other right to disobey the sign. maxheight:physical=z, maxheight=y (where y is smaller than z), there's presumably a sign with the value y. maxheight:physical=z, maxheight=y (where y is larger than z), there's presumably a sign with the value y, but it's wrong and a tall vehicle could hit the low hanging barrier. On a related note, regarding the fact that when turning, the physical maximum width depends on the length of the vehicle: road planners have the concept of a design vehicle which roughly corresponds to the largest allowed vehicle in that vehicle category, and the turning radius such vehicles should be able to achieve. So a tag maxwidth:physical:hgv could describe how wide such a vehicle could be to be able to navigate that curve, supposing the other attributes of the vehicle would correspond to the design vehicle. That leaves a lot of cases undefined, but could be a start. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Martin Vonwald wrote: My understanding so far: * width: this is the actual width of a feature * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature * maxwidth:physical: according to the wiki page: a physical limit The width of the vehicle that could use the way can be wider than the way itself, even if it depends on the conditions whether they're allowed to. For an example, a way in a park might be, say, 2 meters wide, but if there's just grass around it, a maintenance or construction vehicle or what ever could use that way even if all wheels don't fit on the intended surface (supposing the soil isn't too soft). Or a cycleway; the asphalt is 2.5 meters (width), but if there's no guard rail, a police van can use it even if they're wider than that (with mirrors included) - but if there's a guard rail on one side and a hedge on the other side, the physical maximum width could be just 2.6 meters (numbers off the top of my head.) Another likely case is when the width of a gate is, say, 3 meters (the whole structure), but the gap between the sides is only 2 meters: width=3 + maxwidth:physical=2 Less likely cases could be a road with trees next to it, such that the road is 6 meters wide, but for a section the branches limit the physical width usable for vehicles to, for example, 4 meters. Or a divider on the pedestrian crossing limits the physical width of passing vehicles to x meters, yet the road is more than 2*x wide. I haven't looked up if the maximum legal width sign refers to the actual width (with mirrors etc) or to the width stated in the vehicle's registration documents. Nevertheless, a road with a width of 2.6 meters (e.g. a narrow old town alley or a courtyard entrance) may, or may not, physically allow a vehicle with a width of 2.55 m + mirrors to pass. It's true that good example photos would be a nice touch to the documentation. Considering the possibilities of different special loads, with the transported object surpassing the width of the vehicle, should IMO be beyond the applicability of these tags as such; a 4 meter wide load supported 2 meters above the road surface could or would, for example, just go over the pedestrian crossing middle island traffic signs, whereas a four meter wide harvester couldn't navigate that location at all. I don't yet have an idea how that should be best spelled out in the wiki. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
Volker Schmidt wrote: I am very cautious about any of this kind of measurement for the following reasons: 1) the results will be very difficult to standardise 2) the effort is far beyond that what a mapper can reasonably do. Oh well, I guess I'll have to write a comment here, because I recently finished my master's thesis on a related subject in street lighting research. While I wrote this message in parts on several days, there might be some repetition in it, but I hope the ideas are comprehensible. As a background, the eye requires a constrast between the target and the background before the target can be seen; the contrast can be in the colour, or in the luminance, or both. The eye also adapts to the prevailing luminance level; there's no exact model to predict the adaptation luminance given any scene, but the models of human vision take the adaptation level as a starting point - most scientific experiments have used a constant luminance background and a sufficiently long adaptation period (5+ or 20+ minutes) to fixate the adaptation luminance. The road planners have several lighting classes, which apply to different types of roads and pedestrian environments. The classes are not globally identical, but the basic ideas behind those classifications should be roughly similar. Generally the lighting classes set minimum requirements for the average illuminance or luminance on the ground, and a requirement for the evenness of the measured value, and possibly limits for measured glare. Sometimes there is a requirement that in the area next to the road the luminance should be a percentage of the value measured on the road. Some countries require that pedestrian environments fulfill some luminance condition on vertical surfaces, too, and some lighting classes might require or favour sufficient colour reproduction. These are the measurable quantities, and they are quite well predicted already in the planning phaze. When the lights get older and dirtier, less light reaches the road surface, so the new installations typically exceed the requirements. Lighting installations might be up to 40 years old, but some have been replaced earlier. The expected lifetime is often 15 to 20 years in the planner's operating cost calculations. In practice (assuming conditions found on normal roads, i.e. normal cost-optimized installations) the amount of light and the lack of glare are the most effective predictors for the average assessed quality of lighting. On ways used for vehicular traffic, glare seldom is an issue (but for example some early LED lights had a glare problem). There have been numerous studies, and they have compared the users' assessments to other attributes. When the test subjects are pedestrians, things like perceived openness of the area, emphasising the natural elements in the area with the lighting, perceived (lack of) options for escape and the ability to recognize other people's faces/intentions correlate with better lighting - and lighting can improve users' perceptions of those nonlighting attributes. Nobody has proposed a concrete model which could predict the perceived quality with all the recognized parameters. Such a model would require, for example, knowledge of the local living conditions and people's expectations of personal safety: there's a huge difference in what primes people into fear, between crime ridden environments and countries where street crime is very low. Measuring the road luminances is standard practice. They used to have to position the measurement device at regular intervals for measurements, but nowadays they use calibrated digital cameras with special software and do the measurements for a stretch of road surface from one picture. The officially acceptable devices cost more than your average DSLR camera, but from what I've read, the results could be sufficiently accurate for this kind of tagging. The problem is then that the road has to be empty, the tail and headlights of other vehicles would distort the values, and that to get comparable results the street has to be dry and the height needs to be constant; the road surface isn't a totally diffuse reflector (and wet surface even less so) so the values depend somewhat on the angle between the viewing direction and the road surface. The measurement grid has to be manually positioned over the picture, to get a standard sample between and of the whole area between two light poles. If, on the other hand, one were to measure upward, i.e. the mobile device measured the amount of light reaching it's light sensor and not the luminance of the surfaces visible in the camera, there are other hindrances. The sensor basically integrates over the half sphere space angle (or a smaller aperture), and the user holding the mobile phone blocks a significant portion of that; the old method for road lighting measurements had the persons doing the job walk away from the sensor
Re: [Tagging] Tagging Digest, Vol 62, Issue 14
Warin wrote: highway=track is wider than highway=path, tracks being useable for at least one 4WD, So their width should be say 2 metres? The first sentence is a common misstatement. Although track requires enough width for four wheeled vehicles, this does not mean path (or footway, or any other) could not be even wider. Even most proper cycleways are much wider. Tracks just can't be narrow. The original meanings were footway: you can* and may walk here - it looks and works like a way for pedestrians cycleway: you can and may cycle and probably walk here - it looks and works like a way for cyclists, or a combined cycle and pedestrian path * can for some common sense meaning of does it look like it's a way, excluding say open areas of grass even if one may walk there (look up duck tagging in the wiki) for path all we know with absolute certainty is here's something nonmotorized users may use, look at extra tags to be sure which, and if it's a built way or an informal trail in the woods. But we've learned to live with that. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] what does maxheight=none mean?
Personally, i use maxheight = x + maxheight:physical=x for these, but saying that signs are the only thing that can be tagged gives bad data. You may not collide with a bridge, signed or unsigned. Ultrasound range finders can sometimes be purchased for under 10 euros, so without a sign there may still be a real maximum possible height for a vehicle passing under that - bridge or any other - construction. In most countries, no sign should only guarantee that a vehicle under the local legal limit can expect not to hit any permanent structures, unless they have signs. Should, but not necessarily would. Statements to the effect that any tags can only refer to signposted limits do not represent the original usages of the tag - only some access tags referred to legal accessibility. -- alv Lähettäjä: Friedrich Volkmann [b...@volki.at] Lähetetty: 25. lokakuuta 2014 0:29 Vastaanottaja: tagging@openstreetmap.org Aihe: Re: [Tagging] what does maxheight=none mean? On 24.10.2014 20:53, Tom Pfeifer wrote: I stumbled over some maxheight=none tags on motorways, that did not even pass under a bridge. I found that this is the most frequent value of maxheight (2889 of 41474). [...] For bridges without sign, there is no recommendation in the English wiki, however the German wiki proposes maxheight=unsigned (290 uses), also used is maxheight=default (303) and =unspecified (2). I would recommend to add maxheight=unsigned to the English and other wiki pages, and list maxheight=none as incorrect tagging. I don't like either of these (maxheight=none/unsigned/default/unspecified), because we should map what we see. If there is no sign, there is nothing to map. Applications can make their assumptions on their own. Please remove the nonsensical and nonstandard maxheight=unsigned from the german wiki instead of polluting other pages with it. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ 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] Suggestions for the correct tagging of Field borders
Simon Wüllhorst wrote: I was a bit confused about the inconsistent usage of landuse and natural tag. Sometimes it’s not clear why there is used the natural or landuse key. Landuse and natural tags have different keys, so that you can have both; they describe different properties. It's just that often or sometimes some landuse values virtually always imply some natural elements within that area, so we don't even bother tagging them. E.g. farmland is just landuse=farm, without natural=wheat or similar, or a landuse=quarry is without natural=bedrock or similar. For forrest you have both (landuse=forrest and natural=wood) but it seems to be the only one where you can decide whether it is managed or not. The forest vs. wood is a bad example anyway, since years back somebody made a mass edit and nobody noticed back then that you can have an area used for forestry (landuse=forest), that doesn't have trees (natural=wood) in it for several years; when the area has been clearcut / had a full chop recently. I.e. the combination of tags is not redundant, which was the only reason given for the changes back then. The original way was to use natural=wood with landuse=forest, or by itself; many still use them like that. So, for the field borders, one could pick any or several out of (at least) the following: * natural=scrub * natural=grassland * landuse=meadow (meadows exist that aren't for hay harvesting) * natural=meadow Even other tags may be suitable, depending on local ecological conditions. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access tags on areas containing highway=*
bulwersator wrote: In my opinion all relevant access tags should be on way and its nodes, otherwise it is unclear whatever road inherits access data from area. Yes, and it shouldn't be a goal to inherit access tags from surrounding areas. Even if mappers would consistently set layer=* on the way with the access tags, the one encircling that area, so that it would match the roads' layers, it's far too easy to have a bridge or anything inside that should, or shouldn't inherit the tags. Likely not on the proving grounds, but elsewhere. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] surface=ground/dirt/earth
David Bannon wrote: Should I use this road or not ? tracktype= does claim to use that approach It's a shame that we, the community, don't excel at documenting. The part about how well maintained on the Key:tracktype page was added later after the values. There is a connection, but tracktype wasn't meant to be about usable or not, but about the most influential attribute of the road construction (or lack of, among the easily observable attributes), of all the attributes that are involved in shaping the conditions road users see on any ways not up to the highway standards of the present day. So it's a description of a scale from hard materials only to soft materials only. The connection to maintained is variable and complex, but usually the grade is also a good approximation of the maintenance, but there can be, and there are, exceptions. One does not usually(?) maintain a road made of soft sand only, but a track on exposed solid rock is hard materials only even if nobody ever raised a finger to build the way. A user can deduce expectations from the combination of surface=*, tracktype=*, their vehicle, season, and local weather - and in some cases, even smoothness=* if the rocks, roots and potholes prevent some users. There can not be anything beyond soft materials only, that's quicksand. If many mappers have actively used the tag to describe their assessment of should i use or not, the meaning of the tag has diverged from the use in other regions, and we'll never know which one was meant. (Luckily, there's seldom any major difference - it's probably be the rare extreme cases that can be in disagreement.) If mappers want to tag a subjective should i use it, it should be some other tag if the hard/soft materials scale doesn't suit them. But for which road user? -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Landuse=civic_admin
johnw wrote: Martin Koppenhoefer wrote: there is a lot of stuff that isn't yet covered by the well introduced landuses, including: And somebody mentioned landuse=institutional at 68 uses. There's 332 cases of landuse=civil, which we have used for areas and plots used for state or municipality functions that don't fit in the industrial or commercial uses. They (civil features) don't exist to produce income (even if they somewhat do) so the commerce part is missing, but they exist because the society has deemed that it's necessary to make the things that they do happen; like kindergartens, hospitals, state ministeries, city offices, environmental agency offices, churches; and they don't exist to process or refine materials, or construct or physically maintain objects, like depots or the like (industrial). IMO normal commerial activies involve the assumption that the work people do there leads to something getting sold. The choise between civil and some other words is hidden somewhere in the wiki, but if i remember correctly, in the end civil was proposed by some native English speaker. until now, most of these simply got their specific tag to say what they are without any landuse. One can assume, that most areas tagged as leisure=* are silently implying landuse=leisure, and, say, amenity=school implies landuse=education - if that's a zoning category used in that country. If they're used to zoning them differently, the local consumers can map the tags like amenity=school to their zoning style. At least here the zoning plans include areas reserved for common functions; usually the zoning also allows commercial use, so if there's enough private entity interest, they don't have to rezone the plot. theatres and cinemas, restaurants and nightclubs On these, if on they have their own area, I'd go with retail or leisure. Of the mentioned cases, the following are imo clearly landuse=civil: -courthouses -Jails Prisons -parliaments and city counsels (and the levels in between) as well as supranational decision making -hospitals and clinics (here most of the private ones are inside a otherwise commercial building, so they wouldn't count) -public administration (with and without public access) -public services like police, fire, , border patrol, immigration, park ranger stations, customs areas -universities and schools and colleges landuse=Industrial -plow stations landuse=leisure: -skiing park, zoo, theme park, or other tourist attraction. -sports related areas Naturally, one could add the subtags as proposed with landuse=institutional. -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an imaginary oneway barrier
Martin Vonwald wrote: 3 Cut the way where the sign is into a tiny piece of way. Add a motorcar:backward =no to this tiny piece of way. That variant has been used in my area. The tiny piece is usually the part from the junction up to where the sign is located. This is the oldest common simple way to mark these. Vehicles have length and can't turn around without moving forward at least somewhat (save for some machinery), so there's always a short section of the road, where the affected vehicles can't be moving in the forbidden direction. If they were moving in the forbidden direction, they would have had to pass the prohibition sign; straight up or during the u-turn. That short section is effectively oneway (for all, or some vehicles). I didn't take note who argued that the short section represents something virtual, so I say my point here: The tiny piece as described above is no more virtual than the other ways that meet at the junction. The fact that the osm ways, if they were extruded into areas, form overlapping areas, is just a consequence of the data model. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an imaginary oneway barrier
Bryce Nesbitt wrote: does not represent what's on the ground: there won't be a one way street sign. Dual carriage roads don't have one way signs, either, but the parts have oneway=yes. I just noticed that the relatively recently changed description on the Key:oneway wiki page is even wrong because it tries to set the requirement of a oneway street sign. It's the effect traffic on this way may flow in one direction only, not the signs, that are more relevant to most use cases. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag covered questions
Johan C wrote: As often, it depends on the definition :-) : A tunnel is an underground passage for a road or similar. http://wiki.openstreetmap.org/wiki/Key:tunnel People use the word tunnel (or their equivalent word) in different countries in various contexts; many times these do include all or most passages through anything, when they are narrow relative to the length. It's then only natural that they use tunnel=building_passage or even tunnel=yes when they map these, totally without any regard to whether some engineers or geologists or encyclopedia editors have restricted the use of the word in their field in English to only under ground level tunnels. -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - trafficability
Anectotal evidence: while driving around Iceland in a Suzuki Jimny (technically a 4x4), I would never try to tag that half hour of prose into an OSM key. Would it not benefit the next driver to know somebody in a (stock) Jimny got through - or didn't? Even for those driving something else. The number of roads with limited get through is relatively minimal, so it's not even a space issue. Somebody used to say Tags are cheap. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
I propose to move psv (including taxi and bus) from the vehicle classes section to the section by use, because that's what it is. I agree. (Usage, that relies on the current hierarchy should be limited to non-existent) Country differences again. Around here (Finland) all signs(* refer to just vehicles registered as a bus, even those that allow buses and taxis on their own lanes. Effectively nobody would try to use a personal bus anyway, because the extra running costs, costly and time consuming extra driver's licence, and difficulties in finding parking spaces would totally kill any time gains one could get from using bus lanes. I'm quite certain there are other countries, too, where the general reference to bus means and should mean all bus vehicles. Until October 2009 psv used to be described in the wiki with e.g. buses, not i.e. buses and the GB dwellers had to repeatedly explain that it's a term they use to mean both buses and taxis, with nobody stating just official transit buses on their route. At the moment, as the descriptions are, there's no tag that states vehicles registered as a bus, some have narrowed the 'bus' tag down to denote a bus acting as a public service vehicle only. *) I've seen only a few exceptions, signs stating something like no left turn, except line NN buses -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags useful _SUMMARY_ for rendering of roads in poor conditions
Tracktype= has about 2.5 million grade2 and beyond ways. Tracktype is a measure of how well-maintained a track or other minor road is. http://wiki.openstreetmap.org/wiki/Tracktype Having now read through the messages, I find that nobody has mentioned a thing about tracktype, as it was initially described and used; and how the values are still described. Even if there's usually a correlation (even a strong one), it's not directly about how easily some vehicles can get through, but about the mixture of hard materials and soft materials. grade1: just hard materials 3: roughly 50/50 mix 5: only soft materials What's beyond only soft materials, foam? And true, in this some surface= values are impossible with some of the grades. Many extreme_4wd_only rocky ways could be even grade2; it's the clearance needed and the inclines that set their limits, not the mixture of soil present. Likewise, that golf club grass footpath may well be grade5. But maybe the usage has overruled the strictly physical characteristics that it used to describe and the values are used for all sorts of different ideas? If so, then this is again a case where the community failed in documentation back in 2008, or sometime after that when the pages were subsequently improved. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Topographic place names
it won't be a clearly defined border where some meters more or less matter or are clearly definable IMO one can always ask the locals/local geologists is this location/point a part of the mountain/mountain range. At some point, everybody agrees that it is, and somewhere further down the slope everybody agrees it's not. It doesn't matter much where - between those points - the way is. That's still usable data, and it will getter better as more locals edit it, to refine it and to add smaller details. And they'll soon be multipolygons because the way length limit will often be exceeded. However, it would be good if somebody (preferably a geologist by trade, and preferably several from different countries) were to write a nice short summary of the different possible scientific thresholds for where the mountain starts. Then mappers could use a more specific tag to say which kind of boundary they were drawing, before we have ways denoting areas constructed from significantly different attributes. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
when access=destination already exists for exactly this situation. Besides the other arguments about other users already mentioned, the value 'destination' would not work in practice either. For all we know, routing algorithms currently used don't work like a human brain, but they handle destination limits differently. When the algorithms go through the routing graph, they notice the relevant tag with the value 'destination', and thereafter refuse to consider any segment that does _not_ have the value 'destination'. Once you enter a destination only zone, you must find the destination before you leave, otherwise you would be going through. (Also, if the route started in a segment with the value 'destination', this only starts when it first gets to an edge where there is no longer a relevant tag with the value ''destination'). The bicycle=destination tags could not be flood filled to nearby roads without a parallel cycleway (there's no cyclist no through traffic on them). Likewise, if the tag is not flooded, there is in most cases a long detour to get to said tag flooded road without going through the original edge which would have been suggested to be tagged with bicycle=destination; then one would get a long detour route, because it avoids the bicycle=destination bit (even with a better-than-common-practice handling of the value 'destination'). -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
What's the difference between road: you may not cycle, cyclepath: you may cycle and road: you may only cycle on the cyclepath, cyclepath: you may cycle? Because it's not road: you may only cycle on the cyclepath, but road: you may only cycle on the cyclepath if the cyclepath is going where you're headed The =use_cycleway / restricted value is closer to destination than to no. It's however with the significant difference that in these cases the destination is not anywhere along either of the tagged ways, but the road is sometimes needed for, like, turning left or right at the next intersection, i.e. the cycleway diverges away from the road before the next intersection, or does not have a legal crossing point at or before the next intersection. There might be a longer route available, by first going along the cycleway somewhere, and then approaching on the road from the other direction - or not. The first best example I found was like this intersection: http://osm.org/go/0xPnBw03o-?node=27254468 When driving east, a cyclist must always use the cycleway on the north side of the road, there are obligating signs after each crossing. However, if turning south at the next one(*), they may use the road. A cyclist driving the road all the way to the eastern end could be fined for not obeying traffic signs, in theory anyway. If the whole road Tattarisuontie was tagged bicycle=no, there would be no way to get a cyclist routed to the Jäähdytintie road southward - beyond a long detour. *) There's a phrase in the relevant paragraph: may use [conditions]... for a short distance but nobody knows what is short. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
2) if the cyclepath is going where you're headed, you are obliged to use the cyclepath, to the exclusion of all other carriageways I think number 2) is intended here? Yes, the original was an unreviewed sentence. In the original the if only applies to only, not to may. Normally in routing, the slight preference given to cycleways for a cycling route should weed out the driving on road bits with a parallel cycleway, but because the difference in the edge costs can't be too radical, without the information these tags under discussion try to convey, there are bound to be cases where one either gets illegal routes when the cycleway is somewhat longer, or long detours along cycleways if the edge cost for roads is much higher than the cost for cycleways. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Waterway river vs stream.
Using if an able person can jump it as the rule has some issues. How far Not only that, but as it was described years back* (Maybe you can just jump over it. from January 2008) did not seem like a hard set rule, but like a soft description. * http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dstreamoldid=69266 That's how I read it, and I'd be inclined to believe that's how many who don't speak English as their native language would read it: - If you can jump over it, it's probably a stream, but not necessarily - If you can't jump over it, it's more likely a river, but it might still be a stream - Locally prevalent mindset will have an effect on where the line between a river and a stream is set. Around here most, if not all, people would never call many of the non-jumpable streams and ditches rivers, so they would not know to tag them as rivers. A trunk road is bigger than a residential. A river is bigger than a stream. Yet: a trunk road in rural areas may be 1+1 lanes 9 meters, but a residential road elsewhere may be 2+2 lanes and 13 meters plus sidewalks. Likewise: a river in one part of the world may be narrower than a stream elsewhere. When we can't rely on somebody else's authority (e.g. ref for highways), the classification always has some gray areas where local practices use a mixture of locally important attributes to move the line one way or the other. My point being, that these top level classifications with only two categories hardly make sense for globally valid hard set division by one attribute. If somebody has the means and resources to survey and to tag the width and jumpability and mean annual flow and all that, they will come along and add that later. Being a stream in OSM doesn't even tell us with great detail how big it is; a small stream is something you can step over - or even bike over - and a bigger stream might be unjumpable. Is that jumping measured with sneakers and without baggage, or with a backbag filled with a weeks food rations? And which one makes sense as the dividing line for a general use mapping database? * Was three with waterway=riverbank, but even that has been diluted in this meaning as mappers have had time to draw even narrower rivers with the riverbanks. -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
Can anyone state that in her/his country this traffic_sign is official and not made up by some people ? Not my country, but in the UK it's listed here: http://www.legislation.gov.uk/uksi/2002/3113/schedule/5/made Some countries have a blanket allowance for using a text only sign when no suitable sign exists, not just as an additional sign limiting the effect of the main sign, but on their own. From what I read, at least here in Finland a cyclist not obeying any traffic sign could get a fixed 20 euro ticket. (In practice, from what I've seen and heard, they only bother to fine those driving on sidewalks, or past a red light - unless something bad happens, that is.) -- alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
Martin Koppenhoefer: Btw.: What about monocycles? Are you alled to carry a monocycle in these streets? What would the traffic ticket claim as the offence? FWIW, our law has a clause that on a footway a pedestrian may not push a bike, moped, kicksled, ski or skate or carry a big load if it can cause considerable hindrance to others. I've only once seen a dismount sign, it was this year at a combined cycleway on a bridge that was being renovated. Had they changed to a footway sign, cyclists would have taken the main carriageway legally, but because of the circumstances they probably wanted that they'd rather be pushing their bikes on the sidewalk for that 50 meters, than have them wobbling between the buses on narrower-than-usual lanes between the guard rails. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro mapping traffic signals
Pieren wrote: was placed on the intersection node itself. routine engine where routes with traffic signals are penalized. I won't be saying anything about the discussed alternatives at this time, but just wish to point out that this intersection is controlled by signals when used only on the intersection nodes, can't be straight away used as a constant time penalty for each such node. For example, where two dual carriage way roads intersect, (right hand drive) - a route turning right passes one node tagged with highway=traffic_signals - a route going straight goes through two such interesction nodes - a route turning left goes through three such nodes For some even more complex intersections where carriageways are further divided before the signals, the wrong count can be and would be even higher. Even where a single carriage way road crosses a dual carriage, the other road's traffic going straight passes through two such nodes - the other road's traffic only through one such node. I'll let everyone to consider by themselves how the passed node count changes on different routes through the intersection, if mappers happen to move the tags away from the intersection node. This shortcoming exists for all intersections where not all roads are single carriageway roads, in different ways. It always need more data, or algorithmically derived guesses. Only when the intersecting roads are both single carriage twoway roads, tagging the signals just before the intersection doubles the constant penalty effect, if a router uses the nodes blindly. IMO, therefore, this time penalties go all wrong can't be used as a reason why it's always more correct to tag the intersection node. I'd be happy to see someone explain here how their router does something more complex with the highway=traffic_signals nodes. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] telephone lines (and marking other things we don't map)
More generally, should we tag things that we don't normally map, that There's no such existing thing as we don't normally map. People map what is of interest to them. Just use a tag that doesn't already mean something different. FWIW, I've used aerial_line=telephone for such telephone lines on poles. There could something more popular, but I didn't find it. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Lester Caine : This was part of the discussion on tracks and paths at the time. Martin Koppenhoefer wrote: AFAIK that distinction was always made by width Just to be precise, this choise between track/path based on width only works in one direction: something that is narrower than a two tracked vehicle, is too narrow to be a track, so it must be a path, but not the other way round. Most things tagged for example as highway=path + bicycle=designated are much wider. Or even without any *=designated tag. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] road side
connecting the driveways to the road, which they don't The driveways do connect to the road, even up to the center line, just as much as normal roads connect through each other in every intersection. All roads and paths are both: a surface, and a connection. It's an inherent consequence of the osm data model, where roads are represented as ways. There are necessarily areas that fall within the width of several different ways. Even in practice, you couldn't park right in front of the part of driveway on the private property, as you would be said to be blocking the driveway (regardless of whether parking is allowed anywhere within that example area). The connection that must not be blocked, exists from the plot boundary to the road lanes. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - Power transmission refinement
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement - Power lines refarming with power=cable deprecation. Power lines refarming does not at all sound like what it is; diluting power=line from current usage as a big visibile structure with towers and cables up in the air to just about any linear power conductor, even if it's invisible underground or in bottom of the sea - in addition to the big things as it used to be. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
In the UK, the most common weight restriction is '7.5t except for access'. Which doesn't answer the question, so I had to do some digging: no sources seem to mention any traffic signs in the UK that would limit the actual laden weight - only the what's-in-the-papers-maximum is used. Which seems strange, since the signs even refer to goods vehicles only, but a weak bridge does not care what sort of a too heavy vehicle is about to cross said bridge. surely its simply a hgv tag, or a maxweight tag Just yesterday I found a nice example bridge (far away from where I usually roam) with all sorts of weight limits (I can only later try to extract the video frame(s) with the signs). At the previous intersection there was a sign (freely translated as) no entry for goods vehicles with a maximum mass of over 3.5 tonnes. That does not affect for example buses at all. Right after that, there were signs maximum axle load 8 tonnes and maximum bogie load 13 tonnes. Then, just before the old bridge, there was a sign no entry for vehicle combinations of over 32 tonnes laden mass. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
needed e.g. in Finland) or of a single vehicle (needed in most of the vienna convention countries) By far the most common sign is - even here - of the vehicle laden weight variant. Only the max gross weight of a vehicle combination sign does not (legally) exist - here, that is. Implying that we're not following the convention is just... uneducated. It would be best of someone living in the UK atm could check of most of the maxweight tagged ways there are in fact with a traffic sign no entry for goods vehicles with gross weight over X tonnes, or the laden weight limit variant. Regardless of what the wiki example photos show. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
sign does not exclude vehicles transporting people Indeed, yes, I missed the last bit: ausgenommen Personenkraftwagen und Kraftomnibuse Seems strange to put it that way (everything but not X), when they mean Y. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
maxweight:type=gross_vehicle, gross_train, laden, empty, etc. definitions + _weight can be used as properties in conditional restriction, eg. maxspeed=80 @ (empty_weight5.5). Drawback is that only one maxweight-restriction per way is possible. Just today I drove past a sign that means maxweight for combinations (1, with another sign below it, which corresponds to Key:maxbogieload. Different restrictions exist together on some roads, tuet need 1) http://commons.m.wikimedia.org/wiki/File:Ajoneuvoyhdistelm%C3%A4n_suurin_sallittu_massa_345.svg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
(Sorry, the previous message was sent prematurely.) Different weight restrictions exist together on some roads, they need to be different keys. -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
I take it the gross weight item on the driver's license Just to make sure, not all countries' driving licenses directly refer to weight; mine only states the allowed vehicle classes, and I can check the vehicle's papers to see of it's a B or a C. Effectively the difference is still max gross weight under vs. over 3.5t, but there could be exceptions. Therefore, the prohibiting sign with the hgv symbol only bans vehicles registered as vans and hgv's, i.e. not for example buses. Unlike in for example Germany, where that sign seems to refer to (gross) weight only. There are even some vans, that can be registered (when new) as vans or hgv's at will; what the first buyer chooses, affects the recuired driver's license, and the permitted load. (There are probably some tax reasons in there, too, like you may never ever have so called temporary seats in a hgv's cargo department.) -- alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
there are weight restrictions sometimes given as maximum-per-axis-weight, indicated by traffic sign 263 (see http://commons.wikimedia.org/wiki/File:Zeichen_263.svg ), which is similar, but not the same. There's http://wiki.openstreetmap.org/wiki/Key:maxaxleload -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New Proposal
this example, http://osrm.at/36D To stay on the A511 no instruction to turn is given, That just looks like a bug in the osrm. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - More Consistency in Railway Tagging
Martin Atkins wrote: Refine the basic railway=* tagging to have a more specific definition, taking inspiration from the tagging conventions around highway=* . IMO this is flawed in two ways: - on empty highways, one can drive in circles on the whole road surface (not that one may or should, but they can). For anything that moves on tracks, the switches are the only place one can change course. This makes the individual tracks and their connectivity the network, that is the roads they happen to run on are not the network itself. Drawing a single way where there are multiple tracks is not wrong, but it's just an intermediary solution before somebody has the time to add the switches and separate the tracks. and more importantly - there are an abundance of places where the tracks switch from the simplest case in the road to short (or long) bits where a separate way is required ; that is, for example where the tracks diverge from the lanes and a stop platform is between the tracks and the lanes for other motorized traffic. Were the adjoining simple case ways just one tag on the road, you would introduce arbitrary(!) turns and kinks in the course of the tracks. Other variations exist, too. There's an example of such kink in your proposal's example photos, the one where the two tracks suddendly come together when they go into a tunnel. It's easier to go back (in code, that is) from more detailed ways to a generalized display, than it is to reconstruct the actual possible routes and the placement of the tracks if they are just tags on ways that do not follow the course of the tracks meticulously. Tracks shown outside the highway where they are not, is just a rendering issue in one map, at extreme zoom levels. There's already tram:lanes=yes| etc. as an additional attribute tag on the highway way to say the lanes of this highway contain tram tracks, which may well be drawn separately. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed features/Connecting of routes - RFC
Description: type=route - this is a route route=road - this is a route for motorcars network=e-road - this is a cars' route, which is related to E-road network IMO network=* should be read as is a route, which is a part of the E-road network. These connections are not a real part of the agreed-on network, but local roads and links that act as a tool to route between them. Therefore, I'd say it would be better to differentiate these already at the network tag; say, network=e-road_link Also, they exist where two E-roads intersect at a grade separated junction, but the connecting links are not a part of either route relation. If they were a part of the e-road relations, there would also be some other onramp link roads, ones that get traffic from local roads and which are guideposted just as the connecting ramps between actual E-roads. There's less room for random inclusions, when these instruments to routing are a separate network=*, one which osm mappers are constructing on their own. Btw, maybe just a tag would suffice? e-road=A_link - this is a connecting route between two European routes What are A and B class E-roads? Which one should one use, when it's a connection between an A and a B class route? Even if they don't exist now (do they?), they might exist in the future. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] source:maxspeed vs. maxspeed:type
And usually we use the key source for how we collect the data, but not the key source:maxspeed Realistically, to know that there is a speed limit sign, or that there isn't one (i.e. =sign vs. =XX:urban), one has had to visit the place, so source:maxspeed key effectively says the data is from a survey. Some may have used suitable photos or videos showing the sign, or lack of a sign, but still somebody was there to record the surroundings - that is, something akin to source=survey by friend -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Resorts
buffers), I think a landuse= value is appropriate. It isn't residential, industrial, or retail. Probably the same landuse tag is appropriate for a big resort as for a regular hotel. In the beginning it took a while to realize, that the osm tagging system as-it-was-at-the-start omits some tags when some other tag logically normally implies something not mentioned anywhere: leisure=park could imply landuse=leisure leisure=resort could imply landuse=leisure leisure=pitch should (often) be inside an implied landuse=leisure and so on. Why is it so, then, I hear you ask; the answer is that for simple mapmaking the depicted leisure element is more important/will be rendered instead of some generic landuse=leisure tag, which tells us very little about the physical contents. Likewise most don't tag the area with amenity=university with any landuse tag - some do use landuse=civil. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
Martin Koppenhoefer wrote: * natural - geographical features (e.g. a named forest) abstract IMO there's no need to limit the key natural to geographical features only, and never has there been such a distinction. The natural=wood / landuse=forest distinction is flawed and creates In practise some mappers prefer natural=wood where other mappers would set landuse=forest (for the exact same situation). Even some mappers prefer to do it as it was done initially: * natural=wood: here be trees * landuse=forest: this area is used for forestry These are often coexisting, but e.g. the landuse does not imply it's necessarily filled with trees. It's a shame somebody ran a bot edit years back to remove natural=wood as redundant from landuse=forest ways. After clearcutting an area can be both landuse=forest + natural=scrub, or even natural=grassland for some years. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
By consumer, we all think about renderer (which is in my knowledge the only consumer looking for bridges in OSM atm). If you keep the bridge tag on the multiple highways, it is duplicating the information. I believe there's no obvious reason not to think that bridge=yes on a highway could be said to mean is on a bridge (attribute), and not this is a bridge (and a highway) (object). Then, it's no longer duplicate information. So far the tools have just deduced that there must be the (undrawn) bridge along the road, and would continue to do so if they do not bother themselves with the exact shape of the bridge deck. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
there and so on - so: keep them splitted and it's less work with more backwards compatibility. If they are not, it's up to you as a mapper if you want outdated renderers to use the old scheme or not. Most renderers and conversion tools work internally without a database (even if they first fetch the data for the area in question from a database) - many consumers of the data take an osm extract, and work on the ways one by one, one or multiple times, and draw them as such in appropriate order (say, mkgmap included). There's work going on to have mapnik draw the road name labels only once where a road has been split several times. Not by me, but see the SOTM slides linked to on page http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2012/Saturday Parking map – make and break stuff Mappers split ways a lot, for a lot of reasons, so avoiding the split for a bridge and at the same time hiding the attribute in a) other, connected ways or b) a relation only or c) the spatial data seems ... making things unnecessary complex for the consumers. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Ronnie Soak wrote: Several addresses per building: addr:* tags on entrance nodes along the building outline. Just a reminder that in many countries buildings can have several addresses, each address on different streets; none of the addresses is a primary address, and all staircases of said building are referenced just with a letter after any of the possible street addresses. The numbers can be on a separate lamp on each wall, away from any entrances. Which means that the house numbers really have to go as separate nodes inside the building, and each entrance only has the ref=letter on them. Consumers need to support separate address nodes inside the building anyway, for that has been used extensively, so that should not break anything, either. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] agglomération
Simone Saviolo: if you need to tag the maxspeed anyway, then what's the point of that tag? It's not about the maxspeed, but the area that supposed to be considered urban, and interesting in itself. The rural/urban distinction affects other rules, even outside of the traffic code. Here the traffic rule differences are, at least the following: - no honking in urban areas, except in case of danger - no unnecessary(!) driving in urban areas - no parking on marked priority roads in rural areas. - in rural areas, only marked junctions (guideposts or a traffic sign) forbid overtaking - different rules for lights in parked cars - stricter rules about distances between slow vehicles in rural areas Examples of non-traffic implications include - dogs always on leash in urban areas, and one must collect the poop (with conditions). - (disruptive) drinking forbidden in urban areas - smaller traffic signs allowed in urban areas, with less spacing between them, and between them and the road Even the state funding for municipalities depends somehow on the population within the urban area, among many other things. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] agglomération
The idea is that with a 30 driving rules list applying to an agglomération If it's just the traffic rules urban vs. rural, there's the tag (with 37 000+ uses) zone:traffic=**:rural zone:traffic=**:urban where ** is the two letter country code. Don't count on anything ever deriving the rules (like maxspeed) from that tag, so tag the maxspeed anyway. If, on the other hand, it's about the area that is considered agglomerated, irrespective of the (not) implied traffic rules, there are probably/apparently different rules in every country for calculating the area, for example by buffering all residential buildings and combining the area formed by that operation. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access=emergency revisited
specifically, no U-turn is the common signage in many jurisdictions, and that's a turn restriction, not an access restriction. in a perfect world, that's how we'd have Mostly we are interested in the result, not the signs. It's the traffic code's limitation, that their best option is to forbid the turn, but the result is the same: generally nobody may use the u-turn connector, but emergency vehicles can. As for overloading, is there an imaginable case where a way tagged highway=* acts as an emergency=fire_hydrant, or any of the other values listed? Afair, the key emergency was first used as an access group, and the emergency facilities were only later grouped under a single key. access=emergency Emergency vehicles are a by use category - as the Key:access page refers to them. It's better as a key. Here some effectively pedestrian ways into apartment building yards are signposted as a (literally) rescue road - that's emergency=designated. It doesn't by itself stop anyone else using it when they need to haul something heavy, but the signs make it clear to anybody that parking there will block the fire engine/ladder car from reaching some houses. (There's a no parking icon included in the traffic sign to make it understandable even for foreigners). -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Stop sign?
Can we start using relations for this already? Really seems like that provides the specifics we want for this. So far nobody has provided a real world example of a place where the simple distance-to-next would not be correct. If somebody does that, then a relation could be made up. highway=stop As a node on the way, where one must stop. traffic_sign=stop As a node at the exact location of the sign. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
Only part 5 is relevant. Having just returned from my (mapping) trip, and having finally browsed through all these messages on this subjet, I don't think anybody mentioned it explicitly: You can't consider only part 5. At part 6, the ways are physically separated, so IMO there should be two separate nodes on the 5 - 6 border. With two nodes there, the transition from one way (part 4) two two ways happens during part 5. Often, but not always, before the physical separation begins, the solid line is of convenient length for said transition. Assume there is no physical separation just a double line between the upper and lower two lanes. How would you tag this: a) One way with lanes=4 b) Two separate ways with lanes=2 each c) Tell me! Depending on the length of part 5, fully b, or if it's a really long part, first as one way, and as two ways from the point where one or both of those ways' angles match the angles of the ways in part 6. Where I'd draft the definition of match as equals, or makes a bit shallower or a bit steeper angle with the orientation of the part 5 carriageway; this is to say no abrupt right-left-curves, but don't do separate ways at the start of a long decelaration lane either. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
I don't like the lanes tag where there are no lines on the street, it misses the point. It completely misses the point! The lanes tag should only be used for lanes that are somehow marked - usually with lines. There are an abundance of unpaved, 6 to 8, or even 10 meter wide roads that must be called two lane roads, but will never have painted lane markings; any painted sand/gravel would get smeared really fast. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarify tag access doc
Rob Nickerson wrote: Although I don't know the history of the access tag, I would expect that designated and permissive might have something to do with Public Rights of Way in the UK: Just a recap on how the values have evolved, not to open the path controversy, but just to give some background: 'Designated' is a result of the path controversy. Back in 2008, or thereabouts, there was only yes, permissive, destination, private, no. Permissive is (originally, in the OSM sense) a UK thingy, as it seems to matter there. Back then very few used the tag designation=*, if any. Apparently, it's easier there for a land owner to legally limit outsiders from using any road on their property (no matter how big), unless it's legally designated as a public highway (or any of the other designations) - in other words it's a right of way, as it's described at Key:access. There was no need for designated or official; either - you have a right to use a way, or - the land owner has given a general allowance for anybody, or - you have a right to use a way, but only if your destination is along said way, or - you can use the way if you really know the owner allows you specifically to use it. This was thought to be sufficient for any case. When some non-UK mappers felt that highway=cycleway + foot=yes somehow prefers or favours cyclists over pedestrians, they suggested highway=path. x=designated was originally meant solely to record _for which users any such highway=path is_ (where x=foot/bicycle/snowmobile/hazmat/whatever, but not access=designated). Generally this is always somehow signposted; if it's not signposted, the way looks and works like a footway/cycleway/track or any other highway, and could be tagged as such. Without at least one tag x=designated, one can tell very little about the form and practical use of any single highway=path. Some months later, users in Germany, iirc, noticed that new mappers had used the value 'designated' where there was no specific traffic sign (i.e. the blue compulsory use kind), so they started using x=official and defined it solely as: official = has a compulsory use traffic sign for that transport mode Tool/rendering support for x=official is less common, than the support for =designated. Later, mappers noticed that besides agricultural=yes (tractors allowed/not allowed), sometimes a traffic sign no motorvehicles has a supplementary sign agricultural traffic allowed, to allow those maintaining the farm fields along that road to use any vehicles they need to. Hence, there's the value 'agricultural', most likely used with vehicle= or motor_vehicle=. Both agricultural=* and motor_vehicle=agricultural have about 18 000 uses. Likewise, there's apparantly a lot of no motor vehicles, but allowed for forest maintenance signs somewhere. So they've used x=forestry. I don't remember exactly when was 'delivery' added as a value, but that's not one of the original values, either. Deliveries can happen with any vehicle, but it's not a general allowance for destination traffic; like agricultural, forestry and customers, it's a role, as the various proposals for describing complex access restrictions would label these. Roles don't belong in the value, IMO: motor_vehicle=customers;delivery;garbage_hauling. (I've seen one place with a sign no motor vehicles, but dog park waste collection allowed. After that dog park there's a regular 'combined cycle/footway' sign. Effectively, even the first part is a cycleway). -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] on the name of a tag for landcover
according to the wiki, for smaller areas of mown and managed grass for example in the middle of a roundabout, verges beside a road or in So this isn't actually a tag for every spot where you can find grass, but it is a tag for auxiliary areas dedicated to traffic. It reads for example above. My point in this message: Not all of them are auxiliary areas of highways. I've always taken landuse=grass to mean any area, that grows grass, but where said area is not used for anything else, except for growing that grass, and which gets mowed at least sometimes, to keep it from naturally becoming something else. If it would be left unmaintained, it would turn into scrub, mud, or meadow, or similar. In a few years anyway. If it would be used for leisure, it'd be (a part of a) leisure=park. If it would be used for sport, it'd probably be leisure=pitch. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Petr Morávek [Xificurk] wrote: 2) A relation exists with member ways without ref tag. This means that the route is essentially mapped and any further editor is correcting errors, that he found. Then someone comes and adds a ref tag to one of the ways - why? He drove by, and saw a different ref sign next to that road from one intersection and the next one. He has no knowledge of where the ref on the relation comes from, and if it is still valid on all the ways currently part of the relation. He only knows that this way has a ref=new value, and it's all he can enter. Locals will eventually notice, and resurvey the whole area - they'd have to resurvey anyway. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
Pieren wrote: but the wiki doesn't say explicitely that overtaking=no means no u-turn as well. Could we write this assertion ? Probably not. Here they leave a small (about 3 meter long) gap in the solid line whenever there's a tiny one lane side road (or a driveway) and it's not necessary to ban turning left onto said driveway or similar. An u-turn would be likewise allowed at that spot. Even if I'm known for going - as some would say - overkill by splitting ways to short bits for some changing road attributes, I don't think it's reasonable to have a three meter long way-bit on both sides of an intersection just to make sure that routers don't think they can't turn left (or u-turn) there. And to be exact, in most countries overtaking in the opposite direction lanes is forbidden within an intersection, even when the solid line doesn't continue through the intersection. An overtaking restriction can be (shouldn't, but can) given with just a traffic sign. I'll need to see if I (or anybody else) can find a spot where a multilane (3+ lanes) undivided road has a no overtaking sign in the direction with several lanes, but doesn't have a solid or double solid line in the middle. Since I started mapping overtaking=* tags back in 2009, I've found that there's a border case that the current values can't convey thoroughly: On a multilane (3+) undivided road, overtaking in the direction with two or more lanes may be - forbidden only if using the opposite direction lanes (appropriate solid line) - forbidden regardless of the lane used ( =no ) - allowed on all lanes (given no oncoming traffic ( =yes) -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping larger Mini-roundabouts
Here's one option: http://osm.org/go/euu1t7NMP-- The dual carriageway (Shenley Road) is brought to a point (node) at the intersection. Even if it's currently the only way, it should be noted that it has the unfortunate effect of mangling the geometry; there's no slight-right turn followed by a slight-left turn when driving straight through. Just that whenever such cases are used as an example, new editors easily pick the method as an example for any intersection of dual carriageway roads, and start bringing the carriageways to a single point at any normal large intersection. Takes anything from a few weeks to some months before there's the first wiki dispute on what was the intent of said example, or how the regular, long ago written examples are wrong. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes cycle tracks - my findings and a proposal
As long as (just my favorite example) you have to move x ways to move a street by a few meters, this will no succeed. Nobody says that we should not map buildings, bus stops, pubs, benches, restaurants, post boxes, streams, pubs, trees, advertising columns, etc. just because one would have to move x of them when they get a better source for the street alignment, or the street changes. The map will get crowded and more tedious to edit over time, but that's just a sign of active mappers - and of more users to do smaller bits of said tedious edits. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Before that I added a point in the Open issues section about lanes=1.5 and modified the note at the end of the section Narrow road. As So, today I got a chance to revisit an unpaved residential road I've tagged as lanes=1.5 in the distant past. Here's two pictures of it (in one) Above, usual traffic drives almost in the center of the road, as if it were lanes=1. Below, the car in picture has it's right side mirror almost touching the fence, and there's 2.2 meters of the carriageway free for oncoming traffic, 2.6-2.7 meters of space to the fence on the other side of the road. Oncoming cars can get past each other, so it's not lanes=1. Yet all driveers will slow to a crawl, or at least to a jogging speed, so IMO it can't be lanes=2, either. http://i46.tinypic.com/2cfqivn.png Which value would people use for the lanes=*? -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Looks as if 2 cars can pass each other without big problems. Only in the utopia where all drivers can confidently manouver their cars at speed to gaps only 10-20 cm wider than their car. Most people don't. The white car already has it's right hand wheels outside the normal driving surface. And this is early spring, there are no tree/scrub branches delineating the fences, or any snow limiting such attempts at scraping the fences with the side mirror. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
police doesn't enforce the official rules, then there are factually more lanes on the ground than painted on the road. Isn't that equal to cycling on sidewalks: we shouldn't tag sidewalks with bicycle=yes (in coutries where cyclists may not use them), even if only a dozen or so get a fine each year. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
IMHO it would be a good idea to remove fractional lanes amounts and forget about them. They are too subjective. What do you think of lanes=3.5? I have an example here: http://maps.google.it/maps?hl=enll=41.899274,12.464333spn=0.008497,0.021136t=hz=16layer=ccbll=41.899391,12.464289panoid=O8BHrnM_gTAW2XQUWqxcXgcbp=12,353.6,,0,4.57 When the lanes are marked on the ground, it ought to be an offence to drive continuously on the lines separating lanes; hence, there are only three lanes in the link above, even if some or many drivers think they can get away with it. Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: http://maps.google.it/maps?hl=enll=41.876836,12.481943spn=0.000378,0.00066t=hz=21 Changing lanes and overtaking within an intersection ought to be an offence in developed countries, so from the modelling point of view there can only be as many lanes as there are on any of the incoming or outgoing carriageways. vehicles can pass at the same time, lanes=1.5 doesn't really help you, it will always remain unclear which width is the street. There are those roads (yes, roughly 4 meters wide) that, based on the overall setting, can not be called two lane roads, but it would be misleading to tag them with lanes=1, either. Aren't we supposed to safely assume that every road can be tagged with some correct lanes tag? -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 21.04.2012 um 13:34 schrieb Ilpo Järvinen ilpo.jarvi...@helsinki.fi: ...What I don't really care if it is called lanes=1.5 or lanes=1/2+some_other_agreed_tag_which_is_not_an_estimated_width=x, but simply saying that use lanes=1/2 alone instead I oppose. I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, narrow roads? Can someone provide photos and widths? There are a few things to this, that haven't yet been mentioned. I've been writing this as the discussion has progressed, so this got a bit long, but I tried to rearrange it to a comprehensible presentation of the issues. All this discussion is taking place, because there are roads where lanes=2 would be wrong part of the time, or for some motorized road users, and lanes=1 would be wrong on that same road at some other times. IMO we should not omit the lanes tag altogether on these roads, when the between 1 and 2 tells us something significant of the attainable speeds and the layout of that road. Even if the actual width is measured and entered. First: I give you two clear examples why we must not limit the lanes tag to roads with a painted line: Urban road 9 meters wide (measured from aerial images), parked cars on one side (always), no markings. Definitively lanes=2 - that's 3,5 meter wide lanes, enough for the bus that runs here. http://g.co/maps/9pvjn Rural road less than 5.7 meters(*), probably 5.5m. No markings. Low traffic, passenger car and a hgv can pass even if most drivers slow down a bit because they have to drive so close to the edge. Has passing places for the easier driving in the rare case of oncoming hgv's, even if they can fit side by side with only few cm margin. Passing places are also in place for winter time, when the snowplowed road edge has too much snow for driving safely in a straight line, when a bus and a passenger car need to fit side by side. In winter two passenger cars would most of the time disregard the passing places. I'd still say lanes=2: http://g.co/maps/c7p3h *) Here the road marking rules state that generally no center line markings are used on roads less than 5.7 meters wide; even that is 2.8 meters per lane, i.e. enough for the widest road legal hgv's to pass. I'd believe the point being, that a center line on a road narrower than that would make it impossible for the hgv to stay within the lane it is supposed be driving in. About car widths: typical European car widths are 1.80 meters, give or take 5 cm. That does not include mirrors. That is why a row of parked cars takes up 2 meters from the road width. (Also, not everybody can park every time less than 5 cm from the road edge.) The widths have grown some 20 cm between the 1970's and present day. Likewise, the 2.55/2.60 meters for trucks and buses does not include mirrors. Second point: often we would, I believe, assume that a road tagged as having two lanes generally always allows unimpeded traffic flow in both directions. Where it's 4.2-4.4 meters wide, that holds for passenger cars. A case I often see, especially in urban areas built between 1920 and 1960, are residential roads that are 5.5 to 6 meters wide without a center line, but allow parking on one side of the road carriageway - and they're generally often full of parked cars. It's not a parking lane, but part of the road reserved for traffic; when there are no parked cars, even hgv's could pass each other with care. On 5.5 meters wide roads, many passenger car drivers will wait at a random free space between the parked cars, but on a 6 m wide road people will just slow to a crawl (or halt) when passing oncoming cars. The wider one could be lanes=2, but the narrower one hardly. See below for streetview examples, the last two example links. Third point: were we to estimate widths visually (not all areas have good enough aerial imagery), there would be lots of relative errors between nearby roads: IMO it's bad if such measures are recorded that claim that a road is narrower than the next, when it's the other way round - especially when the claimed-to-be narrower road might have two clear lanes, whereas the lane count isn't that unambigous on the other road. With lanes=1.5 we have a rough scale, but one that's correct relative to nearby roads with definitively 1 or 2 lanes. Examples, both clear cases and ones that are to date without a lanes tag, or with lanes=1.5. None of the examples below are oneway roads. Only now did I measure the width from Bing aerials. One can take the phrase Generally always below to mean that if you were to go there on 10 different days, on 8 or 9 days the situation would be as depicted. Clear cases of lanes=2: Rural road 7.5 meters wide (+shoulders), marked lanes, lots of margin within the lanes for the widest of vehicles. http://g.co/maps/zjjx2 Rural road about 6.5 to 7 meters, marked lanes, even a hgv still has lots of margin within their own lane. lanes=2
Re: [Tagging] How to tag the width of a gate
This was discussed intensely some time ago for maxheight, I suggest you read the archives on this. I agree that a physical restriction is Originally there was little mention of any of them tags depicting purely legal restrictions. Even access/*=no was unsuitable or not allowed, but later, as it was deemed unverifiable, the only legal started creeping into all sorts of tags, where it may or may not be the common usage, or sensible. For a lorry driver it doesn't matter if a gate's width limit is legal or physical, if they can't get through, but can drive up to it. That's the history bit. Using width=* only for physical maximum width for a vehicle could only work for, for example, gates, whereas a narrow road lined with trees might be impassable for wide vehicles, but there isn't an object that could be tagged with width=* at that narrow point between two trees. Mind you, the road itself (its width=*) can be narrower than the load the vehicle is carrying, or the vehicles extents (e.g. side mirrors). Likewise, a gate is often actually wider than the gap; for an stone arch gate even several meters wider. My point being, that physical maximum width deserves some other tag than width=*. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] building attributes
4. building:levels=*Number of stories of the building above ground. - why only above ground? I find this missleading as well. The logical meaning of a tag building:levels would be the total amount of building levels. If it is for the levels above ground, why not building:levels:above_ground ? The description could be enhanced to IMO this is a make mapping easy choise (vs. code requires sticking to definitions, even if it is against day to day speak): you can get a random mapper to count the windows and have them enter that. If one asks people if a building is a, say, six-storey building, they don't ask if it has many underground levels but look at the windows. Likewise many pro map databases, and statistical databases classify buildings by the above ground count. It deserves to be the first to pop up when entering. Colons in keys are likely to make many casual mappers uneasy about editing said tag, let alone two of them in one key. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] psv
Are there examples of places where taxis can't use a bus lane? Like in Germany, also in Finland some bus lanes are just for buses, whereas on some roads the traffic sign includes the word taxi to allow both. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping a negative
Are there any other OSM conventions that indicate a lack of a facility? Maybe: toilets=no Not going into the wiki-approved new schemes, currently many highway=bus_stop nodes have one or more of: shelter=no (54800) bench=no timetable=no waste_basket=no departures_board=no Each of these could, at least in some sense, be a separate facility/amenity, in contrast to for example unaccepted payment options, e.g. payment:coins=no. Also, in places where a pedestrian is legally obliged to use the painted crossing nearby, at a point where a footway way crosses a way depicting the road, but where there is no crossing, there can be (1971 uses) the tag crossing=no. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - natural=ridge
What data source are you suggesting that the renderer should use, if not the OSM database? The same one that the cycle map layer uses to draw contour lines. Unfortunately that srtm data ends at 60° N: http://osm.org/go/0TORO-- And it's eventually way too scarse. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Key location (was Feature Proposal - Voting - entrance=*)
'established' is a big word. I'm surprised by the taginfo stats. I never used this tag myself and I don't remember if it was really discussed in the international lists. It is in the wiki since July. Taginfo won't show the combinations at the moment, but location=* is, afaik, used on ways with man_made=pipeline and nodes tagged amenity/emergency=fire_hydrant. The pipeline tagging proposal suggested it first on 6 December 2007(*) and the proposal vote ended on 31 December 2007. The proper mention has been on Tag:man_made=pipeline from the day that page was created, on 17 May 2009. *) http://wiki.openstreetmap.org/w/index.php?title=Approved_features/Tag:man_made%3Dpipelineoldid=62974 -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Key location
Left out a significant word by mistake: is, afaik, *mostly* used on ways with man_made=pipeline and nodes The fire hydrant page now suggests fire_hydrant:type=underground/wall etc., but many old mappers try to avoid type=* as a key - or as a part of a key. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Turn Lanes
The tag lanes should be reserved for the straight forward lanes. At a T-junction, the road ending there would then be lanes=0, given that wording. Nice. As a result, we just add a node for a minor information and do not damage the existing highways. There's bound to be, eventually, enormous amounts of data beside the roads, from buildings and their entrances, to curved ditches, fences, hedges and scrubs, just to name a few. I find it strange that roads should somehow be frozen at the lengths of n2 block spanning ways. What value does it add, to try to keep the roads from being split midblock? Bus routes and parking restrictions already make it necessary to split at most urban junctions, anyway, and longer rural roads have very few turning lanes per distance. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Storm drains
osm.tagging at thorsten.engler.id.au wrote: I guess nobody has bothered tagging storm drains yet? While deducing other underground pipelines from markers and manhole/valve lids, I have occasionally added some nodes with manhole=drain, too. Some could do with a, say, location=kerb tag if the kerb isn't yet drawn as a way. I believe most of the 760 uses of manhole=drain so far aren't mine, though. manhole=drain is clearly wrong I would say. Around here most of the storm drains are identical in appearance to regular manholes: round, about 60 cm diameter, flat on the asphalt, with a removable 2-3 cm thick iron lid - the lid is just perforated. Seem's there's no picture in the wiki, so I'll add one once I find one from my mapping photos. The manhole=* key has been used roughly for any dedicated metal cover in the ground and with space underneath - from valve covers in the street to district heating pipeline junction box access manholes to big hatches to (whatever they're hiding). It's the simplest categorization for anyone a) not working with them professionally b) non-native english speakers; i.e. I see a metal cover on the ground - add manhole=*, and possible refining tags. And it doesn't exclude others tagging them as man_made=storm_drain :) Btw. could you/may I upload the photos you linked to a few messages back to the osm wiki, for illustrating the kerb discussion? If they're yours to give. https://lh4.googleusercontent.com/-ZazzZqW8w5U/TkNH_duXp5I/AEs/kwDNJFxO9BE/s800/IMG_20110806_170811.jpg https://lh5.googleusercontent.com/-gD6RfYExBTc/TkNNqT-MNuI/AFI/gqh2ROwDkNQ/s800/IMG_20110811_132316.jpg https://lh3.googleusercontent.com/-ML8g03AXppA/TkNO5KLLIeI/AFY/O42YukZE_EY/s800/IMG_20110811_132337.jpg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
