I'll be commenting in line because your text is long sletuffe 12:20, 30 May 2010 (UTC)

Your second comment on this page shows that you do not really understand the changes I did. Exclave is equal to outer, enclave equal to inner. They are semantically identical, so the old way and the new style are only a matter of syntax and this changes always in OSM when older styles are replaced by newer ones. That's why I also only marked enclave/exclave as old (not as wrong), as tools still need to support this. Only new stuff and updated stuff should use the most common form and it is positive fact, that this is equal to the multipolygon (reduces complexity).

I think I did understand the changes you made, I'm just not happy with them. I think that introducing two or more ways to tag the same think is bad, not because it might creates technical problems (wich is not true) but because it introduces doubt in mappers's behavior. And no, I don't think creating/adding/talking about one new possible combinaison reduces complexity over the allready duplicate multipolygon/boudary sletuffe 12:20, 30 May 2010 (UTC)

This is right. Maybe the current form of type=boundary is not the optimum. Frederiks type=multipolygon has same advantages, but also some disadvantages. I don't decide and I don't want to decide what is better. I only care what is. The old page of type=boundary did only reflect a small part of the real database. The larger parts now used the tagging of multipolygon. Frederiks type=multipolygon was a success, but only partly. The type tag itself has not been accepted. Important is, that the sematics are equal. --Stoecker 12:42, 30 May 2010 (UTC)

Frederiks suggestion to use multipolygon directly has not been widely accepted as well, so in Germany and Netherlands probably the type=multipolygon needs to be replaced with type=boundary as well. Due to the fact that this is exchangable syntax only, that can be done automatic. The same is true for exclave/enclave which probably will be replace by inner/outer in the future.

Frederik's suggestion is a sensible suggestion, it reduces complexity by merging practices or multipolygon stuff to every kind of multipolygon (lake,forest,... and boundaries). I think this is the way to go, and it has good and stable description, unlike the for ever moving boundary page. sletuffe 12:20, 30 May 2010 (UTC)

Regarding subarea and admin_center. Your comment says you did not understand that as well. They are optional, so when they are not used in France, then they are not used in France. Where in the OSM database do we state that everything possible MUST be used?

I know that every think is optionnal, describing every use is also a good thing, but some wiki pages have more visits than others, and some readers might think that description on the boundary page has been tested, well though and born from a consensus. But since it is not the case, it will just increase the confusion. sletuffe 12:20, 30 May 2010 (UTC)

The wiki pages have never been tested. But instead of describing what should be they have to decribe what really is. Consensus or not is mainly irrelevant. If all agree that smoething must be like described on a wiki and the database itself is completely different, then the wiki mave have consensus, but it is irrelevant nevertheless. It may be that the original wiki design ideas are better that database usage is, but well, that's life. Consensus is required to have a starting point. For this topic we are way behind that point. --Stoecker 12:42, 30 May 2010 (UTC)

I don't agree with that, or else I'm really wondering what the map features page is about. If the wiki is not a first step description for "how to tag that", then where should we put the current "recommended usage". And if there is no "recommended usage" because the community is unable to decide a consensus, should we put in the same front page all possible tagging practices ? and should we change it every now and them to reflect the new max usage ? Won't every "big" import just change the recommended guidelines every now and then ? If so, we'll just wait the end of france's admin import (wich has more admin_level 8 than all europe put together), and I'll be back to change the page again, this is a non sense.sletuffe 21:17, 30 May 2010 (UTC)

So the main change is that instead of blank/enclave/exclave now outer/inner is used (very likely due to the equalness to common multipolygon practice). And some additional stuff has become used (subarea, admin_center). Do you really think it is bad that the database now uses a form which is unified? Is your problem only, that "France" was early adopter and now the standard develops very slightly into another direction? If yes then blame on you. You should be happy instead.

No, I'm not happy, standard way of mapping are not created by permanently moving pages and "in run" changes of way to do it. Not every one is reads wiki pages before mapping something, so not every one is aware of your changes, so database got fed up with many different simultaneous way of mapping, and that is bad in many regards sletuffe 12:20, 30 May 2010 (UTC)

The current database HAS many simultaneous ways of mapping. What I did is change the description from a small percentage to the majority of usage. France, Germany and Netherlands are no longer the only ones. Inbetween many other countries imported boundaries and they created facts as well. --Stoecker 12:42, 30 May 2010 (UTC)

