[Tagging] Precisions about tourism=chalet
Current tag page is here :
http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dchalet
My questions copied from talk page :
As a non native english speaker, I have no clues about what a chalet is
supposed to be (in french, a chalet is a type of construction found in the
mountain made of wood and does not imply anything about it's possible usage)
Could you be more specific about the differences between a
{{tag|tourism|chalet}}, an {{tag|tourism|hostel}} or a
{{tag|tourism|guest_house}} ? In a "chalet" is the owner sleeping in a
different building ? Does breakfast can be brought by owner ? Is a "chalet"
rented by the same group, by different group ? Can you rent one place only ?
one room only ? Who does the clean up of rooms ? Are bathrooms dedicated
"per groups" ? Is there a possibility of restaurant service ? is that
optionnal ?
Thanks for your answer to help me found what is the french equivalent of a
"chalet"
-
--
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context:
http://gis.19327.n5.nabble.com/Precisions-about-tourism-chalet-tp5870993.html
Sent from the Tagging mailing list archive at Nabble.com.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
Jan van Bekkum wrote It is amazing to see how few people participate in this discussion and vote compared to the number of mappers. I will only talk for myself : I'm very interested in the outcome of this specific discussion about tag proposals, and I did my best to make my way thru the 6 threads on 2 mailing lists + a wiki page for a total of around 100 messages. But that is far too much time consuming not only to read, but to answer while it was probably allready answered in another branch of mail thread number 5. A mailing list is not suited for that purpose for the time I'm ready to invest. I'd welcome a summary somewhere (a wiki page ?) after a first pass of discussion about the, says, 5 proposed changes of the proposal process that have met a few supporters. proposal 1- Voting quorum upgrade to 15 voters proposal 2- 2 thirds approval required to have the accepted sticker proposal 3- Voting period extended to 2 month proposal 4- Remove all words that make people think the wiki process is somehow an official and only way to accept tags proposal 5- give free ponies to mailing list contributors who passed the 100 emails mark in the month proposal 6- disregard any previous proposal and let every one do what they want ps: do we have a process for changing processes ? - -- sly, contact direct : sylvain /a\ letuffe o r g http://wiki.openstreetmap.org/wiki/User:Sletuffe -- View this message in context: http://gis.19327.n5.nabble.com/Accepted-or-rejected-tp5837104p5837849.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Smoothness possible values, straw poll.
David Bannon-2 wrote 1. Numeric tags, perhaps grade1 .. grade8 similar to tracktype. For information, that proposition was created a few month after the smoothness acceptation to avoid using subjective sounding words like very_bad/bad/good : http://wiki.openstreetmap.org/wiki/Proposed_features/usability But wasn't accepted as it didn't change the core subjectivity of the proposal. But I do personnaly still prefer scale numbers (it's easier to remember that 3 is lower than 4) than remembering intermediate is better than good David Bannon-2 wrote 2. Words that describe the smoothness - glassy -smooth -rough -bumpy - rutted no, because the smoothness tag isn't about smoothness of the surface David Bannon-2 wrote 3. Words that describe the (wheeled) vehicle that might use it - Any_vehicle, cispecialized_off_road_wheelsty_car_bike, 4x4_mtb, off_road_vehicle, extreme_vehicle, none. yes, but no need to re-invent the wheel, http://wiki.openstreetmap.org/wiki/Key:smoothness allready lists thin_rollers / high_clearance / specialized_off_road_wheels as alternatives - -- sly, contact direct : sylvain /a\ letuffe o r g http://wiki.openstreetmap.org/wiki/User:Sletuffe -- View this message in context: http://gis.19327.n5.nabble.com/Smoothness-possible-values-straw-poll-tp5837081p5837227.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging established, unofficial and wild campings
dieterdreist wrote Am 14.03.2015 um 05:41 schrieb John Willis lt; johnw@ gt;: and mapping them for other Trekkers would be useful only if they are not confused at all with all of the other, more substatial or easily accessed spots in a camp or along a road. +1, I believe the tag for informal camping spots should not just be a sub key added to the same tag as for a commercial or otherwise official camp site, it should be a different main tag +1 from me as well. Too much risks of confusion of too different concepts. (Please note that I just discovered on that page the existence of impromptu=yes which imho should be warned against on the wiki, and given it's rather low usage (400) after 8 years of existence, could also be marked as proposed for deprecation in favor of another tourism=x top tag - -- sly, contact direct : sylvain /a\ letuffe o r g http://wiki.openstreetmap.org/wiki/User:Sletuffe -- View this message in context: http://gis.19327.n5.nabble.com/Tagging-established-unofficial-and-wild-campings-tp5834677p5837225.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] Lifecycle concepts, REMOVED
Hi, dieterdreist wrote thank you all for your comments, user:RicoZ, the creator of that page also agreed and has changed the description. In fact, the creator of the above mentionned wiki page copy/pasted the page I originally created to document the removed: prefix here : http://wiki.openstreetmap.org/wiki/Key:removed The goal was to describe an allready in use practice about the removed: prefix which I thought defered from the destroyed: prefix which was intended for features that once were, but were destroyed, while the removed: prefix is a more generic case where some mapper discover on the ground that a real life object in fact does not exists (and that mapper does not know if that real life object once existed or not), and after removing it, is faced with another (harmchair) mapper re-adding again that feature. - -- sly, contact direct : sylvain /a\ letuffe o r g http://wiki.openstreetmap.org/wiki/User:Sletuffe -- View this message in context: http://gis.19327.n5.nabble.com/Lifecycle-concepts-REMOVED-tp5831677p5831969.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Escape_lane - Approved
On vendredi 23 novembre 2012, José Juan Sánchez del Arco wrote: Okay, as the proposed feature highway=escape has been approved, now it is time for clean_up. I have completely no idea how to do it, so... can anyone do that for me?? http://wiki.openstreetmap.org/wiki/Proposed_features/escape_lane Thank you very much :) Here we go : http://wiki.openstreetmap.org/wiki/Tag:highway%3Descape Basically, it's a copy/pasted version of the proposal page, using the template for tags. -- 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] [VOTE] stop recommending the use of place_name=* for place=* on areas
Hi, No more inputs for a while, do you want to vote for such a basic proposal ? (Many would probably have just changed the wiki, but the way of tagging it concern is hot topic, and I prefere to gather some idea before just doing it) : http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] agglomération
On mercredi 21 novembre 2012, A.Pirard.Papou wrote: Hi, Hi, OSM-talk-fr sounds like associating agglomération and speed limit. I don't think we do. A french agglomération implies some speed limits (bellow 50km/h) But speed limits doesn't imply you are in an agglomération. An agglomération is more than that, and I don't think there currently is an agreed way to tag them... However, at least in Belgium, the definition of agglomération is very strict Same here : http://fr.wikipedia.org/wiki/Agglom%C3%A9ration#France How is an agglomération tagged? I would suggest something in the place=something format + name=x And if the wiki doesn't give any clues, it might be that we just need someone writing a proposal and start discussing that matter. Is my reasoning correct that I should I make a relation containing the roads? Do you mean roads as member of a relation ? I wouldn't advise to do that, but maybe draw an area around the agglomeration, or, before that, start discussing it on the wiki. But how do I tag it so that software recognize it as an agglomération as described above??? When a new tag is created, chances are that no software will reconize it right away, but by explaining somewhere how you tagged it in a clear (and unambigous) way then everyone doing a software will know how to recognize it. Well, if I too consider just the speed limit, I see that Speed_limits http://wiki.openstreetmap.org/wiki/Speed_limits applies to roads, railways! and waterways!!! Not relations ! That's the current state of recommendation, but maybe we could start discussing it to see if that's a good idea to apply speed limits on roads inside a bounding polygon -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] agglomération
Hi, Le mercredi 21 novembre 2012 22:53:53, A.Pirard.Papou a écrit : Look at multilinestring, which I see as a swiss-knife way assembly. In my mind, such a relation is the way to assign the same tags to a collection of objects making a whole with regard to those tags. If we add recursion (nesting), which is very easy to do, that's powerful. You misunderstood the idea/goal behind the multilinestring proposal. It wasn't created to factorize tags of all members. It was used to record one real life feature made of 2 or more OSM way objects. (like a long river, a boundary between two countries all made of hundreds of ways) A key sentence has been added to avoid using it badly : Do not use it to group loose ways : Relations/Relations_are_not_Categories (like all path in a forest) Example : if the name is not the same for all those ways, then you'd better not use this relation What you are looking for is a category thing to group loose ways sharing a common property but relation weren't made for that : http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories -- sly (sylvain letuffe) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposition about the place_name tag on place areas
Hi, I'd like your opininion of the following proposal : http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name -- 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] What is and what isn't a valid type=multipolygon relation for osm ?
Hi, In response to this change on the wiki : http://wiki.openstreetmap.org/w/index.php?title=Relation%3Amultipolygonaction=historysubmitdiff=820392oldid=797879 (which I do not completely agree with to say the least) I think it should be discussed and agreed on. Perhaps with more examples of what is valid and what isn't. Reading this : http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Multipolygon_should_consist_of_polygons_rather_than_ways we can guess that it is hot topic, but allowing the wiki to change what is accepted or not every now and then isn't really something usefull I guess. What about splitting in two maybe : - what is considered valid/accepted from an OSM point of view - what is considered good practice/avoid if possible from a mapper/consumers point of view -- sly (sylvain letuffe) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
On mercredi 10 octobre 2012, Rob Nickerson wrote: * For more details see [1]** and [2]. Essentially there is a hierarchy of subcategories for** transportation modes.** [2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png* This scheme should be more wildly used. It seems to be use only in the German wiki. FYI : Here is another way to display such a tree in a more readable way I created long ago : http://wiki.openstreetmap.org/wiki/Proposed_features/Any_moving_thing_grouping_system here is another page, and another diagram : http://wiki.openstreetmap.org/wiki/Computing_access_restrictions -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Seasonnal roads
On mercredi 10 octobre 2012, Martin Koppenhoefer wrote: long ago : http://wiki.openstreetmap.org/wiki/Proposed_features/Any_moving_thing_grouping_system but it should be mentioned that this diagram (unlike the previously posted one) is not in line with the current access model in OSM. Ooops, that's true. Haven't updated my memory since then. I added a statement to make it clear on the wiki page. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Naming boundary ways - the — separation character
Q1e2 : However I don't like using some strange caracters my keyboard does'nt have like — Strange you mention that. (...) Then I noticed that municipality names I wrote were being changed without discussing them and without warning. It turned out that those changes were made by a Frenchman who was also forcing that character upon us (1). It wasn't that strange that I mentionned that (it was a test to see if I was the only one disagreeing with him) Yes, I know him too well, and we had an argument on that point (and on many others, but I won't publicly extend on it or I'll probably end using not nice words) on which he replied that I was the only one arguing against and that every one was happy with a — instead of more common characters like / - or whatever. I now know he was/is a liar. That particular issue is so small that I won't start a war to change — in whatever, but you have all my support if you wish to do so. Someone has to tell him that he cannot just change that on a global scale without consensus. (Since I also don't care about names on boundary, I won't change things, but he is kind of pissing me off... once more) ps:I suggest you should split your answers by topics because it's quitte hard to read what part repliers are interested in -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Naming boundary ways
You mean like this http://www.openstreetmap.org/browse/relation/111 When I suggested the route recursion solution (a too restrictive concept), I was replied (by some Frenchman) that it's impossible. Mmmm ? I would be interested to know who told you that. Such a solution was allready used for France boundaries, and explained on the wiki [1]. It isn't an approved solution, but a discussion was started to express pros and con of such a recursion. And a live example was set up (France). [1] http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Naming boundary ways
I had assumed it was constructed differently but maybe it isn't. ok It might, but if it does, it shouldn't as it would be an error as far as what we have documented for it is concerned. But since one french contributor has decided against all others's will and local practices to change as he see fit several times, your comment raised in my mind the idea that he might have tried it again. There's a relation in Chile where the admin=4 relation consists of all the admin=6 relations or so, this is what I meant with different concept. Spain as well is using those subarea role constructions (in addition to the other model) We spent countless hours in France evaluating the pros and cons of both methods but ultimetly coundn't decide wich was better so we sticked to what we called the boundary model (in opposition to the surfaces sum model) But that is off topic. -- 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] dispute about how to tag a type=multipolygon relation
Hi, A recent proposal (and change after that) on the wiki has been made, which roughly sums up to : relations type=multipolygon's members should only be closed ways, not sums of ways making closed rings, unless the way is too big that it would be refused by the API Full discussion is here : http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#.27outer.27_and_.27inner.27_should_be_.22closed_lines.22_.28areas.29 I think that's an important change to one of the mostly used relation type (multipolygon) which should be a little more discussed before validation. Your opinons are welcome. Is it a necessary simplification to those relation ? Is it for the sake of some badly made software ? Does supperposing ways to avoid factorising any type of area boundaries is much better, and if yes, for who ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] dispute about how to tag a type=multipolygon relation
Let me first point out that these edits don't affect the definition of the multipolygon relation per se. No relation would become invalid, so this doesn't break anything. To be honnest, by what I read of the change, it wasn't so obvious. When reading : Use multipolygons only if there is no other way to map something Don't split highways into shorter segments, to create an outer-ring for a multipolygon Does seams order like to me, maybe some sentences like : Sometimes it is better to avoid spliting short segments for ease of editing or Both spliting or superposing ways is supported to build 2 touching areas represented by multipolygons, and you can choose the one you want that fits you better whould have had my preference ;-) It is about which of the alternative mapping styles is preferable when either would work from a technical point of view. I understand that, and I think there is no one answer to all because it depends on the editor used, on the real case, on the tags we want to add to ways (if any) My opinion here is that multipolygon relations should not be used unnecessarily. So if a closed way is possible (no holes, small area), then it should be used instead of a multipolygon. I share that opinion on small area as well, although my small isn't probably your small, but whatever, I think people should be let to decide with both solutions explained on the wiki at equal, not expressing it some ways one could think it means can't or don't I do personnaly use multipolygons every now and then, but not for isolated areas, because I don't need them in that case, but whenever there is a common border of say... more than ~30 nodes between two areas (a forest and a lake, forest clearing, lake and beach) I find if more convenient to re-use the border in a multipolygon that re-drawing two ways on top of each other. Still, I use both method, even the extra simple one without multipolygon at all, which is my prefered for small and isolated areas -- 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] Special geometry cases of the type=multipolygon relation
Hi, I'd like you opinion on this : http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#special_case_of_touching_outer_.28or_inner.29_rings_on_one_or_more_points_only Is it agreed that such a tagging (see image in link): Multipolygon Illustration touching on one point.svg is a valid way of tagging a multipolygon relation according to this wiki description ? (i.e one type=multipolygon relation with touching outer or inner rings with one points only ? ) * If the answer is yes, could I add this example as beeing specifically valid so that mappers are more aware of such border cases ? -- sly (sylvain letuffe) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Voting : Isolated buildings in mountain/wild used by hikers(/...) for shelter/sleeping/eating
Hi, After the huge clean up, improve and re-wording by rudof (thanks rudolf) the 4 proposals are open for a vote at : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Alpine_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wilderness_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Basic_hut http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lean_to The grouping page is here : http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings Please use the talk page for generic comments on all 4 proposal here : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/wilderness_mountain_buildings Or use one of the 4 specific proposal pages if you want to comment on one specific tag -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC : Isolated buildings in mountain/wild used by hikers(/...) for shelter/sleeping/eating
Hi, The proposal : http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings is re-opened for comments after 2 years of clean up -- 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] Proposal for a generic : type=multilinestring
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
Re: [Tagging] Proposal for a generic : type=multilinestring
On jeudi 26 janvier 2012, LM_1 wrote: 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). Oups, looks like a copy paste error, there are no reasons to have rings for those relations and instead of relation read way for the 2nd relation, I'm changing it in the wiki. 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. Well, I'd say it's better if but since it will not always be the case, data consumers should not rely on it. A API server side re-ordering whould be cool, but that's not part of the proposal 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. Either you keep this model for the higher admin entity (country) like it is used now sometimes with type=boundary_segment, or, at your option, or your local community's, goes as deep as you want. That's also why this proposition, unlike the type=multipolygon one, expressly states that it can be used recurrently with other type=multilinestring as members How would it solve the case of river bifurcation if the river merges together (river island, the same river flows on both sides)? It will not. However, it can be used for the main line river, wich, in turn, could be member of a type=river relation. I designed type=multilinestring as a geometry model, not as a fancy ever-changing relation with roles or nodes. It can be used as being the member of other complex relation grouping several features, but building it's geometry is meant to be as stable in time as possible. How would it solve similar case of streets (lanes for different directions split for some time and later merge together)? Same, it will not. -- 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] Free Flying (Hanggliding and Paragliding) - Voting Proposal
It hasn't been changed for a while, I'm moving it to voting period (in case we have paragliders out there, but any one is welcome to find bugs and/or things we forgot ) http://wiki.openstreetmap.org/wiki/Proposed_features/free_flying -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC - Via ferrata
http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed feature : World wide place=* standardisation only based on population
(Multiple answers) First, I'm aware that full classification of every populated places is not possible world wide with one tag only, the proposition states that clearly. administrative, interest, tourism, local concerns need to be recorded with other tags. The problem I see with actual place usage is that it is not standardazided world wide and serves merly for writing a label on a map. It makes it quite hard for newcomers to guess in wich case they should use wich place, and that proposal tries to help have a first easy step to record at least a population estimation. On jeudi 27 mai 2010, Simone Saviolo wrote: -1, if it's exclusively population-based. The risk is that the US have tenths of cities and smaller countries - say, dunno, Uganda - get none. Well, this is the truth ;-) based on such a scale. I don't see any problem in uganda having no megacity, because it's what is. On jeudi 27 mai 2010, Roy Wallace wrote: I like your motivation. But maybe it's not necessary. Using population=* achieves the same goal. Yes it does, and it does much more precisely, this is the utimate solution. Unfortunetly, having access to this information is much harder when you are driving your car thru, than a rough estimate that gives you the approximate size of a hamlet (I have to admit that the upper part of the scale is kind of useless as population data is much easier to get in those cases) On vendredi 28 mai 2010, John Smith wrote: +1 I doubt you could ever standardise cities, especially not based on population alone. That proposition is not about standarisation of cities around the world, it's about standardisation of the place tag usage in the osm database. I don't see any problem if a place=city is actually a town in the local language usage, (let's add a common_denomination=town) just like in france we dont care that our villes are tagged place=town. I'm concerned about database storage and meaning of the data, and key values could just have been numbers, but it's harder to remember. On vendredi 28 mai 2010, Simone Saviolo wrote: consequence, while it is good to see the map of France showing five cities, Italy's map should instead contain a few tenths. Of course, this cannot be achieved if we only look at population - especially if we want to use a world-wide population criterion. I hope the idea is clear. Unfortunetly, I think I get it, you have invented/searched perfect Italian thresholds in order to make the map...@osm.org map look what you are used to see. Maybe you endeded to 47000 people max for a city In order that city X of 46999 isn't shown, because it's administrative role is not enough to apear at zoom 10 ? Wich, in other words is a way to say you addapted the tagging of places to the actual mapnik style sheet at osm.org. Is osmarender rendering the way you want ? maybe no... Will it survive the next map...@osm.org stylesheet update ? maybe no... I don't blame that need, of course, map...@osm.org is the perfect portal of the projet, and it needs to bring a decent map that every country is happy with, but that's tagging for the/a renderer. What I'm looking for is go thru a first step where maps won't be as perfect has we want them to look (population based representation of population) before we consider the need of other tags in order to render correctly. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposed feature : World wide place=* standardisation only based on population
Here is another try for world wide standardisation of places in order to hopefully try to create a consistent database and not a renderer work around font label positionning system http://wiki.openstreetmap.org/wiki/Proposed_features/world_wide_place_default_standardisation fake quote of the day : A geographic database records what is, a map is what we show of it By Larry Obvious -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging the multipolygon model (was landuse and military)
On vendredi 16 octobre 2009, Emilie Laffray wrote: 2009/10/16 Martin Koppenhoefer dieterdre...@gmail.com +1, I agree. Inside a landuse=residential we could than map the different surfaces. I'd suggest to use the key surface for the ground-cover, or is there a problem with it? Having a ground-cover tag would be perfect. What about every thing but boundary is ground-cover surface ? (I haven't checked the whole map features) -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging the multipolygon model (was landuse and military)
On jeudi 15 octobre 2009, Martin Koppenhoefer wrote: no, this is not the case. Multipolygon says: the inner part is NOT part of the outer polygon. I didn't say that ;-) I said : an area representing something inside another area would still be part of a multipolygon relation (I assumed people discussing this with me are familiar with the (advanced) multipolygon proposal and have assumed I was talking about an inner role in this case.) let the mappers decide. So we do agree. My point was to stop or not to stop harrassing mappers that do not include inner polygons. and/or not updating the wiki acordingly, giving the choice, mentionning that solution. We could let decide, but give clues about what's for what. -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tagging the multipolygon model (was landuse and military)
On jeudi 15 octobre 2009, Martin Koppenhoefer wrote: For the lake in the forest: do you agree that someone would say: the lake (pond) is in the forest? Like a way in the forest, which doesn't have trees growing on it, but still is in the forest. It is not excluded. That's a human language matter. I don't think it's good to stick a data model to verbs and words. Between them, there should be interpretation, understanding, and questions answering. That is to say, programs. The data model should be able to answer maximum human questions (with programs) Case of the lake in the forest, you could imagine multi-question to answer : - what surface is this forest ? Suppose I'm a wood lumber producer, I've got statitics about mean trees per square km. I'll surely want to exclude the lake's surface, as well as any road's surface going thru. - is the lake in a forest ? I suppose here I want to know if I can reach the lake by transporting my boat through grass fields. ... -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
