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: [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: [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-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
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: [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: [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
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-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
