[Tagging] Weigh stations
Is there a tag in use for weigh stations, places where trucks are weighed to ensure that they are not too heavy? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
2012/4/19 Alan Mintz alan_mintz+...@earthlink.net: * PSV lanes SHOULD be included (also [2]). Example: lanes=3 and lanes:psv=1 means we have three lanes and one OF THEM is for PSV only. Same goes for HOV (high-occupancy-vehicles) lanes, unless they are separately mapped (which is a better solution for routing, given their controlled access). I will think about a phrase, that will cover all those lanes. For english and russian: suggestions from native speakers are welcome! * Turn lanes SHOULD be included (see [2] and [5]). * The lane count should change, as soon as a) new lane has reached its full width or b) a lane starts to disappear (usually a merge with another lane) (also [5]). Technically, yes, but it doesn't seem practical in developed areas in the US, which typically change lane configurations at every major intersection and then change back again. Yes - and no. That's called micromapping. I fully agree with you, that under normal circumstances it should not be necessary. But for example on motorways I actually tag this way, especially since turning lanes can be properly mapped. This way routers could precisely determine e.g. the start and end of lanes exiting the motorway and give very accurate instructions. As there are no obvious reasons to not include turning lanes, we should not exclude them. But I think about adding a statement, that usually only on major roads or very complex junctions those lanes are actually mapped. Can we agree on this? - Two-way roads with a specified lane count, but without a specified lanes:forward OR lanes:backward and a lane count, that is divisible by two, are assumed to have half of the lanes in each direction, e.g. lanes=4 means two lanes in each direction if not specified otherwise. I will add a recommendation for this situation, to add explicit values. If an odd number, assume a center turn lane (e.g. lanes=5 means 2 forward, 2 backward, 1 center). This is simply not working that way. If we would use that assumption, we would assume a lot of center turn lanes in Austria. I don't know 1 (in words: one) of them. Completely omitting those default assumptions might also not be a good idea, because in my opinion it should not be necessary to tag the lanes count on e.g. normal residential roads. How about a table for the most common types of roads? Example: residential is assumed to have one lane if one-way, two otherwise. For motorways and trunks I would not add any assumptions, because they simply differ too much. Can we agree on that? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
There is a discussion about PSV lanes, but what about emergency lanes. Nobody is allowed to use it, with the exception of people who have to stop for a car problem, or by emergency vehicles when there is a traffic jam on the other lanes (at least, that's the case in Belgium). This is not one place where you can drive to and park your car to change a wheel or so, it's a lane along a huge part of the way. As they are not open (under normal circumstances) for traffic I would use the same arguments with them as for parking lanes and therefore not include them. Do we agree on this? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, Apr 20, 2012 at 8:09 AM, Martin Vonwald imagic@gmail.comwrote: But I think about adding a statement, that usually only on major roads or very complex junctions those lanes are actually mapped. Can we agree on this? +1 Urban roads are going to be very messy if every little centre turning lane gets tagged. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Weigh stations
On 4/20/2012 4:19 AM, Georg Feddern wrote: Am 20.04.2012 09:02, schrieb Nathan Edgars II: Is there a tag in use for weigh stations, places where trucks are weighed to ensure that they are not too heavy? There is only a tag at http://wiki.openstreetmap.org/wiki/Relation:enforcement for such enforcement devices. It doesn't make sense to use a relation. It's more like a rest area (highway=services - though I just found a problem there and will send a separate message) than a traffic camera. See the photo here: http://www.dot.state.fl.us/statemaintenanceoffice/WeighStationListing.shtm#Plant%20City%20Weigh%20In%20Motion%20(WIM)%20-%20Static%20Station and the others on that page. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] highway=services/rest_area
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it (usually) has fuel and food, but it links to Wikipedia:rest area. Should the Wikipedia link be removed (and added to http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Should the word 'usually' be removed? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Weigh stations
In Europe at any rate there are proper weighbridges which drivers/operators can use to check for compliancy with weight limits or for the registration of the transport of certain bulk materials (such as coal, oil etc - the truck is weighed before and after (un)loading). There are also invisible weight sensors embedded in the normal highway surface which are used for enforcement (while driving over it at full speed!). Sometimes these are announced on signs, sometimes they are not. These are IMHO very similar to speed cameras, which, by the way, can also often tell the difference between cars and trucks and apply the appropriate speed limit. If the police suspect a vehicle is overweight they can also require the vehicle to follow them to a convenient public (or, by agreement with the operator, private) weighbridge for a check. So some weigh stations can be seen as a public facility, some are a private facility, and some are for enforcement. Colin On 20/04/2012 10:42, Nathan Edgars II wrote: On 4/20/2012 4:19 AM, Georg Feddern wrote: Am 20.04.2012 09:02, schrieb Nathan Edgars II: Is there a tag in use for weigh stations, places where trucks are weighed to ensure that they are not too heavy? There is only a tag at http://wiki.openstreetmap.org/wiki/Relation:enforcement for such enforcement devices. It doesn't make sense to use a relation. It's more like a rest area (highway=services - though I just found a problem there and will send a separate message) than a traffic camera. See the photo here: http://www.dot.state.fl.us/statemaintenanceoffice/WeighStationListing.shtm#Plant%20City%20Weigh%20In%20Motion%20(WIM)%20-%20Static%20Station and the others on that page. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
Am 20.04.2012 10:46, schrieb Nathan Edgars II: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it (usually) has fuel and food, but it links to Wikipedia:rest area. Should the Wikipedia link be removed (and added to http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Uhmm, difficult, because the linked wikipedia article refers to rest area _and_ service area. I would differ between highway=rest_area as rest area (min. parking and rest rooms, may be a picnic area or a very small kiosk, but no further service) and highway=services as service area. (min. any 'full' service like refuel, restaurant, accomodation) Should the word 'usually' be removed? Possibly, at least I am expecting a fuel service at highway=services - but that may be a result of my german / european practice. I do not know of service areas with accomodation only, just of fuel and optional restaurant, optional accomodation. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
Nathan Edgars II wrote: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it (usually) has fuel and food, but it links to Wikipedia:rest area. Should the Wikipedia link be removed (and added to http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Should the word 'usually' be removed? As I read it, Wikipedia:rest_area encompasses both highway=services and highway=rest_area. The highway=rest_area page was created by an Australian, and I suspect it reflects the situation in (Eastern) Australia*. It links to Wikipedia:rest area#Australia. There are similar non-service rest areas in other countries of course - lots in the US, and there's at least one in the UK. I'd say the wikipedia links are about right as thet are Cheers, Andy * I don't remember seeing one in a few thousand km of driving in Western Australia last year. Bottle-shops, plenty... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
On Fri, 2012-04-20 at 06:43 -0400, Nathan Edgars II wrote: On 4/20/2012 5:50 AM, Georg Feddern wrote: Am 20.04.2012 10:46, schrieb Nathan Edgars II: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it (usually) has fuel and food, but it links to Wikipedia:rest area. Should the Wikipedia link be removed (and added to http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Uhmm, difficult, because the linked wikipedia article refers to rest area _and_ service area. Wikipedia:service area redirects to rest area, so I'm going to change it to that. At least it won't give the wrong impression to someone skimming the description. I think Wikipedia is very wrong on that one, and we really should not follow it. To give the impression that you will get fuel, food or drink at a rest area is misleading. A rest area is a place to stop (to rest), that may have a WC, picnic tables, somewhere maybe to set up a barbeque but no 'services' are available. At a service area you can also get fuel, there will be a shop and cafeteria/restaurants. Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Am 05.04.2012 04:27, schrieb Eckhart Wörner: Hi, (sorry for starting a new thread, I just subscribed to the list) infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have developed an improved tagging scheme for TMC data which we would like to propopose to the OSM community. I believe this is much needed, so thank you for starting this effort. The one thing I like very much about the proposal is that it allows people to start using TMC information without spending too much time implementing insane heuristics or programming shortest path algorithms. However, I feel like there are some problems with your design, which should be discussed on a mailing list, since Wiki discussions are ugly. 1) The big problem: missing directional information Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also has real-time traffic information that talks about a traffic jam at LCD 456, negative direction, extent 1. One therefore knows that this traffic jam affects DE:123-456, and since we have a way with that information, we know that this way is affected. However, there's one problem: which direction of the way is affected? It could be either the direction from the first point of the way to the last (called forward from now on), or vice versa (backward). This essential information is missing and makes the TMC information on non-oneway ways useless. There are several solutions to this problem. Probably the best solution is not using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus assuming the direction of the way is from LCD 123 to LCD 456, the tagging would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. forward and backward are already used in tagging (for example, maxspeed:forward) and are also protected by tools. E.g. if you try to reverse the before-mentioned way, JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing to do in that case). That's no problem at all. The TMC direction must not be mixed up with the driving direction, which here does not matter at all. All that counts is the direction given (and defined) by the TMC data. If a traffic event extends forward woth respect to the direction defined by TMC, then + is used, if it extends in the revers direction, we use -. This is very concise, and using forward or backward instead would just blow the tags. 2) A matter of taste: + and - I'm not sure how others are feeling about this, but I find DE:123+456, DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes DE:123-456, and DE:456-123 becomes DE:123-456 (notice the changed order). Therefore, the LCD order is encoded in the position of the numbers, and the movement between the LCDs is encoded in the arrow. I would go even one step further and allow ← (LEFTWARDS ARROW; U+2190) and → (RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody knows how to enter these codes, but every editor and every operating system nowadays should be able to display them, and we have full unicode support in the database. Because of 1), DE:123/456 does not make sense at all. OK, I think special unicode characters should not be used at all because compatibility is uncertain and they are not available at any keyboard. Using + and - is just straightforward. I would not expected intereference or incompatibility with any other software from these, and for the tests that we made so far everything works fine. However, anybody having made experience with the issue what special characters to use for tagging without running into compatiblilty problems: Please would you share your ideas, your opinion is greatly appreciated. 3) Bad influence: TMC information at junctions One thing that I cannot wrap my head around is the TMC information *at* junctions. As far as I remember, a traffic jam at LCD 456, negative direction, extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual junctions 123 or 456. However, the rules of adding tmc tags to the actual junctions influence a lot of maneuvers going over those junctions but not using any other part of the way. This is especially true for roundabouts or junctions between dual carriageways. Please could you supply an image, or probably refer to the figures and the numbering that we use in the proposals examples? That would make it a lot clearer. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) Isn't that just a matter of the granularity of TMC location coding versus OSM mapping? If so, then there's nothing to help about that with any TMC tagging scheme
Re: [Tagging] highway=services/rest_area
Am 20. April 2012 14:21 schrieb Philip Barnes p...@trigpoint.me.uk: I think Wikipedia is very wrong on that one, and we really should not follow it. +1, we might even think of correcting it in WP. To give the impression that you will get fuel, food or drink at a rest area is misleading. A rest area is a place to stop (to rest), that may have a WC, picnic tables, somewhere maybe to set up a barbeque but no 'services' are available. At a service area you can also get fuel, there will be a shop and cafeteria/restaurants. +1, it is the same situation in Germany, Italy and probably mostly anywhere. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Thu, 2012-04-19 at 12:33 -0700, Alan Mintz wrote: If an odd number, assume a center turn lane (e.g. lanes=5 means 2 forward, 2 backward, 1 center). You cannot assume that, many 3 lane roads have a 'chicken' lane. Where the centre lane is used for overtaking by traffic in either direction. The presence of a solid and broken line together indicating that you should give priority to traffic overtaking but travelling in the opposite direction. But allows you to overtake otherwise. Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 2012-04-20 at 09:09 +0200, Martin Vonwald wrote: For motorways and trunks I would not add any assumptions, because they simply differ too much. Can we agree on that? +1 Very much agree with you there. Trunks in particular can vary enormously, from practically motorway standard roads to having to give way to traffic coming in the opposite direction because they are not wide enough for two vehicles to pass. When I was a child, back in the 1960s I can remember trunk roads, in Scotland, that were single lane with passing places, although I don't think they exist anymore, but am prepared to be proven wrong. Which prompts another question, do we have a tag for a 'passing place'? There is a photo of one on this page http://en.wikipedia.org/wiki/Single-track_road Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf: 1) The big problem: missing directional information Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also has real-time traffic information that talks about a traffic jam at LCD 456, negative direction, extent 1. One therefore knows that this traffic jam affects DE:123-456, and since we have a way with that information, we know that this way is affected. However, there's one problem: which direction of the way is affected? It could be either the direction from the first point of the way to the last (called forward from now on), or vice versa (backward). This essential information is missing and makes the TMC information on non-oneway ways useless. There are several solutions to this problem. Probably the best solution is not using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus assuming the direction of the way is from LCD 123 to LCD 456, the tagging would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. forward and backward are already used in tagging (for example, maxspeed:forward) and are also protected by tools. E.g. if you try to reverse the before-mentioned way, JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing to do in that case). That's no problem at all. The TMC direction must not be mixed up with the driving direction, which here does not matter at all. All that counts is the direction given (and defined) by the TMC data. If a traffic event extends forward woth respect to the direction defined by TMC, then + is used, if it extends in the revers direction, we use -. This is very concise, and using forward or backward instead would just blow the tags. Please re-read my argument. (Note that I use positive/negative to indicate a direction along TMC chains, and forward/backward to indicate a direction along an OSM way). Arguing that the driving direction does not matter at all is wrong as soon as you're not talking about oneways anymore. An event affecting the positive direction of a TMC chain may affect either the forward or the backward direction of an OSM way, and this entirely depends on the OSM way. 3) Bad influence: TMC information at junctions One thing that I cannot wrap my head around is the TMC information *at* junctions. As far as I remember, a traffic jam at LCD 456, negative direction, extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual junctions 123 or 456. However, the rules of adding tmc tags to the actual junctions influence a lot of maneuvers going over those junctions but not using any other part of the way. This is especially true for roundabouts or junctions between dual carriageways. Please could you supply an image, or probably refer to the figures and the numbering that we use in the proposals examples? That would make it a lot clearer. See http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Auswirkungen_von_TMC-Nachrichten_an_Kreuzungen for a discussion of the problem. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) Isn't that just a matter of the granularity of TMC location coding versus OSM mapping? If so, then there's nothing to help about that with any TMC tagging scheme whatsoever. Unless I'm wrong (and I haven't read the TMC specs in a while) this should be possible with TMC, OSM just needs to supply the relevant data. Anyway, parts of this have been covered in a different mail. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
On 20/04/12 14:32, Heinrich Knauf wrote: Am 05.04.2012 04:27, schrieb Eckhart Wörner: Thanks for you effort. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) Isn't that just a matter of the granularity of TMC location coding versus OSM mapping? If so, then there's nothing to help about that with any TMC tagging scheme whatsoever. I am not that into TMC but I thought there is a difference between a TMC Point and TMC Roads/Segments and that either a TMC Point might be blocked or some part of a Segment/Road (from Point A till Point D) with the TMC Points unblocked. Please tell me if I am wrong. With the new tagging system there is no difference between a way which is part of a TMC Point (eg roundabout or junction with several slip roads). In your wiki example of the roundabout let there be a small road intersect from the northeast. In order to get there comming from Point 7 you need to turn at the roundabout about 300° and using part of (20+8) and (20-5). Would this still work ? 5) Versioning You argue that versioning is not needed, since data can be changed in a timely manner, and the errors that appear are mostly harmless. I don't feel that way: a) Experience tells that data is not always changed in a timely matter, especially since TMC data does not appear on most of the maps. It takes a while to process data (being half a month outdated seems to be normal even for online routing), and offline maps make this situation worse (just look at the bug reports at MapDust that appeared since Skobbler had started shipping offline maps). b) When LCDs are inserted into chains, things break *badly*, since the extents are then out of sync as well. Since TMC tags will simply be part of all other road network data that any solution will use for mapping, navigaiton, etc., they will always fit together from the time of creation. So there's n need for versioning. On the other hand, it is abolutely certain that the issueing organisations that are in charge of TMC (like BASt in Germany) will never re-cycle previosly used location codes in a way that might create trouble. In my region there was and still is TMC data of the future available (version 9). This is due to changing routes and up/downgrading parts of the road system. The decision was made before the (re)constuction was finished. E.g. TMC data leads along roads with heavy constuctions or even non existing roads and was/is inconsistant with the routes on the ground (traffic signs). With the versioning I was able to tag the current (old) route and the future one. Best regards, Mit freundlichen Grüßen, Heinrich Knauf ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf: 2) A matter of taste: + and - Using + and - is just straightforward. I would not expected intereference or incompatibility with any other software from these, and for the tests that we made so far everything works fine. I'll take this one back, in the context of my other mails + and - look like a sane solution. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 20. April 2012 14:21 schrieb Philip Barnes p...@trigpoint.me.uk: I think Wikipedia is very wrong on that one, and we really should not follow it. +1, we might even think of correcting it in WP. To give the impression that you will get fuel, food or drink at a rest area is misleading. A rest area is a place to stop (to rest), that may have a WC, picnic tables, somewhere maybe to set up a barbeque but no 'services' are available. At a service area you can also get fuel, there will be a shop and cafeteria/restaurants. +1, it is the same situation in Germany, Italy and probably mostly anywhere. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging In the USA, you have the same distinction between service areas and rest areas. In addition, there will sometimes be parking areas, meaning that there will be a parking lot but no restrooms or other amenities. Fortunately, parking areas are rare. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Weigh stations
On Fri, Apr 20, 2012 at 2:02 AM, Nathan Edgars II nerou...@gmail.com wrote: Is there a tag in use for weigh stations, places where trucks are weighed to ensure that they are not too heavy? I think the only thing I've done for weigh stations so far is put a exit_to=Weigh Station on the exit nodes on interstates. But I could certainly see using a highway=weigh_station or something like that for the area, similar to highway=rest_area|services. Is there any use in noting wich weigh stations support PrePass[1]? Maybe just a prepass=yes|no tag? This is clearly visible on the road with signs that tell drivers to follow in-cab PrePass prompts plus the overhanging sensors to read the transponder. [1] http://www.prepass.com/services/prepass/Pages/WhatIsPrepass.aspx Toby ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Voting : Isolated buildings in mountain/wild used by hikers(/...) for shelter/sleeping/eating
Hi, After the huge clean up, improve and re-wording by rudof (thanks rudolf) the 4 proposals are open for a vote at : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Alpine_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wilderness_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Basic_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lean_to The grouping page is here : http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings Please use the talk page for generic comments on all 4 proposal here : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/wilderness_mountain_buildings Or use one of the 4 specific proposal pages if you want to comment on one specific tag -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On 20 April 2012 14:35, Philip Barnes p...@trigpoint.me.uk wrote: Which prompts another question, do we have a tag for a 'passing place'? There is a photo of one on this page http://en.wikipedia.org/wiki/Single-track_road Tag info shows it does highway=passing_place does get used http://taginfo.openstreetmap.org/search?q=highway%3Dpassing And there is a page on the wiki for it. And here's another question. A twoway single lane highway implies that if you meet a vehicle coming in the other direction the road is blocked. Hence the the common of existence, at least in the UK, of 'Passing Places' mentioned by Philip. A twoway two lane highway implies that common road vehicles can drive down the road each within their own lane? But there is a third situation that in my area is arguably more common than implied single lane status, and that is a road which is wide enough for cars to pass each other at at crawl, but which would be blocked if a large vehicle meets another vehicle. This I assume is impotant information, especially for routing, because these are roads a car owner would wish to avoid if there is an alternative 'true' 2 lane road, and which a lorry or van should avoid unless they must use the road. A while back I went through a period of trying to add lanes, speed limits, and lighting info. This was prompted by the excellent tools produced by ITO map eg www.itoworld.com/map/179 While trying to sort through the confusing speed limit laws in my country, I stumbled across a document advising that roads where two cars could pass slowly or with care, but wider vehciles could not, the road should be considered to consist of 1.5 lanes. Didn't bother to save the document at the time and search engines can't track it down. Does the idea of lanes=1.5 seem acceptable for roads where cars can pass slowly, but wider vehicles will block the road. There is an obvious problem that the decision to label a road as lanes=1.5 is subjective. Jason ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
I want to come back to the question from fly: how shall TMC-points be tagged (or shouldn't they?). Somehow we should have them visible in the Editor (because otherwise tagging TMC on ways would also become difficult), but besides from having them explicitly in the data maybe they could also be pulled from a parallel system at editing time. They are official anyway, and there won't be much need for a mapper to move them around or modify them in other ways. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=services/rest_area
Am 20. April 2012 16:18 schrieb John F. Eldredge j...@jfeldredge.com: n addition, there will sometimes be parking areas, meaning that there will be a parking lot but no restrooms or other amenities. Fortunately, parking areas are rare. we also have these, I'd include them in rest_areas. Basically you can rest there, even if there is no toilet. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag disputed names in the same language?
In the proverbial case of of Northern Cyprus, disputed names are easy because both sides use different languages, Greek (el) and Turkish (tr). What if the dispute names are in the same language? I was wondering about this because Philippines and China are currently in a stand-off regarding an atoll in the South China Sea. The atoll is int_name=Scarborough Shoal but in English, the Philippines calls it Panatag Shoal and China calls it Huangyang Island. How do we tag these two names? One possible way is to introduce ISO country codes (in all caps) and with a format similar to int_name:: PH_name:en=Panatag Shoal PH_name:tl=Isla ng Panatag CN_name:en=Huangyang Island CN_name:zh=I have no idea But a possible problem is that the country codes might be confused for the language codes, though using all caps should mitigate the confusion. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag disputed names in the same language?
Who is in actual control of the atoll? Are there people living there? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag disputed names in the same language?
At 2012-04-20 08:29, Eugene Alvin Villar wrote: One possible way is to introduce ISO country codes (in all caps) and with a format similar to int_name:: PH_name:en=Panatag Shoal I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF language tag format. -- Alan Mintz alan_mintz+...@earthlink.net ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] demolished buildings, temporal component of data
In some regions of the world OSM is already in a state where many of the map modifications are not due to missing or wrong data, but result from actual changes in the real world, e.g. a building gets demolished. Given that we store not only the actual state of the DB but also record all kinds of changes that the mappers apply, I wonder if we shouldn't agree on some formal mechanism to distinct the changes where the map gets updated to the real world from those where the edit is done to correct mapping errors, to increase the level of detail or to store them for the first time. Since the introduction of API 0.6 we have in theory one powerful tool where this detail can already be associated to the edit: the changeset comments. The only missing link for effective automated evaluation would be an agreement on a formal way of storing information there (and quite some discipline in structuring your edits and uploads ;-) ). E.g. we could use hashtags to distinguish free text from formal comments ( e.g. #demolishion , #new_construction ,etc) An alternative could be, e.g. for a building that was demolished, to explicitly map this. Given an object tagged with building=yes we could change the tag to building=demolished, upload to the server, and in a second step delete the object and upload again. The deletion and second upload could even be automated easily in the editors, if we could agree on something like this. As an advantage with the second method you would not need to structure your edits and changesets in a special way, I'd expect to get more reliable results and less oversight with this approach. Is someone already using a scheme for this kind of information? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] demolished buildings, temporal component of data
On Fri, 20 Apr 2012, Martin Koppenhoefer wrote: In some regions of the world OSM is already in a state where many of the map modifications are not due to missing or wrong data, but result from actual changes in the real world, e.g. a building gets demolished. Given that we store not only the actual state of the DB but also record all kinds of changes that the mappers apply, I wonder if we shouldn't agree on some formal mechanism to distinct the changes where the map gets updated to the real world from those where the edit is done to correct mapping errors, to increase the level of detail or to store them for the first time. Since the introduction of API 0.6 we have in theory one powerful tool where this detail can already be associated to the edit: the changeset comments. The only missing link for effective automated evaluation would be an agreement on a formal way of storing information there (and quite some discipline in structuring your edits and uploads ;-) ). E.g. we could use hashtags to distinguish free text from formal comments ( e.g. #demolishion , #new_construction ,etc) Changeset comments/tags are very problematic because they're not fixable once you realize you made a mistake. An alternative could be, e.g. for a building that was demolished, to explicitly map this. Given an object tagged with building=yes we could change the tag to building=demolished, upload to the server, and in a second step delete the object and upload again. The deletion and second upload could even be automated easily in the editors, if we could agree on something like this. As an advantage with the second method you would not need to structure your edits and changesets in a special way, I'd expect to get more reliable results and less oversight with this approach. Is someone already using a scheme for this kind of information? was: prefixes and keeping geomtery which also helps to prevent somebody too eager from redrawing from imagery (which ahs certainly happened multiple times around here). :) -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] demolished buildings, temporal component of data
Hi,
On 04/20/2012 06:31 PM, Martin Koppenhoefer wrote:
Since the introduction of API 0.6 we have in theory one powerful tool
where this detail can already be associated to the edit: the changeset
comments. The only missing link for effective automated evaluation
would be an agreement on a formal way of storing information there
The changeset *comment* is just that, a comment that should be
human-readable. But many people forget that changesets can have any
number of tags, so instead of adding machine-readable hash tags into the
comment field, just invent new tags for the changeset, e.g.
type_of_edit={initial|geometry_fix|change_in_real_world|revert|...}
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag disputed names in the same language?
On Apr 20, 2012 9:04 AM, Alan Mintz alan_mintz+...@earthlink.net wrote: I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF language tag format. en-PH feels more correct, since it's specifying dialect in a standard format. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
