Re: [Talk-br] Notícias » Internet Foursquare troca Google Maps por OpenStreetMaps
A propósito alguém sabe me responder qual a vantagem do Foursquare utilizar como tile agora o OSM e manter o core da geolocalização no Google Maps ? Não vi em nenhum lugar a explicação de que ponto da licença eles teriam vantagem, mandei pra lista internacional e ninguém respondeu. Custo. Os tiles que o Google oferece não pertencem ao Google. Pertencem, por exemplo, à TeleAtlas. Por causa disso, para usar os tiles do Google o Foursquare tem que licenciar o acesso à API do Google para mapas, e além disso licenciar o uso dos tiles com a TeleAtlas. Ao usar os dados do OSM, eles podem simplesmente fazer uma cópia dos dados e não pagar para ninguém. Mais importante do que isso, não há mais nenhuma dúvida sobre a licença de uso dos dados. O que confirma minha idéia de que essas licenças de mapas não tem utilidade nenhuma na web, até pq podem ter várias interpretações diferentes e ninguém cobra se alguém está utilizando seus dados, principalmente POIs. Recentemente houve uma discussão aqui e a conclusão foi que a Wikimapia não poderia utilizar os pontos geolocalizados por seus usuários pq utilizava o Google Maps como tile e para recuperar as coordenadas, agora a opinião é que o Foursquare pode, sendo que a utilização é a mesma... Existe uma diferente bastante importante entre estar cobrando e poder cobrar. O caso do Wikimapia é bastante claro: os usuários usam os tiles do Google para desenhar os metadados. Ou seja, é claramente um trabalho derivativo. No caso do Foursquare, até onde eu sei as coordenadas dos POI são obtidas a partir das coordenadas GPS dos aparelhos dos usuários. Essa parte é limpa, pois funciona exatamente como o OSM. O que resta a saber é como que o Foursquare obtém as informações do POI (nome, tipo, etc). Se eles consultam dados do Google, então a coisa fica complicada de novo... R. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mudança de Licença do OpenStreetMap - IMPORTANTE
2012/2/10 Cleber Gouvêa cleb...@gmail.com Bom, por essa lógica grande parte dos mashups na Internet estão ilegais pq de uma forma ou de outra eles recuperam as informações da api do Google e armazenam elas. A página com os termos de uso da API para mapas do Google [1] explicitamente indica os limites de uso (ênfase minha): * 4.2 Limits on Your Use of the Service. You acknowledge and agree that Google may impose or adjust the limit on the number of transactions you may send or receive through the Service; such fixed upper limits may be set by Google at any time, at Google's discretion. For further information, see Section 10.1.1(i) below. (...) * *8.3 Content License. Subject to these Terms (including but not limited to Section 9 (License Requirements) and Section 10 (License Restrictions)), Google gives you a personal, worldwide, royalty-free, non-transferable, non-assignable, and non-exclusive license to access, use, publicly perform and publicly display the Content in your Maps API Implementation, as the Content is provided in the Service, and in the manner permitted by the Terms. Specifically, you understand the following:* * * *(a) Content (including but not limited to map data, traffic, directions, and places) is provided for planning purposes only. You may find that weather conditions, construction projects, closures, or other events may cause road conditions or directions to differ from the results depicted in the Content. You should exercise judgment in your use of the Content.* *(b) Certain Content is provided under license from third parties, including Tele Atlas B.V. (Tele Atlas), and is subject to copyright and other intellectual property rights owned by or licensed to Tele Atlas and/or such third parties. You may be held liable for any unauthorized copying or disclosure of this content. Your use of Tele Atlas map data and certain other Content (including certain business listings Content) is subject to additional restrictions located in the Legal Notices page.* Tem que ler toda a seção 10.1 para ver os detalhes das limitações, é muito texto para copiar aqui. A licença da TeleAtlas está em outra página [2], e diz isso aqui: *3 Tele Atlas Licensed Content.* * * *3.1 Restrictions on Commercial Use of Tele Atlas Licensed Content.* * * *(a) You are not permitted to print more than 5,000 copies of sales collateral materials containing a screenshot of Tele Atlas Licensed Content for commercial sales lead generation (Direct Marketing). If you desire to do so, you must (i) enter into a Google Enterprise license agreement or (ii) contact Tele Atlas to obtain a direct license to do so.* * * *(b) You are not permitted to incorporate Tele Atlas Licensed Content as a core part of printed matter (such as printed maps or guide books) that you redistribute for a fee. If you desire to do so, you must contact Tele Atlas to obtain a license.* * * *(c) You are not permitted to offer a batch geocoding service that uses the Tele Atlas Licensed Content contained in any Google products or services.* E depois disso tem uma longa lista de parágrafos adicionais para diversos países. Para uso online, as restrições estão em outra página [3], e a parte importante é essa aqui: *Use of the Google Geocoding API is subject to a query limit of 2,500 geolocation requests per day. (User of Google Maps API for Business may perform up to 100,000 requests per day.)* Resumindo: Pelo que eu entendi, tanto o Google como a TeleAtlas permitem um uso comercial limitado, mas a partir de um certo volume tem que licenciar o conteúdo. E se esses serviços realmente estão armazenando informações do Google (ao invés de requisitar on-the-fly), então eles estão violando as licenças do Google e da TeleAtlas. R. [1]: http://code.google.com/apis/maps/terms.html [2]: http://www.google.com/intl/en-us/help/legalnotices_maps.html [3]: http://code.google.com/apis/maps/documentation/geocoding/#Limits ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mudança de Licença do OpenStreetMap - IMPORTANTE
A pior parte é que a única maneira de se livrar do problema é recriar do zero. Que lamentável desperdício de trabalho. Pelo que eu vi, tem algumas cidades no RS que vão simplesmente desaparecer [1]. Eu duvido que conseguiremos contatar as pessoas responsáveis antes da data final. [1]: http://cleanmap.poole.ch/?zoom=12lat=-28.30894lon=-53.51408layers=00B R. 2012/2/9 Rodrigo Avila rodr...@avila.net.br Em 7 de fevereiro de 2012 22:00, vitor vitor.geo...@gmail.com escreveu: Pode ser que o usuário [...] simplesmente não concorda com os novos termos. [...] Por falar nisso, tem uma área bem grande na Europa que foi mapeada (ou importada) por um usuário que, de acordo com o site, não concordou com os termos... [1] pensa no rombo que isso vai deixar no mapa... [2] [1] http://hdyc.neis-one.org/?balrog-kun [2] http://cleanmap.poole.ch/?zoom=8lat=52.14464lon=20.78955layers=00B ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mudança de Licença do OpenStreetMap - IMPORTANTE
Desculpem a minha ignorância, mas digamos que eu identifiquei um usuário que precisa ser notificado. O que devo fazer? Ricardo P.S.: Como ficam os casos de contas abandonadas? 2012/2/7 vitor vitor.geo...@gmail.com Pessoal, Em breve será aplicada a etapa final da licença do OpenStreetMap para a Open Database License (ODbL). A partir desta data, que deve ser em abril, não estarão mais disponíveis dados mapeados por usuários que não aceitaram a mudança. Neste link é possível ver as partes do mapa que estão em risco. http://tools.geofabrik.de/osmi/?view=wtfe Existe uma página no wiki que centraliza as atividades de contato com os usuários indecisos: http://wiki.openstreetmap.org/wiki/Asking_users_to_accept_the_ODbL A página está em inglês, mas recomendo que todos a utilizem para evitar duplicação dos esforços. Obrigado, Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dados dos Correios são públicos?
2012/1/13 Wille wi...@wille.blog.br Creio que isso seria uma boa solução para termos uma base de dados dos municípios que possuem um único CEP. E acho que isso não infringe direitos autorais... o que acham? Posso estar muito enganado, mas me parece que essa solução está infringindo copyright de todas as páginas que foram usadas na pesquisa... para ter certeza teria que ler os termos de uso de cada um desses websites que estão sendo usados na pesquisa. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imagens Aéreas do Estado de Minas Gerais
Oi pessoal, O problema maior não é tanto o espaço (um disco de 2 TB está até relativamente barato hoje em dia). O problema maior é um servidor com largura de banda suficiente para fazer upload de 1 TB antes do final da década. E depois disso, tem que ter largura de banda suficiente para servir o conteúdo. Eu poderia até tentar negociar um espaço no rack da universidade onde estou para colocar um servidor(zinho) FTP, mas não garanto nada. Alguém tem contato com o pessoal da UFMG para perguntar se eles não hospedariam isso? Att, Ricardo 2011/6/21 enqd e...@ymail.com Olá Samuel, Fico feliz em ter feito contato. 1TB realmente é espaço adoidado, é muita mídia. Fui no irc do osm e fiz uma pergunta se alguem tem espaço em servidores para colocar as imagens, mas ninguém respondeu. Mas acho que vale uma mensagem na lista perguntando novamente. Essa questão do termo, fiquei curioso, será que tem alguma restrição? Se as imagens foram compradas com dinheiro público, deveriam ser de domínio público. Deixa o pessoal usar as imagens do jeito que quiserem, rsrsrs. Já que não existe espaço suficiente em HD/midias para copiar as imagens de todo estado, concordo em requisitar as imagens dos municípios que o pessoal aqui tiver interesse. Quando acharmos uma solução para armazenar todas as imagens, agente (samuel) vai requisitando mais imagens junto ao IEF.. Lembrando que talvez o próprio IEF armazene essas imagens no servidor deles em breve (esse breve geralmente demora viu). Samuel: Vc questionou isso? Enfim, já que temos poucas cidades (4 até agora) seria interessante requisitar as 3 coberturas. Outra pergunta: No seu servidor, tem espaço para armazenar quanto? Vc saberia montar um servidor wms para que as imagens possam por exemplo serem usadas no OSM? Eu espero que o serviço OpenaerialMap comece a funcionar novamente em breve para que possamos armazenar essas imagens lá. Muito Obrigado Samuel. Ficamos no aguardo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Cafofo do OSAMA
Aqui: http://goo.gl/PARxR :) 2011/5/9 Guilherme Dagostin Donadel gdona...@gmail.com Alguem já encontrou a casa onde o Osama foi morto? Guilherme D'Agostin Donadel ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Membro novo dando oi e fazendo perguntas
Oi Leandro, 2010/12/8 Leandro Motta Barros lmbar...@gmail.com 1. Notei que em algumas rotas já anteriormente mapeadas usavam Rua e Avenida por extenso, enquanto em outroas abreviavam para R. e Av. Existe alguma orientação quanto a qual forma é preferível? Eu sou da opinião que não se deve abreviar nada. Abreviação, se necessário, pode ser feita na renderização. Me pergunto também se existe alguma regra sobre isso... Ricardo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Diferença entre GPX/Imagens de Satél ite
Na minha opinião, o maior problema não são imagens deslocadas. Como o Claudomiro disse basta um script para pegar a área e aplicar um delta nas coordenadas. O problema maior de se basear em imagens é se elas não são corretamente achatadas (ortoretificadas). Nesse caso, podem haver distorções muito difíceis de corrigir com um simples script. Alguém sabe se o problema é apenas deslocamento ou se temos problemas de rotação e/ou distorção tridimensional? Além disso, eu não confiaria muito nos dados do GPS... não antes de dar uma boa olhada no HDOP (Horizontal Dilution Of Precision [1]), que indica a precisão dos dados. Já me aconteceu várias vezes de ter um error de vários metros entre a posição real e a posição indicada no GPS, principalmente logo depois de ligar o aparelho ou quando estou em áreas com muita interferência. Alguém sabe se algum dos softwares leva em conta o HDOP? Seria legal que mostrassem a trilha com uma espessura de linha proporcional ao erro. Att, Ricardo [1]: http://en.wikipedia.org/wiki/Dilution_of_precision_(GPS) 2010/11/29 Claudomiro Nascimento Junior claudom...@claudomiro.com Eu também acho que se já houver uma boa base de dados coletada com GPS, não se deve mover tudo para bater com as fotos de satélite. Tanto no Potlatch como no JOSM é possível deslocar as imagens pra bater com os dados existentes. Agora, nas cidades onde não há quase nenhum dados antes da disponibilidade das fotos, acho que é mellhor usar as fotos como referência e em algum ponto no futuro fazer um trabalho de ajuste fino para seguir uma referência mais exata. 2010/11/29 Flavio Bello Fialho be...@cnpuv.embrapa.br Em 26-11-2010 17:34, Johan Dahlin escreveu: São Carlos tem mesmo problema, veja aqui: http://yfrog.com/5j979kp Mas o error é bem minor. Acho em caso vale pena mudar todos os pontos para ser alinhadas com os dados do Bing. NÃO FAÇA ISSO! As imagens de satélite têm erro. O GPS está correto, pelo menos na média. Pode acontecer de uma trilha estar deslocada por erro de leitura do GPS, mas o mapa deve corresponder à realidade, e não à imagem de satélite. Se o GPS for passado várias vezes em dias diferentes no mesmo local, o traço médio estará correto. É comum ver a mesma estrada em dois lugares diferentes no limite entre imagens no Google. Isso acontece por erro na ortorretificação ou na amarração da imagem de satélite ao campo (que deve ser feito com GPS). O melhor é tentar deslocar a imagem de forma que traços conhecidos coincidam com o GPS e depois traçar o que falta com a imagem. -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação dos dados da prefeitura d e Goiânia
Na minha opinião, se os dados da prefeitura são mais corretos*, não tem porque guardar informação antiga, errada ou incompleta. Por outro lado, algo me diz que seria bom guardar esses dados de alguma maneira, caso precisemos consultá-los mais tarde. Eu vejo três possibilidades: 1) Remarcar toda a informação que está agora lá como deprecated (ou algo assim), de maneira que fique invisível no renderer, mas que se alguém tiver interesse ainda pode ser acessada pelo editor. Se ninguém reclamar, depois de um tempo apaga a informação velha. Contra: Vai ficar uma bagunça no editor. 2) Cria um changeset gigante e coloca todos os dados removidos em uma mudança só. Assim fica fácil reverter se houver necessidade. Contra: se houver algum dado que não estiver no que vier da prefeitura, a gente perde. 3) Tentar fazer um merge dos dados... isso requer identificação de quais pontos presentes atualmente coincidem com os pontos do novo dataset. E depois tem que ver o que fazer com os tags... Contra: a menos que alguém tenha um método automágico, fazer um merge vai ser uma quantidade de trabalho incrível. *) Nota: eu me pergunto qual dos datasets é realmente mais correto. Eu já vi diferenças bem feias entre as imagens de satélite e a realidade (baseado em deixar o gps no mesmo lugar um tempão para que a posição estabilizasse, ou seja, ter baixo DOPhttp://en.wikipedia.org/wiki/Dilution_of_precision_(GPS)). Pode ser que os dados da prefeitura sejam os corretos... Att, Ricardo 2010/6/20 Flávio Henrique yoshi...@gmail.com Offset... vou procurar... O Claudomiro tá ocupado nestes dias, então vou tentar me virar por enquanto. Eu iria perguntar sobre os dados já existentes depois, mas já que o assunto foi mencionado agora: realmente os dados a serem importados são completíssimos (tem até os postes da rede elétrica da cidade), então por que não podemos apagar o que existe lá e importar a cidade inteira (não de uma vez, claro)? Grande parte do que está lá fui eu quem inseri e o que existia nem havia ligação com rodovias ou outras vias. Não sei se alguém sabe, mas se eu, utilizando o JOSM, reposicionar a imagem de satélite para que as vias fiquem ok, o JOSM vai adequar as coordenadas das vias ou da imagem? Digo, é uma forma de corrigir? Abraços! Flávio Henrique 2010/6/20 Vitor George vitor.geo...@gmail.com Com certeza deve existir uma opção de offset, talvez o Claudomiro conheça. Outra coisa, no IBGE o Claudomiro importou só em lugar onde não tinha nada mapeado. No caso de Goiânia, eu acho que não dá para fazer assim, porque na imagem que você mandou dá pra ver que os dados a serem importados tem uma qualidade muito melhor. Também não dá pra apagar tudo que tá no osm, então eu acho que vai ter que existe uma parte manual, não sei como, de substituição do que tá no OSM pelo que está nos dados da prefeitura. Ou talvez jogar tudo e aí corrigir de acordo com as imagens de satélite. Vitor 2010/6/19 Flávio Henrique yoshi...@gmail.com Olá pessoal! Depois de várias tentativas e algumas quase-desistências, consegui descobrir o caminho das pedras para começar a importar os dados da Prefeitura de Goiânia para o projeto. Entretanto... (claro, pois sempre há um problema) os dados importados estão deslocados em relação a algumas vias já desenhadas no projeto, bem como ao background do Yahoo Imagery. Vejam no link abaixo um exemplo do que estou falando. O que está em cinza (desabilitado) são os dados importados e os coloridos são dados baixados pelo JOSM do projeto. Preciso resolver isso antes de começar a analisar outros fatores da importação que, com certeza, ainda vai demorar. Link: http://i45.tinypic.com/27xqbf5.png Fazem ideia de como tratar isso? Desde já agradeço ao Claudomiro e ao Vitor George pelos primeiros 'empurrões' sobre o assunto. Grato! Flávio Henrique There are only 10 types of people in the world: Those who understand binary, and those who don't 2010/5/13 Flavio Bello Fialho be...@cnpuv.embrapa.br Provavelmente SAD-69. Manda converter para WGS-84. Flávio Henrique escreveu: Ok. Consegui abrir os arquivos pelo uDig e estão ótimos. Há coisas interessantes que posso trabalhar... Porém, preciso indicar ao uDig qual é o Sistema de Coordenadas que os arquivos utilizam. Como descobrir? Desculpem-me se é uma questão básica, mas estou iniciando... Grato! Flávio Henrique 2010/5/12 Flávio Henrique yoshi...@gmail.com mailto: yoshi...@gmail.com Olá Arlindo! Sim, os arquivos .shp são acompanhados por outros 5 ou 6 extensões (dbf, shx, dbx, etc)... Tentei abrir os .shp pelo Merkaator, mas nada aparece. O ogr2ogr também não gera um .osm que o JOSM consiga abrir... estou meio sem opções. :( Vou tentar a sugestão do Vitor... tentar abri-los em um GIS. Vamos ver no que
Re: [Talk-br] Aspectos a serem mapeados numa rodovia
Eu acho que o mais fácil é simplesmente usar uma câmera digital e combinar o timestamp das fotos com os dados GPS. Em outras palavras, bate foto de todas as placas no caminho. :-) Ricardo 2010/5/22 Bráulio Bezerra da Silva brauliobeze...@gmail.com k, realmente é coisa demais. E como vou de carona, não vou poder ficar parando. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] OSM no TED
Olá pessoal, Talvez seja notícia antiga para alguns, mas o Tim Berners-Leehttp://pt.wikipedia.org/wiki/Tim_Berners-Lee(inventor da WWW) fez uma apresentação em Fevereiro sobre *open data* na internet. A parte que nos interessa começa em 3min:33seg, onde ele começa a falar sobre o OSM, apresentando uma animação muito bacana mostrando as edições a nível mundial. Vale a pena assistir (em inglês): http://www.ted.com/talks/tim_berners_lee_the_year_open_data_went_worldwide.html Att, Ricardo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Digest Talk-br, volume 19, assunto 13
Olha, até posso estar enganado, mas se o aparelho usa apenas um canal por satélite, não tem porque ter mais do que 12 canais. Hoje existem apenas 31 satélites GPS em órbita. Da wikipedia[1]: ***As of March 2008, there are **31 actively broadcasting satellites** in the GPS constellation, (...) About **eight satellites** are visible from any point on the ground at any one time* [2] Ou seja, se apenas um canal é usado por satélite, o de 32 canais já seria demais, pois é impossível ver todos os satélites ao mesmo tempo. Segundo a wikipedia, apenas um canal é usado por satélite[3]: *A receiver is often described by its number of channels: this signifies how many satellites it can monitor simultaneously.* Ou seja, a menos que alguém descubra que esses aparelhos usam mais de um canal por satélite, não vale a pena comprar o de 66 canais. Att, Ricardo [1]: http://en.wikipedia.org/wiki/Global_Positioning_System#System_segmentation [2]: http://en.wikipedia.org/wiki/File:ConstellationGPS.gif [3]: http://en.wikipedia.org/wiki/Global_Positioning_System#User_segment 2010/4/15 Fernando Caldas fernandoccal...@gmail.com Olá pessoal. Encontrei no mercado livre este aparelho a 159,00 com 32 canais, e tem com 66 canais a 199,00. A diferença de canais é considerável? abç. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Esforço de mapeamento da crise humanit ária do Haiti
Heh, acabou de passar uma reportagem na CNN International sobre o Haiti onde mostraram o OSM como parte dos esforços de crowd-sourcing. Parabéns a todos que estão ajudando no esforço. Ricardo 2010/1/14 Vitor George vitor.geo...@gmail.com http://is.gd/6gpHuEsforço de mapeamento da crise humanitária do Haiti. Arquivos digitais atualizados a cada 5 minutos de vias trafegáveis, hospitais, edifícios públicos em funcionamento e escombros com possíveis feridos, além de outras informações. Qualquer um pode ajudar. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida sobre rótula
Oi, Você fez de maneira correta. O problema é que a restrição de conversão é bastante complicada de fazer corretamente e eu não tenho certeza que os softwares de cálculo de rota atuais utilizam as restrições corretamente. Se não me engano o novo mapzen deveria facilitar a criação de restrições. Alguém já testou? Att, Ricardo 2009/12/1 Rodrigo Avila rodr...@avila.net.br Oi pessoal, bom dia. Estou com uma dúvida sobre como criar rótulas, e já faz um tempo. Dêem uma olhada, por favor, no link em [1]. Uma foto desta junção vocês podem ver em [2]. Até aí nada de mais. Mas na página do wiki em [3] não tem nenhum exemplo de como criar uma rótula cortada; apenas rótulas com ilha no centro. E eu estou tendo problemas com rótulas deste tipo na hora de fazer o roteamento. Vejam, em [4] como deveria ser a rota em uma via deste tipo. Mas tanto no Cloudmade Maps quanto no Garmin Mobile XT a rota fica desenhada como na figura [5]. Já pensei em retirar os nós que ligam a RS-287 e o círculo do roundabout, mas o KeepRight [6] reclama que ali tem uma via sobre a outra sem um nó de ligação. Também já tentei colocar naquele nó uma restrição de conversão, mas sem sucesso. E agora? Qual é a maneira correta de mapear este tipo de junção, preservando o roteamento? Grato pela atenção. [1] http://osm.org/go/M5t4FIy73-- [2] https://dl.dropbox.com/u/114881/screenshots/round-1.png [3] http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout [4] https://dl.dropbox.com/u/114881/screenshots/round-2.png [5] https://dl.dropbox.com/u/114881/screenshots/round-3.png [6] http://keepright.ipax.at/ -- Rodrigo de Avila ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mais uma apresentação
2009/10/29 Flavio Bello Fialho be...@cnpuv.embrapa.br Eu penso em quem vai usar o mapa. O usuário espera que as primary sejam mais ou menos semelhantes em termos de trafegabilidade (existe essa palavra?). Mesmo que seja a única via de acesso a um lugar, se a estrada é ruim ela deve ter uma classificação compatível. Claro que temos que usar o bom senso. Existem estradas de terra que são ótimas de dirigir, lisas e bem conservadas, enquanto que para algumas pavimentadas o tertiary chega a ser bom demais. Só não acho indicado classificar como primary uma estrada onde um motorista pode quebrar um eixo do caminhão nos buracos (como, infelizmente, existem). O faro dela ser BR, estadual ou municipal não faz diferença para quem dirige. O importante é a estrada em si. Até onde eu entendo, a qualidade da manutenção da estrada não deveria influenciar a classificação da mesma. Tomando um exemplo extremo: se houvesse uma rodovia duplicada, de vias de sentido oposto separadas e com rampas de acesso, mas cheia de buracos ou cuja superfície é de barro, eu ainda marcaria como motorway. Mas complementaria com a maior quantidade possível de tags adicionais para explicar que se trata de uma rodovia muito mal conservada. Em um sistema ideal, essas tags adicionais seriam usadas para renderizar a rodovia de maneira diferente no bitmap final. Concordo que a distinção entre o que seria primary, secondary e tertiary é bem mais sutil, mas ainda assim acho que o estado de manutenção não deveria ser um critério para classificação. Até porque, dado o esforço que os governos federal e estaduais colocam na manutenção das rodovias, a gente teria que fazer um downgrade da maior parte das rodovias todos os anos... 2009/10/29 Arlindo Pereira nig...@nighto.net: Talvez então a gente devesse ter uma tag para especificar se a rodovia é federal, estadual ou municipal? Porque tag por tag, a qualidade da pista pode ser definida com tags específicas pra isso, como track-type. Quanto ao tag para indicar se é federal, estadual ou municipal: não é para isso que servem as relations? Att, Ricardo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mais uma apresentação
Alguns comentários: 2009/10/28 Ulf Mehlig ulf.meh...@gmx.net: Por que evitar unclassified?! É simplesmente um tag para ruas/estradas que não tem denominação oficial (em contraste a primary, secondary e tertiary), e que não são residenciais ... Deve ser a maioria das ruas em muitos lugares! Eu gosto de usar a cidade de Kalrsruhe como exemplo, dado que eles praticamente definiram muitos dos padrões usados (isso e o fato de que morei lá alguns anos, e portanto conheço as ruas pessoalmente). Se você olhar no centro de Karlsruhe, praticamente não existem ruas unclassified. Ou é tertiary ou é residential. Me parece que o fator para decidir se uma rua é residencial ou não é o tráfico. E a decisão sobre se é secondary ou tertiary é baseada na capacidade da rua acomodar tráfego ou não. Ou seja, uma rua estreita, apesar de ter muito tráfego na vida real, ainda é tertiary. As ruas primary (exemplo: Kriegstraße [1]) são ruas que tem duas vias para cada lado, separadas por canteiro central ou guard-rail. Em respeito à área rural: aqui no norte, pelo menos, a gente tem estradas que tem significância (e denominação, ex BR-xx) de uma secondary ou até primary, mas estão sem asfalto (ou com tão pouco de asfalto entre os buracos, que uma pista de chão seria melhor de qualquer jeito). A qualidade da superfície da estrada não deveria ter a ver com sua classificação. Se eu me lembro bem, é para isso que servem os tags surface[2] e tracktype[3]. (Me corrijam se eu estiver errado) Acho também (ainda) que não deve-se exagerar o uso de primary, secondary e tertiary dentro de cidades. Se são ruas arteriais que conectam bairros importantes, tudo bem; mas praticamente qualquer pista dupla asfaltada? Eu acredito que sim, se faz sentido do ponto de vista de tráfego. Porém, tenho as vezes a impressão que estas discussões estão mais determinadas pelo rendering atual do OSM, e então pela cor das ruas no mapa do site principal (quero as ruas no meu bairro todas amarelas ;-) Este tagging for the renderers não é visto positivo por uma parte significante dos integrantes do OSM ... Se todas as ruas do seu bairro oferecem a mesma capacidade de comportar tráfego, e essa capacidade é superior que a das ruas vizinhas, então deveriam ser mapeadas em um nível que indica essa diferença, independente de estarem no seu bairro ou não. Pessoalmente, eu tageio no OSM sempre pensando em um navegador GPS. Ou seja, se a gente considera que cada nível teria prioridade de rota sobre o inferior, então eu tento classificar as ruas conforme o meu conhecimento sobre elas, e como eu gostaria que uma determinada rua fosse utilizada pelo sistema de navegação. Em outras palavras, se eu sei que uma determinada rua é estreita e não foi preparada para receber grande volume de tráfego, eu coloco como residential. Se for uma grande avenida, com quatro vias separadas por canteiro central e interrompidas apenas por semáforos em crusamentos, eu coloco primary, dado que estas deveriam (em teoria) suportar o maior fluxo de tráfego. Se for uma rua, que apesar de não ser duplicada, tem faixas largas e/ou tem os semáforos ajustados para maximizar o fluxo de tráfego, então é secondary. Se for uma rua de tráfego pesado, mas do mesmo porte que uma residential, eu coloco tertiary. Ou seja, tertiary é um compromisso entre menor prioridade possível mas sem incomodar os bairros residenciais com tráfego desnecessário. ;-) Att, Ricardo [1]: http://www.openstreetmap.org/?lat=49.008lon=8.39389zoom=16layers=B000FTF [2]: http://wiki.openstreetmap.org/wiki/Key:surface [3]: http://wiki.openstreetmap.org/wiki/Key:tracktype ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapeando número de endereços e CEP e m São Paulo
Esclarece uma coisa que eu não entendi: a informação dos números seria colocada na própria linha da rua? Porque se esse for o caso, eu consigo imaginar uma série de problemas que inviabilizariam essa idéia (por exemplo quando os números não estão corretamente alinhados em ambos os lados da rua, etc). Eu acho o esquema de Karlsruhe bastante consistente e coerente: http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Para a numeração de blocos eles colocam os números em uma linha paralela à rua (http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_interpolation_to_mark_many_houses_along_a_way). Usar uma linha separada tem várias vantagens, como por exemplo separar os 'layers' de ruas e números, sendo que ambos podem ser processados separadamente, e portanto pode ser iterativamente melhorados. O único inconveniente é que tem que criar linhas extras. Fora isso, as linhas paralelas à rua preenchem todos os requisitos que enumerastes. De qualquer maneira, não devemos mexer no sentido das ruas. Essa informação é crítica para vias marcadas com 'oneway=yes', e portanto seu comportamento e semântica já estão definidos. Tentar mudar o significado do sentido de rodovias seria uma mudança que é completamente incompatível com aplicativos que já existem e fazem uso dos mapas. 2009/7/15 Julison juliso...@gmail.com: Pessoal, de repente o que vou escrever aqui já foi discutido antes ou não tem nada a ver. Fiquem à vontade para comentar. A questão da numeração sempre foi algo que mais senti falta no OSM. Eu li a solução ideal do wiki e apesar de concordar com ela eu acho que isso é uma solução de longo prazo. Pensei em algo mais imediato que pudéssemos fazer, para que a questão da numeração pudesse ser resolvida, mesmo que de modo paliativo. Ainda acredito que a numeração por blocos (ou quadras) é a melhor por ser mais exata. Mas pensei no seguinte: - Alterar o sentido de todas as ruas para que o sentido siga a numeração das ruas. Isso vale para os dois sentidos (quando aplicável). No caso de dois sentidos, um dos lados teria o sentido invertido em relação às direção, para poder dar o sentido correto da via. - Com isso, poderia ser desenvolvido um algoritmo para encontrar um número na via a com base na distância em relação ao início da mesma, como é o caso, por aproximação, das ruas aqui no Brasil (pelo menos a maioria) O que vocês acham disso? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
