Re: [Talk-us] Mappy Hour tomorrow (monday) night
OK On Mon, Mar 23, 2015 at 7:53 AM, Richard Welty rwe...@averillpark.net wrote: On 3/23/15 8:32 AM, Paul Johnson wrote: I may need access to the US chapter page to do it without screwing over who's gonna be running it from recording. i think only Martijn can add managers. i'll try wrestling with event interface again in a little bit. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-it] Oneway vs access=no
Ciao Maxx, scusami, non avevo capito bene. Sempre da ignorante della situazione locale a cui ti riferisci, direi che se troviamo entrambi i segnali - accesso e direzione - allora metterei sia access che turn restriction, come hai fatto tu, in modo da rispettare al massimo la situazione reale. Gli exclude nelle turn restriction che hai messo mi pare vadano benissimo e siano in linea con quel che dice il wiki. In questi casi di informazione doppia, per evitare che in futuro qualcuno in vena di austerity elimini la turn restriction perché gli sembra ridondante rispetto agli access, potremmo mettere un source=traffic_sign sulla restriction, o almeno un tag note, che ne dite? E' un po' OT, ma non mi sembra ci sia modo di legare la turn restriction al/i segnale/i che la esprimono, ad esempio un role signaled_by= legato a un node con tag highway=traffic_sign. Avrebbe senso proporlo? Sig Il giorno 23 marzo 2015 13:41, emmexx emm...@tiscalinet.it ha scritto: Il 03/23/2015 01:16 PM, Martin Koppenhoefer scrisse: Ho trovato anch'io delle turn_restrictions sulla mappa, dove in realtà l'intenzione era quella di escludere traffico pubblico. Al solito, access=no non si trova nella realtà, cosa si trova molto più spesso è access=private (qualcuno che normalmente non siamo noi, può usare la strada) oppure motor_vehicle/vehicle=no. Con i turn_restrictions si esclude tutti, mentre con access=private qualcuno può ancora usare la strada. Nel caso specifico pero' i cartelli di direzione obbligatoria ci sono. Venendo da via Canova c'e' un cartello che indica l'obbligo di tirar dritto o di girare a sx, escluso autorizzati. Venedo da corso Sempione nord c'e' la segnaletica per girare a dx o a sx. Idem venendo da via Melzi d'Eril. Nel wiki si dice anche che nelle turn restriction e' possibile indicare la categoria di veicolo. Le 2 tipologie di restrizione (access o restriction) permette di inserire dati che danno info su 2 aspetti diversi. Con access indico una proprieta' lineare: in quella way vale questo. Con la restriction indico (in generale) una proprieta' puntuale: da quel punto non si passa. Quale e' piu' corretta? ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Oneway vs access=no
Il 03/23/2015 01:16 PM, Martin Koppenhoefer scrisse: Ho trovato anch'io delle turn_restrictions sulla mappa, dove in realtà l'intenzione era quella di escludere traffico pubblico. Al solito, access=no non si trova nella realtà, cosa si trova molto più spesso è access=private (qualcuno che normalmente non siamo noi, può usare la strada) oppure motor_vehicle/vehicle=no. Con i turn_restrictions si esclude tutti, mentre con access=private qualcuno può ancora usare la strada. Nel caso specifico pero' i cartelli di direzione obbligatoria ci sono. Venendo da via Canova c'e' un cartello che indica l'obbligo di tirar dritto o di girare a sx, escluso autorizzati. Venedo da corso Sempione nord c'e' la segnaletica per girare a dx o a sx. Idem venendo da via Melzi d'Eril. Nel wiki si dice anche che nelle turn restriction e' possibile indicare la categoria di veicolo. Le 2 tipologie di restrizione (access o restriction) permette di inserire dati che danno info su 2 aspetti diversi. Con access indico una proprieta' lineare: in quella way vale questo. Con la restriction indico (in generale) una proprieta' puntuale: da quel punto non si passa. Quale e' piu' corretta? ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-us] Mappy Hour tomorrow (monday) night
On 3/23/15 8:32 AM, Paul Johnson wrote: I may need access to the US chapter page to do it without screwing over who's gonna be running it from recording. i think only Martijn can add managers. i'll try wrestling with event interface again in a little bit. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Mappy Hour tomorrow (monday) night
I may need access to the US chapter page to do it without screwing over who's gonna be running it from recording. On Mon, Mar 23, 2015 at 7:04 AM, Richard Welty rwe...@averillpark.net wrote: On 3/23/15 4:14 AM, Paul Johnson wrote: Should I make the G+ event for it or will that trip things up? i was a little mystified by the current G+ interface so i didn't do so. if you can figure it out, more power to you. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Hallo, Der will wohl den von ihm erkannten Geburtsfehler von OSM korrigieren: http://forum.openstreetmap.org/viewtopic.php?pid=492839#p492839 lg 2015-03-23 12:59 GMT+01:00 borut.mari...@borut.eu: Hallo! Mapper http://www.openstreetmap.org/user/GUFSZ führt(e) heute einige Massenedits der tracktype=* durch, um sozusagen die innere logische Konsistenz zu verbessern. Aus meiner Sicht wurde dabei angenommen, dass die tracktype=* falsch sind und die surface=* korrekt (sprich, die tracktype=* werden verändert). Ich frage mich, ob das ganz durchdacht ist, weil es denkbar ist, dass die tracktype=* korrekter sind als die surface=*. Ist es euch bekannt, ob diese Edits vorher auf einer der talk-DACH Mailinglisten durchdiskutiert worden sind? Habe den GUFSZ vor kurzem auch direkt gefragt und warte auf die Antwort. Liebe Grüße, Borut ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-be] Local chapter OSMF
So what will be the local chapter? Will OFKN as a VZW be the local chapter? Will it be a part of OFKN, or a new VZW? I guess it needs to be some sort of organisation. Apart from that unclear part. I fully support having a local chapter for Belgium. It can only help with finding funds to organise stuff. Regards, Sander 2015-03-23 11:59 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com: Hi Marc, On Mon, Mar 23, 2015 at 11:51 AM, Marc Gemis marc.ge...@gmail.com wrote: Everybody is free to do what (s)he wants, not ? :-) No because if we claim to represent the OSM-community in Belgium we should act according to what they want to do! ;-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-us] Mappy Hour tomorrow (monday) night
On 3/23/15 4:14 AM, Paul Johnson wrote: Should I make the G+ event for it or will that trip things up? i was a little mystified by the current G+ interface so i didn't do so. if you can figure it out, more power to you. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk-be] Local chapter OSMF
Hi, As was said in one the past email-threads here, we are thinking about becoming a local chapter of the OSMF (OpenStreetMap Foundation). I think this is a good idea for several reasons. We will be: - An 'official' local instance of OSMF representing OSMF in relation to local governments, companies and media. - It's just common sense to work together (we are already de-facto a local chapter) [1] I think it's our job to ask feedback before doing this. So my question is now, is there anybody not happy with us spending our time on this? Met vriendelijke groeten, Best regards, Ben Abelshausen [1] http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters#Why_Local_Chapters.3F ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Hello, Comme je l'avais indiqué il y a quelques temps sur cette ML j'ai développé un petit programme permettant l'importation de base de données avec des hauteurs d'immeubles (véritable hauteur en mètre ou juste nombre d'étages). A la base c'était pour importer la base de donnée de http://www.pss-archi.eu (environ 40 000 immeubles répartis sur l'ensemble de la France) mais finalement j'ai commencé par les données de http://opendata.paris.fr. Cette dernière BD a l'avantage d'être complètement libre et elle contient 320 000 volumes bâtis parisiens avec leur nombre d'étage. Voici très grossièrement le fonctionnement: du programme - pour faire la correspondance avec les éléments d'OSM je regarde tout simplement si leur polygone contient (fonction ST_Contains de PostGIS) les coordonnées des bâtiments importés - si le bâtiment OSM a déjà un tag de hauteur ou de nombre d'étages je n'y touche pas - s'il y a plusieurs imports qui matchent le même bâtiment OSM c'est celui dont la surface se rapproche le plus du bâtiment OSM qui gagne - si un import match une relation multipolygone : s'il y a un et un seul membre outer (la grosse majorité des cas) je le met à jour, sinon je ne fais rien (pour l'instant) J'ai testé le programme sur la base de test avec une zone couvrant Bastille / Gare de Lyon / Nation et cela se passe plutôt pas mal : environ 2400 immeubles (sur 2500 matchés) ont été mis à jour, soit quasiment tous les immeubles de la zone concernée. Vous pouvez voir le résultat avec JOSM par ex. en le faisant pointer sur http://api06.dev.openstreetmap.org (éventuellement avec le plugin Kenzi3D pour avoir un rendu 3D). Maintenant j'aimerais avoir vos conseils pour la suite : - dans quelle mesure dois je pousser mes tests avant de pouvoir prétendre les appliquer en live ? - quelles précautions à prendre pour pouvoir éventuellement rollbacker mes changements sans trop de complications ? - dois je demander une autorisation spéciale avant de faire des modifications en masse sur le serveur live ? Pour le 2e point j'imagine que ça sera possible dans la mesure où j'aurais des changesets bien définis (ie. avec les mêmes tags source et comment) ainsi qu'un compte utilisateur créé pour l'occasion (différent de mon compte personnel). Merci pour votre aide, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre à Paris vendredi 27 mars
Si vous voulez encore une louche d'Open pour le jeudi 26 : http://sodata.org/ SO Data 3 26 mars 2015 - Paris, France La conférence Scientific Open Data, 3e édition, se tiendra le 26 mars prochain à l’Institut des Systèmes Complexes à Paris (113 rue Nationale, 75013 Paris Métro ligne 6 (Nationale) et 14 (Olympiades)). Cette journée est consacrée à l’Open Data dans le milieu scientifique... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Hallo! Mapper http://www.openstreetmap.org/user/GUFSZ führt(e) heute einige Massenedits der tracktype=* durch, um sozusagen die innere logische Konsistenz zu verbessern. Aus meiner Sicht wurde dabei angenommen, dass die tracktype=* falsch sind und die surface=* korrekt (sprich, die tracktype=* werden verändert). Ich frage mich, ob das ganz durchdacht ist, weil es denkbar ist, dass die tracktype=* korrekter sind als die surface=*. Ist es euch bekannt, ob diese Edits vorher auf einer der talk-DACH Mailinglisten durchdiskutiert worden sind? Habe den GUFSZ vor kurzem auch direkt gefragt und warte auf die Antwort. Liebe Grüße, Borut ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-cl] [WM-CL] Registro Conferencia Wikimedia Chile 2015
Estimad@s miembros de la Comunidad Open Street Map Chile, Les escribo a nombre de Wikimedia Chile, para invitarles cordialmente a la *Conferencia Wikimedia Chile 2015 http://www.wikimediachile.cl/Conferencia_Wikimedia_Chile_2015*. La *Conferencia Wikimedia Chile 2015* será la primera conferencia nacional de Wikimedia realizada en Chile. Es organizada por *Wikimedia Chile http://www.wikimediachile.cl/Wikimedia_Chile:Acerca_de*, capítulo local de la Fundación Wikimedia en Chile, y su objetivo es abordar diversos temas de interés sobre Wikipedia, los demás proyectos Wikimedia, y en general, de la cultura libre. La conferencia se centrará en tres temas principales: los desafíos que enfrenta Wikipedia en la actualidad, la ejecución de proyectos que favorezcan el conocimiento libre, incluyendo los acuerdos con instituciones culturales http://www.wikimediachile.cl/Instituciones_culturales o «GLAM», acrónimo en inglés que significa *Galleries, Libraries, Archives and Museums*, o en español, Galerías, Bibliotecas, Archivos y Museos, y la ejecución de proyectos educativos http://www.wikimediachile.cl/Educaci%C3%B3n en Wikipedia. El evento se realizará los días 26, 27 y 28 de marzo en la Biblioteca Nacional de Chile, y contará con expositores internacionales y nacionales. Pueden consultar el programa completo en el siguiente enlace: http://www.wikimediachile.cl/Conferencia_Wikimedia_Chile_2015#Programa Además, estarán presentes: Patricio Lorente, vicepresidente de la Junta Directiva de la Fundación Wikimedia Estados Unidos; Vlado Mirosevic diputado de la República; Kacie Harold, Analista de Aprendizaje y Evaluación de la Fundación Wikimedia y Melina Masnatta, encargada de Educación de Wikimedia Argentina. El enlace para el registro (*totalmente gratuito*) en la Conferencia es el siguiente: *http://conferencia-wmcl-2015.eventbrite.es http://conferencia-wmcl-2015.eventbrite.es* No está de más decir, que pueden compartir y enviar este enlace a otras entidades, instituciones y corporaciones que tengan interés en el conocimiento libre, y que formen parte de sus redes de contacto. De antemano muchas gracias! Atentamente, -- Eduardo Testart Wiegand Presidente - Wikimedia Chile +56 98 293 52 78 http://wikimediachile.cl ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
Re: [OSM-talk-be] Local chapter OSMF
Hi Marc, On Mon, Mar 23, 2015 at 11:51 AM, Marc Gemis marc.ge...@gmail.com wrote: Everybody is free to do what (s)he wants, not ? :-) No because if we claim to represent the OSM-community in Belgium we should act according to what they want to do! ;-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-it] Oneway vs access=no
2015-03-23 9:09 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: La turn restriction dovrebbe essere inserita solo in presenza di un segnale specifico di direzione obbligatoria. Non indica chi può o non può transitare nella way di destinazione, ma solo chi può o non può effettuare una certa manovra ad un incrocio. +1 Ho trovato anch'io delle turn_restrictions sulla mappa, dove in realtà l'intenzione era quella di escludere traffico pubblico. Al solito, access=no non si trova nella realtà, cosa si trova molto più spesso è access=private (qualcuno che normalmente non siamo noi, può usare la strada) oppure motor_vehicle/vehicle=no. Con i turn_restrictions si esclude tutti, mentre con access=private qualcuno può ancora usare la strada. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
Am 23. März 2015 um 10:12 schrieb Kurt Waldhans k...@waldhans.com: ich bin immer noch fuer cycling=yes in Analogie zu hiking=yes auch als Namespace wenn Du auf cycling bestehst, es könnte ja auch sign_type=cycling sein. cycling=yes ist einfach nicht allgemeinverständlich. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
Sveiki, autorių teisės įdėtos - http://www.geoportal.lt/wps/poc?uri=page:6_P10C7I930GG1F0IGPAS4G33GL6. Žemėlapių naršyklėje, apačioje kairėje paspaudus autorių teisės, nukreipiama į visų duomenų šaltinių, kurie panaudoti kuriant pagrindo žemėlapį, autorių teises. Čia nurodytas ir openstreetmap kaip užsienio teritorijos duomenų šaltinis. Manau, kad reikalavimas iš esmės išpildytas. Galima būtų parašyti pilną tekstą iškart be paspaudimo ant nuorodos, bet įsivaizduokite, jeigu reikėtų visus surašyti, tai vietos žemėlapiui neliktų. Taigi, autoriai tikrai neslepiami, viskas nurodytas, tik vietoje vietoje pilno pavadinimo yra nuoroda į detalesnį aprašymą, kuris mano galva yra gal net geriau, nei tiesiog OpenStreetMap būtų parašyta. Jeigu galvojate, kad toks sprendimas labai netinkamas, galėtume keisti. Tik su daugeliu duomenų teikėjų sutarėme, kad apačioje kairėje pateikiame nurodą į detalesnį aprašymą, nes visi norėjo ant žemėlapio rašyti. Tai jei rašysime OSM, tai reikės ir visų rašyti, na ir grįžtame prie situacijos, kad žemėlapyje nebėra vietos žemėlapiui. Andrius. 2015 m. kovo 23 d. 12:25, Tomas Straupis tomasstrau...@gmail.com rašė: ... the credit should appear in the corner of the map ... Iš teisinės pusės gal ir taip. Bet iš praktinės: 1. OpenStreetMap duomenys yra antriniai, t.y. jie nėra esminis dalykas, vaizduojamas žemėlapyje. 2. Žemėlapyje yra labai daug kitų duomenų tiekėjų, visi jie minimi vienoje vietoje, nėra jokių išimčių/išskirtinių tiekėjų. Jei visus tiekėjus kišti į „žemėlapio kampą“ - neliks vietos žemėlapiui. Žinoma galima pulti visus, naudojančius OSM duomenis, ir reikalauti, kad jie vidury žemėlapio riebiu šriftų parašytų „OpenStreetMap rulez“, tik kas ir ką iš to laimės? :-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt -- Andrius Balciunas cartoIQ.com http://www.cartoiq.com | cartoUI.com ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Le Lundi 23 mars 2015 11h56, Vincent Frison vincent.fri...@gmail.com a écrit : Hello, Comme je l'avais indiqué il y a quelques temps sur cette ML j'ai développé un petit programme permettant l'importation de base de données avec des hauteurs d'immeubles (véritable hauteur en mètre ou juste nombre d'étages). A la base c'était pour importer la base de donnée de http://www.pss-archi.eu (environ 40 000 immeubles répartis sur l'ensemble de la France) mais finalement j'ai commencé par les données de http://opendata.paris.fr. Cette dernière BD a l'avantage d'être complètement libre et elle contient 320 000 volumes bâtis parisiens avec leur nombre d'étage. Voici très grossièrement le fonctionnement: du programme- pour faire la correspondance avec les éléments d'OSM je regarde tout simplement si leur polygone contient (fonction ST_Contains de PostGIS) les coordonnées des bâtiments importés- si le bâtiment OSM a déjà un tag de hauteur ou de nombre d'étages je n'y touche pas- s'il y a plusieurs imports qui matchent le même bâtiment OSM c'est celui dont la surface se rapproche le plus du bâtiment OSM qui gagne- si un import match une relation multipolygone : s'il y a un et un seul membre outer (la grosse majorité des cas) je le met à jour, sinon je ne fais rien (pour l'instant) J'ai testé le programme sur la base de test avec une zone couvrant Bastille / Gare de Lyon / Nation et cela se passe plutôt pas mal : environ 2400 immeubles (sur 2500 matchés) ont été mis à jour, soit quasiment tous les immeubles de la zone concernée.Vous pouvez voir le résultat avec JOSM par ex. en le faisant pointer sur http://api06.dev.openstreetmap.org (éventuellement avec le plugin Kenzi3D pour avoir un rendu 3D). Maintenant j'aimerais avoir vos conseils pour la suite : - dans quelle mesure dois je pousser mes tests avant de pouvoir prétendre les appliquer en live ?- quelles précautions à prendre pour pouvoir éventuellement rollbacker mes changements sans trop de complications ?- dois je demander une autorisation spéciale avant de faire des modifications en masse sur le serveur live ? Pour le 2e point j'imagine que ça sera possible dans la mesure où j'aurais des changesets bien définis (ie. avec les mêmes tags source et comment) ainsi qu'un compte utilisateur créé pour l'occasion (différent de mon compte personnel). Merci pour votre aide, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
On Sun, Mar 22, 2015 at 06:57:22PM +0100, Alexander Heinlein wrote: Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort zwei mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja bei allen Preset-Checkboxen so üblich, führt in diesem Fall aber zu Routing-Problemen. JOSM can mittlerweile das no auch unterdrücken. Kannst ja nach einem enchancement fragen. Ist aber leider auch nur eine halbe Lösung. Wenn man bicycle=no unterdrückt, dann ist nicht mehr ersichtlich, ob der Wegweiser keine Fahrradrouten enthält oder ob es bisher nur niemand eingetragen hat. Nicht vorhandene Beschilderungen für Fahrradrouten können dann einfach nicht mehr gekennzeichnet werden. guidepost:bicycle=yes? Ja diese namespace geschichten sind nicht formal definiert bei OSM aber sie werden an allen ecken und enden verwendet. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
Greg, 3. It is my belief and experience that the ground observable rule is something that only applies to Europe or older metropolitan areas. I think there's a misunderstanding here. Of course even in European metropolitan areas there will *not* be a sign bearing the name of every stream that you drive across! That doesn't keep Europeans from mapping the stream (the fact that there *is* one is at least observable), or naming it according to common knowledge or whatever the locals will tell you the name is. We usually draw the line when it is about features that cannot be seen on the ground; these should be in OSM only in exceptional cases (for example we do map administrative boundaries and post code areas even if they're invisible; the discussion about how much of a railway must still be there to map it as abandoned is going on elsewhere; the mapping of airways is strongly discouraged; some people map long-distance radio links but that is not likely to catch on). Your remark that OSM is different from the old GIS world with ESRI and $20k GPS receivers is correct, however it is not a suitable basis for reasoning (following the same logical path as you did, I could say they use computers; we are different, so we should not use computers). The ground observable rule kicks in most strongly when there's a dispute. If one mapper happily maps an invisible boundary and another mapper pops up and maps it differently, and they later apply to someone to mediate in their conflict, that third person will ask whether there is any proof for each mapper's version, and if there isn't any because both just map from hearsay, then the feature will have to be tagged as disputed or removed altogether. 9. Taking Serge's example of neighborhood boundaries to the logical conclusion, nothing should be put in OSM because an edit war __could__ ensue. Again, you've misunderstood Serge; because as long as we stick to observable things, the edit war can be resolved by fact-checking. This is what Serge hinted at when he talked about Alice and Bob. Crucially he also mentioned that there's a high risk that if we allow un-substantiated mapping of neighbourhoods, this might be at the expense of the underprivileged who seldom participate in OSM. For some, it might make a very big difference whether their address resolves to neighbourhood A or neighbourhood B if they live just on the border. As long as we're talking facts there's not much that can go wrong - an able-bodied, college-educated caucasian male can trace a stream through the slums from Bing without being in much danger of unwittingly applying prejudice. The same is not true for the same able-bodied, college-educated caucasian male drawing the boundary of the neighbourhood they are unlikely to ever set foot in. There's actually quite a few things apart from neighbourhoods that are not defined. For example here in Germany, if a village can advertise themselves as being in the Black Forest, that's a plus, tourism-wise. But the Black Forest is not a forest where you simply check the treeline; it's a large region with not-really-well-defined boundaries. There's places where 99% of interviewees would says clearly that's in the Black Forest, and places where 99% would say clearly not, but a grey band in between. The kind of area that is labelled with a curved, wide-spaced font on old-school maps. OSM doesn't have a good mechanism to record these; OSM only accepts precise geometries, not fuzzy ones. 7. The ground observable rule is a barrier to new mappers. I helped a new mapper at a Editathon add taco stands. She did everything wrong. I did say no you cannot add that node. We have not gone and surveyed that node exists. I let her add the node with abbreviated street names and all. She was so exited to add here research data to OSM. There's absolutely no problem with adding Taco stands from memory as they are observABLE (even if not observED) and if someone else starts a fuss about the Taco stands, we can just go there and check. People add data from memory all the time, and if it's wrong, it get fixed. But that's not the point when discussing neighbourhood boundaries. I failed to map for months because it sounded like I had to have a GPS five years ago before I could map. I think you're consistently misunderstanding the difference between observable and observed. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
Greg Morgan wrote: 2. To quote Richard Fairhurst, Seriously, OSM in the [England] s still way beyond broken. You can open it at any random location and the map is just __fictional__. Here are two random examples bing;OS StreetView [2] shape is approximate. Needs proper survey as mostly built after current BING imagery date [3] I have no idea, at all, what point you are trying to make, but I would appreciate it if you didn't make it by deliberately misquoting me. Thank you. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Retagging-hamlets-in-the-US-tp5837186p5838190.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
On 23.03.2015 12:59, borut.mari...@borut.eu wrote: Mapper http://www.openstreetmap.org/user/GUFSZ führt(e) heute einige Massenedits der tracktype=* durch, um sozusagen die innere logische Konsistenz zu verbessern. Aus meiner Sicht wurde dabei angenommen, dass die tracktype=* falsch sind und die surface=* korrekt (sprich, die tracktype=* werden verändert). Ich frage mich, ob das ganz durchdacht ist, weil es denkbar ist, dass die tracktype=* korrekter sind als die surface=*. So sehe ich das auch. Außerdem hat er nicht mal die Definitionen im Wiki gelesen (z.B. dass grade1 auch unpaved sein kann). Bin für einen schnellen Revert. Ist es euch bekannt, ob diese Edits vorher auf einer der talk-DACH Mailinglisten durchdiskutiert worden sind? Nicht dass ich wüsste, und es wär auch sehr verwunderlich, wenn diese Edits in irgendeiner Mailingliste für gut befunden worden wären. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Mappy Hour tomorrow (monday) night
here is an event link which i hope works ok: https://plus.google.com/b/113331273824393211883/events/cnsbqt4rtjjcekl2hcgc53josj0?authkey=COK7xau86urZ6gE i may need to send invitations to people on a case by case basis; if you have a g+ account but can't get access, send me an email and i'll try to sort it out. note that i teach class at UAlbany from 5:30pm to 7:05pm, so i will be ignoring all messages until about 7:40pm, but that gives me nearly an hour to sort things out after i get home. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Am 23. März 2015 um 15:25 schrieb Friedrich Volkmann b...@volki.at: Bin für einen schnellen Revert. +1 Selbe Meinung. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Mon, Mar 23, 2015 at 2:30 AM, Greg Morgan dr.kludge...@gmail.com wrote: 1. Every time this boundary debate or accuracy debate comes up, I image that I am supposed to have $20,000 of GPS equipment[1]; post process the data so that it is accurate; before I dare put the data in OSM. I agree with you that things which you can't verfiy without thousands of dollars of equipment doesn't belong in a generalized dataset like OSM. 3. It is my belief and experience that the ground observable rule is something that only applies to Europe or older metropolitan areas. Then you're going to have problems with all of OSM, since we use that rule to handle virtually any dispute. I am curios what river or wash I just drove over. It is not posted. I had to go to the US government sites to find the information because it is useful in OSM. It's entirely possible that the names the locals use for that river differ from the government dataset, in which case, OSM would prefer you use the local name as the primary name, and not the official one. Ground observable in this case is Local knowledge. Of course that requires consensus, but this is why we have so many tags related to names 6. The ground observable rule is trying to take over the more important rule: Mappers with local knowledge of their area add valuable data that commercial mapping companies cannot always afford to add to the map. This is based on a misunderstanding of your understanding of what the ground observable rule is. A person who lives in an area and can talk about it will actually trump most other sources, including signage, but that requires that we get lots of people involved and working in a diplomatic way. 7. The ground observable rule is a barrier to new mappers. I helped a new mapper at a Editathon add taco stands. She did everything wrong. I did say no you cannot add that node. We have not gone and surveyed that node exists. I let her add the node with abbreviated street names and all. She was so exited to add here research data to OSM. Why not help her ensure that her data be in OSM by being a teaching resource? Also, what does sign names have to do with ground surveying? 8. The ground observable rule is a barrier to new mappers. Most of the new mappers I know started mapping by signing up and adding data. Adding data they surveyed or adding data they got from another source? 9. Taking Serge's example of neighborhood boundaries to the logical conclusion, nothing should be put in OSM because an edit war __could__ ensue. This is quite the stawman argument you've build in my name, but it's not my argument. OSM has a long history of encouraging surveyed data. 11. The ground observable rule fails to acknowledge that not every feature is observable but still is useful to OSM. I had to talk the rent-a-cops out of arresting me for taking pictures around Chase Field [8]. I could not see around the building or under the 7th street bridge via satellite imagery. In this post 911 world, the ground observable rule is an unrealistic requirement. I've never encountered a problem with law enforcement officials when mapping, so I can't speak to your experience. 12.I am passionate about what I do with OSM and the out reach that I do. I am game to survey and map my city, county, and state. It feels like this growing number of people believes that every mapper has to map just like Steve Coast did ten years ago. Congratulations Serge! It is my growing belief that your growing number of people has stymied growth in new and different valuable ways of mapping data. I failed to map for months because it sounded like I had to have a GPS five years ago before I could map. Last year (or was it the year before) at SOTM US, there was discussed with Ian Dees leading the discussion about using municipal data in a separate dataset, and yet I don't see you being as viscous against him. Whether it's deliberate or not, please stop misquoting me to further your arguments. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk-fr] ?
Bonjour, Le 19 mars 2015 17:38, Jérôme Amagat jerome.ama...@gmail.com a écrit : Bonjour, Quel tag pour une forêt communale ou domaniale ? ( le problème avec landuse=forest c'est que ça veux dire que la forêt est partout à l’intérieur mais c'est pas sûr pour une forêt communale ou domaniale) Que veux-tu dire par c'est que ça veux dire que la forêt est partout à l’intérieur mais c'est pas sûr pour une forêt communale ou domaniale? c'est quoi une piscine dans osm? pour moi c'est soit un bassin plein d'eau soit un lieu ou l'on va pour se tremper dans un bassin plein d'eau. ça se traduit comment dans osm? (amenity ou leisure, swimming pool ou sport_centre). Leisure est maintenant plus utilisé que amenity cf. http://wiki.openstreetmap.org/wiki/FR:Tag:leisure%3Dswimming_pool Tout le monde sait ce que c'est un château ou une école par exemple. Mais quand on veux les indiquer sous forme d'area dans osm, qu'est ce qu'on met dedans? Là c'est ton interprétation qui considère que château ou école désigne un bâtiment or à mon sens c'est bien tout ce qui est en relation. Donc représenter une école c'est englober la cour... et un château ce sont un éventuel parc et les dépendances... Et la plupart du temps, l'aire est facile à identifier, il n'y a qu'à suivre les contours des murs ou grilles. Pour un château, c'est juste un bâtiment ou on va jusqu’à un éventuel mur, avec ou sans jardin, allée... Pour une école : salle de classe, cour, allée, parking Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Oneway vs access=no
Il giorno 23 marzo 2015 14:49, emmexx emm...@tiscalinet.it ha scritto: Senza voler riaprire un thread recente che spero tu non abbia seguito [ :-) ], le turn restriction non hanno necessariamente corrispondenza con la segnaletica esistente. Anzi in molti casi viene consigliato di non inserire turn restriction quando le restrizioni sono implicite (ad esempio perche' una way e' a senso unico). Visto che non possiamo risolvere il problema affidandoci al manuale o alla prassi corrente (che ci dicono tutto e il contrario di tutto), facciamo una scelta e rimaniamo consistenti. Io voto per inserire il set minimo di informazioni ;) Sarebbe possibile arrivare a definire delle regole almeno a livello locale (penso a Milano) e formalizzarle nel wiki? Potremmo usare a tal fine la pagina http://wiki.openstreetmap.org/wiki/Milano ? Grazie Sig ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Oneway vs access=no
2015-03-23 13:41 GMT+01:00 emmexx emm...@tiscalinet.it: Nel caso specifico pero' i cartelli di direzione obbligatoria ci sono. Venendo da via Canova c'e' un cartello che indica l'obbligo di tirar dritto o di girare a sx, escluso autorizzati. se legalmente non puoi girare per via di un access tag non è necessario inserire una turn restriction. E' simile al caso dei sensi unici, anche lì trovi le restrizioni in città, ma in OSM non le mettiamo se il senso della restrizione già si crea dal tag oneway. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Deletion of relations in Sicily / Di eliminazione delle relazioni in Sicilia
Whilst investigating something else, I came across a large number of deleted relations in Sicily (1) , and wanted to check that these deletions had been discussed within the Italian community first. I've added a changeset discussion comment to it asking this, but haven't seen a reply yet. I'm posting here because it seems like the most widely used OSM forum for the Italian community. If it's not I'd be grateful if someone could post in a more widely used forum. (In italiano con Google Translate) Mentre indagando qualcos'altro, mi sono imbattuto in un gran numero di rapporti eliminati in Sicilia (1), e volevo controllare che queste delezioni erano stati discussi all'interno della comunità italiana prima. Ho aggiunto un commento changeset discussione che chiedere questo, ma non ho ancora visto una risposta. Sto postando qui perché sembra che il forum OSM più utilizzato per la comunità italiana. Se non è sarei grato se qualcuno potrebbe postare in un forum più largamente usato. Best Regards /i migliori saluti, Andy Townsend (SomeoneElse), on behalf of the OSM Data Working Group (1) http://www.openstreetmap.org/changeset/29645361 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)
Bonjour, Sans vous raconter ma vie, j'avais 3h de correspondance à perdre à Paris ce dimanche, et je me suis retrouvé au salon du tourisme nature ou un truc de ce genre au Parc des Expositions. Et finalement, j'ai regretté de n'avoir eu que ce temps-là, je pense que j'aurais pu y passer une journée… Pour en venir au fait, forcément, le stand FFRandonnée est bien grand, avec du monde pour discuter (ou rigoler de l'absence de topoguide de la crête des Vosges/GR5… mais ça avance… depuis 2 ans, oui… mais ça avance…). Bon, le sujet qui me fait rire, la revendication de propriété intellectuelle sur les itinéraires de GR, dont la Fédération promettait une réponse pour fin 2014 (https://twitter.com/cq94/status/474838237778026496, Christian, tu sais qui s'était engagé ?) et qui n'a rien donné (https://twitter.com/cq94/status/550692276205531136). Bon, le petit jeune croisé en premier me dira tout de suite qu'il est au bas de l'échelle (ses mots, pas les miens). J'abandonne ? Ho, pas tout de suite, j'aime rigoler… Un plus âgé, qui se cache au fond : « Pas de propriété intellectuelle, on met à disposition… mais faudrait quand même pas que des gens puissent gagner de l'argent avec… Vous savez, on a un service juridique, il saura mieux vous répondre, je vais la chercher… ». Alors ça, par contre, c'est top, il y a des gens du service juridique sur le salon ! Attention, je précise que je ne prononce pas le mot OSM, je n'oriente pas la discussion. La personne rencontrée évoque très rapidement l'arrêt de cour de cassation de 1998 (?) qui confirme l'originalité d'un itinéraire. Elle évoque les dépenses et le travail de la FFR. Et elle crache le mot OpenStreetMap (maintenant, j'ai découvert ce que c'est que de cracher des mots), « il faut pas croire, il y a aussi des contraintes quand on utilise leurs données (j'essaye de creuser, j'arrive pas à lui en faire dire plus sur ces contraintes). Puis Base Rando, mise à disposition ? grosses dépenses ? Modèle économique ? À inventer ? « Il y aura des mises à dispositions avec l'IGN ». Sous quelle forme ? Réutilisable ? « Allez les voir, ils sont à coté » (et laissez moi tranquille, je crois aussi). Demandé sous cette forme, je vais les voir de sa part, sans scrupule d'aborder des sujets délicats (et d'avoir des réponses, en plus !). L'IGN travaille/propose un service loisir (je ne sais pas s'il tourne déjà ou en construction avancée), y système à la CIRKWI, développé avec Cirkwi (code en commun, interopérabilité, circuits proposables par tous). Base Rando ? Gros volume de données promis pour fin 2015… mais ce sera en fait 50 itinéraires, 3 par départements sur les départements qui ont de la donnée… Et probablement rien de plus pour 2015, et pas très optimiste pour la suite : données au tronçon, pas à l'itinéraire, efficacité du relevé, de la saisie. La FFR a formé beaucoup de monde, mais vu depuis l'IGN, apparemment pas beaucoup de résultats. Et pas forcément de mise à disposition, y compris à travers le portail de l'IGN (les PDIPR, en gros, et elle garde le reste pour elle ?). Et pour la route, le train n'attend pas : et le MNT de l'IGN, il sera libéré ? « on ne connait pas encore la vision du nouveau directeur… ». Bon, hors sujet maintenant. Distribution gratuite de Rando Passion, le magazine de la FFR : même eux ne payent plus l'IGN pour représenter les itinéraires des circuits proposés ! Idem sur le stand de Balade. En gros, maintenant, pour représenter une rando, on met un vague ombrage, même pas forcément de CLC par dessous, 3 sommets autours, et une grosse trace GPS pour donner une impression de complétude… Par contre, pour aller randonner avec ça… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Oneway vs access=no
Il 03/23/2015 02:22 PM, Luca Sigfrido Percich scrisse: scusami, non avevo capito bene. Sempre da ignorante della situazione locale a cui ti riferisci, direi che se troviamo entrambi i segnali - accesso e direzione - allora metterei sia access che turn restriction, come hai fatto tu, in modo da rispettare al massimo la situazione reale. Senza voler riaprire un thread recente che spero tu non abbia seguito [ :-) ], le turn restriction non hanno necessariamente corrispondenza con la segnaletica esistente. Anzi in molti casi viene consigliato di non inserire turn restriction quando le restrizioni sono implicite (ad esempio perche' una way e' a senso unico). ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-be] Local chapter OSMF
Great news! Of course it seems a logical step to link to the OSMF internationally, this might create new opportunities, not only in ways of funding OSM-be, but also in knowledge and creating a network on a Global and European level. I’m not a big hero on legal aspects, but if you can use my help in writing the proposal, than good :) . PJ Pieter-Jan Pauwels Community Coordinator, Open Knowledge Belgium m: +32 476 66 27 77 tel:+32 476 66 27 77 | e: pieter-jan.pauw...@okfn.org mailto:pieter-jan.pauw...@okfn.org | w: okfn.be http://okfn.be/ On 23 Mar 2015, at 12:31, Nicolas Pettiaux nico...@pettiaux.be wrote: Le Lun 23 mars 2015 12:15, Ben Abelshausen a écrit : Hi, On Mon, Mar 23, 2015 at 12:08 PM, Sander Deryckere sander...@gmail.com wrote: Will OFKN as a VZW be the local chapter? Will it be a part of OFKN, or a new VZW? I guess it needs to be some sort of organisation. Thanks for an actual question! :-) The plan is that nothing will change, we will still be a working group in Open Knowledge Belgium but also a local chapter. As I read the new requirements of a local chapter this is perfectly ok. It used to be the case that we would have to be a seperate VZW focused on only OSM but that has changed. +1 I am completely in favor of such a work and I am ready to contribute as much as I can Thanks, Nicolas -- Nicolas Pettiaux - nico...@pettiaux.be Soutenons april.org , framasoft.org et laquadrature.net ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-it] Deletion of relations in Sicily / Di eliminazione delle relazioni in Sicilia
2015-03-23 14:34 GMT+01:00 SomeoneElse li...@atownsend.org.uk: http://www.openstreetmap.org/changeset/29645361 Thank you, Andy, for pointing us to this. The user has opened this account just 2 days ago, but it looks as if it is an experienced user. Already the fact that s/he tries to hide his/her real nickname is a bit strange. New users typically don't come to OSM and delete 600+ relations of the same type in a big area (IMHO qualifies very likely as an automated edit and guidelines apply). Cheers, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] How to report spam/abuse on the wiki?
On Sun, Mar 22, 2015 at 11:51 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
On 03/23/2015 06:20 AM, Bryce Nesbitt wrote:
I noted a spam post to the wiki ( User:BrookMcIlvain ).
How do I report that?
Well the standard procedure would be replacing the page content with
{{Delete|Spam}}. That takes care of the spam, and then a Wiki admin
might or might not look at deletion requests from time to time and
actually remove the page.
In this particular case it was a user profile, so I could not add
{{Delete|Spam}}
More generally, is there a way to write a message a wiki admin may see, in the
case where the matter may be more subtle than a simple spam delete?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Ja, folgendes habe ich zu meinem Entsetzen auch bemerkt: [...] Außerdem hat er nicht mal die Definitionen im Wiki gelesen (z.B. dass grade1 auch unpaved sein kann). Ich selbst trage z.B. die surface=* nie ein (und ändere eigentlich auch nicht), aber in meinem Kopf ist festverdrahtet - vielleicht falsch, aber so ist es halt - surface=unpaved gleichgesetzt mit surface=fine_gravel, sprich eine gute, relativ schnell befahrbare, meist frei zugängliche Waldstraße. Und das Mappe ich halt ausgerechnet mit tracktype=grade1. Er hat mir mittlerweile beantwortet. Ich werde ihm diese meine Sichtweise oben in einer privaten Nachricht schildern. Ob das ganze zum reverten ist, kann ich nicht beurteilen. Wäre sicherlich am einfachsten, klingt für mich persönlich aber etwas brutal. Wenn viele sich als betroffen melden, wird es dann klarer. Wenn vieles kaputt gegangen ist - ist ja DACH betroffen - wird es eh hohe Wellen schlagen. Was ich vorerst machen werde: Analysieren, wie sich das auf die tracks um Leoben (wo ich halt bin) ausgewirkt hat. Das kann ich aber erst gegen Mitternacht tun. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)
Quelle énergie perdue à recréer une version privatisée de données de plus en plus accessible à tous et toutes. L'investissement pour une fédération est énorme et le retour très hypothétique. Cette logique de marchandisation et de rente touche à sa fin, on est maintenant dans une logique de services. So XXème siècle ;) Le 23/03/2015 15:01, JB a écrit : Bonjour, Sans vous raconter ma vie, j'avais 3h de correspondance à perdre à Paris ce dimanche, et je me suis retrouvé au salon du tourisme nature ou un truc de ce genre au Parc des Expositions. Et finalement, j'ai regretté de n'avoir eu que ce temps-là, je pense que j'aurais pu y passer une journée… Pour en venir au fait, forcément, le stand FFRandonnée est bien grand, avec du monde pour discuter (ou rigoler de l'absence de topoguide de la crête des Vosges/GR5… mais ça avance… depuis 2 ans, oui… mais ça avance…). Bon, le sujet qui me fait rire, la revendication de propriété intellectuelle sur les itinéraires de GR, dont la Fédération promettait une réponse pour fin 2014 (https://twitter.com/cq94/status/474838237778026496, Christian, tu sais qui s'était engagé ?) et qui n'a rien donné (https://twitter.com/cq94/status/550692276205531136). Bon, le petit jeune croisé en premier me dira tout de suite qu'il est au bas de l'échelle (ses mots, pas les miens). J'abandonne ? Ho, pas tout de suite, j'aime rigoler… Un plus âgé, qui se cache au fond : « Pas de propriété intellectuelle, on met à disposition… mais faudrait quand même pas que des gens puissent gagner de l'argent avec… Vous savez, on a un service juridique, il saura mieux vous répondre, je vais la chercher… ». Alors ça, par contre, c'est top, il y a des gens du service juridique sur le salon ! Attention, je précise que je ne prononce pas le mot OSM, je n'oriente pas la discussion. La personne rencontrée évoque très rapidement l'arrêt de cour de cassation de 1998 (?) qui confirme l'originalité d'un itinéraire. Elle évoque les dépenses et le travail de la FFR. Et elle crache le mot OpenStreetMap (maintenant, j'ai découvert ce que c'est que de cracher des mots), « il faut pas croire, il y a aussi des contraintes quand on utilise leurs données (j'essaye de creuser, j'arrive pas à lui en faire dire plus sur ces contraintes). Puis Base Rando, mise à disposition ? grosses dépenses ? Modèle économique ? À inventer ? « Il y aura des mises à dispositions avec l'IGN ». Sous quelle forme ? Réutilisable ? « Allez les voir, ils sont à coté » (et laissez moi tranquille, je crois aussi). Demandé sous cette forme, je vais les voir de sa part, sans scrupule d'aborder des sujets délicats (et d'avoir des réponses, en plus !). L'IGN travaille/propose un service loisir (je ne sais pas s'il tourne déjà ou en construction avancée), y système à la CIRKWI, développé avec Cirkwi (code en commun, interopérabilité, circuits proposables par tous). Base Rando ? Gros volume de données promis pour fin 2015… mais ce sera en fait 50 itinéraires, 3 par départements sur les départements qui ont de la donnée… Et probablement rien de plus pour 2015, et pas très optimiste pour la suite : données au tronçon, pas à l'itinéraire, efficacité du relevé, de la saisie. La FFR a formé beaucoup de monde, mais vu depuis l'IGN, apparemment pas beaucoup de résultats. Et pas forcément de mise à disposition, y compris à travers le portail de l'IGN (les PDIPR, en gros, et elle garde le reste pour elle ?). Et pour la route, le train n'attend pas : et le MNT de l'IGN, il sera libéré ? « on ne connait pas encore la vision du nouveau directeur… ». Bon, hors sujet maintenant. Distribution gratuite de Rando Passion, le magazine de la FFR : même eux ne payent plus l'IGN pour représenter les itinéraires des circuits proposés ! Idem sur le stand de Balade. En gros, maintenant, pour représenter une rando, on met un vague ombrage, même pas forcément de CLC par dessous, 3 sommets autours, et une grosse trace GPS pour donner une impression de complétude… Par contre, pour aller randonner avec ça… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)
Merci JB pour ce moment de détente. Romain Le 23 mars 2015 15:01, JB jb...@mailoo.org a écrit : Bonjour, Sans vous raconter ma vie, j'avais 3h de correspondance à perdre à Paris ce dimanche, et je me suis retrouvé au salon du tourisme nature ou un truc de ce genre au Parc des Expositions. Et finalement, j'ai regretté de n'avoir eu que ce temps-là, je pense que j'aurais pu y passer une journée… Pour en venir au fait, forcément, le stand FFRandonnée est bien grand, avec du monde pour discuter (ou rigoler de l'absence de topoguide de la crête des Vosges/GR5… mais ça avance… depuis 2 ans, oui… mais ça avance…). Bon, le sujet qui me fait rire, la revendication de propriété intellectuelle sur les itinéraires de GR, dont la Fédération promettait une réponse pour fin 2014 (https://twitter.com/cq94/status/474838237778026496, Christian, tu sais qui s'était engagé ?) et qui n'a rien donné ( https://twitter.com/cq94/status/550692276205531136). Bon, le petit jeune croisé en premier me dira tout de suite qu'il est au bas de l'échelle (ses mots, pas les miens). J'abandonne ? Ho, pas tout de suite, j'aime rigoler… Un plus âgé, qui se cache au fond : « Pas de propriété intellectuelle, on met à disposition… mais faudrait quand même pas que des gens puissent gagner de l'argent avec… Vous savez, on a un service juridique, il saura mieux vous répondre, je vais la chercher… ». Alors ça, par contre, c'est top, il y a des gens du service juridique sur le salon ! Attention, je précise que je ne prononce pas le mot OSM, je n'oriente pas la discussion. La personne rencontrée évoque très rapidement l'arrêt de cour de cassation de 1998 (?) qui confirme l'originalité d'un itinéraire. Elle évoque les dépenses et le travail de la FFR. Et elle crache le mot OpenStreetMap (maintenant, j'ai découvert ce que c'est que de cracher des mots), « il faut pas croire, il y a aussi des contraintes quand on utilise leurs données (j'essaye de creuser, j'arrive pas à lui en faire dire plus sur ces contraintes). Puis Base Rando, mise à disposition ? grosses dépenses ? Modèle économique ? À inventer ? « Il y aura des mises à dispositions avec l'IGN ». Sous quelle forme ? Réutilisable ? « Allez les voir, ils sont à coté » (et laissez moi tranquille, je crois aussi). Demandé sous cette forme, je vais les voir de sa part, sans scrupule d'aborder des sujets délicats (et d'avoir des réponses, en plus !). L'IGN travaille/propose un service loisir (je ne sais pas s'il tourne déjà ou en construction avancée), y système à la CIRKWI, développé avec Cirkwi (code en commun, interopérabilité, circuits proposables par tous). Base Rando ? Gros volume de données promis pour fin 2015… mais ce sera en fait 50 itinéraires, 3 par départements sur les départements qui ont de la donnée… Et probablement rien de plus pour 2015, et pas très optimiste pour la suite : données au tronçon, pas à l'itinéraire, efficacité du relevé, de la saisie. La FFR a formé beaucoup de monde, mais vu depuis l'IGN, apparemment pas beaucoup de résultats. Et pas forcément de mise à disposition, y compris à travers le portail de l'IGN (les PDIPR, en gros, et elle garde le reste pour elle ?). Et pour la route, le train n'attend pas : et le MNT de l'IGN, il sera libéré ? « on ne connait pas encore la vision du nouveau directeur… ». Bon, hors sujet maintenant. Distribution gratuite de Rando Passion, le magazine de la FFR : même eux ne payent plus l'IGN pour représenter les itinéraires des circuits proposés ! Idem sur le stand de Balade. En gros, maintenant, pour représenter une rando, on met un vague ombrage, même pas forcément de CLC par dessous, 3 sommets autours, et une grosse trace GPS pour donner une impression de complétude… Par contre, pour aller randonner avec ça… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Local chapter OSMF
On Mon, Mar 23, 2015 at 11:45 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: I think it's our job to ask feedback before doing this. So my question is now, is there anybody not happy with us spending our time on this? Everybody is free to do what (s)he wants, not ? :-) As long as I don't have to spend time on doing it, it's fine for me regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Local chapter OSMF
Hi, On Mon, Mar 23, 2015 at 12:08 PM, Sander Deryckere sander...@gmail.com wrote: Will OFKN as a VZW be the local chapter? Will it be a part of OFKN, or a new VZW? I guess it needs to be some sort of organisation. Thanks for an actual question! :-) The plan is that nothing will change, we will still be a working group in Open Knowledge Belgium but also a local chapter. As I read the new requirements of a local chapter this is perfectly ok. It used to be the case that we would have to be a seperate VZW focused on only OSM but that has changed. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Recherche avec orthographe approximative
Essaye aussi ton orthographe sur: https://adresse.data.gouv.fr/map/ c'est aussi libre et aussi basé sur OSM (BANO) Le projet (python/redis) est ici: https://github.com/etalab/addok Le 23/03/2015 19:37, Simon a écrit : Enfin une recherche d'adresse pour ceux qui on de gros souci d'orthographe comme moi http://jdf.geovelo.fr/ Si je recherche la rue sun onore, pari il me trouve bien la Rue Saint-Honoré, Paris en plus c'est libre et c'est basé sur OSM Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Deletion of relations in Sicily / Di eliminazione delle relazioni in Sicilia
Hi On 23 March 2015 at 16:31, Martin Koppenhoefer dieterdre...@gmail.com wrote: Thank you, Andy, for pointing us to this. The user has opened this account just 2 days ago, but it looks as if it is an experienced user. Already the fact that s/he tries to hide his/her real nickname is a bit strange. New users typically don't come to OSM and delete 600+ relations of the same type in a big area (IMHO qualifies very likely as an automated edit and guidelines apply). the user answer to the changeset comment, he was sure about removal of the relations, some Sicilian guys can check if he answer the true or not, for me seems really strange to remove more than 600 relation... maybe a revert could be useful? Cheers, Martin -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] FFRandonnée − de quoi rire encore un moment (jaune ?)
Dans une certaine mesure, je ne sais pas s'il est possible de cartographier le support des marques des itinéraires de randonnée. Au final, on obtient une carte avec des points successifs que le randonneur connecte mentalement pour trouver l'itinéraire. Concernant les contraintes d'OSM, oui, il y en a : il faut citer la source et ouvrir les modifications sous la même licence. C'est rigolo, j'ai l'impression de revoir le match Encarta/Universalis/Wikipédia mais pour la cartographie : tout ce qui n'est pas encore saisi le sera de toutes façons tôt ou tard. Merci pour cette anecdote, et dommage que la correspondance n'aie pas été plus longue :) 2015-03-23 16:56 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Quelle énergie perdue à recréer une version privatisée de données de plus en plus accessible à tous et toutes. L'investissement pour une fédération est énorme et le retour très hypothétique. Cette logique de marchandisation et de rente touche à sa fin, on est maintenant dans une logique de services. So XXème siècle ;) Le 23/03/2015 15:01, JB a écrit : Bonjour, Sans vous raconter ma vie, j'avais 3h de correspondance à perdre à Paris ce dimanche, et je me suis retrouvé au salon du tourisme nature ou un truc de ce genre au Parc des Expositions. Et finalement, j'ai regretté de n'avoir eu que ce temps-là, je pense que j'aurais pu y passer une journée… Pour en venir au fait, forcément, le stand FFRandonnée est bien grand, avec du monde pour discuter (ou rigoler de l'absence de topoguide de la crête des Vosges/GR5… mais ça avance… depuis 2 ans, oui… mais ça avance…). Bon, le sujet qui me fait rire, la revendication de propriété intellectuelle sur les itinéraires de GR, dont la Fédération promettait une réponse pour fin 2014 (https://twitter.com/cq94/status/474838237778026496, Christian, tu sais qui s'était engagé ?) et qui n'a rien donné (https://twitter.com/cq94/status/550692276205531136). Bon, le petit jeune croisé en premier me dira tout de suite qu'il est au bas de l'échelle (ses mots, pas les miens). J'abandonne ? Ho, pas tout de suite, j'aime rigoler… Un plus âgé, qui se cache au fond : « Pas de propriété intellectuelle, on met à disposition… mais faudrait quand même pas que des gens puissent gagner de l'argent avec… Vous savez, on a un service juridique, il saura mieux vous répondre, je vais la chercher… ». Alors ça, par contre, c'est top, il y a des gens du service juridique sur le salon ! Attention, je précise que je ne prononce pas le mot OSM, je n'oriente pas la discussion. La personne rencontrée évoque très rapidement l'arrêt de cour de cassation de 1998 (?) qui confirme l'originalité d'un itinéraire. Elle évoque les dépenses et le travail de la FFR. Et elle crache le mot OpenStreetMap (maintenant, j'ai découvert ce que c'est que de cracher des mots), « il faut pas croire, il y a aussi des contraintes quand on utilise leurs données (j'essaye de creuser, j'arrive pas à lui en faire dire plus sur ces contraintes). Puis Base Rando, mise à disposition ? grosses dépenses ? Modèle économique ? À inventer ? « Il y aura des mises à dispositions avec l'IGN ». Sous quelle forme ? Réutilisable ? « Allez les voir, ils sont à coté » (et laissez moi tranquille, je crois aussi). Demandé sous cette forme, je vais les voir de sa part, sans scrupule d'aborder des sujets délicats (et d'avoir des réponses, en plus !). L'IGN travaille/propose un service loisir (je ne sais pas s'il tourne déjà ou en construction avancée), y système à la CIRKWI, développé avec Cirkwi (code en commun, interopérabilité, circuits proposables par tous). Base Rando ? Gros volume de données promis pour fin 2015… mais ce sera en fait 50 itinéraires, 3 par départements sur les départements qui ont de la donnée… Et probablement rien de plus pour 2015, et pas très optimiste pour la suite : données au tronçon, pas à l'itinéraire, efficacité du relevé, de la saisie. La FFR a formé beaucoup de monde, mais vu depuis l'IGN, apparemment pas beaucoup de résultats. Et pas forcément de mise à disposition, y compris à travers le portail de l'IGN (les PDIPR, en gros, et elle garde le reste pour elle ?). Et pour la route, le train n'attend pas : et le MNT de l'IGN, il sera libéré ? « on ne connait pas encore la vision du nouveau directeur… ». Bon, hors sujet maintenant. Distribution gratuite de Rando Passion, le magazine de la FFR : même eux ne payent plus l'IGN pour représenter les itinéraires des circuits proposés ! Idem sur le stand de Balade. En gros, maintenant, pour représenter une rando, on met un vague ombrage, même pas forcément de CLC par dessous, 3 sommets autours, et une grosse trace GPS pour donner une impression de complétude… Par contre, pour aller randonner avec ça… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] ?
Le lundi 23 mars 2015, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Le 19 mars 2015 17:38, Jérôme Amagat jerome.ama...@gmail.com javascript:_e(%7B%7D,'cvml','jerome.ama...@gmail.com'); a écrit : Bonjour, Quel tag pour une forêt communale ou domaniale ? ( le problème avec landuse=forest c'est que ça veux dire que la forêt est partout à l’intérieur mais c'est pas sûr pour une forêt communale ou domaniale) Que veux-tu dire par c'est que ça veux dire que la forêt est partout à l’intérieur mais c'est pas sûr pour une forêt communale ou domaniale? Ce que je veux dire c'est qu'il peut il y avoir des clairières, des zones plus ou moins grandes sans arbre à l'intérieur de l'emprise de la forêt communale. Avec landuse= forest ça voudrait dire qu'il y a des arbres partout. c'est quoi une piscine dans osm? pour moi c'est soit un bassin plein d'eau soit un lieu ou l'on va pour se tremper dans un bassin plein d'eau. ça se traduit comment dans osm? (amenity ou leisure, swimming pool ou sport_centre). Leisure est maintenant plus utilisé que amenity cf. http://wiki.openstreetmap.org/wiki/FR:Tag:leisure%3Dswimming_pool Mà question c'est plus sur la différence entre un basin ou il faut leisure= swimming pool et le lieu ou il y a 1 ou plusieurs basins et ou l'on paye pour entrer et avoir le droit de se baigner. Sur l'emprise bâtiments plus basin met on leisure= swimming pool avec d'autres swimming pool à l'intérieur. C'est écrit ça sur la page anglaise: Use leisure http://wiki.openstreetmap.org/wiki/Key:leisure=sports_centre http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsports_centre for a fenced or covered area which may include one or more swimming pools perhaps in combination with a sports hall, pitches, courts, a gym, fitness studio, etc. Mais si c'est combiner avec rien Tout le monde sait ce que c'est un château ou une école par exemple. Mais quand on veux les indiquer sous forme d'area dans osm, qu'est ce qu'on met dedans? Là c'est ton interprétation qui considère que château ou école désigne un bâtiment or à mon sens c'est bien tout ce qui est en relation. Donc représenter une école c'est englober la cour... et un château ce sont un éventuel parc et les dépendances... Et la plupart du temps, l'aire est facile à identifier, il n'y a qu'à suivre les contours des murs ou grilles. C'est souvent tager sur le bâtiment (sûrement vu que c'est le plus simple) pour ces 2exemples château et Ecole. Moi pour l'école je met bâtiment plus cour de l'école pour les enfants. Pour le château je sais pas trop ça dépend des fois. Pour un château, c'est juste un bâtiment ou on va jusqu’à un éventuel mur, avec ou sans jardin, allée... Pour une école : salle de classe, cour, allée, parking Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Incrocio di strada con pista nciclopedonale
è una pista ciclopedonale con sedi separate o combinate? strano che il semaforo è solo per bici, e i pedoni attraversano quando gli pare? comunque per ora i tag dovrebbero essere highway=traffic_signals bicycle=yes non scrivo crossing=traffic_signals poichè mi dici che non è un semaforo per pedoni ci sono le strisce per l'attraversamento pedonale? Il 21/03/2015 22:44, flaviano.ghe...@libero.it ha scritto: Sto mappando una pista ciclo-pedonale che ad un incrocio con strada laterale presenta un semaforo per gli utenti ciclisti della pista. Come devo segnalarlo nella mappa? Grazie. (Flaviano Ghedin: ultimo chilometro) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-br] Restrição de Manobra em U
Se por acaso encontrar alguma destas em Recife, deve ter sido eu mesmo que inseri. Vi um exemplo pre-existente e espalhei o erro. Mea Culpa. Em 23 de março de 2015 15:15, Oéslei Taborda Ribas oesleiri...@gmail.com escreveu: Olá Pessoal, Terminei de corrigir os erros de roundabout reportados em [1]. Analisando os outros arquivos de erros disponibilizados por esse sites, encontrei vários erros como esse: 2015/03/23 01:12:52 WARNING (RestrictionRelation): 55137017.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/relation/3924718 (at http://www.openstreetmap.org/?mlat=-20.415043mlon=-42.900811zoom=17) no_u_turn with equal 'from' and 'to' way and via node is ignored Pelo que eu vi estão sendo criadas restrições de manobra em U nas quais a origem e o destino são os mesmos. Seria algo como: proibido retornar na mesma via. Penso que essas restrições realmente não sejam necessárias, pelos motivos abaixo: A) Geralmente restrições de manobra em U ocorrem quando existem duas vias paralelas em sentidos opostos e uma terceira via perpendicular ligando elas. Assim sinaliza-se que não é permitido usar a via perpendicular para fazer um retorno entre as vias opostas. Agora placa sinalizando que não é permitindo retornar na mesma via eu não me lembro de ter visto, o que também seria mais próximo de uma manobra em I do que uma manobra em U... rsss B) Se for levar ao pé da letra, nesse caso o pé da lei [2], é proibido retornar na mesma via quando está sobre: pontes, viadutos, túneis, aclives, declives, curvas e também em vias com faixas amarelas duplas continuas. Imagine mapear todos esses locais com restrições de manobra em “U”, seria insano, além do que o mapa viraria uma “Colcha de Retalhos”. C) Mesmo sem essas restrições, nos GPSs que usei até hoje não me lembro do GPS ter sugerido esse tipo de manobra, algo como faça retorno na mesma via, geralmente ele pede que você siga até um cruzamento e faça um retorno na quadra. Assim acredito que o próprio software do GPS evite sugerir manobras desse gênero. D) Pelas mensagens do Mkgmap essas restrições estão sendo ignoradas, acredito que procedimento semelhante deva ser feito por outros compiladores, assim na prática essas restrições de manobram não tem muita utilidade visto que o próprio compilador está ignorando essas informações. Procurando na internet encontrei esse ticket [3] no iD, sugerindo que seja desabilitada a opção de criar manobras como essa. Concordo com tudo que foi dito pelos usuários brasileiros no ticket, principalmente a parte que diz que a interface do iD está induzindo os usuários a criar essas restrições mesmo não sendo necessárias. Estava pensando em deletar essas restrições, pelos motivos acima expostos, porém antes de fazer isso gostaria de saber se vocês veem algum problema nisso? [1] - http://mapas.alternativaslibres.es/errors_Brazil.zip [2] - http://www.ctbdigital.com.br/?p=ComentariosRegistro=78campo_busca=artigo=206 [3] - https://github.com/openstreetmap/iD/issues/2527 Att Oéslei. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- São Pedro recebe Seu Lunga no céu perguntando: Morreu, Seu Lunga? Não, vim passar o Natal! ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrição de Manobra em U
Mostrando este erro do mkgmap no meu opinião totalmente matar o argumento do fazer este tipo do no_u_turn. On 3/23/15, Nelson A. de Oliveira nao...@gmail.com wrote: 2015-03-23 15:15 GMT-03:00 Oéslei Taborda Ribas oesleiri...@gmail.com: Estava pensando em deletar essas restrições, pelos motivos acima expostos, porém antes de fazer isso gostaria de saber se vocês veem algum problema nisso? Não tem cara de que vão mudar isso no iD. Se o nó com função via não for um mini_roundabout ou algum objeto que indica separação de via (como traffic_calming=island), não precisa ter no_u_turn. Teve uma discussão sobre isso no meio desse tópico https://lists.openstreetmap.org/pipermail/talk-br/2015-February/thread.html#9447 (erros x relações) também. Por mim pode apagar a relação. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
I agree 100% with Bryce. - Serge On Mon, Mar 23, 2015 at 12:29 PM, Bryce Nesbitt bry...@obviously.com wrote: The nice thing about mapping a neighborhood name as a point feature is: a) It helps people locate the neighborhood b) it completely sidesteps the question of the exact, possibly fuzzy, boundaries. For 10% of the hassle you map 90% of the benefit. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-it] Oneway vs access=no
Il 23 marzo 2015 09:09, Luca Sigfrido Percich luca.perc...@gmail.com ha scritto: sono incappato in diversi usi di oneway per taggare strade in cui un senso di marcia è riservato ai psv. Non è corretto. Eppure il wiki lo riporta come esempio proprio sulla pagina della key access. «oneway=yes + psv=opposite_lane The street is one way for cars but there is one opposite lane for buses and taxis.» Perché dici che non è corretto? E' giusto come avete fatto tu ed AnyFile nel tuo esempio: https://www.openstreetmap.org/way/333995756 oneway=no access=no foot=yes bicycle:backward=yes emergency:backward=yes taxi:backward=yes vehicle:forward=yes Quindi è vietato l'accesso a cavallo in entrambe le direzioni? Forse avrei semplificato l'accesso per le bici con: oneway=no access=no foot=yes bicycle=yes emergency:backward=yes taxi:backward=yes motor_vehicle:forward=yes Questo oltre a vietare l'accesso a cavallo vieta anche il carretto a mano. ma solo perché mi sembra di più immediata lettura per un umano :) - non mi è chiaro se ci siano delle regole precise sulla modalità di espressione di access in casi come questo. Come già detto esprimono concetti diversi: va solo descritta la realtà, non inventata :) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-dk] hvad er rundkørsler?
Hvad er vores kriterier for rundkørsler? En rundkørsels er ikke noget der eksisterer i færdselsloven, men der må kræves to samtidigt. Du har A) en cirkulær vej hvor start og slutpunkt er det samme og B) påbudstavle D12 (samt D11) ved indkørslen på vejen. http://www.openstreetmap.org/way/8120345 Ligner noget der kan være konverteret til en privat fællesvej. Så er det ikke nødvendigvis en rundkørsel, men en parkeringsplads/vendeplads. http://www.openstreetmap.org/way/192952657 Er næppe en rundkørsel. Det ligner en vejforskønnelse som bruges til optimering af parkeringspladsområde. Bør undersøges IRL. http://www.openstreetmap.org/way/146702887 Ligner en kombineret parkeringsplads/vendeplads hvor du må køre begge veje rundt, omend du nok kommer til at møde en del had fra de der kører højre rundt. I alle tre tilfælde vil det dog ikke rigtigt gøre det store om vi taggede som rundkørsler eller ej. Veje kan også naturlig være ensrettet, for eksempel når en vej bliver splittet med et midterrabat. Det bør altid være anvist med et D11 påbudsskilt? Alternativ en helle, som det snart er 10 år siden jeg så sidst. Med venlig hilsen Rasmus Vendelboe 2015-03-21 21:48 GMT+01:00 Niels Elgaard Larsen elga...@agol.dk: Hvad er vores kriterier for rundkørsler? som fx: http://www.openstreetmap.org/way/8120345 http://www.openstreetmap.org/way/192952657 http://www.openstreetmap.org/way/146702887 Jeg tror ikke, at de er skiltet som rundkørsler. Og måske ikke engang som ensrettede. På den anden side tror jeg, at man kunne komme i problemer, hvis man fulgte OSM og troede, at man kunne køre venstre om. -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-br] Restrição de Manobra em U
2015-03-23 15:15 GMT-03:00 Oéslei Taborda Ribas oesleiri...@gmail.com: Estava pensando em deletar essas restrições, pelos motivos acima expostos, porém antes de fazer isso gostaria de saber se vocês veem algum problema nisso? Não tem cara de que vão mudar isso no iD. Se o nó com função via não for um mini_roundabout ou algum objeto que indica separação de via (como traffic_calming=island), não precisa ter no_u_turn. Teve uma discussão sobre isso no meio desse tópico https://lists.openstreetmap.org/pipermail/talk-br/2015-February/thread.html#9447 (erros x relações) também. Por mim pode apagar a relação. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-it] Incrocio di strada con pista nciclopedonale
2015-03-23 18:13 GMT+01:00 Fabri erfab...@gmail.com: non scrivo crossing=traffic_signals poichè mi dici che non è un semaforo per pedoni Riporto di seguito alcuni estratti della wiki, in particolare della pagina che ho linkato prima. This tag [highway=crossing] is used for more accurately describing specific types of pedestrian crossings across roads, and other types of crossing over road or rail. Crossing infrastructure for the convenience of pedestrians, cyclists etc. should first be tagged with highway=crossing or railway=crossing as appropriate. The specific type of crossing may be further specified with the crossing=* tag and other properties described below. Quindi anche gli attraversamenti ciclabili possono essere mappati con highway=crossing. crossing=traffic_signals Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights. Quindi il crossing=traffic_signals può essere usato anche per gli attraverssamenti ciclabili e non solo per quelli pedonali. Il tag highway=traffic_signals invece indica espressamente un semaforo per le macchine, non per pedoni o ciclisti. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Hi, On 03/23/2015 12:59 PM, borut.mari...@borut.eu wrote: Ist es euch bekannt, ob diese Edits vorher auf einer der talk-DACH Mailinglisten durchdiskutiert worden sind? Wurden sie nicht, und daher werden die Edits jetzt von mir revertiert. Wir haben nicht viele Regeln, aber undiskutierte automatische Edits sind eine Sache, gege die wir eine Regel haben ;) Meiner Meinung nach wäre es besser, in einem beliebigen Qualitätstool einen Check surface passt nicht zu tracktype einzubauen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Recherche avec orthographe approximative
L'outil est intéressant. Il y aurait sûrement intérêt à perfectionner un tel outil. Nominatim est peu performant pour les recherches. 1 couverture Est-il possible que cet outil ne couvre que la France? Recherche Montreal, par exemple, ne retourne pas Montréal, Québec. C'est plus grand que Montréal-en-Gers quand même! 2. recherche autre qu'a partir du début de l'expression La recherche est intéressante si je donne les infos à partir du début. Y ajouter la recherche n'importe où dans le texte rendrait cet outil encore beaucoup plus performant.Exemplest-symforien me renvoi comme réponse Saint-Symphorien symforien ne me renvoi pas Saint-Symphorien Pierre De : Simon msr...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi 23 mars 2015 14h37 Objet : [OSM-talk-fr] Recherche avec orthographe approximative Enfin une recherche d'adresse pour ceux qui on de gros souci d'orthographe comme moi http://jdf.geovelo.fr/Si je recherche la rue sun onore, pari il me trouve bien la Rue Saint-Honoré, Paris en plus c'est libre et c'est basé sur OSM Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-dk] Brudte kystlinjer på Drejø
Hej Anders, Jeg har i tidens løb pillet en del ved kystlinjerne og rettet op på dem. De oprindelige er tagget med PGS og importeret i brudstykker af omkring 100-200 noder. Jeg gætter på det har været en optimalt størrelse for en importscript? Generelt er stykkerne tagget med source=PGS af lav kvalitet. Jeg kan se af historikken, at jeg bl.a. har blandet mig på Drejø og at den ene del er tagget med FUGRO og den anden med PGS. Vi (der har rettet i stykket) har sikkert kun rettet op på den ene halvdel da vi var sikre på billedernes overenstemmelse med virkeligheden på den del. Det er helt fint, at rette den anden halvdel til (eller det hele), nu der er ens, nye og konsistente overflyvningsbilleder til rådighed for området Der er to ting du bør have i mente inden du merger andre steder: # Lange veje og veje med uoverskueligt mange noder er svære for andre brugere at udføre QA på. Selv om jeg ikke blander mig så meget mere, kigger jeg stadigvæk med over skulderen. # Veje med mange noder kræver meget load og upload hver gang du rører ved noget. Det giver en unødvendig lang historik hvis uploaderen ikke gør arbejdet ordenligt første gang. I det her tilfælde synes jeg bare du skal rengøre og merge de to stykker. Det vil give fin mening. Med venlig hilsen Rasmus Vendelboe 2015-03-22 11:18 GMT+01:00 Anders Lund and...@alweb.dk: Hej, Drejøs kystlinje er brudt, er der nogen grund til det, eller er det OK at samle den? God forberedelse til at få tilføjet tags, så øen optræder med et navn. Drejø består i øvrigt lige som Avernakø af to øer samlet med et drej. Men hvor der på Avernakø er en menneskeskabt dæmning på drejet, er det på Drejø naturligt landfast. Avernakø har da også to kystlinjer, mens Drejø nok burde bestå af én. Vh, Anders ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[OSM-talk-fr] Rencontre à Paris vendredi 27 mars
Hello Paris, Le rdv du dernier vendredi du mois tient toujours tous les mois ? J'ai rien vu passer pour ce vendredi, je me demande si c'est prévu. Dans ce cas vous vous retrouvez où d'habitude ? ++ PS [Spoiler] : je suis de retour sur Paris et content de retrouver tous les parigos ! -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] How to report spam/abuse on the wiki?
Hi,
On 03/23/2015 06:20 AM, Bryce Nesbitt wrote:
I noted a spam post to the wiki ( User:BrookMcIlvain ).
How do I report that?
Well the standard procedure would be replacing the page content with
{{Delete|Spam}}. That takes care of the spam, and then a Wiki admin
might or might not look at deletion requests from time to time and
actually remove the page.
(There's quite a few pending deletion requests
https://wiki.openstreetmap.org/wiki/Category:Labelled_for_deletion so I
guess Wiki admins are either understaffed or don't think this is very
important.)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
ich bin immer noch fuer cycling=yes in Analogie zu hiking=yes auch als Namespace On 23-Mar-15 08:32, Alexander Heinlein wrote: guidepost:bicycle=yes? Ja diese namespace geschichten sind nicht formal definiert bei OSM aber sie werden an allen ecken und enden verwendet. Namespaces finde ich generell immer die bessere Lösung. Es ist eindeutig worauf sie sich beziehen und Kollisionen sind ausgeschlossen. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Kurt Waldhans +49 2162 89507 mobile +49 172 7033010 k...@waldhans.com ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Rencontre à Paris vendredi 27 mars
Salut vincent ! Dommage que ça soit jeudi, perso je suis chez Mozilla pour le Meetup Open Transport #4 http://www.eventbrite.fr/e/billets-meetup-open-transport-4-16199576369 Je verrai d'ailleurs peut-être certains d'entre vous, qui sait. A bientôt dans tous les cas Le 23 mars 2015 10:38, Vincent de Château-Thierry osm.v...@free.fr a écrit : Salut revenant :) De: Florian LAINEZ winner...@free.fr Hello Paris, Le rdv du dernier vendredi du mois tient toujours tous les mois ? J'ai rien vu passer pour ce vendredi, je me demande si c'est prévu. Dans ce cas vous vous retrouvez où d'habitude ? ++ PS [Spoiler] : je suis de retour sur Paris et content de retrouver tous les parigos ! Depuis le mois dernier on a décalé au dernier _jeudi_. Pas de lieu fixé pour cette fois-ci, mais ça va se préciser dans la journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-lt] OpenStreetMap žemėlapis geoportale
Sveiki geoportal.lt panaudojo OpenStreetMap duomenis užsieniui vaizduoti. Valio :) http://www.geoportal.lt/wps/portal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os_gAQwNnc09LYwMLA3dzA08D8yB_E4NAA3czY_1wkA5kFZaergZG5gaGHpaW7u7-HoYQeQMcwNFA388jPzdVvyA7O83RUVERAATYHL4!/dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfUDEwQzdJOTMwODBHNzBJMDdSTzQwUTAwTzI!/?WCM_GLOBAL_CONTEXT=/wps/wcm/connect/lgii/sa-portalas/sa-aktualijos/sa-naujienos/pagrindo_map_papildytas -- Tomas Straupis ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
O atributinės info nėra? http://wiki.openstreetmap.org/wiki/Legal_FAQ Yra. Paspaudus apačioje ant nuorodos „www.geoportal.lt/copyright“: https://www.geoportal.lt/wps/myportal/copyright randame: Užsienio teritorijos OpenStreetMap žemėlapis OpenStreetMap -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
Nelabai gerai, nes OSM reikalauja kitaip: http://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F Where to put it This credit needs to appear in a place reasonable to the medium you are utilising. In other words, you should expect to credit OpenStreetMap in the same way and with the same prominence as would be expected by any other map supplier. Therefore: For a browsable electronic map (e.g. embedded in a web page or mobile phone application), the credit should appear in the corner of the map, as commonly seen with map APIs/libraries such as Google Maps. 2015.03.23 12:10, Tomas Straupis rašė: O atributinės info nėra? http://wiki.openstreetmap.org/wiki/Legal_FAQ Yra. Paspaudus apačioje ant nuorodos „www.geoportal.lt/copyright“: https://www.geoportal.lt/wps/myportal/copyright randame: Užsienio teritorijos OpenStreetMap žemėlapis OpenStreetMap ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-in] About having a mapping party in Koorachundu Village Panchayat - Kozhikode district - Kerala - Reg.
Hi Jaisen, As someone who's a newcomer to mapping, I've just been introduced to some wonderful possibilities. Thanks so much for documenting the process so extensively, makes for very good reading and learning material. Koorachundu is a beautiful village. On Mon, Mar 23, 2015 at 9:49 AM, Yogesh योगि yog...@karnatakaeducation.org.in wrote: Hi Jaisen, On Saturday 21 March 2015 07:38 PM, Jaisen Nedumpala wrote: Hai, I have written a blog post, about the background, and the need of the mapping experiments held at Koorachundu Village Panchayat. Here is the link: http://blog.smc.org.in/mapping-efforts-in-an-unsurveyed-land-koorachundu/ One of the fine examples of using OSM at the grassroots level. Well documented with nice pictures, will certainly help other local governments engaged in similar efforts. :) Loved the Malayalam map and GNOME being used in Malayalam. :) :) -- Yogesh K S Sent from an Electronic Device ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-us] Mappy Hour tomorrow (monday) night
Should I make the G+ event for it or will that trip things up? On Sun, Mar 22, 2015 at 9:19 PM, Richard Welty rwe...@averillpark.net wrote: in the traditional 8:30pm ET slot - Martijn is traveling so i get to pick the time. i'll post a link here when i have it. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
O atributinės info nėra? http://wiki.openstreetmap.org/wiki/Legal_FAQ On 23 March 2015 at 11:55, Tomas Straupis tomasstrau...@gmail.com wrote: Sveiki geoportal.lt panaudojo OpenStreetMap duomenis užsieniui vaizduoti. Valio :) http://www.geoportal.lt/wps/portal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os_gAQwNnc09LYwMLA3dzA08D8yB_E4NAA3czY_1wkA5kFZaergZG5gaGHpaW7u7-HoYQeQMcwNFA388jPzdVvyA7O83RUVERAATYHL4!/dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfUDEwQzdJOTMwODBHNzBJMDdSTzQwUTAwTzI!/?WCM_GLOBAL_CONTEXT=/wps/wcm/connect/lgii/sa-portalas/sa-aktualijos/sa-naujienos/pagrindo_map_papildytas -- Tomas Straupis ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
Nepanašu, kad būtų įgyvendinti OSM licenzijos reikalavimai. 2015-03-23 12:10 GMT+02:00 Tomas Straupis tomasstrau...@gmail.com: O atributinės info nėra? http://wiki.openstreetmap.org/wiki/Legal_FAQ Yra. Paspaudus apačioje ant nuorodos „www.geoportal.lt/copyright“: https://www.geoportal.lt/wps/myportal/copyright randame: Užsienio teritorijos OpenStreetMap žemėlapis OpenStreetMap -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] OpenStreetMap žemėlapis geoportale
... the credit should appear in the corner of the map ... Iš teisinės pusės gal ir taip. Bet iš praktinės: 1. OpenStreetMap duomenys yra antriniai, t.y. jie nėra esminis dalykas, vaizduojamas žemėlapyje. 2. Žemėlapyje yra labai daug kitų duomenų tiekėjų, visi jie minimi vienoje vietoje, nėra jokių išimčių/išskirtinių tiekėjų. Jei visus tiekėjus kišti į „žemėlapio kampą“ - neliks vietos žemėlapiui. Žinoma galima pulti visus, naudojančius OSM duomenis, ir reikalauti, kad jie vidury žemėlapio riebiu šriftų parašytų „OpenStreetMap rulez“, tik kas ir ką iš to laimės? :-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-de] information=guidepost auf eine kreuzungsnode
Gesendet: Montag, 23. März 2015 um 08:26 Uhr Betreff: Re: [Talk-de] information=guidepost auf eine kreuzungsnode On Sun, Mar 22, 2015 at 06:57:22PM +0100, Alexander Heinlein wrote: Leider macht beispielsweise das JOSM-Preset genau das. Klickt man dort zwei mal auf cycling, dann landet ein bicycle=no am Wegweiser. Das ist ja bei allen Preset-Checkboxen so üblich, führt in diesem Fall aber zu Routing-Problemen. JOSM can mittlerweile das no auch unterdrücken. Kannst ja nach einem enchancement fragen. Ist aber leider auch nur eine halbe Lösung. Wenn man bicycle=no unterdrückt, dann ist nicht mehr ersichtlich, ob der Wegweiser keine Fahrradrouten enthält oder ob es bisher nur niemand eingetragen hat. Nicht vorhandene Beschilderungen für Fahrradrouten können dann einfach nicht mehr gekennzeichnet werden. guidepost:bicycle=yes? Ja diese namespace geschichten sind nicht formal definiert bei OSM aber sie werden an allen ecken und enden verwendet. Namespaces finde ich generell immer die bessere Lösung. Es ist eindeutig worauf sie sich beziehen und Kollisionen sind ausgeschlossen. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Sun, Mar 22, 2015 at 2:04 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: tl;dr: I'm against a blanket rule when it comes to administrative boundaries. They're really nuanced, and so should we. On 2015-03-22 04:32, Serge Wroclawski wrote: Imagine if Bob and Alice conflict on where a neighborhood boundary is inside OSM. The issue escalates to an edit war and the DWG is called in to resolve the conflict. Let's say that Frank is our DWG member. How is Frank supposed to resolve the conflict between Alice and Bob? Often neighborhoods don't have administrative recognition, or administrative recognition is not in alignment with the people. I imagine this would be especially an issue with neighborhoods where lots of the under-represented populations live. This is an important consideration. As I mentioned in a footnote earlier, even a city with strong neighborhood organization can have boundary disputes. However, the problem exists for administrative boundaries in general, all the way up to admin_level=2 boundaries that cut right across ethnic fault lines. My point was that we should map neighborhood boundaries in cities where doing so requires little editorial judgment, thanks to signage, distinctive lamp posts, etc. And we are quite clear (via the tag value administrative) that this isn't the only way by which a community can be delimited. As numerous threads have pointed out, the USPS has very different ideas of location (ZIP codes), but that's OK. When it comes to all our discussions around *administrative* boundaries, I like this two-point test as a rule of thumb: 1. Are people or property governed differently on one side versus the other? 2. Is this distinction observable on the ground? Municipalities generally pass both points. Congressional districts pass #1 but not #2. CDPs generally fail both. School districts can be observed, but not with the granularity required for mapping a boundary. City neighborhoods may pass one, both, or neither. Maybe all the locals you interview can agree on the name of a neighborhood but not its shape -- in which case it should be nothing more than a POI. Which brings me to Serge's other point: First, there are a growing number of people who believe that administrative data is very useful, but breaks OSM's ground observable rule. That is, someone who is present on the ground should be able to observe the data in OSM. It's usually not possible to do that with administrative boundaries. SteveA has responded more forcefully on this point, and so have I in the past. [1] Fortunately, Alice and Bob's disagreement sounds pretty clear-cut. If the city didn't go through the trouble of demarcating any part of the boundary in some way, perhaps the general public shouldn't expect OSM to reproduce their two neighborhoods' boundaries at all. But I see no reason why such a decision would impact boundaries with very different characteristics. tl;dr: I'm against blanket rules especially when they don't reflect the realities of the world or how far we have come in ten years. These rules prevent progress and new ways of thinking about solutions. Imagine the changes OSM, OpenLayers, Leafet, MapBox have made. The ESRI rule said that we shouldn't do it that way. You should spend large amounts of money to do GIS things. Based on my ESRI analogy, the ground observable rule feels like using ArcGIS Desktop to do mapping. Is that a reality anymore? In actuality, the OSM and ESRI way complement each other and can be used together. 1. Every time this boundary debate or accuracy debate comes up, I image that I am supposed to have $20,000 of GPS equipment[1]; post process the data so that it is accurate; before I dare put the data in OSM. 2. To quote Richard Fairhurst, Seriously, OSM in the [England] s still way beyond broken. You can open it at any random location and the map is just __fictional__. Here are two random examples bing;OS StreetView [2] shape is approximate. Needs proper survey as mostly built after current BING imagery date [3] I thought Bing was so bad that it is broken. What is happening with this growing number of people is they say or imply that England, the birth place of OSM, is the bee's knees for accuracy because it was surveyed the old fashioned way. I find no difference in these two examples in England than adding an approximate area in the US based on a subdivision or some other locally named area. 3. It is my belief and experience that the ground observable rule is something that only applies to Europe or older metropolitan areas. There's a number of times that I have read on the US list that either the signs are missing, stolen, or never posted. One of the reasons I map what I do is because the signs are missing. I am curios what river or wash I just drove over. It is not posted. I had to go to the US government sites to find the information because it is useful in OSM. So what do you want
Re: [OSM-talk] How to report spam/abuse on the wiki?
On Mo, Mär 23, 2015 at 07:51:13 +0100, Frederik Ramm wrote:
On 03/23/2015 06:20 AM, Bryce Nesbitt wrote:
I noted a spam post to the wiki ( User:BrookMcIlvain ).
How do I report that?
Well the standard procedure would be replacing the page content with
{{Delete|Spam}}. That takes care of the spam, and then a Wiki admin
might or might not look at deletion requests from time to time and
actually remove the page.
(There's quite a few pending deletion requests
https://wiki.openstreetmap.org/wiki/Category:Labelled_for_deletion so I
guess Wiki admins are either understaffed or don't think this is very
important.)
I recently used the {{Delete}} template on a few pages and the next day they
were gone. So somebody is working on that. I suspect some cases are easy and
are handled quickly, others need some investigation or maybe links to those
pages need to be removed first, and so they need some more time. But spam
should be obvious and quickly dealt with.
Jochen
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Oneway vs access=no
Ciao Maxx, non conosco la situazione specifica, ma a giudicare dai dati e da quello che mi pare di aver capito, dovrebbero bastare le limitazioni di accesso (il cartello di cui parli è un divieto di accesso). La turn restriction dovrebbe essere inserita solo in presenza di un segnale specifico di direzione obbligatoria. Non indica chi può o non può transitare nella way di destinazione, ma solo chi può o non può effettuare una certa manovra ad un incrocio. Tornando al subject (oneway), in questi giorni, sistemando i dati di Milano, sono incappato in diversi usi di oneway per taggare strade in cui un senso di marcia è riservato ai psv. Non è corretto. E' giusto come avete fatto tu ed AnyFile nel tuo esempio: https://www.openstreetmap.org/way/333995756 oneway=no access=no foot=yes bicycle:backward=yes emergency:backward=yes taxi:backward=yes vehicle:forward=yes Forse avrei semplificato l'accesso per le bici con: oneway=no access=no foot=yes bicycle=yes emergency:backward=yes taxi:backward=yes motor_vehicle:forward=yes ma solo perché mi sembra di più immediata lettura per un umano :) - non mi è chiaro se ci siano delle regole precise sulla modalità di espressione di access in casi come questo. Buona giornata Sig Il giorno 21 marzo 2015 16:44, emmexx emm...@tiscalinet.it ha scritto: Il 10/24/2014 06:13 PM, Any File scrisse: Per rispondere al quesito se spezzare o meno la way dove inizia la striscia gialla, se sei sicuro fai pure (io non ho capito esattamente dove sia il punto) Scusate se interesso la lista per una situazione molto locale ma la mappatura e' abbastanza complessa. Ho fatto le modifiche che risultavano dalla discussione di qualche mese fa. Al momento di farle mi sono tornati un po' di dubbi relativamente a cio' che era stato consigliato di fare. Ad esempio qualcuno suggeriva di usare delle restriction (turn restriction immagino) mentre io avrei usato access=no. Non ho capito bene quale sia la differenza. Cioe' la differenza mi e' chiara ma quale delle 2 e' meglio usare? Ho preferito mettere comunque anche access=no con relativi eccezioni in modo che ci sia anche un feedback visivo sul fatto che li' c'e' una restrizione d'accesso pero' l'impressione e' che spesso ci siano info ridondanti che rendono piu' difficile mantenere le info aggiornate e corrette. Ho anche sistemato alcuni altri problemi nell'incrocio corso sempione/canova, melzi d'eril. Ho inserito delle turn restriction per impedire inversioni ad u ahli incroci ed alla fine degli sparti-traffico. Anche qui credo si dovrebbe inserire o un tag esplicito o qualche convenzione nel wiki per distinguere restrizioni dovute alla presenza di cartelli rispetto a quelle derivanti dal codice della strada senza necessita' di cartelli (es. inversione ad u agli incroci quando non c'e' un nodo che agisce come way nella relazione ma una o piu' way). Per chi conosce il posto: http://www.openstreetmap.org/?mlat=45.47787mlon=9.16952# map=19/45.47787/9.16952 Le varie restrizioni erano state descritte in questo thread, non le ripeto. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Rencontre à Paris vendredi 27 mars
Salut revenant :) De: Florian LAINEZ winner...@free.fr Hello Paris, Le rdv du dernier vendredi du mois tient toujours tous les mois ? J'ai rien vu passer pour ce vendredi, je me demande si c'est prévu. Dans ce cas vous vous retrouvez où d'habitude ? ++ PS [Spoiler] : je suis de retour sur Paris et content de retrouver tous les parigos ! Depuis le mois dernier on a décalé au dernier _jeudi_. Pas de lieu fixé pour cette fois-ci, mais ça va se préciser dans la journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Oneway vs access=no
On 2015-03-23 at 18:42:19 +0100, Luca Sigfrido Percich wrote: Invece mi scuso per i cavalieri e i conducenti di carretto a mano, che vedo circolare sempre più abbondanti nella mia cara metropoli. Mi è stato più volte ribadito di essere parsimonioso con gli access=no, ma ci casco sempre. Quindi, per essere propositivi, anziché access=no nei nostri casi (milano, strada con marciapiede, apparentemente nessun divieto a veicoli a trazione animale, carretti a braccio, biciclette), meglio usare sempre un motor_vehicle=no? attenzione che i carretti a mano e quelli trainati da cavalli sono veicoli e i divieti non altrimenti specificati si applicano anche a loro, così come alle biciclette. http://www.altalex.com/index.php?idnot=34124#titolo -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Oneway vs access=no
Il 03/23/2015 09:48 PM, Elena ``of Valhalla'' scrisse: attenzione che i carretti a mano e quelli trainati da cavalli sono veicoli e i divieti non altrimenti specificati si applicano anche a loro, così come alle biciclette. In effetti nel caso in questione il problema sono le definizioni per il senso opposto a quello dell'accesso con restrizioni. Attendiamo la proposta più economica, nel senso di numero di tag, per comprendere tutti i veicoli e non possibili. Comincia a capire chi aveva suggerito di sdoppiare in 2 way a senso unico quel breve tratto. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 23 mars 2015 16:21, dHuy Pierre dh...@yahoo.fr a écrit : Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Tout dépend ce qu'il y a déjà dans OSM. Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-dk] adresseposition
Hej Niels Det er fordi adressen findes både i Sorø og Kalundborg kommune. Dette problem findes også andre steder i landet. Kalundborg Kommune burde fjerne deres fordi adresse er i postnummer 4293 Dianalund som er en del af Sorø Kommune. Jeg har før fået en adresse node slettet i AWS ved at skrive på Twitter til @DKAdresser. Mvh Stephen 2015-03-23 0:24 GMT+01:00 Niels Elgaard Larsen elga...@agol.dk: Hvad er der sket med: http://www.openstreetmap.org/node/3391506535 Når jeg slår op på AWS får jeg koordinater: [ 11.4397830479696, 55.5713548335101 ], Hvilket er meget tæt på den position knuden havde i OSM fra 13 til 10 dage siden. -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [OSM-talk] Major Update to OpenRouteService 2.0
Sure we do like them ;-) but we still had some issues with available ressources, but are working on it. I think it's already quite a step from europe only. (ps. you understand that all this is no funded work, so we can't always do as much and what/how we would like to do, but one small step after the other) best az http://uni-heidelberg.de/gis http://OpenRouteService.org https://www.facebook.com/GIScienceHeidelberg https://twitter.com/GIScienceHD *Robert Kaiser* kairo at kairo.at mailto:talk%40openstreetmap.org?Subject=Re%3A%20%5BOSM-talk%5D%20Major%20Update%20to%20OpenRouteService%202.0In-Reply-To=%3Cmeklk2%24dn3%241%40ger.gmane.org%3E Alexander Zipf (HD) schrieb: / - OpenRouteService is now available for all of Europe, Asia, Africa and // Oceania/Australia ! / Why not for the Americas? Don't you like them? KaiRo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Rencontre à Paris jeudi 26 mars
Vraiment pas loin de Mozilla jdçjdr Le 23 mars 2015 22:17, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 12:02, althio a écrit : Si vous voulez encore une louche d'Open pour le jeudi 26 : N'en jetez plus :) Pour la rencontre parisienne de jeudi, ce sera finalement chez Papa, 153 rue Montmartre : http://www.openstreetmap.org/node/2695378308 Rdv à partir de 19:00, les premiers arrivés prennent une table au 1er étage... À jeudi, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-hr] scripta za OSM Notes (samo svoje nerjesene)
PS. Njemci su spomenuli tvoje djelo: http://blog.openstreetmap.de/blog/2015/02/wochennotiz-nr-237/ Pod sekcijom Programme On 03/22/2015 03:37 PM, hbogner wrote: Matija, daj ono što si ovdje i na talk@ listi objavio napiši tako da je prilagođeno kao post za http://osm-hr.org pa da i tmao objavimo. Hrvoje On 02/01/2015 05:35 PM, Matija Nalis wrote: Za zainteresirane koji imaju isti problem kao ja: koriste dosta OSM Notes, ali neke bugove ne uspiju odmah rijesiti, pa onda isti ostanu zauvijek zatrpani medju onima rijesenima (a nikad vam se ne da browsati kroz desetine/stotine stranica OSM-a da ih nadjete) Slijedeca scripta ce pokazati samo nerjesene OSM Notes za zadani username. Mozete ju isprobati na: https://torres.voyager.hr/~mnalis/my-osm-notes/ source code je objavljen na https://github.com/osm-hr/my-osm-notes (GPLv3+) (trebalo bi je uploadati na nas server u nekom trenu vjerojatno) Komentari/prijedlozi/pull requestovi/itd dobrodosli... On Tue, Jan 20, 2015 at 02:33:38PM +0100, Matija Nalis wrote: Meni bi bilo lakse za pratiti da mogu vidjeti vlastite OTVORENE notes. :( https://github.com/openstreetmap/openstreetmap-website/issues/832 Zna netko za neki 3rd party web da to moze pokazati? ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] scripta za OSM Notes (samo svoje nerjesene)
PPS. A i weeklyosm http://www.weeklyosm.eu/archives/2388 Pod sekcijom Software On 03/23/2015 10:46 PM, hbogner wrote: PS. Njemci su spomenuli tvoje djelo: http://blog.openstreetmap.de/blog/2015/02/wochennotiz-nr-237/ Pod sekcijom Programme ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-fr] Rencontre à Paris jeudi 26 mars
Le 23/03/2015 12:02, althio a écrit : Si vous voulez encore une louche d'Open pour le jeudi 26 : N'en jetez plus :) Pour la rencontre parisienne de jeudi, ce sera finalement chez Papa, 153 rue Montmartre : http://www.openstreetmap.org/node/2695378308 Rdv à partir de 19:00, les premiers arrivés prennent une table au 1er étage... À jeudi, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
The nice thing about mapping a neighborhood name as a point feature is: a) It helps people locate the neighborhood b) it completely sidesteps the question of the exact, possibly fuzzy, boundaries. For 10% of the hassle you map 90% of the benefit. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] About Open Street Map
Hi everyone I´m new in this project; i´m actually working with open data sets of my city and I wish to map the information aboutbirths, deaths and many others; how can I Translate it to OSM? Thanks for your help!CarlosArturoFyu ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Inserimento nomi vie da tabella
Ciao a tutti, riesumo questa discussione per chiarirmi le idee. In definitiva: questo tabellone è liberamente utilizzabile o no? https://dl.dropboxusercontent.com/u/20901490/Cerignola_Stradario.jpg Ciao /niubii/ Il giorno 28 agosto 2012 14:22, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2012/8/28 Elena ``of Valhalla'' elena.valha...@gmail.com: On 2012-08-28 at 13:25:44 +0200, Federico Cozzi wrote: 2012/8/28 Martin Koppenhoefer dieterdre...@gmail.com: IMHO un tabellone con l'elenco delle vie non è un'opera creativa D'accordo, però in questo caso potrebbe essere protteto dalla direttiva europeo sui database, al meno in europa. No, perché un tabellone fisico non è una banca dati, e quindi non è coperto dalla direttiva europea. una cartina stampata (tipo tuttocittà) da cosa e` coperta? non è poi così diversa dal tabellone. sono coperti da copyright classico, e da diritto d'autore. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Oneway vs access=no
On Monday 23 of March 2015 17:54:34 Mauro Costantini wrote: Il 23 marzo 2015 09:09, Luca Sigfrido Percich luca.perc...@gmail.com ha scritto: sono incappato in diversi usi di oneway per taggare strade in cui un senso di marcia è riservato ai psv. Non è corretto. Eppure il wiki lo riporta come esempio proprio sulla pagina della key access. «oneway=yes + psv=opposite_lane The street is one way for cars but there is one opposite lane for buses and taxis.» Perché dici che non è corretto? Aggiungo: ricordo quella regola almeno dal 2008. È cambiato la modalità di mappatura di queste (frequenti) situazioni? Ciao -- Luigi ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Incrocio di strada con pista nciclopedonale
2015-03-21 22:44 GMT+01:00 flaviano.ghe...@libero.it flaviano.ghe...@libero.it: Sto mappando una pista ciclo-pedonale che ad un incrocio con strada laterale presenta un semaforo per gli utenti ciclisti della pista. Come devo segnalarlo nella mappa? Se ho ben capito la situazione, userei i tag descritti dal wiki qui: http://wiki.openstreetmap.org/wiki/Key:crossing quindi: highway=crossing (in corrispondenza del nodo di intersezione tra la pista e la strada) crossing=traffic_signals (sempre sul nodo per indicare la presenza del semaforo) cycleway=crossing (per la parte di pista ciclabile che attraversa la strada) Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Oneway vs access=no
Il 03/23/2015 05:54 PM, Mauro Costantini scrisse: Quindi è vietato l'accesso a cavallo in entrambe le direzioni? Posso chiedere di essere piu' propositivi? Ho scritto apposta qui perche' sono poco esperto di tag access. E spendere ore ad interpretare email e wiki non e' divertente. Avevo descritto la situazione a suo tempo. Ripeto: Provenendo da nord all'inizio dell'ultimo tratto di corso Sempione c'e' un cartello di divieto d'accesso: http://www.emmexx.it/varie/osm/sempione/DSC_0061.JPG Divieto eccetto tram, mezzi di soccorso e bici. A terra c'e' anche scritto TAXI. La corsia ha le strisce gialle delle preferenziali solo per 30 metri poi spariscono. In direzione opposta non ci sono preferenziali. Chi entra da altri punti puo' percorrere la via in entrambe le direzioni, a parte quei 30 metri iniziali in direzione sud-est. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Mon, Mar 23, 2015 at 10:29 AM, Bryce Nesbitt bry...@obviously.com wrote: The nice thing about mapping a neighborhood name as a point feature is: a) It helps people locate the neighborhood b) it completely sidesteps the question of the exact, possibly fuzzy, boundaries. For 10% of the hassle you map 90% of the benefit. Except when it reports you are in a different neighborhood than you actually are. When neighborhoods are not clearly defined then yes, a point is the best choice. But when neighborhoods have defined boundaries then they should be added. Just going up the admin level to city level, points work until it says you are in a different city. We can not see city boundaries but OSM has thousands of city boundaries. The simple solution is if the neighborhood boundaries are clearly defined they belong in OSM as polygons. If neighborhood boundaries are not clearly defined then they should be represented by points. For the supporters of no admin boundaries in OSM, build the case on the mailing lists instead of just saying there is a growing support for no boundaries. In some parts of the US there is a growing support that climate change is a hoax. That doesn't make it true. Build a case for removing admin boundaries (and please include landuse.) Ideally in the future we can have a fuzzy boundary. But until then I think what I proposed is an acceptable solution. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
On 03/23/2015 04:53 PM, Borut Maricic wrote: Ob das ganze zum reverten ist, kann ich nicht beurteilen. Wäre sicherlich am einfachsten, klingt für mich persönlich aber etwas brutal. Die Sache ist doch klar: Wenn er großflächig (automatisiert) editiert, ohne es abzusprechen, dann wird das reverted. Es kann nicht sein, dass jeder schnell mal automatisiert was macht und dann unzählige Leute mühsam in jedem Edit vielleicht doch was Sinnvolles suchen müssen, bevor der reverted wird. Das bindet einen Haufen Leute nur weil sich einer nicht die Arbeit machen wollte, die Edits kleinräumig und kontrolliert zu machen. Das mag jetzt für dich vielleicht brutal wirken, aber die Regeln gibt's ja für jeden lesbar im Wiki. Wenn er es bis dorthin noch nichtmal geschafft hat zu lesen, dann muss er halt damit umgehen lernen, dass ihm sein Edit genauso schnell wieder reverted wird. Und je länger man damit wartet umso unwahrscheinlicher wird es, dass der Revert genauso automatisiert (und damit für andere zeitsparend) geht. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it] Oneway vs access=no
Ciao cari, rispondo brevemente e senza quotare, pedonatemi. Perché oneway no: perché non sono strade a senso unico. Se il bus passa nell'altro senso allora è una strada a doppio senso di marcia. Se con separazione fisica, sono due carreggiate a senso unico. E' vero che la wiki riporta il vecchio tagging scheme dei busway, che prevedeva busway=opposite_lane: ma per il codice della strada è oneway=no. Invece mi scuso per i cavalieri e i conducenti di carretto a mano, che vedo circolare sempre più abbondanti nella mia cara metropoli. Mi è stato più volte ribadito di essere parsimonioso con gli access=no, ma ci casco sempre. Quindi, per essere propositivi, anziché access=no nei nostri casi (milano, strada con marciapiede, apparentemente nessun divieto a veicoli a trazione animale, carretti a braccio, biciclette), meglio usare sempre un motor_vehicle=no? Grazie Sig Il giorno 23 marzo 2015 18:28, emmexx emm...@tiscalinet.it ha scritto: Il 03/23/2015 05:54 PM, Mauro Costantini scrisse: Quindi è vietato l'accesso a cavallo in entrambe le direzioni? Posso chiedere di essere piu' propositivi? Ho scritto apposta qui perche' sono poco esperto di tag access. E spendere ore ad interpretare email e wiki non e' divertente. Avevo descritto la situazione a suo tempo. Ripeto: Provenendo da nord all'inizio dell'ultimo tratto di corso Sempione c'e' un cartello di divieto d'accesso: http://www.emmexx.it/varie/osm/sempione/DSC_0061.JPG Divieto eccetto tram, mezzi di soccorso e bici. A terra c'e' anche scritto TAXI. La corsia ha le strisce gialle delle preferenziali solo per 30 metri poi spariscono. In direzione opposta non ci sono preferenziali. Chi entra da altri punti puo' percorrere la via in entrambe le direzioni, a parte quei 30 metri iniziali in direzione sud-est. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] About Open Street Map
On Mon, Mar 23, 2015 at 1:16 PM, Carlos Arturo Fyu spark_...@hotmail.com wrote: Hi everyone I´m new in this project; i´m actually working with open data sets of my city and I wish to map the information about births, deaths and many others; how can I Translate it to OSM? Thanks for your help! CarlosArturoFyu Hi Carlos, Welcome to the OpenStreetMap project, and thanks for your interest. Adding information to the OpenStreetMap database from another dataset, like city data, is a very advanced activity. I can't recommend it for somebody who is in a hurry. :-) Adding data that you observe, about the things that interest you, is much simpler, and I can recommend that everybody start their involvement with the OpenStreetMap project by doing exactly that; map your neighbourhood. Make sure that your favourite restaurant and grocery store are included in the OpenStreetMap database. There are some guidelines: The best data to include is verifiable, permanent and significant. Ideally, we don't include data that is personal or private in some way, data that is too rapidly changing, not significant, or that is opinion. The personal aspect of the births and deaths data that you mention may be an issue. I imagine that there will be objections to including death-location data into the OpenStreetMap database. There are potential objections based on the accuracy (how precisely is it know where a person died?) and on privacy, and perhaps on other grounds. On the other hand, if you have data about a street address where a person died, it would be acceptable to confirm that the street address is properly included in the OpenStreetMap database. If you want to know more about including data from external sources in the OpenStreetMap database, please start your reading here[1]. The Import page on the wiki and several connected pages from there, will give you some details on the required steps before you begin. If you want to know more about how to map your neighbourhood, and that is a great way to get started participating in OpenStreetMap, then have a look at the beginners' guide[2] Best Regards and Happy Mapping, Richard [1] http://wiki.osm.org/wiki/Import [2] http://wiki.osm.org/wiki/Beginners%27_Guide ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Recherche avec orthographe approximative
Enfin une recherche d'adresse pour ceux qui on de gros souci d'orthographe comme moi http://jdf.geovelo.fr/ Si je recherche la rue sun onore, pari il me trouve bien la Rue Saint-Honoré, Paris en plus c'est libre et c'est basé sur OSM Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-br] Restrição de Manobra em U
Olá Pessoal, Terminei de corrigir os erros de roundabout reportados em [1]. Analisando os outros arquivos de erros disponibilizados por esse sites, encontrei vários erros como esse: 2015/03/23 01:12:52 WARNING (RestrictionRelation): 55137017.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/relation/3924718 (at http://www.openstreetmap.org/?mlat=-20.415043mlon=-42.900811zoom=17) no_u_turn with equal 'from' and 'to' way and via node is ignored Pelo que eu vi estão sendo criadas restrições de manobra em U nas quais a origem e o destino são os mesmos. Seria algo como: proibido retornar na mesma via. Penso que essas restrições realmente não sejam necessárias, pelos motivos abaixo: A) Geralmente restrições de manobra em U ocorrem quando existem duas vias paralelas em sentidos opostos e uma terceira via perpendicular ligando elas. Assim sinaliza-se que não é permitido usar a via perpendicular para fazer um retorno entre as vias opostas. Agora placa sinalizando que não é permitindo retornar na mesma via eu não me lembro de ter visto, o que também seria mais próximo de uma manobra em I do que uma manobra em U... rsss B) Se for levar ao pé da letra, nesse caso o pé da lei [2], é proibido retornar na mesma via quando está sobre: pontes, viadutos, túneis, aclives, declives, curvas e também em vias com faixas amarelas duplas continuas. Imagine mapear todos esses locais com restrições de manobra em “U”, seria insano, além do que o mapa viraria uma “Colcha de Retalhos”. C) Mesmo sem essas restrições, nos GPSs que usei até hoje não me lembro do GPS ter sugerido esse tipo de manobra, algo como faça retorno na mesma via, geralmente ele pede que você siga até um cruzamento e faça um retorno na quadra. Assim acredito que o próprio software do GPS evite sugerir manobras desse gênero. D) Pelas mensagens do Mkgmap essas restrições estão sendo ignoradas, acredito que procedimento semelhante deva ser feito por outros compiladores, assim na prática essas restrições de manobram não tem muita utilidade visto que o próprio compilador está ignorando essas informações. Procurando na internet encontrei esse ticket [3] no iD, sugerindo que seja desabilitada a opção de criar manobras como essa. Concordo com tudo que foi dito pelos usuários brasileiros no ticket, principalmente a parte que diz que a interface do iD está induzindo os usuários a criar essas restrições mesmo não sendo necessárias. Estava pensando em deletar essas restrições, pelos motivos acima expostos, porém antes de fazer isso gostaria de saber se vocês veem algum problema nisso? [1] - http://mapas.alternativaslibres.es/errors_Brazil.zip [2] - http://www.ctbdigital.com.br/?p=ComentariosRegistro=78campo_busca=artigo=206 [3] - https://github.com/openstreetmap/iD/issues/2527 Att Oéslei. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
On 23.03.2015 16:53, Borut Maricic wrote: Ich selbst trage z.B. die surface=* nie ein (und ändere eigentlich auch nicht), aber in meinem Kopf ist festverdrahtet - vielleicht falsch, aber so ist es halt - surface=unpaved gleichgesetzt mit surface=fine_gravel, sprich eine gute, relativ schnell befahrbare, meist frei zugängliche Waldstraße. Und das Mappe ich halt ausgerechnet mit tracktype=grade1. surface=unpaved is alles, was nicht paved ist, also ein Überbegriff für alles mögliche von Schotter bis Sumpf. Aber wenn du es eh nicht taggst, ist deine falsche Vorstellung kein Problem. ;-) Die meisten falschen oder inkonsistenten Tags werden von Leuten eingetragen, die einen Editor benutzen, in dem sie über Listboxes alles mögliche auswählen können, und da wählen sie halt was aus, um quasi die Fragen bestmöglich zu beantworten, auch wenn sie gar nicht wissen, was überhaupt gemeint ist. Das offenbart sich auch an überflüssigen access-Tags, oneway=no, cycleway=no usw. Und wer weiß, ob nicht mancher Editor sich die zuletzt ausgewählten Werte für tracktype und surface merkt und den nächsten track gleich damit vorbefüllt... Ob das ganze zum reverten ist, kann ich nicht beurteilen. Wäre sicherlich am einfachsten, klingt für mich persönlich aber etwas brutal. Das finde ich überhaupt nicht brutal, denn die rückgängig gemachten Edits sind ja keine, wo jemand viel Schweiß und Blut hineingesteckt hat, und es sind auch keine, bei denen irgendwelche neuen Daten oder Informationen eingepflegt wurden. Wenn viele sich als betroffen melden, wird es dann klarer. Wenn vieles kaputt gegangen ist - ist ja DACH betroffen - wird es eh hohe Wellen schlagen. Wer soll sich als betroffen melden und bei wem? Wenn ich in meiem Leben 1 Tracks angelegt habe und bei dem Massenedit wurden 100 davon umgetaggt, dann merke ich das vielleicht erst in ein paar Monaten oder Jahren, wenn ich zufällig wieder einen davon im Editor anschaue. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Effectivement, si tu fais ça, ça serait uploader des données erronées si tu le fais directement... C'est un travail minutieux que de cartographier les volumes, ça sert ensuite pour mettre en place une visualisation 3D et une erreur sur ces datas provoquera, une erreur dans la visualisation et réduira conséquemment l'appréciation d'osm pour ce type de données, alors qu'à Paris de nombreux cartographes y travaillent (jette un oeil à Cité).Librement, Le Lundi 23 mars 2015 23h38, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Openstreetmap Urheberrechtshinweis
Ist diese Mail schon weg? Am 2015-03-21 um 18:52 schrieb Paul Wölfel: Hallo, wie es scheint verwendet ihr Openstreetmap Daten auf eurer Homepage, allerdings ohne Hinweis auf deren Ursprung. Laut der Lizenz von Openstreetmap sind die Daten zwar als Open Data verfügbar, jedoch muss der Hinweis auf die Quelle genannt werden. Bitte dies dementsprechend beachten. Hier die Infos zu der Lizenz von Openstreetmap: http://www.openstreetmap.org/copyright/de BTW: sollte auf einer österreichischen Website nicht ein österreichischer Urheberrechtshinweis anstatt eines US Copyrights sein? Mit freundlichen Grüßen Dipl.-Ing. Paul Wölfel Email p...@woelfel.at mailto:p...@woelfel.at Tel. +43 664 88 533 801 Lindengasse 31/1/11 1070 Wien Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it] Deletion of relations in Sicily / Di eliminazione delle relazioni in Sicilia
On 23/03/2015 21:46, Luca Delucchi wrote: the user answer to the changeset comment, he was sure about removal of the relations, some Sicilian guys can check if he answer the true or not, for me seems really strange to remove more than 600 relation... maybe a revert could be useful? At the very least, an edit that deleted 683 relations should have been discussed with the community first, if for no other reason because it was rude not to do so. I've added another comment to the discussion http://www.openstreetmap.org/changeset/29645361 trying to get that across. If (after checking with people on the ground locally) the Italian OSM community wants to see this changeset reverted and someone from within the community is happy to do that then please go ahead. If you'd like help with the revert, then please ask and I'm sure that we'll be able to sort something out. Best Regards, Andy Townsend (SomeoneElse), on behalf of the OSM Data Working Group ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-br] relação ROTA Rodovia Washington Luís (BR-040)
Amigos, estava eu analisando problemas de não roteamento do Rio de Janeiro para Brasília e iniciei a analise pela relação Rota Rodovia Washington Luís. Por culpa minha mesmo, quando inseri os novos trechos da rodovia na serra, no Rio de Janeiro, deixei de excluir os antigos trechos da relação e inserir os novos. Foi feito agora. Na continuidade de analise da relação para o norte cheguei a cidade de Paraopeba e ali não entendi porque excluíram da relação a rodovia e nela inseriram as vias de acesso, internas e de saída da cidade. Exemplo de caminho inserido na relação: http://www.openstreetmap.org/way/294898358 Foi equívoco ou tem alguma razão? []s Marcio ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
ça améliore pas mal les données mais il y a des inexactitudes donc c'est mauvais d’après toi. (réaction que j'ai déjà vu ici sur d'autres types de données). d’après ce qui a été dit il ne touche pas aux bâtiments avec déjà des tags de hauteur et rien n’empêche que d'autres contributeurs n’améliore se qui a déjà été touché par son script. je n'y connais pas grand chose en import mais ce que j'ai compris : - pour l'importation il faut le faire à partir un compte dédié à l'import (un compte normale mais avec sur sa page une description de ce qui est importé.) - vu que c'est sur la France il faut en discuter ici Apres, je suis aller voir les données rapidement là http://api06.dev.openstreetmap.org/api/ (pour ceux qui ne savent pas comme moi il y a quelque minutes, dans josm, préférence, mettre cette adresse comme serveur où se connecter puis charger la zone modifié (une zone couvrant Bastille / Gare de Lyon / Nation)). on voit dans l'historique que tu as fais plusieurs passages qui modifies plusieurs fois les level pour certains building, j'ai pa Le 24 mars 2015 00:24, dHuy Pierre dh...@yahoo.fr a écrit : Effectivement, si tu fais ça, ça serait uploader des données erronées si tu le fais directement... C'est un travail minutieux que de cartographier les volumes, ça sert ensuite pour mettre en place une visualisation 3D et une erreur sur ces datas provoquera, une erreur dans la visualisation et réduira conséquemment l'appréciation d'osm pour ce type de données, alors qu'à Paris de nombreux cartographes y travaillent (jette un oeil à Cité). Librement, Le Lundi 23 mars 2015 23h38, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore une carte OSM dans la presse...
Le 23/03/2015 23:40, Vincent Pottier a écrit : Bonsoir, Le journal La Croix se met à OSM : http://www.la-croix.com/Actualite/France/Le-poids-des-nouvelles-regions-francaises-2015-03-23-1294236?xtor=EPR-9-%5B1300815577%5D Et aussi : http://www.la-croix.com/Actualite/France/Elections-departementales-2015-tour-de-France-des-departements-a-enjeux-2015-03-09-1289194 -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