A short comment about the way you handle things. There are many forms to reach me, so why do you start an edit-war by reverting all my changes. It may be I'm wrong, you're wrong or there is a misunderstanding. In any of these cases it would be the best to contact me first! Is that so complicated? Describe what your problem is or why you have a different view. Doing an immediate revert is like "I'm right, everybody else is dumb". You should at least assume that I also have a head to think with and that I did have reason to do the changes I did.

I'm sorry about that, I didn't considered any one "dumb", nor do I think I'm right in any cases, but I don't modify pages explaining mapping technics without deep discussions with other wiki users. sletuffe 12:20, 30 May 2010 (UTC)

Then we'll have to agree that we disagree, if you are from germany you have nothing to do on that page, you should be using multipoygons instead and leave this page alone. Also I suggest that you read Relations/Relations_are_not_Categoriessletuffe 11:04, 30 May 2010 (UTC)

What problem do you have? Should I say if you're from France, then don't edit the english page as well. Hey, you should start to grow-up. Also what do you mean with Relations_are_not_Categories. What does this have to do with this topic? It seems you either do not try to understand the changes at all or they are not clearly enough. In the latter case they should be improved, but the way you act currently surely does not help to do so. --Stoecker 11:39, 30 May 2010 (UTC)

What I don't like is people changing pages without discussion first, I donn't think I over reacted by reverting your edits, hoping that you'll sit down and start a discussion with me and others BEFORE actually doing your change. sletuffe 12:24, 30 May 2010 (UTC)

My comment on categories is related to the "proposition" you added about adding sublevel administrative boundaries inside relation containing them, wich is not inline with GIS relationnal databases, and wich is constructing a form of categories. Sorry again if I felt rude, but I'm all for talking before changing, that's all sletuffe 12:25, 30 May 2010 (UTC)

There already have been lots of discussion and the result was a different database. I adapted the WIKI accordingly. If every change should be discussed first, then nothing will ever be done. --Stoecker 12:42, 30 May 2010 (UTC)

My comment on categories is related to the "proposition" you added about adding sublevel administrative boundaries inside relation containing them, wich is not inline with GIS relationnal databases, and wich is constructing a form of categories. Sorry again if I felt rude, but I'm all for talking before changing, that's all sletuffe 12:25, 30 May 2010 (UTC)

Again I don't care at all. I documented. The tag subarea is used. From a programmers standpoint it is obsolete, as this can be detected automatically. But I do not decide. It is used 11836 times in europe, so it is an actively used tag and thus should be documented properly. I also can see sense in its usage. --Stoecker 12:42, 30 May 2010 (UTC)

Okay, let's suppose it is good to do it this way. Then you are not applying what you said earlier, you said that the majority usage should be describe, you only backup your decision based on the number of time it was used in europe. Did you checked the number of time it WASN'T used ? At least in belgium, italy, france, and germany it wasn't. As far as I can tell, only does the spain import used this. Should we start documenting in the main page of a tag every possible used case in the world ? I'm not against describing every usage, I'm against showing it prominently. sletuffe 21:17, 30 May 2010 (UTC)

Merge 'other maps'

No problems for me, it makes sense. Better not have duplicates. sletuffe 21:02, 8 August 2010 (BST)

Bridleways on openhikingmap

Just wanted to say thank you for adding bridleways on to openhikingmap. Looks much better around where I live (on the tiles that have been updated so far). Thank you --MarkS 18:35, 7 January 2011 (UTC)

You are welcome. But it will need more time to update tiles everywhere, only those with recent changes will be updated until I clean the cache up sletuffe 18:58, 7 January 2011 (UTC)

Proposed features/wilderness mountain buildings

Hi Sly,
I got some questions.

You sent out an RFC for all four pages, right? Do you have to change the RFC-date and the status by hand? Who does the update on List of Proposed?

