Re: [Tagging] Power generation refinement: power plant model evolution
Hi! Am 09.04.2013 um 17:22 schrieb François Lacombe francois.laco...@telecom-bretagne.eu: In my mind, define a role in a relation is mandatory but you say it's definitely not right. Roles can make sense. For example ways in a route relation may have the role forward or backward, if this specific way is only used in one direction. This is a property of the route and not of the way, therefore it is tagged as role in the relation. A generator is different. It simply is a generator and its role within the plant is to be a generator. So there is no need to explicitly specify it. Furthermore think of the consumers. Example: the process one feature of the plant. If the plant is described by a relation the consumers have two sources about the type of that feature: the tags on the feature and the relation. As the relation is not always present they will trust the tags on the feature and ignore the role in the relation. I agree to say generator / substation and other roles are not relevant and maybe redundant but they formalize association between features and power plant, which features' tags (or plants' tags) won't do ever since they're attached to objects, not to the link between objects. Which association would they formalise? If a generator is part of a plant its function (aka role) is to work as generator. The association is created by adding the generator to the plant. To make proposal lighter I would consent to remove generator, substation roles and most of the specific roles from non-enclosed power plants relations (perimeter has already left the proposal as you maybe noticed). I'm just curious about the perimeter: what would we do if a plant has multiple perimeters? How would we map them? But that will allow mappers to use any values they want to use, not convince them into letting the role field blank. Does it matter? Besides some special roles defined by the proposal, what would a consumer do with an unknown role? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
Hi! Am 08.04.2013 um 04:44 schrieb John Baker rovas...@hotmail.com: As you are talking about rendering of the roads. I am actually looking at this for the new cartoCSS mapnik style for osm.org. Have you had a look at the style Lane and road attributes for JOSM? I know it's not a cartoCSS style but it demonstrates how a detailed road rendering could look like and with the additional capabilities of cartoCSS you should also be able to solve the connection problem, i.e. if the number of lanes changes. It's sad that we don't have a common style language for (at least) the major editors and renderers. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Hi! Am 08.04.2013 um 00:03 schrieb François Lacombe francois.laco...@telecom-bretagne.eu: Hi again :) 2013/4/7 Martin Vonwald imagic@gmail.com Hi! Actually how could that happen? I don't have example, I was only guessing. Assuming 2 different power plants with output generators in each (and links for power exchanges between both) would help us to solve that kind of issue. = All right, my objection was stupid! Lets call it discussion, then it's not stupid anymore ;-) I was about to suggest the same as Martin Koppenhöfer: additional tag on the generator itself. Putting the generators of a plant into categories (category A: output, category B: intermediate) by using a relation sounds to me like this: [1] . I'll update proposal with following generator tag values: generator=output or generator=intermediate (generator=* key doesn't exist). I like readable tags. When I read generator=output I have no clue about its meaning. Every generator has output. So I definitively would add the word plant there anywhere. Thus all generators of a power plant would be added to an hypothetic power=plant relation with role=generator. This will be convenient to make the distinguishing on generator's tags and only there. What could be the role of a generator if not generator? You wrote all generators ... with role=generator - so the role does not have any meaning. Then drop it. Also: if I simply add all the perimeters of a multi-site plant to the relation, I don't need anything else in the relation. It would also be more robust. Think of Joe Mapper who adds a newly built substation within the perimeter of the plant. A relation was created earlier by a different mapper. Joe doesn't know/care about the relation so he only adds the substation. If the relation only contains the perimeters it is still complete and the new substation is now part of the plant. If the relation has to carry all of the features it is now broken. And furthermore: how can we find such broken relations? Of course if there is no clear perimeter (e.g. wind parks) the features themselves have to be added. Same goes for the substations by the way. It's different for substations. No categorization for them. My point was more like: if we have the perimeters we don't need this information about the substations. But see below! Nevertheless they could easily be placed off the perimeter of a single site power plant. How to make links in that particular case? Is it still part of the plant? In France for instance, substations and power grid are operated by RTE and power plants by different companies. So they are two different features. A plant and a substation. Have a look to Tricastin nuclear power plant (biggest one I mean) : http://goo.gl/maps/HcyIf Power plant perimeter is between Rhone river and publicly accessed road D459 with 4 reactor buildings. Substation is behind a private uranium enrichment plant (big white buildings) which is not part of the power plant so we can't put a whole closed way around that stuff. Does it really belong to the plant? Or is the output of the plant transferred to the substation outside of the plant, where it is further transformed? If you ask the operator of Tricastin if this is their substation, what would be their answer? And what would be the answer of RWE? I don't see anything else than a relation to bring substation and power plant together. If they don't belong together they shouldn't be brought together ;-) You may say it's not a single site power plant. = Many situation like above would be encountered so we won't actually have so many single site power plant. = Only the substation is off the power plant site. Do we have to link substation and power plants this way? See above. Two different operators might be a good clue that they don't belong to each other. Best regard, Martin___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki article about key hov
Hi! Am 29.03.2013 um 00:15 schrieb Paul Johnson ba...@ursamundi.org: I tend to go with access=no, hov=*, and possibly motorcycle=yes or psv=designated, since I've yet to find an HOV road that allows you to walk, ski, ride an animal or a bicycle, etc. on it; it literally only allows the modes specified. The question was primarily about the values of the hov-key. Obviously we agree on this. One more question: am I correct that any numeric value should be treated as designated? Although I don't really like this deviation from the other access tags why not use a separate key for the minimum requirement? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Amenity=shelter for field shelter?
Hi, Are there any arguments against using amenity=shelter + shelter_type=field_shelter for field shelters (see [1]) for horses? From the wiki: The amenity=shelter tag marks all sorts of small shelters to protect against bad weather conditions. Sounds good to me. Regards, Martin [1] http://www.herefordstables.co.uk/imgs/gallery/10_12ft-field-shelter.jpg___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 15:01 schrieb Janko Mihelić jan...@gmail.com: I think that's harder than you think. What if you have the next example: http://i.imgur.com/ETBsfSQ.png How does the renderer preprocesor know if the middle line is inside the bridge area? It has to make some difficult calculations for that. And the blue line is outside, although it shares two nodes with the bridge. (I know it would rarely happen, but it will happen.) If I'm not mistaken it could work like this: If a way with bridge=yes is connected to a way with man_made=bridge follow the way with bridge=yes and all connected ways until you reach a way without bridge=yes. All those ways belong to the bridge marked with man_made=bridge. Regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 15:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: That's why I promoted to keep bridge=yes nevertheless (see previous posts) We definitively should keep bridge=yes! Regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tunnels and bridges
Am 01.02.2013 um 00:01 schrieb Michael Kugelmann michaelk_...@gmx.de: On 31.01.2013 12:06, Martin Vonwald wrote: I'm looking for some alternatives to map tunnels and bridges that contain several ways. I'm not really happy with the proposed relation -1 The current method is used and well established since years and for my point of view works fine. So I clearly dislike to change it. What current method do you refer to? The key bridge or the proposed relation? When reading through the responses in this thread I get the impression that there is need for a simple way to specify what OSM-ways belong to one, single bridge. Regarding the relation: there was a short discussion about a waterpark short time ago. It was asked if all the features should go into a site relation. The answer was (as I remember it): no. Only if the features are spread over different places. We have a spatial database so if all features are within a closed way there is no need for a relation. Why is there a different reasoning for a bridge? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
Am 25.01.2013 um 20:23 schrieb Ole Nielsen on-...@xs4all.nl: It is a little bit sad that the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement died due to lack of votes. It would have resolved these problems. Maybe somebody could review and eventually improve it and put it forward for a new vote (this time advertised properly). I definitively would support this! Maybe we should just reopen it for RFC for a month or two and then put it up for a vote. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] wiki building=hangar
I didn't invent neither building:use nor building:type. I was also curious about building:type. I've seen these keys somewhere - cant remember where - and thought they were accepted. Obviously I was wrong. Regards, Martin Am 23.01.2013 um 16:59 schrieb Martin Koppenhoefer dieterdre...@gmail.com: 2013/1/23 Martin Vonwald imagic@gmail.com: I just want to add my understanding of the building tags: building=xxx (with no other tags like building:use): it looks like a xxx and is used as xxx building:use=xxx: it is used as xxx, but might not look like one building:type=xxx: it looks like xxx, but might not be used as xxx I'm not sure I get this. If we say that the value for key building is a building type, then the key building:type would be the same, no? The key building:use on the other hand is usually given by other keys (landuse, shop, amenity, office, craft, tourism, aeroway, railway, ...) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
Hi! Am 03.12.2012 um 20:27 schrieb Ole Nielsen on-...@xs4all.nl: I intentionally chose not to deprecate maxspeed:wet as I had the feeling that doing so might upset some people and I didn't want such minor issues to affect the voting process. Of course I will recommend to use the conditional scheme and hope we can make a recommendation to deprecate the maxspeed:wet tag if there is no strong opposition to do so. The reason why I asked was: will someone complain if I change maxspeed:wet to maxspeed:conditional when I encounter it? I don't think so but better safe than sorry and therefore I asked ;-) BTW, I'm not sure how useful the wet tag (old style or new style) is. You will need some damn precise and detailed weather forecasts for a route planner to be able to use such information. And usually it is only fairly short sections of highway having such tags so the impact is minimal (and in my experience drivers pretty much ignore such signs anyway). I guess the best answer to this is: 640 kB ought to be enough for anybody. ;-) I completely agree with you, but who knows what some clever people invent tomorrow. As I already have the information about those signs it doesn't hurt to put it into the database. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Exclusive access rights
Hi, Am 31.10.2012 um 23:49 schrieb Johan C osm...@gmail.com: Ok, so what you guys are saying is that http://wiki.openstreetmap.org/wiki/Map_Features#Restrictions is wrong on the description of motor_vehicles. Fine to me, but I would appreciate an improvement of that page then. How can that be achieved? No, I'm not saying its wrong, I'm saying it seriously outdated. Which might be related to the fact that I've never seen this page before and I guess there might be a few more who haven't. I'm also not sure if such a page is a good idea, because it will always be outdated. Currently we are unable to keep different language versions of single articles synchronised, so how can we expect to keep such articles up-to-date? Especially as this is not a specialised article about a single topic for which some people might feel responsible, but some all-in-one article. Maybe it would be better to reduce such articles to a link collection pointing to specific articles about one single topic? Martin___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Exclusive access rights
Hi, The problem is the hierarchy of the access tags (see Land-based transportation in http://wiki.openstreetmap.org/wiki/Access): the tag vehicle=no implies motor_vehicle=no and e.g. bicycle=no, the tag motor_vehicle=no implies e.g. psv=no and goods=no, and goods=no implies hgv=no. At least that's the way I understand it. And yes, this is neither perfect nor always intuitive. What about a cycle rickshaw? It's definitively a psv but most definitively not a motor_vehicle. Of course there is this great sentence in the access article: This hierarchy is different in each country. That's not making anything easier. I'll guess I have another look at the access 1.5 proposal which tries to clean up a little: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 Martin Am 31.10.2012 um 18:56 schrieb Johan C osm...@gmail.com: I don't think I understand both responses (Georg/Martin). Why should a hgv and a psv use 'a kind of' motor_vehicle? According to the map features motor_vehicle is used for: 'Access permission for motor cars and motorcycles.' A bus or a truck is not one of these two types. If I put 'motor_vehicle=no' on any highway, then psv and hgv are still allowed to drive on that highway. Am I misreading the map features? 2012/10/31 Martin Vonwald imagic@gmail.com 2012/10/31 OSM o...@bavarianmallet.de: I am sorry to disagree, but if hgv and psv use a kind of motor_vehicle, they are still not allowed on the rightmost lane then ... according to the tagging. Georg I have to agree with Georg... of course unless the lanes are exclusively for horse-drawn cabs or carriages ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Exclusive access rights
Am 29.10.2012 um 14:27 schrieb Tobias Knerr o...@tobias-knerr.de: It is currently not valid - vehicle types can only appear in the key, whereas groups of users (forestry, customers, delivery, ...) can only appear in the value. For the groups of users, it actually gives exclusive access rights to that group. That's how I understand it. Thanks for the confirmation. I can imagine changing this if we find a nice definition. Of course applications would not be compatible with that at first, but mappers could simply refrain from using it excessively and limit the use to lanes and similar cases where compatibility doesn't matter as much. I'm afraid that we wouldn't get app-support for this. On the other hand if mappers are forced to use a lot of tags simply to specify what kind of vehicles are allowed for each lane, I believe most mappers will just forget about it. It's not worth the hassle especially as in the beginning no apps would support it. And as no-one maps it then why should apps support it? That's one of the drawbacks of the consumer-centered view: create theoretically perfect tagging schemes that are wonderfully easy to process - and so hard to map that there's no need to implement the processing because no one is using the scheme. http://en.wikipedia.org/wiki/KISS_principle Martin___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency lane used by PSV at rush time
Am 16.10.2012 um 21:30 schrieb Eric SIBERT courr...@eric.sibert.fr: 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. I'll update the english, german and russian article accordingly if there are no further objections. (Other translations are welcome to keep the articles consistent). Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
Am 15.10.2012 um 17:55 schrieb Markus Lindholm markus.lindh...@gmail.com: But as I'm sure you've noticed there's some divided opinion about this. That's why I asked! Actually I don't think that we see any consensus about this soon. But then I can document at least that there are two variants under discussion. If I claim in the wiki that a) is the ultimate solution it will be fixed by supporters of b) and vice versa. As I don't like edit wars I prefer to write the truth: both are used. I don't claim this is perfect (or at least good) but it is the current status-quo. As soon as there is a consensus about this issue I'm happy to update all affected wiki articles. But I'm a little afraid that I won't live long enough ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
Am 13.10.2012 um 14:48 schrieb Janko Mihelić jan...@gmail.com: 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. A narrow bridge is a narrow bridge: a bridge with a small width. Therefore simply use the width key. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Uses of parts of buildings
Hi, A quick question how you would tag this: * one building (looks from the outside mostly like a residential building) * the building is used for three different things: an office, a riding ground (just assume it's a pitch) and a stable. * the building is not separated - it's just one building * I'm not interested in the detail- tagging, just how you would tag three different uses. My idea right now is: * building=yes for the whole building. Or should it be residential? * for each part draw a separate polygon and tag with building:use=whatever. What I'm missing here is the connection between the building and its parts. So I thought I could use the 3D-extensions for this, namely building:parts=yes on the main polygon and building:part=yes on the parts. Comments? Hints? Thoughts? Thank you, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Map for surface/smoothness?
Am 11.09.2012 um 16:10 schrieb Georg Feddern o...@bavarianmallet.de: http://roads.osm4people.org/?zoom=7lat=49.60305lon=10.72137layers=B0TFF Thanks! This covers surface, but smoothness isn't supported as far as I can see. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Completely off-topic: native speakers for a short survey needed
Hi, First I have to excuse myself for this 100% off-topic mail. I nonetheless sent it to this mailing list because here might(!) be the right target group. I need a few volunteers for a short survey. They need to be native speakers, preferable from GB, and not(!) involved in the legal or financial sector (that's why I'm looking here). I would send them a few terms and they should tell me what they think what these terms mean. This shouldn't take longer than a few minutes. Background for this is the standardisation of terms in some part of the financial sector within the EU. Currently many terms used in this sector are very hard to understand for people not involved in the financial sector. To improve this situation a new set of terms should be defined which is easier to understand for everyone. If you want to take part in this survey please contact me direct and do not(!) send your response to the list. Once again: sorry for this off-topic mail. Kind regards, Martin Vonwald ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - blue_flag=yes
Just a quick thought: wouldn't it be more readable if this tag would be a subkey of beach, i.e. beach:blue_flag=yes? So you see at once that this is a property of the beach. Regards, Martin Am 06.07.2012 um 17:10 schrieb Johan Jönsson joha...@goteborg.cc: There are plenty of beaches (and marinas) that have a blue flag with a breaking wave on it, they have excellent water quality and a couple of other nice things. It wouldn´t be wrong to map these, and it is easily done with this simple proposal. When a mapper sees the flag on the beach just add the tag blue_flag=yes. Read more at http://wiki.openstreetmap.org/wiki/Proposed_Features/Blue_flag and contribute with your insights, eother directly by changing the wiki-page, writing on the discussion-page or kust reply here. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - blue_flag=yes
Am 06.07.2012 um 20:48 schrieb Martin Koppenhoefer dieterdre...@gmail.com: If you would like to subtype it, I'd use an award-namespace, similar to how it was mentioned in the other thread: award:blue_flag=yes on the entity it applies to (be it a beach or something else) This looks to me more descriptive and appropriate. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Am 05.07.2012 um 12:08 schrieb Chris Hill o...@raggedred.net: This really is the wrong way round. We must always consider the mapper *first*. If a scheme is too complex there will be no data added for consumers to use. I fully agree with you, but simply wrote it badly. We need a scheme that is supported by the database. So let's see what we actually can use and then pick that one that is most intuitive. I hope I made myself now clearer. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Am 05.07.2012 um 13:49 schrieb aighes o...@aighes.de: Am 05.07.2012 12:08, schrieb Chris Hill: This really is the wrong way round. We must always consider the mapper *first*. If a scheme is too complex there will be no data added for consumers to use. This shouldn't be a problem, because you can have a GUI for mapping such data. E.g. roadsigns-PlugIn for josm. I completely disagree! We will never have a plugin for any existing editor and any tagging scheme. IMO any scheme must always be readable for humans.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Am 05.07.2012 um 14:30 schrieb Frederik Ramm frede...@remote.org: reading this discussion again demonstrates how useless our voting process is. Sad, but true. It is obvious that this issue has not been thoroughly discussed, that there is no consensus about which problem exactly it should solve and what the implications for mappers or users would be. Again sad, but true. But why hasn't it been thoroughly discussed? At some point the discussion simply stopped. A mail trying to revive the discussion didn't receive any response. From the last votings I have observed I have to state, that a lot - yes, really a lot - of people stay silent until the voting starts. And then they all jump out of their holes and scream Oppose, Oppose! Many of them - of course - don't have any suggestions how the proposal could be improved, it just sucks in their point of view. Thank you, great help. BTW: I haven't voted yes for this proposal and also will not. But as I already wrote: the discussion simply stopped This means the whole thing isn't ready for voting. Yet I read that voting was full underway. You cannot vote *instead* of having a discussion, it won't work. Right now I think we have to vote instead of discussing because it seems to be the only way to bring people to speak. After writing all this I think that maybe not the voting is the problem, but the discussion. Especially the discussions of controversial topics die quite fast because there are (at least) two sides who - of course - think that their solution is the one and only and it can never-ever be any better. Other opinions are ignored and therefore unresponded and we reach again the Game-Over-state. What we lack often is evolution. Someone suggests a feature, others provide feedback and the proposal is continuously updated until a majority agrees. But this isn't working, because the (constructive) feedback is missing and/or not acknowledged. Enough rant - back to the beach ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - natural=bare_rock
Am 02.07.2012 um 22:09 schrieb sabas88 saba...@gmail.com: I'd opt for landcover system. +1 for landcover. IMO the tag natural should not be used for areas (yes, I know, currently it is used often for areas). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate: first summary
+1 to the summary and especially to: Am 15.06.2012 um 16:41 schrieb Eckhart Wörner ewoer...@kde.org: I would also like to ask people not to blindly start new proposals, because otherwise we'll inevitably end up with hundreds of proposals and no conclusion at all. I would even prefer to have only one, single proposal which evolves during the discussion. But, well, we all know this will never happen ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New access tag value needed?
Am 01.06.2012 um 15:01 schrieb Colin Smale colin.sm...@xs4all.nl: On 01/06/2012 14:19, Jason Cunningham wrote: On 1 June 2012 08:09, Martin Vonwald imagic@gmail.com wrote: But we have to make sure, that this values are only applied if real indications (e.g. signposts) are present and not e.g. if one just thinks that some vehicle can not drive there. The example given is within the UK. Within the UK signs or signposts haver no 'status' unless they're listed within official documents and linked to legislation. I am confident this unsuitable for HGVs sign has no legislative status. It's existence may be due to local residents asking their local politician to find a way to 'stop' HGV's following satnavs down this road because the noise reduces they're enjoyment of their evening cocktails (Very unlikely, but a possibility). Therefore it's more than possible that an 'unsuitable status sign' may refer to a road that is very suitable. People or business will place signs adjacent to UK roads in rural areas which attempt to alter the actions of drivers, and we should not map these. And if these signs are placed by the highway authority? I think these most definitely do have a place in OSM. It's then up to the data consumers whether they attach any value to them. By making the data available, we are enabling e.g. HGV routing programs to take these hints into account. Without these hints, trucks may be directed down unsuitable routes. The political process leading to their erection is not important - only their existence. Political pressure has a large influence on speed limits as well. You are both correct in my opinion. As I wrote earlier this doesn't feel like something that belongs into an access tag to me especially as you are still allowed to use that specific way. But if those signs have some official character they should have a place in OSM. What do you think about using some other key for this? Martin___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Dispute again: Re: (Mini)Roundabout: examples
Can someone please stop NE2? I'm sick and tired of this person. Beside contraproductive statements and continuous vandalism (yes, I call it this way) and can't see anything useful coming from his direction. If this isn't stop here and now I don't see any point in investing a single second in the wiki or openstreetmap at all. Am 17.05.2012 um 21:18 schrieb Nathan Edgars II nerou...@gmail.com: On 5/17/2012 3:04 PM, Martin Vonwald wrote: Hi! I updated now the english article: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout Translations will follow in the next days. Traffic circles are usually tagged as roundabouts, contrary to your statement. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Mini)Roundabout: examples
But this is exactly the definition of turning_place: a widening of the road without any island. Am 17.05.2012 um 22:23 schrieb Tobias Johansson t...@mensa.se: There is one thing. In Sweden we have something called Vändplats http://www.transportstyrelsen.se/sv/Vag/Vagmarken/Forbudsmarken/Vandplats/ roughly translated turnaroundplace usally in sweden we have used highway=turning_circle for this. According to this definition almost no vändplats would be turning_circles because: They are almost never circular (except new ones beeing built today). And there is no island in the middle. In many cases they ar more like a widening of the road so its possible to make a three-point-turn. I dont think anyone i sweden will change how we map this in Sweden because of this definition. But how do you guys feel about this? Best Regards Thod 2012/5/17 Martin Vonwald imagic@gmail.com: Hi! I updated now the english article: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout Translations will follow in the next days. Many thanks to everyone who took part in the discussion and provided valuable feedback. Stay tuned - I'll come back to you for the next article soon ;-) regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Mini)Roundabout: examples
Look at the second column for the suggested tagging. The wording turning circle is misleading here and does NOT refer to turning_circle; it should read turning place. But I will not do any more wiki-edits unless NE2 is banned so I can not fix this. Nonetheless thanks for pointing this out. Am 17.05.2012 um 22:42 schrieb Tobias Johansson t...@mensa.se: On the page you referensed to. in the table with pictures it says A round place with a traversable island in the middle, but this is neither a mini-roundabout nor a roundabout, but instead a turning circle, which allows large vehicles to turn around. 2012/5/17 Martin Vonwald (Imagic) imagic@gmail.com: But this is exactly the definition of turning_place: a widening of the road without any island. Am 17.05.2012 um 22:23 schrieb Tobias Johansson t...@mensa.se: There is one thing. In Sweden we have something called Vändplats http://www.transportstyrelsen.se/sv/Vag/Vagmarken/Forbudsmarken/Vandplats/ roughly translated turnaroundplace usally in sweden we have used highway=turning_circle for this. According to this definition almost no vändplats would be turning_circles because: They are almost never circular (except new ones beeing built today). And there is no island in the middle. In many cases they ar more like a widening of the road so its possible to make a three-point-turn. I dont think anyone i sweden will change how we map this in Sweden because of this definition. But how do you guys feel about this? Best Regards Thod 2012/5/17 Martin Vonwald imagic@gmail.com: Hi! I updated now the english article: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout Translations will follow in the next days. Many thanks to everyone who took part in the discussion and provided valuable feedback. Stay tuned - I'll come back to you for the next article soon ;-) regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] (Mini)Roundabout: examples
Am 16.05.2012 um 19:44 schrieb Nathan Edgars II nerou...@gmail.com: Does anyone have an actual use case where it's so important to know whether entering traffic yields that the user expects a completely different tag when one or more approaches has right-of-way? Penalties for routing? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 26.04.2012 um 20:03 schrieb Jason Cunningham jamicu...@googlemail.com: Major problem: You've haven't adequately dealt with the lanes=1.5 issue. You've suggested something that can't solve the issue, but simply looks like an attempt to cleanse it from the lanes tag and forget about it. Actually I thought it was solved by specifying the width. And I can't cleanse it from the database by - for the first time as far as I can see - mention lanes=1.5 in the wiki. Major Problem: The Assumptions section, I think, is a very bad idea. The 'Remark' for everything other than motorways/trunk suggests not to add the lane data, but rely on the assumption. If you do not know how many lanes are present the Assumptions table is good idea to what might be present. But surveyed data is superior to an assumption, and we must not encourage people not to add the data. In the remarks I wrote ... is usually not tagged..., which afaik is the truth. I also had the impression, that we don't want the lanes-tag on every residential road. If this is not the case I could remove the none from the residential-road-example and rephrase the assumptions. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 20.04.2012 um 16:58 schrieb Jason Cunningham jamicu...@googlemail.com: 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. Thanks for that. I would add a recommendation not to count such places for the lanes-count, but instead use the passing-tag. I will add a link to its article. 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. In my opinion, lanes=1.5 is a very bad choice. We have a tag for this situation: width . According to taginfo, lanes=1.5 is used, but not too often. What should we do? I would recommend not to use it and advise to specify a width (which is also objective rather than subjective as 1.5 is). Opinions? ___ 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? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multi-value tagging and Lane Groups
Am 08.02.2012 um 18:48 schrieb Colin Smale colin.sm...@xs4all.nl: On 08/02/2012 17:52, Martin Vonwald wrote: I suggest putting the lanes qualifier in front, allowing arbitrary tag hierarchies to follow at a fixed location. This was suggested, but dropped for better readability: see Default values; minimise ambiguity on the Discussion page. Yes, I see that now. I guess beauty is in the eye of the beholder. Tag lists are intrinsically unordered, so any sorting will be done by a machine. I admit it will have to think a bit harder to sort lanes:1:psv=yes adjacent to psv=no. But my (not-so-humble?) opinion is that the way the data is modelled is more important than the sort order of a list of tags. I spend my working life surrounded by data models, and regularly see at first hand how expedient and pragmatic solutions can come back to bite you later. OSM's tagging is dynamic, open and free. We cannot predict to what uses OSM will be put in the future, so we should implement things in a way that does not impinge on future creativity. My rationale is that having lanes as a prefix keeps it more out of the way of future changes. Actually I do agree with you. A prefix would make more sense. For a computer, for a program, for everyone who studied computer science. But for the average human? I'm not so sure about that. And we always have to remind ourselves, that a large number of mappers don't know about namespaces and actually they shouldn't. We don't gain anything if we agree on some perfect format which is a beauty as a data format, but we don't get data because only a few can handle and understand the format. You introduce a new tag applies_to to limit the lane to a certain class of vehicle, whereas I suggest reusing the existing access tags. You missed here the point, that this tag is part of a new relation, which handles lane connectivity. Can you give an example of when this would add something to the mix, compared to a restriction relation following the current specs plus the lane information? If there is no right turn from a left-hand lane, wouldn't the left-hand lane just be tagged for left/straight only? You say yourself that it will rarely be needed. This whole idea feels like a solution looking for a problem. The connectivity relation (maybe we need a better name) does not set any restrictions! It just states what markings are on the road and what lane connections are present, which are not obvious. This information is necessary for navigational devices to tell you on which lane to stay. It is not sufficient to know, that you need to be on the right-turn lane to turn right (surprise! ;-) ) but the navigational devices needs to know which lane leads to this right-turn lane to give you precise instructions. There are already (as you note in your proposal) turn restriction relations. If they are to be applied to lanes, maybe the way should be split for the 50m or so in the approach to the junction, and then we won't need a new construct. That is a very bad idea. Splitting the way would mean, that there is no possiblity to switch between the lanes (as they are separated), which in reality often is not correct. This would also break routing. Where I am (NL) it is actually an offence to not follow the arrows on the lane in which you are driving. So if you are in a left-turn lane (marked as such), you must turn left. In theory at least... But I agree, this will not be the case everywhere. If a road is still modelled as a single way, further detailed at the lane level, I don't see a need for turn restrictions at the lane level, only at the way level. So maybe my comment was irrelevant anyway. If I am on a right turn lane I am still allowed to switch to a straight lane (usually), before(!) the junction. If you split the way you state, that this is not allowed, which is wrong. Why do you think this will break routing though? There is also a relation type through_route which provides a strong hint to routers which path across a junction should be considered default. Could you please provide a link to this relation? I couldn't find anything in the wiki for it. Indeed, it doesn't seem to be documented on the OSM wiki. I found out about it through mkgmap, which uses it. It works well and is very useful for improving routing instructions. You can read a bit about it here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007028.html If it is not documented it doesn't help a lot. First we would need some usage statistics and if it is really widely used someone needs to write the documentation. Thanks for this information! Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Multi-value tagging and Lane Groups
Am 08.02.2012 um 20:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com: you could have a relation to say that there is a linear possibility to switch between the lanes (proposed area relation). This would make some things much easier (we could use standard tags on the ways and it would be clear without counting, which tag applies to where, the geometric layout would be right before you in the editor, and you could also model spatial details as fine as you like (up to single holes in the pavement). On the other hand we would have much more geometry for roads in the db. Considering that relations don't have many friends in the community I'm pretty sure, that this will never be approved. There is some proposal to map lanes as relations, but the feedback is not very positive as far as I know. Also we would need a lot of support in the editors for multiple lanes. Or would you like to map every of the eight lanes of a motorway one by one? I am much too lazy for that ;-) Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
