User talk:Sletuffe

Contents 1 Relation boundary 2 Archives 3 Free_flying 4 Merge 'other maps' 5 Bridleways on openhikingmap 6 Proposed features/wilderness mountain buildings 7 Proposed features/bothy

Relation boundary

Do not revert changes completely without even checking what you do. You only need to look at the tagwatch pages linked from the very page you reverted to see the real data usage.

Also you blame that exclave/enclave is still used. Yes, sure. The text I adapted also tells this. They are outdated and only used very seldom compared to inner/outer, so the texts states them as old.

The old form of this webpage does not reflect reality. The changes I did adapt to real database. This wiki must state what is and not what one person thinks it should have to be.

--Stoecker09:38, 30 May 2010 (UTC)

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)

--Stoecker 11:30, 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)

--Stoecker 11:49, 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_Categories sletuffe 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)

Archives

• User_talk:Sletuffe/2008_talk
• User_talk:Sletuffe/2009_talk

Free_flying

Salut Sly !

je suis également fan de parapente, et je voulais discuter de quelques modifs à ta suggestion :

Je verrais bien les déclinaisons de free_flying sous une forme identique à celle utilisée pour la plongée :

sport=free_flying
free_flying:site=takeoff/landing
free_flying:retail/shop=yes
free_flying:school=yes/paragliding/hangliding
free_flying:tandem=yes
free_flying:repair=yes
free_flying:club=yes

Cette forme permettrait à mon avis de standardiser les tags des différentes activités liées au sport (enseignement, biplace, vente, réparation, etc.) et le cas échéant de pouvoir les combiner.

Un avis là-dessus ? Djam 21:28, 22 July 2010 (UTC)

Salut Djam !

Que dirais-tu de continuer cette discussion sur la page Talk:Proposed_features/free_flying ?

Zut, je n'ai pas réfléchis que tu écrivais en français, tu arrives à lire l'anglais ? ou tu préfères en français ? sletuffe 15:09, 23 July 2010 (UTC)

Merge 'other maps'

Hi, would you agree in merging Other maps, please? --!i! 17:39, 8 August 2010 (BST)

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?
• You started a discussion about lean-tos at Talk:Proposed features/wilderness mountain buildings. Should this discussion better took place at Talk:Proposed_features/Lean_to?

--Rudolf 19:58, 5 April 2012 (BST)

I sent an email with an RFC to Proposed_features/wilderness_mountain_buildings here 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)

Proposed features/bothy

Hi Sly, there is still a page Proposed features/bothy. It claims to be part of Proposed features/wilderness_mountain_buildings. Do you want to keep this proposal? Otherwise you should delete it.--Rudolf 10:09, 16 April 2012 (BST)

I've deleted it sletuffe 14:23, 16 April 2012 (BST)