I sent an email with an RFC to Proposed_features/wilderness_mountain_buildingshere is the email. Yes the rfc date in the pages as to be changed by hand (yup, it's done). The list of "proposed tags" is automatically updated if you change the status of the proposal to "Proposed" (I did it). About the lean_to discussion, I think it is better to keep all on one page, because there might be comments related to the other proposal as well. But I'm ok for the idea of a vote per tag/page

I'll be sending a request for a vote in a few days (that page has been there, with already a RFC 3 years ago, so I think we should get moving)sletuffe 21:23, 5 April 2012 (BST)

Well ooops, I saw you started to split discussion on every tag's page. while I started the opposite. I'll stop for now, do as you see fit sletuffe 21:28, 5 April 2012 (BST)

There existed already a discussion on some subpages. I moved some topics to the approbiate page. I refer to Proposed_features. It says: "Please discuss each proposed feature on its own discussion page."

It says also: "At least two weeks after the RFC, ..., send out a (Request for Voting)". I think we should wait this time, because we don't know about the persons how discussed in the year 2009. And there are now also new members who should discuss. What do you think?--Rudolf 06:28, 6 April 2012 (BST)

Ok, no problems for me if we split discussions.

For the person who discussed it in 2009, I know him perfectly well... because it's me ! ;-), here was the RFC the 1st of August 2009 : [1]. But I have no problems waiting another two weeks, after 3 years, it doesn't matter that much. Don't forget to remind me and/or do it, in case I forgot ! sletuffe 09:10, 6 April 2012 (BST)

I have done some editing of the definitions for the four proposals. Please have a look at this and tell me your opinion. The definition should be one phrase, that can be used for the Map_features.
IMHO the phrase "located in the countryside" is not necessary if we use "remote buildung".--Rudolf 09:05, 18 April 2012 (BST)

Please have a look at the proposals. If you think it's okay, you can start the voting.--Rudolf 17:43, 19 April 2012 (BST)

Hi Sylvain, what do you think about the next steps, after the voting finished? It seems basic_hut and lean_to don't get approved. My suggestion is to create two new values for Key:shelter_type: lean_to and basic_hut. The value weather_shelter should be deprecated.--Rudolf 19:36, 29 April 2012 (BST)

Categories and minor edits

Thanks for the comment on my talk page which I have responded on there. I will try to always use 'minor' for category changes in future. I was unaware of the noise I was creating for others. Apologies. PeterIto 14:01, 13 June 2012 (BST)

Escape lane

Because I have seen most opposed voters for the proposed highway=escape were against the same type=* tag, I have decided to change it. This mistake is now corrected. Maybe now you are interested in changing your vote ;) --Schumi4ever 14:35, 5 November 2012 (UTC)

Glaciers tags

Hi Sly,
I've been updating the Glaciers tags proposal with the most recent developments from the discussion, and I would like to know your opinion about it. I've also added a couple of ideas concerning the last three topics of the discussion and I would like to discuss them with you.
Thanks, Ocirne

Moraine/scree/debris cover for glaciers

Hi Sly,

on the topic "debris cover on top of a glacier" I've been pondering the various options, and I've come to some conclusions about the pros and cons. I would like your opinion on it, in order to complete this hopefully last step of the glaciers tags proposal; please find the table on the proposal's talk page.

via ferrate

Why stop this proposal. For me and other user it's time to vote. Bredy 17:48 28 September 2013

This proposal isn't stopped nor abandonned and every one is welcome to use it to tag via ferrate (At least I am using it as is) ! As for the voting, if noone has come up with objections, maybe someone just could declare the proposal as "open for voting" as expressed here : "Proposal process". I'll be glad to come and vote yes. sletuffe (talk) 12:37, 29 September 2013 (UTC)

2u map's status

Hi there! I tried to view a running instance of 2u but it was not listed on http:DESPAM//layers.openstreetmap.fr/ and also the tiles are not accessible. If this instance is discontinue, could could you please remove the info about it on that page? Thank you! :-) --Aseerel4c26 (talk) 09:37, 10 May 2014 (UTC)

It is discontinued. I've remove the sentences saying it is available. sletuffe (talk) 10:00, 13 May 2014 (UTC)

Boundary overlay messed up

Poland has a multipolygon to organise the hi-res bing images. But that multipolygon includes some parts of the Poland border. As such, because some outer ways are tagged "boundary=administrative", with the additional tags also present, the entire multipolygon is treated as an admin border, that overlaps with existing borders and creates a broken view. Could you look into fixing it?

