Re: [Talk-br] Limites administrativos
Descobrimos a causa de não indexação dos estados do Acre. O problema ocorreu quando foram alteradas as relações do Parque Nacional da Serra do Divisor que pega o Brasil e a Bolívia. Nas alterações das relações desse Parque o limite administrativo do Brasil naquela região foi alterado (cresceu). No pré processamento da compilação dos dados com o MKGMAP existe a figura da poly que é um arquivo chave para cortar os dados baixados para serem processados só os de interesse. Esse arquivo foi por nós trabalhado logo quando iniciamos o processo de compilação do mapa para o Brasil, em maio deste ano. Na alteração nas relações do Parque, crescendo o limite do Brasil, com ele cresceu o limite do Acre - AC. Com isso esse estado ficou sem indexar porque seu polígono, sua relação boundary=administrative do Brasil e Acre foi cortada pela poly que estava adequada para os limites do Brasil naquela região. Para contornar o problema, alteramos o poly e as cidades do Acre passaram a indexar normalmente, entretanto vamos trabalhar nos styles porque com a poly aumentada muitos dados da Bolívia que não nos interessam começaram a aparecer no mapa do Brasil. []s Marcio From: Gerald Weber Sent: Tuesday, September 2, 2014 10:42 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites administrativos Marcio, sua preocupação é bem justificada. Estas tags poderiam não ser estritamente necessárias na way, se já existissem na relation, mas também não estavam fazendo mal a ninguem. Vou repetir o que disse no outro post: Não mexa no que está feito, procure fazer o que falta. abraço Gerald___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites administrativos
Eu realmente não pesquisei na época, segue um pedido de desculpa à comunidade pela negligencia, mas segue uma explanação do fato abaixo de como eu pensei sobre aquela alteração e porque deve ficar como está. O parque é brasileiro, ele deve estar contido em território totalmente brasileiro, juntamente com isso, um divisor de territórios são as divisas naturais, os rios, o que segundo a wikipedia https://pt.wikipedia.org/wiki/Fronteira_Brasil%E2%80%93Peru, trecho referenciada a SOARES, Clemente B. *Faixa de fronteira* https://sistema.planalto.gov.br/siseventos/faixafront/exec/arquivos/Painel3-Clemente_Baena_Soares.pdf. Ministério das Relações Exteriores, Subsecretaria-Geral da América do Sul, Departamento da América do Sul-II. Brasília, DF. a divisa entre Brasil e Peru é quase 70% água e o trecho em questão é, e parte do texto de criação do Parque http://presrepublica.jusbrasil.com.br/legislacao/110437/decreto-97839-89 diz: Oeste: do ponto 15 segue-se acompanhando a divisa internacional Brasil/Peru, no sentido norte até atingir o ponto 1, inicial da presente descrição. . Portanto o que eu fiz de forma empírica não estava errado e deve ser preservado(no me entendimento), no máximo ajustar as coordenadas do rio em questão para assim ajustar simultaneamente as Fronteiras Brasil/Peru e do Parque em questão. Tarcisio Oliveira On 04-09-2014 09:46, Augusto Stoffel wrote: Thundercel, A história deste problema é a seguinte. O limite Brasil--Bolívia era o que costumava ser, talvez importado do IGBE. Um dia eu importei o Parna da Serra do Divisor do ICMBio e notei que o seu susposto contorno acompanhava perfeitamente a divisa com a Bolívia, exceto por um trecho em que havia um discrepância bem grande (o parque “invadia” um pedaço da Bolívia). Como eu não tinha certeza se o erro é do ICMBio ou do OSM, eu não mexi em nada e deixei uma nota: https://www.openstreetmap.org/note/118278 Aparentemente o que aconteceu uns meses atrás é que o Tarcisio mudou os limites do Brasil, aumentando-os para acomodar o parque nacional. Se ele fez isso com a devida diligência eu não sei dizer (isto é, não sei dizer se ele pesquisou em uma terceira fonte que o limite Brasil--Bolívia correto é aquele que consta no OSM atualmente). On Thu, 2014-09-04 at 09:12 -0300, thunder...@gpsinfo.com.br wrote: Descobrimos a causa de não indexação dos estados do Acre. O problema ocorreu quando foram alteradas as relações do Parque Nacional da Serra do Divisor que pega o Brasil e a Bolívia. Nas alterações das relações desse Parque o limite administrativo do Brasil naquela região foi alterado (cresceu). No pré processamento da compilação dos dados com o MKGMAP existe a figura da poly que é um arquivo chave para cortar os dados baixados para serem processados só os de interesse. Esse arquivo foi por nós trabalhado logo quando iniciamos o processo de compilação do mapa para o Brasil, em maio deste ano. Na alteração nas relações do Parque, crescendo o limite do Brasil, com ele cresceu o limite do Acre - AC. Com isso esse estado ficou sem indexar porque seu polígono, sua relação boundary=administrative do Brasil e Acre foi cortada pela poly que estava adequada para os limites do Brasil naquela região. Para contornar o problema, alteramos o poly e as cidades do Acre passaram a indexar normalmente, entretanto vamos trabalhar nos styles porque com a poly aumentada muitos dados da Bolívia que não nos interessam começaram a aparecer no mapa do Brasil. []s Marcio From: Gerald Weber Sent: Tuesday, September 2, 2014 10:42 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites administrativos Marcio, sua preocupação é bem justificada. Estas tags poderiam não ser estritamente necessárias na way, se já existissem na relation, mas também não estavam fazendo mal a ninguem. Vou repetir o que disse no outro post: Não mexa no que está feito, procure fazer o que falta. abraço Gerald ___ 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] Limites administrativos
Amigos, me preocupa muito alterações significativas no mapa sem o devido debate com a comunidade. Na tentativa de alavancar o OSM no Brasil implantamos, sem fins comerciais, o site http://cocardl.com.br onde disponibilizamos mensalmente (sempre no dia 1) o mapa do Brasil e da América do Sul para usuários de GPS. Visando atingir um maior publico também disponibilizamos esses mapas nos sites que administramos Gpsinfo e Maparadar. Com isso a comunidade brasileira que emprega o GPS foi apresentada ao OSM por esses sites e acreditamos que estamos colhendo frutos disso em função do incremento de novos participantes no Projeto, seja por edições ou abertura de notas. Só identificamos as alterações realizadas recentemente nos limites administrativos no centro oeste e norte do Brasil quando começaram a pipocar nos sites que administramos informações de falta de indexação, no mapa que disponibilizamos dia 1/09/2014, de algumas cidades que não eram encontradas na busca pelo GPS, a grande maioria de usuários de Brasília - DF e poucos do Estado do Acre. Pode até ser que o Mkgmap suporte a leitura da TAG Boundary nas relações e como participante da lista dele já identifiquei a resposta ao Nelson lá feita. On Mon, Sep 01, 2014 at 09:05:44PM -0300, Nelson A. de Oliveira wrote: Does mkgmap support administrative boundaries defined only by relations? (ie, there isn't any kind of tag in the ways) This at least used to work. I wrote the apply rules for getting names on the boundaries from the relations, separated by / or ,. It might have been broken since I wrote the code. For this code, I introduced the $(name) syntax, so that I could append to the existing name. Marko Essa resposta só vem demonstrar que alterações desse tipo, inclusive diferente do padrão aplicado no OSM por outros países, merecem analise de implicações antes de executadas. Infelizmente nós do COCAR fomos surpreendidos com ela após críticas recebidas e vamos envidar esforços na identificação de uma solução a nível renderizador. []s Marcio -Mensagem Original- From: Nelson A. de Oliveira Sent: Monday, September 1, 2014 7:47 PM To: Tarcisio Oliveira Cc: OSM talk-br Subject: Re: [Talk-br] Limites administrativos (respondam para mim também, por favor, porque não recebo mais mensagem da talk-br) On 01-09-2014 14:26, thunder...@gpsinfo.com.br wrote: O limite administrativo fica assim mesmo sem etiqueta e só formatado nas relações? Sim, pode ficar apenas assim. É uma forma válida de uso. Qual a aplicação que não está reconhecendo os limites definidos por relações e que está sendo utilizada para gerar os mapas? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites administrativos
Marcio, sua preocupação é bem justificada. Estas tags poderiam não ser estritamente necessárias na way, se já existissem na relation, mas também não estavam fazendo mal a ninguem. Vou repetir o que disse no outro post: Não mexa no que está feito, procure fazer o que falta. abraço Gerald 2014-09-02 11:45 GMT-03:00 thunder...@gpsinfo.com.br: Amigos, me preocupa muito alterações significativas no mapa sem o devido debate com a comunidade. Na tentativa de alavancar o OSM no Brasil implantamos, sem fins comerciais, o site http://cocardl.com.br onde disponibilizamos mensalmente (sempre no dia 1) o mapa do Brasil e da América do Sul para usuários de GPS. Visando atingir um maior publico também disponibilizamos esses mapas nos sites que administramos Gpsinfo e Maparadar. Com isso a comunidade brasileira que emprega o GPS foi apresentada ao OSM por esses sites e acreditamos que estamos colhendo frutos disso em função do incremento de novos participantes no Projeto, seja por edições ou abertura de notas. Só identificamos as alterações realizadas recentemente nos limites administrativos no centro oeste e norte do Brasil quando começaram a pipocar nos sites que administramos informações de falta de indexação, no mapa que disponibilizamos dia 1/09/2014, de algumas cidades que não eram encontradas na busca pelo GPS, a grande maioria de usuários de Brasília - DF e poucos do Estado do Acre. Pode até ser que o Mkgmap suporte a leitura da TAG Boundary nas relações e como participante da lista dele já identifiquei a resposta ao Nelson lá feita. *On Mon, Sep 01, 2014 at 09:05:44PM -0300, Nelson A. de Oliveira wrote:* *Does mkgmap support administrative boundaries defined only by relations? (ie, there isn't any kind of tag in the ways)* *This at least used to work. I wrote the apply rules for getting names on the boundaries from the relations, separated by / or ,. It might have been broken since I wrote the code.* *For this code, I introduced the $(name) syntax, so that I could append to the existing name.* *Marko* Essa resposta só vem demonstrar que alterações desse tipo, inclusive diferente do padrão aplicado no OSM por outros países, merecem analise de implicações antes de executadas. Infelizmente nós do COCAR fomos surpreendidos com ela após críticas recebidas e vamos envidar esforços na identificação de uma solução a nível renderizador. []s Marcio -Mensagem Original- From: Nelson A. de Oliveira Sent: Monday, September 1, 2014 7:47 PM To: Tarcisio Oliveira Cc: OSM talk-br Subject: Re: [Talk-br] Limites administrativos (respondam para mim também, por favor, porque não recebo mais mensagem da talk-br) On 01-09-2014 14:26, thunder...@gpsinfo.com.br wrote: O limite administrativo fica assim mesmo sem etiqueta e só formatado nas relações? Sim, pode ficar apenas assim. É uma forma válida de uso. Qual a aplicação que não está reconhecendo os limites definidos por relações e que está sendo utilizada para gerar os mapas? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Dr. Gerald Weber gwebe...@gmail.com Personal website https://sites.google.com/site/geraldweberufmg/ ResearchGate Profile https://www.researchgate.net/profile/Gerald_Weber2 Departamento de Física/Universidade Federal de Minas Gerais Department of Physics/Federal University of Minas Gerais Campus da Pampulha Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil mobile: +55-(0)31-96462277 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Pessoal, desculpem estar entrando tarde. Estive nos EUA a trabalho e os e-mails acumularam. Em que pesem os problemas apontados pelo Márcio, consideremos: 1) Não mapear para o mkgmap; 2) A tag is_in deve ser descontinuada; 3) Se a indexação está incoerente, há algo no mapa que o mkgmap não está vendo, possivelmente por causa de algum problema ou no mkgmap propriamente dito ou por erro no style file, já que mexi nele para se adequar às necessidades do Brasil. Linha de ação: 1) Pegar Pirassununga e uma cidade corretamente indexada e ver o que há de diferente que impacte a indexação; 2) Alterarmos o style file para indexar corretamente; 3) Se 2) não resolver, reportar o problema na lista mkgmap-dev. []s Paulo Em 10 de maio de 2014 21:05, Fernando Trebien fernando.treb...@gmail.comescreveu: Vou usar um contra-exemplo pra estimular a reflexão (porque é um assunto indefinido), mas acho não precisamos nos aprofundar muito porque colocar essa tag no nó faz pouca diferença na prática. Onde faz diferença mesmo é na relação do limite, que sempre deve ter a tag admin_level. O nó que representa a cidade de Berlim tem a tag admin_level: http://www.openstreetmap.org/node/240109189 Assim como o de Londres: http://www.openstreetmap.org/node/107775 Já o wiki (http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative ), supostamente escrito em inglês britânico, diz que não se deve usar essa tag em nós, contradizendo a prática estabelecida de longa data sem explicar o motivo. O wiki já dizia isso em 2010 (podem conferir no histórico do artigo), não mudou nenhuma vez, e essas cidades continuam com essa tag. Eu acho que o que eles querem dizer é que não é pra sair colocando admin_level em tudo. Faltou então alguém escrever que a exceção é que dá pra colocar no nó com a tag place associado à relação, mas não em outros lugares. Um dos problemas de colocar a tag no nó e na relação é que, por acidente (esquecimento/desconhecimento ao editar), ela pode acabar tendo valores diferentes. E daí (como a informação é replicada) algumas aplicações vão consumir de um lugar (digamos, do nó), outras vão consumir de outro (da relação), e daí elas vão se comportar de um jeito diferente caso o valor não seja igual isso acontecer - uma confusão desnecessária. Mas esse problema acontece com todas as outras tags replicadas entre o nó de lugar e a relação do limite (ex.: name), e, ao que parece, isso não tem solução ainda. 2014-05-10 16:06 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Usando o exemplo de Campo Grande. É uma cidade, mas vale a mesma coisa para bairros e outras delimitações. O limite (a relação que define a área da cidade) possui admin_level=8: http://www.openstreetmap.org/relation/334022 Já o nó da cidade não possui esta informação: http://www.openstreetmap.org/node/319054316 Para bairros deve ser exatamente a mesma coisa: admin_level apenas no limite administrativo. O nó recebe apenas o tipo do lugar, nome, etc. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ 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] Limites Administrativos.
Não li toda a conversa (é bem longa) então posso estar falando alguma bobagem. Mas aí vão os meus 20 centavos. label serve para especificar onde o nome da área relativa ao limite administrativo deve ser renderizado. Ainda cabe à aplicação seguir essa especificação ou não. admin_centre serve para especificar onde fica o centro administrativo do limite administrativo. Para um estado, é a capital. Para uma cidade, normalmente é a prefeitura (mas não acho que chegou a ser discutido). Por mera convenção (que não está escrita em pedra, mas que se pode observar sendo adotada em vários países): * Cidades têm só admin_centre, que normalmente é bem próximo à prefeitura (o centro administrativo da cidade); * Estados têm label e admin_centre. O admin_centre do estado é o mesmo ponto do admin_centre da capital do estado. Ou seja, esse ponto pertence a duas relações de limite administrativo, tendo o papel admin_centre nas duas; * Países, tal como estados, têm label e admin_centre, e o admin_centre do país é o mesmo da capital. No Brasil, seria o ponto que representa o lugar Brasília. Esse ponto é o único no Brasil que participa de 3 relações de limite administrativo com o papel admin_centre (ver no final: http://www.openstreetmap.org/node/34567423) As cidades normalmente não têm label porque (suponho, porque nunca vi escrito) a maioria dos cartógrafos o colocaria na mesma posição do admin_centre da cidade, porque não faz muito sentido posicionar o label de um município no seu centro geométrico (considerando os contornos do município, não os contornos da região urbana do mesmo). Cidades podem ter um label separado de um admin_centre? Podem, todas as relações de limite administrativo (país, estado, cidade, bairro) podem ter um membro label posicionado arbitrariamente. Parecido com isso, não faz muito sentido posicionar obrigatoriamente o label de um bairro no seu centro. O local onde mais faz sentido é no ponto considerado o núcleo do bairro, o ponto mais visitado, o mais importante, onde o bairro nasceu, etc. O mesmo vale para uma cidade, onde o ponto mais importante geralmente é uma porção urbanizada, que pode ficar bem longe do centro geométrico do limite administrativo. A única diferença é que bairros normalmente não têm admin_centre. (Essa já seria uma discussão bem avançada, mas poderíamos talvez convencionar em colocar o admin_centre dos bairros na respectiva associação de moradores.) Já num estado sim faz sentido posicionar o label no centro geométrico porque a capital normalmente tem uma renderização especial. Mas enfim, essas são meras convenções de renderização, que (no mkgmap) se misturam com a lógica que associa cidades a estados. É fato que a maioria das cidades brasileiras não está com o ponto label incluído na lista de membros da relação de limite administrativo. Deveriam estar? Deveriam. Mas não por causa do mkgmap em especial. Deveriam ter as tags is_in? Na minha opinião, idealmente não, essas tags são informação redundante e várias aplicações trabalham corretamente (e mais corretamente! já que o valor em is_in pode contradizer a geometria) sem a presença dessas tags. As tags is_in são proibidas? Não, e como são amplamente usadas, e não queremos afastar as pessoas que usam o mkgmap, acho que podem ser usadas até que o programa as suporte, mas de preferência não em tudo (se possível não em cada POI de cada cidade; isso geraria uma quantidade enorme de redundâncias difícil de gerenciar depois). Seria bom pra comunidade do OSM que alguém se envolvesse com o desenvolvimento do mkgmap para ajudar a alinhar a visão dos desenvolvedores à visão da comunidade do OSM. Do contrário, sempre teremos ideais que nunca virarão realidade. Mesmo uma correção simples, multiplicada por 5500, seria uma tarefa árdua. Uns meses atrás, eu consertei a relação nos principais (capitais + 2 cidades grandes em cada estado), na esperança de algum dia inspirar as pessoas a fazer o mesmo nas cidades do interior do seu estado. Em vários estados (especialmente nas regiões norte e nordeste) nem mesmo as capitais estavam corretas. O motivo: não temos colaboradores envolvidos trabalhando nessas áreas ainda. Em algumas até temos, mas não chegaram a estudar da complexidade dos limites administrativos, talvez porque considerem mais urgentes outros problemas do mapa. Mas qualquer um pode sair fazendo a correção, a qualquer hora, em qualquer lugar. Pode até transformar isso numa mapping party. Ou num desafio de programação. 2014-05-10 0:09 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-05-10 0:01 GMT-03:00 thunder...@gpsinfo.com.br: Foi dito que ele não é necessário e agora o label, mesmo não sendo necessário porque o nome vai aparecer mesmo no centro geométrico do estado, tem seu emprego defendido? Continuo não atingindo. Eu não estou defendendo label. Eu apenas tentei explicá-lo quando você perguntou sobre o que seriam os dois nós na relação do MS. ___ Talk-br mailing
Re: [Talk-br] Limites Administrativos.
label serve para especificar onde o nome da área relativa ao limite administrativo deve ser renderizado. Ainda cabe à aplicação seguir essa especificação ou não. Até onde sei, os renderizadores atuais, indexam o nome de uma área definida no centro geométrico dela, independente da existência de label. Isso ocorre também para polígonos que não são de limite administrativo. Em nossa compilação estamos dando comando para que esse ponto seja indexado próximo a uma via roteavel. admin_centre serve para especificar onde fica o centro administrativo do limite administrativo. Para um estado, é a capital. Para uma cidade, normalmente é a prefeitura (mas não acho que chegou a ser discutido). Deveria ser o marco zero dela porque esse marco tem relação com a numeração de porta nas vias da cidade. Na cidade de São Paulo esse marco é na Praça da Sé e oficialmente a menor numeração de porta nas vias deveria estar mais próxima a esse marco zero, ou seja, toda numeração de porta deve partir do ponto mais próximo ao marco zero. As cidades normalmente não têm label porque (suponho, porque nunca vi escrito) a maioria dos cartógrafos o colocaria na mesma posição do admin_centre da cidade, porque não faz muito sentido posicionar o label de um município no seu centro geométrico (considerando os contornos do município, não os contornos da região urbana do mesmo). Partindo do principio que os renderizadores atuais desconsideram essa label criada e criam a sua, também não faz sentido ter o label de estado no centro geométrico dele (considerando os contornos do estado, não os contornos do município onde está sua capital. Como tenho de sair da net neste momento só deixo registrado que no Rio de Janeiro existe a figura de subprefeituras que administram os bairros. Essas estão ligadas a Prefeitura do município. Nessa caso, na minha opinião, haveria o admin_centre para o nível 10. Ps: Estarei daqui a 20 minutos saindo para viagem ao exterior e só voltarei dia 23. Pode ser que eu não leia a tempo qualquer comentário a respeito desse assunto. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Por causa desse problema com o mkgmap eu estou vendo usuário mudando os lugares corretamente classificados como place = suburb, por exemplo, para place = yes + admin_level = 10 Não sei se houve discussão sobre isso em outro lugar, mas por favor, não modifiquem os dados nos OSM apenas por causa de uma aplicação. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
2014-05-10 14:06 GMT-03:00 A. Carlos anorcar...@hotmail.com: Problema com o Mkgmapp? O que o Mkgmapp pegou foi e indexou foi cidades erradas como o exemplo que o Márcio citou abaixo, onde cidades nível 8 estavam com Nivel 4. Isso eu corrigi (tirando o admin_level da cidade, que não deve existir). Indexação errada no mkgmap não justifica colocar admin_level nas cidades e nem utilizar place = yes. Admin_level =10 , os que eu alterei eu TENHO CERTEZA que são BAIRROS...lá está bem especificado o que é Nivel 10. Não, Anor. Você trocou lugares que são corretamente definidos por place = suburb para place = yes + admin_level = 10, por exemplo. Não existe definição de place = yes. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Nelson eu posso ter errado no place=yes, Agora dizer que Bairro não pode ser admi_level =10?? então me dá um exemplo CLARO onde admi_level=10 se enquadra... ___ Anor C. A. de Souza Concórdia SC 49-8808-4963 Date: Sat, 10 May 2014 14:10:58 -0300 From: nao...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Limites Administrativos. 2014-05-10 14:06 GMT-03:00 A. Carlos anorcar...@hotmail.com: Problema com o Mkgmapp? O que o Mkgmapp pegou foi e indexou foi cidades erradas como o exemplo que o Márcio citou abaixo, onde cidades nível 8 estavam com Nivel 4. Isso eu corrigi (tirando o admin_level da cidade, que não deve existir). Indexação errada no mkgmap não justifica colocar admin_level nas cidades e nem utilizar place = yes. Admin_level =10 , os que eu alterei eu TENHO CERTEZA que são BAIRROS...lá está bem especificado o que é Nivel 10. Não, Anor. Você trocou lugares que são corretamente definidos por place = suburb para place = yes + admin_level = 10, por exemplo. Não existe definição de place = yes. ___ 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] Limites Administrativos.
2014-05-10 15:52 GMT-03:00 A. Carlos anorcar...@hotmail.com: eu posso ter errado no place=yes, Agora dizer que Bairro não pode ser admi_level =10?? então me dá um exemplo CLARO onde admi_level=10 se enquadra... admin_level é um atributo apenas do limite administrativo, da borda que define o bairro, cidade, estado, etc, e não do lugar em si (do nó onde se utiliza place = suburb, por exemplo). admin_level=10 sim, é um bairro, mas este atributo não vai no nó que possui o nome do bairro. Este atributo fica apenas na relação que define toda a área do bairro. A confusão está contecendo nessa parte: está se colocando admin_level nos nós de cidades, bairros, etc, enquanto essa informação já existe no local correto, que é o limite administrativo. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Usando o exemplo de Campo Grande. É uma cidade, mas vale a mesma coisa para bairros e outras delimitações. O limite (a relação que define a área da cidade) possui admin_level=8: http://www.openstreetmap.org/relation/334022 Já o nó da cidade não possui esta informação: http://www.openstreetmap.org/node/319054316 Para bairros deve ser exatamente a mesma coisa: admin_level apenas no limite administrativo. O nó recebe apenas o tipo do lugar, nome, etc. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Vou usar um contra-exemplo pra estimular a reflexão (porque é um assunto indefinido), mas acho não precisamos nos aprofundar muito porque colocar essa tag no nó faz pouca diferença na prática. Onde faz diferença mesmo é na relação do limite, que sempre deve ter a tag admin_level. O nó que representa a cidade de Berlim tem a tag admin_level: http://www.openstreetmap.org/node/240109189 Assim como o de Londres: http://www.openstreetmap.org/node/107775 Já o wiki (http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative), supostamente escrito em inglês britânico, diz que não se deve usar essa tag em nós, contradizendo a prática estabelecida de longa data sem explicar o motivo. O wiki já dizia isso em 2010 (podem conferir no histórico do artigo), não mudou nenhuma vez, e essas cidades continuam com essa tag. Eu acho que o que eles querem dizer é que não é pra sair colocando admin_level em tudo. Faltou então alguém escrever que a exceção é que dá pra colocar no nó com a tag place associado à relação, mas não em outros lugares. Um dos problemas de colocar a tag no nó e na relação é que, por acidente (esquecimento/desconhecimento ao editar), ela pode acabar tendo valores diferentes. E daí (como a informação é replicada) algumas aplicações vão consumir de um lugar (digamos, do nó), outras vão consumir de outro (da relação), e daí elas vão se comportar de um jeito diferente caso o valor não seja igual isso acontecer - uma confusão desnecessária. Mas esse problema acontece com todas as outras tags replicadas entre o nó de lugar e a relação do limite (ex.: name), e, ao que parece, isso não tem solução ainda. 2014-05-10 16:06 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Usando o exemplo de Campo Grande. É uma cidade, mas vale a mesma coisa para bairros e outras delimitações. O limite (a relação que define a área da cidade) possui admin_level=8: http://www.openstreetmap.org/relation/334022 Já o nó da cidade não possui esta informação: http://www.openstreetmap.org/node/319054316 Para bairros deve ser exatamente a mesma coisa: admin_level apenas no limite administrativo. O nó recebe apenas o tipo do lugar, nome, etc. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
2014-05-09 17:52 GMT-03:00 thunder...@gpsinfo.com.br: Se for isso acredito que teremos muito trabalho pela frente porque não são poucas as cidades nessa situação. Do jeito que os limites estão agora eles não estão errados (pelo menos o Nominatim e osmand eu sei que interpretam corretamente estas informações). Da maneira que eu entendi, aparenta ser uma limitação da aplicação que está utilizando estes dados. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
É o meu entendimento também. Ter o is_in=* em cada objeto é um mão na roda para os aplicativos, mas não é nada fácil para os mapeadores manterem essa informação no mapa. 2014-05-09 18:04 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-05-09 17:52 GMT-03:00 thunder...@gpsinfo.com.br: Se for isso acredito que teremos muito trabalho pela frente porque não são poucas as cidades nessa situação. Do jeito que os limites estão agora eles não estão errados (pelo menos o Nominatim e osmand eu sei que interpretam corretamente estas informações). Da maneira que eu entendi, aparenta ser uma limitação da aplicação que está utilizando estes dados. ___ 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] Limites Administrativos.
Só para complementar, antes de começar a modificar todas as cidades/limites do Brasil (e começar a inserir uma chave que não é mais necessária, a is_in), eu sugiro perguntar e explicar isso na lista de desenvolvimento do mkgmap. O Gerd (que desenvolve o mkgmap) é bem atencioso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
2014-05-09 18:22 GMT-03:00 thunder...@gpsinfo.com.br: Entendo então que o MKGMAP é limitado? Limitado no sentido de não estar compreendendo o que seja um estado (ou por falta de alguma opção ao executar o mkgmap ou por falta de implementação). Por que alguns limites administrativos de município (nivel 8) tem o nó de relação dele geralmente na sede (cidade sede do município) e a grande maioria dos limites administrativos de municípios no mapa OSM não tem essa relação? Os limites podem ter um nó de centro administrativo ou um nó de label. Mas a ausência deles não é um erro. São informações opcionais. O is_in é uma chave antiga, da época que não existiam os limites administrativos. Ainda existe, mas não é necessário mais. O que o Nomination e osmand estão interpretando para a sede do limite administrativo do município quando não existe a relação como no exemplo que dei: Pirassununga - SP ? Dá pra ver diretamente no Nominatim como ele interpreta os dados. No caso de Pirassununga: http://nominatim.openstreetmap.org/details.php?place_id=97596400 Mas de qualquer forma, é melhor perguntar na lista do mkgmap sobre isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Nelson, creio que você não entendeu. Citei que uma aplicação (Mkgmap) me atentou para uma situação incoerente no mapa do Brasil onde alguns estados eram indexados e outros não. Essa situação que me levou a analisar como esses estados estavam configurados no OSM. Ao analisar os limites administrativos dos estados brasileiros, identifiquei que 80% deles tinham o is-in e 20% não, ou seja somente padronizei a todos e posso tranquilamente reverter se for necessário desde que se decida que padrão adotaremos. O que não pode é 80% com e 20% sem como estava. Antes de mudar analisei em outros países e todos que analisei contem o is-in. Pesquisei bastante no wiki sobre o is-in e só encontrei sugestões de inclusão da chave. Onde está normatizado que essa chave não é mais necessária? Espero que o Gerard saiba disso e que o pessoal do Mkgmap esteja trabalhando a respeito. Outra situação é a que já reportei anteriormente onde aproximadamente 20% dos limites administrativos municipais tem em sua relação o objeto cidade sede do município e a grande maioria não tem. Isso também não é necessário? Qual o certo? -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 6:20 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. Só para complementar, antes de começar a modificar todas as cidades/limites do Brasil (e começar a inserir uma chave que não é mais necessária, a is_in), eu sugiro perguntar e explicar isso na lista de desenvolvimento do mkgmap. O Gerd (que desenvolve o mkgmap) é bem atencioso. ___ 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] Limites Administrativos.
Entendi sim. Foi isso que eu tentei te explicar: o is_in é uma chave antiga, que não é obrigatória (e nem se deve adicioná-la). Ver em http://wiki.openstreetmap.org/wiki/Key:is_in#When_to_use.3F Eu também tentei explicar que se o mkgmap não interpreta corretamente alguns objetos pela ausência do is_in, é porque isso é uma limitação dele. Se um objeto está dentro de um limite, a aplicação deve entender que este objeto faz parte daquela área, mesmo que não exista um is_in. Sobre os limites com cidade sede (os admin_centre), como eu já disse, também são opcionais (assim como label). Ver http://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Nelson, seguindo sua orientação para ir a pagina http://wiki.openstreetmap.org/wiki/Key:is_in#When_to_use.3F ali identifiquei que não existe impedimento ao uso do is-in . Existem ainda controvérsias do seu uso ou não. O que me chamou a atenção na pagina foi: Description This tag lets you by specify, with words, where a place or feature is in the world. It can be used with anything, pubs, buildings, streets, parks but is most likely to be used with places. It is recommended that it is ALWAYS used with place tags to help some search engines - for example there are several places called San Francisco in the world (Philippines, Spain, USA), but to return only the one in California would required something like: name=San Francisco is_in=California; CA; USA Particularmente concordo com essa citação porque facilita muito aos sistemas de busca a inclusão do is-in Uma coisa que me chamou a atenção depois foi ver a tradução para o portugues dessa página: Controversy Por favor note que essa marca é controversa e tem gerado muitas discussões quentes em várias ocasiões. Os proponentes dizem que alguns pesquisa-motores são ajudados pela tag is_in. Opositores afirmar que é totalmente redundante, pois onde o nó é pode ser derivado das fronteiras de polígonos que cercam o local. Outro argumento é que os valores utilizados para a tag são tão inconsistentes que não é principalmente útil de qualquer maneira. Muitas contribuições definitivas apagar essas marcas como se depararem com elas. Mas, como sempre com OSM, o que é indicado aqui no wiki não é a forma oficial de fazer as coisas. Faça a sua própria mente. Está desatualizada? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Leia a discussão em http://wiki.openstreetmap.org/wiki/Talk:Key:is_in (os 3 primeiros tópicos) Não é que esteja errado utilizar is_in, mas é desnecessário adicioná-la (e só serve para contornar a limitação de algumas aplicações). Gera trabalho e inchaço supérfluo no OSM. Talvez resolva esse problema se utilizar o mkgmap com --location-autofill=nearest,is_in (ao invés de utilizar is_in antes). Mas eu perguntaria/pediria na lista do mkgmap para que ele passasse a utilizar os limites administrativos, sem a necessidade de is_in. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Discussão sobre a situação entendo como uma coisa e decisão global outra. Pelo que analisei até o presente momento não existiu consenso da comunidade para se modificar a pagina sobre is-in e aquela pagina ainda recomenda o seu emprego para facilitar os motores de busca. Desconheço o percentual de emprego dos dados do OSM, mas deduzo que o Mkgmap supera em muito outros aplicativos. Vamos manter o is-in para facilitar a indexação pelo Mkgmap ou vamos deixar de emprega-lo na esperança que o Mkgmap se adeque a sua falta? Não é por aí que vamos garimpar colaboradores para o mapa do Brasil. -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 7:44 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. Leia a discussão em http://wiki.openstreetmap.org/wiki/Talk:Key:is_in (os 3 primeiros tópicos) Não é que esteja errado utilizar is_in, mas é desnecessário adicioná-la (e só serve para contornar a limitação de algumas aplicações). Gera trabalho e inchaço supérfluo no OSM. Talvez resolva esse problema se utilizar o mkgmap com --location-autofill=nearest,is_in (ao invés de utilizar is_in antes). Mas eu perguntaria/pediria na lista do mkgmap para que ele passasse a utilizar os limites administrativos, sem a necessidade de is_in. ___ 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] Limites Administrativos.
Em 9 de maio de 2014 20:07, thunder...@gpsinfo.com.br escreveu: Vamos manter o is-in para facilitar a indexação pelo Mkgmap ou vamos deixar de emprega-lo na esperança que o Mkgmap se adeque a sua falta? Se existe o caminho correto, ele deve ser buscado. Não é por aí que vamos garimpar colaboradores para o mapa do Brasil. A decisão meramente técnica nada tem a ver com garimpar ou não colaboradores para o mapa do Brasil. Alexandre Magno ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Marcio, Na verdade já dá para fazer isso no mkgmap, usando --bounds: The style file can be used to assign the address tags mkgmap:country, mkgmap:region etc. using these values. Então não há realmente necessidade de se adicionar is_in nos dados. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Estamos empregando o --bounds Continuando minha analise fui ver porque a cidade de Campo Grande - MS não estava indexando como cidade de MS. Olha o que encontrei para ela: Fica difícil indexa-la como cidade se ela está com nível administrativo 4. 4 é para estado e cidade é 8. Não alterei ainda para que vocês possam ver. -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 8:19 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. Marcio, Na verdade já dá para fazer isso no mkgmap, usando --bounds: The style file can be used to assign the address tags mkgmap:country, mkgmap:region etc. using these values. Então não há realmente necessidade de se adicionar is_in nos dados. ___ 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] Limites Administrativos.
2014-05-09 20:53 GMT-03:00 thunder...@gpsinfo.com.br: Continuando minha analise fui ver porque a cidade de Campo Grande - MS não estava indexando como cidade de MS. Fica difícil indexa-la como cidade se ela está com nível administrativo 4. Isso é erro no objeto (e no mkgmap, de certa forma). admin_level é apenas para o limite administrativo, e não para o place. Precisa corrigir isso (remover os admin_level dos nós de cidades e deixar a informação apenas no limite). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Eu vou arrumar esses lugares com admin_level. Tem 15 cidades apenas (e é coisa bem antiga, de 2008, 2009). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Não computo erro ao mkgmap já que ele me apontou o erro no osm. Até sou de opinião que ele acertou já que identificou incoerência de dados e indexou Campo Grande no Brasil e não em Mato Grosso do Sul. Ainda para Mato Grosso do Sul observe que tem 2 objetos na relação do estado MS. Por gentileza me diga que objeto é esse relacionado e também com nível 4 https://www.openstreetmap.org/edit?relation=334051#map=19/-19.58550/-54.47845 -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 9:01 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. 2014-05-09 20:53 GMT-03:00 thunder...@gpsinfo.com.br: Continuando minha analise fui ver porque a cidade de Campo Grande - MS não estava indexando como cidade de MS. Fica difícil indexa-la como cidade se ela está com nível administrativo 4. Isso é erro no objeto (e no mkgmap, de certa forma). admin_level é apenas para o limite administrativo, e não para o place. Precisa corrigir isso (remover os admin_level dos nós de cidades e deixar a informação apenas no limite). ___ 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] Limites Administrativos.
2014-05-09 21:17 GMT-03:00 thunder...@gpsinfo.com.br: Não computo erro ao mkgmap já que ele me apontou o erro no osm. Ele apontou o problema, mas ao mesmo tempo ele interpretou este dado de forma incorreta (deveria ignorar o valor do admin_level contido no place). E essa relação https://www.openstreetmap.org/relation/334051 é o próprio estado do MS. Possui um objeto label (onde é exibido o nome do estado) e um admin_centre (a capital). Por isso há dois objetos além do próprio contorno. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Cada vez entendo menos. O MKGMAP não apontou o problema, ele simplesmente não cumpriu a ordem de indexar a cidade ao estado porque a própria cidade estava como estado. Eu que por meio dele identifiquei o problema. Agora ele ignorar um comando não sei se é possível já que o comando existe. Seria querer demais de um aplicativo em desenvolvimento. Se a relação por mim apontada é o objeto label do próprio estado, por que a maioria dos estados brasileiros não tem essa relação dessa forma? Por que esse objeto não é a Cidade capital Campo Grande que inclusive é o admin_center do estado? Porque esse objeto está com nível 4? Afinal o estado de MS está com duas relações com nível 4: esse objeto e a cidade de Campo Grande. Pelo que andei vendo a maioria dos estados brasileiros tem essa relação na sua capital e não no meio do mato como está essa para o MS. -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 9:24 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. 2014-05-09 21:17 GMT-03:00 thunder...@gpsinfo.com.br: Não computo erro ao mkgmap já que ele me apontou o erro no osm. Ele apontou o problema, mas ao mesmo tempo ele interpretou este dado de forma incorreta (deveria ignorar o valor do admin_level contido no place). E essa relação https://www.openstreetmap.org/relation/334051 é o próprio estado do MS. Possui um objeto label (onde é exibido o nome do estado) e um admin_centre (a capital). Por isso há dois objetos além do próprio contorno. ___ 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] Limites Administrativos.
O admin_level da cidade de Campo Grande eu corrigi (só a relação do estado e da cidade possuem admin_level agora). E até onde eu lembro todos os estados possuem label e admin_centre, da mesma forma que o MS. O Fernando tinha atualizado isso. O label fica em posição diferente da capital do estado justamente para que ambos os nomes (da capital e do estado) estejam visíveis. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Na tentativa de identificar os resultados incoerentes na indexação pelo Mkgmap já havia identificado essa label introduzida no centro geométrico do estado, mas confesso que não identifico sua necessidade uma vez que o limite administrativo absorve tudo contido dentro dele e os indexadores indexam (ou deveriam indexar) como sendo dele. Como ele não recebe nível administrativo não entra na indexação atual pelo Mkgmap. Não consigo vislumbrar a necessidade de se ter um objeto, sem nível administrativo, posicionado no centro geométrico do Estado e tendo relação com o estado. Não conheço outros aplicativos, mas até sei e testei o Mkgmap identifica todos os objetos contidos no interior do limite administrativo e os relaciona aquele. O que não pode ocorrer é como estava no Mato Grosso do Sul esse ponto com nível adm 4. Se batermos martelo nessa necessidade por que não inseri-la também para limites administrativos municipais? Observe o município de Sorocaba - SP que também não está sendo indexado corretamente pelo Mkgmap. Pelo que vejo o limite administrativo do município não tem admin_centre e tampouco a label comentada. Como esse, empregando a indexação com o Mkgmap, identifico inúmeras situações semelhantes. Finalmente desejo deixar registrado que o meu objetivo não é apontar erros e sim resgatar (se existe) a padronização de procedimentos de forma que eu e os demais façamos o mesmo quando da edição e que os utilizadores não identifiquem as incoerências que venho identificando. -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 9:52 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. O admin_level da cidade de Campo Grande eu corrigi (só a relação do estado e da cidade possuem admin_level agora). E até onde eu lembro todos os estados possuem label e admin_centre, da mesma forma que o MS. O Fernando tinha atualizado isso. O label fica em posição diferente da capital do estado justamente para que ambos os nomes (da capital e do estado) estejam visíveis. ___ 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] Limites Administrativos.
2014-05-09 22:35 GMT-03:00 thunder...@gpsinfo.com.br: Não consigo vislumbrar a necessidade de se ter um objeto, sem nível administrativo, posicionado no centro geométrico do Estado e tendo relação com o estado. O label pode não ter uso para navegação, mas para renderização sim. Se batermos martelo nessa necessidade por que não inseri-la também para limites administrativos municipais? Não são necessários, mas sim, pode adicionar admin_centre e/ou label em todos os municípios. Só que o trabalho é grande. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
Se a label tem uso para renderização do estado por que não é necessária para renderização do município? Ela não teria uso para município? Por que? Lembro que município recebe nível adm 8 e depois dele ainda temos alguns outros níveis administrativos empregados no Brasil e contidos dentro de município. Não consegui alcançar a diferença. O poder adicionar não é a questão. Se um adiciona e outro não estaremos despradronizados, o que não é recomendável. Estou perseguindo uma padronização de procedimentos de forma a minimizar erros encontrados por utilizadores. -Mensagem Original- From: Nelson A. de Oliveira Sent: Friday, May 9, 2014 10:46 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] Limites Administrativos. 2014-05-09 22:35 GMT-03:00 thunder...@gpsinfo.com.br: Não consigo vislumbrar a necessidade de se ter um objeto, sem nível administrativo, posicionado no centro geométrico do Estado e tendo relação com o estado. O label pode não ter uso para navegação, mas para renderização sim. Se batermos martelo nessa necessidade por que não inseri-la também para limites administrativos municipais? Não são necessários, mas sim, pode adicionar admin_centre e/ou label em todos os municípios. Só que o trabalho é grande. ___ 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] Limites Administrativos.
2014-05-09 23:03 GMT-03:00 thunder...@gpsinfo.com.br: Se a label tem uso para renderização do estado por que não é necessária para renderização do município? Ela não teria uso para município? Por que? O propósito do label é apenas mover o local onde é exibido o nome do local. Não é necessário (o nome vai aparecer do mesmo jeito no centróide do objeto). É apenas uma forma de forçar que o nome seja exibido em uma localidade diferente. Por exemplo, daria para usar label em uma cidade muito grande: o place dela poderia ficar no marco zero enquanto que o label na região central (diferente do centróide). Lembro que município recebe nível adm 8 e depois dele ainda temos alguns outros níveis administrativos empregados no Brasil e contidos dentro de município. Sim, 9 para distritos e 10 para bairros. Essas informações ficam nos devidos limites administrativos (e não no nó da cidade/distrito/bairro). O poder adicionar não é a questão. Se um adiciona e outro não estaremos despradronizados, o que não é recomendável. Eu não vejo como falta de padrão justamente porque é um atributo opcional (e que gera bastante trabalho). Se cada um classificar as rodovias da maneira que bem entender, isso é falta de padronização (a classe da via é um atributo obrigatório). Deixar de colocar o admin_centre/label de um lugar é igual deixar de colocar opening_hour em um restaurante, por exemplo. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
O propósito do label é apenas mover o local onde é exibido o nome do local. Não é necessário (o nome vai aparecer do mesmo jeito no centróide do objeto). É apenas uma forma de forçar que o nome seja exibido em uma localidade diferente. Forçar para quem ou para o que? Estávamos debatendo sobre o is_in que na minha opinião força o que julgamos obvio. mas que por enquanto, na minha analise e opinião, é necessário para o Mkgmap. Foi dito que ele não é necessário e agora o label, mesmo não sendo necessário porque o nome vai aparecer mesmo no centro geométrico do estado, tem seu emprego defendido? Continuo não atingindo. Sim, 9 para distritos e 10 para bairros. Essas informações ficam nos devidos limites administrativos (e não no nó da cidade/distrito/bairro). Citei esses níveis administrativos além de município porque imaginei que existiria alguma relação com níveis administrativos para se criar o label. Apesar de julgar não necessário, continuo não atingindo o motivo para se criar o label no estado e não em município. Não observei, mas criaram label para região? Sul, Sudeste, leste, etc... (nível 3) Eu não vejo como falta de padrão justamente porque é um atributo opcional (e que gera bastante trabalho). Se cada um classificar as rodovias da maneira que bem entender, isso é falta de padronização (a classe da via é um atributo obrigatório). Deixar de colocar o admin_centre/label de um lugar é igual deixar de colocar opening_hour em um restaurante, por exemplo. Não vejo assim. Não vejo comparação de admin centre/label com opening hour de restaurante. Pode ser que no futuro optem por indexar opening hour de objetos inseridos, mas por enquanto só conheço a importância de indexação das cidades capitais de estados e das cidades sedes de municípios. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Limites Administrativos.
2014-05-10 0:01 GMT-03:00 thunder...@gpsinfo.com.br: Foi dito que ele não é necessário e agora o label, mesmo não sendo necessário porque o nome vai aparecer mesmo no centro geométrico do estado, tem seu emprego defendido? Continuo não atingindo. Eu não estou defendendo label. Eu apenas tentei explicá-lo quando você perguntou sobre o que seriam os dois nós na relação do MS. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
