Re: [Tagging] Feature Proposal - Voting - shop=storage
Was this RFC ever submitted to the mailinglist?
Shop sounds a bit strange to me as you say, maybe it's also just that
non-native speakers see it a bit different. But as you say we kinda lack
a key for services.
On 3/9/15 08:50 , Jan van Bekkum wrote:
As the comments period is over and no comments have been received lately
I would like to move the proposal shop=storage
http://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dcar_storage
to stage voting.
I have done some final editing to cover the received feedback.
Instructions for voting:
* Log in to the wiki - top right corner of the page -scroll up
* Then scroll down to voting and click on 'edit'
* Copy and paste for * yes - nowiki {{vote|yes}} /nowiki, for
no - nowiki {{vote|no}} /nowiki
Thanks for your support!
Regards,
Jan
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
--
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways
2015-03-11 8:24 GMT+01:00 Richard Fairhurst rich...@systemed.net: Please let's not adopt deletionism as well. +1, seriously. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-11 13:53 GMT+01:00 Pieren pier...@gmail.com: I search an adjective about this tag and I hesitate between very_bad and horrible ;-) In my opinion this tag is pretty bad. Btw, what's different today about its verifiability ? I think most of the people rejecting this tag simply ignore the discussions around it. Which is another problem: ignorance never leads to a solution. Especially if those people don't come up with any other - practical and feasible - suggestion. And this brings us back to the tag smoothness. It is completely subjective if the tag is good or bad, excellent or horrible. But it is 100% objective that this is the best tag, simply because it is the only one (please remember: practical and feasible). So I support the removal of the section Controversy. Maybe add some note about the limited verifiability. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
2015-03-11 12:06 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-03-11 12:56 GMT+01:00 Jean-Marc Liotier j...@liotier.org: As you can see, each block is subdivided into land plots - each with a courtyard and several buildings that usually all belong to an extended family. Those land plots have a strong significance and the frequent sighting of spontaneous attempts by to map them in various ways is testimony to that. I do not yet have an answer to this requirement - it should obviously be mapped as an area but I have so far failed to select satisfactory attributes to model it. I believe that landuse=* is not suitable - in Senegal, as http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal recommends, the whole urban area is landuse=residential, so it is not available to map smaller subdivisions. maybe a new place value? Of the existing ones, maybe place=neighbourhood? Although this is a really small nieghbourhood compared to other areas with this tag. I don't see a problem in the whole area being landuse=residential, still you could split these into several smaller landuse=residential, but I agree that there will be no inherent semantics about the special situation there with just the landuse tag. I also think that landuse=residential, plus name=* or whatever, is fine. It's how I and some others map housing estates in the UK. I might carve out a portion of the larger landuse=residential. (Not everyone does it this way.) Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Haul Channel
On 12/03/2015 05:49, Warin wrote: On 11/03/2015 4:06 AM, Sam Dyck wrote: In Canada, privately licensed frequencies, not CB Humm Why call it a 'channel'? And not 'frequency? Might reduce confusion with CB radio channels? And why 'haul'? I'm actually having no success finding examples of the phrase 'haul channel' in actual use via Google. Is it short for 'long-haul channel' or something? -- Steve --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
On Mar 11, 2015 7:44 PM, Markus Lindholm markus.lindh...@gmail.com wrote: On 11 March 2015 at 18:04, althio althio.fo...@gmail.com wrote: The trouble is there is no definition yet of city_block Not so. When I added it to osm wiki I also put there a reference to the definition found in Wikipedia and that's also how I've used the tag. I am sorry that I missed your page. I am referring to http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block Where is your page? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] square_paving_stones:width
As described in paving_stones:n thread there is a problem with surface=paving_stones:integer values. To offer better alternative for storing information about size of square paving stones I am proposing this tag. Key: square_paving_stones:width Value: size of square paving stone in cm. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-11 23:15 GMT+01:00 David dban...@internode.on.net: I consider the definitions quite reasonable for this tag. Yes,there is a degree of subjectiveness there,there has to be given what it is trying to do. Honestly, we really need to got over this dread fear of being subjective. Not everything can be measured in integer numbers, great when it can be but accept it when what is being described is, by its nature, difficult. +1, I believe that the main problem are the value names. If these were called grade1 to grade8 many more people would likely use these values and I guess there would be much fewer objections. The property of smoothness is really quite important to many users of a road, in the more extreme cases likely important to all. The thing is, that these verbal descriptions of a smoothness hierarchy are mostly not easier to apply than any numeric scale. Excellent, good and impassable are exceptions, but you can't tell the dfifference between bad, very_bad, horrible and very_horrible without looking this up in the wiki. I suggest to add another column to the definition which is about objective figures (without removing the use classes), e.g. the biggest grain size you can frequently find on the road (i.e. the biggest rocks / pebbles) and or the size of eventual cracks and holes, the steepness of steps, height of humps, etc. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-12 7:24 GMT+01:00 Warin 61sundow...@gmail.com: That is a very complex question. You may add bicycle to the vehicles too. Animals and humans .. too? Soft surfaces may not support the vehicle weight (given a tyre size and number). Slippery surfaces may no provide enough traction. Rough surfaces may though a vehicle off the require path. Very rough surfaces may require lots of ground clearance. This might be combined with the above 'rough surface'? +1, an (almost) perfectly smooth surface will likely require low speed because it will be very slippery, a (theoretical) perfectly smooth surface will be unpassable (no traction). These conditions do not typically occur on roads though, save for ice roads ;-) Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Imports] [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster
On mercredi 11 mars 2015, Bryce Nesbitt wrote: in some cases it's modernizing tagging I don't like the sound of Modernizing tagging in a mechanical way, that should be handeled with care, and time. If you intend to replace all type=deciduous to leaf_cycle=deciduous send a new email with a new title so that people know what you'r up to. But I'still against integrating that change to a well understood mechanical revert of a previous mechanical edit To be clear: Initial post to the mailing list involved: *removing useless fixmes* Based on list feedback, the discussion shifted and was focused on one task: * remove denotation=cluster along with the fixme* (the fixme was in fact recognized as flag for the bad data). I'm still okay with that. As long as it means removing denotation=cluster as it was automatically added with the fixme=set␣better␣denotation. But not manually entered denotation=cluster like : http://www.openstreetmap.org/node/2919343692/history If you wish to, please send another email with title : removing all denotation=cluster tags on natural=tree On the table now: * performing remaining needed cleanup on objects that will be edited anyway* And I'm not okay with that unless discussed on a separated topic -- sly, direct contact : sylv...@letuffe.org http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
Landuse=* is not just about defining a residential area or an industrial zone. I use all of the class landuses to define the individual grounds for a specific company’s factory or for a certain shop. yes, I can use the landuse to define a section, but I just as often use it to define individual places - just as one defines a school, park, hospital, or other facility. I am mapping Maebashi, Japan street by street thanks to a recent imagery update. http://www.openstreetmap.org/#map=17/36.42821/139.03987 http://www.openstreetmap.org/#map=17/36.42821/139.03987 There is no reason you can’t use landuse=residential on the land, wall on the border, and a building=* as necessary. This is the only intended use of landuse=religious, for example - define the grounds of a religious place. Plot=* could be applied to many different kinds of land ownership, just as the other industrial, commercial, and industrial landuses are already used in this way. if you really want to map the landuse of individual houses, or even contiguous blocks of residential housing, the landuse=residential is for you. The blocks might be numbered (like Japan), and the house numbered below that. (no street names or sequential numbers, as the plots are not numbered based on street location). I went looking fro an answer to this just now, (assuming Japan Tagging solved this issue) because these block numbers are absolutely necessary for visual navigation (they show up on Google and Apple maps, for example) So I compared the wikipedia entry on the Japan addressing system to the OSM wiki page for Japan tagging to find an answer. http://en.wikipedia.org/wiki/Japanese_addressing_system http://en.wikipedia.org/wiki/Japanese_addressing_system http://wiki.openstreetmap.org/wiki/Japan_tagging#Places http://wiki.openstreetmap.org/wiki/Japan_tagging#Places There are two land naming systems in use in Japan (old and new), and between them and the special cases, they use up all the values between “city” and “neighborhood” (not every value is used for every address, it is a mix for each area), so some kind of administrative value for “place=block” will have to be used for the last level between “neighborhood” and “street address” (plot # in Japan), which is currently undocumented on the JA tagging Wiki page. . It might help this labeling situation as well. Javbw On Mar 11, 2015, at 9:56 PM, Dan S danstowell+...@gmail.com wrote: 2015-03-11 12:06 GMT+00:00 Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com: 2015-03-11 12:56 GMT+01:00 Jean-Marc Liotier j...@liotier.org: As you can see, each block is subdivided into land plots - each with a courtyard and several buildings that usually all belong to an extended family. Those land plots have a strong significance and the frequent sighting of spontaneous attempts by to map them in various ways is testimony to that. I do not yet have an answer to this requirement - it should obviously be mapped as an area but I have so far failed to select satisfactory attributes to model it. I believe that landuse=* is not suitable - in Senegal, as http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal recommends, the whole urban area is landuse=residential, so it is not available to map smaller subdivisions. maybe a new place value? Of the existing ones, maybe place=neighbourhood? Although this is a really small nieghbourhood compared to other areas with this tag. I don't see a problem in the whole area being landuse=residential, still you could split these into several smaller landuse=residential, but I agree that there will be no inherent semantics about the special situation there with just the landuse tag. I also think that landuse=residential, plus name=* or whatever, is fine. It's how I and some others map housing estates in the UK. I might carve out a portion of the larger landuse=residential. (Not everyone does it this way.) Dan ___ 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
Re: [Tagging] [Talk-bf] Buildings blocks
2015-03-12 7:54 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: reference to the definition found in Wikipedia and that's also how I've used the tag. and if someone changes the Wikipedia page, the definition for our tag will change as well? How likely is that? Not that somebody edits the page but that the definition would change in a material way? I believe the definitions for our tags should be in our wiki, and not in external sources which have different scope and are continuously changed. This is also about focus, i.e. stating what are the key properties that must be met. Wikipedia articles tend to get longer by the time, and I don't want mappers to be required to read long articles to get to know the meaning of a tag, or to have continuous minor changes to the meaning of a tag which might sum up to more substantial changes by the time, without actual mappers making those changes. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Temperature=
Warin, you have a 50/50 split. Maybe it's better to try to address the issues and re-vote the proposal? We could have a good tag, but we are going towards a barely accepted one. My main concern is not even that we don't have the vast majority support, but that the proposal hasn't provided a clear answer to some open questions. Cheers, Kotya On Thu, Mar 12, 2015 at 1:57 AM, Warin 61sundow...@gmail.com wrote: Well a summary at ~ 2 weeks Total votes 15. Approvals 7. So it is close. Please vote! In another week I've evaluate the votes and proceed from there. ___ 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] Feature Proposal - Voting - Reception Desk
2015-03-12 2:53 GMT+01:00 Bryce Nesbitt bry...@obviously.com: The level of opposition -- regardless of the technical count -- indicates the proposal can use some improvement. I urge any person getting this level of opposition to reconsider, resolve the issues, and resubmit. If you look at the actual comments, almost none of them are useful, sometimes already answered (but still repeated by following voters). E.g. - It's not simple at all. Using amenity https://wiki.openstreetmap.org/wiki/Key:amenity=* for this makes it impossible to combine it with such POIs. Also why amenity at all? For me it looks like a I didn't find anything better, I mean amenity https://wiki.openstreetmap.org/wiki/Key:amenity=reception_desk https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk can't even stand on its owm. with which POI should this be combined _on the same object_? I mean, this is a tag for a reception desk, obviously it can be combined with other amenities by putting it inside them, but you won't have many objects that are at the same time a reception desk and don't know, toilets? An example why this is a problem would help to understand the reservation. - this comment pops up several times (as the only reason for opposition): The tag is related to tourism and not to amenity. but it was already answered: this is nothing particular to tourism, it can appear in all kinds of companies, administration contexts etc. - vague, half-baked is not a critic that helps to improve or even shows potential problems - The proposal Sems to me too isolated, it should be embedded in an indoor tagging scheme. the voter wants a complete indoor tagging scheme and therefor opposes a tag that might be one of the first steps towards this? - It should not be an amenity, the definition is vague, and in most cases this should go under indoor mapping, which is quite a complex subject. I didn't know indoor mapping was a different part of the project. You can discuss the vagueness of the definition, but to me A Reception Desk provides a place where a visitor goes to gain information and or access to the facility e.g. could be in a motel, office, campsite. It has been suggested as an additional tag for a campsite .. but would be better as a general tag as reception desks occur in many other places. isn't too vague. - This tag needs more time. not helping in any way to find potential problems. No substantial critique. the only useful point of critique is this one IMHO: The reception is not necessarily a 'desk'. More than the proposal I think the reasoning for opposing the proposal would have to be improved. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
+1 But make it 1-8 note grade1-grade8 for simplicity IMHO. The grade1-grade5 for tracktype is an error in itself... It does not matter if it's easier or more difficult - the main thing is that people using it should know what they enter. With the current values like good some mappers just use it without knowing what is behind the value - therefore often rendering smoothness unusable - because the values are unrealiable. On 12.03.2015 10:36, Martin Koppenhoefer wrote: 2015-03-11 23:15 GMT+01:00 David dban...@internode.on.net mailto:dban...@internode.on.net: I consider the definitions quite reasonable for this tag. Yes,there is a degree of subjectiveness there,there has to be given what it is trying to do. Honestly, we really need to got over this dread fear of being subjective. Not everything can be measured in integer numbers, great when it can be but accept it when what is being described is, by its nature, difficult. +1, I believe that the main problem are the value names. If these were called grade1 to grade8 many more people would likely use these values and I guess there would be much fewer objections. The property of smoothness is really quite important to many users of a road, in the more extreme cases likely important to all. The thing is, that these verbal descriptions of a smoothness hierarchy are mostly not easier to apply than any numeric scale. Excellent, good and impassable are exceptions, but you can't tell the dfifference between bad, very_bad, horrible and very_horrible without looking this up in the wiki. I suggest to add another column to the definition which is about objective figures (without removing the use classes), e.g. the biggest grain size you can frequently find on the road (i.e. the biggest rocks / pebbles) and or the size of eventual cracks and holes, the steepness of steps, height of humps, etc. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-12 11:21 GMT+01:00 Martin Vonwald imagic@gmail.com: Is grade1 now excellent or horrible? No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. it really doesn't help you a lot to know whether good is better than bad, you have to know if good or bad are sufficient for your current means of transport. I'd use grade1 etc. because this is an established scale from tracktype, and should be understandable therefor. To use these values you'll have to look them up, and this can be seen as an advantage: unlike good or bad (which do have precise meaning according to the wiki, but are often used by the expectation the user has of their meaning) it will improve consistency (hopefully). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
-1, I like the idea of OSM maps being consistent on a worldwide basis. I would support the idea of a regional style iff it turns out to be practicable. One, isolated example. One of the reasons i was given for the inability to render unsealed roads was that the preferred style, dashed infill, was already used for tunnels. Where i live, there are many more unsealed roads than tunnels and their distinctive rendering is far more important. On the other hand, can we afford the effort of maintaining several constantly diverging stylesheets ? I was told to be silent on the matter until I could usefully contribute myself and have bookmarked a few pages but got no further. That might be the real question. David . Shawn K. Quinn skqu...@rushpost.com wrote: On Wed, 2015-03-11 at 20:14 -0700, Bryce Nesbitt wrote: On Wed, Mar 11, 2015 at 7:21 PM, johnw jo...@mac.com wrote: In certain countries (such as the one I am in) the thick black line has a single purpose - private train lines. The zebra striped lines -carto uses are for national lines only (JR lines in Japan), and the thick black lines are for private railways (such as most of the Tokyo subway system) that run across the country. [...] -1 for thread hijacking, but +1 on the thought. There ARE regional differences in rendering preferences. -1, I like the idea of OSM maps being consistent on a worldwide basis. Roads in blue, green, red, orange, yellow, and white mean the same thing no matter what country we're in. Same with railroads for the most part. At most I would support one of the alternate styles being region-specific stylesheets, but definitely not at the expense of the style we have now that's consistent across the entire planet. -- Shawn K. Quinn skqu...@rushpost.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] Feature Proposal - Voting - Reception Desk
One personal factual example; 5 buildings with an area including parking, landscaping etc .. of about 2 square kilometers One reception desk. Yes only one. The node of reception desk is spatially within the area .. so 'connected' to the rest .. as are the car parks within the area. On 13/03/2015 11:25 AM, Andreas Goss wrote: anything that is big enough to have a reception is better represented by an area than by a node- IMHO. At the time I micromap the reception I'd likely also convert the node POI into an area So how do you now connect the reception with the area? What if you have different levels? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ 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] Current status of the key smoothness=*
I think this should be resolved with lots and lots of photos.. I think it would be a mistake to put too much emphasis on photos. In my experience, photos very rarely show the true usability of a road or track. It does really need to be looked at in context, the issues averaged out by eye. One, or even a set of snapshots just does not cut it ! And talking of issues, last time this discussion came up, from memory, we identified about 20 separate issues that might need to be considered. So lets not talk about trying to identify measurables. The smoothness tag, as described, already takes the right direction, it tries to judge the usability of the road. And, honestly, thats what people want to know ! Lets improve it with better values, sure a heap of photos if thats what people want. But clear words that describe just what sort of vehicle could traverse the road. So, questions, for better values, numerical or verbal ? Is it acceptable for a tag to have two, parallel sets of values, why not ? If we can get past there, we can then look for more descriptive sets of words David . Janko Mihelić jan...@gmail.com wrote: I think this should be resolved with lots and lots of photos, which the community then segregates into classes. Smoothness on asphalt is something entirely different than smoothness on sand, or smoothness on ground. When a mapper is in doubt, just look at 10 photos which are determined to be grade3, and then you can be sure that's the right value. Janko ___ 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] Feature Proposal - Voting - Reception Desk
On Thu, Mar 12, 2015 at 10:40 AM, Andreas Labres l...@lab.at wrote: Sorry, but amenity= is the wrong key. Should be tourism= IMHO. I voted yes for amenity... however I agree the tourism/amenity issue should be worked out and the proposal resubmitted for vote. --- I find tourism wrong, because valuable reception areas exist at conferences (say, at State of the Map), and in a variety of commercial areas having nothing to do with tourism. reception_point may be better than reception_desk. This are also closely related to concepts such as hotel checkin desk, and a staffed information kiosk or security desk. In all cases it's a place where a visitor will typically go first. We can expect over time the staffed reception desk will be replaced with a machine, in which one swipes some sort of identify card. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
I voted yes for this proposal. The same people who are leaving confused comments are likely to be confused at tagging time also. The level of opposition is indicating some sort of problem with the proposal. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I think the judgement words should be taken out of the tags.
*For hiking a horrible trail may be nicer than a smooth one. Stepping
over roots for example is not always unpleasant.*
glassy -
smooth -
rough -
bumpy -
or an measurement
1-20cm
20-30cm
30-50cm
travel:motorcycle={easy:hard:very_hard:impossible}
travel:foot={easy:hard:very_hard:impossible}
travel:wheelchair={easy:hard:very_hard:impossible}
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
Sorry, but amenity= is the wrong key. Should be tourism= IMHO. /al ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On Thu, Mar 12, 2015 at 2:56 AM, SomeoneElse li...@atownsend.org.uk wrote: The standard map has an impossible job - trying to be a nice map, providing feedmap to mappers that an esoteric thing that they've just mapped is now present on the map and trying to work for everyone around the world regardless of country or urban / rural location. It's not going to the best representation of map data for Japan for the same reason that it can't be the best representation of map data for Englandor anywhere else - it's compromised by having to work internationally. That's not the only option. Current the world gets a compromise map, with heavy UK influence. It's technically possible to divide that, at least along fairly coarse boundaries. Draw dividing lines in the South China Sea, and the tile server could use a different stylesheet for Japan, for example. The Arctic and Antartic could gain a stylesheet that shows everything, for example, as there is less of a clutter issue. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On Mar 12, 2015, at 10:40 AM, Andreas Labres wrote: Sorry, but amenity= is the wrong key. Should be tourism= IMHO. Tourism for the reception desk for visitors, most likely only business or invited individuals, at a facility of International Corp? That sounds wrong to me. Not sure if it should be amenity=, but it sure should not be tourism= Cheers! Tod ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
On Thu, Mar 12, 2015 at 11:09 AM, Tim Waters chippy2...@gmail.com wrote: In the UK, in urban areas, it is more common to see telephone wires (and poles) in residential streets than power lines, but again not many mappers have mapped them. I also think that they are not being rendered currently in the OSM style. Have a peek here to see what residential power lines might look like, if added to the database: https://www.openstreetmap.org/#map=17/37.64529/-118.97450 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On 12/03/2015 17:11, Bryce Nesbitt wrote: It's technically possible to divide that, at least along fairly coarse boundaries. (not that it's particularly relevant to the tagging list, but just in case anyone wasn't aware) that's what Mapquest already do: https://www.openstreetmap.org/#map=9/50.9714/1.3307layers=Q Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On Mar 12, 2015, at 6:56 PM, SomeoneElse li...@atownsend.org.uk wrote: The standard map has an impossible job - trying to be a nice map This is true, and thanks for linking to the resources to set up the server for a special version. However, what I would like to see implemented, I think, is not impossible. Martin mentioned that color can be mapped to a train line - why isn't it rendered? Setting the color to black for my train lines - even if that made the zebra black and dark grey - would be an easy step. Different cultures use different iconography for things - why can't a tag system for icon be set up to handle regional iconography? Japan uses a many pointed star for police - I should be able to tell OSM here is a reference to an icon to use and -carto can have an index of icons. This wouldn't solve issues like rendering of the trunk power lines, but as I've said the trunk lines are against the style sheet and should be softened anyway. Additional issues, like the rendering of multiple stop lights per intersection is fine for most countries, because roads are named. Most of Japan's roads are unnamed (almost everything below secondary), so navigation by counting lights and named signals is common, so understanding that regional change requests (that may not seem like a big deal) are sometimes crucial for map readability in an area (in this case, a single icon per intersection, with the name when labeled) I imagine each country has iconography and small issues that need to be worked out - that should be a major goal for OSM/-carto to natively support. There is support for multiple languages - why not multiple icons? There is no reason why some kind of regional flexibility can't be baked into the default -carto render. All the world mapping programs have to have this flexibility if they want popularity, why is OSM/carto different? Google Maps and Apple Maps are basically a single style sheet, but there are regional iconography differences. We should consider it a *basic requirement* of the tagging/style sheet to have similar flexibility. If I was a coder, rather than an old Mac Tech now teacher, I would love to learn the code, however I'm dependent on others in the community to create the code for such a system. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
Am 12.03.2015 um 22:11 schrieb Bryce Nesbitt bry...@obviously.com: Tagging a node with reception_desk is not the given use case. it doesn't matter if it's a node or a small area, most likely it will be smaller than the feature for which it is the reception cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On 12/03/2015 21:11, John Willis wrote: On Mar 12, 2015, at 6:56 PM, SomeoneElse li...@atownsend.org.uk wrote: The standard map has an impossible job - trying to be a nice map This is true, and thanks for linking to the resources to set up the server for a special version. However, what I would like to see implemented, I think, is not impossible. I'd therefore suggest that you do exactly that! The current OSM stylesheet didn't just magic itself into existance - someone sweated blood to get the carto style to match the look of the preceding godawful-to-maintain osm.xml stylesheet, something that people (myself included) sometimes forget. However, now that it exists it's FAR more customisable than what went before. It's much easier to now say I think X feature should be Y colour (or Z width, or whatever) and to show a screenshot of a small area with that in place. That tends to be how things in OSM happen - someone says hey, let's do it this way - here's an example of something that I've done that's not quite finished, but shows what can be done. ... If I was a coder, rather than an old Mac Tech now teacher, I would love to learn the code, however I'm dependent on others in the community to create the code for such a system. Would/did you ever say to your students you'll never be able to do that? I'd be very surprised if you did... Cheers, Andy (and apologies for the offtopic rant) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On Thu, Mar 12, 2015 at 2:29 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 12.03.2015 um 22:11 schrieb Bryce Nesbitt bry...@obviously.com: Tagging a node with reception_desk is not the given use case. it doesn't matter if it's a node or a small area, most likely it will be smaller than the feature for which it is the reception Perfect: we'll just invent a new OSM primitive, the sub node, for micromapping within a given node. -Bryce Note: :-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
I'm wondering, there seems to be potential overlap with tourism=information. From what is written on the reception desk page, it seems like the main difference is that the tag reception_desk also controls access to a site, and a reception desk which only gives information may as well be tagged tourism=information. Is that accurate? On Thu, Mar 12, 2015 at 3:05 PM, Andreas Goss andi...@t-online.de wrote: - It's not simple at all. Using amenity https://wiki.openstreetmap.org/wiki/Key:amenity=* for this makes it impossible to combine it with such POIs. Also why amenity at all? For me it looks like a I didn't find anything better, I mean amenity https://wiki.openstreetmap.org/wiki/Key:amenity=reception_desk https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk can't even stand on its owm. with which POI should this be combined _on the same object_? I mean, this is a tag for a reception desk, obviously it can be combined with other amenities by putting it inside them, but you won't have many objects that are at the same time a reception desk and don't know, toilets? An example why this is a problem would help to understand the reservation. Look at http://wiki.openstreetmap.org/wiki/Key:amenity and tell me those don't have reception desks. And you can't put them inside and amenity if it's just a node of a building like for example many doctors. By adding *=reception_desk to such a node it would be clear that someone did not just put a random node somewhere on the building, but that the doctor is actually there. Also what about receptions at big companies, factories etc. where you often also have a gate. Do you just use the tag for that? Is reception_DESK really fitting? http://bavaria-werkschutz.de/cms/files/img/header-teaser/Werkschutz.jpg __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ 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] Feature Proposal - Voting - Reception Desk
Am 12.03.2015 um 21:48 schrieb Brad Neuhauser brad.neuhau...@gmail.com: I'm wondering, there seems to be potential overlap with tourism=information yes, if the feature is tourism related there might be overlap for a subset of information=* This is not a problem as you could either tag both (different keys) or eg only tag tourism because it is more specific cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On Thu, Mar 12, 2015 at 1:05 PM, Andreas Goss andi...@t-online.de wrote: Look at http://wiki.openstreetmap.org/wiki/Key:amenity and tell me those don't have reception desks. And you can't put them inside an amenity if it's just a node of a building like for example many doctors. Tagging a node with reception_desk is not the given use case. The reception_desk proposal was about helping a person find the reception area in a larger space such as a campground or conference centre. A large space may have several information boards, a dozen doors, and but usually just one main starting place for visitors. In a hotel, this is also known as reception, and it's the place you check in to rooms and pay. At a conference like SToM, it's the place you say your name and pick up your ticket. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
(I think of the roads we drove in Kenya), so any input is welcome even if it isn't perfect. We ran into some nasty surprises during our trip because the road quality wasn't tagged at all. +1. I also widely use smoothness=* in Madagascar. Indeed, I use it to describe practicability of roads or tracks for 4 wheels motor vehicles, in somehow to answer the question: what kind of vehicle do I need to use this road? Despite using it often, I still have to check the wiki time to time to be sure about values definition. I even more dislike tracktype=gradeN that is using numerical values. Maybe, it is time to define a new key/values. We already have mtb:scale and sac_scale. For instance, practicability for cars: practicability=* practicability=no (damaged road) practicability=tractor_only practicability=fourwheeldrive_only (and not 4WD_only to avoid abbreviation) practicability=highclearance_only practicability=normal (default value) practicability=lowclearance Subjectivity still remains. One may consider a road as usable with a high clearance car because it is used by 404 taxi-brousse when another one may not want to use his Porche Cayenne SUV on it. It doesn't really describe smoothness. A road usable with normal vehicles may be driven at 100 km/h or 20 km/h, depending on smoothness. One may define some side scales like: practicability:bicycle=mountainbike_only/trekkingbike_only/citybike/all(defaut) practicability:motorcycle=* My 0,02 . Eric ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
- It's not simple at all. Using amenity https://wiki.openstreetmap.org/wiki/Key:amenity=* for this makes it impossible to combine it with such POIs. Also why amenity at all? For me it looks like a I didn't find anything better, I mean amenity https://wiki.openstreetmap.org/wiki/Key:amenity=reception_desk https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk can't even stand on its owm. with which POI should this be combined _on the same object_? I mean, this is a tag for a reception desk, obviously it can be combined with other amenities by putting it inside them, but you won't have many objects that are at the same time a reception desk and don't know, toilets? An example why this is a problem would help to understand the reservation. Look at http://wiki.openstreetmap.org/wiki/Key:amenity and tell me those don't have reception desks. And you can't put them inside and amenity if it's just a node of a building like for example many doctors. By adding *=reception_desk to such a node it would be clear that someone did not just put a random node somewhere on the building, but that the doctor is actually there. Also what about receptions at big companies, factories etc. where you often also have a gate. Do you just use the tag for that? Is reception_DESK really fitting? http://bavaria-werkschutz.de/cms/files/img/header-teaser/Werkschutz.jpg __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
Just a couple of observations.
The first is that there are not many such elements in urban areas for the
problem to become an obvious one. This will change if more mappers add
power lines and these examples become more obvious.
In the UK, in urban areas, it is more common to see telephone wires (and
poles) in residential streets than power lines, but again not many mappers
have mapped them. I also think that they are not being rendered currently
in the OSM style.
Cheers,
Tim
On 11 March 2015 at 22:20, Bryce Nesbitt bry...@obviously.com wrote:
Have a peek at: https://www.openstreetmap.org/#map=17/37.64529/-118.97450
Where individual residential power lines are rendered in a cluttered way.
What dividing line can the tagging offer here, to allow rendering to make
better choices?
Here the mapper made some attempt to call these residential lines, but not
enough
to dissuade osm-carto.
---
Separately,what do people think of this lite power tagging scheme as a
solution?
*highway*={any}
*utility_wires*={overhead,underground,none,unknown}
___
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] Rendering of individual power lines in residential areas on default osm-carto
On 12 March 2015 at 02:21, johnw jo...@mac.com wrote: I opened a ticket in which I was told it was my fault for thinking it it was a bad idea and to stop complaining or claiming persecution (which was really really weird). Just to be clear, this was not a comment by one of the maintainers of the style. The issue is still open, which simply means nobody has gotten yet to implementing this. If you want to speed things up, feel free to write a pull request. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Resubmitted proposal: mechanically removing all denotation=cluster and fixme=set_better_denotation tags worldwide
Resubmitting by request of maper Sly: The edit described at http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt was modified based on mailing list input, and sits at complete removal of the cluster value for denotation, along with a certain fixme value. The cluster value was introduced to mean non-special tree. The tag was spread by a hotly disputed and partially reverted bot, and the tag moved from there, finding its way onto a rather random assortment of trees, water towers and sea buoys. Removing just the bot added tags is not enough to fix the damage caused. No other values of denotation are at risk. No human entered fixme values will be harmed. The edit is proposed worldwide, though the impact is highly clustered. Simple typos such as *dentoation=clustar* may be handled at the same time. Named trees with denotation=cluster are likely mis-tagged now. Landmark trees marked cluster will be handled manually when noted. For example: https://www.openstreetmap.org/node/3321396264/history ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
anything that is big enough to have a reception is better represented by an area than by a node- IMHO. At the time I micromap the reception I'd likely also convert the node POI into an area So how do you now connect the reception with the area? What if you have different levels? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
Sorry, but amenity= is the wrong key. Should be tourism= IMHO. Hmm, i don't think so. While it may be sometimes, its more of amenity than tourism. Lets take an extreme case, a caravan park. Yes, the most likely role of the caravan park is tourism (but maybe not). But the reception desk is just an amenity, you book in there, pay a fee, complain. The reception desk itself has no tourism function. David . Andreas Labres l...@lab.at wrote: Sorry, but amenity= is the wrong key. Should be tourism= IMHO. /al ___ 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] Feature Proposal - Voting - Reception Desk
Am 12.03.2015 um 22:38 schrieb Bryce Nesbitt bry...@obviously.com: Perfect: we'll just invent a new OSM primitive, the sub node, for micromapping within a given node. anything that is big enough to have a reception is better represented by an area than by a node- IMHO. At the time I micromap the reception I'd likely also convert the node POI into an area cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On Wed, 2015-03-11 at 20:14 -0700, Bryce Nesbitt wrote: On Wed, Mar 11, 2015 at 7:21 PM, johnw jo...@mac.com wrote: In certain countries (such as the one I am in) the thick black line has a single purpose - private train lines. The zebra striped lines -carto uses are for national lines only (JR lines in Japan), and the thick black lines are for private railways (such as most of the Tokyo subway system) that run across the country. [...] -1 for thread hijacking, but +1 on the thought. There ARE regional differences in rendering preferences. -1, I like the idea of OSM maps being consistent on a worldwide basis. Roads in blue, green, red, orange, yellow, and white mean the same thing no matter what country we're in. Same with railroads for the most part. At most I would support one of the alternate styles being region-specific stylesheets, but definitely not at the expense of the style we have now that's consistent across the entire planet. -- Shawn K. Quinn skqu...@rushpost.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
2015-03-12 4:14 GMT+01:00 Bryce Nesbitt bry...@obviously.com: In certain countries (such as the one I am in) the thick black line has a single purpose - private train lines. The zebra striped lines -carto uses are for national lines only (JR lines in Japan), and the thick black lines are for private railways (such as most of the Tokyo subway system) that run across the country. there are tags to describe the color of railway lines typically used in maps, see here: http://wiki.openstreetmap.org/wiki/Key:colour?uselang=en-US It is not completely clear what a private railway is, many former federal railways have been privatized in the last few decades, btw. also the JR has been privatized in 1987 (meaning operating as a private company for the law), but AFAIK is still 100% state owned. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-12 10:36 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: I believe that the main problem are the value names. If these were called grade1 to grade8 many more people would likely use these values and I guess there would be much fewer objections. Is grade1 now excellent or horrible? No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
+1 On Thu, Mar 12, 2015 at 12:05 PM Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-12 2:53 GMT+01:00 Bryce Nesbitt bry...@obviously.com: The level of opposition -- regardless of the technical count -- indicates the proposal can use some improvement. I urge any person getting this level of opposition to reconsider, resolve the issues, and resubmit. If you look at the actual comments, almost none of them are useful, sometimes already answered (but still repeated by following voters). E.g. - It's not simple at all. Using amenity https://wiki.openstreetmap.org/wiki/Key:amenity=* for this makes it impossible to combine it with such POIs. Also why amenity at all? For me it looks like a I didn't find anything better, I mean amenity https://wiki.openstreetmap.org/wiki/Key:amenity=reception_desk https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk can't even stand on its owm. with which POI should this be combined _on the same object_? I mean, this is a tag for a reception desk, obviously it can be combined with other amenities by putting it inside them, but you won't have many objects that are at the same time a reception desk and don't know, toilets? An example why this is a problem would help to understand the reservation. - this comment pops up several times (as the only reason for opposition): The tag is related to tourism and not to amenity. but it was already answered: this is nothing particular to tourism, it can appear in all kinds of companies, administration contexts etc. - vague, half-baked is not a critic that helps to improve or even shows potential problems - The proposal Sems to me too isolated, it should be embedded in an indoor tagging scheme. the voter wants a complete indoor tagging scheme and therefor opposes a tag that might be one of the first steps towards this? - It should not be an amenity, the definition is vague, and in most cases this should go under indoor mapping, which is quite a complex subject. I didn't know indoor mapping was a different part of the project. You can discuss the vagueness of the definition, but to me A Reception Desk provides a place where a visitor goes to gain information and or access to the facility e.g. could be in a motel, office, campsite. It has been suggested as an additional tag for a campsite .. but would be better as a general tag as reception desks occur in many other places. isn't too vague. - This tag needs more time. not helping in any way to find potential problems. No substantial critique. the only useful point of critique is this one IMHO: The reception is not necessarily a 'desk'. More than the proposal I think the reasoning for opposing the proposal would have to be improved. Cheers, Martin ___ 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] Current status of the key smoothness=*
There are two fundamental approaches to this and I believe that in this discussion the two are mixed: 1. The physical status of the road is described as well as possible and it is left to the receiver of this information to judge if he/she can use the road. This is quite complex as many parameter play a role: on gravel and rock roads smoothness is important, on sand roads how soft the sand is, for fords how deep the water is, but also the bottom structure etc. Furthermore it is season dependent: a road may be perfectly OK in the dry season and hardly passable in the rainy season 2. The tagger determines how hard it will be to use the road, irrespective of the reasons why it is hard or easy: there can be different reasons why a road is horrible. This approach requires a distinction between different types of vehicles: I have driven the Turkana route in north Kenya in a small convoy with motorcycles and 4WD cars. Some parts of the road had boulders as big as children's heads and were relatively easy for the 4WD's, but very hard for the motorcycles. However, crossing a small stream with a very steep decline/incline was relatively easy for the motorcycles and very hard for the cars. I would favour the second approach as the judgement is made by someone who was there and has seen it; I admit this is subjective. The approach does require an attribute describing the road per type of vehicle, and sometimes also per season. I share the opinion that grading in words is better than in numbers: in case of hotels 5 stars is the best, for the tracks grade 5 is the worst. So in its most extensive form you would get something like road_quality:car:rainy_seasion=very_poor. On Thu, Mar 12, 2015 at 11:36 AM Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-12 11:21 GMT+01:00 Martin Vonwald imagic@gmail.com: Is grade1 now excellent or horrible? No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. it really doesn't help you a lot to know whether good is better than bad, you have to know if good or bad are sufficient for your current means of transport. I'd use grade1 etc. because this is an established scale from tracktype, and should be understandable therefor. To use these values you'll have to look them up, and this can be seen as an advantage: unlike good or bad (which do have precise meaning according to the wiki, but are often used by the expectation the user has of their meaning) it will improve consistency (hopefully). cheers, Martin ___ 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] Current status of the key smoothness=*
I think this should be resolved with lots and lots of photos, which the community then segregates into classes. Smoothness on asphalt is something entirely different than smoothness on sand, or smoothness on ground. When a mapper is in doubt, just look at 10 photos which are determined to be grade3, and then you can be sure that's the right value. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-12 12:29 GMT+01:00 Janko Mihelić jan...@gmail.com: I think this should be resolved with lots and lots of photos, which the community then segregates into classes. Smoothness on asphalt is something entirely different than smoothness on sand, or smoothness on ground. I believe the tag smoothness doesn't fit generally for sand surfaces, but asphalt and ground could easily use the same metrics / definitions. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
2015-03-11 16:51 GMT+01:00 Malcolm Herring malcolm.herr...@btinternet.com: This is why I am of the view that survey points should be mapped on separate nodes. I agree, having an area tagged as survey point doesn't make much sense, it will be a precise point, typically marked with a metal sign similar to this: http://www.pitopia.de/pictures/standard/f/focusfinder/91/focusfinder_402591.jpg cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On Wed, Mar 11, 2015 at 7:21 PM, johnw jo...@mac.com mailto:jo...@mac.com wrote: ... which is a real detriment to the OSM/-carto render in Japan ... So create your own rendering (either on your own, or with the rest of the Japanese community). Many different ones exist already - for example if you go to http://www.openstreetmap.de/karte.html you'll see a very German style. The standard map has an impossible job - trying to be a nice map, providing feedmap to mappers that an esoteric thing that they've just mapped is now present on the map and trying to work for everyone around the world regardless of country or urban / rural location. It's not going to the best representation of map data for Japan for the same reason that it can't be the best representation of map data for Englandor anywhere else - it's compromised by having to work internationally. Depending on what you want to change, small changes to an existing map style need not be a particularly difficult job. Assuming what you want is an OSM-like tile server, the basics of setting that up are described here(1). MapBox's TileMill Crash Course is here(2). I also have some notes here(3), here(4) and here(5) - but I'm sure that there are lots of other ones - try looking at presentations from previous SOTMs. Cheers, Andy (1) https://switch2osm.org/serving-tiles/manually-building-a-tile-server-14-04/ (2) https://www.mapbox.com/tilemill/docs/crashcourse/introduction/ (3) https://wiki.openstreetmap.org/wiki/User:SomeoneElse (4) https://github.com/SomeoneElseOSM/SomeoneElse-style (5) https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Haul Channel
On 12/03/2015 7:57 PM, Steve Doerr wrote: On 12/03/2015 05:49, Warin wrote: On 11/03/2015 4:06 AM, Sam Dyck wrote: In Canada, privately licensed frequencies, not CB Humm Why call it a 'channel'? And not 'frequency? Might reduce confusion with CB radio channels? And why 'haul'? I'm actually having no success finding examples of the phrase 'haul channel' in actual use via Google. Is it short for 'long-haul channel' or something? Think it comes from the term 'haul road' . a road built to haul stuff a long to a job site. Is there a better term than 'haul' that is used to describe such roads? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] ?=maze
On Fri, Feb 27, 2015 at 8:54 AM, Richard Z. ricoz@gmail.com wrote: On Fri, Feb 27, 2015 at 10:57:28AM +1100, Warin wrote: Mapping a maze path would reduce the enjoyment of the maze .. at least for me. Even if it was a single path. spoiler_warning=yes ? I do not think that is necessary: #1 you don't have to loook at the map before going through the maze #2 GPS is not precise enough to lead you through a maze You say that, but I'm guessing you've never been to an American suburban neighborhood full of twisty little cul-de-sacs with no rational urban planning or terrain to justify such obfuscation, each more identical than the last. American mazes can be quite huge, often dozens or even hundreds of square kilometers, and I'm pretty convinced the people who live in them do so because they can't find their way out. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Temperature=
I'll summarise at the end. A clear statement of any opposition, its number on any one point and potential resolution/s or rebuttals can be made then. I'd rather get a good indication of any problems and ideas to go forward through the voting system now that it has started rather than terminate and miss even one input. On 12/03/2015 9:20 PM, Kotya Karapetyan wrote: Warin, you have a 50/50 split. Maybe it's better to try to address the issues and re-vote the proposal? We could have a good tag, but we are going towards a barely accepted one. My main concern is not even that we don't have the vast majority support, but that the proposal hasn't provided a clear answer to some open questions. Cheers, Kotya On Thu, Mar 12, 2015 at 1:57 AM, Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com wrote: Well a summary at ~ 2 weeks Total votes 15. Approvals 7. So it is close. Please vote! In another week I've evaluate the votes and proceed from there. ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org 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] Current status of the key smoothness=*
No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. But Martin, its not a good or bad situation, thats the point. Some people seek out extremely challenging roads to traverse. While dead smooth is good while getting there, why bother to go there if its going to be smooth all the way ? While i am not keen on numeric values, i think they are the best possible solution. Similarly, i think we need to concentrate on the word description and treat the photos as eye candy. That part is already pretty good. David . Martin Vonwald imagic@gmail.com wrote: 2015-03-12 10:36 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: I believe that the main problem are the value names. If these were called grade1 to grade8 many more people would likely use these values and I guess there would be much fewer objections. Is grade1 now excellent or horrible? No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. ___ 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] Feature Proposal - RFC - Haul Channel
On 12/03/2015 7:57 PM, Steve Doerr wrote: On 12/03/2015 05:49, Warin wrote: On 11/03/2015 4:06 AM, Sam Dyck wrote: In Canada, privately licensed frequencies, not CB Humm Why call it a 'channel'? And not 'frequency? Might reduce confusion with CB radio channels? And why 'haul'? I'm actually having no success finding examples of the phrase 'haul channel' in actual use via Google. Is it short for 'long-haul channel' or something? Could the road be given property tags; tag haul_road=yes frequency= as per http://wiki.openstreetmap.org/wiki/Key:frequency ? or a single property tag; frequency:haul_road= then use the same value system as key:frequency? That may make the meaning clear? As duplexing is not used you don't need to stipulate it. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11 March 2015 at 23:52, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 11.03.2015 um 19:43 schrieb Markus Lindholm markus.lindh...@gmail.com: reference to the definition found in Wikipedia and that's also how I've used the tag. and if someone changes the Wikipedia page, the definition for our tag will change as well? How likely is that? Not that somebody edits the page but that the definition would change in a material way? For me a city block is a city block is a city block, but I'm probably biased because I live in a city where street signs have the name of the city block on them and some old city blocks even have Wikipedia pages. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Key:Waste Collection
not the suggested values on the page .. those are for an indication ONLY .. and should be further discussed and voted on if the proposal is approved. It is strange and confusing - how key is supposed to be used without any valid values? 2015-03-12 2:16 GMT+01:00 Warin 61sundow...@gmail.com: Time to see if there is support to have a new top level key for waste, rather than have many waste values under some other key, for example amenity=sanitary_dump_station. Overview https://wiki.openstreetmap.org/wiki/Proposed_features/waste_collection Voting https://wiki.openstreetmap.org/wiki/Proposed_features/waste_collection Note: The voting is a test of the support for a new top level tap Key:waste_collection= .. not the suggested values on the page .. those are for an indication ONLY .. and should be further discussed and voted on if the proposal is approved. Do note the present voting for another amenity= value of waste collection http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station .. if you wish to go down the path of many amenity= waste values. If you are against this proposal you should be for the other? Vote. ___ 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] Current status of the key smoothness=*
On 12/03/2015 5:39 PM, Friedrich Volkmann wrote: I think that we should explicitly include or exclude steepness in the smoothness definition. Opinions? Exclude. 'Steepness' is covered by the incline tag. There is no mention of width or surface in the smoothness tag.. nor should there be. The surface=concrete can be very smooth, rough or impassable. Still a concrete surface. Numbers? Something like? Very smooth = less than 1 mm bumps (rise/fall) in a 1 square metre area? Impassable = 0.3 m bumps in a 1 square metre area? I'm not suggesting measuring it objectively .. but subjectively it gives an idea? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Key:Waste Collection
On 12/03/2015 6:04 PM, Mateusz Konieczny wrote: not the suggested values on the page .. those are for an indication ONLY .. and should be further discussed and voted on if the proposal is approved. It is strange and confusing - how key is supposed to be used without any valid values? I've given 'suggestions' ... I cannot predict what values may be given to it, discussed, approved or simply added by mappers. The simple question is .. should there be a 'master' key for waste that is not a value of another key OR continue populating the amenity= key with 'waste' values Yes or No? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I don't say that the pictures are wrong, but it would be helpful to have perhaps six representative pictures of every level. Related question: does the tag only cover uneven ground or also for example also deep soft sand that may be difficult to cross. The tag surface=sand in itself doesn't tell much how hard is is to pass. What I am looking for is a tag that tells me how much trouble I will have passing irrespective of the importance of the road (highway=*) or the surface. An extra complexity is that the ease of passing may be season dependent (wet sand is easier to drive than dry sand), what about seasonal river crossings (seasonal=yes and ford=yes by itself don't tell the whole story). Smoothness may not be the perfect phrase, but the bottom line question is: how hard is it to pass with a 2WD, 4WD, motorcycle etc. On Wed, Mar 11, 2015 at 11:25 PM David dban...@internode.on.net wrote: I am a little unsure what the problem is with the pictures. Could you be a bit more specific please Friedrich ? It would be very hard to have a set of pictures that cover every case but, as Jan said, if we are only one level out, thats still very useful information. Honestly, while not very clear, the pictures look about right to me. David . Friedrich Volkmann b...@volki.at wrote: On 11.03.2015 17:29, Jan van Bekkum wrote: Perhaps we can extend the library of pictures in the wiki to give people a better feeling which rating means what. I agree that work on the pictures is needed. The values and their verbal descriptions are approved, and they look sound, while the bogus pictures are not approved and they do not match the definitions. We should either replace those pictures or just delete them. It seems to me that these pictures are the root of most of the controversy and the reason why these tags are ignored by most mappers and data consumers. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org 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] Current status of the key smoothness=*
On 12/03/2015 5:05 PM, Jan van Bekkum wrote: but the bottom line question is: how hard is it to pass with a 2WD, 4WD, motorcycle etc. That is a very complex question. You may add bicycle to the vehicles too. Animals and humans .. too? Soft surfaces may not support the vehicle weight (given a tyre size and number). Slippery surfaces may no provide enough traction. Rough surfaces may though a vehicle off the require path. Very rough surfaces may require lots of ground clearance. This might be combined with the above 'rough surface'? So that would be 3 measures .. they all have objective measures that give numbers.. very few people would be able to measure and map them though. And, as you say, they all change with weather and traffic. The first vehicle to cross sand has a hard crust .. the next has a softer surface.. after quite a few vehicles you get to a compacted surface... with a covering of soft sand that has fallen back in to the grove. Quantifying it is very difficult. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
On 11.03.2015 23:23, David wrote: I am a little unsure what the problem is with the pictures. Could you be a bit more specific please Friedrich ? It would be very hard to have a set of pictures that cover every case but, as Jan said, if we are only one level out, thats still very useful information. Honestly, while not very clear, the pictures look about right to me. Ok, let's see... Now that I look at it in detail, I realize that the verbal descriptions might be flawed too. When there's a category /excellect/ usable by roller blade, skate board and all below, there should also be one even better category like /perfect/ desirable for roller blade and skate board. Raugh asphalt is usable by roller blade, but fine asphalt is desireable. Similarly, fine gravel roads are usable by racing bikes, but not desirable. surface=ground may be usable by racing bikes when dry, but certainly not when wet. All of this should be pointed out in the text. BTW: Rollerblade is a trade mark. Better change that to roller skates and/or inline skates. One more text issue: the term city bike should be replaced by something like standard/normal/conventional bicycle, because a city bike is a mountain bike plus lights and reflectors, thus more robust than a trecking bike. I'll be numbering the pictures from #1 (excellent line) to #8 (impassable line). #1 is a scanned paper photo or diapositive. You see dirt and scratches, and the picture is not quite sharp. But the content of the picture seems alright. It's intermediate quality asphalt with patches. Not optimal, but easily usable for all. #2 What part of the road do they mean? The carriageway looks similar to #1. (No patches, but on the other hand there's a gully grid.) Or do they mean the bus stop? Or the footway? The footway surface seems well suited for roller skates and skateboard too, although some grass creeps in, and you need to beware the seams and poles. I suggest a photo depicting sand surface or very coarse-grained and uneven asphalt or concrete. #3 This looks like a ford or a temporarily flooded area. The photo should probably go to the highway=ford wiki page. If you leave away the water, the road is perfectly suitable for racing bikes, although the dirt indicates that it may be even more dirty at seasons, making it less usable then. I suggest a photo of a road with fine gravel or compacted gravel surface instead. #4 is a big step from #3. This is indeed unusable for racing bikes, but usable for trecking bikes and normal cars (although vegetation is near to the limit). This photo seems to match the description, but I am not shure about rikshaws. #5 This track looks like the same as #4 or even better because there's less vegetation and the surface looks harder and less prone to waterlogging. You do not need a high-clearance vehicle for that track. I suggest to move the #5 photo to #4, and to use a photo of a track with 10-20 cm deep ruts (but otherwise similar to #4) for #5. #6 This shows a track you can use with a normal car. The grass will make some noise, but it will not damage the car. You can add this photo to the smoothness=bad examples, i.e. 2 rows up. The photo for smoothness=horribly should show a very uneven and either muddy or densely vegetated road. #7 This photo looks like a clip, you don't see the whole way. Just throw that photo away. #8 This looks smooth enough for MTB. It might be to steep to drive uphill, but experienced MTBers drive this downhill no matter how steep it is. Steepness (see incline=*) is an important factor we should consider. A track may be smooth enough for a sports car, but so steep that only a tractor can make it. I think that we should explicitly include or exclude steepness in the smoothness definition. Opinions? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] place=block vs. place=city_block (was: Buildings blocks)
Has anyone ever mentioned merging place=block and place=city_block ? I have found no mention of this question. Would the merging of those two tags for an apparently identical concept be beneficial ? Of course after extensive discussion (and I won't be the one advocating either of the two - as long as one is chosen...) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
