Re: [Tagging] waterway=stream oneway=1
On 04/07/2015 21:57, Mike Thompson wrote: Is it really necessary for a way that is tagged waterway=stream to also be tagged oneway=1? Isn't this implied? The oneway tag doesn't indicate the flow direction but is a restriction that applies to boat or ship traffic on the waterway. Thus if it is set to oneway=yes it means that boats may only sail in the downstream direction. Such a restriction is found on small rivers in Denmark having a lot of canoeing tourists. Anyway, oneway=1 is deprecated and should be replaced by oneway=yes. Furthermore, I suspect that the tag in this case might indeed be an erronous attempt to indicate flow direction. Ole / opani ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - power_supply:schedule
I'm the one who reverted your edit to http://wiki.openstreetmap.org/wiki/Template:Map_Features:power The power features template isn't the appropriate place for this tag. The template includes important power infrastructure features such as power=line and some of the most essential attribute tags to these features such as voltage=*. Your proposed tag clearly doesn't belong there since it's not intended to be used with power features. It seems like it is rather to be used together with tourism=camp_site and similar features. Therefore it should be documented on http://wiki.openstreetmap.org/wiki/Camp_site . I see that there are already various other attributes defined on that page and it would be natural to include your tag there as well. Ole / opani On 28/03/2015 22:35, Jan van Bekkum wrote: I did that, but somebody reversed it without telling me. I now put it in the tourism section. On Sat, Mar 28, 2015 at 10:14 PM Michał Brzozowski www.ha...@gmail.com mailto:www.ha...@gmail.com wrote: You have to edit the Map Features template. Michał On Thu, Mar 26, 2015 at 9:09 PM, Jan van Bekkum jan.vanbek...@gmail.com mailto:jan.vanbek...@gmail.com wrote: I can't find how I get this in Map_Features. Can anybody help? On Thu, Mar 26, 2015 at 7:04 PM Jan van Bekkum jan.vanbek...@gmail.com mailto:jan.vanbek...@gmail.com wrote: The voting period is over. The proposal collected 10 approvals and 2 rejects. Therefore I moved it to state approved: http://wiki.openstreetmap.org/__wiki/Power_supply:schedule http://wiki.openstreetmap.org/wiki/Power_supply:schedule Met vriendelijke groet/with kind regards, Jan van Bekkum www.DeEinderVoorbij.nl http://www.DeEinderVoorbij.nl On Fri, Mar 20, 2015 at 5:29 PM, Jan van Bekkum jan.vanbek...@gmail.com mailto:jan.vanbek...@gmail.com wrote: The set voting period is over. The proposal collected 7 approval votes, and 2 oppose votes (one without comment). I have extended the voting period for another week. Regards, Jan On Mon, Mar 16, 2015 at 12:15 AM Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: On 16/03/2015 9:41 AM, David Bannon wrote: On Sat, 2015-03-14 at 11:14 +0100, Jörg Frings-Fürst wrote: Where in the rules is the only persons who have participated previously allowed to vote? It most certainly does not say that. On the other hand, sitting back and only being involved to vote 'no' is - 1. Bad manners. And any community has many unwritten manners rules. 2. Unproductive. Lot of well meaning effort goes into a proposal, where is the pleasure in killing it, apparently just for the sake of killing it ? There is a lot more benefit in improving a tag. Please use the comments/draft time to do that. I would oppose firm rules like Jorg mentioned but, like any community, we need to indicate clearly just what bad manners are ! Perhaps a short para on good manners on the voting page ? Best Practice? And it needs to be for the draft/comments section. With an expansion on the voting section? David _ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.__org/listinfo/tagging https://lists.openstreetmap.org/listinfo/tagging _ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.__org/listinfo/tagging https://lists.openstreetmap.org/listinfo/tagging _ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.__org/listinfo/tagging https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
On 25/02/2015 16:41, Martin Vonwald wrote: I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) Well, we already have the approved feature http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpassing_place for features of a very similar physical nature but for a different purpose. The consistent solution is to use highway=emergency_bay on nodes in the same way as for passing places. And why do you want that kind of details? If it is tagged as emergency_bay you know it is big enough for a broken down vehicle. That is the only information you really need if you are having car problems. And adding an attribute to a short section of highway just results in further (in my opinion unnecessary) fragmentation of highways. If you really want to add the length you could use maxlength=* for the maximum vehicle length fitting in the bay. That would also be easier for data consumers to process. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power networks European codification scheme
I'm not sure how these codes could benefit OSM. They seem to be mostly for use in transactions between entities such as TSO's and would have little public interest, even for power grid 'nerds' like me. Further, from where would you get these codes (with an odbl compatible license)? I have never seen such codes used on public websites of TSO's and power companies. And I don't think they label substations, power plants with such codes at the gates so you can't get them from surveys. Ole On 14/01/2015 21:54, François Lacombe wrote: Hi all, I've just discovered a document published by ENTSO-E which is the European authority for power Transmission System Operators (like RTE in France or TenneT in Germany : https://www.entsoe.eu/about-entso-e/inside-entso-e/member-companies/Pages/default.aspx) This document summarizes a couple of principles for power system elements codification. http://clients.rte-france.com/htm/fr/vie/telecharge/EIC-Reference%20Manual%20v4r4.pdf I think it would be great to introduce the key ref:EU:EIC to tag transmission power lines, power plant or transmission power substation with it. These codes seem to be unique all around Europe and they would allow us to sustainably identify a lot of features (instead of using the OSM ID only). I only found one instance of eic_code=* on taginfo which actually concern a feature located in Czech Republic (they do have a wikipedia page for it http://cs.wikipedia.org/wiki/EIC_k%C3%B3d) If everyone agree about the key, I may add it to the Power Transmission Refinement proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement All the best *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com http://www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] oneway=no spams
I notice a quicky increasing number of oneway=no tags on roads, probably due to editors offering some flashy list box for the oneway key. I wonder what's next. bridge=no, tunnel=no...? I find these information-less tags annoying, because you have to browse a long list of bogus tags on each object to finally spot the one or two tags that actually matter. It depends. Sometimes it is useful to add this tag. I typically add it to bidirectional cycle paths along roads as you would normally expect such cycleways to be oneway. Adding a oneway=no indicates that it has been surveyed and found to be bidirectional and will further prevent eager mappers adding the missing oneway=yes tag to this cycleway. But I agree that it is silly to add it to all highways in general. I occasionally see highways having long lists of obvious *=yes access tags (and some silly *=no as well such as boat=no on a highway=trunk!). I think that those editors should only make undefined, yes and -1 selectable, or omit the no values on upload at last, except for motorways, motorway_links and roundabouts. A roundabout with oneway=no is not a roundabout, just a circular road. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki
On 02/12/2014 14:48, Martin Koppenhoefer wrote: In short, I think we should add more access classes to the wiki: - armed_forces=yes/no etc. (identifier cannot be military because that key is taken) I think military_personnel=* is better. Armed forces in my opinion refers to the entire organisation whereas military personnel according to wikipedia refers to members of the armed forces. Maybe separate classes for types of military vehicles are needed as well? I also still think that tram could be a subclass of landbased transportation - vehicle - motor_vehicle - psv (yes, they are on rails, but they are also part of road transport if their rails aren't separated from the road). I don't see a big need for this class. The access is already defined by the presence of physical rails. On the other hand we might need a key for trolley buses as they behave like buses but with physical restrictions on where they can go. There are no rails defining their access and I'm not aware of a tagging scheme for the contact lines. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Cycle lane tagging
Questions regarding correct cycle lane tagging. Regarding a situation like http://wiki.openstreetmap.org/wiki/Bicycle M3a: a) How do I tag the width of the cycle lane? b) How do I tag an arrangement like M3a where the lane is signposted as non-segregated foot and cycle use? Do I need to use lanes tagging for this, which is completely different form the cycle lane tagging? See here how to do it http://wiki.openstreetmap.org/wiki/Key:surface#Surface_for_foot-_and_cycleways ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] Beach routing
On 11/07/2014 22:43, Richard Weait wrote: On Wed, Jul 9, 2014 at 12:50 PM, Elliott Plack elliott.pl...@gmail.com wrote: OSM US: I've been using some routing engines to map fitness routes (e.g. Strava) that use OSM data. Along our US coasts, there are beaches. The beaches I'm familiar with are popular with walkers and joggers to go up and down the shore, since access is generally open to anyone along the water's edge. I'm considering adding a `highway=path` along the beach to facilitate this. I'd add the connections to the walking paths between parking lots and the beach as well. For uninterrupted strips of sandy beach, would a path be appropriate to indicate walkability? Adding a single arbitrary path where an area exists seems a bit of a hack. I recognize that part of the problem that you are trying to address is that routers aren't routing across areas. And that is surely a difficult problem to solve. Is the creation of arbitrary fake-paths a worse problem than not being able to route with specific routing software? Perhaps. A similar situation exists in (micro-)mapping golf courses. Some courses have cart paths with discontinuities. Often those discontinuities direct you to drive the cart (or walk, I'm not judging here) on the fairway, until the next section of physical cart path begins. In that situation, I only map the real path, not the virtual path. The another similarity is that users will select different paths for different reasons. Beach walkers may divert towards interesting items on the beach, or away from waves, washouts or debris. Golf players will be guided by course rules, weather rules and the location of their ball. The golf player is probably more likely to complete a predictable circuit. Beach walkers might follow an out and back of entirely arbitrary length. Using a router to select a, let's say, 5km stroll, out and back on a beach, seems of limited utility. I suggest, no path on the beach. Map a boardwalk where one exists, by all means. And adding those access ramps / paths is awesome. ;-) Maybe this proposal could be promoted to solve this problem? http://wiki.openstreetmap.org/wiki/Proposed_features/virtual_highway ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Track grades
On 09/07/2014 01:08, David Bannon wrote: I don't really care exactly how it is done as long as we end up with a clear model advising people whether or not they should attempt a particular road. I have posted references to lost lives as a result of bad decisions. Its easier to get people to take notice of simply presented data. Too much detail scares most people My pet solution was based around tracktype= with two legs, (a) we reassert that tracktype= applies to all highway=, not just highway=track. This was the original intention. (b) extend the five grades by another three, being 4wd recommended, required and extreme. This would completely redefine the current meaning of tracktype which I think would be a very bad idea considering the widespread use of this tag. Extending with new values that are of a completely different class than the current values would be confusing. Another approach is to make wider use of 4wd_only=yes. Extend it to have the 'recommended' and 'extreme' values. I was advised that tags starting with a number were a problem in mapnik but others have dismissed that and a new default render has taken over now. I prefer the tracktype= model as it has pretty wide use world wide, 4wd_only= does not yet get much use outside of Australia. Please see Unsealed and 4wd roads in - https://wiki.openstreetmap.org/wiki/Talk:Australian_Tagging_Guidelines Some more ranting on my wiki page (inc discussion) https://wiki.openstreetmap.org/wiki/User:Davo Instead of trying to tweak existing tags I would propose a new tag to indicate suitability for different types of vehicles. The following scheme can be applied to all unpaved highway types. vehicle_suitability= class 1: The road is suitable for 2WD vehicles with normal clearance. class 2: 4WD recommended. 2WD vehicles only with experienced driver. class 3: 4WD required. 2WD vehicles unlikely to be able to pass. class 4: 4WD and high clearance required. I think this should fit most dirt roads and tracks around the world. Would it be worth a proposal? Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
On 09/07/2014 09:44, Kytömaa Lauri wrote: Calling it replacement doesn't mean it's not deprecation. The proposal is still trying to deprecate power=minor_line, and to remove the simple physical distinction between really big thing on big pylons vs. smaller overhead lines that you can often find everywhere. Mappers can make that size distinction much easier and faster than they could estimate what the actual voltage happens to be; the size is the criteria, not the voltage, even if the size quite often exceeds the threshold after some value in any particular country. And that classification is the most prominent feature for everybody else not interested in the voltages or circuits or number of cables or whatever; in mostly incomplete areas, mappers are most likely to first draw only the big things, and only then start adding the minor_line's, so it's even easier to use the right choice. Pnorman provided you with nice example pictures for the distinction on the rendering github pages, and gravitystorm explained in detail in another issue in the same tracker why arbitrarily changing established tags is bad for the community. It should be a lesser inconvenience for power infrastructure consumers to select where (power=line or power=minor_line) and voltage= etc., than it would be for every other existing map to be cluttered with prominent power lines crisscrossing the suburbs and countryside until all eternity (entering a voltage=* tag can never be enforced on mappers). +1 I see two problems with this proposal. 1) This proposal requires a voltage tag to distinguish big and small power lines. If mappers don't add a voltage tag then it's probably because they don't know the voltage and this information is often difficult to get hand on. However, they can mostly figure out whether it is a major or a minor power line looking at the towers/poles and use either line or minor line appropriately. With only power=line as main tag and not knowing the voltage they can't add this information anymore. 2) The proposal will require renderers and other consumers to evaluate the voltage tag if they want to distinguish between major and minor lines. This can however be a rather complex task since the voltage tag values are not always simple numerical values as required to perform simple comparisons. In the case where two voltage separated by a semicolon are specified more complex processing using regular expressions etc is required. I have the feeling that the Carto stylesheet maintainers won't be eager to implement that (if supported by Carto at all). The result of deprecating minor_line will effectively be a loss of information in the database and in inferior rendering of power lines (400 kilovolt lines and 400 volt lines will be rendered the same way!) Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Substation proposal approved - and a suggestion for a post-vote change
I have now introduced a specific attribute for small substations: substation=minor_distribution. It is exclusively to be used on the 'last level' of transformation to low voltage line voltage (400 volt in Europe). This should address the desire to have an unambiguous way of tagging small kiosk-type etc substations. At the same time the recommendation to map such small substations as power=transformer has been removed from the feature page (except for pole-mounted transformers). See http://wiki.openstreetmap.org/wiki/Tag:power%3Dsubstation#Substation_values Ole On 12/10/2013 13:08, Martin Koppenhoefer wrote: 2013/10/12 Ole Nielsen / osm on-...@xs4all.nl mailto:on-...@xs4all.nl I propose to change the meaning of substation=distribution to be used only on substations at the last level of voltage transforming, thus the small street-level transformer kiosks etc supplied with medium voltage (typically 10-30 kV) and delivering low voltage power to households and small businesses. IMHO the IEC are right with defining everything below 100kV as distribution, I wouldn't use this given term with a different meaning. Maybe you could add another term like local_distribution for the last level (Trafohäuschen), if you don't have confidence in the mappers tagging voltage levels. According to wikipedia:de there seem to be 4 agreed levels of power transport and distribution in Germany: * 220kV/400kV (national transport, also DC) * 110kV (regional transport) * 30-60kV (regional distribution) * 6-20kV (local distribution) http://de.wikipedia.org/wiki/Umspannwerk cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Power] sub_station vs substation
François you'll need to be a bit patient. As long as the main mapnik map and the major editors don't support the new tag there won't be a quick switch to the new tag. The old sub_station tag (10 uses) will continue to exist for a very long time and renders should keep supporting it. At least the count for power=station seems to be decreasing now (somebody retagging?). Ole On 03/11/2013 00:14, François Lacombe wrote: Hi, As mentionned in the issue #230 on the main openstreetmap rendering github, the number of occurences of power=sub_station increased during the last 15 days. https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-27632715 The new value power=substation was introduced not long ago and is the official value of power template for power substations on the wiki. It would be great to stop using the old value (sub_station) for new features, and edit the old ones (case by case, carefully) to suggest people to support the new tagging scheme. If you're knowledgable about power networks, you could add the substation=* tag to indicate the usefulness of the substation. http://wiki.openstreetmap.org/wiki/Substation#Substation_values Many thanks in advance. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Substation proposal approved - and a suggestion for a post-vote change
On 16/10/2013 20:57, François Lacombe wrote: I was wondering if using line=* for busbars and bay is the best thing to do regarding of what line=* is commonly used for : http://taginfo.openstreetmap.org/keys/?key=line There are busbar and bay obviously but many other values dealing with public transport. Thus, and I'm sorry to suggest that just 2 weeks after the end of the vote, power:line=* wouldn't be better for busbar and bay ? I'm planning to use this for some stuff in power transmission refinement. I can't see any problems. line=* is indeed used a lot on public transport features (mostly nodes (bus stops?) and relations). But there shouldn't be any chance of confusion since the two contexts are so different. In both situations (power and public transport) 'line' is used only as an additional tag. It would indeed have been a problem if 'line' was a main tag used for identifying the type of feature. But that is not the case here. 'power=*' is never used on public transport features and vice versa. Further line=busbar/bay follows the established practice of using the main tag value as a key in an additional tag (power=line, line=busbar). No need to make things more complex if there are no real conflicts. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Substation proposal approved - and a suggestion for a post-vote change
2013/10/12 Martin Koppenhoefer dieterdre...@gmail.com 2013/10/12 Ole Nielsen / osm on-...@xs4all.nl I propose to change the meaning of substation=distribution to be used only on substations at the last level of voltage transforming, thus the small street-level transformer kiosks etc supplied with medium voltage (typically 10-30 kV) and delivering low voltage power to households and small businesses. definitely +1 IMHO the IEC are right with defining everything below 100kV as distribution, I wouldn't use this given term with a different meaning. I don't agree. Imagine you find several 90 kV and 63 kV lines in such a substation connected with busbars. Then, the operator can use this stuff to make power transit between lines of a given power level and use transformers to transit between both 90 kV and 63 kV. That's transmission and not distribution obviously and it's below 100 kV. Furthermore, we can't qualify of distribution voltage levels which accept industrial client feeding : CERN is connected to French 400 kV (and I hope everyone will agree 400 kV isn't distribution). I surely wouldn't associate CERN with distribution. They may have their own internal industrial distribution network but substation=industrial is more appropriate for such internal facilities. The idea behind transmission and distribution is to provide data consumers a hint about the role of the substation without having to look for the voltage tag (which may be missing or having multiple ;-separated values). The 100 kV specified threshold is only a guideline and if the mapper think that a 70 kV substation is mainly for transmission then it may be indicated as such. Another example: 132/10 kV substations are not uncommon in Denmark and they seem most appropriately to be considered distribution stations. Of course we are here talking about the final substations *for households and small businesses* only being connected at the low voltage level, not those feeding larger industrial customers at a higher voltage level. I'm open to suggestions for alternatives to distribution. Martin suggested local_distribution which is a bit long but otherwise a possibility. Some other ideas: local or minor?. I am just looking for a way to clearly distinguish those low voltage substations from other substations. BTW, transformer=distribution is currently defined as meaning a transformer supplying low voltage! Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Substation proposal approved - and a suggestion for a post-vote change
The substation refinement proposal has been approved by a large majority of voters. The new feature page can be found here http://wiki.openstreetmap.org/wiki/Tag:power%3Dsubstation Afterwards I regret a bit that I didn't reserve a dedicated value in the substation=* tag for the small street level substations (Trafohäuschen in German). I used the IEC definitions that suggest that anything below 100 kV or so should be considered 'distribution'. It may have been better to define this value only to cover the last level of transformation from medium voltage to low voltage supplied to household customers. This would address the concerns of some mappers, especially in central Europe, that used the old station vs sub_station to distinguish this. I propose to change the meaning of substation=distribution to be used only on substations at the last level of voltage transforming, thus the small street-level transformer kiosks etc supplied with medium voltage (typically 10-30 kV) and delivering low voltage power to households and small businesses. A small substation would then be tagged as power=substation and substation=distribution. Mappers could then unambiguously tag such facilities without having to know the actual voltage(s) employed in a given area. Tagging the voltage is still recommended, though. I would like to have opinions on this. If this change is made some substations at the 'second level' such as 60/10 kV now tagged as 'distribution' should have this tag removed. The current suggestion that small kiosk substations may be tagged as 'power=transformer' will then be removed to avoid any confusion. Only pole mounted transformers will keep their own tagging scheme (power=pole, transformer=yes/distribution). Ole N ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
On 08/10/2013 02:33, Matthijs Melissen wrote: At least in the Netherlands you have to distinguish between bicycle=no and bicycle=dismount. Some pedestrian streets are explicitly signed with no bicycle pushing. I never heard of that, what sign do you mean? In which contexts is out used? Do you have a picture by any chance? Here is one found in a local shopping centre in Rijswijk (crappy phone photo made in poor lighting). http://wiki.openstreetmap.org/wiki/File:Fiets-verboden.jpg It literally translates to Forbidden to bring along bicycles by hand Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Usefulness of bicycle=dismount on ways
On 07/10/2013 21:42, Richard Fairhurst wrote: dieterdreist wrote: bicycle=no indicates that you cannot (legally) ride your bicycle there. If you dismount and push you become a pedestrian, so you are not riding a bicycle and bicycle=no has no effect on you. That may not be the case in the UK. The law allows walkers and their usual accompaniments along public footpaths. It's generally agreed that (for example) a car is not a usual accompaniment, so you can't push a car along a public footpath. It is unclear whether or not a bike is. CTC (the Cyclists' Touring Club) thinks it is, many local councils disagree. That said, for routing purposes in the UK, I treat bicycle=no the same as bicycle=dismount, because in reality the tag is often used on paths where cycling is tolerated. At least in the Netherlands you have to distinguish between bicycle=no and bicycle=dismount. Some pedestrian streets are explicitly signed with no bicycle pushing. In other words you may not bring your bicycle here. Thus you need bicycle=no in its strict interpretation. In other situations bicycle=dismount is useful for routing as already mentioned. One good example is steps having a groove along the side intended for bicycle pushing. Routers would probably not suggest steps as routable for bicycles unless you indicate that fact. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wind turbines: big and small
On 07/10/2013 22:40, Clifford Snow wrote: It seems that small and large are too granular for the complexities of wind turbines. Wikipedia has numerous sizes of wind turbines. There is a classification for small, 100kw or less wind turbines, but it is not related to physical size, just power output. Tagging wind turbines should have room for type, tower height, rotor and hub size and power output. Maybe we shouldn't tag such small wind turbines as power=generator as they hardly count as power infrastructure. My suggestion is man_made=small_generator or something like that for (could also apply to rooftop solar panels). Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - (Substation Refinement)
The Substation Refinement proposal has now been stable for some time. It is therefore time to announce the voting on this proposal. http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement In short it - introduces a consistent tagging scheme for substation properties and substation components. - deprecates the confusing power=station tag - corrects the spelling of power=sub_station to power=substation Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power tower and pole usefulness
On 21/09/2013 21:01, Martin Koppenhoefer wrote: I continue to oppose the usage of man_made=tower for electricity lattice towers (that what has been power=tower until now and which is 4,8 Million times in use). Why should we change this well established practise, which would require 4,8 Million new additional tags (tower:type=electricity) and which doesn't even help to reduce potential multivalue conflicts? At least I'd use man_made=power_tower or something similar, but IMHO if there are problems with power=tower having other infrastructure on them this should be dealt with in an alternative way possibly keeping power=tower. +1 And we will loose the elegant ability to retrieve all power features just by using a power=* query in Overpass. Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 02/09/2013 09:58, François Lacombe wrote: Ok, but 'yes' has to be added to the transformer=* table of values in the proposal. Done, but with the recommendation to use a more specific value such as distribution if possible. It isn't for now, that's why I thought we can't use it in this particular case. And what about multi-utilities poles ? IMHO they definetly can't only be identified by power=* tag. You can add any kind of tags to the power pole. E.g. communication=antenna (don't know if this is correct) transformer=yes highway=street_lamp etc But it is a power pole if it looks like a power pole and was put in place for the purpose of carrying a power line. The other features are just getting a free ride. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 01/09/2013 19:04, François Lacombe wrote: 2013/8/30 Ole Nielsen on-...@xs4all.nl mailto:on-...@xs4all.nl Agree, the transformer is just a feature of the pole. I wouldn't tag it as a substation. According to http://wiki.openstreetmap.org/__wiki/Proposed_features/__Substation_refinement http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement that is indeed how to do it. I see no problems in having an alternative tagging of the transformer since the power key is already used for the pole. For retrieval it is only slightly more complicated than just searching for power=transformer. It's already used for the poles but don't you think it's transformers which deserve the most the usage of power=* ? In this case no. From an electrical viewpoint the transformer is of course important. However, is this the most important aspect for the average user? You see a pole in a row of poles and this particular one happens to have some kind of lump attached to the top. It may be useful to tag this fact for navigational purposes but it is otherwise of doubtful use. Very few users will be interested in the details of that transformer or its connections to the grid. Even when I'm interested in power grids myself I don't find the lower voltage distribution grids particularly interesting. Furthermore, it is mostly impossible to map the distribution networks to any degree of completeness due to undergrounding etc. Thus I can't see much need to develop an elaborate tagging for this reason especially if it is not compatible with the existing tagging practice. However, the average mapper may still want to tag the transformer as an interesting feature of the pole. An additional attribute tag (transformer=yes/*) will be sufficient for that and it won't break anything. Data consumers can easily extract this information if they need to. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 30/08/2013 11:00, bredy wrote: Another question. But the pole with transformer is a substation? For me is better to tag it as a Pole because really I see a pole, not all people know a transformer. Then if I put transformer=yes I see there is a transformer in the pole. Agree, the transformer is just a feature of the pole. I wouldn't tag it as a substation. According to http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement that is indeed how to do it. I see no problems in having an alternative tagging of the transformer since the power key is already used for the pole. For retrieval it is only slightly more complicated than just searching for power=transformer. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 30/08/2013 10:55, bredy wrote: In Italy there are many substation like this Cabina Enel http://viadeisalici.blog.tiscali.it/files/2011/04/imagesCAMV.jpg the line arrive in the building. How can I tag this? Actually building=yes + power=sub_station, but for JOSM if I connect del line with the node of substation take me an advice. Lost Pole/tower. Do I have to connect the line with one node at center of substation and tag it with power=transformer? Actually this is more relevant to the http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement proposal than to the power transmission proposal. According to that scheme you should tag the substation as building=yes, power=substation, location=indoor. I would prefer to connect the incoming power lines to the building polygon as you don't really know what happens inside. However, you may add a node inside and tag it with power=transformer, transformer=distribution. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 06/08/2013 10:16, François Lacombe wrote: No comments except my suggestion for hosted features on a pole or tower at the end of Transformer Type chapter. http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Substation_refinement#Transformer_type The proposal has been adapted for pole mounted transformers using the suggestion of RM87. But It's wise to wait for september to start voting indeed :) Due to holidays I prefer to delay the voting a bit. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
The proposal is more or less ready. No recent comments to the proposal. However, we are in the middle of the holiday season and I don't think it would be a good idea to call for a vote before late August or so. On 01/08/2013 01:31, François Lacombe wrote: Hi, It seems there hasn't been so many activity on substation refinement proposal for weeks. http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement How about launching vote, at least on power=station deprecation for substations and inside stations stuff ? I've used the new model to map sevral big and small French substations and I didn't find any big issues. How about the hosted features on poles / towers discussion ? http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Substation_refinement#Transformer_type I have applied the scheme to many substations in Denmark and the Netherlands (however for the moment keeping power=sub_station). Those two countries are now mostly free of any power=station tags. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bad tag: demolished=date: move to a) modify, b) strongly discourage
On 27/06/2013 19:23, Andrew Chadwick (lists) wrote: iii. We should not in general be mapping features which are no longer physically relevant. Demolished items by their very nature are not relevant, and are potentially not verifiable. OSM a map of the the world as it is in reality, verifiably and currently, and not a historic map. If a demolished item is currently a brownfield site, it should be tagged as a new object with those details. If it's now a construction site, tag it as that. Therefore I propose: a) Modification of this page to avoid bad data creeping into the database, by: 1. Rewriting it as a namespace in a similar manner to abandoned and disused, addressing [i]; Agree, although demolished may not be the best choice. I use removed:key=value as it is more neutral than demolished which is mainly applicable to buildings. 2. Altering the date specification to be Right, namely the ISO 8601 date formats, addressing [ii]. I use end_date=date (usually only the year) b) Strongly discouraging its use altogether, addressing [iii]. Disagree. There are reasons to keep objects in the DB after they have ceased to exist. First of all that will (hopefully) prevent other mappers from accidentially remapping features still visible in outdated imagery. Recently dismantled power lines are good examples for this as they are often mapped by armchair mappers. Secondly, some people may have a genuine interest in keeping a geographical record of disappeared objects, in particular significant objects that may have dominated an area and may be found in old photos etc. I agree we shouldn't start adding long gone objects to OSM. However, for recently demolished/dismantled features I find it justifiable to keep them in OSM especially if they can be mapped from current imagery or were mapped from previously available imagery such as yahoo. Ole N ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Power generation refinement
On 11/06/2013 17:08, fly wrote: The next tricks are coming with the substation proposal (RFC) and the power transmission proposal (Draft) http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement I already have two questions: 1. How am I supposed to tag a power=transformer on a node which is already tagged with power=*. The substation proposal deals with that problem. It would be tagged as power=transformer + location=pole (for a pole mounted transformer). Thus there is no power=pole tag. 2. Please remove the part which says that you should not use power=tower for minor_lines. This is a problem of renderers but no tagging issue. It would be better to move this discussion to the discussion page of the transmission proposal (this thread is about the approved power plant proposal!) Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Substation Refinement
On 22/05/2013 17:26, Frank Villaro-Dixon wrote: I wonder if this level of granularity is really that useful ? Where's the limit ? I mean: without knowing all the complete diagram, all of that is a bit useless, no ? Correct me if I'm wrong, but it would be like changing from mapping only the signals/signs on the railroads to mapping each of the elements of the railroad such as the level-crossing sensors, speed-control beacons, axle counters, data pickup units, etc.. IDK, maybe this is used somewhere (In that case, I'd love to see a pratical example ;) ). Whether such detailed mapping is useful only time can tell but there are certainly mappers who want to add such information. From Taginfo: power=busbar (13795), power=switch (8591), power=transformer (8958) to mention the most frequently used substation component tags. With this proposal I have tried to define the granularity at which substations should be mapped. For example busbars and bays should be mapped at the circuit level, not as individual conductors. With the exception of power=switch (because it is so popular) it is recommended not to map bay components (disconnectors, instrument transformers, surge arresters etc) or other fine details. Ole N ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Substation Refinement
After being developed over a couple of months the Substation Refinement proposal is now ready for comments http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement The proposal is really two proposals in one. 1: New power=substation tag for all substations. First of all it aims at fixing the power=sub_station versus power=station dispute. The power=station tag was really created by accident (German for substation is Station) whereas power station in English actually is a synonym for a power plant. And sub_station is wrongly spelled. Thus the proposal introduces the new tag power=substation for all types of substations to replace the two former tags. 2: New attributes for substations, new tagging scheme for substation components. The proposal introduces new attributes substation=* and location=* for substations. Further it introduces or improves the following tags: power=switchgear, line=busbar, line=bay, power=switch, power=transformer, power=converter, power=compensator. Various attributes for these tags are also defined. It is possible that a future vote on the proposal will be split into two separate votes according to the 'subproposals'. Ole N ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Life cycle group
On 08/04/2013 09:07, Alberto wrote: Well, disused:*=* and abandoned:*=* are widely used, you could simply link to their Wiki pages. For construction, we should make a general proposal separated from power refinements, as you suggest. We really need a consistent life cycle scheme that defines all stages of an objects life, that is proposed, construction, (active), disused, abandoned and historic (completely gone). The life cycle state:key=* scheme is my favourite. Somebody just needs to make a proposal (it would basically be a generalisation of the disused:*=* tag). See http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts for a comparison of current ways of tagging life cycles. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
On 08/04/2013 15:02, François Lacombe wrote: I finally agree with you. I've began to update the proposal to remove relations in all cases except when power plant doesn't have any physical permimeter. Thanks! We must keep role=generator for all generators (no need to distinguish them there) in such relation since other features may be added too. Concerning output/intermediate generators, I've introduced generator:plant=output or generator:plant=intermediate to follow your readability suggestion. I'm failing to see the justification of 'intermediate' generators. Do you mean the boiler making steam for the steam turbine? That is an integral part of the thermodynamic cycle that the (output) generator operates on and shouldn't be mapped as a separate entity. The generator:method and generator:type tags already imply the presence of such intermediate generators. In my opinion this 'intermediate' generator thing should be removed from the proposal as it would just cause confusion (it would also make the currently very complicated proposal slightly simpler). Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Life cycle group
2013/4/8 Ole Nielsen on-...@xs4all.nl mailto:on-...@xs4all.nl not so sure, that historic is the right term for stuff completely gone, currently the key historic is used mainly for stuff that was created a long time ago, but which hasn't necessarily vanished in the meantime (most of the stuff categorized under historic is actually still there, so there would be some risk of creating confusion using the same term for another concept). Besides this I agree that it is nice to tag these states in a uniform way, simply use another term for historic, maybe disappeared, vanished, demolished, or simply delete and formalize a changeset tag? The exact term can be discussed, that's why we need a proposal. I think there are good reasons to keep track of demolished features. One is for recording the past (think a openhistorymap.org), another reason is to prevent accidential remapping of features that have recently been demolished but are still visible in aerial imagery. The undergrounding of power lines is a good example. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power transmission refinement proposal
On 11/02/2013 19:53, Janko Mihelić wrote: 2013/2/11 Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com According to the proposal we would then need to know the exact voltage in order to distinguish between the various sizes of substations We could make a little tool that suggests voltages by the powerlines that end up near a substation. That would solve a majority of big substations. Well, that seems like overkill to me. A manual inspection of the lines terminating at the substation should be sufficient (assuming their voltages have been tagged). I have noticed that you can quite easy detect the voltages handled in the substation by measuring the distances between busbars (Bing imagery is mostly sufficient detailed to allow this). It requires that you know the standard voltages used in the given area but is otherwise a pretty reliable way of distinguishing voltages. I'm thinking about writing a wiki page explaining how to detect voltages and other features of power grids from aerial imagery. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power Tagging
On 03/02/2013 02:31, Michael Patrick wrote:
For reference, see the International Electrotechnical Commission (
http://www.iec.ch/about/ ) Electropedia ( http://www.electropedia.org/ )
or from the Glossary search at ( http://std.iec.ch/glossary ), to the
Overhead lines / Towers description page (
http://www.electropedia.org/iev/iev.nsf/display?openformievref=466-08-08 )
where we see a diagram (
http://www.electropedia.org/iev/iev.nsf/master/466-08-08:fr/$FILE/466-fig2.gif
) and nomenclature in multiple languages: (English) double warren
redundant support ..
This is a highly useful reference that I would have liked to know about
earlier. Now I see why the Germans are so fond of the power=station
tag: en:substation = de:Station (authoritative!).
Whether we should go into details about how towers are braced etc can be
discussed. If somebody wants to tag bracing types, ok with me, but I
would find it of little added value in osm. There is already a scheme to
tag different types or designs of towers, see
http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower, but it does not go
into that kind of details.
While I get that crowd generated attribute tagging has some unique
advantages, huge flexibility, allows whatever level of detail in any
language to be incorporates, at the other end of the pipe are editing
tools, maintenance bots, and rendering engines which do expect some sort
of conventions. There might be some advantages to at least examining
these vocabularies ( like the IEC). For instance, it might be revealed
that a proposed tag might actually be several additional tags ( I
usually can't see every possible variation when looking at a specific
case). As dedicated user communities seek to add their own tags, there
would be a path to add more level of detail without breaking downstream
tools. Expanding tag sets to other languages is somewhat easier because
the basic objects and concepts are already translated. There also seems
to be a growing space of communities and applications outside of OSM
that would benefit from interoperability ( 'routing' as a quick example ).
I agree that it would have been better to define osm features according
to internationally accepted standards to facilitate the use of such
data. However the existing power tagging scheme is going to be difficult
to adapt although our terminology and definitions are clearly different
from IEC and often illogical ('cables' and 'wires' being some of the
more strange tags). As an example we are currently trying to eliminate
the station/substation confusion but even that isn't appreciated by
everybody. For some features it may be possible to subtag further
details according to the IEC definitions and I would certainly recommend
to consult the IEC vocabulary when drafting new power related proposals.
Ole
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 29/01/2013 21:00, François Lacombe wrote: Hi everyone, Here is my discussion with aliponte, as suggested by Friedrich Volkmann I've contacted him last week end. I've asked him before if he minds copying it here. Thanks for making the contact with him. He is bringing up some valid points (not that I agree to all of them). We have the line vs minor_line distinction which is also somewhat arbitrary and the related tower vs pole problem. These were all introduced in the early days of osm without providing some rigid guidelines on how to distinguish them (the result occasionally being some strange tagging). However, one difference to the station/substation discussion is that these tags are not incorrect in that they refer to correct English terms. Also trying to change minor_line or pole would be difficult since those values have been used literally hundreds of thousands of times. (personally I tag anything below 50 kV as minor_line/pole). And of course there is the line vs cable discussion but that is in a different thread. My pragmatic suggestion on station vs substation is to keep the deprecation of station, advice mappers to use substation and add a voltage tag when possible. Data consumers may treat any substation without a voltage tag as small. In time the larger substations will probably be visited by interested mappers who can add voltage tags etc (380 kV lines connecting to small substations should attract attention). Data consumers should continue to support 'station' for the time being until the use of the tag is clearly declining. One thing: Don't perform any mass retagging of 'station'! Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 27/01/2013 17:15, Janko Mihelić wrote: You also have to map these two with same tags, but mappers have no problems with that: http://farm4.staticflickr.com/3231/3612088299_4886057d1b_z.jpg http://1.bp.blogspot.com/_q4w5GY0uBAU/TG2j3tGzz2I/BLg/EQ9YBbhrwz4/s1600/Large+view+of+school.JPG And these: http://3.bp.blogspot.com/-FboxEgz3Zm8/ToN98JRlyyI/BLs/uIfFLPEqR7E/s1600/St%2BPeters%2B1.jpg http://pixelprayers.com/wp-content/uploads/2012/03/1.1274402303.the-world-s-smallest-church.jpg The word substation says nothing about it's size, just like school or church. Why should we invent new meanings for words? +1 Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 21.01.2013 01:54, François Lacombe wrote: May someone answers that question power=station is used for large, fenced areas where high voltage is transformed to medium voltage. In German: Umspannwerk power=sub_station is used for smaller objects, like buildings with 2m each side and a height of a few m, where medium voltage is transformed to low voltage. In German: Trafohäuschen (or Trafostation) That is a misunderstanding that was unfortunately introduced in the early days of OSM. The creator of the 'station' tag, Bahnpirat, has admitted it was a mistake, see http://wiki.openstreetmap.org/wiki/Power_lines#RFC_-_draft. In English as substation is a substation never a 'station'. A 'power station' in English is the same as a power plant! This leads to confusion among mappers resulting in quite a few power plants tagged as 'stations' according to my experience. I have seen a lot of small 'Trafohäuschens' tagged as 'station' (especially in the Netherlands) so the distinction is not that clear to mappers. Using voltage=* to indicate the catagory of substation is much better. No, it was rejected. It did not get enough votes. The start of voting was never properly announced on this list. Maybe that could explain the few votes. I only discovered the voting by accident. Maybe it should be revived for a new vote? Maybe. Spelling errors have been corrected in other cases too (e.g. type=broad_leafed). We are all aware that that underscore is wrong but it is quite difficult to get rid of it since 'substation' is currently not supported by renderers and editors. 'broad_leafed' was easier as none of the mainstream renderers are rendering it anyway, AFAIK. This is a consensus among 2 persons at best. This does not legitimate you to make vast changes to the Wiki. There should at least be a topic in the wiki talk page for some months. Discussions about tagging are supposed to take place here, not on 'talk'. And first of all you should contact user aliponte who did a lot of work mapping power networks in central Europe. Do everyone agree with that? No, I disagree. On 24.01.2013 22:46, Ole Nielsen wrote: I have now marked http://wiki.openstreetmap.org/wiki/Tag:power%3Dstation as deprecated, removed 'power=station' from the power features template meaning it's gone from all language versions of Map Features using the template and removed links from a few feature pages. This is really bad. Please revert these changes immediately. Otherwise I'll do it, but I am afraid that I would miss some of the affected pages. I think you should first justify why 'station' is a correct tag (i.e. a substation and not a power station). Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 24/01/2013 10:40, François Lacombe wrote: Ok, I agree with you about substation vs sub_station. Consensus seems to emerge from this discussion, I would edit the wiki like polderrunner explained. * Deprecation (not removal) of power=station, power=substation (and all other values), message adding at the top of keys' pages. power=sub_station will be the only valid value. It will encourage mappers to migrate existant power=station to power=sub_station. * Removing all the links to the keys' pages. * Editing all pages refering to power=station, power=substation and eventually update to power=sub_station. * Moving all good stuff from power=station to power=sub_station if needed and relevant. Finally, valid stuff will be located at : http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station http://wiki.openstreetmap.org/wiki/Power_substations Do everyone agree with that? I have now marked http://wiki.openstreetmap.org/wiki/Tag:power%3Dstation as deprecated, removed 'power=station' from the power features template meaning it's gone from all language versions of Map Features using the template and removed links from a few feature pages. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Key:circuits added to power template
On 22/01/2013 08:43, Volker Schmidt wrote: 1) For a non-expert it is difficult to assess how many circuits a power line carries without having access to the operators' documentation. Right, it will not always be possible to tag the number of circuits when a cable doesn't connect to an overhead power line. For underground cables at low and medium voltage such information is rarely publicly available (but then you probably don't even know that there is a cable there). For high voltage transmission grids the number of circuits is often indicated on grid maps of the TSO or documented in cable project descriptions. 2) I notice that the wiki page uses the term cable for overhead power distribution. According to my knowledge and Wikipedia (https://en.wikipedia.org/wiki/Overhead_power_line) overhead power lines are implemented with conductors. Cables (i.e. insulated conductors) are normally not used in overground transmission. Again an unfortunate choice of name for a tag that happened in the early days of OSM (like station/sub_station). It should in my opinion have been conductors=*, not cables=*. Difficult to correct now since 'cables' is so widely used. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 22/01/2013 00:49, John Sturdy wrote: On Mon, Jan 21, 2013 at 7:33 PM, François Lacombe francois.laco...@telecom-bretagne.eu wrote: So we have the same opinion so far, that's great! And from me, to. Just a question about the OSM sense of deprecated. Why can't we directly display a big message on each never use this tag to inform mappers that they would not use this key/value any more? = May administrators could build a template? Because there is no one point at which that could be displayed, just several different map editor programs, each maintained by different people. Yes, there is unfortunately no simple 'delete' button for this. The tag should of course be removed completely from the Map Features page, the 'station' feature page should be flagged with a big warning that the tag is deprecated. Links to it from other feature pages should also be removed. That's the easy part. It will be necessary to create a ticket for each of the popular editors (JOSM, Potlatch2 etc) requesting station to be removed from the presets. This may take some time depending on the developers. It may also be a good idea to post a message to talk list (not everybody subscribes to the tagging list) and to some of the more popular fora (especially the German forum). And also, there are several renderers (some with multiple stylesheets) which can each have different rules about what to display and what (by not having a rule to display it) to ignore. In this case it seems to be a minor problem as 'station' and 'sub_station' are rendered the same way in Mapnik and probably most other renderers as well. It will of course be a good idea to remove 'station' from the mapnik stylesheet as that would cause the 'wrong' substations to disappear from the map and in that way discourage mappers from using that old tag. But it may be difficult to convince the stylesheet maintainers to do that as long as the tag is still common in the database. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is the difference between power station and sub station clear?
On 21/01/2013 11:02, François Lacombe wrote: But the current usage of a tag doesn't avoid its deprecation, do you? It may be clearly written on the wiki page that power=station is from now deprecated as for starting the swap to the power=sub_station value. There will be a time were power networks would be overloaded with all those different values describing the same thing. Can't we start a sensus (or finalize 2 or 3 RFC wainting for votes) and bring it up in osmose? I clearly support to deprecate station quickly. It was an unfortunate choice to introduce this tag as the creator admits himself, see http://wiki.openstreetmap.org/wiki/Power_lines#RFC_-_draft I have already taken the first step to deprecate station on the main power page ( http://wiki.openstreetmap.org/wiki/Key:power ) by removing the distinction between 'large' and 'small' substations and mentioning the station tag as being 'disputed'. I didn't dare to take the full step and use the word deprecated, however. The main problem is of course that 'station' is so widely used. I would not recommend to do a mass retagging of all 'stations' as some of them are genuine power plants, not substations according to my experience! They need inspection. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Key:circuits added to power template
As already mentioned in a previous thread I have been drafting a definition for a new circuits key describing the number of electrical circuits of a power line or cable connection. See the feature page at http://wiki.openstreetmap.org/wiki/Key:circuits The new key is mainly intended for underground cable connections (power=cable) where the number of cables is unknown or has no fixed relationship with the number of electrical circuits. I have now added this key to the power template expecting nobody will have major objections to this additional key. The circuits key will not affect current tagging practice. It will however allow mappers to add an important extra information to power lines and cables, an information that it is not always possible to deduce from the existing cables=* tag. The circuits=* key is now visible in http://wiki.openstreetmap.org/wiki/Key:power and map features. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Powerlines underground
On 15/01/2013 15:31, François Lacombe wrote: But aerial line refers to all the conductors transmitting different lives/phases whereas underground power cable, at high voltage, refers to only one phase/conductor. http://www.nexans.no/eservice/Norway-no_NO/fileLibrary/Download_540199654/Norway/files/Underground_power_cables.pdf *So, many underground cables are needed to set up a line!* You may have multi-conductors cables up to 150 kV but you still have several conductors. Insulation is mandatory underground because we can't put enough space between conductors, instead of what is done in the air. The right question is *do we map cables separately or lines*? It's all about the vocabulary we use. http://2.bp.blogspot.com/-CnkQkGiPmbs/UFM6M2N0lUI/Ark/IMZxA3i6SmY/s1600/tunnel.png If we map cables we must do the same for both aerial and underground lines and I'm not sure it would be really efficient. Well, I think we need to properly define what is meant by power=cable. The wiki page isn't entirely clear on that matter. I'm usually mapping a underground cable connection as a single way tagged as power=cable and indicating the number of physical cables with cables=* (if it is known to me). Your interpretation is obviously that each physical cable should be mapped as power=cable (which you can't if you don't know the number of cables). Considering that power=line and power=cable are used so extensively I think it is a bad idea to redefine the meaning of them as it would break a lot of things and confuse mappers. The distinction between 'line' for overhead power lines and 'cable' for underground cable connections is easily understandable by the average non-expert mapper. My proposal is to clarify both the 'line' and 'cable' wikis as follows: power=line should represent a connection comprising UN-insulated conductors mounted on towers or other supporting structures, normally over ground. power=cable should represent a connection consisting of one or more insulated cables (whether underground, underwater, in a tunnel or overground). The number of physical cables for a cable connection should be indicated by cables=* when known. I'm currently drafting a wiki page for a circuits tag to describe the number of electrical circuits, especially useful for cable connections having an unknown number of cables, see http://wiki.openstreetmap.org/wiki/Key:circuits. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Powerlines underground
On 15/01/2013 19:29, A.Pirard.Papou wrote: But, while I was readjusting what others have left behind, I found a power line, as it's often the case with those long haul mappings (landuse etc...), that was attached to a bike lane (node in common). Imagine catching 24000 V in the pedals ;-) Seriously, isn't there a way to be exempted from having to detach those long haul ways from everything many times a day, and often have to move them to the right place, sometimes 50 m away? It's clearly wrong to connect power lines to highways, landuse etc. Maybe you could try to find out if it is a particular mapper in your area doing this and contact him. Those attached line and lane were crossing at right angle !!! I suppose one does not do that on purpose ! There must be some feature to fix in some editor explaining that. The 'snap-to' function in JOSM sometimes causes such accidents if you are not careful but I suspect many of those spurious connections are caused by mappers using Potlatch. Ole ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Exclusive access rights
On 29/10/2012 18:29, Martin Vonwald (imagic) wrote: Am 29.10.2012 um 14:27 schrieb Tobias Knerr o...@tobias-knerr.de mailto: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 Here is a simple proposal that avoids confusion with the existing access restrictions. special_use_lanes = no | no | hgv (or special_use:lanes = .. to be consistent with other lanes tags) Values can be 'no' (no special limitations apply to this lane), 'hgv', 'psv', 'hov' etc. special_use_lanes is just a suggestion, other words not making an association to access could also be used. Other ideas: special_lanes, exclusive_use_lanes Would this be a useful way forward? Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted – turn restrictions ahead?
I don't think we need to make it complicated. The Conditional Restrictions syntax is a bit overkill here. The restriction type is already known (type=restriction), so is the value (restriction=no_left_turn). What is left is just the condition (plus eventually a transport mode). I already mentioned the following proposal on the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction#Conditional_restrictions : * condition=condition * condition:transportation_mode=condition (condition uses the condition values from Conditional Restrictions) The need for the transportation mode variant will like be small as restriction:transportation mode=* should already cover this. In my opinion there are no reasons to make it more complicated than that. It is backward compatible and easy to understand by mappers. It would deprecate hour_on, hour_off etc. I believe it may be better to keep except but I would like to see real-world examples of conditional exceptions before adapting a Conditional Restrictions like syntax for that key (is your example 3 real?). Ole / polderrunner On 16/10/2012 17:45, Rob Nickerson wrote: Hi Eckhart, Your right, voting has come to an end for the Conditional Restrictions proposal, which was approved. A statement was not made on this list as Ole and I are working on how best to write the feature page so that some of the concerns raised (about complexity / difficulty to understand) are reduced as much as possible. Like Martin, I'm not hugely convinced about the need for complicated turn restrictions (most of the restrictions will be on the road and the detail on the turn sign will simply be advanced warning for the driver). Having said that, you have provided a few examples so I have looked into it: 1. Currently we tag a no left turn restriction using restriction = no_left_turn. 2. If we want this to apply only to HGVs then the key is changed so that it become restriction:hgv =no_left_turn. To draw the comparison with Conditional Restrictions the above tags cover of restriction type, transportation mode and the tag value. There is no need to specify direction as this is already captured in the relation (from, via, to). Therefore the only part left to add is the condition. At the moment there are 2 ways to do this 3. Using except = * (where * is a vehicle type). e.g. except = bicycle 4. Using day on, day off, hour on, hour off In summary we already have both applies type tags (1, 2 and 4) and except type tags (3, and the inverse of 4!). My gut instinct is that adding an applies = * tag would further complicate the issue. In conclusion I would be in favour of adding the conditions directly to the restriction or except tag (depending on how the road sign is written). Yes this breaks backward compatibility but there are a lot less turn restrictions in OSM than the other restrictions and if the conditions are not met then the restrictions does not apply so it shouldn't really be tagged anyway! == Some Examples == * Example 1: no u-turn restriction for HGVs longer than 6 metres: * restriction:hgv = no_u_turn @ (length 6) * Example 2: no right turn Monday to Friday 8am to 4 pm: * restriction = no_right_turn @ (Mo-Fi 08:00-16:00) * Example 3: no left turn except PSV's on Monday to Friday 8am to 4 pm: * restriction = no_left_turn * except = psv @ (Mo-Fi 08:00-16:00) This then depreciates the need for day on, etc... tags which I'm not a fan of - I think it is better to tag what is on the sign e.g. (Mo-Fr 08:00-19:00). Happy to hear your thoughts. Rob p.s. I think it would be nice to see a few more real world examples if anyone has any photographs (or can remember the conditions). p.p.s It would be nice to know how many routing software apps are using these turn restriction relations. ___ 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] Emergency lane used by PSV at rush time
On 14/10/2012 14:40, Tobias Knerr wrote: On 14.10.2012 14:04, Eric SIBERT wrote: 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. You could combine Conditional restrictions and the lanes suffix¹: lanes=3 access:lanes = yes | yes | no emergency:lanes = | | yes psv:conditional:lanes = | | yes @ rush_time There are a couple of issues here 1. I did not include 'lanes' when I created the Conditional Restrictions scheme (mostly not to complicate the discussion and voting process of the proposal). It could be done as suggested by you. However, I would prefer to write the key as psv:lanes:conditional in order to be consistent with other uses of conditional where the unconditional and the conditional tags can be distinguished just by the :conditional suffix. I may add this to the wiki page. 2: It can be discussed how useful it would be to tag such information. It's a bit like maxspeed:wet. It may be indicated by a sign but a route planner or other application cannot really use that information as it has no clues to the road condition or traffic situation at some time into the future. We have a similar issue in the Netherlands where many motorways have hard shoulder running and lanes called plus lanes which open only at times of high traffic intensity. Furthermore, the speed limit is lowered when such lanes are open (thus two conditional restrictions)! 3: About the condition value: What about traffic_jam or congestion? Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Conditional Restrictions
After about one month of discussions resulting in some refinements to the proposal I now put the proposal forward for voting. Please make your vote at the proposal page. http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging for checkpoints?
Yes, you need to add access=yes. The router does not know who may pass a checkpoint and access=yes is definitely not the default for a checkpoint (private would be more likely). This is a general issue for all point type barriers where a default access is unknown and mappers forget to add the access tags. For some types of barriers default access rules can be assumed. Bollards for example allow narrow vehicles (bicycles, mopeds) to pass but not wide vehicles like motorcars. Ole On 26/08/2012 21:02, Nathan Oliver wrote: This agricultural inspection station [1] has the tag barrier=checkpoint, which OSRM appears to interpret as access=no. [2] Is this a bug in the router, or should additional/different tags be used? I've consulted the wiki, and can't find anything definitive about how this should tagged. Any suggestions? I'm tempted to simply add access=yes, since I'm pretty sure that everyone is allowed to pass (unless they have forbidden produce), but I thought I'd consult the crowd. [1] http://www.openstreetmap.org/browse/node/848749487 [2] http://map.project-osrm.org/1cN Nathan ___ 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] Feature Proposal - RFC - Conditional Restrictions
This is the formal RFC for the Conditional Restrictions proposal which was already mentioned here last week. http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions Feel free to discuss the proposal on the talk page of the proposal. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Everybody is hiding?
Hi tagging list, the Extended Conditions proposal has been shot down by a majority, and therefore there is still no official way of tagging quite a lot of things. (As a side note, the Extended Conditions proposal is still the de facto standard.) Therefore, I expected that those people who had voted against the proposal came up with a well-designed alternative proposal â yet nothing happened. Shall I conclude that all those people who voted against the proposal did this just for the sake of voting against? First of all I actually approved the proposal but later realized that having variable keys is less than ideal. I am currently working on an alternative proposal and I was planning to announce it within a few days (I have only limited internet access the next couple of days). But here it is. http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions A short comment on the proposal: The actual conditions go into the tag value. The transport mode (vehicle catagory) and the direction stay in the key in accordance with current practice for access restrictions. Feel free to comment on it, preferably on the talk page. Ole / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for some additional power line tags
On 09/04/2012 21:11, Guillaume Allegre wrote: Please add a tag to specify that a specific tower is the point where the line comes from underground to aerial. I previously proposed raiser=yes, but it didn't seem to match exactly what I meant. Somebody has already proposed 'tower=air_to_ground' and 'pole=air_to_ground', see http://wiki.openstreetmap.org/wiki/Power_lines These values seem clearer to me than raiser. My proposal will adapt 'air_to_ground' to be used in combination with either tower:terminal=yes or tower:branch=yes (if the cable begins as one leg of a T-branch). Please continue the discussion on the talk page http://wiki.openstreetmap.org/wiki/Talk:Tag:power%3Dtower Ole N ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposal for some additional power line tags
Please see http://wiki.openstreetmap.org/wiki/Talk:Tag:power%3Dtower for some additional tags for advanced tagging of transmission towers. I intend to add these tags to the http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower feature page but first I would like to receive any comments you may have to these proposed tags. Please add any comments on the discussion page. Ole N / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature proposal - Voting - Lane_group
The proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Lane_group is now open for voting. The proposal has been stable for the last couple of weeks and I find it useful to have a vote on it now (noting that the competition has also entered voting status). Ole N / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Star (*) character in tags?
I'm considering some changes to the syntax of the lane_group proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Lane_group . The syntax of the proposal in some cases allows empty lane values in the value list (nothing between two commas), e.g. to indicate default value or 'not applicable'. This can result in poorly readable tag values like =,,70. My idea is to add a wildcard for empty lane values using the * character. Is this character in any way 'reserved' in OSM? (API, mapnik, editors etc). The wiki uses * as wildcard but in my proposal the * character will never appear alone in the value field. Ole N / polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Lane_group
This is a new proposal for solving the highway lane tagging problem. http://wiki.openstreetmap.org/wiki/Proposed_features/Lane_group Please use the talk page for comments. Regards, polderrunner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