(Btw, I arrived here because your name is on that map, if you're not the right person, can you pass it on?)

Yes I'm the one handeling http:// layers.openstreetmap.fr 's layers. I've heard about this problem before, but I'd like to check if it really is the same, could you give me one relation's id ? (any polygon of those "hi-res bing multipolygons" will do) like in the form of a link : http://www.openstreetmap.org/relation/xxxsletuffe (talk) 14:16, 7 September 2014 (UTC)

links to "removed:" etc

Hi, I do not think this is a good idea at this time - I have previously removed the links. RicoZ (talk) 18:44, 30 January 2015 (UTC)

The problem is that we don't yet have templates to describe namespace keys like "removed:" and the key infobox/descriptions might easily confuse people who look just at the infobox. Or look where demolished=* gets redirected to. RicoZ (talk) 18:44, 30 January 2015 (UTC)

Since those pages have more information than the one linking, I don't agree with you that the lack of better wiki templates is a good reason to unlink them. Wiki should be iterative shouldn't it ? Linking those pages make people aware that it exists, and might help at improving content.

I would agree that if those pages where linked from pages like "current usage" or "information for begginers" it would be wise to wait until a better state is reached, but that isn't the case. sletuffe (talk) 13:49, 31 January 2015 (UTC)

Somehow we need the templates for namespaces - without them not much improvement is possible for the subpages. The current use of KeyDescription also makes keys like "demolished=yes" appear prominently in taginfo.

So I see this possibilities to move forward:

use FeatureDescription instead of KeyDescription template and move those pages out of the key namespace

I have no problems with a different wiki page's name and even no template used or fancy stuff, what I like is just a random wiki page I can link to where I can describe with more words. So Okay with your option 1) (if I understand you well), while we wait for a namespace prefixe template and a adapted name for the page, I'm ok to just remove the template that doesn't work and leave it as simple page : something in the line of this : Prefix:removed . What do you think ? sletuffe (talk) 02:26, 1 February 2015 (UTC)

Hi, I just came here because I saw the use of the wiki namespace Prefix:. I don't think they should be used before discussion, mostly because current tools that work with wiki documentation look for tags in the namespaces Key: and Tag:. Also, there can be keys that work both as a key and as a prefix (e.g. fuel=*), so a key and a prefix isn't mutually exclusive. We can already know which keys are namespace by seeing whether they are in Category:Namespaces. People seem to like to have this information in templates, and that can be done too, but I would recommend discussing it first how to do it. Cheers --Jgpacker (talk) 18:46, 4 February 2015 (UTC)

I personnaly don't care at all of the page's name. It could well be Tags starting with removed: that I'd be totally happy with it, as long as I can describe a usage somewhere sletuffe (talk) 19:00, 4 February 2015 (UTC)

I see the the current "prefix:" namespace as a workaround until there is a better possibility to organize the information. Some sort of separation was required to avoid total confusion of prefixes with key names - especially in cases where use of the key is discouraged but use of the prefix appears acceptable. In such cases the use of key namespace and KeyDescriptionTemplate would be totally misleading. When something can be both a key and prefix separate pages can exist. RicoZ (talk) 21:35, 4 February 2015 (UTC)

I disagree that it's misleading to leave it in the "Key:" namespace. People often will read the page and see how to use it. I'm not happy with the namespace "Prefix:", because namespaces should be used for things that are mutually exclusive, which is not the case for "Key:" and "Prefix:". --Jgpacker (talk) 10:32, 5 February 2015 (UTC)

Not really sure what you mean that the (wiki?)-namespaces are for things which are mutually exclusive. As of key-prefixes - sometimes they are not mutually exclusive with the same name key (like diving= and diving:) and sometimes they are practically incompatible like abandoned= or abandoned: . Regarding "People often will read the page and see how to use it." - those pages are not translated into too many languages, taginfo and doc-reading laziness do the rest so it is reasonable to assume that a substantial share of people will not read or understand the documentation of eg "abandoned=*". Even just seeing a link to abandoned=* in the search results may fool people. Why risk that? Where is "abandoned:" in the search results? When you search for "removed" you get prefix:removed in the first place. So the question is - how to do it better? RicoZ (talk) 11:58, 5 February 2015 (UTC)

For thing that are always prefixes, we could use something like Key:diet:*. --Jgpacker (talk) 12:09, 5 February 2015 (UTC)

Ok, I have already suggested something similar here. So would we rename it to "abandoned:", "abandoned:*" or perhaps something like "abandoned:tagname"? I assume it would work to have separate "key:abandoned" and "key:abandonded:" wikipages? RicoZ (talk) 12:31, 5 February 2015 (UTC)