Re: [Talk-de] Osmose QA available on Germany (english)
2015-04-26 12:40 GMT+02:00 Simon Poole si...@poole.ch: The major issue with osmose is that it invokes the notion of being authoritative when it is not, and by that motivates mappers to fix things (well actually break them) which are simply false positives. +1, I suggest to remove the test for roundabouts with missing junction=roundabout tags, because you can hardly tell from remote whether a circular road is a roundabout or not (roundabouts have to be signposted to be such), or at least make the wording weaker, because I fear the introduction of new errors by overeager correctors. Cheers, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Removing redundant routing instructions
FWIW, I just wanted to fix the situation to give you an example, and someone else was faster, it is already fixed in the way I did suggest above: http://www.openstreetmap.org/#map=19/52.45290/-1.48908 Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
On Sun Apr 26 12:35:57 2015 GMT+0100, Rob Nickerson wrote: Hi all, In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. Although the road continues round the bend SatNav systems often think it is a junction and tell you to turn right/left in 100 yards/meters. I wonder whether it is possible to indicate this in OpenStreetMap so that routing engines can omit this redundant instruction. == Example picture == https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing In the example Oban Road [1] turns to the right to become the northern section of Sydnall Road. All main routers tell you to turn right. In my opinion this is a redundant instruction (or could be better worded). I've tried to add extra nodes so that the road naturally bends but the main routing engines still tell you to turn. == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Phil (trigpoint) -- Sent from my Jolla ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
On 27/04/15 10:45, p...@trigpoint.me.uk wrote: == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Why do I find that confusing? Currently in general the directions ignore corners even if there are roads going off those corners. The complaint is about 'extra' directions where the corner is actually the main road and the straight on branch is the turning. If the directions remain silent one would in some conditions get confused so the safe thing to do is announce both? The correct wording of the the directions should be perhaps 'road bares right' and 'go straight on' rather than 'turn right' but that does need the perhaps missing through_route information? As I said, the inclusion of road names in OSMAND while useful at times does get similarly annoying when a 'continue on Axxx' would suffice. In this case the road id provides the through_route information ... one remains on the same road ... and the straight on road has a different one which may just be 'minor road'. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Intégration des données de PSS dans OSM
Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND ( https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance pour votre aide, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Removing redundant routing instructions
2015-04-27 10:52 GMT+02:00 Cartinus carti...@xs4all.nl: If you reread the original mail, then you'll see he already tried this himself and it did not work. Maybe this is caused by geometry simplication in the router? If you have a detailed look at the overlay you can see that the routing geometry is not following completely the rendered geometry: http://www.openstreetmap.org/directions?engine=osrm_carroute=52.45362%2C-1.48598%3B52.45341%2C-1.48944#map=18/52.45311/-1.48788layers=Q On the other hand, OSRM test website (with apparently different geometry) also show a turn slight right at this spot: http://map.project-osrm.org/?hl=enloc=52.453163,-1.488334loc=52.453129,-1.489063z=18center=52.453214,-1.489010alt=0df=0re=0ly=-1171809665 I guess in this case I wouldn't mind if I got the turn slight right instruction, in the end that's what you have to do, but I agree it would be better to get stay on the road and turn slight right or something like this. The other case (main road turns right but you have to keep straight) is more important to be fixed. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-it-trentino] Mappiamo per il Nepal?
ciao a tutt* immagino che qualcuno di voi stia già lavorando per arricchire la mappa del Nepal su OSM. Mi chiedevo se valeva la pena provare ad organizzare un incontro formativo a breve in cui ci vediamo come mappers trentini e, se riusciamo, coinvolgiamo anche altre persone. Che dite? -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Si les données sont en NC et ND, il n'y a en effet pas d'intégration possible dans osm qui est en ODBL, qui permet tant l'usage commercial que les modifications. Cependant si le site déverse dans OSM, il pourrait également capter des données depuis OSM et même en faire business, sous réserve de respecter la licence ODBL. Un exemple : http://overpass-turbo.eu/s/92u Leur page À propos semble en phase avec le projet communautaire qu'est OpenStreetMap : http://www.pss-archi.eu/aproposde.html -- Jean-Baptiste Holcroft Le 27 avril 2015 20:30, Philippe Verdy verd...@wanadoo.fr a écrit : Pas de SA peut-être, mais ND: aucune oeuvre dérivée possible, on n'a donc le droit qu'à l'utilisation de l'original. Ajoute NC et cette version originale est aussi interdite à certaines utilisations. Bref non on ne peut pas changer de licence sur une copie à l'identique de l'original. SA c'est pour permettre le repartage (modifié ou pas), mais ne permet pas non plus un changement de licence. Cette oeuvre n'est donc pas libre, et CC-BY-NC-ND est en fait tout à fait comparable à une contenu sous copyright publié sur n'importe quel site web ne donnant aucune licence explicite, et placé par défaut sur la protection générale du copyright. C'est le même régime en fait que les cartes de Google Maps (gratuites et consultables pour un usage personnel ou une diffusion très limitée à l'identique, mais pas libre non plus et soumis aussi à des restrictions pour l'utilisation commerciale, qui nécessite l'acquittement de droits pour la licenc ou pour en faire des données dérivées, dont Google conserve les droits exclusifs). C'est le même régime que de nombreux freewares qui sont free as a beer (gratuits) mais pas libres et eux aussi resteints pour l'utilsiation commerciale. CC-BY-NC-ND ne sert à rien d'autre que de montrer que le contenu est protégé, en offrant un lien ver sune page pour le dire explicitement (et cela ne sert que dans les rares pays où le régime du copyright ne s'applique pas par défaut mais où le régime serait plus permissif). Globalement cela ne sert que pour les utilisations dans les pays qui n'ont pas adhéré à la convention de Bern ou au WIPO (je ne suis même pas sûr que même en Corée du Nord cette licence soit utile, car si on y contrevient là-bas il n'y aura personne pour l'interdire ou recevoir une plainte). A mon avis CC devrait même supprimer le support de cette licence inutile et qui n'est pas dans ses missions de soutenir les contenus libres. Le 27 avril 2015 13:39, dHuy Pierre dh...@yahoo.fr a écrit : Il n'y a pas SA donc pour moi on peut changer la licence à l'export. À confirmer. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance 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 ___ 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-cz] kresleni vodniho toku s vodni nadrzi
Zdárek, 1) část v trubce označit jako tunnel=culvert + layer=-1 2) občasný tok označit tagem intermittent=yes Obojí se dokonce v současnosti vykresluje na hlavní mapě xkomczax __ Od: Petr Vozdecký v...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27.04.2015 22:44 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi ahoj, diky za odpovedi. Mluvim asi o detailech, ktere nejsou importovany. Piditoky, pidipritoky apod. Ziskane odpovedi vygenerovaly dalsi dotazy: 1) mam tok, ktery mizi pod povrchem, je to zatrubnena cast. Mam to tedy (v navaznosti na info o nutnosti routovat) s ostatnimi castmi spojit relaci? 2) mam tok (navic evidentne obcasny), ktery mizi pod povrchem a po desitkach metru se zase vynoruje. Neni to ale zadne propadani ani jiny klasicky podzemni krok, proste se do te doby regulerni tok v malem koryte doslova vsakne do zeme a zase se objevi o velky kus dal... neni to zadna umela meliorace, ale prirodni jev v lese. Mapoval jsem to jako WAY pak nic a pak WAY. To je ale teoreticky z hlediska routovani taky spatne...? vop -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 27. 4. 2015 14:32:51 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz= -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 2015-04-26 10:03, Borut Maricic wrote: Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? als bewohner des steierischen wald-multipolygons, der des öfteren in diesem mappt, bin ich für pragmatische lösungen: flächenoutline, mit scrub oder grassland taggen und danke. und diese outline ist mit keinen anderen linien und oder flächen in irgendeiner weise verknüpft. stimmt inhaltlich - jetzt (!!) ist dort gemüse und kein Forest - und macht spätere anpassung wenn wieder wald ist zu einer einfachen übung. ich weiss, dass ich mich mit der aussage bei den multipolygon-fans total unbeliebt mache, aber solange es keine klare richtlinie für die minimalen und/oder maximalen ausdehnungen eines selbigen gibt und was zum MP dazugehören muss und was nicht, solange werde ich mich grösstenteils weigern komplexere dinge als see + insel oder wiese + baumgruppe oder vierkanthof anzugreifen. wer sich einmal wald in der steiermark angeschaut hat, der wünscht sich, dass sich ein multipolygon bei mehr als 10 membern sofort selbst tesselieren würde. und zwar un-revertable. ;) grüsse, grubernd ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk] Overpass Quotas
Dear all, in the last weeks the server overpass-api.de has seen a flood of extra requests. Unfortunately, most of these requests have been from a few clumsy clients. The standard pattern has been apparently a server that fires as much requests as possible, often some or most of them syntactically correct, but semantically nonsense. For example, from one IP adress was sent the same query for objects with name Lipkenskothen every 5 seconds (It is very unlikely that these few results change more often than once per month, hence a frequency of once per day would be more than enough). While I may block such extreme cases with iptables (i.e., the server then appears unreachable from that IP), I would like to avoid manual blocking as much as possible. Beside the quite hard challenge of being unbiased in blocking decisions, it is also a lot of annoying work. For that purpose I have changed the quota calculation. I will uphold the basic rule that a client shall not send more than one request in parallel from an IP. For the other details, I'm trying an A/B-strategy for traffic management, hence they may change quite often at the moment. If you encounter a serious service degradation, in particular sustaining HTTP 429 responses, please contact me by mail such that I can adjust the algorithm to make fewer or no false positives. Cheers, Roland ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
ahoj, diky za odpovedi. Mluvim asi o detailech, ktere nejsou importovany. Piditoky, pidipritoky apod. Ziskane odpovedi vygenerovaly dalsi dotazy: 1) mam tok, ktery mizi pod povrchem, je to zatrubnena cast. Mam to tedy (v navaznosti na info o nutnosti routovat) s ostatnimi castmi spojit relaci? 2) mam tok (navic evidentne obcasny), ktery mizi pod povrchem a po desitkach metru se zase vynoruje. Neni to ale zadne propadani ani jiny klasicky podzemni krok, proste se do te doby regulerni tok v malem koryte doslova vsakne do zeme a zase se objevi o velky kus dal... neni to zadna umela meliorace, ale prirodni jev v lese. Mapoval jsem to jako WAY pak nic a pak WAY. To je ale teoreticky z hlediska routovani taky spatne...? vop -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 27. 4. 2015 14:32:51 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-es] Weeklyosm #246 en castellano
Hola El semanario #246 de weeklyosm, el sumario de todo lo que está ocurriendo en mundo OSM está en linea en español http:/www.weeklyosm.eu/?lang=es Disfrutadlo!___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
Ahoj, diky za odpovedi, ale pro uplnost si dovoluji dodat, ze na toto jsem se ne zcela ptal. Tyto tagy totiž zmiňované WAYe již mají. Podstatou dotazu byly ty casti textu, ktere byly oznaceny otaznikem: 1) mam navazne nadzemni a podzemni casti scelit relaci? 2) mam vodni tok mizejici pod zemi scelit podzemnim vedenim toku i kdyz jde jen o tuseny tok? S diky vop -- Původní zpráva -- Od: xkomc...@centrum.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 4. 2015 22:51:23 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Zdárek, 1) část v trubce označit jako tunnel=culvert + layer=-1 2) občasný tok označit tagem intermittent=yes Obojí se dokonce v současnosti vykresluje na hlavní mapě xkomczax __ Od: Petr Vozdecký v...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27.04.2015 22:44 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi ahoj, diky za odpovedi. Mluvim asi o detailech, ktere nejsou importovany. Piditoky, pidipritoky apod. Ziskane odpovedi vygenerovaly dalsi dotazy: 1) mam tok, ktery mizi pod povrchem, je to zatrubnena cast. Mam to tedy (v navaznosti na info o nutnosti routovat) s ostatnimi castmi spojit relaci? 2) mam tok (navic evidentne obcasny), ktery mizi pod povrchem a po desitkach metru se zase vynoruje. Neni to ale zadne propadani ani jiny klasicky podzemni krok, proste se do te doby regulerni tok v malem koryte doslova vsakne do zeme a zase se objevi o velky kus dal... neni to zadna umela meliorace, ale prirodni jev v lese. Mapoval jsem to jako WAY pak nic a pak WAY. To je ale teoreticky z hlediska routovani taky spatne...? vop -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 27. 4. 2015 14:32:51 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz= -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] maxspeed=AT:*
On 27.04.2015 22:56, Markus Straub wrote: spricht irgendetwas dagegen maxspeed=AT:* gegen folgendes zu ersetzen: z.B. maxspeed=AT:urban zu maxspeed=50 source:maxspeed=AT:urban Ja. Beide Varianten sind zulässig, und sie sind äquivalent. Bitte sowas nicht unnötig hin und her umtaggen. Wie ich schon zum Thema Kahlschläge schrieb: Wenn man nichts Neues beizutragen hat, gehört sich solches Umtaggen nicht. -- 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
[Talk-at] maxspeed=AT:*
Hi, spricht irgendetwas dagegen maxspeed=AT:* gegen folgendes zu ersetzen: z.B. maxspeed=AT:urban zu maxspeed=50 source:maxspeed=AT:urban Ich denke ersteres ist ein Relikt aus plan.at Zeiten mit at:maxspeed=Ortsgebiet und sollte ersetzt werden. (http://www.openstreetmap.org/changeset/30452271) LG, evod ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk] GSoC - Accepted students have been announced
Hi all, the list of accepted projects is out and OpenStreetMap will mentor 8 student projects during Google Summer of Code 2015. You can have a look at the full list at the google melange site¹. Additionally, you can have a look at our wiki page here, for the accepted OSM projects and project details². As the community bonding period³ starts now, the students have time to get to know their mentors, read documentation and get up to speed to begin working on their projects. Official coding begins on 25 May, and I hope we'll have 8 motivated students who will do a great project. So you may expect first documentations of progress after 25 May. We hope that students whose applications were unsuccessful will nevertheless stay in touch with OpenStreetMap. Contributors are always welcome, and we have a wealth of interesting projects available ;) Happy GSoC, Peda [1] https://www.google-melange.com/gsoc/projects/list/google/gsoc2015 [2] https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2015/AcceptedProjects [3] http://googlesummerofcode.blogspot.de/2007/04/so-what-is-this-community-bonding-all.html ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
1) Zkus se podívat, zda přesná trasa zatrubněné části není v cuzk:km. Často jde také odvodit z tvaru parcel. Podzemní část značit standardně jako řeku s layer=-1 a dle situace tunnel=yes/culvert. Relace není třeba, dělení řek na více navazujících cest nevadí. 2) Zkusil bych podzemní část trasovat dle 1) a pak bych asi použil tunnel=yes nebo location=underground s příp. komentářem situace. Dle toho, co bude vypadat líp. Na wiki jsem žádný tag hodící se na tuhle situaci nenašel. Michal 27. dubna 2015 22:43:11 CEST, Petr Vozdecký v...@seznam.cz napsal: ahoj, diky za odpovedi. Mluvim asi o detailech, ktere nejsou importovany. Piditoky, pidipritoky apod. Ziskane odpovedi vygenerovaly dalsi dotazy: 1) mam tok, ktery mizi pod povrchem, je to zatrubnena cast. Mam to tedy (v navaznosti na info o nutnosti routovat) s ostatnimi castmi spojit relaci? 2) mam tok (navic evidentne obcasny), ktery mizi pod povrchem a po desitkach metru se zase vynoruje. Neni to ale zadne propadani ani jiny klasicky podzemni krok, proste se do te doby regulerni tok v malem koryte doslova vsakne do zeme a zase se objevi o velky kus dal... neni to zadna umela meliorace, ale prirodni jev v lese. Mapoval jsem to jako WAY pak nic a pak WAY. To je ale teoreticky z hlediska routovani taky spatne...? vop -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 27. 4. 2015 14:32:51 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz= ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost.___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk] Next: Relation name (WAS: Removing redundant routing instructions)
Ok a few people are agreeing that a relation is needed to assist the routing engine to provide higher quality instructions (with routing left unaffected). That's good. I'd like to get something in the wiki and ideally get it approved (this is not an invite to talk about the wiki or the approval process - I've heard it all before). Question: Should I revive the through_route proposal or start a new one under a different name, say route_continues (or just continues) so as to avoid any ambiguity with the use of through route in general language? Cheers, Rob ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] [Talk-us] Great Lakes Boundaries
On Sun, Apr 26, 2015 at 8:47 AM, Mike Thompson miketh...@gmail.com wrote: Since no objection to removing natural=water from the Lake Superior relation has been expressed, I have removed it. I also amended the note on the relation asking that it not be added back in. Huron, Michigan, and Erie all had the same issue (added at the same time by the same user) so I removed natural=water from those as well and added a similar note. Lake Ontario on the other hand is *only* mapped a water multipolygon (no coastline ways) so I've left it as-is for now. On Mon, Apr 27, 2015 at 11:12 AM, Mike Thompson miketh...@gmail.com wrote: I don't think we are out of the woods yet. Overnight the NE end of Isle Royal became flooded at zoom level 13 This may also be due to outdated coastline shapefiles used by the standard tile layer (but I am not sure). The coastline data for Isle Royale looks good as processed in the latest daily files from http://openstreetmapdata.com. Proposed Course of action. [...] The proposed course of action for cleaning up the extra/incomplete Lake Superior relation seems good to me. AJ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] Event Calendar on Wiki
On So, Apr 26, 2015 at 12:27:05 -0700, Clifford Snow wrote: On Sun, Apr 26, 2015 at 11:22 AM, Mike Thompson miketh...@gmail.com wrote: I added an event (OSM Basics @ Colorado State University...) to the wiki (by editing the calendar template as the instructions state), yet it doesn't show up on the main wiki page with the other events. Did I do something wrong? I see it listed on the wiki main page. You have it scheduled for April 27th. The Wiki caches pages, so sometimes it can take a while for things to show up. This is especially true when a wiki page includes parts from other pages like in this case. I think usually the caching is disabled when you are logged in, so you should see the up-to-date version then. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Liesinger Platz, Fahrbahn-Mapping, Bus-Relationen zerstört
Am 22.04.2015 um 01:50 schrieb Kevin Kofler: Christian Aigner wrote: Ich liebe es. Wirklich! (NICHT!!!) Da hab ich viele Stunden investiert, um die Busrelationen zu ergänzen bzw. überhaupt neu einzutragen, und jetzt kommt da einer daher (User: Girolamo) und macht das kaputt. Nur weil er meint, er müsse die Fahrbahnen, die nicht baulich getrennt sind, aufzutrennen. Es ist ein Jammer! :-( In dem Fall ist ein Revert wahrscheinlich die beste Lösung. Kevin Kofler Ich werde jetzt noch einmal mit dem User reden, der dafür verantwortlich ist. Wenn er bereit ist, es rückzubauen, dann bin ich damit zufrieden. Andernfalls wäre ich auch für einen Revert. LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Hundekottütenspender tagging
Am 26. April 2015 um 00:24 schrieb Andreas Goss andi...@t-online.de: Hatten wir das nicht auf Tagging damals mit den Post Dingern schon diskutiert? Damals gabe es soweit ich mich erinnere keinen Vorschlag bei den ich gesagt hätte ja super passt. Ich wäre auch dafür vending_machiene durch einen größeren Überbegriff zu ersetzten, dann braucht man da nicht jedes mal zu diskutieren. Automat was ich finde am ehesten hinkommt gibt es im Englischen so wohl nicht. Wieso müssen denn Packstationen und Hundekottütenspender unbedingt denselben Haupttag erhalten? Geldautomaten haben ja auch einen anderen Haupttag, Parkuhren AFAIK auch. Sind das nicht dermaßen unterschiedliche Objekte dass unterschiedliche tags mehr Sinn machen würden? automat gibt es schon in Englisch, meistens wird allerdings machine benutzt (was auch Maschine heisst, je nach Kontext, nicht grundsätzlich Automat). Im Falle von Hundekottütenspendern sind das aber in den mir bekannten Fällen sowieso keine Automaten, sondern schlichte Spender, d.h. Behältnisse die dazu dienen, dass man bequem die Tüten entnehmen kann - ohne irgendeinen Automatismus, ohne elektrischen Strom und ohne Mechanik. Wie sollte Euerer Meinung nach der Weg sein, wenn man die tags ändern will? Proposal ins Wiki? Einfach das Wiki ändern, z.B. nach Ankündigung und unter Einhaltung entsprechender Fristen in denen man auch Einwände wartet? Falls das bisher nicht ganz klar geworden ist: Ich bin nicht auf der Suche nach einem allgemeineren Tag der den vending_machine tag komplett ablösen soll, sondern ich würde gerne die Dinge aus den Verkaufsautomaten rausnehmen, die auch keine Verkaufsautomaten sind, und dafür einen oder mehrere bessere(n) tag(s) einführen, von den derzeit auf der engl. Seite beschriebenen (vielen) Werten betrifft das lediglich diese 3-4: Hundekottütenspender, Paket/Postannahme- und -ausgabeautomaten, ggf. Spritzenautomaten, sofern die Spritzen kostenlos sind und man dazu weitgehend Einigkeit hat (ist ein bisschen ein grenzwertiger Fall). In allen anderen Fällen passt der tag auf das Objekt. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Removing redundant routing instructions
2015-04-26 13:35 GMT+02:00 Rob Nickerson rob.j.nicker...@gmail.com: I wonder whether it is possible to indicate this in OpenStreetMap so that routing engines can omit this redundant instruction. == Example picture == https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing I think you might be able to fix this with micromapping. If you add the detailed shape (i.e. the curve like it is signed on the road) of the junction topology it might be solved. It is a general issue in many cases that the junctions don't get modelled accurately (you can't determine from the drawn shape which road is continuous and which gets discharged into the other, because of oversimplification / bad generalization). Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
If you reread the original mail, then you'll see he already tried this himself and it did not work. On 27-04-15 10:46, Martin Koppenhoefer wrote: FWIW, I just wanted to fix the situation to give you an example, and someone else was faster, it is already fixed in the way I did suggest above: http://www.openstreetmap.org/#map=19/52.45290/-1.48908 Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
On 26/04/2015 12:35, Rob Nickerson wrote: In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. One simple way of representing this situation is to place give_way nodes on the subsidiary roads. Whether any routers or renderers make use of these to deduce that a particular route through the junction is the 'through route', I don't know. -- Steve --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
On 27/04/15 09:06, Steve Doerr wrote: In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. One simple way of representing this situation is to place give_way nodes on the subsidiary roads. Whether any routers or renderers make use of these to deduce that a particular route through the junction is the 'through route', I don't know. It does irritate me that OSMAND announces 'turn right onto A46' when I'm currently driving down the A46, and 'turn slightly left onto M5' when approaching a slip road to 'turn right onto A46'. There is NOTHING wrong with the tagging in OSM, it is purely how OSMAND handles each case which needs further work. Other satnav's do the same sort of thing in different areas, and around here many roads don't have road numbers, so when moving between sections of what is essentially the same road one gets directions about the junction. All that was missing from the tagging was an indication that it is the same road, so yes signs on the side junctions might help but it's up to the third party software to interpret that. The opposite side of the coin is when 'tomtom' tells me it's 50 miles to the next junction and I know I've got two or three major interchanges where I need to merge with other traffic. It just depends what one considers to be redundant. The example given says 'the white lines mark it as such', but if those white lines are warn or obscured by mud? The extra direction can ACTUALLY be helpful if it's a route one has not been before. It only becomes irritating when one is hearing it for the n'th time ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
The trouble with nodes is that they are non-directional. Junctions in quick succession, and lane-dependent give-ways could make a challenging scenario for a program to try and make sense of. Why not tag it explicitly instead of leaving it to heuristics which (by definition) will not always get it right? //colin On 2015-04-27 10:06, Steve Doerr wrote: On 26/04/2015 12:35, Rob Nickerson wrote: In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. One simple way of representing this situation is to place give_way nodes on the subsidiary roads. Whether any routers or renderers make use of these to deduce that a particular route through the junction is the 'through route', I don't know. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
As I understand it, there is an implied direction in that the convention is that the give_way node applies to the nearest intersection involving the way. But yes, I can see that involves extra computation. Steve On 27/04/2015 09:51, Colin Smale wrote: The trouble with nodes is that they are non-directional. Junctions in quick succession, and lane-dependent give-ways could make a challenging scenario for a program to try and make sense of. Why not tag it explicitly instead of leaving it to heuristics which (by definition) will not always get it right? //colin On 2015-04-27 10:06, Steve Doerr wrote: On 26/04/2015 12:35, Rob Nickerson wrote: In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. One simple way of representing this situation is to place give_way nodes on the subsidiary roads. Whether any routers or renderers make use of these to deduce that a particular route through the junction is the 'through route', I don't know. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-lt] JOSM prakalbo lietuviškai
Pagaliau JOSM prakalbo lietuviškai: http://blog.openmap.lt/2015/04/27/josm-lietuviskai/ ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Il y a deux choses à voir : - l'oeuvre à proprement parlé - les données. ODbL est une licence sur les données, alors que Creative Common concerne les œuvres (site, document etc.) A voir comment les administrateurs du site seraient donc prêt à partager les données. Dans tous les cas on ne peut pas interdire la modification de données dans OSM et encore moins une utilisation des données pour faire des supports commerciaux (La carte Michelin est un bel exemple). ... A discuter donc entre le CA d' OSM et les administrateur du site. C'est vrai que les données sont super intéressantes. Il y a même le statut de réalisation (construction, terminé) Le 27 avril 2015 13:39, dHuy Pierre dh...@yahoo.fr a écrit : Il n'y a pas SA donc pour moi on peut changer la licence à l'export. À confirmer. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND ( https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-nl] http://forum.openstreetmap.nl
Toch fijn dat het iemand opvalt. Ik heb inderdaad een stofkam door alle osm.nl verwijzingen gehaald. De website is een volgende stap tot opschoning. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-fr] Bano, BAN, Ripart et IGN
Le 27/04/2015 13:37, Jean-Christophe Becquet a écrit : Le 24/04/2015 00:19, Christian Quest a écrit : Google n'est pas près d'utiliser de l'ODbL, ils ont même tenté de manipuler quelques collectivités dernièrement à ce sujet... mais ça a capoté, heureusement ! Bonjour, À ce sujet, voir notamment : http://www.dignelesbains.fr/2014/11/digne-prend-position-face-a-google/ et le courrier de l'association Opendata France à Google : http://www.dignelesbains.fr/wp-content/uploads/2014/11/Courrier-Google.pdf Ce dont je parle est beaucoup plus récent (ces dernières semaines)... donc Google ne lâche pas le sujet et risque de revenir à la charge car ces données sont intéressantes pour eux. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bano, BAN, Ripart et IGN
Le 24/04/2015 00:19, Christian Quest a écrit : Google n'est pas près d'utiliser de l'ODbL, ils ont même tenté de manipuler quelques collectivités dernièrement à ce sujet... mais ça a capoté, heureusement ! Bonjour, À ce sujet, voir notamment : http://www.dignelesbains.fr/2014/11/digne-prend-position-face-a-google/ et le courrier de l'association Opendata France à Google : http://www.dignelesbains.fr/wp-content/uploads/2014/11/Courrier-Google.pdf Bonne continuation Librement JCB -- Les logiciels libres pour les collectivités locales et les administrations http://www.apitux.org/index.php?2007/07/05/178-les-logiciels-libres-pour-les-collectivites-locales ==APITUX : le choix du logiciel libre== APITUX - Jean-Christophe Becquet BP 32 - 04001 Digne-les-Bains Cedex 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com/ SIRET : 452 887 441 00031 - APE : 6202A === ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Voici la compatibilité des licences (du plus ouvert au moins ouvert) http://creativecommons.org/examplessachant que OSM est en CC-BY-SA http://www.openstreetmap.org/copyright pour la publication. Pour la publie c'est pas compatible en tous cas. Le 27 avril 2015 13:52, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Il y a deux choses à voir : - l'oeuvre à proprement parlé - les données. ODbL est une licence sur les données, alors que Creative Common concerne les œuvres (site, document etc.) A voir comment les administrateurs du site seraient donc prêt à partager les données. Dans tous les cas on ne peut pas interdire la modification de données dans OSM et encore moins une utilisation des données pour faire des supports commerciaux (La carte Michelin est un bel exemple). ... A discuter donc entre le CA d' OSM et les administrateur du site. C'est vrai que les données sont super intéressantes. Il y a même le statut de réalisation (construction, terminé) Le 27 avril 2015 13:39, dHuy Pierre dh...@yahoo.fr a écrit : Il n'y a pas SA donc pour moi on peut changer la licence à l'export. À confirmer. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] points de vente SNCF en opendata
Salut, Je bosse à SNCF Transilien et j'essaye de répertorier tous les tags qu'on a en gare. Il manque en effet un référentiel précis pour les gares, j'y travaille ... - J'utilise shop=ticket pour une boutique, avec les détails qui vont avec : operator=SNCF wheelchair=yes; limited; no - J'utilise tourism=information avec information=office pour l'accueil / le point d'information, toujours avec : operator=SNCF wheelchair=yes; limited; no @JB je suis d'accord que c'est difficile distinguer un office de tourisme dans ces conditions, mais j'ai beau chercher et je ne trouve rien de plus satisfaisant pour l'instant ... si vous avez des idées je suis preneur. librement, -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Osmose QA available on Germany (english)
Frédéric Rodrigo fred.rodrigo at gmail.com writes: We have finish the coverage of Germany by Osmose QA. Thank you for this. Osmose made me find a few errors in my area, I wouldn't have found without this nice tool. Great job! Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Il n'y a pas SA donc pour moi on peut changer la licence à l'export. À confirmer. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance 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-ar] Invitación a flisol. Charla y mapping party? (Juan Martin)
Hola Agustin como salio todo finalmente?, lamento mucho mi partida antes de tiempo el sábado. Les mando un abrazo y mapeare algo en la semana y les consulto. seguimos en contacto Gus El 24 de abril de 2015, 16:53, Gus Urban gusunava...@gmail.com escribió: hola yo puedo ir de 12.45 a 14 ... aclaro que también iría como un aprendiz mas. abrazo para todos gus El 24 de abril de 2015, 16:49, Juan Martin Muguerza jua...@gnutn.org.ar escribió: El Thu, 23 Apr 2015 12:41:37 -0300 Agustin Rissoli aguztin...@gmail.com escribió: Yo pienso ir a eso de la 1, portátil no tengo, pero bueno vemos ¿alguien mas que vaya y vamos acomodando un horario? Tal vez podríamos mejorar la zona ¿les parece si llevo unos walking papers? Entre 12:45 y 2pm es un muy buen horario para estar, ya que es el receso y no va a haber otras charlas o talleres. Mucha gente va a andar dando vueltas y se pueden acercar para saber mas de OSM y tal vez sumarse a la mapping party. Si querés lleva walking papers, y si hay quorum pueden salir a mapear la zona, o sino quedan como exposición. Mañana vemos si se puede trasladar la mapping party a un lab o nos dan netbooks. De última, va a estar mi notebook disponible que tiene JOSM instalado. Cristian Paez y Gus Urban por acá habían comentado que le interesaba ir, y entre los organizadores de flisol hay un par más interesados. Nos vemos! ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] SOTM 2016 @ ULB
Dear All, About SOTM 2016, I have asked the ULB about availability. I am thinking about the rooms in building K and H where most of Fosdem and RMLL have taken place. The person in charge tells me === Vu les besoins en locaux, il faut oublier la période septembre/octobre/novembre. Cela sera tout simplement impossible. Est-ce que vendredi 29, samedi 30 et dimanche 31 juillet 2016 pourrait convenir ? == What do you think about such dates for SOTM 2016 ? Thanks -- Nicolas Pettiaux, phd - nico...@pettiaux.be Open@work - Une société libre utilise des outils libres «Apprendre aux élèves à utiliser les produits privateurs de Microsoft, Google ou Oracle, c'est comme leur apprendre à fumer. C'est leur donner une habitude coûteuse, dangereuse et dont ils se déferont difficilement.» Richard Stallman ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM 2016 @ ULB
tant que c'est pas avant le 10 juillet ... https://fr.wikipedia.org/wiki/Championnat_d%27Europe_de_football_2016 Le 27 avril 2015 14:39, Nicolas Pettiaux nico...@pettiaux.be a écrit : Dear All, About SOTM 2016, I have asked the ULB about availability. I am thinking about the rooms in building K and H where most of Fosdem and RMLL have taken place. The person in charge tells me === Vu les besoins en locaux, il faut oublier la période septembre/octobre/novembre. Cela sera tout simplement impossible. Est-ce que vendredi 29, samedi 30 et dimanche 31 juillet 2016 pourrait convenir ? == What do you think about such dates for SOTM 2016 ? Thanks -- Nicolas Pettiaux, phd - nico...@pettiaux.be Open@work - Une société libre utilise des outils libres «Apprendre aux élèves à utiliser les produits privateurs de Microsoft, Google ou Oracle, c'est comme leur apprendre à fumer. C'est leur donner une habitude coûteuse, dangereuse et dont ils se déferont difficilement.» Richard Stallman ___ 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
Re: [OSM-talk] Removing redundant routing instructions
On Mon Apr 27 15:07:45 2015 GMT+0100, Marc Gemis wrote: As long as the name (or the ref/int_ref) of the street remains the same, I think the router should be able to give other messages than turn right. There is no need for an additional relation IMHO. There is often no ref, or name. If there is a name it will often change. Phil (trigpoint ) On Mon, Apr 27, 2015 at 12:06 PM, Lester Caine les...@lsces.co.uk wrote: On 27/04/15 10:45, p...@trigpoint.me.uk wrote: == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Why do I find that confusing? Currently in general the directions ignore corners even if there are roads going off those corners. The complaint is about 'extra' directions where the corner is actually the main road and the straight on branch is the turning. If the directions remain silent one would in some conditions get confused so the safe thing to do is announce both? The correct wording of the the directions should be perhaps 'road bares right' and 'go straight on' rather than 'turn right' but that does need the perhaps missing through_route information? As I said, the inclusion of road names in OSMAND while useful at times does get similarly annoying when a 'continue on Axxx' would suffice. In this case the road id provides the through_route information ... one remains on the same road ... and the straight on road has a different one which may just be 'minor road'. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Sent from my Jolla ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Sidewalks
pmailkeey . schrieb: I've always considered OSM to be two maps - a geographic and a routing. And actually, when you look deeper, both is wrong. It's first and foremost a database of geographic information, out of which both a map (of various styles) and a routing graph can be constructed - and probably even more than that. KaiRo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
As long as the name (or the ref/int_ref) of the street remains the same, I think the router should be able to give other messages than turn right. There is no need for an additional relation IMHO. m On Mon, Apr 27, 2015 at 12:06 PM, Lester Caine les...@lsces.co.uk wrote: On 27/04/15 10:45, p...@trigpoint.me.uk wrote: == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Why do I find that confusing? Currently in general the directions ignore corners even if there are roads going off those corners. The complaint is about 'extra' directions where the corner is actually the main road and the straight on branch is the turning. If the directions remain silent one would in some conditions get confused so the safe thing to do is announce both? The correct wording of the the directions should be perhaps 'road bares right' and 'go straight on' rather than 'turn right' but that does need the perhaps missing through_route information? As I said, the inclusion of road names in OSMAND while useful at times does get similarly annoying when a 'continue on Axxx' would suffice. In this case the road id provides the through_route information ... one remains on the same road ... and the straight on road has a different one which may just be 'minor road'. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Osmose QA available on Germany (english)
The tool is powerful and useful (and it detected correctly some of my errors). Thank you! The critical remarks made by Simon and Martin are basically requests for better wording or category, i.e. warning/potential error instead of error. Any such instrument has this potential side effect and can be improved with time. Volker (Padova, Italy) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Great Lakes Boundaries
Mike, Thanks for doing this! It sounds like a much bigger ordeal than I had originally thought. -- Jim On Sun, Apr 26, 2015 at 8:47 AM, Mike Thompson miketh...@gmail.com wrote: All, Since no objection to removing natural=water from the Lake Superior relation has been expressed, I have removed it. I also amended the note on the relation asking that it not be added back in. Mike On Sat, Apr 25, 2015 at 9:08 PM, David Fawcett david.fawc...@gmail.com wrote: Inland sea... On Apr 25, 2015, at 8:19 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 24.04.2015 um 17:23 schrieb AJ Ashton aj.ash...@gmail.com: Yes, if Lake Superior is mapped as natural=coastline (which I think is the easier-to-maintain approach for such a large complex water body) then we should remove natural=water from the multipolygon relation (r4039486). Does anyone have any objection to this? It's causing some noticeable rendering issues both in the standard style and for data consumers. yes, if the coastline tag remains it seems logical to remove the natural=water tag. Semantically the coastline tag on a freshwater lake is clearly wrong, but it seems to be an accepted compromise in this case: http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline#What_about_lakes.3F cheers Martin ___ 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 ___ 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: [OSM-talk] Removing redundant routing instructions
I should have written then there is no need (with then when there is a name or ref that stays the same) in the other cases you need a relation. On Mon, Apr 27, 2015 at 4:18 PM, p...@trigpoint.me.uk wrote: On Mon Apr 27 15:07:45 2015 GMT+0100, Marc Gemis wrote: As long as the name (or the ref/int_ref) of the street remains the same, I think the router should be able to give other messages than turn right. There is no need for an additional relation IMHO. There is often no ref, or name. If there is a name it will often change. Phil (trigpoint ) On Mon, Apr 27, 2015 at 12:06 PM, Lester Caine les...@lsces.co.uk wrote: On 27/04/15 10:45, p...@trigpoint.me.uk wrote: == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Why do I find that confusing? Currently in general the directions ignore corners even if there are roads going off those corners. The complaint is about 'extra' directions where the corner is actually the main road and the straight on branch is the turning. If the directions remain silent one would in some conditions get confused so the safe thing to do is announce both? The correct wording of the the directions should be perhaps 'road bares right' and 'go straight on' rather than 'turn right' but that does need the perhaps missing through_route information? As I said, the inclusion of road names in OSMAND while useful at times does get similarly annoying when a 'continue on Axxx' would suffice. In this case the road id provides the through_route information ... one remains on the same road ... and the straight on road has a different one which may just be 'minor road'. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Sent from my Jolla ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
Won't work in the UK as there are plenty of cases where you have to give way and make a proper turn in order to stay on the same road name and/or ref. The concept even has a name - TOTSO which means Turn Off To Stay On. http://en.wikipedia.org/wiki/User:Martinvl/TOTSO You cannot reliably infer from the geometry and name/ref which road (or lanes) has to give way. The only way to improve the navigation instructions is by giving hints. This is not a routing question - nobody here is discussing which road is the best way to MyTown - it's about how you present the router's choices to the user. //colin On 2015-04-27 16:07, Marc Gemis wrote: As long as the name (or the ref/int_ref) of the street remains the same, I think the router should be able to give other messages than turn right. There is no need for an additional relation IMHO. m On Mon, Apr 27, 2015 at 12:06 PM, Lester Caine les...@lsces.co.uk wrote: On 27/04/15 10:45, p...@trigpoint.me.uk wrote: == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? And more importantly, if you need to turn off onto the minor road going straight ahead it remains 'silent'. I have occasionally used a through_route relation in these cases, but lack of support from routers does make it seem futile. Much like the via way relation, that one is so needed too. Why do I find that confusing? Currently in general the directions ignore corners even if there are roads going off those corners. The complaint is about 'extra' directions where the corner is actually the main road and the straight on branch is the turning. If the directions remain silent one would in some conditions get confused so the safe thing to do is announce both? The correct wording of the the directions should be perhaps 'road bares right' and 'go straight on' rather than 'turn right' but that does need the perhaps missing through_route information? As I said, the inclusion of road names in OSMAND while useful at times does get similarly annoying when a 'continue on Axxx' would suffice. In this case the road id provides the through_route information ... one remains on the same road ... and the straight on road has a different one which may just be 'minor road'. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact [1] L.S.Caine Electronic Services - http://lsces.co.uk [2] EnquirySolve - http://enquirysolve.com/ [3] Model Engineers Digital Workshop - http://medw.co.uk [4] Rainbow Digital Media - http://rainbowdigitalmedia.co.uk [5] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [6] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [6] Links: -- [1] http://lsces.co.uk/wiki/?page=contact [2] http://lsces.co.uk [3] http://enquirysolve.com/ [4] http://medw.co.uk [5] http://rainbowdigitalmedia.co.uk [6] https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Sidewalks
Roland Olbricht schrieb: our current pedestrian routers often don't give street names, but instead only instructions like look for the line on the map. To improve that I would like to encourage mappers to give separately mapped footways their proper name instead of leaving them without name. The only correct way to put that into a clean DB model would be to create a relation that has the name on it *once* and has all pieces as members to which the name applies, including all pieces of street, sidewalk, etc. Now that is considered impractical by most people due to the editing strain (we know how likely people already mess up relations right now). Also, note that what you propose needs actual change of the current renderers as they do not at this time ignore the multiple names but instead make maps look really ugly (well, most separately mapped sidewalks make the map look ugly in current renderers). KaiRo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] Evento de mapeamento na USP São Carlos
Pessoal, Hoje fizemos um evento de mapeamento humanitário com os estudantes da USP São Carlos para o Nepal e Xanxerê (aparentemente os estudantes se concentraram mais no Nepal): http://www.agora.icmc.usp.br/site/?p=922 Agradeço muito ao Wille que fez um webinar introdutório aos estudantes, mesmo com o aviso em cima da hora, muito obrigado! Espero que tenhamos ajudado os esforços humanitários e ganhado alguns novos mapeadores para a comunidade OSM Brasil. Abraços, João Porto ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-pt] Recuperação de dados em Viana do Castelo
Aproveito este e-mail para deixar um desafio amigável a alguem mais famirilizado com o OSM para fazerem um tutorial de como reverter um certo changeset. Embora eu já tenha uns anos nesta comunidade é algo que nunca consegui aprender devido à documentação do Wiki oficial, ser algo difusa e na minha opinião insuficiente para se perceber na totalidade o processo. Fica o desafio pois gostava de eu próprio por vezes corrigir erros semelhantes ao defeito neste e-mail em vez de ter que vir pedir para a lista. Certamente não serei o único com este interesse. Cumprimentos Em 28/04/2015 00:40, Marcos Oliveira marcosoliveira.2...@gmail.com escreveu: Olá Topo Lusitania, Reverti a changeset 30430108, a floresta e a área residencial já voltam a aparecer no mapa. [1] Obrigado Mazezito pelo aviso e à Topo Lusitánia pela notificação! [1] https://www.openstreetmap.org/changeset/30563880 No dia 28 de abril de 2015 às 00:08, Topo Lusitania Lusitania topolusita...@yahoo.com escreveu: Caros Reencaminhamos a mensagem para os peritos em recuperar dados Cumprimentos Quote Olá topolusitania, Mazezito http://www.openstreetmap.org/user/Mazezito enviou-lhe uma mensagem através do OpenStreetMap com o assunto Resolução de Problemas em Viana do Castelo: == Boas consegues resolver os estragos que um utilizador causou em Viana do Castelo? Ele eliminou uma área florestal e residencial. https://www.openstreetmap.org/changeset/30430108 Já mandei uma mensagem a ele mas não obtive resposta e eu não sei reparar “changesets”. Comprimentos Maze Unquote A equipa TopoLusitania ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt -- Um Abraço, Marcos Oliveira ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [Talk-pt] Recuperação de dados em Viana do Castelo
101% a favor! Em 28/04/2015 00:55, Marcos Oliveira marcosoliveira.2...@gmail.com escreveu: Rui e restantes membros, São a favor da criação de um tópico na wiki portuguesa que explique de forma sucinta conceitos que podem ser úteis a todos como reversões, conflações, evitação de conflitos, etc? No dia 28 de abril de 2015 às 00:49, Rui Oliveira racoqs...@gmail.com escreveu: Aproveito este e-mail para deixar um desafio amigável a alguem mais famirilizado com o OSM para fazerem um tutorial de como reverter um certo changeset. Embora eu já tenha uns anos nesta comunidade é algo que nunca consegui aprender devido à documentação do Wiki oficial, ser algo difusa e na minha opinião insuficiente para se perceber na totalidade o processo. Fica o desafio pois gostava de eu próprio por vezes corrigir erros semelhantes ao defeito neste e-mail em vez de ter que vir pedir para a lista. Certamente não serei o único com este interesse. Cumprimentos Em 28/04/2015 00:40, Marcos Oliveira marcosoliveira.2...@gmail.com escreveu: Olá Topo Lusitania, Reverti a changeset 30430108, a floresta e a área residencial já voltam a aparecer no mapa. [1] Obrigado Mazezito pelo aviso e à Topo Lusitánia pela notificação! [1] https://www.openstreetmap.org/changeset/30563880 No dia 28 de abril de 2015 às 00:08, Topo Lusitania Lusitania topolusita...@yahoo.com escreveu: Caros Reencaminhamos a mensagem para os peritos em recuperar dados Cumprimentos Quote Olá topolusitania, Mazezito http://www.openstreetmap.org/user/Mazezito enviou-lhe uma mensagem através do OpenStreetMap com o assunto Resolução de Problemas em Viana do Castelo: == Boas consegues resolver os estragos que um utilizador causou em Viana do Castelo? Ele eliminou uma área florestal e residencial. https://www.openstreetmap.org/changeset/30430108 Já mandei uma mensagem a ele mas não obtive resposta e eu não sei reparar “changesets”. Comprimentos Maze Unquote A equipa TopoLusitania ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt -- Um Abraço, Marcos Oliveira ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt -- Um Abraço, Marcos Oliveira ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [OSM-talk] JOSM Tile Cache
Paul, I tested version 8287. I can go ahead and submit a bug report, but wanted to let you know the results directly. It seems that refreshed Mapnik tiles will only show up after they show up in a browser window open to www.openstreetmap.org. Let me explain. I make a change with JOSM, upload it and then, with Mapnik as the imagery layer, right click on the image and click Flush Tile Cache. The screen flickers, but the tiles appear the same. I repeat the Flush Tile Cache several times over the next few minutes with the same result. I go to the browser (Chrome 42.0.2311.90 m) window open to www.openstreetmap.org the same area and zoom level, and hit F5. Updated tiles are displayed. I then return to JOSM, Flush Tile Cache and then the updated tiles are displayed in JOSM as well. To attempt to prove that it isn't just coincidence, I have repeated the whole test a number of times with the same results. Is it possible that JOSM uses the same tile cache as Chrome (but is unable to flush it directly)? MIke On Sun, Apr 26, 2015 at 8:26 AM, Mike Thompson miketh...@gmail.com wrote: Paul, Thanks for your reply and for the information. I test with the development version. Mike On Sun, Apr 26, 2015 at 8:20 AM, Paul Hartmann phaau...@gmail.com wrote: Hi Mike, There has been a major rework of the TMS cache back end in version 8168-8186. If you can still reproduce this problem with the current development build or with the upcoming release, then please don't hesitate to report it directly on the JOSM bug tracker! Paul On 23.04.2015 22:58, Mike Thompson wrote: I am using JOSM version 8109 on Windows 7. I would like to flush JOSM's OpenStreetMap (Mapnik) tile cache. With the OpenStreetMap (Mapnik) layer displayed, I right clicked on the map, and then clicked on Flush Tile Cache, but I still see outdated tiles (when compared to the openstreetmap.org website - I made sure both were on the same zoom level). I also tried, in conjunction with the above, removing and re-adding the OpenStreetMap (Mapnik) layer, as well as restarting JOSM. Finally I tried renaming the OpenStreetMap (Mapnik) folder in the following location: C:\Users\username\AppData\Local\JOSM\cache\tms (this is the location the imagery.tms.tilecache preference is set to). Only after doing this were the tiles updated. Does the Flush Tile Cache work? I saw a bug report[1] about something like this, but it was closed four years ago as fixed. If it is working, am I using it correctly? Thanks, Mike [1] https://josm.openstreetmap.de/ticket/6109 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
I'd call this mostly a routing presentation issue. If the road name is the same, I'd want any super sharp curve to warn me: Tight left in 100 meters, or 15mph left turn ahead. The very fact of the OSM geometry ought to be enough to calculate the necessary warning. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
Ahoj, -- Původní zpráva -- Od: Petr Vozdecký v...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 4. 2015 23:18:48 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Ahoj, diky za odpovedi, ale pro uplnost si dovoluji dodat, ze na toto jsem se ne zcela ptal. Tyto tagy totiž zmiňované WAYe již mají. Podstatou dotazu byly ty casti textu, ktere byly oznaceny otaznikem: 1) mam navazne nadzemni a podzemni casti scelit relaci? Pokud ty dvě cesty mají společný uzel (a to by měly mít), tak ne. 2) mam vodni tok mizejici pod zemi scelit podzemnim vedenim toku i kdyz jde jen o tuseny tok? Myslím, že jo. Na tu tušenou část přidej fixme=. Něco jako potřebuje zpřesnit nebo pouze odhad. Marián S diky vop -- Původní zpráva -- Od: xkomc...@centrum.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 4. 2015 22:51:23 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Zdárek, 1) část v trubce označit jako tunnel=culvert + layer=-1 2) občasný tok označit tagem intermittent=yes Obojí se dokonce v současnosti vykresluje na hlavní mapě xkomczax __ Od: Petr Vozdecký v...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27.04.2015 22:44 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi ahoj, diky za odpovedi. Mluvim asi o detailech, ktere nejsou importovany. Piditoky, pidipritoky apod. Ziskane odpovedi vygenerovaly dalsi dotazy: 1) mam tok, ktery mizi pod povrchem, je to zatrubnena cast. Mam to tedy (v navaznosti na info o nutnosti routovat) s ostatnimi castmi spojit relaci? 2) mam tok (navic evidentne obcasny), ktery mizi pod povrchem a po desitkach metru se zase vynoruje. Neni to ale zadne propadani ani jiny klasicky podzemni krok, proste se do te doby regulerni tok v malem koryte doslova vsakne do zeme a zase se objevi o velky kus dal... neni to zadna umela meliorace, ale prirodni jev v lese. Mapoval jsem to jako WAY pak nic a pak WAY. To je ale teoreticky z hlediska routovani taky spatne...? vop -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 27. 4. 2015 14:32:51 Předmět: Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi Dne 26.4.2015 v 21:33 Petr Vozdecký napsal(a): Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Cus, viz predchozi, + starsi diskuse v konferenci. Vodni tok by mel vzdy zacinat u pramene a koncit u soutoku/v mori. Bez ohledu na to, jestli ma nebo nema v ceste nejaky nadrze. Jinak to neni pouzitelny pro navigace ani pripadnou analyzu rozvodi ... Ostatne, drtiva vetsina vodnich toku v CR byla do OSM importovana, takze pokud to je nekde jinak, tak to leda znamena, ze to nekdo rozbil. A to rozbijeni muze byt dany tim, ze nekde nejaky reneder vykresli osy nad plochama = v tom rybnice je to pak videt = nekteri si myslis, ze je to spatne. S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz= -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz; ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-gb-westmidlands] Ghoists igns
Is anyone tagging ghost signs: https://en.wikipedia.org/wiki/Ghost_sign around the West Midlands? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [OSM-talk] Removing redundant routing instructions
On 27 April 2015 at 13:52, Lester Caine les...@lsces.co.uk wrote: On 27/04/15 13:17, pmailkeey . wrote: Is the 'through route' and 'the same road' the same thing ? and does it mean that the road number stays the same or that you do not cross the white paint ? One of the routes I follow regularly is an old Roman cross road which is straight, but crosses several more major roads with give way or stop at every junction. It is the one B class road, but crosses white paint at every junction. So there is not a general rule that can be applied. The place 'through route' would be helpful is where a road bends at a junction, and the main route route is not straight on. In the example given, the road name changed and if there is no road reference to override that then either you announce the turn, or you need something else to switch it off? I think the answer is that less ambiguous terminology is needed. 'Turn off' and 'stay on' are ambiguous. Also, instructions relying on something else aren't good, e.g. Follow 'A1'. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-it] sentieri - accessibilità ciclistica/pedonale
Ciao, In zone rurali/forestali spesso si vedono sentieri (highway=path) con tag bicycle=yes o foot=yes senza altre restrizioni di divieto. Ha senso lasciare tali tag ? Lo chiedo perchè opencyclemap per esempio disegna path con bicycle=yes con colore blu, al pari di una pista ciclabile quando invece si tratta di un semplice sentiero, magari anche poco indicato per utilizzo ciclistico che non sia mtb, a mio avviso generando un po' di confusione. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Removing redundant routing instructions
On 27/04/15 16:49, pmailkeey . wrote: On 27 April 2015 at 13:52, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: On 27/04/15 13:17, pmailkeey . wrote: Is the 'through route' and 'the same road' the same thing ? and does it mean that the road number stays the same or that you do not cross the white paint ? One of the routes I follow regularly is an old Roman cross road which is straight, but crosses several more major roads with give way or stop at every junction. It is the one B class road, but crosses white paint at every junction. So there is not a general rule that can be applied. The place 'through route' would be helpful is where a road bends at a junction, and the main route route is not straight on. In the example given, the road name changed and if there is no road reference to override that then either you announce the turn, or you need something else to switch it off? I think the answer is that less ambiguous terminology is needed. 'Turn off' and 'stay on' are ambiguous. Also, instructions relying on something else aren't good, e.g. Follow 'A1'. As I said ... 'turn onto A46' when one is already on the A46 ... As long a one has an identifier that matches before and after a junction, then the speech set CAN change. Where you have a traffic route that has road names then it should perhaps be optional to use the road names and while the 'A' route gives 'stay on', the change of road name gives the 'over junction to yyy'. With unnamed roads then something else would be needed to identify the through_route, but if that is an extra tag, or just 'give way' on the other connections just needs some agreement. While we don't 'tag for the routers', a few common ground rules that ensure that how a junction is navigate can be consistently 'routed' would not hurt and is just sensible data to be included in the database. From a rendering point of view it should allow the 'white lines' to be added even if they don't physically exist. While a give way should have road markings, often these days it IS only a sign. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-gb-westmidlands] Ghoists igns
I believe White Lady may be covering these Cheers Andy -Original Message- From: Andy Mabbett [mailto:a...@pigsonthewing.org.uk] Sent: 27 April 2015 16:47 To: talk-gb-westmidlands Subject: [Talk-gb-westmidlands] Ghoists igns Is anyone tagging ghost signs: https://en.wikipedia.org/wiki/Ghost_sign around the West Midlands? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-es] Mapping response for the Nepal earthquake HOT
Hola a todos, Disculpad el cross posting Desde geoinquiets estamos organizando mañana 28 de abril de 2015 un mapathon[1] para ayudar con las tareas del HOT [2] Por temas organizativos estaría bien que los que vayan a asistir avisen por esta vía o se apunten la wiki[1]. [1] https://wiki.openstreetmap.org/wiki/Barcelona/Events/Barcelona_HOT_Nepal_Earthquake_Mapathon_1 [2]https://wiki.openstreetmap.org/wiki/2015_Nepal_earthquake -- Saludos, Bolo www.geoinquiets.cat ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-it] sentieri - accessibilità ciclistica/pedonale
2015-04-27 18:16 GMT+02:00 Francesco Lotti lottif...@gmail.com: In zone rurali/forestali spesso si vedono sentieri (highway=path) con tag bicycle=yes o foot=yes senza altre restrizioni di divieto. Ha senso lasciare tali tag ? Lo chiedo perchè opencyclemap per esempio disegna path con bicycle=yes con colore blu, al pari di una pista ciclabile quando invece si tratta di un semplice sentiero, magari anche poco indicato per utilizzo ciclistico che non sia mtb, a mio avviso generando un po' di confusione. penso che ha senso lasciare i tags (ci dicono che qualcuno ha controllato queste proprietà). Invece il problema del rendering sembra da parte di OCM (dovrebbe renderizzare bicycle=designated/official in quel modo, e non un solo bicycle=yes). Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Sidewalks
2015-04-27 16:43 GMT+02:00 Robert Kaiser ka...@kairo.at: The only correct way to put that into a clean DB model would be to create a relation that has the name on it *once* and has all pieces as members to which the name applies, including all pieces of street, sidewalk, etc. there is a kind of informal guideline that states you shouldn't use relations for things that can be expressed with a tag (e.g. relations like all streets of type x in a country b should be omitted because you don't gain anything more than is already in the db). Redundancy (like repeating the name on the parts) is more stable than a relation (also because relations are not handled very well by some editing programs, and the concept seems more complex for new mappers than simple tags are). OSM is likely not a clean DB model in your sense, at least it prefers redundancy and transparency over complexity and formal simplicity. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] sentieri - accessibilità ciclistica/pedonale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 27/04/2015 18:16, Francesco Lotti ha scritto: Ciao, In zone rurali/forestali spesso si vedono sentieri (highway=path) con tag bicycle=yes o foot=yes senza altre restrizioni di divieto. Ha senso lasciare tali tag ? Lo chiedo perchè opencyclemap per esempio disegna path con bicycle=yes con colore blu, al pari di una pista ciclabile quando invece si tratta di un semplice sentiero, magari anche poco indicato per utilizzo ciclistico che non sia mtb, a mio avviso generando un po' di confusione. Per i sentieri, generalmente esiste il tag mtb=*, laddove la larghezza del sentiero permette. bicycles=* lo vedo un tag utile solo dove il sentiero o strada rurale sia tale da consentire il passaggio a biciclette generiche, mentre mi soffermerei su mtb=* nel caso di sentieri un pò impervi, mi sembra più realistico. Per le restrizioni, bisognerebbe conoscere le località ed i cartelli del posto, per cui non mi pronuncio. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVPmp7AAoJEMTPIIVov0ZtOWwH/RwTDWeBwOkA+G4ynqK6oep4 KKkyfZXcvdsXT6dxqEtSIOAcsZPYFMyHhObCc4Y/UxWgUAEWEe9vGmObN7+F4IRW DKR6aaQeMUETXL5Joi5k0XS5keXeTR4rtNONfHSVbIzRd+VROXgBDIE2OsBVuza0 e6rlGnx8Idu6nFle3qe3d09wGZxR45gL49GYaLFV6Ojkeoq91rKtIufwPbJCjROU Ai0RV1hTyAOZwjxhUis770MQLyc/vruWj7QAIJGPwWk0KY6ykEQDdYQcHKVfHqIQ J6XJ54uJ9fAYrW+NmrnAMxujUOl/qmS00+shfl6McCiT5T42UCYKK8j7v2DiyDk= =MeB8 -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-pt] Recuperação de dados em Viana do Castelo
Olá Topo Lusitania, Reverti a changeset 30430108, a floresta e a área residencial já voltam a aparecer no mapa. [1] Obrigado Mazezito pelo aviso e à Topo Lusitánia pela notificação! [1] https://www.openstreetmap.org/changeset/30563880 No dia 28 de abril de 2015 às 00:08, Topo Lusitania Lusitania topolusita...@yahoo.com escreveu: Caros Reencaminhamos a mensagem para os peritos em recuperar dados Cumprimentos Quote Olá topolusitania, Mazezito http://www.openstreetmap.org/user/Mazezito enviou-lhe uma mensagem através do OpenStreetMap com o assunto Resolução de Problemas em Viana do Castelo: == Boas consegues resolver os estragos que um utilizador causou em Viana do Castelo? Ele eliminou uma área florestal e residencial. https://www.openstreetmap.org/changeset/30430108 Já mandei uma mensagem a ele mas não obtive resposta e eu não sei reparar “changesets”. Comprimentos Maze Unquote A equipa TopoLusitania ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt -- Um Abraço, Marcos Oliveira ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [Talk-de] Hundekottütenspender tagging
On 2015-04-27 at 11:03 +0200 Martin Koppenhoefer wrote: Im Falle von Hundekottütenspendern sind das aber in den mir bekannten Fällen sowieso keine Automaten, sondern schlichte Spender, d.h. Behältnisse die dazu dienen, dass man bequem die Tüten entnehmen kann - ohne irgendeinen Automatismus, ohne elektrischen Strom und ohne Mechanik. Wie es schon andere geschrieben haben sehe ich auch vending_machine als ein Ding, aus dem man sich andere Dinge herausholen kann. Im Unterschied zu einen Laden. Strom, Mechanik, ein Automatismus oder Geld spielen dabei keine Rolle. Das diese vier Eigenschaften bei den uns bekannten Hundekottütenspendern nicht vorkommen heißt ja auch nicht, dass es nicht welche gibt, die wie richtige Automaten funktionieren und Geld nehmen. Ich sehe daher kein Problem mit dem aktuellen Tagging. Gruß Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hundekottütenspender tagging
Am 27. April 2015 um 19:40 schrieb Holger Mappt holger...@gmx.net: Wie es schon andere geschrieben haben sehe ich auch vending_machine als ein Ding, aus dem man sich andere Dinge herausholen kann. was sagst Du zu den Paket-/Briefabgabestationen? Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [talk-latam] A los amigos chilenos que han comenzado la traducción del Semanario OSM (weeklyosm)
Olá Carlos Alonso, Olá Julio y todos, first of all I apolgise to write in English, but my Spanish is not good enough to explain, what I would like to explain. Why I'm anwering only today and not earlier? Because I had to travel to A Guarda to talk :( (and map :) ) with the students who translated until now the weeklyOSM from English into Spanish. For those who hadn't heard about this us, that is our page: www.weeklyoem.eu In this interview http://www.weeklyosm.eu/overcoming-language-barriers-with-openstreetmap- the German Wochennotiz (our siterproject - in which I am working since some years) did with the team from weeklyOSM, you can read more about weeklyOSM. If you have any question, don't hesitate to ask. ;-) 2015-04-22 22:44 GMT+02:00 Julio Costa Zambelli julio.co...@openstreetmap.cl: Estimado Carlos, Gracias por la comunicación y el tono. A pesar de que he leído varias de las traducciones anteriores, no estaba al tanto de que esto fuera parte de un programa financiado y/o coordinado por la Comisión Europea. Well, the Comenius Project http://wiki.openstreetmap.org/wiki/MychOSM is financed by the European Comission, not weeklyOSM. ;-) Please see, that the wikipage is under heavy contruction http://wiki.openstreetmap.org/wiki/ES:MychOSM. ;-) (Read more about the money in the interview above!) Within this project the weeklyOSM is *one* of the products. De hecho daba por sentado que eran voluntarios traduciendo el trabajo de quienes reemplazaron a Pascal y Dennis. Yes, we are all volunteers, mainly students who translate under the guidance of teachers. :) ... Nor the students, neither the teachers are payed for this work. The idea from the beginning was to transfer the project into the hands of the OSM community. You can see that, because JP, FR and CZ entered ... as we all volunteers and not payed. ;-) La intención no es duplicar tareas o devaluar el trabajo de nadie, ... but that happend a little bit with our young students. :( ... and to be fair - me as the pedagocial advisor - may say it, the students in Spain, they do a great job to translate *every week* the German Wochennotiz. sino que poner al día la traducción, que hasta este momento llevaba dos boletines de desfase respecto de la versión en Ingles y tres respecto de la Alemana. ... and this happened, because teachers are working with students :) ... and sometimes the workflow is not as efficient as it should be. ;-) ... and because Carlos Alonso had to move to England to work with our team on other Esto no es critica, mal podríamos hacerla nosotros que varias veces acumulamos muchas semanas de desfase respecto del boletín que publicaban Neis y Zielstra. If you read Pascals last edition of weekly, you should know the nmaes of Madalina and me. ;-) Respecto de la fuente y procedimiento, ha sido la misma aplicada a los boletines que se publicaban hasta el año pasado, una vez anunciada la versión en Ingles (la que ustedes publican en http://www.weeklyosm.eu), se traduce al Castellano. Lamentablemente no hay voluntarios disponibles, que hablen alemán, para seguir al boletín original en su última versión. Therefore, and we are working as a whole group of translators, we would invite you to join the group and help us and the students to go forward. ;-) Si esto realmente afecta al proyecto que llevan con la Comisión y significará un daño para ustedes, por favor házmelo saber y no publicaremos la traducción de los siguientes números. In a certain way it affects our project. You are right, but in an other way it affects the project not, because we have in mind to overhand it to the community. ;-) - What we really did with the French, the Japanese and Czech part. Once again, you are very welcome to join the group, like Andy from UK, who joind the team and does a very good job in reviewing each version. Saludos, Julio Costa Zambelli Saludos cordiales desde A Guarda -- ## Manfred Reiter - - ## www.weeklyOSM.eu ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 27/04/2015 13:17, Vincent Frison a écrit : De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Bonjour, Peut-être utiliser l'argumentaire Libérez vos créations pour essayer de les faire changer d'avis ? http://www.apitux.org/index.php?2008/05/03/232-liberez-vos-creations Des explications sur les licences Creative Commons et des infos pour aller plus loin sur : http://www.apitux.org/index.php?2005/09/11/11-les-licences-creative-commons Bonne continuation Librement JCB -- Des formats ouverts pour des données libres http://www.apitux.org/index.php?2006/07/09/107-des-formats-ouverts-pour-des-donnees-libres ==APITUX : le choix du logiciel libre== APITUX - Jean-Christophe Becquet BP 32 - 04001 Digne-les-Bains Cedex 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com/ SIRET : 452 887 441 00031 - APE : 6202A === ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Pas de SA peut-être, mais ND: aucune oeuvre dérivée possible, on n'a donc le droit qu'à l'utilisation de l'original. Ajoute NC et cette version originale est aussi interdite à certaines utilisations. Bref non on ne peut pas changer de licence sur une copie à l'identique de l'original. SA c'est pour permettre le repartage (modifié ou pas), mais ne permet pas non plus un changement de licence. Cette oeuvre n'est donc pas libre, et CC-BY-NC-ND est en fait tout à fait comparable à une contenu sous copyright publié sur n'importe quel site web ne donnant aucune licence explicite, et placé par défaut sur la protection générale du copyright. C'est le même régime en fait que les cartes de Google Maps (gratuites et consultables pour un usage personnel ou une diffusion très limitée à l'identique, mais pas libre non plus et soumis aussi à des restrictions pour l'utilisation commerciale, qui nécessite l'acquittement de droits pour la licenc ou pour en faire des données dérivées, dont Google conserve les droits exclusifs). C'est le même régime que de nombreux freewares qui sont free as a beer (gratuits) mais pas libres et eux aussi resteints pour l'utilsiation commerciale. CC-BY-NC-ND ne sert à rien d'autre que de montrer que le contenu est protégé, en offrant un lien ver sune page pour le dire explicitement (et cela ne sert que dans les rares pays où le régime du copyright ne s'applique pas par défaut mais où le régime serait plus permissif). Globalement cela ne sert que pour les utilisations dans les pays qui n'ont pas adhéré à la convention de Bern ou au WIPO (je ne suis même pas sûr que même en Corée du Nord cette licence soit utile, car si on y contrevient là-bas il n'y aura personne pour l'interdire ou recevoir une plainte). A mon avis CC devrait même supprimer le support de cette licence inutile et qui n'est pas dans ses missions de soutenir les contenus libres. Le 27 avril 2015 13:39, dHuy Pierre dh...@yahoo.fr a écrit : Il n'y a pas SA donc pour moi on peut changer la licence à l'export. À confirmer. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND ( https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Modello lettera mancata attribuzione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 26/04/2015 19:50, Carlo Stemberger ha scritto: Il giorno 26 aprile 2015 19:00, girarsi_liste liste.gira...@gmail.com ha scritto: Chiedo, è da ritenersi una pagina che va bene anche ad uso internazionale? C'è già qualcosa: https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution/Example_email A mio avviso bisognerebbe fare un lavoro di integrazione per uniformare a livello internazionale. Ciao! Carlo P.S.: Mi son permesso di sostituire il vecchio contenuto su Google Docs con un link al wiki, per evitare che vengano apportate modifiche sulla vecchia pagina. Aiutandomi col traduttore, la nostra sembra fatta meglio, soprattutto dal punto di vista della licenza. Comunque credo sia un problema metterla nella parte italiana della pagina, perchè non mi pare gran che visibile per ricerca. Altrimenti bisognerebbe inserire un link con relativa spiegazione nel WikiProject Italy. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVPoFgAAoJEMTPIIVov0Ztl24H+wXYCZjQbrjYu2UslKBga0EV J8Lzy/56eX9398FwiBq7TVlc7tgC2C3ODXSHxKUWzTE/enfyCdvc8zvUJQ35nd2h nmFmcfdTp59WIAgDesfCyZXlq+FUoVNdpne4upYTJ+ALrNhIqda5NBskwU/vnIoO 8sRXXP2kOsJG3SUhLxPDXJpWXSWDJbtBceSJOdbbZpUGC/dRGbAwwxJbiXIYFkxb bQnzkYMzJ9OLVEiA0OP3NsLJX16BpEPoqNO9S/QyZADp1YWNGju5IpNU9xChGpi9 kkKTSLSYDrS9E/SwZhFdeFG9HVfvzukKgx0azDUyomupiYp06AkxRURDOLlIJ0w= =Ijht -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] FW: Participación de OpenStreetMap en el OpenExpo Day 2015
Remito email para ver si hay interesados en dar una charla sobre OSM en OpenExpo en Madrid. Date: Fri, 24 Apr 2015 12:36:04 +0200 Subject: Participación de OpenStreetMap en el OpenExpo Day 2015 From: ro...@openexpo.es To: oscar_zorri...@hotmail.com Buenos días Óscar, Encantado de e-saludarte. Mi nombre es Roman Mas, responsable de eventos de OpenExpo, una iniciativa que se encarga de realizar eventos mensuales sobre tecnologías open source y software libre. Me ha pasado tu contacto nuestro CEO, Philippe Lardy Actualmente, estamos preparando la II jornada nacional del OpenExpo Day, OpenExpo Day 2015, un evento que se celebrará el próximo 16 de junio en el Teatro Galileo de Madrid. La pasada edición, el OpenExpo Day llegó a alcanzar los más de 550 asistentes y contó con la colaboración de empresas como Microsoft Azure, WBS Solutions o Typo 3 entre otras. En este momento estamos elaborando y desarrollando el programa de contenidos del OpenExpo Day 2015, y sería un placer para nosotros que OpenStreetMap formara parte de la programación del evento realizando una charla, ponencia, keyspeak, etc. Así pues, quedo a la espera de saber si algún miembro o la persona responsable del equipo de OpenStreet Map estuviera interesado en participar en el evento y así formalizar una propuesta referente al contenido de programación. Gracias de antemano por tu colaboración. Un saludo, -- Roman Mas / Responsable de EventosMobile +34 634 578 258 Skype roman.mas ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-de] Hundekottütenspender tagging
On 2015-04-27 at 19:43 +0200 Martin Koppenhoefer wrote: Am 27. April 2015 um 19:40 schrieb Holger Mappt: Wie es schon andere geschrieben haben sehe ich auch vending_machine als ein Ding, aus dem man sich andere Dinge herausholen kann. was sagst Du zu den Paket-/Briefabgabestationen? Na da sollte man natürlich keine Hundekottüten hineintun. Da es Briefkästen als eigenständiges Objekt gibt ist das mit den Paketabgabestationen nicht so ganz konsistent. Andererseits gibt es viel mehr Briefkästen bzw. viel weniger Paketabgabe-/Packstationen, um dafür einen extra Tag zu benutzen. Also vending_machine eher als Selbstbedienungsdingens, egal ob raus oder rein. Muss da auch immer an den Vorschlag für eine Babyklappe denken: amenity=vending_machine, vending=living_baby_in. So lange es eindeutig ist und jeder weiß was gemeint ist geht es für mich in Ordnung. Ist halt nur ein Tag und keine Weltanschauung. Gruß Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Terremoto Nepal
Ciao Lista! Anche se superfluo, ricordo che ci sono dei task su HotOSM. Questo é taggato urgente http://tasks.hotosm.org/project/1006 -- cascafico.altervista.org twitter.com/cascafico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
