Re: [Talk-br] Relação Cidade
Parece que está tendo uma convergência boa para a definição aqui. Se não tiver alguma opinião muito diferente ou contrária eu crio uma regra de validação no JOSM para isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação Cidade
Em relação dos admin_level=3, 5, 6, 7, e 9 que não estampam admin_center, eles pode ter (e deve ter) um no com papel label concordo com admin_level=4 e 8 Aun Johnsen On Jun 13, 2015, at 21:35, Marcio - Thundercel thunder...@gpsinfo.com.br wrote: Minha opinião: Relação admin_level=4 ou 8 name=* type=boundary boundary=administrative admin_level=4 ou 8 admin_centre= ponto da cidade Relação admin_level=10 name=* type=boundary boundary=administrative admin_level=10 label= ponto do bairro Nó name=* place=* Os admin_level= 3, 5, 6, 7 e 9 não estampam admin_centre. Essas, na minha opinião, são as tags mínimas a serem incluídas nas relações citadas. A tag place só faz sentido para mim se empregada no nó e não na relação, até porque essa tag tem sentido de lugar (cidade) e não área (região administrativa - município). Há diferença entre cidade e município. Cidade refere-se só ao núcleo urbano. Município abrange tudo: o núcleo urbano e o rural. A área urbana do município, onde se encontra o marco zero, é que deve receber, na minha opinião, valores City, Town, etc. Quanto a tag population fico em duvida para inclusão de dados porque teremos a população do município (áreas urbana e rural) e a população só da área urbana. Já observei muitos dados estatísticos separando área rural de urbana. Não podemos esquecer o admin_centre na relação e tampouco o ponto de bairro incluído com a regra label na relação admin-level=10. []s Marcio -Mensagem Original- From: Tarcisio Oliveira Sent: Saturday, June 13, 2015 8:05 PM To: OSM talk-br Subject: [Talk-br] Relação Cidade Boa noite a todos, devido a ultima discussão sobre relações de cidades e como deve ser as coisas, sugiro uma padronização das relações de cidades. Quais as tags que deverão estar na relação e quais devem ficar no nó. Segue a minha opinião Relação name=* type=boundary boundary=administrative admin_level=* place=* population=* wikipedia=pt:* Nó name=* place=* population=* As tags duplicadas de place e populations são justificadas pois se ela o nó não seria renderizado, o que poderia gerar que ele fosse apagado varais vezes por não enxergarem nada nele. Tarcisio Oliveira ___ ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Some thoughts against remote mapping
Hi Russ, On Sat, Jun 13, 2015 at 2:01 PM, Russ Nelson nel...@crynwr.com wrote: Frederik Ramm writes: I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Western aid has a bad history of mostly aiding westerners. The one simple trick for avoiding that is to ask the locals How can I help? And if the locals say We need a better map for where we live, then that addresses your concern. What about in the situations where locals would like to make their own map but this is not financially feasible? If we are creating truly a free map of the entire world it is important to figure out how not to just make a map of the privileged. Should lack of access to internet and technology be a reason someone can't contribute to this map? I've worked with groups where we did on the ground mapping both through our own digitizing or through that of others. Honestly in most cases people were happy to not have to trace every building themselves. They could then simply put in the names/address information. Though we should think about what types of features and how we do our tagging where culture/experience can come in. For example what someone might think if as a track in their experience may be a secondary road in others. Frederik, Diversity to me has never just been gender. Though it has been shown that if you make a place welcoming to women it also makes it more inviting for other underrepresented groups. Intersectional feminism is about equality for everyone. For those that missed it Kathleen Danielson gave an excellent talk about some of these issues at SotM-US last week: http://stateofthemap.us/improving-diversity-in-osm/ -Kate ___ 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-it] Mappatura corretta pareti naturali/falesie per arrampicata
sent from a phone Am 13.06.2015 um 16:39 schrieb Davide Mangraviti davide...@inwind.it: Anche secondo me è così, come si può considerare struttura sportiva pitch in realtà è più ristretto e vuol dire proprio campo (sportivo) da una parte, ma è anche un termine specifico per arrampicata: https://en.m.wikipedia.org/wiki/Pitch_(ascent/descent) ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-br] Relação Cidade
border_type é outro assunto que vai vir um outro e-mail depois. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] classificação de subprefeituras.
2015-06-14 1:26 GMT-03:00 Lists li...@gimnechiske.org: São Paulo SP tem subprefeituras e distritos no admin_level 9 Vitoria ES tem distritos e subdistritos no admin_level 9 Essas coisas vão ser diferenciadas por border_type, já que não dá por admin_level (e justamente por isso precisa ver o que mais existe e definir border_types pro Brasil) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Some thoughts against remote mapping
Sometimes I wonder whether remote/armchair mapping has similar effects as imports to the growth of the local community. I think we have recognized that imports has a place in osm provided it follows community principles and guidelines. Maybe its time to discuss similar principles and guidelines to remote/armchair mapping? cheers, Maning Sambale (mobile) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Data sources for National Monument boundaries?
Check in the NPS IRMA Portal. They have most of their geospatial data on the site. If you don't find it, we have a mailing list for national parks, talk-us-nps that has some NPS employees on that might be able to help you. Clifford On Sat, Jun 13, 2015 at 7:46 PM, Ian McEwen ianmcorvi...@ianmcorvidae.net wrote: Hello; I'm hoping to map the proper boundaries of several of the newer National Monuments near me (Clinton made a bunch of them in AZ in his last months in office -- Ironwood Forest, Agua Fria, Vermillion Cliffs, Grand Canyon-Parashant, and Sonoran Desert National Monuments at least), but I'm struggling to find a data source I can use; some exist as points, but I'd prefer to expand them to proper boundaries, and clearly older and more established parks and monuments have mapped boundaries, presumably from some source. Does anyone know where this data is available/usable for OSM purposes? -- Ian ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
On 6/13/15 2:38 PM, Richard Fairhurst wrote: I've been finding this a really useful way of locating unreviewed TIGER and fixing it... it's actually quite addictive. :) Looking for roads which cross rivers, or with long sweeping curves, is an easy way of identifying quick wins. My modus operandi is to retag 2+-lane roads with painted centrelines as tertiary, smaller paved roads as unclassified, and just to take the tiger:reviewed tag off paved residential roads. Anything unpaved gets a surface tag and/or highway=track. i mostly like this. my big concern is that part of my personal approach to tiger review is double checking the names on the road signs and verifying any highway designations for any needed correction of the ref tags. on the flip side, tiger review is taking forever and maybe it's ok if that gets decoupled. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-br] Relação Cidade
Aun Johnsen, a relação admin_level=10 também deve ter um nó com papel label. Marcio -Mensagem Original- From: Lists Sent: Saturday, June 13, 2015 10:05 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Relação Cidade Em relação dos admin_level=3, 5, 6, 7, e 9 que não estampam admin_center, eles pode ter (e deve ter) um no com papel label concordo com admin_level=4 e 8 Aun Johnsen ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] classificação de subprefeituras.
Ola pessoas bonitas. Nesse sábado lindo estava deslumbrado com questões de níveis de administração (admin_level), e perguntei para o Nelsão que sugeriu que mandasse este e-mail. Bom em São Paulo temos as famosas e pouco compreendidas subprefeituras, as mesmas não figuram entre os admin_level. Vide lei que estabelece as subprefeituras: http://cm-sao-paulo.jusbrasil.com.br/legislacao/813361/lei-13399-02 Repare que elas englobam um ou mais distritos existentes. Neste caso como deveríamos proceder? ... usar o border_type? http://wiki.openstreetmap.org/wiki/Pt-br:Key:border_type Atenciosamente. -- *xico* *web developer at simbio.se http://simbio.se* *xico.simbio.se http://xico.simbio.se* ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Relação Cidade
Boa noite a todos, devido a ultima discussão sobre relações de cidades e como deve ser as coisas, sugiro uma padronização das relações de cidades. Quais as tags que deverão estar na relação e quais devem ficar no nó. Segue a minha opinião Relação name=* type=boundary boundary=administrative admin_level=* place=* population=* wikipedia=pt:* Nó name=* place=* population=* As tags duplicadas de place e populations são justificadas pois se ela o nó não seria renderizado, o que poderia gerar que ele fosse apagado varais vezes por não enxergarem nada nele. Tarcisio Oliveira smime.p7s Description: Assinatura criptográfica S/MIME ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação Cidade
Eu já deixo(aria) assim: Na relação: - type=boundary - boundary=administrative - admin_level - name - nó do lugar como admin_centre No nó: - name - place - population - wikipedia e possíveis outras tags Com exceção de nome (que é obrigatório), não tem duplicação de tag em 2 lugares. Todos aplicativos e renderizadores, até onde eu vi, conseguem entender e obter todas as informações que precisam (os que só entendem o nó do local conseguem renderizá-lo e os que já trabalham com relação também). Problema de duplicar tag em dois lugares é aparecer discrepância de valores (assim como já vejo acontecer com name). Por exemplo, place na relação estar dizendo city e no nó town, ou population com X em um lugar e Y no outro. Outra razão para não duplicar algumas tags, como population, é que ela indica população total do lugar. Se existe um limite com vários locais populados (um limite de cidade com vários distritos dentro, por exemplo), a tag population da relação nunca será (e nem deve ser) igual à population do nó que representa a cidade. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Very nice, Richard! One quick comment: I might not be the only who doesn't always change the tiger:reviewed tag when fixing TIGER-imported roads. I don't know if that's technically feasible, but maybe it would be better to check if a way has been modified since import, independent of the tiger:reviewed tag. I guess you could assign those a slightly lower priority than the ones that have tiger:reviewed=yes. Harald. On Sat, Jun 13, 2015 at 1:38 PM Richard Fairhurst rich...@systemed.net wrote: Hi all, At State of the Map US last weekend I was really pleased to unveil bicycle routing for the US (and Canada) at my site, cycle.travel. The planner, at http://cycle.travel/map , will plan a bike route for you between any two points - whether in the same city or on opposite sides of the continent. It's all based on OSM data but also takes account of elevation and other factors. I dogfooded it with a three-day ride around New York state after SOTM-US, and it found me some lovely quiet roads in and around the Catskills. I hope it'll be equally useful for the other two-wheelers amongst us. There's still a lot I want to add (as detailed at http://cycle.travel/news/new_cycle_travel_directions_for_the_us_and_canada ) but I hope you enjoy it. Plug aside, there's a couple of things might be relevant to US mappers. First of all, I'm aiming high with this - the aim isn't just to make the best OSM-powered bike router of the US, but the best bike router full stop for commuters, leisure cyclists and tourers. (I leave the athletes to Strava!) Here in Britain, experience over the years has been that good bike routing and good bike cartography - historically via CycleStreets and OpenCycleMap - are a really effective way of driving contributions to OSM. So if you know cyclists who aren't yet contributing to OSM, maybe throw this at them - and if it doesn't find the route they'd recommend, maybe there's some unmapped infrastructure they could be persuaded to add! Second, the routing and cartography both heavily distrust unreviewed TIGER. In other words, it won't route over a rural road tagged as highway=residential tiger:reviewed=no Any road with tiger:reviewed removed or altered, any road in urban areas, and any road with highway=unclassified or greater is assumed to be a usable paved road. (There are a few additional bits of logic but that's the general principle.) Unreviewed rural residentials are shown on the map (high zoom levels) as a faint grey dashed line, explained in the key as Unsurveyed road. I've been finding this a really useful way of locating unreviewed TIGER and fixing it... it's actually quite addictive. :) Looking for roads which cross rivers, or with long sweeping curves, is an easy way of identifying quick wins. My modus operandi is to retag 2+-lane roads with painted centrelines as tertiary, smaller paved roads as unclassified, and just to take the tiger:reviewed tag off paved residential roads. Anything unpaved gets a surface tag and/or highway=track. I can't promise minutely updates I'm afraid - the routing/map update process takes two full days to run so it'll be more monthly than minutely. But I hope you find it as useful as I do. You'll see there's a tiny little pen icon at the bottom right of http://cycle.travel/map which takes you to edit the current location in OSM. Finally, many thanks to everyone who's tested it so far, particularly Steve All - your feedback was and continues to be enormously useful. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-br] Relação Cidade
Minha opinião: Relação admin_level=4 ou 8 name=* type=boundary boundary=administrative admin_level=4 ou 8 admin_centre= ponto da cidade Relação admin_level=10 name=* type=boundary boundary=administrative admin_level=10 label= ponto do bairro Nó name=* place=* Os admin_level= 3, 5, 6, 7 e 9 não estampam admin_centre. Essas, na minha opinião, são as tags mínimas a serem incluídas nas relações citadas. A tag place só faz sentido para mim se empregada no nó e não na relação, até porque essa tag tem sentido de lugar (cidade) e não área (região administrativa - município). Há diferença entre cidade e município. Cidade refere-se só ao núcleo urbano. Município abrange tudo: o núcleo urbano e o rural. A área urbana do município, onde se encontra o marco zero, é que deve receber, na minha opinião, valores City, Town, etc. Quanto a tag population fico em duvida para inclusão de dados porque teremos a população do município (áreas urbana e rural) e a população só da área urbana. Já observei muitos dados estatísticos separando área rural de urbana. Não podemos esquecer o admin_centre na relação e tampouco o ponto de bairro incluído com a regra label na relação admin-level=10. []s Marcio -Mensagem Original- From: Tarcisio Oliveira Sent: Saturday, June 13, 2015 8:05 PM To: OSM talk-br Subject: [Talk-br] Relação Cidade Boa noite a todos, devido a ultima discussão sobre relações de cidades e como deve ser as coisas, sugiro uma padronização das relações de cidades. Quais as tags que deverão estar na relação e quais devem ficar no nó. Segue a minha opinião Relação name=* type=boundary boundary=administrative admin_level=* place=* population=* wikipedia=pt:* Nó name=* place=* population=* As tags duplicadas de place e populations são justificadas pois se ela o nó não seria renderizado, o que poderia gerar que ele fosse apagado varais vezes por não enxergarem nada nele. Tarcisio Oliveira ___ ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação Cidade
Verdade Ate algum municipios usando distrito (border_type=district) e outros subdistrito (border_type=subdistrict), e discobri que pelo menus Vitória ES usando ambos entre municipio (admin_level=8) e bairro (admin_level=10) Aun Johnsen On Jun 13, 2015, at 23:58, Blademir Andrade de Lima blademi...@hotmail.com wrote: É impossível querer padronizar o Brasil, porque existem realidades diferentes pra querer aplicar as mesmas regras no país inteiro. O admin_level:9 pode ser tanto aplicado em distritos como este aonde se usa 'border_type:district' http://www.openstreetmap.org/relation/5172637#map=12/-22.1896/-46.2210 http://www.openstreetmap.org/relation/5172637#map=12/-22.1896/-46.2210 , ou então pode ser usado quando um conjunto de bairros level 10 formam uma área suburbana. Até mesmo em dados oficiais (federais, estaduais ou prefeituras) existe confusão, e não conseguiremos harmonizar isto com o OSM. Minha cidade foi exemplo desta confusão de bairros, foi difícil passar pro OSM. Att, BladeTC From: thunder...@gpsinfo.com.br mailto:thunder...@gpsinfo.com.br To: talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Date: Sat, 13 Jun 2015 22:07:05 -0300 Subject: Re: [Talk-br] Relação Cidade Nelson, esqueci do Distrito (admin_level=9) e tampouco comentei sobre o admin_level=2 porque acredito ser esse ultimo óbvio. o 9, de distrito, deve ser semelhante a bairro (admin_level=10), Assim seria para o 9 e 10: Relação admin_level=9, 10 name=* type=boundary boundary=administrative admin_level=9 ou 10 label= ponto do distrito ou bairro Nó name=* place=districts ou suburb Seria muito util essa regra de validação no JOSM. []s Marcio -Mensagem Original- From: Nelson A. de Oliveira Sent: Saturday, June 13, 2015 9:47 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Relação Cidade Parece que está tendo uma convergência boa para a definição aqui. Se não tiver alguma opinião muito diferente ou contrária eu crio uma regra de validação no JOSM para isso. ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação Cidade
Nelson, esqueci do Distrito (admin_level=9) e tampouco comentei sobre o admin_level=2 porque acredito ser esse ultimo óbvio. o 9, de distrito, deve ser semelhante a bairro (admin_level=10), Assim seria para o 9 e 10: Relação admin_level=9, 10 name=* type=boundary boundary=administrative admin_level=9 ou 10 label= ponto do distrito ou bairro Nó name=* place=districts ou suburb Seria muito util essa regra de validação no JOSM. []s Marcio -Mensagem Original- From: Nelson A. de Oliveira Sent: Saturday, June 13, 2015 9:47 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Relação Cidade Parece que está tendo uma convergência boa para a definição aqui. Se não tiver alguma opinião muito diferente ou contrária eu crio uma regra de validação no JOSM para isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-us] Data sources for National Monument boundaries?
Hello; I'm hoping to map the proper boundaries of several of the newer National Monuments near me (Clinton made a bunch of them in AZ in his last months in office -- Ironwood Forest, Agua Fria, Vermillion Cliffs, Grand Canyon-Parashant, and Sonoran Desert National Monuments at least), but I'm struggling to find a data source I can use; some exist as points, but I'd prefer to expand them to proper boundaries, and clearly older and more established parks and monuments have mapped boundaries, presumably from some source. Does anyone know where this data is available/usable for OSM purposes? -- Ian pgpTDH6RvNVL4.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-br] Relação Cidade
Blad, não compreendi. A definição de Distrito é válida para todo o Brasil: * Significado de Distrito s.m. Divisão administrativa e territorial de um município que pode conter um ou vários bairros. * Em http://produtos.seade.gov.br/produtos/500anos/index.php?tip=defi podemos identificar: Distrito Divisão territorial e administrativa em que certa autoridade administrativa, judicial ou fiscal exerce sua jurisdição. ** Um Distrito tem um administrador subordinado ao Prefeito do Municipio. Um conjunto de bairros level 10 formando uma área suburbana e que não tenha administrador não caracteriza Distrito. From: Blademir Andrade de Lima Sent: Saturday, June 13, 2015 11:58 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Relação Cidade É impossível querer padronizar o Brasil, porque existem realidades diferentes pra querer aplicar as mesmas regras no país inteiro. O admin_level:9 pode ser tanto aplicado em distritos como este aonde se usa 'border_type:district' http://www.openstreetmap.org/relation/5172637#map=12/-22.1896/-46.2210 , ou então pode ser usado quando um conjunto de bairros level 10 formam uma área suburbana. Até mesmo em dados oficiais (federais, estaduais ou prefeituras) existe confusão, e não conseguiremos harmonizar isto com o OSM. Minha cidade foi exemplo desta confusão de bairros, foi difícil passar pro OSM. Att, BladeTC ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] classificação de subprefeituras.
Entao São Paulo SP tem subprefeituras e distritos no admin_level 9 Vitoria ES tem distritos e subdistritos no admin_level 9 Que mais? Aun Johnsen On Jun 14, 2015, at 01:21, Nelson A. de Oliveira nao...@gmail.com wrote: Aproveitem e embalem nisso aqui tudo o que precisa ser discutido de coisa diferente que existe no Brasil, como subdistrito. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] [Talk-ht] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Non c'est le début, Pour les classes elles sont entrain d'être discutées en ce moment. D'ou l'interet de participer car ils sont entrain d'affiner leur algorithme maintenant. Il y a 44 classes pour l'instant, ils veulent en faire moins pour être sur d'extraire régulièrement l'information . Rien n'empeche de discuter par région et voir avec eux directement. D'ou une phase de test ( Juillet - Septembre). https://hackpad.com/Nomenclature-Pour-classification-avec-Sentinel-m04lIl5jKr4 Pour l'instant le CNES / ESA se focalisent sur l'Europe. Mais la donnée sera disponible tous les mois sur d'autre zones. Aprés à voir si cela peut permettre d'alimenter la base de donnée OSM ou si c'est une couche à part. A + FredM https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Le 14 juin 2015 00:19, Severin Menard severin.men...@gmail.com a écrit : Salut Fred, Merci pour l'info ! C'est 15-20 classes pour l'ensemble du monde, de milieu désertique à équatorial, anthropisé ou non ? Comment cela s'est passé jusqu'à présent les imports de données de télédétection dans OSM ? Batch ou par objet ? Quid du recoupement avec les éventuels zonages existants ? Il y a déjà une méthodologie ? 2015-06-13 17:20 GMT+00:00 Frederic Moine frmo...@gmail.com: Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en Fiche Projet ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-ht mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Some thoughts against remote mapping
Hi, I'm known for being critical of armchair mapping by people with no personal connection tho the area being mapped. Whether done for fun, for money, or to help, I think that in most cases it is a bad idea that runs against the spirit of OSM. (I'm willing to concede that there are exceptions, and that sometimes doing something that's against the spirit may still be useful. But these are individual cases, to be carefully justified, and remote mapping should never become anyone's standard mode of contribution.) Until now I thought that the main exception, one that even I would have to accept, is mapping for humanitarian purposes. I was all the more surprised - positively surprised - to read this thoughtful essay by Erica Hagen, who founded Map Kibera: http://groundtruth.in/2015/06/05/osm-mapping-power-to-the-people/ I'd encourage everyone to read that. It questions some rarely questioned assumptions; it even says that mapping by locals doesn't really count if those locals are just doing it for the money (a sentiment that I've always felt but rarely dared to express, because who can expect locals in the poorest parts of the world to map for fun like privileged westerners do?). It also says that local isn't local if the locals from the wealthy city map the slum in their midst. I've tended to routinely associate the call for more diversity in OSM as mainly being one for levelling the gender playing field but this article goes much further. In some parts the article echoes a rather more acerbic posting written last month by Gwilym Eades, a university lecturer in London: http://place-memes.blogspot.de/2015/05/the-hubris-of-proactive-disaster-mapping.html which essentially accused humanitarian mapping (and as I would add, any remote mapping really) of homogenising, westernising, and colonising the map. I don't agree with everything written in these postings but they certainly deserve some wider audience, and that's why I am writing this here - since neither author is on these lists and I haven't seen their messages mentioned or quoted anywhere. I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Mappatura corretta pareti naturali/falesie per arrampicata
Anche secondo me è così, come si può considerare struttura sportiva una falesia per l'arrampicata? Non è che si confonde il fatto che vengono anche chiamate palestre? Si, ma in natura... Non vorrei che ci sia l'intenzionalità di mostrarle su OSM mapnik per il fatto che leisure=pitch viene renderizzato. Comunque ci si trova davanti ad una modifica in massa di tutti i tag climbing. Io non capisco...mah Sentiamo altri pareri -- View this message in context: http://gis.19327.n5.nabble.com/Mappatura-corretta-pareti-naturali-falesie-per-arrampicata-tp5848054p5848063.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Bulk] Mappatura corretta pareti naturali/falesie per arrampicata
-Original Message- From: Davide Mangraviti [mailto:davide...@inwind.it] Sent: sabato 13 giugno 2015 14:15 To: talk-it@openstreetmap.org Subject: [Bulk] [Talk-it] Mappatura corretta pareti naturali/falesie per arrampicata Mi sto trovando ultimamente a mappare le pareti naturali e le falesie attrezzate con chiodi, fittoni, spit ect... per l'arrampicata libera. Secondo me basterebbe come tag sport=climbing e il nome se lo ha ma vedo che qualcuno aggiunge anche leisure=pitch. Ma non c'è una struttura o un impianto... è corretta quindi l'aggiunta di quest'ultimo tag? Nel Wiki non è specificato nulla Generalmente il tag sport=* andrebbe sempre associato a qualcosa di fisico che descrive dove si pratica lo sport. Nel tuo caso, siccome si tratta di una struttura naturale, potrebbe essere più adatto un tag natural, come natural=cliff/rock/stone. Per descrivere come la parete è attrezzata, prova a scegliere un valore adatto alla sezione climbing styles sula pagina sport=climbing [1]. Anche climbing:bolted=* potrebbe applicarsi. [1] http://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Bulk] Mappatura corretta pareti naturali/falesie per arrampicata
natural = cliff c'è già, in quanto descrive l'andamento area dell'intera falesia. per gli altri tag che descrivo i gradi di difficoltà, il tipo di roccia ect... siamo daccordo ma vengono dopo.. rimane aperto il discorso del leisure = pitch che, a mio parere, non andrebbe. Alberto Nogaro wrote Generalmente il tag sport=* andrebbe sempre associato a qualcosa di fisico che descrive dove si pratica lo sport. Nel tuo caso, siccome si tratta di una struttura naturale, potrebbe essere più adatto un tag natural, come natural=cliff/rock/stone. Per descrivere come la parete è attrezzata, prova a scegliere un valore adatto alla sezione climbing styles sula pagina sport=climbing [1]. Anche climbing:bolted=* potrebbe applicarsi. [1] http://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing Ciao, Alberto ___ Talk-it mailing list Talk-it@ https://lists.openstreetmap.org/listinfo/talk-it -- View this message in context: http://gis.19327.n5.nabble.com/Mappatura-corretta-pareti-naturali-falesie-per-arrampicata-tp5848054p5848066.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-br] São Carlos, SP
Aun Johnsen, infelizmente não pode ver o vídeo. Nele mostro os problemas existentes no mapa do Brasil fornecido pelo http://garmin.openstreetmap.nl/ Os problemas existentes e ali mostrados são facilmente tratados a nível Mkgmap, em seus styles, o que infelizmente o mapa NL não faz, pelo menos para o Brasil. Está você testando a indexação por Rua, entretanto o problema ocorre na indexação por cidade / estado e não por Rua. Problemas de indexação por tipo de via ( Rua, Avenida, estrada, etc) são facilmente corrigidos pelo Mkgmap com o comando “x-split-name-index”. Renderizado com esse comando a busca por endereço se torna fácil sem a necessidade de se buscar digitando o tipo de via a frente do nome. Ele indexa com somente a digitação do nome, sem o tipo. De qualquer forma volto a solicitar que seja padronizado o emprego de tags nas relações boundary e nos POI de city, town, etc. Não existindo uma padronização se torna complicado a qualquer renderizador extrair dos dados alguma tag que vá refletir aquele objeto. Para terem noção do problema cito como exemplo o emprego do admin_centre na relação boundary. Os desenvolvedores do Mkgmap, por nossa solicitação, criaram uma regra nele de quando da existência do admin_centre na relação boundary, que a função add-poi-to-area não criasse um POI virtual no centro geométrico da área. Com essa ação passamos a não mais ter o POI da cidade duplicado no mapa, entretanto em alguns lugares do Brasil continua essa duplicação simplesmente porque o membro admin_centre não está incluído em algumas relações boundary, em especial do estado de São Paulo. Pelo que já lemos relação boundary no OSM é um fato relativamente recente em se comparando as outras funções. Talvez por isso o mapa para o Brasil ainda não foi totalmente ajustado as novas regras. Outra situação foi a apresentada para São Carlos – SP e outras cidades do estado. Muitos renderizadores ainda não tratam relações boundarys. Eles tratam os POI, os place=city, town, etc. Se observarmos a maioria das cidades do estado de São Paulo estão vinculadas as correspondentes relações boundary como admin_centre, entretanto não existe o POI da cidade tratado isoladamente, fora da relação, como é tratado o POI de Concórdia – SC citado. Nele, se observarem, existe como resultado da busca a relação boundary e o POI city. Vão dizer que o renderizador tem de se adaptar aos dados OSM e até concordo com essa ponderação, mas convenhamos que em não existindo um padrão fica difícil ao desenvolvedor do renderizador estabelecer uma regra para dos dados extrair o que é desejado. Se desejamos alavancar o OSM no Brasil sou de opinião que devemos nos esforçar em padronizar o emprego de tags e identificar erros grosseiros existentes no mapa. Felizmente mais utilizadores estão empregando o mapa COCAR e com isso estamos recebendo inúmeros “feedbacks” de erros existentes no mapa. Recentemente recebemos uma critica de um utilizador que reside em Ponte Nova – MG. Disse ele que não empregava o mapa COCAR porque não era loteável em sua cidade. Fomo verificar o porque e identificamos que o editor Elias Lopes desenhou as vias mas não as interligou nos entroncamentos. Enviamos mensagem para ele, mas infelizmente não nos respondeu. Decidimos então corrigir o problema interligando as vias, entretanto muitas continuam por serem interligadas como, por exemplo, http://www.openstreetmap.org/way/346557829 Outro utilizador, agora residente em São Luís – MA, também fez critica quanto ao roteamento pela cidade. Fomo identificar e realmente existem inúmeros problemas ali que aos poucos estamos corrigindo. Perdoem o desabafo, mas como abraçamos a causa e estamos divulgando o mapa OSM nos sites que administramos, acabamos por ser o receptor de elogios e também de críticas. []s Marcio From: Lists Sent: Saturday, June 13, 2015 9:02 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP Marcio Desculpa que nao pode ver o video voce me mando nem atualizar as mapas, to offshore Patagonia e meu conecao internet nao dar para ver youtube e nem baixar arquivos grandes. Bem, vejo algum de seus problemas sobre garmin.openstreetmap.nl, principalmente em calcular tempo nos roteamentos, como voce dis não uso regras especificas por brasil, que resultando velocidade padrão no autoestrada (highway=motorway) ser 250km/h, no trunk 130 e no primary 90km/h por exemplo. Mas seus problemas de indexacao não parecendo valido por esse mapa. Eu nao tem mapas do link ES que voce mandou e não pode relatar resultado ai. Como mapas do garmin.openstreetmap.nl indexando as ruas e POI certas, o problema com indexacao nao e no banco dados OSM, mas provavelmente nos regras voce utilizando. Antes de começar mexer com o banco dados, verificar se ha problemas indicados nos ferramentas QA que tem monte, e também verificar se problema também existe no outro fontes do mapa Garmin. Proximo vez voce encontrando
Re: [Talk-br] São Carlos, SP
Marcio Concordo que precisamos padronizar No seu exemplo de indexação do Concordia SC, bem no meu mapa do 29-03-2015 também parecendo indexado similante como São Carlos SP. Credito que o solução do mkgmap não duplicar o POI do relação e mais recente que o versão mkgmap utilizado por garmin.openstreetmap.nl http://garmin.openstreetmap.nl/ p gerar as mapas fim do marco. Como infelizmente nao dar atualizar meus mapas, que com os argumentos agora seria bem interessante, não tem como ver se isso fui resolvido, e se o garmin.openstreetmap.nl http://garmin.openstreetmap.nl/ continuaram usar um mkgmap antiga ou se eles resolvi atualizar também. E bom que utilizadores do COCAR dar feedback para pode melhorar a mapa, mas falto um ferramenta global para isso, tem muitos contribuintes que poderia ajudar se for gerenciado num maneira próprio. Temos muitos atividades que poderia ser melhorado com um task-manager, mas por enquanto precisamos gerenciar tarefas entre nos mesmo. Como ja disse muitos vezes, quando voce ha problemas com Garmin por um motivo ou outro, compartilhar informação sobre o que dar errado e o que voce esperava, para outros tenta reproduzir mesma, também como utilizador do Garmin quero mapa melhor. Eu não utilizando mapa COCAR por falta do arquivos em formato .gmap, que pode gerenciar diretamente entre meu computador (Mac) e meu aparelho GPS (Garmin Nüvi). Em quanto voce nao adicionar esse opção .gmap voce pode passa qualquer propaganda sobre mapa COCAR e eu ainda não vai utilizar, e mesmo eu vou continuar adicionar dados no OSM em forma que opticimando meu uso do garmin.openstreetmap.nl http://garmin.openstreetmap.nl/ Aun Johnsen On Jun 13, 2015, at 10:10, Marcio - Thundercel thunder...@gpsinfo.com.br wrote: Aun Johnsen, infelizmente não pode ver o vídeo. Nele mostro os problemas existentes no mapa do Brasil fornecido pelo http://garmin.openstreetmap.nl/ http://garmin.openstreetmap.nl/ Os problemas existentes e ali mostrados são facilmente tratados a nível Mkgmap, em seus styles, o que infelizmente o mapa NL não faz, pelo menos para o Brasil. Está você testando a indexação por Rua, entretanto o problema ocorre na indexação por cidade / estado e não por Rua. Problemas de indexação por tipo de via ( Rua, Avenida, estrada, etc) são facilmente corrigidos pelo Mkgmap com o comando “x-split-name-index”. Renderizado com esse comando a busca por endereço se torna fácil sem a necessidade de se buscar digitando o tipo de via a frente do nome. Ele indexa com somente a digitação do nome, sem o tipo. De qualquer forma volto a solicitar que seja padronizado o emprego de tags nas relações boundary e nos POI de city, town, etc. Não existindo uma padronização se torna complicado a qualquer renderizador extrair dos dados alguma tag que vá refletir aquele objeto. Para terem noção do problema cito como exemplo o emprego do admin_centre na relação boundary. Os desenvolvedores do Mkgmap, por nossa solicitação, criaram uma regra nele de quando da existência do admin_centre na relação boundary, que a função add-poi-to-area não criasse um POI virtual no centro geométrico da área. Com essa ação passamos a não mais ter o POI da cidade duplicado no mapa, entretanto em alguns lugares do Brasil continua essa duplicação simplesmente porque o membro admin_centre não está incluído em algumas relações boundary, em especial do estado de São Paulo. Pelo que já lemos relação boundary no OSM é um fato relativamente recente em se comparando as outras funções. Talvez por isso o mapa para o Brasil ainda não foi totalmente ajustado as novas regras. Outra situação foi a apresentada para São Carlos – SP e outras cidades do estado. Muitos renderizadores ainda não tratam relações boundarys. Eles tratam os POI, os place=city, town, etc. Se observarmos a maioria das cidades do estado de São Paulo estão vinculadas as correspondentes relações boundary como admin_centre, entretanto não existe o POI da cidade tratado isoladamente, fora da relação, como é tratado o POI de Concórdia – SC citado. Nele, se observarem, existe como resultado da busca a relação boundary e o POI city. Vão dizer que o renderizador tem de se adaptar aos dados OSM e até concordo com essa ponderação, mas convenhamos que em não existindo um padrão fica difícil ao desenvolvedor do renderizador estabelecer uma regra para dos dados extrair o que é desejado. Se desejamos alavancar o OSM no Brasil sou de opinião que devemos nos esforçar em padronizar o emprego de tags e identificar erros grosseiros existentes no mapa. Felizmente mais utilizadores estão empregando o mapa COCAR e com isso estamos recebendo inúmeros “feedbacks” de erros existentes no mapa. Recentemente recebemos uma critica de um utilizador que reside em Ponte Nova – MG. Disse ele que não empregava o mapa COCAR porque não era loteável em sua cidade. Fomo
Re: [Talk-br] São Carlos, SP
Tarcísio, parabéns pelo seu trabalho no Nordeste. Até agora não recebemos nenhuma crítica e tampouco identificamos problemas de indexação por lá. Já quanto a roteamento, que não tem relação com relação boundary, para o Nordeste recebemos críticas para a cidade de São Luis - MA. No mapa identificamos que o editor não se preocupou com sentidos (mão única), terminando a mesma via em sentido único e dando continuidade a ela em sentido duplo, sem nenhum acesso que permitisse ao condutor sair da via que terminava em sentido único contrário. Aos poucos estamos corrigindo os erros encontrados na cidade e incrementando com dados faltantes. Sem empregar o overpass-turbo já havíamos identificado a falta ou exagero de algumas tags nas relações boundary, em especial do estado de São Paulo e é essa padronização que estamos aqui solicitando. Gostei do dividir para conquistar. []s Marcio -Mensagem Original- From: Tarcisio Oliveira Sent: Saturday, June 13, 2015 9:36 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP thundercel se possível verifique a mesma situação com os estados do Nordeste, menos a Bahia(não editei por lá), pois verifiquei que quase todo o estado de são paulo falta algumas tags nas relações o que deve estar gerando esses erros. Algumas cidades que podem estar corretas, Jundiaí, Itatiba, Itupeva e outras que podem estar errado Valinhos, Vinhedo e Louveira. Se for isso mesmo, pode consertar o Estado todo com essa consulta http://overpass-turbo.eu/s/4li até mesmo os outros Estados ou então pegar todas as relações que apontaram esse problema no osmose https://etherpad.mozilla.org/9s9Xov2u2R e mesmo se não for esse o problema, estão todos convidados a consertar essas relações, dividir para conquistar né? Tarcisio Oliveira ___ ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] São Carlos, SP
Aun Johnsen, volto a comentar que no exemplo de Concordia – SC podemos observar no OSM que a cidade de Concordia é indexada isoladamente da relação boundary de Concordia. Ali identificamos 2 indexações: 1 – Limite de Município tendo a cidade como admin_centre devido a relação boundary dela. 2 – somente a cidade devido ao place=town dela Já para São Carlos e outras cidades do estado de São Paulo só existe indexação dos Limites administrativos. Não existe indexação das cidades isoladamente. No vídeo que apresentei mostro o mapa do Brasil renderizado em 10/06/2015 e disponível em http://garmin.openstreetmap.nl/ Independente de empregar uma versão Mkgmap antiga o http://garmin.openstreetmap.nl/ não tem regra específica para o Brasil. Para o Brasil ele emprega os styles default do Mkgmap que por não serem personalizados, indexam as cidades (admin_level=8) dentro das Mesorregiões (admin_level=5), ou Regiões Metropolitanas (admin_level=6), ou Microrregiões (admin_level=7). Como nos GPS não empregamos essas regiões, no mapa cocar comandamos no Mkgmap o “drop admin_level=5 =6 =7” dos dados baixados do OSM. Com isso a cidade é indexada dentro do estado e não da região admin_level mais próximo a abaixo 8. Infelizmente não sou programador, sou aviador. Assim que aprendermos a renderizar um mapa para MAC forneceremos esse mapa para essa plataforma. O importante é que estamos personalizando para o Brasil os styles do Mkgmap de forma a extrair e renderizar somente os dados empregados em GPS Garmin, entretanto está sendo difícil personalizar os styles se os dados existentes, em especial nas relações boundary, não estiverem padronizados. []s Marcio From: Lists Sent: Saturday, June 13, 2015 10:35 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP Marcio Concordo que precisamos padronizar No seu exemplo de indexação do Concordia SC, bem no meu mapa do 29-03-2015 também parecendo indexado similante como São Carlos SP. Credito que o solução do mkgmap não duplicar o POI do relação e mais recente que o versão mkgmap utilizado por garmin.openstreetmap.nl p gerar as mapas fim do marco. Como infelizmente nao dar atualizar meus mapas, que com os argumentos agora seria bem interessante, não tem como ver se isso fui resolvido, e se o garmin.openstreetmap.nl continuaram usar um mkgmap antiga ou se eles resolvi atualizar também. E bom que utilizadores do COCAR dar feedback para pode melhorar a mapa, mas falto um ferramenta global para isso, tem muitos contribuintes que poderia ajudar se for gerenciado num maneira próprio. Temos muitos atividades que poderia ser melhorado com um task-manager, mas por enquanto precisamos gerenciar tarefas entre nos mesmo. Como ja disse muitos vezes, quando voce ha problemas com Garmin por um motivo ou outro, compartilhar informação sobre o que dar errado e o que voce esperava, para outros tenta reproduzir mesma, também como utilizador do Garmin quero mapa melhor. Eu não utilizando mapa COCAR por falta do arquivos em formato .gmap, que pode gerenciar diretamente entre meu computador (Mac) e meu aparelho GPS (Garmin Nüvi). Em quanto voce nao adicionar esse opção .gmap voce pode passa qualquer propaganda sobre mapa COCAR e eu ainda não vai utilizar, e mesmo eu vou continuar adicionar dados no OSM em forma que opticimando meu uso do garmin.openstreetmap.nl Aun Johnsen___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] bano - nom de voie - point bleu
Effectivement, ce sont celles qui m'intéressent. Tu as tout compris... Se serait vraiment bien qu'on puisse récupérer cette information avec, éventuellement si elle existe aussi, le code Fantoir inscrit dans la relation. Par défaut, pour les autres, ne pourraient-ont pas récupérer l'identifiant du tronçon de la voie concernée (n'importe lequel ou le plus proche) ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/bano-nom-de-voie-point-bleu-tp5845781p5848058.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Mappatura corretta pareti naturali/falesie per arrampicata
sent from a phone Am 13.06.2015 um 14:15 schrieb Davide Mangraviti davide...@inwind.it: vedo che qualcuno aggiunge anche leisure=pitch. Ma non c'è una struttura o un impianto... pitch vuol dire campo sportivo, se non c'è non va messo ciao Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Some thoughts against remote mapping
I think you could extend this to saying we should let people live their own lives and not allow them access to things such as mobile phones until they have enough education to design their own. In Canada we have native people and the debate is always what services should you provide them with and what laws should apply. Realistically HOT mapping helps the NGOs and others to provide things such as Polio inoculations. I understand that some people on religious grounds feel that all inoculations should be banned. I personally don't subscribe to this view. I note that one article questions whether or not mapping buildings is of any value. The question has been raised in HOT circles and it depends on the project and the purpose of the project and whom the client is and what their requirements are. I think these days project managers are sensitive to the fact that asking for a million buildings to get mapped may mean the project is never completed or not completed within a reasonable time frame, we have HOT projects still uncompleted some years after they were first started that request buildings. The other thing of note is that often when an area is mapped multiple AID / NGO groups will use the map data. On balance I think that the HOT part of OSM provides value, the locals do not need to use the maps. The maps are much better when locals are involved but then you bring up the whole issue of how reliable is an OSM map? Often something is better than nothing. Cheerio John On 13 June 2015 at 10:37, Frederik Ramm frede...@remote.org wrote: Hi, I'm known for being critical of armchair mapping by people with no personal connection tho the area being mapped. Whether done for fun, for money, or to help, I think that in most cases it is a bad idea that runs against the spirit of OSM. (I'm willing to concede that there are exceptions, and that sometimes doing something that's against the spirit may still be useful. But these are individual cases, to be carefully justified, and remote mapping should never become anyone's standard mode of contribution.) Until now I thought that the main exception, one that even I would have to accept, is mapping for humanitarian purposes. I was all the more surprised - positively surprised - to read this thoughtful essay by Erica Hagen, who founded Map Kibera: http://groundtruth.in/2015/06/05/osm-mapping-power-to-the-people/ I'd encourage everyone to read that. It questions some rarely questioned assumptions; it even says that mapping by locals doesn't really count if those locals are just doing it for the money (a sentiment that I've always felt but rarely dared to express, because who can expect locals in the poorest parts of the world to map for fun like privileged westerners do?). It also says that local isn't local if the locals from the wealthy city map the slum in their midst. I've tended to routinely associate the call for more diversity in OSM as mainly being one for levelling the gender playing field but this article goes much further. In some parts the article echoes a rather more acerbic posting written last month by Gwilym Eades, a university lecturer in London: http://place-memes.blogspot.de/2015/05/the-hubris-of-proactive-disaster-mapping.html which essentially accused humanitarian mapping (and as I would add, any remote mapping really) of homogenising, westernising, and colonising the map. I don't agree with everything written in these postings but they certainly deserve some wider audience, and that's why I am writing this here - since neither author is on these lists and I haven't seen their messages mentioned or quoted anywhere. I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-co] pregunta: OpenStreetMap offline en un computador sin internet es posible?
Estimados todos Muchas gracias por las recomendaciones. Estoy preparando un documento con la descripción del proceso y lo compartiré en breve. Un abrazo Luis ___ Luis Hernando AGUILAR RAMIREZ | Information Management Officer | United Nations Mission for Ebola Emergency Response - UNMEER | aguil...@un.org | twitter: @luishernando | skype: qu1x0t3 | Tie-line ext 174-2104 | Tel: +233(0)540108014 Ghana | Tel +232(0)99500634 Sierra Leone Some of our tools: https://www.humanitarianresponse.info/disaster/ep-2014-41-gin http://ebolaresponse.un.org/un-mission-ebola-emergency-response https://ebolageonode.org https://data.hdx.rwlabs.org/ebola http://ors.ocharowca.info/ebola/ http://nerc.sl https://www.facebook.com/UNMEER http://www.youtube.com/playlist?list=PLrVWthPkPMmfQyLfKr-8idi4vn4T131p2 https://www.flickr.com/unmeer/ From: Leonardo Gutierrez [mailto:l...@nuevoartesano.com] Sent: Tuesday, June 9, 2015 9:22 PM To: OpenStreetMap Colombia Subject: Re: [Talk-co] pregunta: OpenStreetMap offline en un computador sin internet es posible? Gracias Marco Antonio, En caso de necesitarse el osmand tambien puede instalarse en una tablet con android. El 9 de junio de 2015, 12:23, Marco Antonio marcoantoniofr...@gmail.commailto:marcoantoniofr...@gmail.com escribió: 2015-06-09 11:46 GMT-04:00 Luis Hernando Aguilar aguil...@un.orgmailto:aguil...@un.org: Quisiera preguntarles si hay alguna forma de tener la cartografía de OpenStreetMap en un computador sin internet. ... Es necesario buscar por nombres de las calles o puntos de interés (tal cual en OSMAND) pero poderlo hacer en el computador. MapFactor: Navigator Free funciona desde una netbook aunque sólo con Windows (quizá con wine se pueda arrancar para GNU/Linux) utiliza la data de OSM y es totalmente offline. La actualización de la data es online. Hace mucho tiempo hice una prueba (2) pero sólo navegación.. funciona muy bien. La búsqueda indica que tiene pero no probé. Abrazos, Marco Antonio (1) http://navigatorfree.mapfactor.com/ (2) https://www.youtube.com/watch?v=FSsa1q_pIgU ___ Talk-co mailing list Talk-co@openstreetmap.orgmailto:Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [OSM-talk-fr] outil user-friendly pour taguer les horaires opening_hours
Merci pour ce retour, je vais commenter au fur et à mesure, en reprécisant le contexte : ça a été fait en 2h, c'est (pour l'instant) juste une ébauche ;) Le 13/06/2015 09:56, Philippe Verdy a écrit : C'est très moche oui, pas un problème sauf qu'on s'attend à une présentation façon tableau emploi du temps scolaire pour les ouvertures, une icone + pour scinder une tranche horaire en deux ou pour l'étendre aux jours précédents ou suivants de la semaine (on peut aussi tirer depuis bords du tableau si tu gères la souris, un plus compliqué que des boutons). Ce serait effectivement l'idéal, c'est plus complexe à mettre en place (il faut créer un widget dédié), mais ça doit bien pouvoir se faire en prenant le temps. Mais le résultat n'est pas terrible non plus quand on obtient Mo-Su 09:00-18:00; We off; Th off; Fr off; Sa off où les off peuvent être abrégés en We-Sa off... et même encore plus simplement : Su-Tu 09:00-18:00 C'est vrai, je n'avais pas vu ça. Cela vient de l'algorithme du plugin JOSM OpeningHoursEdit (il a le même comportement dans JOSM), donc à voir pour améliorer celui-ci en amont. D'ailleurs, on pourrait même imaginer créer une bibliothèque dédiée à cette question des horaires d'ouvertures, à la manière de opening_hours.js mais dans le sens saisie utilisateur - clé opening_hours. Tu sembles assumer que la commence commence uniquement le lundi (à la façon dont on numérote les semaines ISO y compris en France dans l'adminstration et la plupart des entreprises mais pas dans tous les métiers), mais les anglosaxons protestants et le judaïsme voient la semaine commencer un dimanche après la samedi de shabbat, les musulmans la voient commencer le samedi après le vendredi rituel). C'était par souci de simplicité, je connais ces aspects mais rien n'empêche actuellement quelqu'un de commencer par saisir le dimanche, il faut juste aller le chercher dans le menu déroulant. Si l'on raisonne dans l'autre sens, en souhaitant effectivement implémenter cet aspect là, il faut connaître au minimum la position de la personne (et extrapoler sur les coutumes locales), au mieux sa religion. Le dernier cas n'est pas envisageable, le premier cas donne des résultats variables (la position par localisation d'adresse IP vaut ce qu'elle vaut). Après il existe peut-être une autre solution implémentable, dans ce cas pourquoi pas :) La semaine légale varie d'un pays à l'autre (essentiellement selon la religion majoritaire), mais on devrait pouvoir définir un intervalle de jour de la semaine valide comme Sa-Tu signifiant samedi, dimanche, lundi et mardi alors que Tu-Sa signifie mardi, mercredi,... vendredi et samedi: l'énumération se fait toujours dans l'ordre croissant des jours de la semaine et peut passer sans problème d'une semaine légale à la suivante. À priori la syntaxe opening_hours le permet, il suffirait de l'implémenter. Autant que possible éviter les off pour les jours de fermeture hebdomadaires (par exemple en France de nombreux commerces comme coiffeurs ou boulangers sont fermés le lundi on indique Tu-Su ce qui positionne dimanche en fin de l'intervalle, mais d'autres sont fermés plutot le dimanche et on indique Mo-Sa pour les ouvertures). Le off devrait plutôt être utilisé pour indiquer les périodes saisonnières ou exceptionnelles de fermeture (par exemple pour une fermeture en congés scolaires ou un mois de l'année, ou les jours fériés officiels, ou pour certaines dates religieuses mobiles non fériées dans les services publics mais qui peuvent l'être dans le privé, par exemple durant ou à la fin du mois de Ramadan, ou des fêtes relatives aux différentes dates de Pâques selon les églises, ou le nouvel an chinois). C'est certain que si on peut éviter d'avoir trop de off la clé sera plus lisible. Si l'ouverture est uniquement saisonnière une petite mineure de l'année (par exemple unqiuement en périuoide estivale, il faut le mettre dans le premier attribut avec la plus grande période d'ouverture hebdomadaire. Si c'est ouvert tous les jours (même avec des différences horaires certains jours, cette première période ne devrait même mentionner aucun jour de la semaine). Dans de nombreux services ne pratiquant pas la journée continue, la période matinale est la même tous les jours d'ouverture et seul l'après-midi varie uniquement par l'horaire de fermeture en fin de journée : on a intérêt alors à grouper ensemble les matinées et séparer les après-midi mais souvent ça se limite à un seul des jours hebdomadaire d'ouverture et on crée une entrée séparée pour ce jour (typiquement pour le vendredi après-midi en France quand samedi et dimanche sont fermés): on sépare alors le vendredi des autres jours lundi-jeudi, et on ne met rien pour samedi et dimanche qui sont déjà off par défaut dès qu'un attribut *:open_hours=* est utilisé pour mentionner les périodes d'ouverture) D'une façon générale on doit privilégier en premier l'écriture des
Re: [Talk-de] tunnel überlagert Buildings auf osm.org
Am 13.06.2015 um 06:49 schrieb Andreas Labres: On 12.06.15 13:46, Holger Jeromin wrote: Nein, es gibt verschiedene Ebenen welche nacheinander gerendert werden. Erst Ozean, dann alle landuse, dann alle Häuser, dann Straßen (oder halt so ähnlich). Naja, das ist ja genau, was ich schrieb: erst Flächen (Ozean, landuse, Häuser), dann Linien (Straßen, Wege, usw.) und Punkte. Das will man ja in einer Straßenkarte auch, dass man eine unterirdisch verlaufende Straße sehen will. Das ist richtig. In Karten ist es ja dann üblicherweise so, dass die Tunnelwand gestrichelt sichtbar bleibt, während die Straßenfläche des Tunnels unter den darüber liegenden Flächen zurückbleibt. Damit ist auch die Logik, dass Linien Flächen überlagern nicht kaputt. /al ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] outil user-friendly pour taguer les horaires opening_hours
C'est très moche oui, pas un problème sauf qu'on s'attend à une présentation façon tableau emploi du temps scolaire pour les ouvertures, une icone + pour scinder une tranche horaire en deux ou pour l'étendre aux jours précédents ou suivants de la semaine (on peut aussi tirer depuis bords du tableau si tu gères la souris, un plus compliqué que des boutons). Mais le résultat n'est pas terrible non plus quand on obtient Mo-Su 09:00-18:00; We off; Th off; Fr off; Sa off où les off peuvent être abrégés en We-Sa off... et même encore plus simplement : Su-Tu 09:00-18:00 Tu sembles assumer que la commence commence uniquement le lundi (à la façon dont on numérote les semaines ISO y compris en France dans l'adminstration et la plupart des entreprises mais pas dans tous les métiers), mais les anglosaxons protestants et le judaïsme voient la semaine commencer un dimanche après la samedi de shabbat, les musulmans la voient commencer le samedi après le vendredi rituel). La semaine légale varie d'un pays à l'autre (essentiellement selon la religion majoritaire), mais on devrait pouvoir définir un intervalle de jour de la semaine valide comme Sa-Tu signifiant samedi, dimanche, lundi et mardi alors que Tu-Sa signifie mardi, mercredi,... vendredi et samedi: l'énumération se fait toujours dans l'ordre croissant des jours de la semaine et peut passer sans problème d'une semaine légale à la suivante. Autant que possible éviter les off pour les jours de fermeture hebdomadaires (par exemple en France de nombreux commerces comme coiffeurs ou boulangers sont fermés le lundi on indique Tu-Su ce qui positionne dimanche en fin de l'intervalle, mais d'autres sont fermés plutot le dimanche et on indique Mo-Sa pour les ouvertures). Le off devrait plutôt être utilisé pour indiquer les périodes saisonnières ou exceptionnelles de fermeture (par exemple pour une fermeture en congés scolaires ou un mois de l'année, ou les jours fériés officiels, ou pour certaines dates religieuses mobiles non fériées dans les services publics mais qui peuvent l'être dans le privé, par exemple durant ou à la fin du mois de Ramadan, ou des fêtes relatives aux différentes dates de Pâques selon les églises, ou le nouvel an chinois). Si l'ouverture est uniquement saisonnière une petite mineure de l'année (par exemple unqiuement en périuoide estivale, il faut le mettre dans le premier attribut avec la plus grande période d'ouverture hebdomadaire. Si c'est ouvert tous les jours (même avec des différences horaires certains jours, cette première période ne devrait même mentionner aucun jour de la semaine). Dans de nombreux services ne pratiquant pas la journée continue, la période matinale est la même tous les jours d'ouverture et seul l'après-midi varie uniquement par l'horaire de fermeture en fin de journée : on a intérêt alors à grouper ensemble les matinées et séparer les après-midi mais souvent ça se limite à un seul des jours hebdomadaire d'ouverture et on crée une entrée séparée pour ce jour (typiquement pour le vendredi après-midi en France quand samedi et dimanche sont fermés): on sépare alors le vendredi des autres jours lundi-jeudi, et on ne met rien pour samedi et dimanche qui sont déjà off par défaut dès qu'un attribut *:open_hours=* est utilisé pour mentionner les périodes d'ouverture) D'une façon générale on doit privilégier en premier l'écriture des heures d'ouverture sur les périodes en jour les plus longues et les plus fréquentes, en affichant ensuite les jours supplémentaires sans utiliser off, puis seulement utiliser off pour les dates plus rares ou certaines périodes de l'année : la première entrée (séparée par point-virgule) doit correspondre à la période d'ouverture la plus longue (hors exceptions off listées à la fin) car c'est la première qu'on lira (même si une interface utilisateur la traduit en interprétant la donnée OSM) Le 12 juin 2015 22:47, PanierAvide panierav...@riseup.net a écrit : Pour le challenge, j'ai codé une petite interface, en regardant ce qui se faisait (de simple) par ailleurs. On trouve souvent le curseur que l'on déplace le long d'une journée pour faire un créneau horaire. Je vous présente donc YoHours, la petite interface web pour passer d'horaires compréhensibles par un humain au format opening_hours (compréhensible, mais moins) : http://github.pavie.info/yohours/ Pour l'instant c'est laid, mais ça fonctionne. La génération de la valeur opening_hours est largement basée sur l'algorithme utilisé par le plugin JOSM. Si ça présente un intérêt pour quelqu'un, je verrai pour faire une interface moins Web 0.1 ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Eisenbahn-Relation (controlled_area) ohne Typ
Hallo, Am 2015-06-13 um 07:37 schrieb goegeo: ich hab bei der JOSM Fehlerprüfung in meiner Region eine Relation entdeckt, bei der kein Relationstyp angegeben ist. Von JOSM wird er als Fehler und nicht als Warnung klassifiziert. Als Tags der Relation sind zwei Felder angegeben. - name=Jübek Bf - railway=controlled_area Mag sich jemand das mal mit anschauen? Bin mit ungewöhnlichen Relationen nicht sehr vertraut. Wie sollte damit umgegangen werden? Erstmal die Tags im Wiki suchen und/oder die Mailinglisten und Foren nach diesen Tags durchsuchen (mit einer Suchmaschine deiner Wahl). Allein schon die Suche im Wiki hätte dich auf diese Seite geführt: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging Dort steht, dass es ein veraltetes Tag für eine Stellbereichsrelation ist. Als Stellbereich bezeichnet man den räumlichen Bereich (meist ein Polygon), der von einem Stellwerk aus gesteuert wird. Das kann (bei alten mechanischen Stellwerken) ein kleiner Teil eines Bahnhofs sein, bei elektronischen Stellwerken (im Eisenbahnjargon ESTW genannt) können das auch mehrere Bahnhöfe sein. Vor Ort kann man das durch genaues Anschauen der Signale erkennen, entweder welche Nummer das Signal hat oder – bei Signalen/Weichen, die über Drahtzüge vom Stellwerk aus gestellt werden – wohin der Drahtzug führt. Die von dir genannte Relation ist, bei genauerem Betrachten eh kaputt (nicht wegen dem fehlenden type=railway, das bis vor ein paar Minuten in der deutschen Übersetzung des Taggingschemas gefehlt hat), sondern weil der User entweder das Wiki nicht gelesen hat oder einiges nicht gescheit verstanden hat (er hat auch iD benutzt). Ich habe ihm eine ausführliche PN geschrieben, da er auch andernorts zwischen Neumünster und Flensburg falsch getaggt hat. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Some thoughts against remote mapping
Hi, On 06/13/2015 05:00 PM, john whelan wrote: I think you could extend this to saying we should let people live their own lives and not allow them access to things such as mobile phones until they have enough education to design their own. Or perhaps even break that down to individual people... I'd probably have to relinquish my use of a computer then because I can't design one ;) Jokes aside, yes what you say is echoed in an acerbic comment under the acerbic post of Eades, where the commenter writes: It was far more fun when MSF volunteers had to guess where the latest poor sufferer was brought in from - at least any sketched map on a piece of scrap paper they had was a bottom-up sketched map and free from western hegemonic tyranny! Realistically HOT mapping helps the NGOs and others to provide things such as Polio inoculations. I understand that some people on religious grounds feel that all inoculations should be banned. I personally don't subscribe to this view. I guess one could make the point that the map is part of the aid, and withholding the map means withholding aid. But Erica Hagens's post can certainly not be reduced to the question of should religious beliefs be allowed to interfere with aid, it is much more nuanced than that. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Some thoughts against remote mapping
This is a very intersting discussion and something worth talking about. This should happen more. I think we should distinguish between remote mapping, or armchair mapping, and putting 'color' on the map. Most remote mappers will just trace basic stuff like buildings, roads or other features that can be easily recognized. I think this ethical dilemma should be more about the actual stuff that matters. For example, what name has an area, what name does a street have, what kind of shops have we mapped,... in other words the local communities should decide what's on the map but basically roads and buildings will have to traced anyway and the result will most likely be exactly the same. In my opinion locals should always have the last word on what's on the map. You could also argue that some communities don't want to be mapped for various kinds of reasons. That's something we should probably think about a little more in HOT. But I'm afraid there is very little we can do about it too. Any military operation, that's most likely very questionable when looking at the good it will do for locals, can use use OSM too. To summarize, I think a HOT activation does more good than bad because the 'color' of the map is the most important part but we should be carefull about specific cases because maybe someone out there has a bad experience after we traced their home and suddenly everybody can see there are people living there. Cheers, Ben ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] [Bulk] Mappatura corretta pareti naturali/falesie per arrampicata
Davide Mangraviti wrote natural = cliff c'è già, in quanto descrive l'andamento areale dell'intera falesia tutto intorno. per gli altri tag che descrivo i gradi di difficoltà, il tipo di roccia ect... siamo daccordo ma vengono dopo.. rimane aperto il discorso del leisure = pitch che, a mio parere, non andrebbe. Sì, anche secondo me va rimosso se si tratta di pareti naturali...comunque di aree non specificamente create per lo sport. Essendo la parete naturale secondo me non va messo. Hai contattato il mappatore che ha aggiunto quel tag? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Mappatura-corretta-pareti-naturali-falesie-per-arrampicata-tp5848054p5848079.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ht] [Hot-francophone] [OSM-talk-fr] Orfeo Tool box , Satellite Sentinelle
Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en Fiche Projet ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [OSM-talk-fr] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en Fiche Projet ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Some thoughts against remote mapping
These critiques seem to be beginning to develop themes explored more fully and famously by James Scott in _Seeing Like A State_. In it, he explores the implications of government efforts at systematization, including the original French cadastre and some German forest management projects. I'm afraid the news is worse than you might think, Frederik: Scott makes a compelling case that the *very act of mapping itself* snuffs out locally adapted systems of property management, social support and cultural exchange. It is a troubling critique and one that bears serious consideration. (It also carries vast and unwieldy intellectual coattails, including a deep connection to the failed anarchist project of the early twentieth century.) For my part, the value of being able to deliver emergency services, economic development and competent governance seem overwhelmingly worth the cultural costs that accompany efforts to rationalize the world. It seems to me that the verdict is in and we're all building a global society (and global map!). I'm skeptical that OSM should or can be a meaningful bulwark against this process. Local mapping is preferable not because it escapes the intellectual hegemony of mapping practices -- there is no escape from them at all if you are making a unified map -- but because it delivers a better map. And some map is better than no map: Does every building address need to be mapped? If not, it just seems like an easy win — why not collect everything? One reason not to is because later when you find you need local buy-in, even OSM may be viewed as an outsider project meant to dominate a neighborhood, a city, especially in sensitive neighborhoods where this has indeed been a primary use of maps. I wonder if people will one day want to create “our map” separately from OSM. A different global map wiki which is geared toward self-determination, perhaps? That would be a major loss for the OSM community. This struck me as shortsighted. The author is suggesting that leaving the map blank is preferable because someone might fill it in later, and that person might feel intimidated by the presence of existing data. I will gently submit that needing a blank slate is not even close to the most off-putting thing about OSM for new mappers. More to the point, even if you take an *extremely* rosy view of the extent to which the act of mapping enhances self-determination, the loss to the OSM community seems vastly less important than the losses to everyone who could be using the map to facilitate their businesses, recreation, or government. Every day that a part of the map remains unusably empty is a day that those people lose benefits they might have had -- or a day in which they become more reliant on closed data that has already gotten the job done. Tom ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Some thoughts against remote mapping
On Saturday 13 June 2015, Frederik Ramm wrote: [...] I don't agree with everything written in these postings but they certainly deserve some wider audience, and that's why I am writing this here - since neither author is on these lists and I haven't seen their messages mentioned or quoted anywhere. I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Thanks for pointing to these texts, very interesting reading. I fear though that critical discussion of the matter will most likely be difficult since the perceived need for humanitarian mapping in events of crisis and the perceived prominence of altruistic motives in those activities is so large making even the basic notion that something good does not justify something bad seems unimportant. Critical reflection on your activities in such a context is very difficult. One important point where i think Gwilym is wrong is the idea that proactive humanitarian mapping will lead to a true homogenization of the map. First of all none of the organized mapping activities focusses on those areas that are worst mapped in OSM so they increase differences rather than reducing them. Efforts in true homogenization would only have a chance on a much longer time horizon (i.e. decades) and none of the organizations involved in humanitarian mapping think on that time scale. But more importantly the colonalization, control and power over space is already there in the form of global coverage high resolution imagery. Remote mapping essentailly makes this information more accessible. If this is a good or a bad thing can of course be discussed but OSM is not really the best address to blame here in any case. This is not meant to say remote mapping in OSM is generally a good thing, many of the arguments against it have a lot of merit. But the main question should be if and how this hampers development of true grassroots mapping by locals when performed within OSM and thereby conteracts the primary purpose of the project and not if remote mapping itself, i.e. extracting semantic information from remotely sensed data that exists anyway is morally questionable in general (which is fairly frivolous IMO). And i think there are a lot of other areas in OSM that represent at least as efficient (and therefore damaging) means of cultural imperialism as remote mapping. My favorite example is always map rendering, there is a real lot of more or less subtle cultural bias in that. OSM does not only need more mappers with diverse cultural backgrounds, it also need more diverse input in development and design and the barriers for those are much higher than for mapping. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] São Carlos, SP
Aun Johnsen, perdoe, mas ontem fui obrigado a me ausentar e não pude lhe responder na lista. Conforme comentei anteriormente, os mapas do Brasil produzidos e fornecidos em http://garmin.openstreetmap.nl/ ou http://mapas.alternativaslibres.es/descargas.php não atendem as necessidades brasileiras porque eles empregam os styles default do Mkgmap, sem o devido tratamento para o Brasil. Testamos esses mapas exaustivamente e concluímos que quando empregados no Brasil geram inúmeros problemas aos utilizadores, em especial aos inexperientes. Visando melhor demonstrar os problemas desses mapas, decidi gravar um vídeo tutorial mostrando o que ocorre quando os styles do Mkgmap não são tratados pelo utilizador. Por gentileza veja o vídeo em https://www.youtube.com/watch?v=mwQNV0ndR44 onde nele aponto o problema empregando o mapa do Brasil renderizado no dia 10/06/2015 pelo http://garmin.openstreetmap.nl/ []s Marcio From: Lists Sent: Friday, June 12, 2015 8:32 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP Marcio Me notei nomes de algumas ruas no São Carlos e fiz busca por nome da rua, tudo deles achei sem problema. Se consigo busca pelo nome da rua significando que e indexado, ne? Isso e com mapas do garmin.openstreetmap.nl compilado 29-03-2015, reproducido no BaseCamp e no meu Garmin Nüvi 50 https://i.imgur.com/Xk4FdoK.png Aun Johnsen ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-it] Mappatura corretta pareti naturali/falesie per arrampicata
Mi sto trovando ultimamente a mappare le pareti naturali e le falesie attrezzate con chiodi, fittoni, spit ect... per l'arrampicata libera. Secondo me basterebbe come tag sport=climbing e il nome se lo ha ma vedo che qualcuno aggiunge anche leisure=pitch. Ma non c'è una struttura o un impianto... è corretta quindi l'aggiunta di quest'ultimo tag? Nel Wiki non è specificato nulla -- View this message in context: http://gis.19327.n5.nabble.com/Mappatura-corretta-pareti-naturali-falesie-per-arrampicata-tp5848054.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-br] São Carlos, SP
thundercel se possível verifique a mesma situação com os estados do Nordeste, menos a Bahia(não editei por lá), pois verifiquei que quase todo o estado de são paulo falta algumas tags nas relações o que deve estar gerando esses erros. Algumas cidades que podem estar corretas, Jundiaí, Itatiba, Itupeva e outras que podem estar errado Valinhos, Vinhedo e Louveira. Se for isso mesmo, pode consertar o Estado todo com essa consulta http://overpass-turbo.eu/s/4li até mesmo os outros Estados ou então pegar todas as relações que apontaram esse problema no osmose https://etherpad.mozilla.org/9s9Xov2u2R e mesmo se não for esse o problema, estão todos convidados a consertar essas relações, dividir para conquistar né? Tarcisio Oliveira smime.p7s Description: Assinatura criptográfica S/MIME ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] tunnel überlagert Buildings auf osm.org
sent from a phone Am 13.06.2015 um 06:49 schrieb Andreas Labres l...@lab.at: Naja, das ist ja genau, was ich schrieb: erst Flächen (Ozean, landuse, Häuser), dann Linien (Straßen, Wege, usw.) und Punkte. konkret ist es die Entscheidung, highway areas über die meisten Linien zu rendern, die das ganze oft komisch aussehen lässt. In kleinen zoomlevels wäre das vermutlich besser, aber weit reingezoomt sieht es sonderbar aus, vor allem, wenn die Straßenflächen groß sind Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] São Carlos, SP
Marcio Desculpa que nao pode ver o video voce me mando nem atualizar as mapas, to offshore Patagonia e meu conecao internet nao dar para ver youtube e nem baixar arquivos grandes. Bem, vejo algum de seus problemas sobre garmin.openstreetmap.nl http://garmin.openstreetmap.nl/, principalmente em calcular tempo nos roteamentos, como voce dis não uso regras especificas por brasil, que resultando velocidade padrão no autoestrada (highway=motorway) ser 250km/h, no trunk 130 e no primary 90km/h por exemplo. Mas seus problemas de indexacao não parecendo valido por esse mapa. Eu nao tem mapas do link ES que voce mandou e não pode relatar resultado ai. Como mapas do garmin.openstreetmap.nl http://garmin.openstreetmap.nl/ indexando as ruas e POI certas, o problema com indexacao nao e no banco dados OSM, mas provavelmente nos regras voce utilizando. Antes de começar mexer com o banco dados, verificar se ha problemas indicados nos ferramentas QA que tem monte, e também verificar se problema também existe no outro fontes do mapa Garmin. Proximo vez voce encontrando problemas assim, se e com indexo, roteamento, ou outros coisas, me manda informação sobre o problema, sobre como voce testando, o que testes não dar resultado que voce espero, e o resultado voce espero. Assim eu posso te ajudar reproduzir esses problemas para verificar que realmente e no banco dados ou se consigo identificar outro fonte de problema. Eu sei que tem monte erros no mapa, enquanto tava tentando entender seu problema encontrou ruas com nomes sigintes: “Rua !”, “Rua -1”, A, 1, (7), (Trevo), (Rua Do Estacionamento Do Atacadao E Dicico Usada Pela Comunidade Como Saida Do Transito Da Parada De Taipas)”, Avenida 1? de Maio Também parecendo que temos muitos ruas com erros tipo “Ria” em vez de “Rua”, em monte abreviações errados “R. A” e mais Antes que começando corregir no banco dados que não dar erro no outros fontes, temos um monte a concertar. Aun Johnsen On Jun 13, 2015, at 08:36, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Aun Johnsen, perdoe, mas ontem fui obrigado a me ausentar e não pude lhe responder na lista. Conforme comentei anteriormente, os mapas do Brasil produzidos e fornecidos em http://garmin.openstreetmap.nl/ http://garmin.openstreetmap.nl/ ou http://mapas.alternativaslibres.es/descargas.php http://mapas.alternativaslibres.es/descargas.php não atendem as necessidades brasileiras porque eles empregam os styles default do Mkgmap, sem o devido tratamento para o Brasil. Testamos esses mapas exaustivamente e concluímos que quando empregados no Brasil geram inúmeros problemas aos utilizadores, em especial aos inexperientes. Visando melhor demonstrar os problemas desses mapas, decidi gravar um vídeo tutorial mostrando o que ocorre quando os styles do Mkgmap não são tratados pelo utilizador. Por gentileza veja o vídeo em https://www.youtube.com/watch?v=mwQNV0ndR44 https://www.youtube.com/watch?v=mwQNV0ndR44 onde nele aponto o problema empregando o mapa do Brasil renderizado no dia 10/06/2015 pelo http://garmin.openstreetmap.nl/ http://garmin.openstreetmap.nl/ []s Marcio From: Lists mailto:li...@gimnechiske.org Sent: Friday, June 12, 2015 8:32 PM To: OpenStreetMap no Brasil mailto:talk-br@openstreetmap.org Subject: Re: [Talk-br] São Carlos, SP Marcio Me notei nomes de algumas ruas no São Carlos e fiz busca por nome da rua, tudo deles achei sem problema. Se consigo busca pelo nome da rua significando que e indexado, ne? Isso e com mapas do garmin.openstreetmap.nl http://garmin.openstreetmap.nl/ compilado 29-03-2015, reproducido no BaseCamp e no meu Garmin Nüvi 50 https://i.imgur.com/Xk4FdoK.png https://i.imgur.com/Xk4FdoK.png Aun Johnsen ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Eisenbahn-Relation (controlled_area) ohne Typ - Besten Dank
Hallo Michael, vielen Dank für die Hinweise. Mit den Railway-Tags habe ich mich bisher noch nicht intensiv auseinander gesetzt. Werde ich gleich mal nachholen. Außerdem ein Dankeschön für die abgenommene Arbeiten. Gruß, Nico Message: 9 Date: Sat, 13 Jun 2015 09:56:48 +0200 From: Michael Reichert naka...@gmx.net To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Eisenbahn-Relation (controlled_area) ohne Typ Message-ID: 557be240.6030...@gmx.net Content-Type: text/plain; charset=utf-8 Hallo, Am 2015-06-13 um 07:37 schrieb goegeo: ich hab bei der JOSM Fehlerprüfung in meiner Region eine Relation entdeckt, bei der kein Relationstyp angegeben ist. Von JOSM wird er als Fehler und nicht als Warnung klassifiziert. Als Tags der Relation sind zwei Felder angegeben. - name=Jübek Bf - railway=controlled_area Mag sich jemand das mal mit anschauen? Bin mit ungewöhnlichen Relationen nicht sehr vertraut. Wie sollte damit umgegangen werden? Erstmal die Tags im Wiki suchen und/oder die Mailinglisten und Foren nach diesen Tags durchsuchen (mit einer Suchmaschine deiner Wahl). Allein schon die Suche im Wiki hätte dich auf diese Seite geführt: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging Dort steht, dass es ein veraltetes Tag für eine Stellbereichsrelation ist. Als Stellbereich bezeichnet man den räumlichen Bereich (meist ein Polygon), der von einem Stellwerk aus gesteuert wird. Das kann (bei alten mechanischen Stellwerken) ein kleiner Teil eines Bahnhofs sein, bei elektronischen Stellwerken (im Eisenbahnjargon ESTW genannt) können das auch mehrere Bahnhöfe sein. Vor Ort kann man das durch genaues Anschauen der Signale erkennen, entweder welche Nummer das Signal hat oder – bei Signalen/Weichen, die über Drahtzüge vom Stellwerk aus gestellt werden – wohin der Drahtzug führt. Die von dir genannte Relation ist, bei genauerem Betrachten eh kaputt (nicht wegen dem fehlenden type=railway, das bis vor ein paar Minuten in der deutschen Übersetzung des Taggingschemas gefehlt hat), sondern weil der User entweder das Wiki nicht gelesen hat oder einiges nicht gescheit verstanden hat (er hat auch iD benutzt). Ich habe ihm eine ausführliche PN geschrieben, da er auch andernorts zwischen Neumünster und Flensburg falsch getaggt hat. Viele Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eisenbahn-Relation (controlled_area) ohne Typ
sent from a phone Am 13.06.2015 um 07:37 schrieb goegeo goe...@gmx.de: Als Tags der Relation sind zwei Felder angegeben. - name=Jübek Bf - railway=controlled_area Mag sich jemand das mal mit anschauen? Bin mit ungewöhnlichen Relationen nicht sehr vertraut. Wie sollte damit umgegangen werden? wenn es sich um eine area handelt ist der fehlende tag type=multipolygon Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Import dati da database Regione Lombardia
Ciao a tutti ... Tempo fa mi sono scaricato il dataset dei civici dal
GeoPortale Lombardia e l'ho fatto x provincia e quindi ho gli shapefile
cosi' suddivisi. È' questo che ti serve?
Il venerdì 12 giugno 2015, RColombo roberto.colo...@gruppocorvi.org ha
scritto:
Questo è lo stato attuale del DB. Link
http://www.cartografia.regione.lombardia.it/viewer25/index.jsp?config=config-dbtr.xmlparameters={%27wkid%27:32632,%27rlregis%27:{%27config%27:%27config-rlregis-dbtr.xml%27,%27ctrlTopo%27:{%27layerName%27:%27WIZ_U32WG.VS_CO_CTR_09%27,%27id%27:%2716001%27}}}
Un altro problema è che alcuni comuni si sono dimenticati di aggiungere il
nome della via al db dei numeri civici.
Ho creato una cartella condivisa su drive dove poter scaricare gli shape
file suddivisi per provincia
https://drive.google.com/folderview?id=0B3AkhTNEEd9FfmViRjRFdll0TEpDRWEydl9DOVFoV2pZTjZrSVFYWlpQejZmUnVYRFJsS2susp=sharing
--
View this message in context:
http://gis.19327.n5.nabble.com/Import-dati-da-database-Regione-Lombardia-tp5847787p5848026.html
Sent from the Italy General mailing list archive at Nabble.com.
___
Talk-it mailing list
Talk-it@openstreetmap.org javascript:;
https://lists.openstreetmap.org/listinfo/talk-it
--
Cesare Gerbino
http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b
Questo è un account di posta personale di Cesare Gerbino: tutte le opinioni
espresse sono personali e non riflettono necessariamente quelle del mio
datore di lavoro
This is Cesare Gerbino mail account. Text is written by Cesare Gerbino:
the views expressed are mine and not necessarily those of my employer.
.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
[Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER
Hi all, At State of the Map US last weekend I was really pleased to unveil bicycle routing for the US (and Canada) at my site, cycle.travel. The planner, at http://cycle.travel/map , will plan a bike route for you between any two points - whether in the same city or on opposite sides of the continent. It's all based on OSM data but also takes account of elevation and other factors. I dogfooded it with a three-day ride around New York state after SOTM-US, and it found me some lovely quiet roads in and around the Catskills. I hope it'll be equally useful for the other two-wheelers amongst us. There's still a lot I want to add (as detailed at http://cycle.travel/news/new_cycle_travel_directions_for_the_us_and_canada) but I hope you enjoy it. Plug aside, there's a couple of things might be relevant to US mappers. First of all, I'm aiming high with this - the aim isn't just to make the best OSM-powered bike router of the US, but the best bike router full stop for commuters, leisure cyclists and tourers. (I leave the athletes to Strava!) Here in Britain, experience over the years has been that good bike routing and good bike cartography - historically via CycleStreets and OpenCycleMap - are a really effective way of driving contributions to OSM. So if you know cyclists who aren't yet contributing to OSM, maybe throw this at them - and if it doesn't find the route they'd recommend, maybe there's some unmapped infrastructure they could be persuaded to add! Second, the routing and cartography both heavily distrust unreviewed TIGER. In other words, it won't route over a rural road tagged as highway=residential tiger:reviewed=no Any road with tiger:reviewed removed or altered, any road in urban areas, and any road with highway=unclassified or greater is assumed to be a usable paved road. (There are a few additional bits of logic but that's the general principle.) Unreviewed rural residentials are shown on the map (high zoom levels) as a faint grey dashed line, explained in the key as Unsurveyed road. I've been finding this a really useful way of locating unreviewed TIGER and fixing it... it's actually quite addictive. :) Looking for roads which cross rivers, or with long sweeping curves, is an easy way of identifying quick wins. My modus operandi is to retag 2+-lane roads with painted centrelines as tertiary, smaller paved roads as unclassified, and just to take the tiger:reviewed tag off paved residential roads. Anything unpaved gets a surface tag and/or highway=track. I can't promise minutely updates I'm afraid - the routing/map update process takes two full days to run so it'll be more monthly than minutely. But I hope you find it as useful as I do. You'll see there's a tiny little pen icon at the bottom right of http://cycle.travel/map which takes you to edit the current location in OSM. Finally, many thanks to everyone who's tested it so far, particularly Steve All - your feedback was and continues to be enormously useful. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Some thoughts against remote mapping
Frederik Ramm writes: I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Western aid has a bad history of mostly aiding westerners. The one simple trick for avoiding that is to ask the locals How can I help? And if the locals say We need a better map for where we live, then that addresses your concern. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] [Talk-ht] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Salut Fred, Merci pour l'info ! C'est 15-20 classes pour l'ensemble du monde, de milieu désertique à équatorial, anthropisé ou non ? Comment cela s'est passé jusqu'à présent les imports de données de télédétection dans OSM ? Batch ou par objet ? Quid du recoupement avec les éventuels zonages existants ? Il y a déjà une méthodologie ? 2015-06-13 17:20 GMT+00:00 Frederic Moine frmo...@gmail.com: Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en Fiche Projet ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-ht mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ht] [Hot-francophone] [OSM-talk-fr] Orfeo Tool box , Satellite Sentinelle
Salut Fred, Merci pour l'info ! C'est 15-20 classes pour l'ensemble du monde, de milieu désertique à équatorial, anthropisé ou non ? Comment cela s'est passé jusqu'à présent les imports de données de télédétection dans OSM ? Batch ou par objet ? Quid du recoupement avec les éventuels zonages existants ? Il y a déjà une méthodologie ? 2015-06-13 17:20 GMT+00:00 Frederic Moine frmo...@gmail.com: Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en Fiche Projet ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [OSM-talk] Some thoughts against remote mapping
Western aid has a bad history of mostly aiding westerners. The one simple trick for avoiding that is to ask the locals How can I help? And if the locals say We need a better map for where we live, then that addresses your concern. Unfortunately the world isn't quite so simple. If we look at the ongoing Ebola outbreak for example. Many health teams were met with rocks and a strong negative reaction. Should the west have done nothing and let Ebola spread? How do you know what the locals want? At the department of Indian and Northern Affairs Canada one of the problems is there is half a million status Indians which means roughly half a million different points of view. You don't mention the NGOs and others who consume our maps, are they not legitimate clients? Global Open Data for Agriculture and Nutrition (GODAN) works hard using Open Data to improve the quality of life for many. They make extensive use of OSM especially in the HOT areas. The locals may recognise GODAN's efforts and use their information without recognising the value of OSM underneath. They aren't the only ones using the data. Even quite small AID groups doing nothing more than providing access to clean water use OSM to work out where the wells should go. I think recently the World Bank noted that the cost of building a highway in an African country when they were involved is about twice as high as one where they aren't involved. They think that corruption plays a part in this. There are a number of issues involved in giving aid, for example some US food aid must be carried in US registered ships I believe but the HOT mapping delivers some value to the population often indirectly without some of the problems of other types of aid. Cheerio John On 13 June 2015 at 17:01, Russ Nelson nel...@crynwr.com wrote: Frederik Ramm writes: I think the tl;dr of both these postings could be: Whenever you give someone a map by remote mapping, you also take something away from them. Western aid has a bad history of mostly aiding westerners. The one simple trick for avoiding that is to ask the locals How can I help? And if the locals say We need a better map for where we live, then that addresses your concern. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ 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-at] Beschreibung von Changeset ändern
Norbert Wenzel wrote: Wenn du es nicht geschlossen hast dann schon, zumindest in JOSM. Wobei die Changesets allerdings nach einer Stunde automatisch geschlossen werden, und dann ist leider keine Korrektur mehr möglich. Das Problem der Fehler in den Commit-Messages gibt's auch in den meisten anderen Versionskontrollen. Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
