[Talk-hr] Dopustenje za koristenje banaka i bankomata
Još jedna pobjeda. Erste banka je odgovorila zahvaljujemo Vam na javljanju i ispričavamo se zbog dužeg čekanja na odgovor. Podržavamo Vaš projekt OpenStreetMap te vam dostavljamo tražene podatke o našim bankomatima i poslovnicama u xml. formatu. Molimo Vas da nas kvartalno kontaktirate na adresu Službe elektroničkog bankarstva tako da Vam možemo dostavljati ažurne podatke o bankomatima i poslovnicama Erste banke. Skinuo sam xml i kopirao ga https://dl.dropbox.com/u/3220458/dopusteno/atm_hr-erste.xml https://dl.dropbox.com/u/3220458/dopusteno/poslovnice_hr-erste.xml Ako je netko spreman pomoći samo naprijed :D ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-be] boundary names and my program
On 2012-11-29 09:23, Jan-willem De Bleser wrote : On Thu, Nov 29, 2012 at 4:51 AM, A.Pirard.Papou a.pirard.pa...@gmail.com mailto:a.pirard.pa...@gmail.com wrote: I have presented this to tagging@osm, and I think I mentioned it on talk-be@osm: The municipality (L8=level 8) border segments (ways between two municipalities) should be assembled with multilinestring to form arrondissement L7 border segments. Then, the border of the arrondissement are now a much smaller number of L7 segments. We may do the same at higher levels. The L8 borders are tagged admin_level=8, name=municipalityA — municipalityB The L7 borders are tagged admin_level=7, name=arrondissementA — arrondissementB The L6 borders are tagged admin_level=6, name=provinceA — provinceB and so on for upper levels or lower levels if they exist. And then the meaningless saying the highest admin_level wins goes away by itself, especially when applied to names for which there is no reason to apply that rule. THAT is consistent, coherent, compatible, congruous, harmonious, homogeneous, logical, solid, sound, straightforward, uniform, you name it. But... no answer that proposition. You're right, that does solve the which layer? problem. If you mentioned that earlier in the thread, I'm sorry, I must have missed it. The problem I have, however, is that by using name=A-B, you're trying to give the boundaries a name when it really is the municipalities that have a name. To use your example above, what if the L8 boundaries are all members of multipolygon relations, each with the name of a municipality, the L7 members of multipolygons named after arrondissements, and so on. If you have the border, it is a single api call to find which relations it is a member of, and then you can easily extract the name. This is pretty much what they suggest on the wiki (well, that or left: and right: tags). I assume your program could do that extra query without difficulty? Should be easy in Josm as it grabs any relation in the bounding box, but I'll have to take a look at Potlatch to see if it's possible there. Essentially, I don't want to have to agree on a name, I want to use the one that's already there. When I started to map Belgian boundaries, I looked for instructions on the Belgian pages and I found none. So, I looked at what was being done, I saw that names were used on boundaries and I did the same. And now I am /*accused of *//*insisting*/ to put names on the borders when I found them that way. If I look at the result of the way it is done, I see nameA — nameB name1 name2 name3 name4 ... everywhere, sometimes being a municipality, sometimes being an arrondissement, sometimes being a province etc... without any clue for the map reader to know which is which. And Namur or Liège can be three different types. The result of my view of the Boundaries is that, instead of seeing this on the border Liège — Namur Havelange Huy Namur Dinant Clavier Liège one would see Clavier — HavelangeHuy — Dinant (arr.)Liège —Namur (prov.) beside the unavoidable pile of shit. To this, I'm answered that the pile of shit is very well the way it is. That the nec plus ultra is a renderer taking the name (but not the admin_level!) off the municipality relation without the faintest notion of what are the names to be used for distinguishing admin levels. And one will certainly not miss the occasion to roll out the refrain that I want to tag for the rendering. I, who would certainly be glad to map any community border like the Quartier des Marolles, am accused of not considering them as administrative borders because they can be used as postal addresses and of not mapping level 10 names everywhere. I just read a question of someone wanting to navigate down the boundary tree. I do it, but the answer he received is that it is not possible. It goes on.. Basically everything is free-form in OSM. There are conventions on tagging, but there is no guarantee people will stick to them. My own opinion is indeed that it's difficult and unreliable to obtain data from OSM. But, after reading for boundaries that one does it that way and the other another way and even in Belgium that they are nor doing it the way they say they must do it, I have serious doubts about existing conventions too, conventions allowing to scan the tree here and not there. The net result of this is that I'm losing my time writing messages in hope of doing something right, that I hate doing things wrong and that, in consequence I'm leaving the boundary business. I will finish as perfectly as possible, as I did before, what I have promised to do. I started my boundary work by fixing borders that were 250 m away from their position and putting Banneux that was in arr. Verviers in arr. Liège. Don't forget to fix the other ugly, huge offsets in Belgian borders.
Re: [OSM-talk-be] boundary names and my program
On Thu, Nov 29, 2012 at 1:41 PM, A.Pirard.Papou a.pirard.pa...@gmail.com wrote: When I started to map Belgian boundaries, I looked for instructions on the Belgian pages and I found none. So, I looked at what was being done, I saw that names were used on boundaries and I did the same. And now I am accused of insisting to put names on the borders when I found them that way. I haven't been accusing you of anything. I'm insisting that if we're going to make an effort to fix the borders, we should do it properly. I consider the old names to be wrong, but don't like the ones you want to use either, and you have yet to convinced me otherwise. If I look at the result of the way it is done, I see nameA — nameB name1 name2 name3 name4 ... everywhere, sometimes being a municipality, sometimes being an arrondissement, sometimes being a province etc... without any clue for the map reader to know which is which. And Namur or Liège can be three different types. The result of my view of the Boundaries is that, instead of seeing this on the border Liège — Namur Havelange Huy Namur Dinant Clavier Liège one would see Clavier — HavelangeHuy — Dinant (arr.)Liège —Namur (prov.) beside the unavoidable pile of shit. To this, I'm answered that the pile of shit is very well the way it is. That the nec plus ultra is a renderer taking the name (but not the admin_level!) off the municipality relation without the faintest notion of what are the names to be used for distinguishing admin levels. And one will certainly not miss the occasion to roll out the refrain that I want to tag for the rendering. I'm sorry, I don't understand what you're trying to say. I have said consistently that their shouldn't be a name tag on these border segments, not that they are fine as they are (because I agree that they're no good as they are). I also haven't accused you of mapping for the renderer, but rather for the mapper. And if you read the rules for boundary=admin on the wiki that I was referring to in my previous email, they also refer to putting the admin_level tag on the relation as well, rather than on the boundary way segment. If you do that with the multistring method you might have to query a tree of a few relations rather than just one, but it should still be clear what belongs where. Basically everything is free-form in OSM. There are conventions on tagging, but there is no guarantee people will stick to them. My own opinion is indeed that it's difficult and unreliable to obtain data from OSM. But, after reading for boundaries that one does it that way and the other another way and even in Belgium that they are nor doing it the way they say they must do it, I have serious doubts about existing conventions too, conventions allowing to scan the tree here and not there. I follow the wiki. If there's someone who doesn't, I try to contact them. If the wiki needs adjustment, it gets discussed. There will always be mistakes (I make them as well) as well as unclear rules, but we can only try to improve them. The net result of this is that I'm losing my time writing messages in hope of doing something right, that I hate doing things wrong and that, in consequence I'm leaving the boundary business. Sorry, but you asked for everyone's opinion on your proposal. I gave my opinion, and suggested an alternative. Feel free to accept it, debate it or disregard it because there are no OSM police. I'm not going to sit there reverting your edits because I don't agree with them, but I'm also not going to agree with you just because otherwise you'll stop contributing. You don't get my support without convincing me that you're right, and although Arrondissement A - Arrondissement B might be a better name than Country A - Country B, I still don't think it's a better name than none at all. By the way, I hope you don't think I'm angry at you, which is a well-known danger of email discussions. I do wish we didn't have to have this same discussion again, as the last time it did get heated, but don't take what I'm writing as a personal attack. Do that and you'll get defensive, and then I'll get defensive, and then nothing will be decided. - Jw ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
I feel with you, you are not the only person is disappointed in the working of OSM in Belgium. In my opinion a few people have here own rules (examples: don't use names, put this info in a note, use JOSM, etc) and neglecking hundreds of driven volunteers. In my opinion the problem is that there is no complete wiki and it seams that some people can make their own rules. Exemple : there was a majority for using hiking instead of foot (Potlach preset hiking instead of foot). Its not on the wiki and all hiking's were changed to foot's. If we continue like that i am sure we will lose a lot of people. I hope you will still continue your work on OSM and hope that one day, people will listen to arguments and that specialists will put their energy in making the wiki (after voting) instead of never ending discussions. 2012/11/29 A.Pirard.Papou a.pirard.pa...@gmail.com On 2012-11-29 09:23, Jan-willem De Bleser wrote : On Thu, Nov 29, 2012 at 4:51 AM, A.Pirard.Papou a.pirard.pa...@gmail.com wrote: I have presented this to tagging@osm, and I think I mentioned it on talk-be@osm: The municipality (L8=level 8) border segments (ways between two municipalities) should be assembled with multilinestring to form arrondissement L7 border segments. Then, the border of the arrondissement are now a much smaller number of L7 segments. We may do the same at higher levels. The L8 borders are tagged admin_level=8, name=municipalityA — municipalityB The L7 borders are tagged admin_level=7, name=arrondissementA — arrondissementB The L6 borders are tagged admin_level=6, name=provinceA — provinceB and so on for upper levels or lower levels if they exist. And then the meaningless saying the highest admin_level wins goes away by itself, especially when applied to names for which there is no reason to apply that rule. THAT is consistent, coherent, compatible, congruous, harmonious, homogeneous, logical, solid, sound, straightforward, uniform, you name it. But... no answer that proposition. You're right, that does solve the which layer? problem. If you mentioned that earlier in the thread, I'm sorry, I must have missed it. The problem I have, however, is that by using name=A-B, you're trying to give the boundaries a name when it really is the municipalities that have a name. To use your example above, what if the L8 boundaries are all members of multipolygon relations, each with the name of a municipality, the L7 members of multipolygons named after arrondissements, and so on. If you have the border, it is a single api call to find which relations it is a member of, and then you can easily extract the name. This is pretty much what they suggest on the wiki (well, that or left: and right: tags). I assume your program could do that extra query without difficulty? Should be easy in Josm as it grabs any relation in the bounding box, but I'll have to take a look at Potlatch to see if it's possible there. Essentially, I don't want to have to agree on a name, I want to use the one that's already there. When I started to map Belgian boundaries, I looked for instructions on the Belgian pages and I found none. So, I looked at what was being done, I saw that names were used on boundaries and I did the same. And now I am *accused of **insisting* to put names on the borders when I found them that way. If I look at the result of the way it is done, I see nameA — nameB name1 name2 name3 name4 ... everywhere, sometimes being a municipality, sometimes being an arrondissement, sometimes being a province etc... without any clue for the map reader to know which is which. And Namur or Liège can be three different types. The result of my view of the Boundaries is that, instead of seeing this on the border Liège — Namur Havelange Huy Namur Dinant Clavier Liège one would see Clavier — HavelangeHuy — Dinant (arr.)Liège —Namur (prov.) beside the unavoidable pile of shit. To this, I'm answered that the pile of shit is very well the way it is. That the nec plus ultra is a renderer taking the name (but not the admin_level!) off the municipality relation without the faintest notion of what are the names to be used for distinguishing admin levels. And one will certainly not miss the occasion to roll out the refrain that I want to tag for the rendering. I, who would certainly be glad to map any community border like the Quartier des Marolles, am accused of not considering them as administrative borders because they can be used as postal addresses and of not mapping level 10 names everywhere. I just read a question of someone wanting to navigate down the boundary tree. I do it, but the answer he received is that it is not possible. It goes on.. Basically everything is free-form in OSM. There are conventions on tagging, but there is no guarantee people will stick to them. My own opinion is indeed that it's difficult and unreliable to obtain data from OSM.
[OSM-talk-be] Fwd: Bericht van AXA BANK
Hoping you will pardon my being out of topic... Beste vrienden, Ik schrijf Vlaams niet goed, maar ik ben ook absoluut onbekwaam zo grappig als dit te zijn. Cobbcounty or Cops country? Thundebird users plz right-clickhierom-Report_Email_Scam on updatete voltooien http://www.playtopgunsports.com/axa.be/ other users click here. http://www.google.com/safebrowsing/report_phish/?tpl=mozillahl=en-USurl=http%3A%2F%2Fwww.playtopgunsports.com%2Faxa.be%2F metbestegroenten, André. Original Message Subject:Bericht van AXA BANK Date: Thu, 29 Nov 2012 09:39:51 -0500 From: Rojas, Margaret margaret.ro...@cobbcounty.org To: undisclosed-recipients:; *aandacht;** Erzijn geweesteen automatischebeveiligingsupdate opuw AXA Online Bank Account. ***Klikhierom de updatete voltooien** * http://www.playtopgunsports.com/axa.be/**Houd errekening mee datu 24 uurzijn binnenomdeze update te voltooien. omdat jezou kunnen verliezenacessomuw AXA online Bank Account* ** */Cobb County...Expect the Best/* *//* *www.cobbcounty.org http://www.cobbcounty.org/ * ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Accès et réutilisation des photos et plus?
Un petit update FYI: Legal text almost finised, new wbsite almost done. Let's say January 2013 for the #*UrbIS* https://twitter.com/search?q=%23UrbISsrc=hash #*opendata * https://twitter.com/search?q=%23opendatasrc=hash licence. Thanks 4 your tweet. https://twitter.com/CIRB_CIBG/status/274120674262532098 encore reporté mais bon... c'est pas si loin Brice 2012/10/14 eMerzh merz...@gmail.com Un petit update pour info : La libération de URBIS n'est pas encore là, mais : ... le CIRB souhaite boucler le dossier avant la fin de l’année 2012. Source : http://blog.cibg.irisnet.be/urbis-pour-tous-et-partout/ A bientot Brice 2012/8/26 eMerzh merz...@gmail.com Pour info, j'ai envoyé un petit mail à la région bruxelloise pour les accès à Urbis (la plateforme de carto de bruxelles) Voici, la réponse... à suivre mi septembre donc? Brice -- Forwarded message -- From: Hannecart Claude channec...@cirb.irisnet.be Date: 2012/8/26 Subject: Accès et réutilisation des photos et plus? To: merz...@gmail.com merz...@gmail.com Cc: De Coux Tony tdec...@cibg.irisnet.be Bonjour Mr Maron, ** ** votre message ci-dessous concernant la réutilisation des données cartographiques Brussel UrbIS m'a bien été transmis. ** ** En principe, la réutilisation des données UrbIS dans le cadre d'Openstreetmap devrait bientôt être possible. En effet, nous comptons remplacer le texte de licence que vous mentionnez dans votre mail par un nouveau texte conforme à la philosophie de l'Open data. Le nouveau texte a récemment été soumis pour approbation à notre ministre de tutelle. Nous espérons pouvoir le publier officiellement dans le courant du mois de septembre. ** ** Plusieurs types de licences existantes ont fait l'objet d'une analyse dont la licence ODbL utilisée par Openstreetmap et plusieurs collectivités françaises (Paris, Nantes…). Notre choix s'est finalement porté sur la licence ouverte proposée par l'organisme français Etalab qui dépend du 1er Ministre. Cet organisme a pour vocation d'apporter son soutien aux établissements publics français pour faciliter la réutilisation de leurs données. Voici le lien vers la licence ouverte française http://www.etalab.gouv.fr/pages/licence-ouverte-open-licence-5899923.html . Nous avons adapté ce texte à la législation belge. ** ** Ce texte reprend les trois conditions préalables qui limitent l'étendue des initiatives open data : **· **la protection de la vie privée **· **les droits de tiers sur les données **· **la mention de la paternité des données ** ** Pour ce qui concerne la protection de la vie privée, j'attire votre attention sur l'utilisation des photos aériennes dont la résolution d'affichage est en principe limitée sur internet. ** ** Toutes les données UrbIS seront concernées par cette licence à l'exception du parcellaire cadastral qui ne nous appartient pas et est réservé aux administrations bruxelloises en vertu d'une convention signée avec l'administration du cadastre. ** ** Ce texte devrait également être utilisé par Bruxelles Mobilité pour la mise à disposition de ses données qui ne sont pas uniquement cartographiques. ** ** Pour votre information, des opérations de mise à jour sont actuellement en cours sur base de données provenant de divers travaux aériens effectués au printemps dernier. Ce projet vise notamment à créer une série de produits 3D. ** ** N'hésitez pas à revenir vers moi si vous avez des questions complémentaires concernant UrbIS. ** ** Cordialement, Claude Hannecart ** ** ** ** **[image: Description: C:\Users\channecart\AppData\Roaming\Microsoft\Signatures\logo_cirb_inv.gif] ***CLAUDE HANNECART channec...@cirb.irisnet.be **Service head - Cartography Service** **CENTRE D'INFORMATIQUE POUR LA RÉGION BRUXELLOISE** * Avenue des Arts 21 1000 Bruxelles www.cirb.irisnet.be T +32 2 282 19 71 F +32 2 230 31 07 Helpdesk Iris Line +32 2 801 * DISCLAIMER* Les informations contenues dans ce courrier électronique (annexes incluses) sont confidentielles et réservées à l'usage exclusif des destinataires repris ci-dessus. Si vous n'êtes pas le destinataire, soyez informé par la présente que vous ne pouvez ni divulguer, ni reproduire, ni faire usage de ces informations pour vous-même ou toute tierce personne. Si vous avez reçu ce courrier électronique par erreur, vous êtes prié d'en avertir immédiatement l'expéditeur et d'effacer le message e-mail de votre ordinateur. De informatie in deze e-mail, bijlagen inbegrepen, is vertrouwelijk en is alsdusdanig voorbehouden voor exclusief gebruik door de hierboven vermelde bestemmeling(en). Indien u niet de bestemmeling bent, willen wij u erop wijzen dat u deze informatie niet mag aanwenden voor eigen gebruik noch verspreiden aan derden. Indien u deze e-mail per
Re: [OSM-talk-be] boundary names and my program
Thanks Ben for your mail. I still believe that we have to focus more on new or less expertised volunteers and stay open for new ideas. For that it seems extremely important to have an up to date wiki. I also propose a new rule tag always for the mapper ;-). I really don't understand why it's forbidden to use a name instead of a note. Every time we have here the same discussions (last time wandelnetwerken, now administrative borders). Thats very sad, I found a lot of faults and i can't correct then because the pieces have no names. 2012/11/29 Ben Laenen benlae...@gmail.com On Thursday 29 November 2012 15:58:13 Ivo De Broeck wrote: I feel with you, you are not the only person is disappointed in the working of OSM in Belgium. In my opinion a few people have here own rules (examples: don't use names, put this info in a note, use JOSM, etc) and neglecking hundreds of driven volunteers. Well, I guess I can plead guilty for some of that. It's an unfortunate effect of being in it for so many years and following up on so many issues in the community that you take some things for granted. Several strict rules have been formed in the community in all the years prior and when it's proposed to discard some of them, one is less eager to enter into a discussion rather than saying: no, that shouldn't be done. Use note, not name. That's one example of the don't tag for the mapper rule. Almost as important as the don't tag for renderer rule. I agree that I have difficulty in discussing an issue like this. It's one of those rules that are just there... This may indeed sound a lot like telling other people what to do. For me it's like someone suggesting that 1 plus 1 equals 3 instead of 2, something you can't really argue other than saying it isn't. It's hard to handle, but in this case for example I haven't done anything to enforce this rule, other than restating the rule over and over again. Several people are mapping boundaries with names, good for them, good for OSM. I may not agree to that way of tagging, but so be it. I won't get after them and change everything they've done behind their back as some kind of tagging police. Use JOSM is an example of the numerous frustrations accumulated during the past years. Having seen so many errors made just because of the way Potlatch works, this is a logical result. To be able to use JOSM, you have to get a bit more knowledgeable about mapping for OSM, so people using it automatically tend to be less error-prone. But bad things can be done within JOSM of course. I still discourage usage of Potlatch, but it has its qualities and use cases, and I'm sure we have a lot of mappers who wouldn't be with us if it weren't available. So if you want to use Potlatch, all the best to you, but please use it wisely, and never blindly add things Potlatch suggests by its interface. And don't tell something is true because Potlatch says it is. And that rule goes to every editor out there, including JOSM. In my opinion the problem is that there is no complete wiki and it seams that some people can make their own rules. The latter being the result of the former. The former being the result of the latter. Chicken and egg. People make their rules because there don't (seem to) exist any. Rules aren't written down because since everybody has their own rules, there aren't really any rules. Discussions about it then go into a my way of tagging is right, and again I plead guilty. But the controversial rules that I made are written down on the wiki in my user space to let other people know that it's my rules. Case in point, the extended access tags. It was never discussed on this mailing list but it can be found in several other places. I actually did create my own set of tags for this. Well, then the problem arises quite soon: by making your own rules you somehow had to learn quite a bit about the subject, and I'm pretty pedantic about being able to tag everything in a way that the exact traffic rules can be generated from the tags, and I could immediately see flaws when another proposal is created. I had some tough discussions in the course of solving this issue. Long story short: I ended up supporting a proposal that I didn't have any part in creating, and am now tagging according to those rules. Relating to everything in this thread: I can indeed become quite difficult to persuade. But this is more a way of provoking good solutions. I'm not too proud to let go of my own ideas and adopt other peoples' viewpoints. If this somehow comes over as imposing my will onto others and if I sound a bit arrogant as a result of this, then I do apologize. Exemple : there was a majority for using hiking instead of foot (Potlach preset hiking instead of foot). Its not on the wiki and all hiking's were changed to foot's. If we continue like that i am sure we will lose a lot of people. For what it's worth, I
Re: [OSM-talk-be] boundary names and my program
Exemple : there was a majority for using hiking instead of foot (Potlach preset hiking instead of foot). Its not on the wiki and all hiking's were changed to foot's. If we continue like that i am sure we will lose a lot of people. For what it's worth, I did change some from hiking to foot, but that was before the discussion took place, and never systematically. If I happened to encounter one I'd change it if I had to edit it. Of course, many were tagged with foot since I mapped them myself, and the wiki page about the conventions (which I wrote myself...) always had foot as the used tag. After the discussion I haven't touched those. Before that vote I used whatever was in the route relation that I used as a template. I launched the vote in order to try and please Ivo. He seemed so adamant that hiking was the tag to use, mostly because that's the tag Potlatch defaults to and because he claimed that is what is used internationally. After the vote I was planning to change the wiki and the all the foot/hiking/walking relations going across Belgium. This would have had an influence on a few relations going across the border into France, The Netherlands and Germany, so I felt obliged to notifiy them. This gave some resistance with German mappers who didn't agree with it, as far as the short distance ones were concerned (lwn and rwn). So I changed my mind, didn't edit the wiki page and now I'm changing all the rwn routes I touch and create to route=foot. It's the right tag to use, and to the point, as most people are not using those routes to 'hike', backpack and all, but rather to make a walk on foot. In conclusion: I hope I made my viewpoint a bit clearer with this message, if I left a bad impression on some people in some discussions. I'm a bit stubborn on some issues, but I'm a very friendly person really :-) I think his bile was rather more directed to me... So don't worry, we all try to make the best of it. Unfortunately it's impossible not to step on some people's toes in the process. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
Jo, You did not have to please me. I think the hiking/foot story is a good example how OSM-Belgium is not working as it should. - New proposal - Voting - Changing the wiki - Run programs that correct things that are described in de wiki. PS: What has Germany to do with that??? Simply split ways at the border as I suggest before. 2012/11/29 Jo winfi...@gmail.com Exemple : there was a majority for using hiking instead of foot (Potlach preset hiking instead of foot). Its not on the wiki and all hiking's were changed to foot's. If we continue like that i am sure we will lose a lot of people. For what it's worth, I did change some from hiking to foot, but that was before the discussion took place, and never systematically. If I happened to encounter one I'd change it if I had to edit it. Of course, many were tagged with foot since I mapped them myself, and the wiki page about the conventions (which I wrote myself...) always had foot as the used tag. After the discussion I haven't touched those. Before that vote I used whatever was in the route relation that I used as a template. I launched the vote in order to try and please Ivo. He seemed so adamant that hiking was the tag to use, mostly because that's the tag Potlatch defaults to and because he claimed that is what is used internationally. After the vote I was planning to change the wiki and the all the foot/hiking/walking relations going across Belgium. This would have had an influence on a few relations going across the border into France, The Netherlands and Germany, so I felt obliged to notifiy them. This gave some resistance with German mappers who didn't agree with it, as far as the short distance ones were concerned (lwn and rwn). So I changed my mind, didn't edit the wiki page and now I'm changing all the rwn routes I touch and create to route=foot. It's the right tag to use, and to the point, as most people are not using those routes to 'hike', backpack and all, but rather to make a walk on foot. In conclusion: I hope I made my viewpoint a bit clearer with this message, if I left a bad impression on some people in some discussions. I'm a bit stubborn on some issues, but I'm a very friendly person really :-) I think his bile was rather more directed to me... So don't worry, we all try to make the best of it. Unfortunately it's impossible not to step on some people's toes in the process. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
2012/11/29 Ivo De Broeck ivo.debro...@gmail.com Thanks Ben for your mail. I still believe that we have to focus more on new or less expertised volunteers and stay open for new ideas. For that it seems extremely important to have an up to date wiki. I also propose a new rule tag always for the mapper ;-). I really don't understand why it's forbidden to use a name instead of a note. Every time we have here the same discussions (last time wandelnetwerken, now administrative borders). Thats very sad, I found a lot of faults and i can't correct then because the pieces have no names. Keep asking the developers of Potlatch to support what's used in the field. Over and over again. Explain to them that halfwitted solutions like trying to compute the node numbers don't cut it. Especially as that calculation fails most of the time. They'll have to give in eventually, hopefully some day soon. Of course, if they don't get to hear that their users are suffering because their users don't give them the necessary feedback, it will never be solved. I told them often enough by now. I most certainly tried. You fail to see why name can't be used instead of note, not because note makes more sense as those relations simply don't have a name, but rather because your editor of choice doesn't show that. I fail to understand how the developers of Potlatch can disregard and ignore the way we tag those route relations of which the number is nearing 12000 and rising. And why they feel the need to leave the users of their editor out in the cold. JOSM has a mapcss style to mimic Potlatch. It's even possible to make it work without its modes, so a lot more like Potlatch. If you like to give it a try, I can sit down with you for an evening to get you started with it. I assure you, there are only advantages and once you do get used to it, you'll never want to go back to Potlatch. I don't say Potlatch is bad. It's OK to make minor quick changes, but it's rather limiting for the real work. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
2012/11/29 Ivo De Broeck ivo.debro...@gmail.com Thanks Ben for your mail. I still believe that we have to focus more on new or less expertised volunteers and stay open for new ideas. For that it seems extremely important to have an up to date wiki. I also propose a new rule tag always for the mapper ;-). I really don't understand why it's forbidden to use a name instead of a note. Every time we have here the same discussions (last time wandelnetwerken, now administrative borders). Thats very sad, I found a lot of faults and i can't correct then because the pieces have no names. What Ben really means is tagging for the editor. Tagging for the mapper should always be done, just as tagging for the data user. In the same way, you should tag for the rendering, but not for one specific renderer. I mean that you should use standard tags, usable by a broad range of renderers, and not try to get it pretty for Mapnik. If it isn't grass, you shouldn't tag it as grass just because you want a green colour on the map. In the same way, you shouldn't use a tag because one editor proposes or uses it. But you should use a tag that can be understood by most mappers (in a raw format), so tag for the mapper. The name vs note discussion is indeed about one editor only supporting note tags. Regards, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] boundary names and my program
What Ben really means is tagging for the editor. Tagging for the mapper
should always be done, just as tagging for the data user.
In the same way, you should tag for the rendering, but not for one
specific renderer. I mean that you should use standard tags, usable by a
broad range of renderers, and not try to get it pretty for Mapnik. If it
isn't grass, you shouldn't tag it as grass just because you want a green
colour on the map.
In the same way, you shouldn't use a tag because one editor proposes or
uses it. But you should use a tag that can be understood by most mappers
(in a raw format), so tag for the mapper.
The name vs note discussion is indeed about one editor only supporting
note tags.
You mean one editor NOT supporting the use of note tags? JOSM supports both
name and note tags. Beyond that it allows to display names based on tags of
objects and even tags from their parents to identify them.
This is very practical to group all bicycle node routes together based on
the network they belong to. Or to show names of public transport route
relations composed of {operator} {ref} {from} {via} {to} and for bus stops
as {operator} {ref} {name} {route_ref}.
Jo
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Lost property: one forest, messages, Bing
Unsent message. On 2012-11-12 15:28, Jan-willem De Bleser wrote : On Mon, Nov 12, 2012 at 2:55 PM, A.Pirard.Papou a.pirard.pa...@gmail.com wrote: To send an e-mail to someone, I must fill a web form asking her?/him to reply so that I know his e-mail address to which I send my e-mail (not only OSM). Does anybody know when someone will invent a Web button next to the form to do that automatically, or do I miss something? OSM has an internal messaging system, which I've used to discuss with other mappers without ever knowing their email address. It gives you some privacy at a cost of having to use that form interface. If you want their email address you have to ask. You need not to use that form interface to do what you say. By e-mail address, I mean Name m-hh-hhh...@messages.openstreetmap.org with which two persons can send (real) e-mail to each other through OSM.org without knowing their real e-mail address. It's that address that a button could send without having to send someone a Web form message asking him 'reply' to know that address and start using real e-mail. Same for e-bay. It seems obvious to me. , Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-si] Keep right/left po določitvi različnih omejitev iz ene ali druge smeri
V tem primeru se Keep left pojavlja pri vožnji proti križišču z južne strani, malo pred omejitvijo (tudi sodeč po prikazani razdalji) na 60km/h, torej ob točki, kjer se omejitev razdeli glede na pas po katerem se vozi. Zato sem sumil, da je to razlog za ta napotek, lahko pa, da je napaka drugje. Ima kdo drugo razlago? Lep pozdrav Furli From: Stefan Baebler [mailto:stefan.baeb...@gmail.com] Sent: Thursday, November 29, 2012 7:25 AM To: Bojan Furlan Cc: talk-si@openstreetmap.org Subject: Re: [Talk-si] Keep right/left po določitvi različnih omejitev iz ene ali druge smeri Da vemo o čem govorimo: http://www.openstreetmap.org/?lat=46.241887 http://www.openstreetmap.org/?lat=46.241887lon=14.379816zoom=18layers=M lon=14.379816zoom=18layers=M Keep let/right nima nikakršne povezave s hitrostnimi omejitvami, ampak je zelo blaga oblika zavijanja, npr izvozi na avtocesti so narejeni tako da se postaviš na pravi pas, potem se pa ta pas počasi odcepi od osnovne ceste in mu voznik le sledi. Če je problem na izvozu iz krožišča, kjer se krožišče nadaljuje rahlo v levo, izvoz je pa v rahlo desno zna biti problem v tem, da krožišče ni označeno z junction=roundabout. Nisem preverjal dejanskih oznak in ni jasno točno kje je problem. Lp, Štefan Dne 28. nov. 2012 22:41 je Bojan Furlan bo...@furlan.biz napisal/-a: Na poti, ki jo dnevno uporabljam, sem želel naredil nekaj dopolnitev na katerih bi na realnih podatkih potem testiral, kako se obnaša navigacijski program.Poleg ostalega, sem vnesel nekaj omejitev hitrosti. Te so na nekaterih mestih, po pravilih in označbah, različne v različne smeri iste ceste. Primer je krožišče med cesto Staneta Žagarja in cesto 210 v Kranju, ob Mercatorju. V smeri proti Škofja Loki (jugu) omejitve po izhodu iz krožišča ni, ker pa je izven naselja, tam velja omejitev 90km/h. V nasprotni smeri je pred samim križiščem omejitev 40km/h, nekaj prej pa 60km/h. Po teh spremembah, mi Osmand ob prehodu iz ceste, ki ima enaki omejitvi hitrosti v obe smeri, na cesto z različnima najvišjima hitrostma, javlja, naj se držim levo ali desno. Kaj sem v tem primeru naredil narobe? Kako označiti tak prehod, da se kaj takega ne bi dogajalo? Ali pa je to napaka navigacijske aplikacije? lep pozdrav Furli ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [Talk-si] Keep right/left po določitvi različnih omejitev iz ene ali druge smeri
Stvar je malo odvisna od verzije podatkov in OsmAnd na telefonu. Sem namreč že doživel taka usmerjanja, a se zadnje čase redkeje pojavljajo. Lahko je pač napaka v programu. Na tej lokaciji sem probal in mi ni rekel keep left/right. Probal sem pa na zadnjih uradnih podatkih z dne 23.11.2012 (Ne vem če je že bilo razbito, verjetno ne). OsmAnd pa imam nightly build #87D. Mogoče manjka še lanes=2, čeprav je to po moje privzeti podatek. Lahko pa dodajaš še source:maxspeed:backward=sign in source:maxspeed:forward=SI:rural, da se ve, od kod je omejitev hitrosti in se bo lahko ob zakonskih spremembah avtomatsko popravilo brzine. Dne 29. november 2012 10:10 je Bojan Furlan bo...@furlan.biz napisal/-a: V tem primeru se Keep left pojavlja pri vožnji proti križišču z južne strani, malo pred omejitvijo (tudi sodeč po prikazani razdalji) na 60km/h, torej ob točki, kjer se omejitev razdeli glede na pas po katerem se vozi. Zato sem sumil, da je to razlog za ta napotek, lahko pa, da je napaka drugje. Ima kdo drugo razlago? ** ** Lep pozdrav Furli ** ** *From:* Stefan Baebler [mailto:stefan.baeb...@gmail.com] *Sent:* Thursday, November 29, 2012 7:25 AM *To:* Bojan Furlan *Cc:* talk-si@openstreetmap.org *Subject:* Re: [Talk-si] Keep right/left po določitvi različnih omejitev iz ene ali druge smeri ** ** Da vemo o čem govorimo: http://www.openstreetmap.org/?lat=46.241887lon=14.379816zoom=18layers=M Keep let/right nima nikakršne povezave s hitrostnimi omejitvami, ampak je zelo blaga oblika zavijanja, npr izvozi na avtocesti so narejeni tako da se postaviš na pravi pas, potem se pa ta pas počasi odcepi od osnovne ceste in mu voznik le sledi. Če je problem na izvozu iz krožišča, kjer se krožišče nadaljuje rahlo v levo, izvoz je pa v rahlo desno zna biti problem v tem, da krožišče ni označeno z junction=roundabout. Nisem preverjal dejanskih oznak in ni jasno točno kje je problem. Lp, Štefan Dne 28. nov. 2012 22:41 je Bojan Furlan bo...@furlan.biz napisal/-a:** ** Na poti, ki jo dnevno uporabljam, sem želel naredil nekaj dopolnitev na katerih bi na realnih podatkih potem testiral, kako se obnaša navigacijski program.Poleg ostalega, sem vnesel nekaj omejitev hitrosti. Te so na nekaterih mestih, po pravilih in označbah, različne v različne smeri iste ceste. Primer je krožišče med cesto Staneta Žagarja in cesto 210 v Kranju, ob Mercatorju. V smeri proti Škofja Loki (jugu) omejitve po izhodu iz krožišča ni, ker pa je izven naselja, tam velja omejitev 90km/h. V nasprotni smeri je pred samim križiščem omejitev 40km/h, nekaj prej pa 60km/h. Po teh spremembah, mi Osmand ob prehodu iz ceste, ki ima enaki omejitvi hitrosti v obe smeri, na cesto z različnima najvišjima hitrostma, javlja, naj se držim levo ali desno. Kaj sem v tem primeru naredil narobe? Kako označiti tak prehod, da se kaj takega ne bi dogajalo? Ali pa je to napaka navigacijske aplikacije? lep pozdrav Furli ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si -- Lep pozdrav, *Aleš Trtnik*, Softdata d.o.o., Preradovičeva 14, 1000 Ljubljana. tel: 01 4384164 mob: 041 698793 www: www.softdata.si email: a...@softdata.si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [OSM-talk] Recommendations for OSM mobile app?
It's probably because I somehow stumbled through the first 5 steps while discovering the possibilities of the app that I don't remember how complicated it was. Now I simply use step 6 to toggle between the views I use most often (additional GPX with the part of the walking network I already 'discovered'/Bing/Mapnik). I should figure out how I could add the hiking symbols from Lonvia someday... Still I think with all the other requirements you have, OsmAND is your best bet. Jo 2012/11/29 Steve Bennett stevag...@gmail.com Hi Jo, Yeah, OsmAnd does everything - but it's pretty complicated. Switching between offline and online maps (a pretty basic task) is really hard (and very hard to remember). To go to online maps you seem to have to: 1) Menu | Settings | Offline data (Download) 2) Expand Offline maps (vector) 3) Hold down on each offline map until 'deactivate' appears, which you choose. 4) Back out to Settings, select Online maps 5) Select Online and tile maps To then choose which one actually shows: 6) Menu | Define view | Map source... 7) Pick one Hmm...written out it doesn't sound that bad, but it took quite a lot of fumbling around to get that far. (I guess the problem is the OsmAnd authors think of vector and tile maps as completely different functions, implemented completely differently, but for the user, they're just two variations on a theme.) Steve On Wed, Nov 28, 2012 at 4:56 AM, Jo winfi...@gmail.com wrote: I wanted to tell you a few days ago that OsmAnd does all you want. Maybe write a small manual page for it, for the subset of features your users need. I didn't do it then, hoping somebody else would have a better suggestion. Polyglot 2012/11/24 Steve Bennett stevag...@gmail.com Hi all, I'm looking for a recommendations of mobile apps to recommend, for people visiting rail trails in Australia. What we* need is: Must have: 1) It has to be simple to use. There are lots of powerful apps like OSMand, Locus etc, but they're incredibly complex, with lots of features we don't need. 2) Should by default use bicycle rendering (OpenCycleMap or other), or be very easy to change to that. 3) We'll need a recommendation for both iPhone and Android. Nice to have: 4) Easy-to-use offline tile downloading/use would be a bonus. (Personally I find it pretty complex switching between offline vector rendering and online tiles in the apps I mentioned before). 5) Features like food/drink near here would be a bonus. 6) Ability to also choose Google Maps would be a bonus. 7) Ability to route along bike paths (ie, rail trails) would be nice. Once we've chosen an app, we're going to have to give instructions like download the app, push this button to change to cycle mode, push this button to download tiles etc, so the simpler the better. Thanks, Steve * we = Rail Trails Australia ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Door to door routing to buildings with multiple occupants
Hi, A mapper who is new to my area is interested in mapping disabled access at a micro level. Specifically he would like to achieve door-to-door mapping for key shops and amenities, and has made a good start by adding entrance doors to several buildings. My Question: Where should amenity=* and addr:*=* be tagged? One suggestion was to add all the detail to the entrance node, but this seems odd to me. For single occupancy buildings I suggested tagging the building as amenity=*, etc as the entrance node on the building can be easily matched with these. But what about a building with multiple occupants and entrances. For example 2 shops in one building. One option is to tag the building with building=yes and then add the amenity tags to individual nodes, but then how would door to door routing work? An alternative is to just split the building in to 2 areas (but technically its 1 building). Can we use some form of indoor mapping (e.g. room=yes, amenity=*)? Is there a better solution? All ideas welcome. Regards, Rob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] openBmap - open geodata project seems to need help
Hi all, I'm new to the mailing list here, though a long-time OSM contributor (user daveemtb). I have tried to search the archives to check this hasn't been covered recently but sorry if I missed it. There's a really interesting project at http://www.openbmap.org/ which is an open database of WiFi access points and mobile phone cell locations, IDs etc. it also makes use of OSM maps. I think it has a lot of potential to allow location based services to operate on a wide variety of devices without relying on closed geodata from Google etc (sound familiar?) Unfortunately the project seems to be struggling from a lack of help from people with the relevant technical expertise. (I contacted the people currently running the project). They are currently unable to update the maps of cells etc - there seems to be plenty in the database that isn't showing on maps yet, and I know from OSM how important rendering data is in encouraging people to contribute. Is there anyone who would be able to help these guys out? Unfortunately my web coding and Android app writing skills are absolutely non-existant or I'd chip in myself. Also, it should be possible to run the openBmap Android app in the background while recording OSM traces. Being able to contribute data to two open data projects at once seems pretty neat to me! There are other databases (such as wigle.net) out there aiming to collect similar data via crowdsourcing, only to use the data for commercial purposes, which are getting more data contributions at the moment! :( I suspect this is because the tools and output are better. And I think people have debated integrating the data into OSM. I think this is impossible because triangulation between different observations over time is needed, even if it was desirable (which I'm not sure it is). Anyway, hope this is of interest to some of you! I've found mapping wifi and cell locations to be an interesting add-on to OSM mapping. David E ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Door to door routing to buildings with multiple occupants
2012/11/29 Rob Nickerson rob.j.nicker...@gmail.com: Where should amenity=* and addr:*=* be tagged? One suggestion was to add all the detail to the entrance node, but this seems odd to me. For single occupancy buildings I suggested tagging the building as amenity=*, etc as the entrance node on the building can be easily matched with these. it is better to distinguish the building from the occupancy to avoid confusions to which entity the tags belong. There can be ambiguity e.g. in name, operator, start_date, description, wikipedia, and others. You can overcome this by splitting them into logic entities. If you say that the building is a polygon (or mp relation), we get basically these options for the shop: 1a) a node for the shop floating inside the building 1b) like 1a but part of the outline 2a) a multipolygon with the building as outer 2b) an explicit polygon overlapping with the building 3) a relation that somehow says what is in this building current consense seems to be 1a) 2a) and 2b) but some people also do 1b) 1b) has the disadvantage that the shop is inside the building but with this way of mapping it is in between outdoors and inside. a shop has always some extent, so I'd consider 1a) preliminary (it would be better to have the area to see how big it is etc.) 2a) doesn't duplicate geometry but it might break often (due to missing editor support in some editors) 2b) creates redundant geometry (overlapping way) 3) either doesn't tell you much about the extent or it will be very similar to 2a, and their might be other problems as well (e.g. also missing editor support at the moment) But what about a building with multiple occupants and entrances. For example 2 shops in one building. entrances can be mapped with the key entrance http://wiki.openstreetmap.org/wiki/Key:entrance One option is to tag the building with building=yes and then add the amenity tags to individual nodes, but then how would door to door routing work? first you'd need to make sure the doors are mapped ;-) An alternative is to just split the building in to 2 areas (but technically its 1 building). Can we use some form of indoor mapping (e.g. room=yes, amenity=*)? there is building:part (for parts of a building obviously), but also with one big building there is no problem with putting several amenity-polygons inside. If there is 1 building in the real world we should also have one object in OSM which says this is one building (i.e. a polygon or multipolygon with building=*), so bascially you would need 3 polygons to map a building with 2 POIs in it. You don't need a room-concept to map the extent of a POI, but there is one ;-) http://wiki.openstreetmap.org/wiki/Proposed_features/indoor cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Historical rail lines
Right. So if I delete the mapped rail line that doesn't exist, then remap the individual pieces of track, the remaining point and weighbridge, three overhead pylon mounts, one remaining station and one cutting that remains as historical artifacts, then everyone is cool? If it exists on the ground now, it will get mapped. Otherwise, it won't. Matt On 29/11/2012 4:46 PM, Paul Norman wrote: Actually, the slope is slippery. People have made it about old roads. There are people who have mapped old roads where they have been completely developed over and no trace remains. Mapping the traces of an old rail line isn't historical mapping. If there are currently traces there then it's mapping the present. *From:*Steve Bennett [mailto:stevag...@gmail.com] *Sent:* Wednesday, November 28, 2012 7:02 PM *To:* Matt White *Cc:* talk-au *Subject:* Re: [talk-au] Historical rail lines On Mon, Nov 26, 2012 at 7:31 PM, Matt White mattwh...@iinet.com.au mailto:mattwh...@iinet.com.au wrote: Admin boundaries are a slightly different thing - they may be intangible on the ground, but they are also current. We don't keep historical versions of admin boundaries either The problem with the historical thing is that to my mind, it is a slippery slope. There's a park near me that is currently, well, a park. But I know that it was previously a quarry, and then a rubbish tip/landfill, cos there is a sign saying so. But I certainly wouldn't tag the parks as a quarry or landfill, because it isn't. It's a park IMHO this slope is not slippery. Every time the do we map historical stuff debate comes up, it's always about train lines. That is, we're still at the top of this supposedly slippery slope, waiting to slide down. Somehow, train lines are different. They just are. To reiterate what I said before in different words: we're not mapping the 1890 route of a long forgotten train line. We're mapping the vestigial traces of a former line. And I'm absolutely not proposing to record any information about when lines opened or closed, or were re-routed or whatever. Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Historical rail lines
On Fri, Nov 30, 2012 at 7:30 AM, Matt White mattwh...@iinet.com.au wrote: Right. So if I delete the mapped rail line that doesn't exist, then remap the individual pieces of track, the remaining point and weighbridge, three overhead pylon mounts, one remaining station and one cutting that remains as historical artifacts, then everyone is cool? Not me. If it exists on the ground now, it will get mapped. Otherwise, it won't. Your line of reasoning basically goes we will only map individual historical artefacts that are each worth mapping. The reason (IMHO) that we map a train line like railway=abandoned is to connect lots of little artefacts and landscape features that individually are too trivial to map. For example, a slight embankment (normally not something we'd map), in the context of other abandoned rail features makes sense under a railway=abandoned. Similarly, a line of trees, or simply the absence of development. Frequently, the corridors in which abandoned rail lines lie are still owned by the state. Mapping the railway line makes sense, and is meaningful to many people: Our house is on Station St, just the other side of the old rail line - even if strictly speaking there is nothing on the ground. I have no objections to removing sections that have been built over. So maybe my position is: If the former rail line still plays a part as a landmark or in planning and development, it should be mapped. Similarly, I'm ok with removing former stations that have completely gone and been built over, but if their former presence is preserved in some way, they should be mapped. It seems we both agree on mapping *the present* but differ in how to interpret that. Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Historical rail lines
Matt I believe abandoned railway lines should be mapped. If it is necessary to have a current physical feature to justify mapping, then the railway formation (cut and fill earth works) generally remain, particularly if the railway reserve has been retained as a rail trail, road or linear park. From: Matt White [mailto:mattwh...@iinet.com.au] Sent: Friday, 30 November 2012 7:31 AM To: 'talk-au' Subject: Re: [talk-au] Historical rail lines Right. So if I delete the mapped rail line that doesn't exist, then remap the individual pieces of track, the remaining point and weighbridge, three overhead pylon mounts, one remaining station and one cutting that remains as historical artifacts, then everyone is cool? If it exists on the ground now, it will get mapped. Otherwise, it won't. Matt On 29/11/2012 4:46 PM, Paul Norman wrote: Actually, the slope is slippery. People have made it about old roads. There are people who have mapped old roads where they have been completely developed over and no trace remains. Mapping the traces of an old rail line isn't historical mapping. If there are currently traces there then it's mapping the present. From: Steve Bennett [mailto:stevag...@gmail.com] Sent: Wednesday, November 28, 2012 7:02 PM To: Matt White Cc: talk-au Subject: Re: [talk-au] Historical rail lines On Mon, Nov 26, 2012 at 7:31 PM, Matt White mattwh...@iinet.com.au wrote: Admin boundaries are a slightly different thing - they may be intangible on the ground, but they are also current. We don't keep historical versions of admin boundaries either The problem with the historical thing is that to my mind, it is a slippery slope. There's a park near me that is currently, well, a park. But I know that it was previously a quarry, and then a rubbish tip/landfill, cos there is a sign saying so. But I certainly wouldn't tag the parks as a quarry or landfill, because it isn't. It's a park IMHO this slope is not slippery. Every time the do we map historical stuff debate comes up, it's always about train lines. That is, we're still at the top of this supposedly slippery slope, waiting to slide down. Somehow, train lines are different. They just are. To reiterate what I said before in different words: we're not mapping the 1890 route of a long forgotten train line. We're mapping the vestigial traces of a former line. And I'm absolutely not proposing to record any information about when lines opened or closed, or were re-routed or whatever. Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Veröffentlichung über die Erkennung von Vandalismus in OpenStreetMap
Hi seit ein paar Tagen ist eine neue Veröffentlichung über die Erkennung von Vandalismus in OpenStreetMap online verfügbar. Ich habe wieder darauf geachtet das es als OpenAccess und damit kostenlos für jedermann angesehen werden kann. Die Publikation kann hier heruntergeladen werden: http://www.mdpi.com/2220-9964/1/3/315 Worum geht's? Im Paper werden unter anderem bereits bekannte erkannte Vandalismusfälle nach verschiedenen Kriterien untersucht. Von insgesamt 204 blockierten Usern bei OSM konnten 51 User als wirklicher Vandalismus erkannt werden. Diese zeigten folgende Eigenschaften (Okt. 2009 - Juli 2012): - in 33.3 % der Fälle wurden fiktive Daten erhoben - in ebenfalls 33.3% der Fälle wurden lediglich Daten modifiziert - bei 43.1% der Fälle wurden nur Daten gelöscht - 76.4% der User waren neu beim OSM Projekt - in 82.4% der Fälle wurde der Potlatch Editor beim Vandalismus verwendet. Im zweiten Teil der Veröffentlichung haben wir versucht eine prototypische Implementierung für die Erkennung von Vandalismus umzusetzen. Wie die Architecture im Detail aussieht und wie sie funktioniert kann im Paper nachgelesen werden. Unser Ansatz hat verschiedene Vor- und Nachteile, es sollte aber eigentlich alles im Paper enthalten sein. MM ist das Paper sehr gut als Grundlage für weitere Überlegungen und Umsetzungen geeignet. Von meiner Seite muss ich erwähnen, das ich nicht beabsichtigen werde eine solche Software live in Betrieb zu nehmen. Mir fehlt einfach die Zeit dies in einer akzeptablen ArtWeise umzusetzen. Die Idee von dem Paper war nicht die Entwicklung einer fertigen Software, sondern überhaupt die Wichtigkeit erste Überlegungen zu dem Thema aufzuzeigen. viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Leitschwelle, gelb, mit große rote Fahne
Steht da so ;-) Gemeint ist http://www.toool-factory.com/Leitschwelle-gelb-mit-grosse-rote-Fahne.htm Hier gibt es (mindestens) drei Lokalitäten in der Nähe, wo solche bzw. ähnliche Schwellen dauerhaft angebracht sind. Wie würdet ihr das mappen wenn a) schon zwei getrennte Richtungsfahrbahnen gemapt sind und diese Schwellen dazwischen liegen und b) nur ein einzelner way gezeichnet ist und diese Dinger das Abbiegen bzw. den Fahrbahnwechsel verhindern, mithin eine durchgezogene Linie verstärken sollen? Rainer -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage zu Küstenlinien
Guten Abend, vor einiger Zeit gab es diesen Artikel auf Spiegel-Online [1] und als fleißiger Mapper ist man natürlich neugierig ob das schon existiert. Weil es das noch nicht war habe ich es eintragen und gesehen das in dem Land es zwar gute Bing Bilder gibt aber noch sehr viel nicht eingezeichnet ist. Vorallem habe ich die Küstenlinien verfeinert aber bis heute ist da von noch nix aufgetaucht. [2] Muß man das manuell anstoßen das die Küstenlinien nur gerendert werden? Laut den gängigen Tools ist mit dem Tagging alles in Ordnung. Viele Grüße Andreas [1] http://einestages.spiegel.de/s/tb/25948/neft-dashlari-oel-insel-in-aserbaidschan.html [2] http://www.openstreetmap.org/?lat=40.4525lon=50.3462zoom=13layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leitschwelle, gelb, mit große rote Fahne
Hallo Rainer, wenn es irgendeine Bedeutung für das Routing hat dann ja. Aber es sieht mir eher wie ein Warnhinweis aus der zeigen soll das die Straße zwei getrennte Spuren hat. Daher nein, würde ich nicht eintragen weil zu unbedeutend. Grüße Andreas Am 29.11.2012 19:26, schrieb Rainer Knaepper: Steht da so ;-) Gemeint ist http://www.toool-factory.com/Leitschwelle-gelb-mit-grosse-rote-Fahne.htm Hier gibt es (mindestens) drei Lokalitäten in der Nähe, wo solche bzw. ähnliche Schwellen dauerhaft angebracht sind. Wie würdet ihr das mappen wenn a) schon zwei getrennte Richtungsfahrbahnen gemapt sind und diese Schwellen dazwischen liegen und b) nur ein einzelner way gezeichnet ist und diese Dinger das Abbiegen bzw. den Fahrbahnwechsel verhindern, mithin eine durchgezogene Linie verstärken sollen? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leitschwelle, gelb, mit große rote Fahne
Am 29. November 2012 19:26 schrieb Rainer Knaepper sm...@gmx.de: Hier gibt es (mindestens) drei Lokalitäten in der Nähe, wo solche bzw. ähnliche Schwellen dauerhaft angebracht sind. Wie würdet ihr das mappen wenn a) schon zwei getrennte Richtungsfahrbahnen gemapt sind und diese Schwellen dazwischen liegen könnte man explizit als barrier mappen, würde ich aber mit den beiden getrennten Spuren eigentlich schon ausreichend gemappt ansehen. Ist eher ein Fall für die area-relation, mit der man anzeigen kann, dass dort keine besonders widerstandsfähige Trennung angebracht ist und man ggf. im Notfall (sagen wir mal auf der Flucht bei nem Bankraub oder so ;-) ) auf die andere Fahrbahn wechseln könnte. Da wäre das dann wahlweise einfach nur ein tag in der Relation, oder explizite Geometrie als member in der Relation. und b) nur ein einzelner way gezeichnet ist da kann man jetzt streiten, ob das eine physische Trennung ist, und ggf. daraus 2 ways machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Küstenlinien
FAQ https://help.openstreetmap.org/questions/276/why-do-the-changes-i-have-made-to-coastline-not-appear-on-the-map On Thu, Nov 29, 2012 at 07:56:07PM +0100, Andreas Dommaschk wrote: Date: Thu, 29 Nov 2012 19:56:07 +0100 From: Andreas Dommaschk unnoetige_ma...@gmx.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: [Talk-de] Frage zu Küstenlinien Guten Abend, vor einiger Zeit gab es diesen Artikel auf Spiegel-Online [1] und als fleißiger Mapper ist man natürlich neugierig ob das schon existiert. Weil es das noch nicht war habe ich es eintragen und gesehen das in dem Land es zwar gute Bing Bilder gibt aber noch sehr viel nicht eingezeichnet ist. Vorallem habe ich die Küstenlinien verfeinert aber bis heute ist da von noch nix aufgetaucht. [2] Muß man das manuell anstoßen das die Küstenlinien nur gerendert werden? Laut den gängigen Tools ist mit dem Tagging alles in Ordnung. Viele Grüße Andreas [1] http://einestages.spiegel.de/s/tb/25948/neft-dashlari-oel-insel-in-aserbaidschan.html [2] http://www.openstreetmap.org/?lat=40.4525lon=50.3462zoom=13layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenbreite am Wegepunkt: width_of_way
Hallo, es klingt im ersten Moment sehr ungewöhnlich, aber an vielen Straßen gibt es eine Verziehung der Breite, weil Spuren beginnen/enden, um Linksabbieger umfahren zu können ohne formelle Spur, oder aus sonst irgend welchen Gründen. Um das zu erfassen, müsste man theoretisch alle paar Meter den Way unterbrechen und eine Breite drantaggen. Das ist vielleicht nicht unbedingt so die ganz ideale Lösung, deshalb könnte ich mir vorstellen, für Punkte, die (nur den einen) way stützen, eine Wegebreite width_of_way zu vergeben. Dann kann die Breite punktförmig erfasst werden, bis der Weg wieder eine einheitliche Breite hat, die Verziehung zu Ende ist. Es kann natürlich passieren, dass nachfolgende Mapper gerade an den Punkt irgendeinen anderen Weg heften. Damit muss man dann leben, ggf. kann man ja einen Punkt direkt daneben im way setzen und die Breite auf den übertragen. Meinungen? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leitschwelle, gelb, mit große rote Fahne
Am 29.11.2012 19:58, schrieb Andreas Dommaschk: wenn es irgendeine Bedeutung für das Routing hat dann ja. Ich mappe einklich nicht für Karten oder Routing, sondern das, was ich sehe. Und ich sehe dort eine Barriere, die beispielsweise an zwei der drei erwähnten Stellen aufgestellt wurde, um das offenbar allzuoft mißachtete Linksabbiegeverbot ein wenig moralisch zu unterstützen. An beiden Stellen haben wartende Linksabbieger mehrfach zu Auffahrunfällen geführt, die dritte Angelegenheit behindert allzu rasante Spurwechsel, ebenfalls früher ein Unfallschwerpunkt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbreite am Wegepunkt: width_of_way
Am 29.11.2012 21:57, schrieb Wolfgang Hinsch: Das ist vielleicht nicht unbedingt so die ganz ideale Lösung, deshalb könnte ich mir vorstellen, für Punkte, die (nur den einen) way stützen, eine Wegebreite width_of_way zu vergeben. Dann kann die Breite punktförmig erfasst werden, bis der Weg wieder eine einheitliche Breite hat, die Verziehung zu Ende ist. Eine Alternative wäre allerdings noch die schon früher vorgeschlagene und mancherorts experimentell verwendete Erfassung der Straßenfläche zusätzlich(!) zur Straße als Fläche mit area:highway=*. Das bildet die Situation ebenfalls ab, ist aber flexibler und vermeidet problematische Einschränkungen (z.B. dass ein Knoten mit einer Breitenangabe nur in einem Way sein darf). Außerdem dürfte eine Straßenfläche in Zeiten brauchbarer Bing-Luftbilder sogar intuitiver zu mappen sein als mehrere Messungen von Straßenbreiten an Nodes. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Küstenlinien
Andreas Dommaschk unnoetige_ma...@gmx.de wrote: Vorallem habe ich die Küstenlinien verfeinert aber bis heute ist da von noch nix aufgetaucht. [2] Letztes Küstenfile, das nicht kaputt war ist vom 23. Oktober. Siehe auch http://openstreetmapdata.com/data/land-polygons Gruss Sven -- The term any key does not refer to a particular key on the keyboard. It simply means to strike any one of the keys on your keyboard or handheld screen. (Compaq FAQ Entry 2859) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] Mappy Hour in one hour!
I think everyone involved had fun. I handed out some of my OSM swag, showed off my Columbus V-900 and Nexus 7 tablet running OSMAnd. We drank some beer, had some kebab takeout, and we generally had a fun time talking about mapping. On Thu, Nov 29, 2012 at 8:43 AM, Mikel Maron mikel_ma...@yahoo.com wrote: sorry I missed it! we had some bad news to deal with right before our flight. hope to catch up soon. * Mikel Maron * +14152835207 @mikel s:mikelmaron -- *From:* Chaitanya waichal chaitanyawaic...@gmail.com *To:* Paramvir Singh paramvi...@gmail.com; talk-in@openstreetmap.org *Sent:* Wednesday, November 28, 2012 10:11 PM *Subject:* Re: [Talk-in] Mappy Hour in one hour! how did it all go?! On Wed, Nov 28, 2012 at 5:59 PM, paramvi...@gmail.com wrote: On my way! Sent from BlackBerry® on Airtel -Original Message- From: Russ Nelson nel...@rediffmail.com Date: 28 Nov 2012 12:01:13 To: talk-in@openstreetmap.orgtalk-in@openstreetmap.org Reply-To: talk-in@openstreetmap.org Subject: [Talk-in] Mappy Hour in one hour! ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Mappy Hour in one hour!
hey, thanks to all who travelled across the city and came down .. heard some fascinating stories about the early days of the internet in india from russ, checked out OSMAnd, which is very cool and got some nice osm stickers for my newly replaced laptop casing :) Mikel, are you in town for some time? Would be great to see you again. all the best, Sanjay On Thu, Nov 29, 2012 at 10:35 PM, Russell Nelson russnel...@gmail.comwrote: I think everyone involved had fun. I handed out some of my OSM swag, showed off my Columbus V-900 and Nexus 7 tablet running OSMAnd. We drank some beer, had some kebab takeout, and we generally had a fun time talking about mapping. On Thu, Nov 29, 2012 at 8:43 AM, Mikel Maron mikel_ma...@yahoo.comwrote: sorry I missed it! we had some bad news to deal with right before our flight. hope to catch up soon. * Mikel Maron * +14152835207 @mikel s:mikelmaron -- *From:* Chaitanya waichal chaitanyawaic...@gmail.com *To:* Paramvir Singh paramvi...@gmail.com; talk-in@openstreetmap.org *Sent:* Wednesday, November 28, 2012 10:11 PM *Subject:* Re: [Talk-in] Mappy Hour in one hour! how did it all go?! On Wed, Nov 28, 2012 at 5:59 PM, paramvi...@gmail.com wrote: On my way! Sent from BlackBerry® on Airtel -Original Message- From: Russ Nelson nel...@rediffmail.com Date: 28 Nov 2012 12:01:13 To: talk-in@openstreetmap.orgtalk-in@openstreetmap.org Reply-To: talk-in@openstreetmap.org Subject: [Talk-in] Mappy Hour in one hour! ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
[Talk-it] Sito minerario
salve nella mia zona c'è un area , costiera, usata fino agli anni 60 per lo stoccaggio della pirite in enormi tramogge di laterizio, ed il successivo carico su nave attraverso teleferica (di cui ora rimane solo la struttura a terra). Ora è stata restaurata, è visitabile con guida e fa parte del Parco Nazionale delle colline Metallifere. Che tag usare? Qualcosa che ha a che fare con l'archeologia industriale? Vorrei specifiicare bene le varie caratteristiche. Ciao a tutti ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] è un problema?
Loggetto è la mappatura delle linee bus urbane della mia città. Mi sono documentato e ho prodotto la prima relation route: 2604715 Come membri vi sono le coppie stop_position - platform e le way. Visto che alcune way vengono percorse nel singolo tragitto (NON in andata e ritorno il ritorno sarà in una realtion successiva) in entrambi i sensi, rimangono delle interruzioni nel collegamenti delle way nella relazione. Se questo costituisce un problema, come si risolve? Grazie dei suggerimenti Beppe ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] è un problema?
Ciao, On Thu, 29 Nov 2012 09:48:48 +0100, Giuseppe Amici wrote: L’oggetto è la mappatura delle linee bus urbane della mia città. Benvenuto nel meraviglioso mondo delle route=bus! :D Anzitutto, la chiave è public_transport, non puBBlic_transport, quindi dovresti correggere questo errore anzitutto. Visto che alcune way vengono percorse nel singolo tragitto (NON in andata e ritorno – il ritorno sarà in una realtion successiva) in entrambi i sensi, rimangono delle interruzioni nel collegamenti delle way nella relazione. Se questo costituisce un problema, come si risolve? Semplicemente aggiungi la way due volte alla relazione. Inoltre, dovresti usare i ruoli forward e backward, per indicare in quale direzione viene percorsa. Nell'esempio da te proposto, la way in questione è: http://www.openstreetmap.org/browse/way/193381353 e viene percorsa prima in senso backward, e poi in senso forward (in pratica dipende dal verso in cui è stata disegnata la way). Inoltre, ti pregherei di eliminare tutti quei tag source con il tuo indirizzo e-mail; non è quello il suo scopo (l'autore di un oggetto viene memorizzato altrove). Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] è un problema?
On Thu, 29 Nov 2012 10:12:11 +0100, David Paleino wrote: Ciao, [..] Dimenticavo, altri errorucci: - su tutte le route di una stessa compagnia, dovresti usare lo stesso network. In una usi local, nell'altro usi aMo - Città di Sassuolo. Dovresti usare qualcosa di specifico -- la seconda potrebbe andar bene; - il ref delle linee è solo A, non LINEA A; - i nomi delle linee sono diversi stilisticamente: pur non essendo un errore in sé, dovresti cercare di mantenere una certa congruità nei dati. L'andata è chiamata: Linea A - Rossa: Refice Scuole = Cimitero Nuovo mentre il ritorno: Linea A - Rossa - Cimitero Nuovo, Refice Scuole scegli uno stile, e mantienilo per tutta la rete. - nella relazione ritorno (Cimitero → Refice), i membri non sono ordinati. Ordinali :) Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Eccezioni a divieto di svolta
On Thu, 29 Nov 2012 10:28:33 +0100, Maurizio Daniele wrote: Personalmente ho messo la via access=destination ma volendo mettere anche l'eccezione alla turn restriction, except=destination può andar bene? Secondo il wiki, except si usa solo per escludere categorie di veicoli (esempio tipico: svolta a sx vietata, eccetto mezzi pubblici), ma credo si possa estenderne l'uso. +1. Direi che except è un'estensione di access; per cui tutti i valori validi per access vanno bene anche per except. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: è un problema?
Ciao e grazie per la sollecitudine. Anzitutto, la chiave è public_transport, non puBBlic_transport, quindi dovresti correggere questo errore anzitutto. Ok. Semplicemente aggiungi la way due volte alla relazione. Inoltre, dovresti usare i ruoli forward e backward, per indicare in quale direzione viene percorsa. In effetti avevo provato la tua soluzione. Ma nell'editor di relazioni di Josm non accetta la selezione in quanto già presente. Mi sfugge qualcosa? Inoltre, ti pregherei di eliminare tutti quei tag source con il tuo indirizzo e-mail; non è quello il suo scopo (l'autore di un oggetto viene memorizzato altrove). Errore di gioventù che risale a quando mi sono mappato tutte le strade della città ormai un anno fa. Ora man mano che li ritrovo in effetti li cancello. su tutte le route di una stessa compagnia, dovresti usare lo stesso network. In una usi local, nell'altro usi aMo - Città di Sassuolo. Dovresti usare qualcosa di specifico -- la seconda potrebbe andar bene; - i nomi delle linee sono diversi stilisticamente: pur non essendo un errore in sé, dovresti cercare di mantenere una certa congruità nei dati. L'andata è chiamata: Linea A - Rossa: Refice Scuole = Cimitero Nuovo mentre il ritorno:Linea A - Rossa - Cimitero Nuovo, Refice Scuole scegli uno stile, e mantienilo per tutta la rete. nella relazione ritorno (Cimitero → Refice), i membri non sono ordinati. Ordinali :) Hai guardato anche l'altra relation relativa al ritorno! In effetti quella è nella 1° versione e sono consapevole che andasse rivista. il ref delle linee è solo A, non LINEA A; Ok. Ne prendo nota Ciao, David Ciao Beppe e mille grazie per il tuo supporto. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Eccezioni a divieto di svolta
Il 29 novembre 2012 11:20, David Paleino ha scritto: Direi che except è un'estensione di access; per cui tutti i valori validi per access vanno bene anche per except. torna, ma mi sembra ridondante e in futuro c'è il rischio di avere tag contraddittori sulla way e sulla relazione nel caso più comune di un divieto di accesso eccetto mezzi pubblici, metteremmo i tag solo sulla way e non creeremmo una relazione turn_restriction, giusto? -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] è un problema?
On Thu, 29 Nov 2012 11:31:43 +0100, Giuseppe Amici wrote: Semplicemente aggiungi la way due volte alla relazione. In effetti avevo provato la tua soluzione. Ma nell'editor di relazioni di Josm non accetta la selezione in quanto già presente. Mi sfugge qualcosa? Usi un plugin per l'editor di relazioni? Perché quello di default tutt'al più ti avverte, ma non ti _impedisce_ di aggiungere una way più di una volta. È un avvertimento utile nella maggior parte dei casi, ma in questo caso siamo coscienti di ciò che facciamo :) L'editor di default è questo: http://josm.openstreetmap.de/attachment/wiki/Help/Dialog/RelationEditor/relation_editor.png Semplicemente, apri la relazione, poi selezioni la way in JOSM, torni alla finestra della relazione, scegli dove posizionarla nel tab a sinistra, e con il 2° o 3° tasto sulla destra scegli se posizionarla sopra/sotto al membro della relazione selezionato. Vedrai che i membri duplicati saranno colorati di rosa. Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Eccezioni a divieto di svolta
Il giorno 29 novembre 2012 11:39, Daniele Forsi dfo...@gmail.com ha scritto: nel caso più comune di un divieto di accesso eccetto mezzi pubblici, metteremmo i tag solo sulla way e non creeremmo una relazione turn_restriction, giusto? E' giusto. Nel caso specifico non c'è ragione di svoltare se non sei interessato ad andare in quel vicolo cieco, quindi potrei anche fare a meno della turn restriction ritenendola rindondante, ma potrebbero esserci altri casi in cui serve una eccezione del genere, quindi mi chiedevo se si potesse ritenere un valore valido except=destination -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Eccezioni a divieto di svolta
On Thu, 29 Nov 2012 11:39:30 +0100, Daniele Forsi wrote: Il 29 novembre 2012 11:20, David Paleino ha scritto: Direi che except è un'estensione di access; per cui tutti i valori validi per access vanno bene anche per except. torna, ma mi sembra ridondante e in futuro c'è il rischio di avere tag contraddittori sulla way e sulla relazione nel caso più comune di un divieto di accesso eccetto mezzi pubblici, metteremmo i tag solo sulla way e non creeremmo una relazione turn_restriction, giusto? Nel caso più comune, la way è oneway=yes, per cui non si usano turn_restrictions :) Nel caso in cui fosse una vera restriction (i.e. la strada è a doppio senso, ma da un senso non puoi girarci comunque), la relazione andrebbe creata, e l'eccezione messa su questa, non sulla strada (perché in effetti la strada è accessibile). Per esempio: http://www.openstreetmap.org/browse/relation/2605493 (pensavo di averla già mappata, e invece no, mah) Da Via Notarbartolo, se provieni dal lato stazione, non puoi girare in Via Boito; se provieni dal lato opposto sì. Quindi, ovviamente, la strada è accessibile, e l'eccezione (se ci fosse, qui non c'è) andrebbe sulla relazione. Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Eccezioni a divieto di svolta
2012/11/29 Daniele Forsi dfo...@gmail.com: nel caso più comune di un divieto di accesso eccetto mezzi pubblici, metteremmo i tag solo sulla way e non creeremmo una relazione turn_restriction, giusto? si, i turn restrictions servono per mettere una restrizione dove il diritto d'accesso sarebbe presente per i ways. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Sito minerario
2012/11/29 mario ma...@leatoscana.org: salve nella mia zona c'è un area , costiera, usata fino agli anni 60 per lo stoccaggio della pirite in enormi tramogge di laterizio, ed il successivo carico su nave attraverso teleferica (di cui ora rimane solo la struttura a terra). se fosse un sito attivo un tag generico adatto sarebbe landuse=industrial (perchè comprende anche lo stoccaggio), per siti in disuso ci sono alcuni tags (start_date, end_date, disused, ecc.). Quella strutttua lì mi sembra che era una sorta di porto, vero? Ora è stata restaurata, è visitabile con guida forse tourism=museum? e fa parte del Parco Nazionale delle colline Metallifere. i parchi si possono segnalare con leisure=nature_reserve o meglio boundary=protected_area e relativi subtags (vedi wiki) Che tag usare? Qualcosa che ha a che fare con l'archeologia industriale? Vorrei specifiicare bene le varie caratteristiche. quali sono le charatteristiche che vuoi specificare? Se manca qualcosa lo puoi inventare. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: è un problema?
Usi un plugin per l'editor di relazioni? no Perché quello di default tutt'al più ti avverte, ma non ti _impedisce_ di aggiungere una way più di una volta. È un avvertimento utile nella maggior parte dei casi, ma in questo caso siamo coscienti di ciò che facciamo :) L'editor di default è questo: http://josm.openstreetmap.de/attachment/wiki/Help/Dialog/RelationEditor/rela tion_editor.png Semplicemente, apri la relazione, poi selezioni la way in JOSM, torni alla finestra della relazione, scegli dove posizionarla nel tab a sinistra, e con il 2° o 3° tasto sulla destra scegli se posizionarla sopra/sotto al membro della relazione selezionato. Vedrai che i membri duplicati saranno colorati di rosa. È esattamente quello che faccio. Non ci sono avvisi. Semplicemente non aggiunge nulla (evidenzia invece lo stesso tratto già inserito precedentemente nella lista delle way). Bho?! Che sia un bug? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] ricerca come scoprire il vandalismo in OSM
Vi segnalo questo paper (in inglese) di Pascal Neis, Prof. Zipf, università di Heidelberg, su come scoprire il vandalismo in Openstreetmap. Loro purtroppo per il momento non hanno risorse per sviluppare un sistema che usa i risultati, forse interessa a qualcuno di voi? http://www.mdpi.com/2220-9964/1/3/315 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: R: è un problema?
Esatto! J Da: Maurizio Daniele [mailto:maurizio.dani...@gmail.com] Inviato: giovedì 29 novembre 2012 13:20 A: openstreetmap list - italiano Oggetto: Re: [Talk-it] R: è un problema? Il giorno 29 novembre 2012 13:05, Giuseppe Amici giuseppeam...@virgilio.it ha scritto: Non ci sono avvisi. Semplicemente non aggiunge nulla (evidenzia invece lo stesso tratto già inserito precedentemente nella lista delle way). Bho?! Che sia un bug? Ho verificato: la prima volta che provi ad aggiungere un elemento duplicato ti chiede che cosa vuoi fare e se quello dev'essere il comportamento di default. Se imposti non aggiungere e non chiedere più, lui non te lo chiede più e non aggiunge mai elementi duplicati. Per ripristinare il comportamento di default devi andare a ravanare nelle impostazioni (F12) in modalità avanzata ed azzerare le due voci: message.add_primitive_to_relation message.add_primitive_to_relation.value -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Pagamento bancomat
Ciao a tutti. Sto concludendo il giro dei miei distributori di benzina (magari fossero miei) e come ultimo tag inserirei i pagamenti accettati. Va bene per coins, mastercard, Dyners ecc. ma il mezzo più accettato da tutti è il Bancomat. Quale è il tag giusto? Il wiki contempla la carta di debito ma non credo possa essere assimilata al bancomat. Grazie. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Che io sappia la carta di debito e il bancomat sono la stessa cosa. Saluti Fabrizio Il giorno 29 novembre 2012 17:46, Gianluca Boero gianlucabo...@alice.itha scritto: Ciao a tutti. Sto concludendo il giro dei miei distributori di benzina (magari fossero miei) e come ultimo tag inserirei i pagamenti accettati. Va bene per coins, mastercard, Dyners ecc. ma il mezzo più accettato da tutti è il Bancomat. Quale è il tag giusto? Il wiki contempla la carta di debito ma non credo possa essere assimilata al bancomat. Grazie. -- Gianluca Boero __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Il giorno 29 novembre 2012 17:49, Fabrizio Tambussa ftambu...@gmail.comha scritto: Che io sappia la carta di debito e il bancomat sono la stessa cosa. Sì, infatti, il Bancomat è un sistema di distribuzione di denaro che utilizza carte di debito. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Il 29/11/2012 17:53, Simone Saviolo ha scritto: Il giorno 29 novembre 2012 17:49, Fabrizio Tambussa ftambu...@gmail.com mailto:ftambu...@gmail.com ha scritto: Che io sappia la carta di debito e il bancomat sono la stessa cosa. Sì, infatti, il Bancomat è un sistema di distribuzione di denaro che utilizza carte di debito. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it quindi payment:debit_cards = yes ? -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
2012/11/29 Gianluca Boero gianlucabo...@alice.it: quindi payment:debit_cards = yes ? http://wiki.openstreetmap.org/wiki/Key:payment credo payment:maestro=yes è il tag tra gli elencati. Altri sistemi (evventualmente anche utilizzabile con la stessa carta) sono bancomat ( COGEBAN con gli sistemi PagoBancomat e Bancomat ) cirrus (marchio di Mastercard, vedi http://en.wikipedia.org/wiki/Cirrus_(interbank_network) ) fastpay (caselli autostradali) l'informazione debit_cards si / no non aiuta moltissimo, perchè ce ne sono tanti sistemi in giro (credo), anche se ultimamente con EAPS quelli europaei si sono messi insieme per accettare reciprocamente le proprie carte. Vedete anche EAPS http://en.wikipedia.org/wiki/Euro_Alliance_of_Payment_Schemes Io userei payment:maestro supponendo che dove accettano quello accetteranno anche pago bancomat ecc. http://it.wikipedia.org/wiki/Maestro_(carta_di_debito) oppure mettiamo un tag payment:pago_bancomat=yes/no ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
2012/11/29 Martin Koppenhoefer dieterdre...@gmail.com: COGEBAN il loro sito: http://www.bancomat.it/it/consorzio/marchi.html dice esplicitamente che bancomat e pagobancomat sono servizi livello nazionale e che spesso le carte avranno altri servizi (reti) abbinati (maestro, ecc.). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Il 29/11/2012 18:13, Martin Koppenhoefer ha scritto: 2012/11/29 Gianluca Boero gianlucabo...@alice.it: quindi payment:debit_cards = yes ? http://wiki.openstreetmap.org/wiki/Key:payment credo payment:maestro=yes è il tag tra gli elencati. Altri sistemi (evventualmente anche utilizzabile con la stessa carta) sono bancomat ( COGEBAN con gli sistemi PagoBancomat e Bancomat ) cirrus (marchio di Mastercard, vedi http://en.wikipedia.org/wiki/Cirrus_(interbank_network) ) fastpay (caselli autostradali) l'informazione debit_cards si / no non aiuta moltissimo, perchè ce ne sono tanti sistemi in giro (credo), anche se ultimamente con EAPS quelli europaei si sono messi insieme per accettare reciprocamente le proprie carte. Vedete anche EAPS http://en.wikipedia.org/wiki/Euro_Alliance_of_Payment_Schemes Io userei payment:maestro supponendo che dove accettano quello accetteranno anche pago bancomat ecc. http://it.wikipedia.org/wiki/Maestro_(carta_di_debito) oppure mettiamo un tag payment:pago_bancomat=yes/no ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it fosse possibile crearlo non sarebbe una cattiva idea, potrebbe servire anche per attività commerciali e ristoranti, farmacie ecc ecc. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Direi di valutare di inserire nella pagina http://wiki.openstreetmap.org/wiki/Key:payment sotto Debit Cards ancora: payment:cirrus=* payment:bancomat=* payment:pagobancomat=* Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
On gio, 2012-11-29 at 18:23 +0100, Gianluca Boero wrote: fosse possibile crearlo non sarebbe una cattiva idea, potrebbe servire anche per attività commerciali e ristoranti, farmacie ecc ecc. _Niente_ ti vieta di inserire tag nuovi, ma personalmente non mi sembra una buona idea aumentare il grado incredibile di caos che già regna nel fantastico mondo dei tag. Quindi, per quel poco che conta, ti consiglio in generale di usare uno di quelli documentati sul wiki :-) /bruno P.S. anche quelli documentati non sono granché usati... payment 520 payment:coins 16916 payment:notes 4331 payment:cash 1088 payment:maestro 419 payment:debit_card 1 payment:mastercard 453 payment:visa 480 payment:credit_card 19 (fonte, taginfo.openstreetmap.org) -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email br...@tracciabi.li GNU/Linux registered user #121507 http://linuxcounter.net signature.asc Description: This is a digitally signed message part ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
On Thu, Nov 29, 2012 at 6:47 PM, Damjan Gerl dam...@damjan.net wrote: Direi di valutare di inserire nella pagina http://wiki.openstreetmap.org/wiki/Key:payment sotto Debit Cards ancora: payment:cirrus=* payment:bancomat=* payment:pagobancomat=* +1 dopotutto ci sono già payment:bankaxess e simili... Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Il giorno 29/nov/2012 18:48, Damjan Gerl dam...@damjan.net ha scritto: Direi di valutare di inserire nella pagina http://wiki.openstreetmap.org/wiki/Key:payment sotto Debit Cards ancora: payment:cirrus=* payment:bancomat=* payment:pagobancomat=* Scusa, mi sfugge l'utilità di payment:bancomat=* Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pagamento bancomat
Il 29/11/2012 19:06, Francesco Pelullo ha scritto: Il giorno 29/nov/2012 18:48, Damjan Gerl dam...@damjan.net mailto:dam...@damjan.net ha scritto: Direi di valutare di inserire nella pagina http://wiki.openstreetmap.org/wiki/Key:payment sotto Debit Cards ancora: payment:cirrus=* payment:bancomat=* payment:pagobancomat=* Scusa, mi sfugge l'utilità di payment:bancomat=* Ciao /niubii/ O forse potrebbe essere meno utile pagobancomat. Se il pagamento è il bancomat, poi può avere qualunque denominazione senza bisogno di specificarlo. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] [RETTIFICA]Re: Pagamento bancomat
Il 29/11/2012 19:22, Gianluca Boero ha scritto: Il 29/11/2012 19:06, Francesco Pelullo ha scritto: Il giorno 29/nov/2012 18:48, Damjan Gerl dam...@damjan.net mailto:dam...@damjan.net ha scritto: Direi di valutare di inserire nella pagina http://wiki.openstreetmap.org/wiki/Key:payment sotto Debit Cards ancora: payment:cirrus=* payment:bancomat=* payment:pagobancomat=* Scusa, mi sfugge l'utilità di payment:bancomat=* Ciao /niubii/ O forse potrebbe essere meno utile pagobancomat. Se il pagamento è il bancomat, poi può avere qualunque denominazione senza bisogno di specificarlo. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it Rettifico il mio ultimo post http://www.bancomat.it/it/consorzio/marchi.html quindi hanno ragione di esistere entrambi. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [RETTIFICA]Re: Pagamento bancomat
2012/11/29 Gianluca Boero gianlucabo...@alice.it: Il 29/11/2012 19:22, Gianluca Boero ha scritto: O forse potrebbe essere meno utile pagobancomat. Se il pagamento è il bancomat, poi può avere qualunque denominazione senza bisogno di specificarlo. forse il tag payment:bancomat=no potrebbe avere qualche senso per bancomat (genere di macchina, amenity=atm) che non accettano tessere del circuito bancomat (in Italia), anche se erogare dei soldi non è pagare (diciamo che paga la macchina). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-dk] Flyvestation Værløse
28. nov. 2012 21.20 skrev Lilla 22 geolill...@gmail.com: 1. Hvad skal der gøres ved landingsbanen og tilhørende asfalterede arealer? Ville det være en god idé at tegne den en gang til som vej? Som nuværende tegnes de på GPS’en som hvid på lysegrå baggrund, dvs næsten umulige at se. (Både med og uden Mapnik TYP). Eller ville det være mere rigtigt simpelthen at ændre attributterne fra landingsbane til vej? Har aldrig tagget noget som dette, men hvis det ikke er landingsbane mere, er det vel at betragte som en stor asfalteret plads som kan tagges med area=yes ligesom man tagger pladser/torve osv. inde i en by? 2. Hvad med de områder, som stadig er lukket for offentligheden? Hvordan skal de markeres? Lidt svært at finde noget - hvis det stadig er militært område så måske http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmilitary 3. Hvornår skal noget tegnes som en sti? Det er rimelig uklart ud fra http://wiki.openstreetmap.org/wiki/Path_controversy “Something, where walking is allowed and possible for someone.” Jeg tænker særligt på “stierne” i vestenden som bedst kan beskrives som en strækning af sumpet mudder, som holdes græsfrit af kreaturhove. (Gummistøvler kræves!) Personligt hælder jeg mest til, at man skal kunne færdes med alm sko eller vandrestøvler før noget er en sti. Det du tænker på er hvornår det er en sti og hvornår det bare er et mudderhul? Hvis der er et nogenlunde tydeligt spor, så vil jeg mene det er en sti uanset hvor mudret den er, der er jo nogle muligheder for at tagge fremkommeligheden: http://wiki.openstreetmap.org/wiki/Tag:highway=path Ole ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] forbindelse fra perron til tog?
vores cykelplanlægger har også data for skåne med. men hvis man vil fra kbh til malmø, så foreslår den en pæn omvej med færgen helsingør-helsingborg, i stedet for toget kbh-malmø: http://www.ibikecph.dk/#!/x3yva.7r0b5/x59p8.7hats ruteplanlæggeren kan ellers godt anvende togstrækninger. så vidt jeg kan se, er problemet at toglinjerne ikke er forbindet til perronerne. fx: hovedbanegården i kbh: http://www.openstreetmap.org/?lat=55.67247748374939lon=12.565156817436218zoom=18 ørestad station: http://www.openstreetmap.org/?lat=55.628484lon=12.578697zoom=18layers=M toglinjerne går tæt på perronerne, men rør ikke. hvordan bør det håndteres? på den ene side kunne man sige, at det må håndteres i ruteplanlæggeren. på en anden side virker det naturlig at der er forbindelse i osm, ligesom resten af vejnettet er forbundet. man kan jo faktisk gå helt ind i toget. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dkmailto://z...@tmf.kk.dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
Emil Tin skrev: vores cykelplanlægger har også data for skåne med. men hvis man vil fra kbh til malmø, så foreslår den en pæn omvej med færgen helsingør-helsingborg, i stedet for toget kbh-malmø: http://www.ibikecph.dk/#!/x3yva.7r0b5/x59p8.7hats ruteplanlæggeren kan ellers godt anvende togstrækninger. så vidt jeg kan se, er problemet at toglinjerne ikke er forbindet til perronerne. Hvordan ved du, at den kan anvende togstrækninger? Hvis der bare er nogen stationer i nærheden, der er forbundet til vejnettet, burde ruteplanlæggeren vel vælge dem frem for færgen? hvordan bør det håndteres? på den ene side kunne man sige, at det må håndteres i ruteplanlæggeren. på en anden side virker det naturlig at der er forbindelse i osm, ligesom resten af vejnettet er forbundet. man kan jo faktisk gå helt ind i toget. Jeg vil mene, at det er ruteplanlæggeren, der skal håndtere det. Selv hvis man indtegner gangstier helt frem til perronnerne, skal ruteplanlæggeren alligevel tage højde for, at man hellere vil trække cyklen ind i toget, end at cykle ombord på færgen. I eksemplet med Hovedbanegården er der faktisk allerede forbindelse fra vejnettet til perronnerne via trapperne på Tietgensbroen. Jeg tror ikke, at det kan mappes meget mere detaljeret end det. - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' detaljer ja, men nok til at man blive sendt over helsingør :-) vi har lavet nogen test til OSRM ruteberegneren: https://github.com/DennisOSRM/Project-OSRM/blob/master/features/bicycle/train.feature den tilhørende cykelprofil håndtere toglinjer korrekt nok, i hvert fald viser testene ingen problem. hvad med relations der binder perronen og toglinje sammen? det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? -Oprindelig meddelelse- Fra: Jørgen Elgaard Larsen [mailto:j...@elgaard.net] Sendt: 29. november 2012 14:22 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Emil Tin skrev: vores cykelplanlægger har også data for skåne med. men hvis man vil fra kbh til malmø, så foreslår den en pæn omvej med færgen helsingør-helsingborg, i stedet for toget kbh-malmø: http://www.ibikecph.dk/#!/x3yva.7r0b5/x59p8.7hats ruteplanlæggeren kan ellers godt anvende togstrækninger. så vidt jeg kan se, er problemet at toglinjerne ikke er forbindet til perronerne. Hvordan ved du, at den kan anvende togstrækninger? Hvis der bare er nogen stationer i nærheden, der er forbundet til vejnettet, burde ruteplanlæggeren vel vælge dem frem for færgen? hvordan bør det håndteres? på den ene side kunne man sige, at det må håndteres i ruteplanlæggeren. på en anden side virker det naturlig at der er forbindelse i osm, ligesom resten af vejnettet er forbundet. man kan jo faktisk gå helt ind i toget. Jeg vil mene, at det er ruteplanlæggeren, der skal håndtere det. Selv hvis man indtegner gangstier helt frem til perronnerne, skal ruteplanlæggeren alligevel tage højde for, at man hellere vil trække cyklen ind i toget, end at cykle ombord på færgen. I eksemplet med Hovedbanegården er der faktisk allerede forbindelse fra vejnettet til perronnerne via trapperne på Tietgensbroen. Jeg tror ikke, at det kan mappes meget mere detaljeret end det. - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
Hej. Alt hvad i beskriver kan mappes med (det nye) Public Transport (http://wiki. openstreetmap.org/wiki/Public_transport) Der skal laves relation med public_transport = stop_area for hvert stoppested og ruterne skal tilføjes som relationer. I relationerne for hvert stoppested er perronen og en node på skinnen bundet sammen. Det kan ruteplanlæggeren bruge i første omgang til dumt at sende en bruger med toget. Hvis der senere bliver oprettet relationer for alle togruterne kan den så vise tognummer, perronnummer osv. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dk 2012/11/29 Jørgen Elgaard Larsen j...@elgaard.net Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
lyder godt! dvs. man kan oprette en relation der inkluderer platformen og en node på toglinjen der ligger ud for platformen? og ruteplanlæggeren kan så bruge den til at komme fra platformen og vider med toget.. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dkmailto:z...@tmf.kk.dk Fra: Mathias Dannesbo [mailto:n...@neic.dk] Sendt: 29. november 2012 16:34 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Hej. Alt hvad i beskriver kan mappes med (det nye) Public Transport (http://wiki.openstreetmap.org/wiki/Public_transport) Der skal laves relation med public_transport = stop_area for hvert stoppested og ruterne skal tilføjes som relationer. I relationerne for hvert stoppested er perronen og en node på skinnen bundet sammen. Det kan ruteplanlæggeren bruge i første omgang til dumt at sende en bruger med toget. Hvis der senere bliver oprettet relationer for alle togruterne kan den så vise tognummer, perronnummer osv. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dkmailto:n...@neic.dk 2012/11/29 Jørgen Elgaard Larsen j...@elgaard.netmailto:j...@elgaard.net Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.orgmailto:Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
Ja. På banen opretter du en node med tag: public_transport = stop_position Hvis der er oprettet en platform opretter du en relation med tag: public_transport = stop_area type = public_transport og tilføjer noden på banen med rollen stop og platformen(e) (node, way eller area) med rollen platform. Se dokumentationen for denne type relation her: http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area Denne relation binder kun et stop på banen sammen med en platform. Ud over det kan man oprette stationer som bliver parret sammen med alle stoppende på stationen. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dk 2012/11/29 Emil Tin z...@tmf.kk.dk lyder godt! dvs. man kan oprette en relation der inkluderer platformen og en node på toglinjen der ligger ud for platformen? og ruteplanlæggeren kan så bruge den til at komme fra platformen og vider med toget.. ** ** ** ** Med venlig hilsen *Emil Tin *IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dk ** ** *Fra:* Mathias Dannesbo [mailto:n...@neic.dk] *Sendt:* 29. november 2012 16:34 *Til:* OpenStreetMap Denmark *Emne:* Re: [Talk-dk] forbindelse fra perron til tog? ** ** Hej. Alt hvad i beskriver kan mappes med (det nye) Public Transport ( http://wiki.openstreetmap.org/wiki/Public_transport) Der skal laves relation med public_transport = stop_area for hvert stoppested og ruterne skal tilføjes som relationer. I relationerne for hvert stoppested er perronen og en node på skinnen bundet sammen. Det kan ruteplanlæggeren bruge i første omgang til dumt at sende en bruger med toget. Hvis der senere bliver oprettet relationer for alle togruterne kan den så vise tognummer, perronnummer osv. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dk 2012/11/29 Jørgen Elgaard Larsen j...@elgaard.net Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ** ** ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
super. er der eksempler på brugen i dk? Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dkmailto:z...@tmf.kk.dk Fra: Mathias Dannesbo [mailto:n...@neic.dk] Sendt: 29. november 2012 17:13 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Ja. På banen opretter du en node med tag: public_transport = stop_position Hvis der er oprettet en platform opretter du en relation med tag: public_transport = stop_area type = public_transport og tilføjer noden på banen med rollen stop og platformen(e) (node, way eller area) med rollen platform. Se dokumentationen for denne type relation her: http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area Denne relation binder kun et stop på banen sammen med en platform. Ud over det kan man oprette stationer som bliver parret sammen med alle stoppende på stationen. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dkmailto:n...@neic.dk 2012/11/29 Emil Tin z...@tmf.kk.dkmailto:z...@tmf.kk.dk lyder godt! dvs. man kan oprette en relation der inkluderer platformen og en node på toglinjen der ligger ud for platformen? og ruteplanlæggeren kan så bruge den til at komme fra platformen og vider med toget.. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433tel:%2B45%203366%203433 Email EAN 5798009493149 z...@tmf.kk.dkmailto:z...@tmf.kk.dk Fra: Mathias Dannesbo [mailto:n...@neic.dkmailto:n...@neic.dk] Sendt: 29. november 2012 16:34 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Hej. Alt hvad i beskriver kan mappes med (det nye) Public Transport (http://wiki.openstreetmap.org/wiki/Public_transporthttp://openstreetmap.org/wiki/Public_transport) Der skal laves relation med public_transport = stop_area for hvert stoppested og ruterne skal tilføjes som relationer. I relationerne for hvert stoppested er perronen og en node på skinnen bundet sammen. Det kan ruteplanlæggeren bruge i første omgang til dumt at sende en bruger med toget. Hvis der senere bliver oprettet relationer for alle togruterne kan den så vise tognummer, perronnummer osv. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dkmailto:n...@neic.dk 2012/11/29 Jørgen Elgaard Larsen j...@elgaard.netmailto:j...@elgaard.net Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.orgmailto:Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.orgmailto:Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
Fornylig forsøgte jeg mig med det i bl.a. Kokkedal. Torsdag den 29. november 2012 17:38:55 skrev Emil Tin: super. er der eksempler på brugen i dk? Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dk Fra: Mathias Dannesbo [mailto:n...@neic.dk] Sendt: 29. november 2012 17:13 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Ja. På banen opretter du en node med tag: public_transport = stop_position Hvis der er oprettet en platform opretter du en relation med tag: public_transport = stop_area type = public_transport og tilføjer noden på banen med rollen stop og platformen(e) (node, way eller area) med rollen platform. Se dokumentationen for denne type relation her: http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area Denne relation binder kun et stop på banen sammen med en platform. Ud over det kan man oprette stationer som bliver parret sammen med alle stoppende på stationen. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dk 2012/11/29 Emil Tin z...@tmf.kk.dk lyder godt! dvs. man kan oprette en relation der inkluderer platformen og en node på toglinjen der ligger ud for platformen? og ruteplanlæggeren kan så bruge den til at komme fra platformen og vider med toget.. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dk Fra: Mathias Dannesbo [mailto:n...@neic.dk] Sendt: 29. november 2012 16:34 Til: OpenStreetMap Denmark Emne: Re: [Talk-dk] forbindelse fra perron til tog? Hej. Alt hvad i beskriver kan mappes med (det nye) Public Transport (http://wiki.openstreetmap.org/wiki/Public_transport) Der skal laves relation med public_transport = stop_area for hvert stoppested og ruterne skal tilføjes som relationer. I relationerne for hvert stoppested er perronen og en node på skinnen bundet sammen. Det kan ruteplanlæggeren bruge i første omgang til dumt at sende en bruger med toget. Hvis der senere bliver oprettet relationer for alle togruterne kan den så vise tognummer, perronnummer osv. Med Venlig Hilsen Mathias Dannesbo http://neic.dk n...@neic.dk 2012/11/29 Jørgen Elgaard Larsen j...@elgaard.net Emil Tin skrev: jeg tænkte faktisk på 1. det lille stykke fra slutning af trappen, til kanten af parronen 2. fra perronen og helt ud til tog 'linjen' Jeg kan ikke se, hvordan det kan mappes bedre end det er. hvad med relations der binder perronen og toglinje sammen? Mig bekendt er der ingen måde at angive dette. Se http://wiki.openstreetmap.org/wiki/Railway_stations det kan hurtigt bliver svært for en ruteberegner selv at regne ud hvilke stier, veje og platforme der har forbindelse til en toglinje? Ja. Men problemet stopper ikke der. Lige nu kan man se, at der er jernbanespor fra København til Malmö. Men man kan ikke se, om der kører persontog imellem dem. Principielt kunne der gå tog fra Malmö til Kalundborg og fra København til Flensborg uden at der var mulighed for at skifte mellem dem. Læs mere på http://wiki.openstreetmap.org/wiki/Train_routing og http://wiki.openstreetmap.org/wiki/Train_routes Så vidt jeg kan se, er der ikke angivet toglinier mellem København H og Malmö. Og selv hvis der var, ville det være vanskeligt at se, hvilken perron, et givent tog ville holde ved. Der er dog folk der prøver: http://opentripplanner.com/ http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte Du kan måske også tale med folk fra Rejseplanen og få nogle tip? - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] forbindelse fra perron til tog?
On 29-11-2012 12:54, Emil Tin wrote: vores cykelplanlægger har også data for skåne med. men hvis man vil fra kbh til malmø, så foreslår den en pæn omvej med færgen helsingør-helsingborg, i stedet for toget kbh-malmø: http://www.ibikecph.dk/#!/x3yva.7r0b5/x59p8.7hats ruteplanlæggeren kan ellers godt anvende togstrækninger. så vidt jeg kan se, er problemet at toglinjerne ikke er forbindet til perronerne. fx: hovedbanegården i kbh: http://www.openstreetmap.org/?lat=55.67247748374939lon=12.565156817436218zoom=18 ørestad station: http://www.openstreetmap.org/?lat=55.628484lon=12.578697zoom=18layers=M Hvordan virker cykelplanlæggeren egentlig. Fx kommer man med Hundested-Rørvig færgen, hvis man man skal fra Hedehusene til Rørvig, men ikke fra Roskilde til Rørvig. Dvs den prøver ikke at undgå færger ret meget. Men for tog er det vel anderledes. Hvis man fx skal fra Hørve til Fårevejle er togskinnerne klart den korteste vej. Men det betyder vel ikke at cyklister skal sendes med toget? toglinjerne går tæt på perronerne, men rør ikke. hvordan bør det håndteres? på den ene side kunne man sige, at det må håndteres i ruteplanlæggeren. på en anden side virker det naturlig at der er forbindelse i osm, ligesom resten af vejnettet er forbundet. man kan jo faktisk gå helt ind i toget. Med venlig hilsen Emil Tin IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Email EAN 5798009493149 z...@tmf.kk.dkmailto://z...@tmf.kk.dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-gb-westmidlands] Mapping Social on 1/12/12
Hello All, My name is Bhaveen Dattani and I have recently signed up to the OSM Mailbox. I am currently a final year undergraduate student studying Computer Science and I have an interest in VGI. I would love the opportunity to get involved and find out first hand, how VGI is generated. I am aware that there is a mapping social evening on Saturday 1st December and would like to find out more information about this event? I hope you do not mind my informal approach and would like to thank you for your time. Kind regards, Bhaveen Dattani ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-es] Importación masiva de caminos CyL
Hola a todos; Quería retomar un tema que vi de casualidad en la lista. http://lists.openstreetmap.org/pipermail/talk-es/2011-November/thread.html#8616 Vi que hablasteis del tema de importar caminos en Castilla y León, quisiera saber que pasó al final. El motivo de mi pregunta es porque veo que algunos usuarios como “walo” en Burgos, Montgomery en Palencia, ottokar55 en León y mas usuarios que están mapeando multitud de caminos y si pudieran importase se ahorraría tiempo en ese tipo de mapeo y ocuparlo en otros tipos. Desde mi desconocimiento, me suena que la junta de Castilla y León abrió o cambió a política de datos abiertos, ¿que se puede hacer con ellos desde el punto de vista de OpenStreetMap? http://www.datosabiertos.jcyl.es/web/jcyl/set/es/cartografia/Catalogo/1284207342167 un saludo, Óscar (alias cronoser en osm)___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Importación masiva de caminos CyL
A mi me vendría muy bien la importación, más que nada por no subir todos los dias 1000 nodos de caminos jajaja. Según leo en la licencia, para un uso comercial, hay que ponerse en contacto con el Centro de Información Territorial: c...@jcyl.es ¿Alguien de los que está apuntado en la lista que pertenecen o trabajan para la JcYl puede ponerse en contacto con ellos? Sería muy interesante. Un saludo. -- Original Header --- From : Óscar Zorrilla Alonso oscar_zorri...@hotmail.com To : Lista correo OpenStreetMap España talk-es@openstreetmap.org Cc : Date : Thu, 29 Nov 2012 16:52:06 +0100 Subject : [Talk-es] Importación masiva de caminos CyL Hola a todos; Quería retomar un tema que vi de casualidad en la lista. http://lists.openstreetmap.org/pipermail/talk-es/2011-November/thread.html#8616 Vi que hablasteis del tema de importar caminos en Castilla y León, quisiera saber que pasó al final. El motivo de mi pregunta es porque veo que algunos usuarios como “walo” en Burgos, Montgomery en Palencia, ottokar55 en León y mas usuarios que están mapeando multitud de caminos y si pudieran importase se ahorraría tiempo en ese tipo de mapeo y ocuparlo en otros tipos. Desde mi desconocimiento, me suena que la junta de Castilla y León abrió o cambió a política de datos abiertos, ¿que se puede hacer con ellos desde el punto de vista de OpenStreetMap? http://www.datosabiertos.jcyl.es/web/jcyl/set/es/cartografia/Catalogo/1284207342167 un saludo, Óscar (alias cronoser en osm) ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Baumkataster Wien - Import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/11/12 03:50, ScubbX wrote: Hallo! Die Daten sind nun für den Import präpariert! Timestamp ist der 27.11.2012, Bäume die heute eingetragen wurden, wurden nicht beachtet. Die komprimierten OSM Daten kann man sich hier herunterladen: http://gisforge.no-ip.org:5984/datastore/osm/ogd_trees_wien_selected.osm.bz2 Wow, das nenn ich mal ein Haufen sinnvoller Tags :-) - Die Statistiker werden sich freun! Wie hast du das Problem mit den schon vorhandenen Bäumen gelöst? Werden die einfach ersetzt (was ich für das sinnvollste halte in Anbetracht der Aktualität der neuen Daten)? Es war eine ganz schöne Menge Arbeit, diese zu präparieren. Im Wesentlichen wurde alles so wie zuvor beschrieben gemacht. So es keine Gegenstimmen gibt , würde ich morgen/demnächst den Import durchführen. Ich würd noch 2,3 Tage warten, es liest nicht jeder jeden Tag seine emails ;-) lg, Markus lg, Michi - -- Michael Maier, Student of Telematics @ Graz University of Technology -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQtyxTAAoJEPDJmZ2oE4mGzSMP/iILFMvl+He+V3SJDaxXdgqP 4wmZfUMFKH3DmtfMrzt9Xra+4raMq9CeWWvouG5gFAOygp9zqzd6HmaKgiBJpEAW oRDkUeg7DV35YAiY9T7XgJotA4v+D76uxnBdjs7wWXu5zP6FonHSL2C7pT7fks+p 4tRctVwNYDlzu5wImDGdlEBK1AVpFGR3OkhYac3hlySYJf6LNawJw12DMxC223/8 CE0k3rLa15yyefzAVr99EEFyLp9OiDn6IsNz/YKKqlNcbKTcgWfU4DoVzyxPqGw4 YJi3WyYskMlWR9NbFDlwTWO25frkiKR9tCNVg0A/EMQmrBMnnY0KCKwEPdRX+/UE OD7SeOD5mBpbkCqbx53/lROjZWUAB3iHV12ONdOc/zo3ygHucNlUI/o1bfQHWoKB pbNqIjaErVfi3RIFVFeeUp2+Q5cb8HRNULMXdjvWz4ksE4uFXoGXDCrDCczhpaLM irFnZVxY/Vd3Dp7qyDZ8kPn6G1NI45RqqZLJmAaibymbONWTrVcaQ/4krDibBiqk Mt3a2xTRWcwW9jeijQOcH8vapU4doXWsXbA8BOY+AAcqINLClJuY/Sbe05BxYRzW y/VvGyXgfdqXkUiY9Vy06cZmkEtIJgR2vAylWd55x78gGrARpojDb65KpYnjO912 zqUW2BqLJDskeG2HN4CE =lpbV -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumkataster Wien - Import
Von den bestehenden Bäumen wird kein einziger ersetzt. Die Übertragung der Tags auf bestehende Bäume ist noch offen (Abgleichungsskript?). Am 2012-11-29 10:35, schrieb Michael Maier: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/11/12 03:50, ScubbX wrote: Hallo! Die Daten sind nun für den Import präpariert! Timestamp ist der 27.11.2012, Bäume die heute eingetragen wurden, wurden nicht beachtet. Die komprimierten OSM Daten kann man sich hier herunterladen: http://gisforge.no-ip.org:5984/datastore/osm/ogd_trees_wien_selected.osm.bz2 Wow, das nenn ich mal ein Haufen sinnvoller Tags :-) - Die Statistiker werden sich freun! Wie hast du das Problem mit den schon vorhandenen Bäumen gelöst? Werden die einfach ersetzt (was ich für das sinnvollste halte in Anbetracht der Aktualität der neuen Daten)? Es war eine ganz schöne Menge Arbeit, diese zu präparieren. Im Wesentlichen wurde alles so wie zuvor beschrieben gemacht. So es keine Gegenstimmen gibt , würde ich morgen/demnächst den Import durchführen. Ich würd noch 2,3 Tage warten, es liest nicht jeder jeden Tag seine emails ;-) lg, Markus lg, Michi - -- Michael Maier, Student of Telematics @ Graz University of Technology -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQtyxTAAoJEPDJmZ2oE4mGzSMP/iILFMvl+He+V3SJDaxXdgqP 4wmZfUMFKH3DmtfMrzt9Xra+4raMq9CeWWvouG5gFAOygp9zqzd6HmaKgiBJpEAW oRDkUeg7DV35YAiY9T7XgJotA4v+D76uxnBdjs7wWXu5zP6FonHSL2C7pT7fks+p 4tRctVwNYDlzu5wImDGdlEBK1AVpFGR3OkhYac3hlySYJf6LNawJw12DMxC223/8 CE0k3rLa15yyefzAVr99EEFyLp9OiDn6IsNz/YKKqlNcbKTcgWfU4DoVzyxPqGw4 YJi3WyYskMlWR9NbFDlwTWO25frkiKR9tCNVg0A/EMQmrBMnnY0KCKwEPdRX+/UE OD7SeOD5mBpbkCqbx53/lROjZWUAB3iHV12ONdOc/zo3ygHucNlUI/o1bfQHWoKB pbNqIjaErVfi3RIFVFeeUp2+Q5cb8HRNULMXdjvWz4ksE4uFXoGXDCrDCczhpaLM irFnZVxY/Vd3Dp7qyDZ8kPn6G1NI45RqqZLJmAaibymbONWTrVcaQ/4krDibBiqk Mt3a2xTRWcwW9jeijQOcH8vapU4doXWsXbA8BOY+AAcqINLClJuY/Sbe05BxYRzW y/VvGyXgfdqXkUiY9Vy06cZmkEtIJgR2vAylWd55x78gGrARpojDb65KpYnjO912 zqUW2BqLJDskeG2HN4CE =lpbV -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumkataster Wien - Import
On 29.11.12 11:46, ScubbX wrote: Von den bestehenden Bäumen wird kein einziger ersetzt. Die Übertragung der Tags auf bestehende Bäume ist noch offen (Abgleichungsskript?). Für die neuen Bäume gibt's IMO nix, was dagegen spricht. - Go. Und ich wäre auch für ein Updatescript, das die Tags von bestehenden Bäumen ergänzt. Vielen Dank für die Mühe! /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumkataster Wien - Import
Am 2012-11-29 12:49, schrieb Stefan Tauner: On Thu, 29 Nov 2012 11:46:23 +0100 ScubbX markus4mayr.li...@gmail.com wrote: Von den bestehenden Bäumen wird kein einziger ersetzt. Die Übertragung der Tags auf bestehende Bäume ist noch offen (Abgleichungsskript?). hab mir das erzeugt osm (noch) nicht angesehen (und den thread nur oberflächlich verfolgt :). was hast du konkret vor zu tun? die neuen nodes des katasters zusätzlich zu den bestehenden zu importieren (dh wir hätten dann eine vielzahl an dubletten unmittelbar nebeneinander)? der fachbegriff für abgleich heißt conflation. es gibt ein gleichnamiges josm plugin, das wird aber vielleicht bei der menge überfordert sein (is grundsätzlich ein wenig buggy). einen blick wert ist es auf jeden fall. Um eben genau diese Dubletten zu vermeiden wurden bestehende Bäume aus dem OGD Kataster herausgefiltert (ca 1800 Stück). In OSM sind noch nicht viele Bäume eingezeichnet. Der Großteil davon liegt in Innenhöfen im 8. Bezirk, welche vom Baumkataster sowieso nicht abgedeckt sind. Das Filtern habe ich mit Python und QGis gemacht. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Baumkataster Wien - Import
On Thu, 29 Nov 2012 13:42:06 +0100 ScubbX markus4mayr.li...@gmail.com wrote: Am 2012-11-29 12:49, schrieb Stefan Tauner: On Thu, 29 Nov 2012 11:46:23 +0100 ScubbX markus4mayr.li...@gmail.com wrote: Von den bestehenden Bäumen wird kein einziger ersetzt. Die Übertragung der Tags auf bestehende Bäume ist noch offen (Abgleichungsskript?). hab mir das erzeugt osm (noch) nicht angesehen (und den thread nur oberflächlich verfolgt :). was hast du konkret vor zu tun? die neuen nodes des katasters zusätzlich zu den bestehenden zu importieren (dh wir hätten dann eine vielzahl an dubletten unmittelbar nebeneinander)? der fachbegriff für abgleich heißt conflation. es gibt ein gleichnamiges josm plugin, das wird aber vielleicht bei der menge überfordert sein (is grundsätzlich ein wenig buggy). einen blick wert ist es auf jeden fall. Um eben genau diese Dubletten zu vermeiden wurden bestehende Bäume aus dem OGD Kataster herausgefiltert (ca 1800 Stück). In OSM sind noch nicht viele Bäume eingezeichnet. Der Großteil davon liegt in Innenhöfen im 8. Bezirk, welche vom Baumkataster sowieso nicht abgedeckt sind. Das Filtern habe ich mit Python und QGis gemacht. ok, sehr gut. kannst du die nicht selektierten dann auch noch verfügbar machen bitte? vl findet sich ja jemand, der sich derer annimmt. ich hab sonst keine einwände und freu mich drauf, danke! -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-lv] Gulbenes terplāns
Man ir, un es viņu esmu jau gandrīz pabeidzis apstrādāt no PDF (~80% ir pabeigts jau). Tiklīdz būs es iepostošu linku uz OSM failu novērtēšanai. Lauris 2012. gada 27. novembris 11:14 Martins M mart...@mednis.info rakstīja: Vai kādam ir Gulbenes (un apkārtnes) terplāns JOSM formātā? Mārtiņš __**_ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-lvhttp://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
[Talk-ca] City of Waterloo Open Data codefest Saturday
The City of Waterloo is planning on releasing some open data under a UK Open Government-based license, and hosting a code-fest this Friday/Saturday. Details of the event are here: http://www.opendatawr.ca/2012/11/city-of-waterloo-codefest/ I've been part of a preview of the datasets, which include: city facilities, detailed park information, places of worship, bike lanes, roads, trails, historical street names, heritage buildings. Anyone else interested in attending the event to have a look at the data and discuss if any of it might be suitable for OSM? Mike -- Mike Boos, MASc. mike.b...@gmail.com http://real.uwaterloo.ca/~mboos ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. J'utilise aussi le tag route_ref pour noter lors de relevé sur le terrain les lignes qui passent par un arrêt. Cela permet ensuite de retrouver/relier les arrêt dans la relation si elle existe ou quand on la crée. J'ai tendance à les laisser, cela apporte un peu de redondance et permet de faire des contrôles croisés. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment nommer simplement un groupe d'objet?
Nommer un landuse me semble la moins mauvaise solution si j'ai bien compris le besoin (une résidence). Pour une résidence, un landuse=residential + name=* Même principe pour une zone industrielle, zone commerciale, etc. Les relations c'est bien mais il ne faut pas en abuser... si l'on peut définir l'emprise de cette zone, un polygone suffit à indiquer que tout ce qui est à l'intérieur en fait partie. Le 29 novembre 2012 02:53, Tetsuo Shima tets...@gmail.com a écrit : Bonjour, Voilà mon petit souci, nommer un groupe de building/parking/voie accès qui forme une résidence machin ou un groupe truc, sans qu'il y ait particulièrement d'objet englobant le tout comme un amenity=*. Pour les groupes scolaire je trouve déjà la solution du landuse pas très élégante, donc je l'exclue ici, sauf que je ne vois pas d'alternative très pertinente ... a part une relation site=housing . Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Rester simple pour le plus grand nombre ne veut pas dire qu'ils *doivent* saisir les bons caractères sémantiques (le tiret cadratin est sémantique, et PAS typographique, il sépare deux entités complètement différentes et non liées, il résoud des ambiguités dans le cas où un des noms séparés de la même entité est figuré dans plusieurs langues et doit être mentionné à côté du nom d'une toute autre entité). Il sert aussi à éviter toutes sortes d'expressions basées sur des adverbes (comme de ... à , vers, entre, etc. qu'on ne peut pas distiguer des noms pour savoir s'ils s'attachent ensemble en un seul ou pas). Son rôle est pourtant différent du point-virgule qui signale des valeurs multiples dans une liste. Le tiret cadratin ne gêne absolument personne : il n'empêche pas du tout les utilisateurs qui ne savent pas l'entrer de saisir d'autres noms ailleurs avec un tiret simple. Prétendre que ce n'est que de la typographie est faux. Et puisque tu prends Wikipédia pour exemple, justement c'est pareil ! Les ponctuations correctes sont corrigées par d'autres et conservées. Et même leur utilisation ne bloque absolument pas les moteurs de recherche (par exemple Nominatim) ou n'importe quel moteur de recherche qui analyserait un rapport HTML sur le contenu de la base. Ces caractères sont présents depuis longtemps et il y a une très longue tradition dans toutes les entreprises d'édition de documents (dans les livres comme dans la presse) non pas parce qu'ils seraient plus jolis mais parce qu'ils sont plus exacts et plus précis sur ce qu'ils signifient (ils ne sont en particulier jamais utilisés dans aucun toponyme officiel, contrairement aux tirets simples, et pas mal d'autres signes de ponctuation, ce qui les qualifie aussi comme excellent séparateur entre deux entités différentes). Sa compréhension est immédiate et non ambiguë, il n'y a pas lieu de remettre un trait d'union simple mais ambigu. Et c'est facile à uniformiser. En plus ce tiret cadratin (—) est bel et bien sur de nombreux claviers comme l'est aussi le tiret demi-cadratin (–) qui sert à autre chose, surtout comme tiret d'introduction dans une liste énumérée de valeurs présentée dans des paragraphes séparés, ou comme séparateur indiquant une plage de valeur (signification plus précise que les points de suspension). Sa lecture est simple aussi, sur tous les supports. Leur rendu est impeccable aussi si c'est ça qui te gêne, car on ne voit jamais nulle part apparaître un rectangle ou un point d'interrogation ou quelque signe hiéroglyphique. La raison en est simple: ils sont présents dans windows-1252 (le remplaçant de l'ISO 8859-1 en HTML5) et dans pratiquement toutes les polices latines utilisables pour l'écriture complète du français (et pas seulement d'un sous-ensemble de l'anglais), et de non nombre de langues à écriture latine, cyrillique, grecque, ... et même encore arabe, hébreu, thaïe, laotienne (la seule exception c'est l'écriture sinographique où on peut le confondre avec le signe de répétition, mais ce signe traditionnel n'est pas réellement un long tiret mais un stroke qui est orienté, non symétrique, codé différemment dans le carré de composition synographique, et encore utilisé non encadré d'espaces car toujours en association dans un même mot ou une même phrase, ce qui là aussi évite la confusion si l'écriture sinographique est ultra simplifiée pour une représentation en petits caractères). De plus il fonctionne sans problème entre deux noms d'entités différentes qui sont dans des langues différentes. On n'a pas la même lisibilité et des confusions de sens avec le trait d'union (surtout quand de nombreux noms sont des noms composés, particulièrement les toponymes en français ! Il n'a pas d'équivalent clair (le trait d'union on l'a vu ou tiret servant à juxtaposer deux noms dans un seule et même nom officiel, la virgule qui sert aussi à ajouter une précision, le point-virgule qui sert de séparateur entre des valeurs multiples dans une même clé où chacune est applicable séparément à l'objet). Pourquoi ils te gênent, franchement on se le demande. Si le soucis c'est juste l'uniformité, c'est un non-roblème ici car les names=* ne sont pas sensés être analysés comme des codes, mais à donner du sens pour un lecteur humain et pas pour un robot (qui ne sait de toute façon pas quoi faire des name=* homonymes, les name=* n'étant PAS des identifiants, contrairement aux ref=* où l'uniformisation et la normalisation est bel et bien nécessaire). Si un robot veut les lire, il doit comprendre les langues humaines et accepter ses usages, mais pas imposer des trucs comme: supprimer toute ponctuation, tout écrite en capitales, supprimer les accents. Alors oui le robot doit s'adapter aux langues humaines, et pas l'inverse (et ils le font bien en plus concernant ce tiret cadratin car il existe des normes stables à leur sujet : tu ne connais pas UCA ?) Le 28 novembre 2012 20:15, Christian Quest cqu...@openstreetmap.fr a écrit : Pour les noms des stations
Re: [OSM-talk-fr] Suppression des tirets cadratins
La pseudo-règle typographique que tu propose n'est qu'une heuristique, elle s'avère fausse dans de trop nombreux cas. Ne parle pas de typographie quand tu ne sais pas ce que c'est et que tu généralise beaucoup trop vite ce qui te semble simple dans ton petit monde. Ton point de vue simple est celui technique d'un programmeur trop habitué à l'ASCII. Appliquer une telle règle par un robot est carrément stupide quand on sait le nombre d'usages distincts qui sont faits de ce tiret simple extrêmement ambigu hérité du très pauvre ASCII (qui déjà n'avait aucun accent) ou même encore bien avant du code télégraphique Baudot (qui n'avait même pas les minuscules et pas plus de guillemets puisqu'on répétait les apostrophes simples). Et puisque tu cites l'article Wikipédia en question, tu ferais bien de le lire (et même aussi la page consacrée sur Wikipédia sur les recommandations typographiques). Le 28 novembre 2012 20:15, Christian Quest cqu...@openstreetmap.fr a écrit : Il est toujours possible si l'on souhaite suivre les subtilités des règles de typographie de remplacer ces espace-tiret-espace par espace fine insécable-tiret demi cadratin-espace-espace fine insécable. On pourra aussi revoir la capitalisation des noms qui ne respecte sûrement par les règles de telle ou telle académie. * voir: http://fr.wikipedia.org/wiki/Tiret ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Roland à déjà mentionné qu'il serait très content si quelqu'un étend le plugin public_transport sur la liste josm-dev. L'avantage supplémentaire est que l'on peut utiliser les autres classes disponibles en JOSM pour travailler avec les données OSM, ce qui devrait rendre le travail plus facile. Peut-être je devrais me lancer dans l'apprentissage de JAVA, mais je préfère largement la simplicité et l'élégance de Python... Polyglot 2012/11/29 Vincent Privat vincent.pri...@gmail.com Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment nommer simplement un groupe d'objet?
Oui mais la question n'est pas celle des zones résidentielles ou commerciales ou industrielles : elles incluent par définition tout ce qui est dedans (même s'il y a des bois, jardins, constructions, routes, cours d'eau, voies ferrées, parkings...). Ce n'est pas le cas des autres landuse=* (et autres natural=*), comme la forêt qui n'inclue pas les cours d'eau (hormi les fossés et petits ruisseaux qui peuvent être sous la couverture des arbres), les constructions, les routes (sauf les chemins forestiers), les morceaux de mer ou les plages... Le problème c'est que là les règles d'inclusion ou non sont très floues, et qu'un moteur de rendu ou de recherche à du mal à choisir s'il faut ou non y inclure ces éléments. On doit l'aider en étant plus précis. Et on doit découper quand il y a des superpositions entre plusieurs landuse=* de types différents. ou plusieurs natural=* de types différents. De la même façon qu'on doit tronçonne aussi des routes ayant des attributs différents sur des sections distinctes, sans les superposer. Le problème c'est de résoudre les ambiguités. A la limite on a admis que les routes et batiments forment des ilots dans les zones où on les inclue, mais uniquement pour le rendu (qui les tracera par dessus sans les recouvrir). Mais en terme topologique, même les routes et bâtiments restent dans la zone landuse=* où ils sont situés, ce qui veut dire qu'on n'a pas à surdécouper la zone si tout autour de l'élément inclus c'est la même zone landuse=*. Dans un tel cas en effet il n'y a pas ambiguité (même si pour le rendu il faut ajouter une règle pour que ces éléments enclavés dans la zone ne soient pas recouverts, et parfois il faut même l'aider avec layer=* si la seule règle de priorité de superposition ne suffit pas). Le 29 novembre 2012 09:03, Christian Quest cqu...@openstreetmap.fr a écrit : Nommer un landuse me semble la moins mauvaise solution si j'ai bien compris le besoin (une résidence). Pour une résidence, un landuse=residential + name=* Même principe pour une zone industrielle, zone commerciale, etc. Les relations c'est bien mais il ne faut pas en abuser... si l'on peut définir l'emprise de cette zone, un polygone suffit à indiquer que tout ce qui est à l'intérieur en fait partie. Le 29 novembre 2012 02:53, Tetsuo Shima tets...@gmail.com a écrit : Bonjour, Voilà mon petit souci, nommer un groupe de building/parking/voie accès qui forme une résidence machin ou un groupe truc, sans qu'il y ait particulièrement d'objet englobant le tout comme un amenity=*. Pour les groupes scolaire je trouve déjà la solution du landuse pas très élégante, donc je l'exclue ici, sauf que je ne vois pas d'alternative très pertinente ... a part une relation site=housing . Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Salut, Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). J'y avais pensé... Jusqu'à tomber sur des lignes de bus qui passent devant des arrêts mais ne s'y arrêtent pas (y en a qu'ont essayé, ils ont eu des problèmes...). Du coup, le risque est grand de lever des faux-positifs. Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Pour ces cas-là, je ne vois pas trop comment les gérer, et encore moins comment les tester... Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Pour les bancs et Abribus, j'ai plutôt tendance à indiquer cette info directement sur le platform, car il arrive qu'un arrêt ait un banc et/ou un Abribus dans un sens mais pas dans l'autre (ce dernier correspond au cas où l'arrêt est vers la fin de la ligne, et que donc personne n'y monte). Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. C'est en cours : j'ai déjà ajouté ce matin la prise en compte de Maven, et revu en conséquence la hiérarchie des fichiers. Polyglot * * Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il n'y a pas 3 entités mais 2 : Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles - Brussels. Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles / Brussels et est-ce moins ambigu ? Faut-il alors écrire (et alors traduire...) De Paris à Bruxelles - Brussels, à traduire ensuite dans toutes les langues ? Maintenant compare à Paris – Bruxelles - Brussels : il n'y a plus aucune ambiguïté on voit bien 2 entités, l'une ayant 2 noms officiels juxtaposés et utilisés ensemble par défaut dans toutes les langues (même si on peut traduire dans une langue particulière pour en éliminer un, mais ce n'est pas toujours vrai car on a aussi les cas où deux graphies sont co-officielles dans la même langue, par exemple en écriture latine et en écriture cyrillique, et même co-officielles dans la même écriture et la même langue sans qu'on ait à choisir laquelle pour n'en afficher qu'une seule). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Ah, la question qui tue, et que je craignais de voir arriver ! :-) Petite histoire : Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes augmentant, j'ai vite réalisé à quel point ça allait devenir long et fastidieux de les vérifier toutes et de m'assurer qu'une modification à un endroit (un bout de route scindé en 2, des routes fusionnées, ...) pouvait avoir des répercussions sur mes relations. Bref, je me suis donc lancé dans l'écriture de cette appli, après avoir testé le plug-in en question, que je n'ai pas du tout trouvé pratique à manipuler ! Mais j'avais conscience dès le début que j'allais avoir à faire un choix : en faire un plug-in JOSM ? Une appli Web comme analyser ? De nouveaux tests pour Osmose ? Autre chose ? Maintenant, je reste ouvert aux idées, et inclure mon travail dans ledit plug-in, voire le reprendre pour l'améliorer n'est pas inenvisageable du tout. Le 29 novembre 2012 01:43, Vincent Privat vincent.pri...@gmail.com a écrit : Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort--Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort--Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil de vérification des relations de type transports publics
Il ne faut peut-être pas forcément l'ajouter à ce plugin. Peut-être c'est mieux de l'ajouter aux tests du validateur? Si ce que tu envisages c'est simplement un contrôle de qualité (comme c'est conçu maintenant) c'est l'endroit indiqué. Si tu l'envisages comme 'assistant' pour améliorer/créer les relations route=bus/tram, un plugin est peut-être mieux. Si l'interface graphique de l'existant ne convient pas, je ne pense pas que Roland serait très faché si celle-là est remplacée. Je me débrouille avec, mais dire qu'elle n'est pas très intuïtive c'est être gentil... Cependant, tout ce que je fait avec, c'est ajouter des arrêts, pour éliminer les faux-positifs par après. De toute façon, ça m'intéresse, je viens d'écrire quelque chose de comparable pour les relations d'itinéraire cycliste/randonnée avec des noeuds numérotés à l'aide du plugin scripting en JOSM: https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python/RCN_Route_Validator C'est du code Python (pour que je me sente à l'aise), mais il utilise les classes Java de JOSM. Je ne peut pas promettre que je serai très util, mais peut-être on peut travailler là-dessus ensemble. Polyglot 2012/11/29 Francescu GAROBY windu...@gmail.com Ah, la question qui tue, et que je craignais de voir arriver ! :-) Petite histoire : Lorsque je me suis lancé dans ce projet, c'est parce que je déclarais les lignes de bus Twisto, dans l'agglomération caennaise. Le nombre de lignes augmentant, j'ai vite réalisé à quel point ça allait devenir long et fastidieux de les vérifier toutes et de m'assurer qu'une modification à un endroit (un bout de route scindé en 2, des routes fusionnées, ...) pouvait avoir des répercussions sur mes relations. Bref, je me suis donc lancé dans l'écriture de cette appli, après avoir testé le plug-in en question, que je n'ai pas du tout trouvé pratique à manipuler ! Mais j'avais conscience dès le début que j'allais avoir à faire un choix : en faire un plug-in JOSM ? Une appli Web comme analyser ? De nouveaux tests pour Osmose ? Autre chose ? Maintenant, je reste ouvert aux idées, et inclure mon travail dans ledit plug-in, voire le reprendre pour l'améliorer n'est pas inenvisageable du tout. Le 29 novembre 2012 01:43, Vincent Privat vincent.pri...@gmail.com a écrit : Sympa comme initiative, mais pourquoi en faire forcément une application autonome ? J'aurais bien vu un plugin JOSM qui rajoute ces règles au validateur natif de JOSM. Cerise sur le gâteau, ça pourrait même être incorporé au plugin public_transport de Roland Obricht. En plus vu que Roland passe plus de temps sur l'Overpass API que sur ce plugin, je pense qu'il serait ravi de trouver un co-mainteneur du plugin :) Le 29 novembre 2012 00:24, Jo winfi...@gmail.com a écrit : J'étais en train de commencer le développement de quelque chose de comparable. En outre de détecter des erreurs, moi j'envisageais de faire une détection automatiques d'arrêts. Pour cela je voulais répérer tous les arrêts dans les 5-15m (configurable) à droite (gauche) du bout de chemin. (A l'aide du code des parallel ways pour déterminer une surface). Cela devrait également aider à les mettre dans l'ordre parcourue. Chez nous, nous avons des bus express qui ne desservent pas tous les arrêts qu'ils passent. Pour cela j'ai 'inventé' le tag not_served_by pour les exclure. J'utilise également le tag route_ref, car il est facile à remplir quand on est sur place et il aide à faire un contrôle de qualité. Nous avons également des bus qui ne font pas de trajet fixe, pour lesquels il n'existe pas de relation type=route. Ils ne desservent que les arrêts pour lesquels ils ont été réservés. Il pourrait être intéressant d'ajouter le banc, l'abribus et la poubelle à la relation stop_area, comme la plateforme et l'indicateur des bus à l'arrivé. Dès qu'un fichier .jar sera disponible, je serai ravi de tester ton application. Polyglot * * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 09:56, JB jb...@mailoo.org wrote: Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. Justement parce que la typographie c'est du rendu. On peut supposer qu'un moteur de rendu intelligent pourrait avoir des règles pour afficher un — lorsqu'il rencontre un - . JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
On 29 nov. 2012, at 09:47, Philippe Verdy verd...@wanadoo.fr wrote: Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il n'y a pas 3 entités mais 2 : Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles - Brussels. Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles / Brussels et est-ce moins ambigu ? Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Faut-il alors écrire (et alors traduire...) De Paris à Bruxelles - Brussels, à traduire ensuite dans toutes les langues ? Vladimir ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:09, Mikaël Cordon mikael.cor...@gmail.com a écrit : Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
