talk-ch

talk-ch@openstreetmap.ch

4 participants
2262 discussions

Re: [talk-ch] talk-ch Digest, Vol 520, Issue 1
by abonino_ql_IMAP 24 Jul '12

24 Jul '12

Hoi zäme ja - fast genau! - Schwimmstrecken auf OSM (rote und grüne, ...mit Radarfallen)! - und dazu braucht es doch die Icons? ;-) Also ich meinte nicht nochmals eine eigene Karte; sondern nur mal erfassen und anzeigen. Und wenn die Symbole mal erfasst sind, geht es doch von alleine? Gruss, Arthur http://www.aquamap.ch/de.html www.aquamap.ch/fileadmin/user_upload/aquamap/Signaturen_Aquamap.pdf > http://taginfo.openstreetmap.ch/ > Message: 4 > Date: Tue, 24 Jul 2012 10:00:02 +0200 > From: Stefan Keller <sfkeller(a)gmail.com> > To: "Openstreetmap Schweiz/Suisse/Svizzera/Svizra" > <talk-ch(a)openstreetmap.ch> > Subject: Re: [talk-ch] neue Baustelle? > Message-ID: > <CAFcOn2-jHP+uF2THF8wE4mo9SF2kKAKBe16p9YMU1vMWFW2qew(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hoi z?me > > Ich glaube Arthur meinte den da http://taginfo.openstreetmap.ch/ > > Aber was das mit neuen Daten wie hier Schwimmb?dern zu tun hat ist mir > auch nicht klar. > > Ev. meinte er, dass die SOSM (www.sosm.ch) selber eine Web-Karte mit > OSM-Daten ?ber Schwimmb?der aufsetzen k?nnte? > > LG, Stefan > > > 2012/7/24 Raphael Studer <studerap(a)gmail.com>: >> Was ist ein T?g-Info-S?rver? >> >> Gruss >> Raphael >> _______________________________________________ >> talk-ch mailing list >> talk-ch(a)openstreetmap.ch >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

1 0

Re: [talk-ch] Wiki-page for Remapping Switzerland? (PLEASE READ!)
by tnk＠gmx.net 23 Jul '12

23 Jul '12

> Frederik Ramm now has an overview map of the objects actually deleted and modified by the bot. Great! Thanks a lot! That's pretty much the kind of visualisation that I had in mind. Now if there would only be a way to know which keys have been modified or deleted (not the exact values of course) and which relations have been broken. Has any of you succeeded in using the underlying WMS inside JOSM: http://tools.geofabrik.de/osmi/views/redactionbot/wxs? I (quickly) tried to get it to work and found the list with the various layers, I adjusted some parameters like FORMAT and TRANSPARENCY, but I kept ending up with error tiles. I'm not sure if this is by design of Frederik (to prevent tracing) or simply due to an oversight of me. For the areas I know and fixed already, it seems to be working pretty well. I just came across one deleted road that it didn't catch: This road was also missing and had to be redone (the only thing left was a set of orphaned nodes): http://www.openstreetmap.org/browse/way/172339408 But it doesn't show up on Frederik's map: http://tools.geofabrik.de/osmi/?view=redactionbot&lon=6.49619&lat=46.65630&… Again, that was just a quick check, and I can't tell if this is really a bug or just an oversight of mine, e.g. the road was deleted by someone else. Thorsten (Shernott)

1 0

Re: [talk-ch] Wiki-page for Remapping Switzerland?
by tnk＠gmx.net 23 Jul '12

23 Jul '12

On 20.07.2012 18:49, Simon Poole wrote: > Very simple: the above changesets were black listed because they were > copy & paste remapping. The nasty side effect of them is that the hid > any problematic data that they were supposed to fix. With the net result > that such areas were not remapped prior to the bot processing Switzerland. Interesting, thanks for the answer. Where does one learn about such things as black listed change sets? Now I see the problem and I can understand why you are not too happy about the actions of mdk. But let's keep in mind that mdk made his changes from the end of February to March 2012, which was so to speak in the very last minute before the change process that was expected for April. The remapping has been going on a long time before that point and should have pretty much been finished by then. Instead of focussing on mdk's unfortunate change sets, I think it would be more useful to look at the change set of OSMF Redaction Account, if for no other reason than that they reflect what truly went missing, they seem to be more compact and tend to have smaller bounding boxes. Alas, even if their bounding boxes might be smaller, they nevertheless cover a considerable area and I still abhor the idea searching all these bounding boxes for missing nodes, ways and relations. Yes, some of the deletions produce visible errors such as unconnected street segments, others leave visible gaps in a street, noticeable for those who know the area. But on a finer level such as tags or routes, the effort of finding out that something went missing at all goes quickly beyond anything that's reasonable. I understand that the exact locations of nodes and ways and the values of the keys need to be hidden away. But I wonder if it wouldn't be possible to give at least a vague (graphical) hint to the approximate location of deleted ways and relations and a list of deleted keys (without values) in the form of a set of map overlay tiles. If I remember correctly, one of the arguments why the CCBYSA wasn't working for OSM was that the OSM database would be a collection of "facts" that couldn't be protected. Now you could of course make the same kind of argument about Wikipedia (also under CCBYSA). In neither place you should "creatively" make stuff up. And just as WP uses combinations of words to describe these facts as efficiently and elegantly as possible, we in OSM use combinations of nodes, ways, relations and tags to describe facts. In both cases the "creativity" lies in the efficient and elegant use of our means to describe the underlying "facts". Which is to say that even if the exact description of the fact should or should not be protected by CCBYSA, it should still be possible to give us an approximate pointer to the underlying "fact" that was described and whose description needs to be redone. Thorsten

