Re: [Tagging] Power generation refinement: power plant model evolution
I am a mapper (my consumer side experience was very short so far) and I like relations. 1) All situations complex and simple can be mapped in the same way - this makes my mapping easier. 2) Single real object can have all the information on one place only, not on 50+ osm objects (eg. name of long streets). 3) Higher level, more abstract features can be handled more easily. 4) With appropriate editor (eg. JOSM with Relation Toolbox) it is no more difficult to learn than drawing a square. 10) Relations just make sense. Lukáš Matějka (LM_1) 2013/4/12 Martin Vonwald imagic@gmail.com Hi! 2013/4/11 François Lacombe francois.laco...@telecom-bretagne.eu Data quality and consistency check world would definitely prefer to work with relations than with spatial processing. The important word here is prefer. It is obvious that most data consumers prefer relations. They are (often) easier to process. But what the consumers process is the data that mappers provide. The consumers get that data for free. So why should the consumers be allowed to put additional burden on the mappers just to make their own life easier? Processing _is_ (often) harder without relations. That's a fact no-one denies. But we have to make a decision. Do we want data that is very easy to process but we get less of it because mappers often fail to provide it. Or do we want data that's a little harder to process but we get more of it. You can't have both - you have to make a decision. Just for the sake of completeness: I will never be a great plant-mapper so to me it might be completely irrelevant how they should be tagged. But I want this little baby (aka OSM) to become a big boy (or girl - see http://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Post-mortem) and in my opinion we will only achieve this if we keep the new mappers coming and don't frustrate them early on. I'm fully aware of the importance of data consumers. They do a great work and I definitively don't intend to make their life miserable. Actually the exact opposite: I want them to get as much data as possible. For free. That's why I'm sometimes a pain in the ass. And yes, I know that some people would argue about that sometimes ;-) All the best, 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] Power generation refinement: power plant model evolution
Could there not be something else than a generator=* in a role of a generator? LM_1 2013/4/9 Martin Vonwald imagic@gmail.com Hi again :-) 2013/4/9 François Lacombe francois.laco...@telecom-bretagne.eu This is where I still don't understand you: why do I need to specify that a feature XXX has the role XXX? Why do I need to specify, that a generator is a generator? A substation a substation? A dam a dam? A valve a valve? A weir a weir? And so on. This is just because a role must be specified. Why do I have to specify a role? When all features must be member of power=plant relation (because of lack of perimeter), what role can I associate to a generator except... generator? None at all. Because if a generator is a member of a plant, its role is generator. So no need to specify it. Even more: if you force roles to be specified, someone comes along and specifies a generator as dam. This is of course can be very easily and automatically detected as all generators must be generators. But wait! If it can be automatically detected, why should it be specified? Imagine a basket (relation) full of fruits (members). Everyone knows the fruits and their names(tags). Now someone puts notes (roles) on the fruits. On all apples now is a note saying apple, on all pears it says pear, and so on. Would you think of those notes as helpful in any way? You are a professional fruit merchant (mapper). Now your government (the one which writes the proposal ;-) ) decides that in order to sell your fruits you have to put one of those notes on each of them. The neighbours boy comes along and switches all the notes. What do you think of the notes? Are they worth the effort or would you consider changing your job (to google map maker)? (Obviously I like illustrative comparisons) Best 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
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
In my view the streets should be more detailed - after all having the details dropped by computers is possible (even if not always easy). but detail that is not there cannot be add in any simple way. This case might depending on the precise conditions fulfil the requirements for separate direction lanes. If not some more detailed scheme would have to be used - mapping streets as areas. Eventually that will be the only viable option city centres currently mapped in high detail with only the streets being overly simplified... Lukáš Matějka (LM_1) 2013/4/7 Martin Atkins m...@degeneration.co.uk Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
I would see the root problem in the fact that osm has bigger scope that most other maps - from low detail overview maps to very detailed (almost aerial photograph level) city plans. Describing physical area occupied by different features seems to me like the only perspective possibility - With the more abstract features - lanes, streets being represented by relations. That way the routing database would not be alonside it, but would be directly contained in it. The drawback being more processing required to mine useful routing data from the database. LM_1 2013/4/7 Martin Atkins m...@degeneration.co.uk On 04/07/2013 11:58 AM, LM_1 wrote: In my view the streets should be more detailed - after all having the details dropped by computers is possible (even if not always easy). but detail that is not there cannot be add in any simple way. This case might depending on the precise conditions fulfil the requirements for separate direction lanes. If not some more detailed scheme would have to be used - mapping streets as areas. Eventually that will be the only viable option city centres currently mapped in high detail with only the streets being overly simplified... I wonder if the root problem is that we've conflated the idea of the physical construct of a street with its parallel in the routing network. The most complete mapping scheme would use areas to describe the physical area occupied by the sidewalks, street areas, boarding islands and other street features, and then represent the routing network as a separate schematic of ways on top of it with little or no visible impact on normal rendering. That would be very time-consuming to maintain, of course, and would essentially turn OpenStreetMap into a huge, collaboratively edited aerial photograph with a routing database alongside it. :) It seems like the current OSM data model is really designed for and best to suited the low-detail schematic mapping rather than high-detail mapping; abutting features just manifest as ways that happen to share nodes, or worse: ways that happen to just sit alongside one another and have to be maintained individually by mappers. An interesting thought experiment is what OSM might look like if it had started with a different spatial data model. For example, what if it were a graph of connected 2D polygons, like the map format of the Doom or Duke Nukem 3D game engine, or even subdividing 3D space with planes like the Quake game engine? That sort of model would favor realistic physical mapping over schematic mapping. I wonder if it's really feasible for the use-case of highly-detailed renderings and the use-case of highly-accessible collaborative editing of a basic highway network to coexist in the same system; the former is something that requires extensive effort of a single person or coordinated group, while the latter is more suitable when you have many uncoordinated people who each have comparatively little time to spend. (If Google's self-driving cars ever take off in the mainstream I guess we'll *all* have the hardware necessary to create an accurate 3D model of the world and we'll just have to figure out how to store it!) __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Stop sign?
Is there any distinction for direction of the sign? LM_1 2012/11/20 Jo winfi...@gmail.com: I'm mapping them as highway=stop as a node of the way, just before where it crosses the main road. I would map a traffic_sign=stop as a node next to the road. But that just makes it harder to work with the data, so I prefer the first approach. What I never do anymore is to tag the node of the crossing with it. So even if all 4 roads have a stop sign, I'd create for nodes for them on all approaches. Polyglot 2012/11/20 hbogner hbog...@gmail.com How should http://wiki.openstreetmap.org/wiki/File:STOP_sign.jpg stop signs be marked? As highway=stop or traffic_sign=stop Or is there another way? ___ 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] The OSM philosophy (was: Carriageway divider)
This not tagging for renderer is quite misleading. I would always agree that mapping incorrectly for any reason is wrong. But if the mapping is accurate I do not mind that it is for renderer. After all these discussions do not show any globally acknowledged way of modelling reality and renderers/routers seem to be a natural point of unification (There are not many features rendered by the main Mapnik style that are not widely mapped...). LM_1 2012/8/26 Ilari Kajaste ilari.kaja...@iki.fi: On 26 August 2012 10:42, Markus Lindholm markus.lindh...@gmail.com wrote: We're not supposed to map for the renderer nor the router. Exactly for whom are we to map? For nothing, and no one. Which also means: for anything, everything and all. The OSM approach - as I understand it - is to collect data about reality in best way possible, and let the use of that data come afterwards. Let the renderers, routers and whatnot determine how they can best utilize the data. The reasoning behind that is this: If we map focusing on one single case, or even multiple cases, we set ourselves up for bad data that just happens to produce the right result in the case we're looking at. This easily leads to the data becoming unusable for anything else. If we instead map for no particular case, just trying to model reality in best way possible, we might not see any end result immediately, but the data is left intact, in good quality for any emergent uses we're not even thinking about yet. I think it's a very, very good approach. Uses come and go, but the data is what matters, in the end. It's the data itself, the modelling of reality, we need to focus on. -- - Ilari Kajaste - E-Mail: ilari.kaja...@iki.fi WWW: http://iki.fi/ilari.kajaste ___ 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] Tagging amenity=waste_basket
For direction of the benches mapped as ways I would use analogous* rule to cliffs and retaining walls, that is: If you hold the bench with left hand (from the sitting side) you are looking in the same direction as the way. In other words backrest on left side of the way, sitting side on right side of the way. *Lower retaining walls could actually be used as benches LM_1 2012/8/5 Tobias Knerr o...@tobias-knerr.de: Komяpa wrote: PS: Same with amenity=bench [2] I found linear amenity=bench quite useful for micromappning and 2.5D rendering: http://wiki.openstreetmap.org/wiki/File:Kothic-metrics6.png The particular bench in your example could also be modelled as a node with direction and width tags. Nevertheless, one could argue that long benches like this one http://commons.wikimedia.org/wiki/File:Universitaet_Passau_09.jpg would best be mapped as ways. As far as I know, though, there is no obvious or even documented convention on what side of the way the backrest would be? Tobias ___ 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] on the name of a tag for landcover
What about this: Let's have fully qualified hierarchical names, something like landcover=vegetation:herbaceous:grass, landcover=herbaceous:herbs or landcover=vegetation:trees:coniferous That woudld allow precise specification as well as something green grows there. Mappers would understandably not be willing to do it all, therefore any generic qualifications could be omited if the rest is unambiguous. Renderers would be able to easily render all vegetation green (not caring what details come after). Common values like trees or grass would likely (usually) be used without generic qualifiers (would not work on renderers rendering vegetation:doNotCare only). The main advantage is that any detail can be mapped without introducing too many keys of requiring too much detail to be provided. 2012/8/3 Colin Smale colin.sm...@xs4all.nl: On 03/08/2012 13:36, Martin Vonwald wrote: To cut a long story short: landcover=herbs would also be fine, IF we would expect that those tag will be often used and the difference to landcover=grass is substantial enough. As I doubt that I would recommend landcover=grass and grass=herbs. Grass is an example of a herbaceous plant, and we tag from generic towards specific, so it should really be landcover=herbaceous and herbaceous=grass. I would advise against using herbs in this context. Although it may be technically not incorrect amongst biologists, in common English usage it refers to plants used for flavourings etc. like Thyme, Rosemary, and Oregano. Joe Mapper is never going to forget that, although Jean-Luc Cartographe might be excused for confusing grass and herbs (herbe is French for grass, as well as the culinary plants) Colin ___ 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] RFC: Names localization
Let's not forget that this debate was started by naming disputes in Ukraine. I would vote for option 2 myself, but if that would be found impossible, I could agree with Tobias. LM 2012/8/2 Tobias Knerr o...@tobias-knerr.de: Petr Morávek [Xificurk] wrote: Tobias Knerr wrote: You need to realize, though, that mappers in areas where only one language is commonly used will not want to put more effort into mapping names than they do today. And rightly so, imo - from their perspective, it's just more work for little or no gain. Yes, I agree. This is very strong argument for Option 1 and I'm starting to lean towards this solution. Have you considered combining the options? For example you could use option 2 with a single additional rule: If lang contains only one language code, treat name as name:lang_value. So if there is only one main language, lang will contain the code for that language, and name will contain the name in that language. But in multilingual areas, lang contains the codes for all these languages as per option 2, and once mappers in those areas trust data consumers to construct the labels from several name:xx reliably, they can begin omitting the bare name tag. Tobias ___ 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] Data redundancy with ref tag on ways vs relations
Even though the bridges were not the best example, I would not dismiss their importance. Maybe a better example is when two roads (numbers) run on the same asphalt. It is not uncommon in my country and probably possible elsewhere. There is support for this - that is JOSM + RelationToolbox plugin. Potlatch recently gained the ability to highlight all relations, which is great. I will try using it for a while and suggest concrete improvements on this matter. There were concerns if it is more gain for mappers or for data consumers. I am the former and use the later. As a mapper I prefer one thing being present on one and only one place. I prefer one real object being represented by one osm object be it point a way or a relation. As a mapper I hate repetitive work and relations let me get rid of it for some part. I like to know that I have made no mistakes - relations are easier to check than 50 way segments. If the whole street gets a different surface or gets wider, relation at least gives me an easy way to select all members. I like relations when mapping. As a user of osm applications I want them to be as feature rich as possible. Frederick is right that consumers would not go away because data model is not perfect. But they might omit a feature or ten. I started contributing because osm maps were more detailed and precise than any other. Therefore I believe that the better map comes with osm watermark the more contributors the project gains. Lukáš Matějka (LM_1) 2012/8/2 Richard Mann richard.mann.westoxf...@gmail.com: Bridge ref highway ref: bridge ref should have a specific tag, such as bridge:ref=whatever Two roads meet at roundabouts: roundabout has higher-ranking (ie lower) number, unless the higher-ranking road has a flyover or underpass. Or don't have a ref. None of the issues raised justify changing a very well established scheme. Richard ___ 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] Data redundancy with ref tag on ways vs relations
Actually almost any proposal containing relations is criticised from this perspective (relations being too complex/complicated for mappers). You say someone has to do the coding, I disagree. It has already been done. JOSM with RelationToolbox plugin and, as Petr says, Merkaartor are handling relations just fine. As for Potlatch, do not tag for the renderer should apply to editors as well. Maybe the idea that complex reality can be expressed in a very easy way is wrong. That would mean that editors have to become complex or stop being usable for all operations. What way should Potlatch choose is not my decision. For all the rest Petr Morávek wrote, I fully agree with him. Lukáš Matějka (LM_1) 2012/7/31 Richard Fairhurst rich...@systemed.net: Petr Morávek [Xificurk] wrote: This is actually not an argument against any tagging proposal, but argument for improving relation handling in editors. I don't think anyone's arguing with that. But are you offering to do the coding? Because someone has to. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Data-redundancy-with-ref-tag-on-ways-vs-relations-tp5719083p5719179.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] Ferry routes, what's the correct approach?
At the same time there are gates and the access is usually not free for everyone. So access=yes is in fact wrong in some cases. Something like access=customers (passengers of the ferry) might be the middle ground acceptable for both sides. Not knowing how different routers use access I believe that ways marked as access=customers should be routed with some sort of warning. The same goes for access=private. Quite commonly the real final destination would be in some limited access area and so routers do not have to absolutely avoid more restrictive access values than public. Lukáš Matějka (LM_1) 2012/7/31 Philip Barnes p...@trigpoint.me.uk: This thread has prompted me to look at the ferry routes around the UK, and why only certain one are working. The biggest problems I have found, and so far fixed, are not the ferry routes themselves but the access within the ports. A lot of access roads have been tagged to prohibit access (private and the like) thus preventing access the the ferry. The other big problem I have found is gates not being tagged as 'access=yes'. So far I have managed to fix the Holyhead-Dublin/Dunlaoghaire. I did notice a bit of an edit war has been going on with the Holyhead loading ramp for the Holyhead-Dunlaoghaire ferry, where several mappers have done what I have done (fix routing), and the same mapper has come back and again tagged the access ramp/roads as private thus destroying the mapping, will keep an eye on it. Phil On Sun, 2012-06-03 at 12:22 +0200, sabas88 wrote: 2012/6/3 Philip Barnes p...@trigpoint.me.uk [cut] Dover-Calais does seem to work well, you may get some ideas there. http://map.project-osrm.org/xR Thanks, seems similar to how I made the routes in Genoa, we'll see at the next OSRM update how it behaves... I don't understand why way 14271003 (the main route) isn't splitted at node 136942316, the backwards bit is only from that node to the pier, isn't it? Phil ___ 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] on the name of a tag for landcover
When you search wiki for grass, you get landuse=grass. When you type grass in JOSM's preset search box, you get landuse=grass. Potlatch does not offer any direct way to tag grass. landuse=grass was probably used before anyone thought about the difference between landuse and landcover (in osm tagging). Today's renderers support landuse=gras and do not support landcover=anything. That being the reasons for landuse=* domination it is hardly enough to proclaim it the better way. LM_1 2012/7/31 Pieren pier...@gmail.com: On Tue, Jul 31, 2012 at 8:39 PM, Johan Jönsson joha...@goteborg.cc wrote: There are several ways to tag landcover with existing tags but if we where to define a new tag for grass along the lines of http://wiki.openstreetmap.org/wiki/Proposed_features/landcover Why ? We have 1.066.000 landuse=grass and 756 landcover=grass. No vote required (that's perhaps why the proposed feature never tried one). Pieren ___ 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] Data redundancy with ref tag on ways vs relations
Nobody suggests that all information is immediately transferred to relations.But in this particular case where one real-world linear objects is represented by many OSM primitives (better yet if these primitives are common for more objects), relations seem to be the clearly right way to go. 2012/7/31 Pieren pier...@gmail.com: On Tue, Jul 31, 2012 at 10:41 PM, LM_1 flukas.robot+...@gmail.com wrote: Actually almost any proposal containing relations is criticised from this perspective (relations being too complex/complicated for mappers). If you explain OSM to an average newcomer, not a geek or a s/w dev: - yes, concept of relation is complicated (I'm even not talking about super-relations) I am not denying that relations are more abstract and complicated than draw a line - that is a street. Expressing complicated reality without head explosions requires a lot of abstraction, relations would be the minimum. When choosing between the possibility to map complex reality accurately and the extra mappers who are not willing/able to understand the concept of relations, the former always wins. - yes, it is not easy to edit (e.g. hte JOSM relation editor is fine, but hey, you need a special editor dialog with special features just for relations...) And I need one for layers, one for selection, one for tags... The number of features specifically for nodes and ways is still significantly higher. And for the ease of editing I strongly prefer one way being member of multiple relations compared to multiple ways connecting the same nodes - being identical. Try opening Potlatch, draw a square, Draw other areas around to get something like http://img715.imageshack.us/img715/3307/potg.png Try selecting the first square. - yes, big relations are a problem for the API¨ I have to admit that I know very little about such problems - yes, relations are difficult to maintain in long term because it's often broken... by newcomers. Are they really broken by newcomers or by the editors? It is quite difficult not to break something if you are not aware of its existence. Pieren ___ 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] tagging awards and ratings
In my opinion there should be some common prefix (award, rating, does not really matter). That way it is clear what it means even if one does not know that particular rating system. That would probably not be the case with Michelin stars, but most rating systems are less famous. With prefix a sensible presentation is possible even for systems unknown to the application, something not possible without prefix. If there are two entities (hotel and restaurant) eligible for independent award/rating in the same system, they should probably have a different nodes in OSM anyway. If the rating applies to the whole area/facility site relation would be the place for ratings. That is because one object should not be influenced by nearby objects in tagging (adding Subject prefixes and similar. LM_1 2012/7/26 Johan Jönsson joha...@goteborg.cc: Sometimes there is a discussion on how to tag differnt kind of awards and ratings. I thoguht a bit of this http://wiki.openstreetmap.org/wiki/User:Johan_J%C3% B6nsson/Workspace#some_musings_on_the_subject and came up with a pre-draft that I might take further if there is any interest: http://wiki.openstreetmap.org/wiki/User:Johan_J%C3% B6nsson/Workspace#A_preliminary_proposal It is basically like this Award_System=Award With a catchy name for the award_system as key and for each award_system there could be a list of values example 1 Tripadvisor have some awards called Travelers' Choice If someone of some reason would like to tag that, they can use travelers_choice=top25 / best_service example 2 Guide rogue Michelin awards restaurants Michelin=2_stars example 3 there are many hotel star-systems, one is HOTREC by hotelstarsunion (see http://wiki.openstreetmap.org/wiki/Key:stars) HOTREC=3_stars example 4 In the blue flag system beaches are rewarded with the blue flag award blue_flag=blue_flag As you see from the examples, there are some things to discuss. ___ 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=fire_hydrant and wrenches
2012/7/25 Jason Cunningham jamicu...@googlemail.com: On 24 July 2012 19:55, David ``Smith'' vidthe...@gmail.com wrote: Useful to whom? The local fire department should already know, and nobody else should be authorized to open the hydrant anyway — though it seems the biggest reason departments object to unauthorized access is damage caused by using the wrong kind of wrench… Your assuming the existence of something called a local fire department who have some sort of control over the hydrant. This may be the case for the the area your thinking about but not be the case across the rest of the world. Having said that I agree that if people should not interacting with an object then OSM should not provide data on how to do it, especially for something as important as a fire hydrant. Jason More importantly OSM should not censor its data even if there is potential for abuse. (surveillance cameras for crime planning, detailed road maps for attack forces coordination, police using uploaded gps tracks to find locations where cars are likely to exceed speed limits... ) Lukáš Matějka (LM_1) ___ 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] The wiki (was Re: That stupid 'quarter' tag has been approved)
I think that you are both (Steve, Russ) right. If something is mapped for the first time (and documented on wiki) it is not really a standard. If someone else finds it and uses it it becomes one (the more people use it - the more standard :)). If someone finds it and disagrees he should challenge it or document alternative but not ignore it. After a time it is likely that some (one) standard evolves. That would be quite not possible when nobody would document whatever they map before there is a consensual standard. LM_1 2012/6/2 Russ Nelson nel...@crynwr.com: Steve Bennett writes: Again, I'm surprised this discussion needs to be had, but there is clearly very poor shared understanding of what the wiki is for and how to use it. It seems obvious to me that the wiki is to document *shared* understanding of mapping standards. I think you have that almost right but significantly wrong. The wiki is to *share* understanding of mapping standards. Your purpose definition implies to me that there is agreement that an X that is Y will be mapped as X=Y. But just as Inuits have several names for snow depending on its qualities, so may people in different parts of the world have different names for what you consider to be the same Y. For example, I consider surface=gravel to be gravel. You know, those rounded rocks about the size of a pea which come from a riverbank. But many rail-trails have a surface which is ground-up rocks about the size of tapioca or smaller, called rock dust. You wouldn't have me map rail-trails as surface=gravel, would you? That would be more like the ballast that's left behind after the tracks are pulled up. That's why it's important for each of us to *document* how we map. Because if nothing else, in the process of doing so, we will actually take the time to RTFW to see what tags really mean. :-) -- --my blog is at http://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ 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] reference_point and landmark for addresses
Would not the problem with describing the position on the object be that you could still not find the reference object and thus it would be completely useless? If you have a location description referenced from big tree you need to find the big tree. There are multiple ways to get to the location from the reference point - one address can be north from big tree and south from small tree at the same time. We are used to take addresses as absolute positions, but this does not seem to be the case. You have absolute positions of reference points (should be in the map) and then use relative directions to get to the location - this is not an address and should not be tagged as one. Lukáš Matějka (LM_1) Dne 30. března 2012 10:11 Martin Koppenhoefer dieterdre...@gmail.com napsal(a): What about the established tag addr:full? This was intended for cases like this. 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] Value separator
I would choose semicolon, because it is used already (even if not actually supported) LM_1 Dne 4. dubna 2012 23:16 yvecai yve...@gmail.com napsal(a): Hi, What is the best way to 'separate' values? I think about piste:grooming='classic;skating' or 'classic+skating'. Actually, this can be argued that this is a particular grooming type of crosscountry ski pistes, not a simple addition of a 'classic' and 'skating' grooming. So, is there any reason to prefer a semicolon or a plus? Yves ___ 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] dispute about center island in a turning circle
Without willing to interfere in this discussion about the true nature of seemingly similar roundish street features, I'd like to point out that ending a line with a pentagonal or hexagonal approximation of a circle is actually less work than adding a tag on the last node (extra 5 or 6 clicks compared to selecting the node, opening some list, typing first few letters, confirming (or typing it from scratch)...) LM 2012/3/13 Josh Doe j...@joshdoe.com: On Tue, Mar 13, 2012 at 9:13 AM, Paul Johnson ba...@ursamundi.org wrote: On Tue, Mar 13, 2012 at 5:16 AM, Josh Doe j...@joshdoe.com wrote: Definitely not a turning_circle. Either map as a loop or mini_roundabout. -Josh Not a mini_roundabout, either; those typically are painted onto the road surface and don't include a hard island. So we need to do one of the following: 1) Force everyone to draw a loop around the island (too tedious) 2) Change definition of mini_roundabout to allow for non-traversable islands (not happening, since it seems a traversable island is nearly universal, even in the US [1]) 3) Invent new tag 4) Tag as turning_circle, perhaps additionally using a traffic_calming=* value such as island [2] My vote is for #4. Time for me to try out Overpass to get my mis-tagged features... -Josh [1]: http://safety.fhwa.dot.gov/intersection/roundabouts/fhwasa10007/ [2]:http://wiki.openstreetmap.org/wiki/Key:traffic_calming ___ 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] RFC - Bandstand
That seems to be almost philosophical question about a perfect tag. I prefer more structured approach, like you proposed for bathing. LM 2012/3/12 Johan Jönsson joha...@goteborg.cc: LM_1 flukas.robot+osm@... writes: 2012/3/11 Johan Jönsson johan.j at goteborg.cc: leisure=bandstand is a good tag. The bandstand is a prominent feature that is easy to map, so ease of mapping with one tag is prefect. Is this not bad, having more (independent) information in one tag? Imagine that person A - technocratic deaf engineer who hates music and person B - artist who loves music and does not care a bit whether it is inside or outside or anything about buildings. Both happen to be mappers: on cannot input the interesting construction without adding info about music, the other cannot enter music without construction. That is the same reasons that I find this a good tag, whether you are type a or type b, you will know it is a bandstand and tag it with that. Easy. The type a-mapper could add more tags regarding architectural style, the type b-mapper could add more tags regarding music-style. If they do not want or know anything more, the tag bandstand is enough. If per chance they do not know it is called a bandstand I guess there are no problems if they map it with pavilion or music_venue /Johan Jönsson p.s. (As a generalist I would of course prefer if there where a tagging scheme for all pavilions and music_venues out there. building=pavilion pavilion=bandstand and music_venue=open-air_scene, music_venue:size=small or something like that) d.s. ___ 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] RFC - Bandstand
2012/3/11 Johan Jönsson joha...@goteborg.cc: leisure=bandstand is a good tag. The bandstand is a prominent feature that is easy to map, so ease of mapping with one tag is prefect. With one tag it maps both: *the physical building (band_stand says in one word that it is a small open pavilion) *the use/function: scheduled music (a bit informal) Is this not bad, having more (independent) information in one tag? Imagine that person A - technocratic deaf engineer who hates music and person B - artist who loves music and does not care a bit whether it is inside or outside or anything about buildings. Both happen to be mappers: on cannot input the interesting construction without adding info about music, the other cannot enter music without construction. Even worse for them if they want to make a map. A question, there is no such things as indoor band-stands, right? There could be some controversy if one instead want one tag for all small pavilions, garden-kiosks, gazebos out there. building=pavilion If one would want one tag for all music-playing places, leaisure=music_venue or leisure=music. This sounds much, much better. Lukáš Matějka (LM_1) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag the width of a gate
I agree that maxwidth=any_number should be interpreted as general restriction without discrimination. Generally I'd like to see a clearly distinctive tagging of legal (am I allowed to) vs. physical (will I not get stuck) aspects, but that is much broader issue than maxwidth. maxwidth might actually one of the legal limitations that are least arbitrary and most often supported by (bridge) hard reality. Lukáš Matějka (LM_1) 2012/2/26 Mike Valiant mike_vali...@hotmail.com: Originally there was little mention of any of them tags depicting purely legal restrictions. Even access/*=no was unsuitable or not allowed, but later, as it was deemed unverifiable, the only legal started creeping into all sorts of tags, where it may or may not be the common usage, or sensible. I think previous discussions have largely been about roads which may be the only case where there is a legal restrictions apply. In the case under discussion, a gate across a *path*, I think it is unlikely that there will ever be a case where the width restriction is anything but physical. maxwidth:physical as a qualification would be an unnecessary It's not clear whether contributors tagging roads have been differentiating between warning signs (triangular) and prohibitory legal signs (circular). Taginfo suggests not: There are 4147 instances of maxwidth 0 instances of maxwidth:physical 0 instances of maxwidth:legal In my experience the legal restriction is much rarer than the warning signs and physical restrictions. IMHO maxwidth should cover *any* restriction. I shall continue to tag with the majority! //Mike ___ 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] Building tag, building typology vs current function
The value for building key should be the type of the building, not its current use. A church remians church even after islam takes over and its used as a mosque or vice versa (Pécs). Villa is different from apartments or bungalow, but all are usually used for residential purposes. There are poly-functional buildings that contain part of everything and should have separate type. Changing the description was wrong. Lukáš Matějka (LM1) 2012/2/26 Кирилл Zkir Бондаренко z...@zkir.ru: Hi All! Some time ago PeterIto changed the description of tagging criterion from building typology to current function. Looks that there are different points of view for this question. http://wiki.openstreetmap.org/w/index.php?title=Buildingsaction=historysubmitdiff=717395oldid=713015 The discussion on the wiki is currently here: http://wiki.openstreetmap.org/wiki/Talk:Key:building Could you please express your opinion on the issue. Building=* is one of the most used tags, and it would be nice to understand it in the same way, in the whole OSM, even in different countries. Best regards, Kirill Zkir Bondarenko. ___ 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] Tag approval process or its absence (was: Voting for Relation type=waterway)
Hi 2012/2/21 Frederik Ramm frede...@remote.org: Hi, On 02/20/2012 10:59 PM, LM_1 wrote: The possibility of free tags is great, but once some tagging style proves as usable (and better than any other), ... which will never be the case ... I know, it is a kind of ideal state, the closer we are to it, the better. it should become a standard and used exclusively ... in which geographic / cultural region? In all of them. Lukáš Matějka ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging of ele / elevation data e.g. in the context of towers
As I understand it option a) is correct. If put on a building it would mean that the ground level is at this height. In some specific cases this might bring problems though: imagine a lot of stones and earth is transported on the hilltop, the elevation clearly changes. If you build a building there the elevation is unchanged. Now what if you cover this building with earth to look more natural? How thick layer of earth is required for the elevation to change? But these cases will be uncommon and I still vote for a) Lukáš Matějka (LM_1) 2012/2/20 Martin Koppenhoefer dieterdre...@gmail.com: On the German ML we are currently discussing how to applicate ele to towers (and similar situations). There is consensus that the key height is describing the height of the structure from the ground to the top. There is also consensus to tag elevation data in WGS84 (so that numbers in local systems would typically have to be converted before you can enter them). There are 2 alternatives: a) ele is the elevation of the ground around/below the tower (in the case of a mountain summit it would be the elevation of the mountain, not the tower). b) ele is the elevation of the highest point at the tagged spot, i.e. the top of the tower Comments welcome. The idea is to clarify this aspect on the wiki page for the key ele. 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] tagging of ele / elevation data e.g. in the context of towers
Generelly yes, but if there is a tower on the summit, there is not really any other way. Lukáš 2012/2/20 Frederik Ramm frede...@remote.org: Hi, On 02/20/2012 01:06 PM, LM_1 wrote: As I understand it option a) is correct. If put on a building it would mean that the ground level is at this height. Should one not then, to avoid misunderstandings, use ele only on ground-level features? We can define away on the wiki all we want; there will always be people who read ele on a building to mean its height. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging of ele / elevation data e.g. in the context of towers
From what has been written here it seems that elevation clearly does not contain buildings. Frederik Ramm: You would normally put a natural=peak tag next to the tower anyway. Or if you don't, then attach ele to the bench near the base of the tower or so ;) Most peaks with some construction on them have a pile of stones or some other marking with some elevation label. Yes, I usually would put natural=peak there. Not always there is a peak nearby. Imagine an end-station of a ski lift that does end under the peak. It seems sensible to put elevation tag on it, but there is no suitable natural object nearby. Therefore it should be clear how to map this. Lukas ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Custom mailboxes
I would not do that or care for such information, but why not... There is no too far LM_1 2012/2/20 Nathan Edgars II nerou...@gmail.com: Would it be reasonable to map custom personal mailboxes that are essentially public art (e.g. in the shape of a manatee)? Or is this going a bit too far? ___ 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] Tag approval process or its absence (was: Voting for Relation type=waterway)
2012/2/20 Chris Hill o...@raggedred.net: Flattening the tag structure by homogenising tags is destroying the fine detail, sometimes carefully crafted by mappers and I will continue to speak out against mass edits that attempt to do just that. I have to disagree. If the tag structure is not homogenised, it makes the data useless. Non-standard and/or undocumented tags are impossible to process in any reasonable way, even if they look perfectly complete and informative to human. The possibility of free tags is great, but once some tagging style proves as usable (and better than any other), it should become a standard and used exclusively (or be challenged by a better one later). Lukáš Matějka (LM_1) 2012/2/20 Chris Hill o...@raggedred.net: On 19/02/12 23:38, Steve Bennett wrote: On Mon, Feb 20, 2012 at 2:53 AM, Chris Hillo...@raggedred.net wrote: I do not agree with the whole basis of this thread. There are no such things as approved tags, tagging is open and people are free to use *any* tags they like. ... Advertise your ideas and encourage acceptance. Show how well it works any How would you know whether a tag had acceptance? Wouldn't documenting it somewhere make sense? Maybe...in a wiki? I did say document and discuss the OP. What would you call acceptance? Would approved be a reasonable synonym for that? No. It implies some official status that leads people to remove other tags, sometimes with mass edits. The wiki and (currently broken) approval mechanism is not some horrible bureaucracy that exists to ruin your life. It's there so we, as a community, can document the tags we use, and agree on how we use them. While it's ok to spontaneously invent a new tag and use it to solve your current problem, you can surely see the benefits of everyone eventually converging on the same tag? And if so, what would you do with all the old tags that people used before you converged? Wouldn't you deprecate them? No, some tags will wither away, fine. Some seemingly similar tags will exist side-by-side and that is fine too. Most importantly, distinctive differences can emerge too. Just think this through. Approval implies some sort of enforcement, without enforcement what is the point of approval? Just who would make this enforcement happen and how? What would that do to an open project? If only approved tags are used then how would mappers map what they actually see? Wait weeks for some committee to discuss, argue and approve or reject the tag? If you are free to use any tag, what is an approval process for? If approval or 'acceptance' means a tag is rendered or used in a router or whatever then which tool do you mean? There are hundreds run by OSM and other organisations, companies and individuals. Flattening the tag structure by homogenising tags is destroying the fine detail, sometimes carefully crafted by mappers and I will continue to speak out against mass edits that attempt to do just that. -- Cheers, Chris user: chillly ___ 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] man_made
The place is right, but: Why? What good would that change bring? Lukáš Matějka (LM_1) 2012/2/19 Amanda amanda...@gmail.com: hello! new here. don't know if it's the right place to address this issue, sorry if i'm mistaken.. my suggestion is: MAN MADE should be called HUMAN MADE ___ 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] When should a name:* translation be used?
Some cities/towns (especially those that are important for a long time) have different names in different languages (here in Europe almost every major and many minor towns). If there is such a name, it should be added. If I browse through map of China, I would like to see Peking (Czech name), I can live with Beijing, but 北京 is not helpful at all. Of course this name should be generally used by users of the language, not just translation. Survey (of language use) should be as good source for language translations, as it is for mapping. Lukas (LM_1) 2012/1/30 Craig Wallace craig...@fastmail.fm: On 30/01/2012 17:53, Nathan Edgars II wrote: I ask because someone added a name:vi tag for Orange County, Florida: http://www.openstreetmap.org/browse/relation/389011 As far as I know, there is no large Vietnamese population here and no other reason why someone would want to know the literal translation of Orange County into Vietnamese. I think its fine to add other language names for things if you have a reliable source for it (under a suitable licence). So if its signposted somewhere, or if its on a list from the official language agency, or from an official published map (with permission to use it) etc. And preferably a source specific to that place. Two places might have the same name in English, but different names in another language. I'm not convinced that Wikipedia is a reliable source for other language names. Craig ___ 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] Proposal for a generic : type=multilinestring
The idea itself is good, it could secure more consistent tagging and easier automatic processing of data. In the proposal it says: If you have one way making up the line string ring and it does not describe something in its own right, you may also put these tags on the relation and leave the relation untagged. - that does not really make sense to create such relation (one way tagged relation would make splitting the way easier). The order of the relation members does not matter (but properly sorted member lists can help human editors to verify completeness). - I believe it should be always sorted, yet routers/renderers should not rely on it. How would it be used in this situation?: border of two countries (A, B) is also border of lower administrative divisions (AC, AD in country A and BE,BF in country B). going along the border you go through different combinations (A-B all the way; AC-BE-AD-BE-AD-BF; see image). In reality there would be more than two levels and therefore much more combinations. How would it solve the case of river bifurcation if the river merges together (river island, the same river flows on both sides)? How would it solve similar case of streets (lanes for different directions split for some time and later merge together)? Thanks for answering these questions Cheers Lukas (LM_1) 2012/1/26 sly (sylvain letuffe) li...@letuffe.org: Hi, I'd like your opinions on the following proposal : http://wiki.openstreetmap.org/wiki/Relation:multilinestring You are wellcome to discuss it either by replying to this email or by commenting on the wiki. I'm also willing that this proposal is used, as a first step, to replace http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment which I previously proposed without public audience. As a independant side note : I am willing to activate the wiki voting system for this proposal as it seams most relation proposals never used it and have a tendancy to evolve in a way making them incompatible with their previous definitions -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for a generic : type=multilinestring
Sorry I forgot the image. Here it is: The idea itself is good, it could secure more consistent tagging and easier automatic processing of data. In the proposal it says: If you have one way making up the line string ring and it does not describe something in its own right, you may also put these tags on the relation and leave the relation untagged. - that does not really make sense to create such relation (one way tagged relation would make splitting the way easier). The order of the relation members does not matter (but properly sorted member lists can help human editors to verify completeness). - I believe it should be always sorted, yet routers/renderers should not rely on it. How would it be used in this situation?: border of two countries (A, B) is also border of lower administrative divisions (AC, AD in country A and BE,BF in country B). going along the border you go through different combinations (A-B all the way; AC-BE-AD-BE-AD-BF; see image). In reality there would be more than two levels and therefore much more combinations. How would it solve the case of river bifurcation if the river merges together (river island, the same river flows on both sides)? How would it solve similar case of streets (lanes for different directions split for some time and later merge together)? Thanks for answering these questions Cheers Lukas (LM_1) 2012/1/26 sly (sylvain letuffe) li...@letuffe.org: Hi, I'd like your opinions on the following proposal : http://wiki.openstreetmap.org/wiki/Relation:multilinestring You are wellcome to discuss it either by replying to this email or by commenting on the wiki. I'm also willing that this proposal is used, as a first step, to replace http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment which I previously proposed without public audience. As a independant side note : I am willing to activate the wiki voting system for this proposal as it seams most relation proposals never used it and have a tendancy to evolve in a way making them incompatible with their previous definitions -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging attachment: multiline.png___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Chaos and uncertainty in bridge
I agree that what you describe is bad. I agree that your first point can be inferred from what is on the bridge (sometimes there can be more). After a short research: All values that you mention in 2 (together with bascule) are structure types . Number 3 (without bascule) is mode of operation for moving bridges. So my suggestion would be: bridge=[arch;suspension;cable_stayed;bascule;beam...] just like http://en.wikipedia.org/wiki/Bridge#Types_of_bridges The third would indeed deserve a separate tag, I suggest bridge:movable=[drawbridge;swing;lift;yes (moves in an unspecified way)] For your photos: N1 - if it can be considered a bridge at all it should have separate value, eg. bridge=zip_line N2 - suspended bridge, if it should be more specifiic something like bridge=suspension:[simple; underspaned; stressed _ribbon; suspended_deck; self_anchored...] could be used Lukas (LM_1) 2012/1/16 Martin Koppenhoefer dieterdre...@gmail.com: Currently the documented values for bridge don't seem to follow any (single) classification system. http://wiki.openstreetmap.org/wiki/Key:bridge Fortunately 98.49% of all actually used values don't have this problem (they are yes), but the rest seems a mess: 1. There is a first classification system using the kind of way going over it for distinction: 1.1 A road (or railway): viaduct (a term that is not really well defined, especially the distinction between a bridge and a viaduct doesn't seem to be clear). This is a bit mixed because besides the road this seems to be a bridge with several abutments in small distances, whatever small is, and viaduct seems to be used also in conjunction with railroads. Not sure but I feel as viaduct might also be a bridge typology (see 3). 1.2 Water: aqueduct (suitable for the parts of aqueducts that span over a void). The definition seems to extend the use to all kind of aqueducts (A longer structure for carrying a canal or fresh water.) while many aqueducts are not spanning over something (they are tubes, have a solid support like a wall without openings or even are underground) so they clearly aren't bridges. This first system doesn't make much sense IMHO, because you can already see by other tags which kind of way is on top (waterway, highway, railway), but it is currently the most used. 2. Another classification system on the page is one according to the structural system employed: 2.1 arch 2.2 pontoon 2.3 suspension 3. And even another system is that of typology: 3.1 bascule 3.2 drawbridge 3.3 humpback 3.4 lift 3.5 swing so why is this bad? one might argue. Well, the problem is that with this chaos you won't be able to tag all properties (typology, structural system, carried way) of a bridge, you will instead have to decide which one to focus on (might also lead to tagging wars). Another problem is that the lack of systematics makes it difficult to extent this system with new values, because it is not clear where the focus is. I propose to use distinct tags for these properties instead: 1. is not needed IMHO (see above). If the interesting fact for viaducts are the several small spans I'd put this into typology. 2. could be tagged with bridge:structure (or structure or structural_system) 3. could be tagged with bridge:type (or type). Last but not least I'd like to ask you for comments on 3 new values: N1. a bridge made of few ropes where you walk on a rope: http://bauwiki.tugraz.at/pub/Baulexikon/HaengeSeilBrueckeB/Kaiserschild_1.jpg http://www.gruppenstunden-freizeit-programme.de/ferienlager-freizeiten-erlebnisse/freizeit-bilder/seilbruecke/Piratenlager-05-262.JPG http://www.bergsteigen.at/pic/d6025434-21f9-4d93-9ce9-42aba5cf00db.jpg additionally we could tag the amount of ropes (or even more precisely the amount of upper and lower ropes) are these described in English with the term zip-line? http://en.wikipedia.org/wiki/Zip-line N2. a similar bridge made of ropes, but you walk on planks: http://bauwiki.tugraz.at/pub/Baulexikon/HaengeSeilBrueckeB/Trift_Bruecke_1.jpg http://bauwiki.tugraz.at/pub/Baulexikon/HaengeSeilBrueckeB/Tripsdrill.jpg I guess this would be a simple_suspension_bridge N3. A Cable-stayed_bridge (the absence of this value makes it probable that most of these might currently be tagged as suspension bridges or not classified at all). The difference from a suspension bridge is that the cables are directly attached to the towers / pylons instead of to another cable, see here: http://en.wikipedia.org/wiki/Cable_stayed_bridge 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] Amenity swimming_pool (was Amenity parking)
That is what I am saying - access=no is useful as a generic value to make exceptions (like foot=yes) from. LM_1 2012/1/16 Ben Johnson tangarar...@gmail.com: On 16/01/2012, at 6:45, LM_1 flukas.robot+...@gmail.com wrote: Given that absolutely everything on the planet is accessible by at least someone with the right authority, permission, ownership, special equipment, etc. is there ever a need for access=no ? As a default in combination with eg. access=no, foot=yes meaning nothing except foot - it is easier than excluding each use individually. access=no alone is really not usable. Maybe for paths in places of nuclear explosions. LM_1 But is (access=no and foot=yes) the same as just foot=yes? My thinking is they are different. foot=yes in isolation leaves open the possibility of other access methods open, whereas if used in conjunction with access=no, it is confirmed as strictly foot only. As for nuclear explosions... it's dangerous, but you still can go there. You'd be highly advised to take special equipment! access=no alone would be useful for a wildlife reserve where absolutely no humans are ever allowed under any circumstances, but I know of no such place! BJ ___ 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 - combined transport terminal
Hi Michael, I have seen the proposal and like the idea in it. A place where the mode of transportation is changed is important at least for route planning. This does not have to be valid only for goods, but for passengers as well - places where you switch from car to plane and then from plane to train - no matter if it is a person or a gift package or a goods container... The problem with your proposal is that it does not say much, in fact it is very incomplete. If you improve it, I will be glad to support it. LM_1 2012/1/4 Michael Wickert michael.wick...@googlemail.com: Hi Polyglot, sorry for answering so late: http://wiki.openstreetmap.org/wiki/Proposed_features/combined_transport_terminal Michael On 20 December 2011 12:07, Jo winfi...@gmail.com wrote: Hi Michael, It would really help if you had added a link to this proposal. I look at the recent changes on the wiki, but didn't see anything relevant. Polyglot 2011/12/20 Michael Wickert michael.wick...@googlemail.com Dear Sir or Madam, please would you be so kind to comment my Proposal for a new map feature concerning combined transport terminals. It can be used around the world to describe transshipment terminals for e. g. containerized goods. Not only in harbours – there is the need of Hinterlandterminals too. Yours faithfully Michael Wickert Technical University of Applied Sciences Wildau Germany TH Wildau ___ 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] How to tag a dovecot?
2012/1/9 Volker Schmidt vosc...@gmail.com: Hmmm. man_made=dovecote historic=yes This combination would indicate that the building was a dovecote at some point, but is no longer in use, wouldn't it? Without historic it would still be in use, I suppose. I am surprised that this is such a rare tag - there must be many of these very characteristic buildings around in the world. Here in Italy at first glance they look like fortification towers. Not really, it is quite rare to see one in central Europe, afaik they used to be made of wood here so they did not last. Volker On 9 January 2012 15:38, Vincent Pottier vpott...@gmail.com wrote: Le 09/01/2012 11:31, Volker Schmidt a écrit : I would like to tag a historic dovecot (colombara or torre colombaia in Italian). I cannot find an appropriate existing tag. Volker Padova, Italy http://taginfo.openstreetmap.org/tags/man_made=dovecote -- FrViPofm ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- Volker SCHMIDT Via Vecchia 18/ter 35127 Padova Italy mailto:vosc...@gmail.com office phone: +39-049-829-5977 office fax +39-049-8700718 home phone: +39-049-851519 personal mobile: +39-340-1427105 skype: volker.schmidt ___ 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 - Voting - /entrance/door - Indoor mapping - Buildings
Hi, Generally I am in favour of 3D and very detailed mapping even of buildings' inside, but putting number of nodes inside a building outline just does not seem very sensible. It seems like stretching the current mapping model far beyond it should ever be. For how to do it, I believe that there would have to be some object model so that one could edit it separately from the rest of the map. This would generally consist of several layers - one for each different level. It would require editor support. It would allow to accurately map the whole building even with the shops/offices... inside. Maybe it could save some space, because inside of the building would have its own coordinates - no need to relate it to the whole world and measure in latitude/longitude - meters would be more sensible in this case. The whole object would be placed in the map. (Add textures and you have almost 3D buildings like Google or Nokia). Specifically for your proposal's details: I do not see any good reason why an inside door (entrance to living room) should be tagged differently than an outside door (entrance to building). That is apparent from the door location - part of building outline. Dividing rooms as safe/unsafe is not reliable and therefore not a good reference point for everything else. If you go from a corridor to some room, it is clear, if you go from one room to another they are the same. There is already an established division between left/right door - no need to invent a new one. (After a bit of research it seems that English language is not as clear as Czech and there is some confusion). The accessibility information section is confusing and and inconsistent. door:automatic=(no)/yes(non-specified of the following)/switch(button)/remote/card(RFID or swipe)/proximity/biometric/... Cheers Lukas (LM_1) 2012/1/5 Peter Wendorff wendo...@uni-paderborn.de: Hi Andreas. I didn't vote (yet), because I'm a little bit ambiguous about it. On the one hand I like detail mapping and even indoor mapping ideas, but - and here is the (or at least one) comment you requested: Indoor mapping leads to mapping in more than one level in buildings most often. Currently that's often done at - bridges and tunnels - using ways intersecting in the editor - shops in malls etc. that have more than one level - here it's most often nodes, and therefore not very complicated. One big problem with complex mapping scenarios is that it gets more difficult to keep the data correct and up to date. That's a problem with relations very often, yet, and it will be a much bigger problem with indoor data, as I'm not able to fix a wrong building outline, if I'm not able to check, fix or update the indoor data accordingly. And it gets really much data in small areas very fast, if you start mapping indoors. From my point of view I would not vote for your proposal as long as there's no solution for handling indoor data, at least as a proof of concept implementation in at least one of the editor programs. There are more points in your proposal I would be able to give feedback to, but my time is limited currently - probably you'll get more in future from me ;) regards Peter Am 05.01.2012 16:50, schrieb Andreas Balzer: Hello again, so far the voting on the door proposal for indoor mapping got 7 votes (positive and negative). See http://wiki.openstreetmap.org/wiki/Proposed_features/entrance/door I would appreciate if more people can vote and comment their ideas on the dicussion page. So far many people commented that they don't like the structure but haven't send in details on why or on what they would change. I'm faily new to openstreetmap and happy about every comment and detail I can get on this. Thanks, Andreas From: em...@andreas-balzer.de To: tagging@openstreetmap.org Subject: Feature Proposal - Voting - /entrance/door Date: Sat, 24 Dec 2011 11:51:21 +0100 Hello, I would like to hand in a request for voting on http://wiki.openstreetmap.org/wiki/Proposed_features/entrance/door. It is about how to tag a door which is especially useful for indoor tagging. Andreas ___ 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] power=tower enhancement
tower:riser=yes seems good and in need it could be enhanced with yes being replaced by power, telecommunication etc. For basic processing it is simple (any value but no means some sort of riser) if more precise info is needed, the information is there. LM_1 2011/12/14 Владимир Поквалитов p...@isnet.ru: I'd suggest to use power:riser=yes instead of riser=power (to remain compatible if we should decide to map telco lines as well in the future, so we could use telecommunication:riser for those). I'd suggest to use tower:riser=yes (or tower:riser=*). So we can use the same tag not only for power towers but for any (i.e. communication) tower that a risers. power=tower, man_made=tower do fit well with the power: namespace because they explain the tower value of any root tag. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
