Importei os PDF no Inkscape https://pt.wikipedia.org/wiki/Inkscape e
exportei (salvei) como SVG https://pt.wikipedia.org/wiki/SVG. Era PDF
vetorial https://pt.wikipedia.org/wiki/Desenho_vetorial. Então eu enviei
os SVG para o wiki e eles estão sendo exibidos com largura
Oi pessoal,
Recentemente mais mensagens tem caído na moderação por causa do tamanho.
Praticamente todas por causa de imagens em anexo.
Aumentei o tamanho máximo para 300 kb, que é suficiente para a exibição de
uma imagem de resolução média.
Se alguém precisar enviar uma imagem em alta, peço que
O Pixel, aqui do Ecolab, fez a apresentação.
2014-05-07 14:34 GMT-03:00 Marcel Mitsuto F. S. mitsuto+...@gmail.com:
alguém do Serpro
2014-05-07 14:33 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:
On Wed, May 7, 2014 at 2:22 PM, Alexandre Magno Brito de Medeiros
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
É 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:
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.
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
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
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
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
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
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
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
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.
___
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
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).
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
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
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
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.
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
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
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
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
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 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
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
27 matches
Mail list logo