2 1

Re: [talk-ch] It happened again
by tnk＠gmx.net 22 Jul '12

22 Jul '12

On 22.07.2012 16:18, Stéphane Brunner wrote: > Quand au fait de ne pas mettre le nœud sur la route mais du bon côté > et toujours utile pour savoir de quel côté de la route ce trouve > l’arrêt de bus. Indeed... WARNING: I will use the forbidden fruit of Google Streetview. The following information is not intended to serve as a basis for an update of OSM data. This is where you decided to put your new bus stop: at the bay of a street lamp: http://goo.gl/maps/AZuIZ This is where the bus stop actually is (or was): at the other side of the street: http://goo.gl/maps/nAfI Oh well... > On est plut un confis pour des chemins comme ceux-ci: > http://www.openstreetmap.org/browse/way/171925486 > http://www.openstreetmap.org/browse/way/171767901 Yes and no, Stéphane. That would be rather myopic perspective of why I brought attention to this case. Our conflict is about the fact to you keep "correcting" my contributions to fit your rules and that you fail to contact me or the community before you change the data. I'm really tired of having to argue and plead with you after you've presented us with faits accomplis. And now I'm off to the forest... ;-) Thorsten (Shernott)

2 1

Re: [talk-ch] It happened again
by tnk＠gmx.net 22 Jul '12

22 Jul '12

Hello Stéphane D., j'espère que ça va si je réponds en anglais, ça me prendrait un peu trop de temps en français. To use your example with the arboretum, obviously you don't need to hang a tag at each branch of a tree as long as the tag at the trunk is visible. Hanging a visible tag somewhere would correspond to the act of rendering. But that doesn't change the fact that each branch belongs to a certain tree. This is the difference between the renderer, who needs to decide what kind of detail is appropriate for each zoom level, and the underlying data, that can contain much richer information. And if you look at a long branch at a zoom level where the trunk might be out of sight, or if you are looking at a place where branches of different trees are almost touching each other, it can be useful to know which branch belongs to which tree without going back to the trunk. Again, I think this decision should be up to the rendering algorithm. For an example of a "label overkill" (done by a questionable rendering algorithm), have a look at with how many labels the Chemin de Montéclard in Epalinges is rendered in the Bing map: http://www.bing.com/maps/?v=2&cp=rrrfzbhjnpgy&lvl=19.41&dir=348.33&sty=b&fo… But ultimately, my point is a different one: Since I have started mapping in 2010, it happened again and again that Stéphane Brunner felt compelled to "correct" and "improve" information that I had just freshly put on the map, making sure to have everything "his way", and at best notifying me after the fact if at all - not to seek an agreement, but to lecture me about "my error". Moreover, I find it slightly ironic that the very same guy, who felt last year the urge to separate the land cover to the left and right from my forest tracks in order to "represent the physical width" of the tracks, thus creating three times the amount of ways and data to maintain (see here: http://www.openstreetmap.org/user/Shernott/diary/14754), feels now the urge to delete information that he deems "abusive", i.e. not of interest to him. Thorsten On 21.07.2012 21:44, Stéphane Dewarrat wrote:> Je suis désolé pour Thorsten, je crois que c'est inutile de nommer tous > les chemins annexes (service) à une rue nommée sur le terrain. Ce serait > comme si dans un arboretum, il y aurait une plaquette sur chaque branche > d'un pommier disant que c'est un pommier... Le lecteur d'une carte > devine que c'est attaché au chemin principal et que les bâtiments le > long de ces chemins annexes ont comme adresse le chemin principal. J'ai > d'ailleur mappé quelques maisons et ajouter le tag addr:street avec le > nom du chemin. Je pense que ce serait plus utile. Donc je suis l'avis de > mon homonyme.

5 6

It happened again
by tnk＠gmx.net 21 Jul '12

21 Jul '12

