Re: [Tagging] Disputed area
Le 26/07/2015 03:20, Arch Arch a écrit : The main server is not for testing. Please use http://wiki.openstreetmap.org/wiki/Sandbox_for_editing instead Here, you can try out complex things before doing them on the OSM database. If you are developing editing clients and automated edit scripts, this is very useful ... I did not do a complex thing. I've removed Tromelin from Mauritius relation Better practice is to ask the contributor to remove it itself. as this causes rendering issues: http://i.imgur.com/TZTYlHt.png Tagging for render? Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Disputed area
I did some try. * Mont-Blanc area claimed by France and Italy but occupied by nobody. I have split the boundary into two branches (an awful job considering the number of administrative relations involved). I defined an area with: disputed_area=yes dispute:claim:FR=yes (area claim by France) dispute:claim:IT=yes (area claim by l'Italie) dispute:recognized:FR=yes (dispute is recognized as such by French authorities) dispute:recognized:IT=yes (dispute is recognized as such by Italian authorities) dispute:wikipedia:fr=Histoire_de_la_frontière_sur_le_mont_Blanc I added the area both to relations France and Italia (admin_level=2) with role dispute:recognized (each government recognize that there is an area within his border that is subject to dispute). * Juan de Nova island. French island. Claim by Madagascar. French government don't really recognize that there is a conflict (I think this is the most common case of disputed area). I added to the island perimeter which is already the French boundary: disputed_area=yes dispute:claim:MG=yes dispute:recognized:FR=no dispute:recognized:MG=yes Added to Madagascar relation with dispute:claim role. Not added to France relation because French government don't acknowledge the dispute. * Tromelin Island. French island. Claimed by Mauritius. French government accepted to share fishing right with Mauritius that I consider as an acknowledgment of the dispute. I added to the island perimeter which is already the French boundary: disputed_area=yes dispute:claim:MU=yes dispute:recognized:FR=yes dispute:recognized:MU=yes Added to Mauritius relation with dispute:claim role. Added to France relation with dispute:recognized role. I see several drawbacks. - looking at the disputed territories proposal (http://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories), I would say that my use of recognized is not well suited. Recognized would be better fits for foreign governments or international organizations (like UN) that recognized the 'de facto' situation. May be dispute:acknowledge:CC=* would be best suited to indicate that a government recognize that there is a dispute. - there are several redundancies. If country AA claims an area out of his 'de facto' boundaries, it is both marked as dispute:recognized:AA=yes and added to AA relation with dispute:claim role. If country BB recognize that there is a disputed area within his 'de facto' boundaries it is both marked as dispute:recognized:BB=yes and added to BB relation with dispute:recognized role. Indeed, all roles dispute:claim are supposed outside the country boundaries and all roles dispute:recognized are supposed inside the country boundaries. May be one role should be enough for both. Or no role/inclusion in relation at all. What are all the disputed areas within CC and recognized as such by CC government? Request all disputed_area=yes within CC relation and with dispute:recognized:CC=yes. Last question : how to indicate that an area want its independence? Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Disputed area
I think a good test case for testing if this can handle ongoing and complex conflicts would be Kashmir, as it's currently five-ways disputed between Pakistan, India, China, a Kashmir separatist/freedom/independence movement, and recently displaced-from-Afghanistan irregular Islamic fundamentalist forces. I would be cautious about not stabilized conflicts and therefore exclude the last group and just focus on the first four claimers. In the same idea, I would not try to describe the situation in East Ukraine. First question : can you draw current de facto borders? The northern part of India/Pakistan border? Second question : can you draw areas with uniform claims and de facto situation inside? Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Disputed area
Overlapping should be the first step to mapping a dispute. Then if you want to add dispute attributes, you could create a new multipolygon with areas in question, and add dispute specific tags, wikidata tags, and similar. In my previous message, I proposed to create a relation for the disputed area but a single polygon may be enough in most cases. A multipolygon may be used if the same dispute deals with several areas (like one country claiming several islands of another country at the same time). Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Disputed area
Yes, some disputed areas are more stable and, in osm, one may focuses first on it. In a lot of cases, there is de facto one country administrating the area. We should use the de facto aspect to draw a closed boundary=administrative. Then we may add to the relation disputed areas with different roles whenever they are inside or outside the de facto boundaries. The disputed area may be itself defined by a relation including the area, the boundaries claimed by each government and may be some tags to indicate if the disputed area is recognized as such by each government and/or attributed to one specific government by some international organization (for de jure aspect?). For my initial case (Mont-Blanc between fr and it), there is no de facto occupying country. I would split the boundary into two branches corresponding to each government claim. Define a disputed_area relation with: - each branch - the area - claimed by France - claimed by Italy - dispute acknowledged by France - dispute acknowledged by Italy - dispute acknowledged by European Union Put each branch in the corresponding country relations. Add to each country relation a disputed_area_inside with the disputed relation. The main drawback is that there is an overlap between France and Italy that may stress some tools. Gibraltar : there is a de facto occupying country. I would not split the boundary into two branches. Define a disputed_area relation with: - the UK branch surrounding Gibraltar - the earth border between UK and Spain - the area - claimed by Spain - dispute acknowledged by Spain - dispute acknowledged by Uk Maintain the earth border in the corresponding country relations. Add to UK relation a disputed_area_inside with the disputed relation. Add to Spain relation a disputed_area_outside with the disputed relation. Area claimed by nobody between Egypt and Sudan? Split the boundary into two branches according to each government. Define a disputed_area relation with: - the Sudan branch - the Egypt branch - the area (no claim, no dispute acknowledgement). Is such a schema suitable for the Indian/China case? Does is allow to draw a map like the one presented? Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge AND embankment
@Eric: I looked at more examples, and I have to admit that you are right with your statistical (0.1%) argument. Most cases I looked at, are obvious accidental tagging errors. I checked for Madagascar. I found one case and I'm the author :-p I first added embankment and later cute a small part of the road to add a bridge. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge AND embankment
Although I agree that such combination is suspicious... 250 in France A rough evaluation for France give me 200k ways with bridge=yes. So about 1 error each 1000 bridges. Not such a big issue. My 0,02 €. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Disputed area
One thing that perhaps might want to be captured in other disputes is what happens when one country actually occupies and controls the disputed territory. There, there's a de facto border and a claim. Yes, I started with the easy case where not country is occupying the disputed area and both countries agree on the limits of the disputed area. There should be a similar case between USA and Canada for islands near Vancouver. Although not so completely pacific is the case of Perejil/Tourah island between Spain and Morocco with status quo and no one occupying it. In opposite there are a lot of claims that seems mostly theoretical like Spain other Gibraltar, Morocco other Ceuta and Melilla, Madagascar other Juan de Nova and Europa islands (both inhabited but controlled/administrated by France)... Tromelin island controlled by France but with fishing rights share with Maurice republic that is claiming the island. So I don't know were to put the limit on which territories should be tagged as disputed in OSM. May be we can start with areas recognized as such by booth governments and not occupies by any one :-p There is also the case of sea/water disputes like the one recently solved by international tribunal between Chile and Peru. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Maxspeed
In Italy we've been using something like maxspeed=50; source:maxspeed=IT:urban maxspeed=90; source:maxspeed=IT:rural +1 in France: maxspeed=50; source:maxspeed=FR:urban maxspeed=90; source:maxspeed=FR:rural maxspeed=130; source:maxspeed=FR:motorway maxspeed=30; source:maxspeed=FR:zone30 maxspeed=20; source:maxspeed=FR:living_street Although for the last two, speed limit is included in the corresponding traffic sign design. http://wiki.openstreetmap.org/wiki/Key:source:maxspeed Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Bug] calculated shortest route wrong
Paul, USENET and Mailing List posting netiquette: 4. Do not cross-post: http://linux.sgms-centre.com/misc/netiquette.php#xpost People on [tagging] may not be aware of the beginning of the discussion and other people on [osmand] may only receive a fraction of answers. Thanks Éric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
(I think of the roads we drove in Kenya), so any input is welcome even if it isn't perfect. We ran into some nasty surprises during our trip because the road quality wasn't tagged at all. +1. I also widely use smoothness=* in Madagascar. Indeed, I use it to describe practicability of roads or tracks for 4 wheels motor vehicles, in somehow to answer the question: what kind of vehicle do I need to use this road? Despite using it often, I still have to check the wiki time to time to be sure about values definition. I even more dislike tracktype=gradeN that is using numerical values. Maybe, it is time to define a new key/values. We already have mtb:scale and sac_scale. For instance, practicability for cars: practicability=* practicability=no (damaged road) practicability=tractor_only practicability=fourwheeldrive_only (and not 4WD_only to avoid abbreviation) practicability=highclearance_only practicability=normal (default value) practicability=lowclearance Subjectivity still remains. One may consider a road as usable with a high clearance car because it is used by 404 taxi-brousse when another one may not want to use his Porche Cayenne SUV on it. It doesn't really describe smoothness. A road usable with normal vehicles may be driven at 100 km/h or 20 km/h, depending on smoothness. One may define some side scales like: practicability:bicycle=mountainbike_only/trekkingbike_only/citybike/all(defaut) practicability:motorcycle=* My 0,02 . Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging very wide steps - highway=steps on an area?
I had assumed for years that the direction pointing upwards was a commonly agreed on standard, being myself an architect I hadn't expected this to be questionable, but as I got so much flak from people insisting on the other way round, Like me :-p (although not insisting). Indeed, as a poor lonely mapper, I assumed that steps were pointing down like waterways. I now am adding the tag incline=up to all steps. +1 with incline=down but up to now, I didn't corrected my contributions backward. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ethnic shops
I started modifying the wiki following our recent discussion.
For cuisine=*, I added:
May also apply to other services that deliver food, like convenience.
For shop=convenience, I added (in Tags used in combination):
Stores selling specific type of food or with ethnic origin may use
{{tag|cuisine}} to indicate it.
And latter go on with culture=* for nonfood services?
Eric
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] length=
Le 27/01/2015 16:34, Martin Vonwald a écrit : Ok - understood. Although I doubt, that there is real usage for that example. But I had a quick look in overpass: besides aeroways it is quite often used on bridges and tunnels, where the actual (official) length can be observed. Makes sense. Indeed, for tunnels, I just put the length indicated at the entrance in note=*... ... and some other contributors transfered it to length=*. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ford and other river crossing : (was : waterway=wadi problem)
I wonder if there are enough of them to warrant their own bridge=*, as there are so many kinds of bridges. I bet we can put a ford tag on the bridge - it might be a simple solution. I agree with your suggestion of using boot bridge=yes and ford=yes as it is usually a bridge but sometime behaves like a ford. I would avoid flood_prone=yes as it is made to be used when reasonably submerged. Adding depth=0 (or -0.5 ?) to indicate that the ford aspect is usually dry. (depth is not really used with bridge=* : 14 over 240). Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Ford and other river crossing : (was : waterway=wadi problem)
My apologize for switching the discussion (so I change the title accordingly) and also for slowly answering. First, I was not aware of depth=* use recommendation with ford=yes although it is in the wiki for years. Let me back to Madagascar. We have: - unpaved road crossing permanent river without specific equipment ford=yes surface=unpaved depth0 - unpaved road crossing permanent river with specific equipment (usually made of concrete, radier in French, not sure on the correct term in English: raft???) ford=yes surface=paved/concrete depth0 - unpaved road crossing intermittent river without specific equipment ford=yes surface=unpaved depth=0 May we use intermittent=yes/seasonal/flood/winter... to indicate period/frequency submersion? - unpaved road crossing intermittent river with specific equipment ford=yes surface=paved/concrete depth=0 intermittent? - paved road crossing permanent river (of course with specific equipment) ford=yes surface=paved/concrete depth0 - paved road crossing intermittent river ford=yes surface=paved/concrete depth=0 intermittent? Do we have also to use flood_prone=yes or (ford=yes / depth=0) already imply that it is subject to flooding? I don't like the wiki page on flood_prone. It is telling that the main difference between ford and flood_prone is the danger aspect. Indeed, looking at illustrations, especially at the third one, I just see a regular ford with depth scale and so on. I have one last case: some low profile bridge (without parapet) may be submerged after heavy rain but may be still usable if water depth above the bridge in not too high. How to tag this? Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ethnic shops
Le 19/01/2015 18:42, althio althio a écrit : John Willis jo...@mac.com mailto:jo...@mac.com wrote: I think there should be ethnic=*, Nationality=* , or culture=*tag that can be used [...] I find culture=* the best so far. I find it specialised enough (compared to _type=*, origin=*, category=*, group=* ...) I find it accurate enough. I find it generic enough (compared to more restrictive nationality=* and even ethnicity=*) so that it enables tagging for ethnic group but also other types of social group and subcultures. like: amenity=hairdresser name=Scalp culture=punk ? but culture=* is already used. 84 uses: kleinkunst museum music roman celtic youth_club theatre art_gallery arts_centre ... ethnic=* is mostly used in Colombia (x1000) from an OCHA import (that I didn't know was compatible with OSM license) associated with place=hamlet, ethnic=yes and ethnic_group=*. ethnicity=* is used with values indian chinese italian mexican Italian yes asian polish thai czech Some uses are strange like restaurants in USA with cuisine=national, ethnicity=*. Based on the current uses and the fact that culture may have several meanings, ethnicity=* seams to me the best choice with values as similar as possible to cuisine=*. -- Éric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Ethnic shops
Hi all, I'm wandering on how to tag shops that are offering services with specific ethnic orientation. For instance: - convenience specialized for Italian, Portuguese, Chinese products... - clothes typical from one country/area - hairdresser for African people although non African may also want to find it for braids ... cuisine=* is used for restaurant and may be suitable for convenience but not really for clothes or hairdresser. Any suggestion is welcome. Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Juice restaurants
I'd not choose amenity=cafe if they don't sell besides the juice also coffee. Look how quite specific the other tags are for places where you can drink, eg biergarten, pub, cafe, bar, kiosk, nightclub ... I'm wondering if the way we are coding different places where we can drink or eat is not too specific. May be, we should think about a more general model like: amenity=drink_place/eat_place seat=yes/no indoor/outdoor fast_food=yes/no beverage cuisine operator ... So renderer can easily handle a lot of cases. We can then add a tag to specify local cultural items: drink_place:type=biergarten, pub, cafe, bar, kiosk... but renderer can work without this last tag. My 0,02 Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] piste:type=nordic but without underlying track
Hi, I'm also using piste:type=nordic alone not only in field but also on track/road because a lot of things are different between piste and road. Physically, the piste is over the road but don't use his surface. Road is open in summer, piste in winter. Piste could be oneway and not the road... You can see what I did there : http://osm.org/go/0CC~gQzS Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Money transfer agents
There's a proposal in the wiki that money transfer agents such as Western Union should be tagged as amenity=money_transfer. I don't like this tag because of the over use of amenity key. +1. Many of the money transfer agents are banks or bureau de change, which are amenities. Yes, in France, they are always part of an other shop/bank... In Madagascar, they are not only part of some banks put they also have stand alone offices. Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Money transfer agents
Le 19/11/2012 15:58, Janko Mihelić a écrit : Maybe something even wider like: service:money:transfer=yes service:money:exchange=yes (because you can exchange currencies in some banks too, not only exchange bureaus) service:money:withdraw=yes service:money:deposit_coins=yes I like it. So service:money:transfer:operator=Western Union ? Quite long... Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
About the values existing [...] For example, in my proposal there are a comment about obstacle=bridge (69,57% values of obstacle now), that can see here I'm surprise by the large use of obstacle=bridge. Do we have any idea on how it is used now? Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: road in Luxembourgish park with unclear status
Road classification... such a difficult subject in many countries. For the part that inhabitants can use, highway=residential and access=destination. After, for me, the road is large enough for a car but motor vehicles are prohibited - highway = pedestrian. Don't care about park maintenance. until picture 9. At this point, a car can't use it. highway=footway : a intentionally organized way for pedestrians. (opposite to highway=path for way that appears after repeated use by pedestrians but not intentionally made for). In booth cases (pedestrian and footway), bicycle status is not clear by default. Clear indication is welcome : bicycle = yes (assuming that the way is mostly designed for pedestrian). Photo11 : I never now if it is mostly designed for bicycle (highway=cycleway) or for pedestrians (highway=footway). segregated=no to indicate mixing of both type of users. http://wiki.openstreetmap.org/wiki/Key:segregated Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency lane used by PSV at rush time
Sorry for late answer. There is so much traffic related to lanes on this mailing list. I suggest the following rewording which should reflect the initial intention: Other lanes such as Wikipedia spitsstrooken in the Netherlands or Wikipedia temporäre Standstreifen in Austria, Germany and Switzerland which are available to GENERAL traffic (I.E. NOT LIMITED TO A SPECIFIC KIND OF VEHICLES) at certain restricted times, for example during the rush hour. +1. Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Emergency lane used by PSV at rush time
Hi, I'm translating the lanes=* wiki page into French. And some cases are coming into my mind :-p On a motorway, the emergency lane can be used by psv (bus and taxi) when there is traffic jam on the usual lanes. There is no predefined hours. Just, when traffic jam is detected, light signal are switched to indicate it. So, how would you tag this considering lanes=* definition and new Conditional restrictions? Default is lanes=2 oneway=yes but considering that lanes=* should include lanes that are available to traffic at certain restricted times, it should be lanes=3 lanes:psv:conditional= 1 @ rush_time but this will suggest that all 3 lanes are available for all vehicles out of rush time. Some other suggestions? -- Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency lane used by PSV at rush time
For practical tagging I think it is too theoretical for most mappers to understand the difference. [...] In somehow, having a not to complicated model or at least a two levels model a first simple model could be better. Back to my initial problem lanes=2 lanes:condtional = 3 @ traffic_jam lanes:psv:conditional = 1 @ traffic_jam Basic data users just need to understand the first key. More advanced one may use the two last. lanes=* wiki would need to be modified to not count temporary lanes. It would be more consistent as most of the time only two lanes are available. Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»
Hi, During my last travel in Africa, I was thinking on how to map obstacles on road. So I support your proposal but in a generalized way, not only for pedestrian or bicycle. And I take the opportunity to review what I observed: - a narrow bridge i.e. you can't cross a vehicle in opposite direction. We may use width=* but it is difficult to get it precisely. obstacle=narrowness - a bridge or a raft with a bad link to the road/track i.e. a step at each end of the bridge/raft. obstacle=unevenness ? or obstacle=step? For me unevenness is to soft for what you describe. - a hole in the road. * A small hole you can drive other at full speed but that may surprise you when driving during night. * A medium hole where you have to use the other side of the road at full speed if nobody is arriving in front * A big hole where you have to slow down and drive inside. (For full uneven sections, I use smoothness=*). - a road on a dam or a bridge have been damaged : a bailey bridge (http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for ten years ;-) ) added on it. I would no use obstacle for thinks that are deliberate and/or in their initial state. For river and water. If there is water year around (or large fraction of the year) : ford=yes. Only flooded few days a year (after heavy rain), flood_prone=yes. Use surface=* to indicate whenever you are just driving in the river or if there is some raft build. Seasonal? Use seasonal=yes in conjunction with access:conditional=* to indicate approximative closing period (discussed recently on this mailing list. I will update the wiki according soon...). Same with traffic_calming, check points... HOT is also dealing with obstacle : http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model#Obstacle Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
- a narrow bridge i.e. you can't cross a vehicle in opposite direction. We may use width=* but it is difficult to get it precisely. obstacle=narrowness It's slightly offtopic, but wouldn't it be logical to use car as a non accurate unit of length? So you can have a tag like width=1car or width=1.5car. I like it :-) In Europe, I found : 1 car used 2 times wide enough for a car used 1 time Not wildly used. Indeed, as pointed out by Martin, I have to use lanes=1. I had a misunderstanding with the lanes=* key. I thought lanes=* indicated the number of lanes in each direction, not the total number in both directions. The French wiki lanes=* page need a strong update, compared to the English one (todo list...). So, I will go on with lanes=1. Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»
you could use lanes=1 on the narrow parts. Agree. - a bridge or a raft with a bad link to the road/track i.e. a step at each end of the bridge/raft. obstacle=unevenness ? or obstacle=step? For me unevenness is to soft for what you describe. split the way and put a short highway=steps, step_count=1 No. It would indicate that it can't be used by vehicles. - a road on a dam or a bridge have been damaged : a bailey bridge (http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for ten years ;-) ) added on it. is this an obstacle, or is it simply another type of bridge construction? If it is an obstacle the tagging should line out in what the obstacle consists (smoothness, width, maxweight, ...) It's first a lanes=1 and second short connecting slopes at each end. Something no so far from the steps I mentioned earlier i.e. you have to slow down at entrance and exit of the bridge. Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
For mountain pass in Alps, this could be just access:conditional = no @ Nov-Apr That seems logical to me. One word on using access:conditional though - this would indicate no access, including on foot. In somehow, we may consider that the road does not exist in winter due to the large amount of snow over it. I mostly use it during ski touring. For more details see [1] and [2]. Essentially there is a hierarchy of subcategories for transportation modes. [2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png This scheme should be more wildly used. It seems to be use only in the German wiki. Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
I'm looking how to tag a road with seasonal opening or closing. ... Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions May I improve the wiki on seasonal=* to indicate that it would be nice to use it in conjunction with Conditional_restrictions? Regards Eric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
I'm looking how to tag a road with seasonal opening or closing. ... Up to now, I was using opening_hours=* with Nov-Apr off. Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions I had a look some time ago but without thinking at seasonal roads. Work is under way to help make the page clearer, +1 [...] but essentially your tag would be: * vehicle:conditional = no @ Nov-Apr For mountain pass in Alps, this could be just access:conditional = no @ Nov-Apr For African tracks, something like smoothness:conditional = horrible @ May-Oct smoothness:conditional = very_horrible @ Nov-Apr or smoothness = horrible smoothness:conditional = very_horrible @ Nov-Apr All with seasonal=yes to indicate the random aspect of the time condition. Do you agree? Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
One of the main mountain highways here is closed to licensed vehicles during the winter months, but snowmobiles are permitted. Would vehicle:conditional apply to snowmobiles? I also have a similar problem with road that are use in winter for nordic (or not) ski. Up to now, I added a second way for winter activities on top the way for the summer road. Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Seasonnal roads
Hi, I'm looking how to tag a road with seasonal opening or closing. Typical, mountain pass are closed in winter due to snow. Usual opening and closing dates are published (like open from week 24 to 41). In opposite, some roads on ice are only opened in winter. In Africa, some unpaved roads are usually closed during rainy season. Up to now, I was using opening_hours=* with Nov-Apr off. But I was looking for something more generic that can indicate the random aspect. I saw the proposal seasonal=* : http://wiki.openstreetmap.org/wiki/Key:seasonal Use in Europe : yes (497), no (19), winter (12), summer (9), * (2), Spring, Summer, Fall (1), Yes (1) Use in Africa : year_round (171), yes (75), wet_season (32), cannot_determine (27), another_pattern (16), dry_season (7), na_dn (1), dry_weather (1) seasonal=* does not indicate typical opening period. Any suggestion? Éric ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