After last year's incident with Stéphane Brunner (http://www.openstreetmap.org/user/Shernott/diary/14754), he seems to be back to "correct" and "improve" my contributions: http://www.openstreetmap.org/browse/changeset/12404180 Well, last year I announced that I would withdraw entirely from mapping in the larger Lausanne area, but since I live there and a lot of mapping, that none else seems to be doing, remains to be done, I slowly started mapping again. In the upper part of Epalinges were a lot of unnamed, misplaced, and also missing streets. Since the situation has remained unchanged for quite a while, I started to do something about that. In this area, the streets often don't form a simple meshed network, but more something like a tree, where it's sometimes hard to tell if a residential street has split in several branches or if it's just a collection of long driveways with lots of houses connected to each of them. I have chosen to tag what I could identify as the "main arteries" as residential streets, and the rest as driveways. Some of these driveways are rather long, and on a high zoom level (or a small GPS screen) it's possible that all you can see is the driveway. To complicate matters further, sometimes neighbouring houses are served by different driveways coming from different residential streets. Given that in the OSM Wiki the name tag is considered a useful combination for a service highway (https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice), I tagged those driveways with the corresponding street names, leaving the decision whether to render the name of the driveway or not to the rendering system. ... and along comes Mr. Brunner, who seemingly could live very well with all the unnamed, misplaced, and missing streets before, and decides without further question or discussion that my use of names on driveways is supposedly "abusive": http://www.openstreetmap.org/browse/changeset/12404180 As I said earlier, apart from Stéphane Brunner I don't see a lot of mapping activity in the larger Lausanne area, and I'm seriously starting to wonder if that might have something to with his behaviour. Now I would like to revert Stéphane Brunner's change set and get my work back. Any opinions? Thorsten (Shernott)

3 2

Re: [talk-ch] It happened again
by tnk＠gmx.net 21 Jul '12

21 Jul '12

On 21.07.2012 13:51, Stéphane Brunner wrote: > Comme tu le dit très bien cela arrive de nouveaux, tu map pour le > rendu et tu ne veux pas l'admettre ! Let me repeat this for you: "Given that in the OSM Wiki the name tag is considered a useful combination for a service highway (https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice), I tagged those driveways with the corresponding street names, leaving the decision whether to render the name of the driveway or not to the rendering system." I don't think that providing a correct and quite possibly useful information, while leaving the decision whether and how to render it to each renderer, can be called "tagging for the renderer". You might want to do some reading on the meaning of that before you go on to delete other user's contributions: https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Thorsten (Shernott)

2 1

Re: [talk-ch] Wiki-page for Remapping Switzerland?
by tnk＠gmx.net 20 Jul '12

20 Jul '12

On 20.07.2012 09:11, Simon Poole wrote: > I strongly suspect that nearly all damage in Switzerland is in areas > covered by the following changesets: > > 11118383 11095262 11091125 11090732 11090633 11056910 11036647 11028400 > 11025356 11022410 11011188 10998500 10997164 10984354 10973750 10970220 > 10967219 10965831 10955131 10954242 10948362 10904726 10888277 10863549 > 10860867 10859921 10848589 10829940 10828702 10826646 10823523 10820187 > 10819067 10814018 10808494 10807285 10804378 10803113 10801349 10800935 > 10792329 10787459 10783409 10777387 10776862 10772261 10771749 10767600 > 10766866 10766626 10760441 10759022 10758041 > > What may make sense is to have a list in the wiki where items from the > above list can be crossed off after inspection and fixing. I'm not quite sure what you mean by that. These look to me like change sets where user mdk was remapping in order to prevent data losses. Well, actually they seem to contain a rather high number of deletions. Are there other ones that contain corresponding re-creations? And all of that happened already a while ago from end of February to March 2012. What does that have to do with the recent deletions by the OSMF Redaction Account? So meanwhile, how about a little quiz: He who finds the huge (and pretty spectacular) gap that the OSMF Redaction Account ripped up in the middle of Lausanne gets the honour of fixing it. ;-) Thorsten (Shernott)

2 1

Task mangement server fürs Remapping
by Simon Poole 20 Jul '12

20 Jul '12

Ich habe auf http://rebuild.poole.ch/ einen Task Mangement Server aufgesetzt um allfällige "Arm Chair" Mapping Aktivitäten zu koordinieren. Ihr könnt euch mit eurem normalen OSM Login einloggen. Wenn jemand selber Aufgaben/Gebiete eintragen will, bitte Mail an mein OSM Konto (SimonPoole). Da es im Augenblick keine Deutschen Gebiete drin hat wärs nicht schlecht, wenn sich ein paar Freiwillige melden würden. Simon

1 0

Wiki-page for Remapping Switzerland?
by Fred Jelk 20 Jul '12

20 Jul '12

Hello, what do you think, would it be a good idea to create a wiki-page for remapping Switzerland? There are some villages where a lot of streets, landuses and nodes are loss cause of the licence-changing. I think, it would be a good idea, to coordinate the remapping from Switzerland over the wiki, as poland it does: http://wiki.openstreetmap.org/wiki/Poland_remapping p.e. Burgdorf have lost a lot of Streets: http://keepright.ipax.at/report_map.php ... w_tmpign=1 <http://keepright.ipax.at/report_map.php?zoom=15&lat=47.0556&lon=7.62669&lay…> (some streets I had remappt some minutes ago, but I don't know all from there, so I can't tagging the restrictions, names, maxspeeds... This is the reason, I ask for a wiki-page... What do you think? I've asked this also in the forum, but I didn't get an answer: http://forum.openstreetmap.org/viewtopic.php?id=17445 , so I thinked, I would ask it also here in the ML. Greets Fred

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch