Re: [Talk-br] Como criar a interpolação de endereços

[Marcio]

Em Qua, Set 28, 2016 em 11:40 , Paulo Carvalho 
 escreveu:
É assim mesmo.  As interpolações, assim como os números pontuais, 
são linhas ou pontos à parte da via, normalmente paralelos e 
próximos.  O que os liga de forma inequívoca é a tag addr:street 
em cada ponto da interpolação, e, na falta dela, a proximidade 
espacial é usada para "ligar" os números ao logradouro.


Correto.

A via não possui numeração. A numeração é referente a elementos 
que tem endereço na via, como casas, escritórios, etc.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Projeto de teste para integração com overpass

[Marcio]

Em Sex, Set 23, 2016 em 11:15 , George Silva  
escreveu:
Novamente entendo e até concordo com isso. A dúvida surgiu para 
entender se existe um padrão ou recomendação geral

da comunidade sobre o assunto.

Até agora neste tópico, "conto os seguintes votos" (veja vem que 
estou contando apenas para fomentar a discussão, não estou dizendo 
que alguma decisão está de fato sendo tomada no tópico):


* 3 a favor de manter as vias juntas
* 3 a favor de manter as vias separadas

Não enxergo consenso :D.


A minha opnião é que não existe desvantagem em ter as ruas 
segmentadas, porém eu não fico dividindo as ruas. Somente quando 
cruzam bairros ou os trechos são muito longos.


Como falei, segmentar as ruas é um processo natural a medida que vão 
sendo inseridos mais detalhes na mesma (restrição de conversão, 
faixar, largura, velocidade, superficie).
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Projeto de teste para integração com overpass

[Marcio]

Não tenho opnião forte no assunto, mas discordo do Arlindo. Não há 
justificativa para manter a rua como apenas um segmento, mas existem 
razões para ela ser quebrada em trechos menores. Uma que conheço é 
para melhorar o endereçamento do Nominatim. No reverse geocode ele 
utiliza a rua mais próxima do ponto solicitado, mas para identificar o 
endereço ele usa o centroide da rua encontrada. Logo, se a rua/avenida 
cruzar mais de um bairro ou vizinhança ele pode informar o nome da rua 
correto no bairro/local errado.


Quebrar a rua em trechos menores não traz nenhum problema e acaba 
sendo um processo natural no mapeamento ao introduzir relações de 
restrição, diferentes superfícies, diferentes larguras, velocidade 
máxima, etc.




Em Qui, Set 22, 2016 em 6:32 , George Silva  
escreveu:
Sim Arlindo. Mas minha dúvida é: este dado, usualmente não deveria 
ser quebrado no OSM?


2016-09-22 18:17 GMT-03:00 Arlindo Pereira 
:

Legal!

Quanto à sua dúvida: parte da dificuldade de se mapear os 
transportes públicos é justamente quebrar as vias em múltiplos 
pedaços para múltiplas rotas - e o momento seguinte, eventualmente 
alterar categorias da via em todos esses segmentos. No caso, a 
interface teria que ter alguma opção para dado um ponto que 
intersecta duas linhas, segmentasse as duas, resultando em 4 linhas.



[]s
Arlindo Pereira

Em 22 de setembro de 2016 17:07, George Silva 
 escreveu:
Pessoal, uns dias atrás falei de um projeto de integração com o 
Overpass para que as prefeituras pudessem manter os dados de linhas 
de transporte, baseados no OSM.


Bem, fiz uns testes de integração, usando o Leaflet, Jquery e 
mais umas besteirinhas para testar o que queremos aqui na empresa, 
no momento de construir e editar o trajeto.


O projeto está disponível aqui:

https://gitlab.sigmageosistemas.com.br/dev/overpass-selector

Ele depende do bower para ser rodado.

Para rodar, instale o bower e clone o repositório.

Dentro da pasta do repositório, digite bower install. Ele irá 
instalar as dependências todas. Após essa instalação, abra a 
página index.html.


O funcionamento é simples. Dê um duplo clique para definir um 
ponto e um segundo duplo clique para definir o segundo ponto. A 
aplicação irá se comunicar nesse momento com o Overpass e trazer 
todas as ways dentro desse envelope.


A partir disso, ele permite que você selecione as vias, clicando 
nas mesmas.


É só uma prova de conceito, mas acho que vai ser útil aqui

.




Uma dúvida: no segundo screenshot, vocês podem ver que a via 
possui muitos trechos. No momento de mapear, não seria ideal que 
estes trechos estejam quebrados? Na verdade, farei outro email 
sobre isso.


Abraços

--
George R. C. Silva
Sigma Geosistemas LTDA

http://www.sigmageosistemas.com.br/

___
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





--
George R. C. Silva
Sigma Geosistemas LTDA

http://www.sigmageosistemas.com.br/
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Uma coisa é o esperado de acordo com a teoria e outra o observado na pratica 
em exaustivos testes.



A criação do nó em si não interfere, a princípio, com o algoritmo.
Será um nó a mais a ser visitado enquanto o grafo é explorado pelo
algoritmo de roteamento.


O algoritmo, dentre outros, trata os nós e é por eles que ele traça a rota.

Já fizemos inúmeros testes de roteamento e identificamos que o roteamento, 
entre duas vias iguais, ele opta pela que tem menos nós.


Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá na 
frente, como um losango.

Divida um segmento de reta de uma das vias inserindo um nó nela.
Identificará que o roteamento se dá pela via que não tem o nó inserido.
Foi assim que nos testes constatamos a influência de partições de via em um 
roteamento.


-Mensagem Original- 
From: Fernando Trebien

Sent: Sunday, July 5, 2015 4:52 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-05 1:40 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:
Por outro lado lembro que classificação de vias e de velocidades 
interferem
no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O 
que

sabemos sobre ele advém de exaustivos testes realizados.
Não estamos debatendo tempo e sim roteamento e tudo que interfere nele.
Como bem deve saber você o roteamento leva em consideração, além de 
outros,
a quantidade de nós empregados para unir os segmentos de reta na 
retratação

da via.
Ao se reduzir a velocidade de um trecho de via o editor é obrigado a 
dividir
a via de forma a poder no trecho dividido estabelecer a velocidade. Isso 
por

si só já afeta o calculo de rota por aquele trecho.


Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos
de roteamento.

O que acontece é que ele cria um novo nó no grafo de roteamento para
representar o trecho. O nó contem o tempo total para percorrer o
trecho, calculado dividindo distância por velocidade. (há variações em
que o nó contem ambas velocidade e distância e o cálculo do tempo é
feito durante o processamento, mas elas são matematicamente
equivalentes)

A criação do nó em si não interfere, a princípio, com o algoritmo.
Será um nó a mais a ser visitado enquanto o grafo é explorado pelo
algoritmo de roteamento.

O que acontece é que algoritmos diferentes usam heurísticas
diferentes. Algumas dessas heurísticas decidem descartar alguns nós
que eles acham que têm pouca chance de conduzir à melhor rota.
Heurística é um método matematicamente impreciso para chegar a uma
solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas
melhores e piores. Uma heurística comum é visitar primeiro os nós
relativos às vias de maior classificação. Nesse caso, como a
classificação não foi alterada, o nó seria visitado mesmo tendo uma
velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística
que eu desconheço.

Outro insight: explorar o gráfico requer somar esses tempos, trecho
por trecho. São milhares de operação de soma. Se o programa não for
bem construído, ele pode acumular erros numéricos ao somar milhares de
números. O OSRM me parece particularmente sensível a esses erros. O
Garmin geralmente opera num hardware limitado e talvez também seja
sensível (tratar desses erros numéricos requer usar mais memória).

Mais um insight: classificação interfere com esses algoritmos mais
simples que usam heurísticas. A classificação das vias não
interfere em nada com o algoritmo A* (a-estrela) puro, nem com o
algoritmo do OSRM. Por isso, classificações não devem ser alteradas
com vistas ao roteamento. No entanto, um bom método de classificação
serve bem a praticamente qualquer algoritmo de roteamento, não por ser
o objetivo da classificação, mas por ser efeito colateral dela.

Se, numa rota com vários quilômetros, a escolha de uma alternativa ou
outra depender de um trecho tão curto quanto o mencionado, é bem
provável que alguma dessas características esteja inteferindo no
resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem
os desenvolvedores da aplicação sem ter que reescrevê-la por completo
para resolver algum problema mais profundo.

O que os roteadores prometem não é encontrar a melhor rota, mas uma
rota sub-ótima. Quanto mais longa a distância, maior o efeito desses
dois fatores (erro numérico e qualidade da heurística). Até mesmo o
Waze às vezes faz bobagem na tentativa de encontrar a melhor rota.

--
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] Necessidade de intermediação

[Marcio - Thundercel]

From: Fernando Trebien
Sent: Sunday, July 5, 2015 3:47 AM


Sem problemas. Caso você não tenha mais a cópia da trilha, seria
possível o residente contribuir essa trilha para o OSM pelo mecanismo
padrão de submissão das trilhas? Acho que isso sana todas as dúvidas.


Me perdoe, mas a partir do momento que minha edição foi questionada e minha 
palavra foi posta em duvida, não solicitarei e tampouco apresentarei 
qualquer tracklog do local. As provas de que fiz o correto virão com as 
atualizações das imagens satélites.
Se desejarem voltar o desenho para o estampado no Bing desatualizado, sem 
problema.
Já me desgastei muito com essa situação e perdi muito tempo justificando uma 
edição.
O mais interessante é que ficam se prendendo a detalhes e deixam de corrigir 
a ponte sobre o Rio Madeita ( BR-319 ) que se encontrava com etiqueta em 
construção e esqueceram de verificar que essa ponte já consta das fontes 
ilícitas e que foi inaugurada em 15/09/2014
conforme noticiado em 
http://g1.globo.com/ro/rondonia/noticia/2014/09/inaugurada-ponte-que-liga-rondonia-ao-amazonas-em-porto-velho.html
Corrigido o erro em http://www.openstreetmap.org/way/243298056 e só espero 
que eu não seja novamente questionado por ter editado e colocado a ponte em 
operação.



Sei que dá mais trabalho, mas para não ter que arquivar, e não ter que
se preocupar com as justificativas posteriores, poderia submeter as
trilhas ao OSM. Não precisa ser todas, só aquelas que podem esclarecer
polêmicas. Acredito que poucas das trilhas coletadas divergem da
imagem de satélite atual (as coisas mudam, mas geralmente só perto das
vias principais), então seriam poucas trilhas a submeter ao OSM.


Se observou atentamente já existe trilha de trecho desse novo trevo 
arquivada no OSM por alguém, mas de qualquer forma não é do meu feitio ficar 
arquivando dados para comprovar minha palavra. Poso errar sim, mas erro 
porque edito. Seria facil passar de editor para fiscal e talvez essa seja a 
melhor situação no OSM Brasil.




Também poderia não submeter, apenas guardá-las, e compartilhá-las em
caso de questionamento.

Guardo o que me interessa para futuras referencias.
Tenho auxiliado ao OSM por prazer e não tenciono começar a guardar provas 
das minhas edições porque deixa de ser prazer e passa a ser obrigação.



As etiquetas dos changesets são, a princípio, apenas informativas. O
objetivo da informação é permitir que outros mapeadores verifiquem a
informação que foi editada. Se você declara que fez survey, outro
mapeador pode lhe solicitar o tracklog ou fotos ou qualquer informação
que você tenha levantado, ou pelo menos entender que precisa confirmar
a informação em campo (ou seja, entender que ela não veio da imagem de
satélite).


A partir do momento que um mapeador declara em sua edição GPS;survey 
acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha é o 
OSM porquemais um colaborador, voluntariamente, atuou no mapa.



Da mesma forma, se sua informação viesse de uma prefeitura, você
colocaria a prefeitura na etiqueta source. Isso informaria os outros
mapeadores onde procurar a informação para confirmar:
- sua veracidade; e
- sua correção


Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado com 
survey.



Note que nem sempre questionar significa não acreditar em você. Ás
vezes o outro mapeador só quer saber se você transcreveu a informação
corretamente. Como disse, todos somos passíveis de erro, então o
questionamento é válido.


Creio que voce não atingiu minha ponderação.
Não sou contra questionamento, sou contra questionamento seguido de 
exp0licação e replicado com solicitação de prova em se tratando de 
GPS;survey.



Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma
informação fica lá sem que uma fonte seja citada para verificação. Se
a fonte não for fornecida, a informação pode ser removida por falta de
neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se
apresenta aos novos usuários. Tudo deve ser verificável, não somente
sob o ponto de vista da idoneidade, mas também do ponto de vista da
correção.


Não tem relação com survey.

Perfeito. Então o maxspeed no OSM está todo correto, mas o roteamento
dá uma rota inadequada. Curiosidade minha: é realmente inadequada, se
segue por um caminho mais rápido? (teoricamente, desconsiderando o
tráfego)

Sim, é inadequada porque transita por área urbana.
Gastaram muito dinheiro para fazer a BR-101 Estrada do Contorno.
Por ela que o roteamento deve passar.

Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que
seja uma declaração dizendo tá igual à [fonte X]? Acho que basta.

Não.
Minha palavra nesse caso basta.


Daí o que eu faria é acrescentar uma etiqueta note na linha contendo
o link para a mensagem dele que você encaminhou pra cá. Dessa forma,
outros mapeadores podem verificar a informação. Note que eu colocaria
isso em note (um comentário informal) e não em source (a fonte
usada para verificar com certeza 

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

From: Fernando Trebien
Sent: Sunday, July 5, 2015 4:31 AM


Todas não. Apenas as potencialmente polêmicas. A comunidade pode sim
julgar e discordar.
Não tenho duvida que a comunidade pode julgar e discordar de alguma edição, 
entretanto essa deve discordar pautada em alguma regra no OSM que foi 
descumprida pelo editor e não reverter os dados porque o editor deixou de 
apresentar tracklog de sua edição.



Dependendo do que chamas de análise, talvez não. Elas são, no
máximo, fontes de inspiração para que se priorize sua verificação
através de fontes lícitas.


As fontes lícitas são sempre empregadas, mas nada impede que o editor 
consulte como andam as fontes ilícitas.



Quando questionado, precisa. Espera-se isso de todos.


Me exclua desse todos,
Se isso for padrão OSM paro aqui minhas edições e vou desfrutar da minha 
aposentadoria e finalizar o projeto Cocar. 



___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Amigos,
me perdoem, mas enquanto alguns discordam de um lado outros discordam de outro.

Alguém poderia intermediar o debate em 
http://www.openstreetmap.org/changeset/30210630 ?

Se torna muito difícil fazermos edições no mapa pautados em colaborações 
recebidas de outros e termos que ainda ficar justificando essas edições porque 
as fontes normais de emprego ainda não retratam as alterações feitas na malha 
viária.

Acreditava eu que quando se colocava o source:GPS;survey já se tornava 
implícito que não foi empregado o Bing, MapBox, IBGE ou outra fonte aceita pelo 
OSM.

Obrigado.

Marcio ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Venho recebendo muitas informações de erros nessa área que comprometem o 
roteamento e aos poucos, com tempo, irei corrigir, se outro não o fizer antes.

Por exemplo:

A Avenida das Nações Unidas ( https://www.openstreetmap.org/way/358400706 ) é 
uma via de pista dupla e não pista simples de sentido duplo. Esse erro 
compromete o roteamento de todas as vias que nela se entronca pelo norte ou 
pelo sul.

A Avenida Raimundo Cantuária ( https://www.openstreetmap.org/way/338488263 ) só 
tem sentido único, de leste para oeste, até a Avenida das Nações Unidas, dela 
para oeste é via de mão dupla.

Para quem não sabe, a construção desse Trevo do Roque (nome dele) se arrasta há 
mais de 10 anos e foi até parar na justiça. Existe muita matéria na NET sobre 
ele.

A administração atual decidiu dar continuidade as obras e a circulação na área 
tem sido modificada constantemente devido as obras. Recentemente a Prefeitura 
abriu ao tráfego um novo acesso a BR-364 para quem trafega pela BR, sentido NW 
e deseja pega-la no sentido SW. Esse acesso passa por baixo dos viadutos.

Acabaram de incluir ali um acesso ( https://www.openstreetmap.org/way/358538171 
) que segundo informação que tenho ele não existe. Acredito que aquele que 
incluiu tenha certeza de que ele existe e não vou questionar se existe, ou não.

[]s
Marcio

-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 4:18 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

Marcio, lista talk-br

Primeiro meu pergunta e motivo para avisar no changeset fui duvida
sobre se roteamento realmente era possível, e vi Marcio tinha editado
no local. Eu poderia perguntar algum outros dos mapeadoras que
ideintificei como dbusse, mas como saber ele e alemão de armchair
mapping não poderia espera resposta inteligente dele.

No mesmo tempo que vi a problema de roteamento vi que tracklogs GPS
compartilhado no OSM não bati com Bing, significando que ha alterações
no local. Com isso eu vi que precisava melhor informação antes do
mexer, eu poderia rever pra situacao do Bing, que também e mesmo no
MapBox, mas com o evidencia do OSM-GPS isso seria ação errado e mais
conhecimento necessário, outro motivo para enviar mensagens para
Marcio.

Alem isso, eu confirei com o camada do Strava Heatmap também mostrou
falta do various partes nesse trevo, independente se for versão Bing
ou versão OSM-GPX ou como desenhado pelo Marcio. Para quem não
conhecer o Strava, muitos trackers esportivas, relógios, e similares
gravando pontos onde voce correr, passiando bicicletas e outros
atividades, e esses logs e visualicado nesse camada. Para uso aqui no
Brasil, muito pessoas usando esses aplicativas errados, e com isso dar
para identificar estradas também.

Depois muito discussão, e o Marcio resolvendo algum dos erros e faltas
que identifiquei, ainda ovei algumas erros, que tentei corrigir aqui
https://www.openstreetmap.org/changeset/32412378

Marcio, favor entra em contato com seus fontes no Porto Velho, para
eles verificar se meus edições e certo. Tudo esse seus discussão nesse
changeset seu for por caso do um pergunta sobre roteamento duvidoso.

Para volta ao assunto do do informação usado e compartilhado: No meu
opinião, tracklogs utilizado para atualizar a mapa sempre deve ser
compartilhados. Se não pode compartilhar o tracklog por motivos de
copyright não podemos utiliza-los para corrigir o mapa, em conforme da
licenciamento ODbL.

Para tira duvida sobre imagens Bing, MapBox ou outros imagens
verticais, que sempre pode ser desatualizados, sempre usando mais
camadas para compartilhar meu decisão a trazer ruas e estradas. Sempre
usando Bing e MapBox em conjunto, não confie totalmente em nenhuma
deles. Geralmente também tem OSM-GPX e Strava as overlay junto com
esses imagens verticais, e quando procurando problemas especificas de
roteamento também OSMI Routing.

As camadas IBGE eu uso quando procura informação especifica do que
pode tirar deles.

Nao sei se iD pode ter mais que um camada ativa, sei que Potlatch no
versão 1 não poderia e provavelmente também não em versão 2. Por isso
o único editor da mapa considerado para uso e o JOSM.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Nelson,
com assessoramento de um residente editei esse novo trevo há 3 meses atrás.

De lá para cá a edição que fiz sofreu alterações inclusive com a inclusão de 
acessos inexistentes e acessos impróprios não permitindo inclusive o acesso 
citado que não permitia roteamento correto. Simplesmente editei toda a área 
novamente corrigindo a situação por mim deixada 3 meses atrás.


Nesses casos seria interessante identificar os autores de changeset e 
questionar a eles.


De qualquer forma não considero pertinente dar prosseguimento a pergunta e 
ainda duvidar da palavra do editor quando esse insere source:gps;survey, 
inclusive questionando a esse editor porque não foi compartilhado os 
tracklogs recebidos. Até onde sei compartilhar tracklog é recomendado, mas 
não obrigatório.


Apontar erros em uma edição é normal, mas não existindo erro, apontar que a 
edição não confere com as referencias satélite não concordo uma vez que o 
source inserido foi gps e survey e essa informação, até onde sei, supera 
qualquer outra fonte satélite de referência disponível.


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Saturday, July 4, 2015 3:02 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-04 14:34 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:

Alguém poderia intermediar o debate em
http://www.openstreetmap.org/changeset/30210630 ?


Ele queria saber sobre essa situação do trevo:
http://i.imgur.com/RWtGdON.png

Que depois foi corrigido para isso:
http://i.imgur.com/nzQ6O1t.png

Antes de ser corrigido, o estado anterior dele estava bem errado (não
permitia roteamento corretamente).
Repare que quem vinha da rodovia primary não conseguia seguir para o
lado direito na trunk.

A dúvida dele era justamente sobre aquela situação inicial, se aquilo
estava realmente correto.


___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Conforme já citei a você anteriormente e somente a titulo de ilustração porque 
as fontes não podem ser empregadas no OSM:

Tracklogs atualizados no trevo:

http://gpsinfo.com.br/images/portovelho2.jpg

Mapa Waze atualizado segundo informação do residente local:

http://gpsinfo.com.br/images/portovelho.jpg

Mapa Here atualizado no trevo também segundo informação desse mesmo residente:

https://www.here.com/?map=-8.77122,-63.88256,18,normalx=ep

Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e um 
histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo depois 
que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso em 
http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html

Compreenda também que estamos tratando de vias automotivas e não vias para 
bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas podem 
valer de referência para se desenhar vias ou links automotivos.

O desenho que havia eu feito refletia as informações recebidas por mim de um 
residente local e você as está alterando por deduções e não vejo isso como 
correto.

Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso 
passando por baixo do viaduto que foi aberto ao tráfego na semana passada. 
Estou aguardando ele me retornar.

Se você cita que faço edições que não concorda também não concordo com muitas 
que você faz e nem por isso vou a você questionar a fonte de referencia 
empregada e mesmo informando eu replicar que não é verdade.

Creio que essas discussões também não levam a nada e como você citou, se 
pararmos para ficar debatendo essas pequenas situações deixaremos de corrigir 
os inúmeros erros ainda existentes no mapa. Como você também não vou questionar 
seus erros, vou corrigi-los diretamente, mas continuo aguardando a correção do 
roteamento incorreto pela ES-060 que você se prontificou a corrigir. Creio que 
pelo visto serei obrigado a corrigir as velocidades incorretamente incluídas em 
trecho da rodovia. 



-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 6:48 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

 Acabaram de incluir ali um acesso ( 
 https://www.openstreetmap.org/way/358538171 ) que segundo informação que 
 tenho ele não existe. Acredito que aquele que incluiu tenha certeza de que 
 ele existe e não vou questionar se existe, ou não.

Eu tentei mostra para voce tudo evidencia que esse link existe, como
voce não quer compartilhar seus fontes, e nem olhando o informação que
eu tentando mostra para voce, eu precisava editar o trevo para mostra
a voce.

Segundo Strava tem muito fluxo nesse link, e não credito que isso e
pessoas correndo ou pedalando.

Voce for la ver mesmo que esse link não existe? Eu procurando
Mapillary e outros fontes e não vejo nada contrario.

Sim, vejo ainda que tem muito dados para melhorar no local, mas voce
não queria acertar quando primeiro perguntou voce sobre problemas de
roteamento, independente se for voce ou outros pessoas quebrando, so
depois muito discussão voce editou. A mapa e cheia do erros e
problemas e em vez acertar algum coisa quando alertada voce decide
começar um guerra contra o pessoa que voce mostrando isso?

Muitos vezes eu vi voce fazer edicoes que não concordo, ou que acho
errado, e cada vez apontando algum coisa a voce sair com mesmo tipo
resposta.

Bom, as fontes voce tem talvez tem melhor conhecimento local, mas eu
adicionei esse link por causa do evidencia de fluxo no local. Se voce
não passou esse trevo mesmo, e não pode compartilhar dados provando o
existência ou falta do existência esse link eu não tem outro escola em
creditar que o evidencia que tem do fluxo dos veicules e valido.

Se cada vez eu apontando um erro a voce eu vou peder 2 dias com
discussão ate voce decide jogou na lista eu vou parar de apontar ao
voce os erros na mapa e somente concerta-los como acho certo, sem
avisar a voce. Eu poderia resolver esse situação rapidamente sem
gastar tudo esse tempo.


On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 Venho recebendo muitas informações de erros nessa área que comprometem o
 roteamento e aos poucos, com tempo, irei corrigir, se outro não o fizer
 antes.

 Por exemplo:

 A Avenida das Nações Unidas ( https://www.openstreetmap.org/way/358400706 )
 é uma via de pista dupla e não pista simples de sentido duplo. Esse erro
 compromete o roteamento de todas as vias que nela se entronca pelo norte ou
 pelo sul.

 A Avenida Raimundo Cantuária ( https://www.openstreetmap.org/way/338488263 )
 só tem sentido único, de leste para oeste, até a Avenida das Nações Unidas,
 dela para oeste é via de mão dupla.

 Para quem não sabe, a construção desse Trevo do Roque (nome dele) se arrasta
 há mais de 10 anos e foi até parar na justiça. Existe muita matéria na NET
 sobre ele.

 A administração atual decidiu dar continuidade as obras e a circulação na
 área

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Paciência tem limite.

Infelizmente não é a você que são dirigidos os erros do mapa.

Quer dizer que o emprego do gps survey só é válido se existir o 
compartilhamento do tracklog no OSM? Novidade para mim.

Quer dizer que outras fontes de referencia não licenciadas no OSM não podem 
servir ao editor como fonte alternativa e secundária de análise? Novidade para 
mim.

Se o HERE, WAZE, YAHOO e outras fontes de analise não podem ser empregadas por 
mim como consulta não sei o que estou fazendo aqui e porque estou debatendo 
esse assunto.

Quem citou Tracksource aqui? Não emprego e nunca empreguei o Tracksource como 
fonte  de consulta para minhas edições até porque ele contem mais erros que o 
OSM.

Sei muito bem que todas essas fontes citadas e não licenciadas no OSM não podem 
ser empregadas na etiqueta source, mas citar, desconsiderar e descartar 
consulta a elas para sanar duvidas é um procedimento seu, não meu.
Não descarto nenhuma delas quando faço analise de determinada área ou região. 
Se você descarta e não as considera, paciência.

Por gentileza e em prol dos demais exclua os acessos que incluiu no trevo por 
dedução sua e que não existem.

Se desejamos ter um mapa atualizado e confiável devemos primeiramente confiar 
naqueles que ainda estão se empenhando em ajudar ao OSM no Brasil.

Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete também 
meu pensar:

Considero que toda pessoa que mapea age de boa fé, sem necessidade de 
questionamento, exceto em casos explícitos de vandalismo.
Atenciosamente,
Blademir Andrade - BladeTC



-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 7:35 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 Conforme já citei a você anteriormente e somente a titulo de ilustração
 porque as fontes não podem ser empregadas no OSM:

 Tracklogs atualizados no trevo:

 http://gpsinfo.com.br/images/portovelho2.jpg

Vejo que spread e muito grande nesses tracklogs, mas pode ser por
ferramenta do visualização, esses tracklogs pode ser compartilhadas
para o OSM? do onde eles são disponíveis?
 Mapa Waze atualizado segundo informação do residente local:

 http://gpsinfo.com.br/images/portovelho.jpg

Nao conheco esse feramenta do visualisazao, os dados não e do OSM,
isso e do TrackSource? Acho que e do um projeto ou  outro de mapas
crowdsource com licença não compatível com OSM, não confia muito isso
porque pode ha mesmo erros de falta do levantamento. Que a link não
existe no TS ou outros fontes similares não significa que não existe.
 Mapa Here atualizado no trevo também segundo informação desse mesmo
 residente:

 https://www.here.com/?map=-8.77122,-63.88256,18,normalx=ep
Mapas Here também tem mesmo problema, mapas crowdsource sobre licença
não compativel mesmo não confiável

 Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e
 um histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo
 depois que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso
 em
 http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html

Isso e informação novo para mim, porque voce não divulgou isso
primeira vez? Blog do um politico aparentemente do Porto Velho, que
quer usar o problemas de terminar obras nesse trevo para fim deles,
esse pode dar mais luz sobre situação admito.
 Compreenda também que estamos tratando de vias automotivas e não vias para
 bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas
 podem valer de referência para se desenhar vias ou links automotivos.

 O desenho que havia eu feito refletia as informações recebidas por mim de um
 residente local e você as está alterando por deduções e não vejo isso como
 correto.

 Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso
 passando por baixo do viaduto que foi aberto ao tráfego na semana passada.
 Estou aguardando ele me retornar.

Espero retorna dele, e se for posivel compartilhar os tracklogs dele
com o comunidade, vai ser muito util em disputas como esse, e talvez
podemos descobrir mais problemas do roteamento com isso?
 Se você cita que faço edições que não concorda também não concordo com
 muitas que você faz e nem por isso vou a você questionar a fonte de
 referencia empregada e mesmo informando eu replicar que não é verdade.

 Creio que essas discussões também não levam a nada e como você citou, se
 pararmos para ficar debatendo essas pequenas situações deixaremos de
 corrigir os inúmeros erros ainda existentes no mapa. Como você também não
 vou questionar seus erros, vou corrigi-los diretamente, mas continuo
 aguardando a correção do roteamento incorreto pela ES-060 que você se
 prontificou a corrigir. Creio que pelo visto serei obrigado a corrigir as
 velocidades incorretamente incluídas em trecho da rodovia.

Pelo roteamento do ES-060 e BR-101 entre Guarapari

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

-Mensagem Original- 
From: Aun Johnsen 
Sent: Sunday, July 5, 2015 12:11 AM 

 So para dar um dica que muito vezes passa no meu trabalho: se não ha 
 evidencia, não existe”

Não sei se é questão de idioma, mas evidencie no inglês é prova que por sua 
vez não é evidência no idioma português.
'Evidência', em português, significa aquilo que é claro, inequívoco, muito 
visível, incontestável.
Apresentei  três evidências, não evidences, e mesmo assim decidiu você se 
valer de sua “evidência” deduzindo o que viu no Strava. O pior, editou se 
valendo dele. 

 To vendo que dados do este fonte que voce citando e mais certa que os fontes 
 que eu mostrando, voce comentou que um dos links que eu inseri não existe, 
 mas segundo Strava ha muito fluxo nesse link. como esse e meia do um trevo 
 onde ha obras eu não posso creditar esse e tao   muitos pedestres. 
 Obviamente os dados do Strava não tem valor, porque seu fonte, que voce não 
 pode compartilhar, sabe melhor.

Um dos links não. Você inclui os seguintes trechos que segundo informação por 
mim recebida não existem:
- https://www.openstreetmap.org/way/358538171
- https://www.openstreetmap.org/way/358538169
- https://www.openstreetmap.org/way/358538166

Inclusive esse terceiro já está errado porque é um trecho de sentido duplo 
conectando um trecho de sentido único.

 Eu tenho mesmo motivos para desconfiar em WAZE e HERE como TS

Desconfiar do TS também desconfio até porque conheço os inúmeros erros dele, 
mas desconfiar da minha edição pautada em informações de residente, do Waze e 
Here, quando esses apontam para a mesma situação, é outra estória. Prefere você 
desconfiar de todos esses e incluir acessos pautados em sua dedução do que vê 
no Strava. Interessante essa ação.

 Bom voce conheço esse trecho pelo seu amigo morando em Vila Velha, que voce 
 visitando regularmente, so em caso voce tem duvida, eu moro no Guarapari e 
 viaje muito, e por acaso esse trecho e entre meu casa e o aeroporto.

Sim e você sabe disso porque recentemente editei uma Rua em Vila velha que 
estava com nomenclatura incorreta e como fiscaliza todas as edições também no 
changeset dessa edição comentou e tive a oportunidade de ali informar que 
trafeguei pela rua no fim de semana e identifiquei o erro.

 Se 150 metros de 40km/h vai fazer muito diferencia pelo tempo? Acho que não. 
 Se o posto e do PM ou PRE e muito fácil verificar, como esse trecho em ambos 
 sentidos e documentado pelo Mapillary

Lembro ao nobre amigo que não são 150m e sim 500m a sinalização vertical para 
redução de velocidade para passagem a frente de posto policial rodoviário.
Por outro lado lembro que classificação de vias e de velocidades interferem no 
roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O que 
sabemos sobre ele advém de exaustivos testes realizados.
Não estamos debatendo tempo e sim roteamento e tudo que interfere nele.
Como bem deve saber você o roteamento leva em consideração, além de outros, a 
quantidade de nós empregados para unir os segmentos de reta na retratação da 
via. 
Ao se reduzir a velocidade de um trecho de via o editor é obrigado a dividir a 
via de forma a poder no trecho dividido estabelecer a velocidade. Isso por si 
só já afeta o calculo de rota por aquele trecho. 

 Quantos veze eu preciso esplicar, eu colhendo dados para melhorar o 
 roteamento urbano, com esse eu espero que resolver varias dos problemas que 
 dando roteamento pelo zona urbano nas gps do Garmin. Eu tentando também busca 
 informação sobre que tags que tem influencia
 desse roteamento para pode inserir dados certo na mapa. Os dados preciso ser 
 certas e adequadas.

Sim, já compreendemos isso, entretanto essa situação foi identificada em 
dezembro de 2014 e até o presente momento não identificamos solução a nível 
OSM. A nível renderizador já corrigimos, mas continuamos preocupados com os 
demais aplicativos que empregam roteamento.

On 7/4/15, Aun Johnsen li...@gimnechiske.org wrote:
 On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 -Mensagem Original-
 From: Aun Johnsen
 Sent: Saturday, July 4, 2015 9:56 PM
 To: OpenStreetMap no Brasil
 Subject: Re: [Talk-br] Necessidade de intermediação

Se voce quer entra em briga com pessoas sobre como voce mapeando, voce
pode manter seus tracklogs no seu computador ou ate apaga-los sem
compartilhar, mas esse so vai beneficiar seu ego do brigar, e não o
projeto ou comunidade. Eu compartilhando meus trilhos, e ativo no
Mapillary, e outros coisas que pode ajudar a comunidade em geral.
Provavelmente voce não vai ver as tracklogs que compartilho porque
publica-los como trackable, significando que eles são organizados
mas meu identificadora e segredo. Voce pode compartilhar assim, e isso
vai deixar tudo mundo acesso dos dados sem identificar voce
pessoalmente.

 É a sua opinião e respeito, entretanto minha formação é militar e por
 meio
 dela aprendi a sempre agir com lealdade e confiabilidade. Acredito no
 próximo

Re: [Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Creio que você inverteu a ordem ao citar:

Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e você me 
questionou até a exaustão. 


Tenho todo nosso debate aqui arquivado para relembrar se for necessário.

Vou desfez, sem qualquer consulta a mim,  uma edição que fiz em uma via do 
bairro onde resido e por onde trafego diariamente.


Questionei e você em replica disse que eu estava errado.

Apresentei fotos do local, legislação e tudo mais para poder lhe provar que 
o certo era eu.


Ali foi você que me questionou até a exaustão.

O caso do Aun é bem semelhante e esse questiona até a exaustão e o pior, 
põe em duvida a palavra do editor, o que para mim é inaceitável quando, não 
tendo eu mais o tracklog recebido, aponto fontes ilícitas de consulta. 
Ilícitas, ou não, não deixam de ser fontes de consulta que comprovam a 
veracidade dos fatos.


Por fim lembro que estamos aqui para colaborar voluntariamente com o OSM 
editando os erros existentes no mapa (que não são poucos) e ninguém gosta de 
ficar sendo questionado insistentemente por edições. Ser questionado é 
aceitável, mas duvidarem da palavra e das justificativas, não aceito.


Como tenho realizado muitas edições devido aos inúmeros reportes que recebo 
nos sites que administro e também por email, não são poucas as interpelações 
que recebo de edições feitas. Me parece até que o OSM Brasil tem mais 
fiscais do que editores. Será?


-Mensagem Original- 
From: Fernando Trebien

Sent: Saturday, July 4, 2015 8:44 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-04 20:04 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:

Paciência tem limite.


Verdade.


Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete
também meu pensar:

Considero que toda pessoa que mapea age de boa fé, sem necessidade de
questionamento, exceto em casos explícitos de vandalismo.
Atenciosamente,
Blademir Andrade - BladeTC


Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e
você me questionou até a exaustão. O Aun desfez um trabalho seu,
também agindo de boa fé, e você está fazendo o mesmo com ele. Me
parece conveniente essa interpretação seletiva dessa filosofia.

Sejamos colegas. Questionamentos são sempre bem-vindos, a quem quer
que seja. Precisamos ter o material para defender nossos mapeamentos
quando não está claro o que estamos fazendo (por exemplo, quando
diverge da imagem de satélite). Todos nós, sem exceção. Títulos e
honrarias não conferem autorização automática a todas as ações. Isso é
trabalhar em comunidade, sem hierarquias.

O questionamento só não faz sentido depois que o material já foi 
apresentado.


--
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] Necessidade de intermediação

[Marcio - Thundercel]

-Mensagem Original- 
From: Aun Johnsen

Sent: Saturday, July 4, 2015 9:56 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação


Se voce quer entra em briga com pessoas sobre como voce mapeando, voce
pode manter seus tracklogs no seu computador ou ate apaga-los sem
compartilhar, mas esse so vai beneficiar seu ego do brigar, e não o
projeto ou comunidade. Eu compartilhando meus trilhos, e ativo no
Mapillary, e outros coisas que pode ajudar a comunidade em geral.
Provavelmente voce não vai ver as tracklogs que compartilho porque
publica-los como trackable, significando que eles são organizados
mas meu identificadora e segredo. Voce pode compartilhar assim, e isso
vai deixar tudo mundo acesso dos dados sem identificar voce
pessoalmente.


É a sua opinião e respeito, entretanto minha formação é militar e por meio 
dela aprendi a sempre agir com lealdade e confiabilidade. Acredito no 
próximo até prova em contrário.
O OSM não é um tribunal onde devemos nos resguardar com provas todas nossas 
edições.



Marcio, quando perguntando voce sobre dados, voce e muito rápido
mostrar fontes que não podemos utilizar para defender seu mapeamento.


Por gentileza, vamos comentar os fatos que estão descritos e arquivados no 
debate do changeset.
Não sei se é a sua dificuldade de idioma, mas ali pode rever você que 
apontei as fontes ilícitas e comentei que elas não poderiam ser empregadas 
no OSM, mas que serviam como fontes de analise.
Comentei que minha fonte de mapeamento foi um tracklog recebido de um 
colaborador que reside em Porto Velho e que infelizmente não o tenho mais e 
confesso que mesmo se o tivesse não o apresentaria porque não preciso ficar 
insistentemente justificando meus atos.



Eu mencionou o TrackSource so porque eu sei que o comunidade tem muito
trabalho identificar edições ilícito copiado do TS, mas não tem
conhecimento nesses dados. Voce me mostrou 2 imagens desse trevo do
fontes que eu não conheço, eu não sei se isso poderia ser TS ou não,
mas sempre pode ter suspeito desse. Eu vai achar muito ruim se vai
parecer voce copiando dados do TS, o trabalho do verificar seus 5000
changesets para identificar qual deles pode ser copiado do TS vai ser
um tarefa grande demais. Eu acho muito estranho que voce não quer
compartilhar com o comunidade os dados que te auxiliando resolver
problemas da mapa, ações muito simples de teu parte poderia resolver
muitos discussões rapidamente.


Mais uma vez identifico que sua dificuldade no idioma português não o 
permite ler adequadamente o que citamos.
Lá no debate do changeset informei as fontes WAZE e HERE. Se você diz agora 
que não conhece essas fontes ilícitas me desculpe, pois a maioria as 
conhece e imaginei que você também as conhecesse até porque la comentou você 
que o Waze empregou dados do OSM.



Sobre dropar o maxspeed no ES-060, fui 2 vezes que reverti ao
verdade no chão nesses trechos, uma vez do Marcio que resultou em um
discussão feia, ate aqui na lista, onde eu prometeu, a promessa que
não esqueci mas ainda não houve condições ao completar, a resolver
esse roteamento no forma melhor, outro vez fui um pessoa da MG que
coloquei 110 no tudo trecho do BR-101 dizendo que conheci a local
porque fui la nas ferias, eu moro no Guarapari, e frequentemente
andando esses trechos do BR-101 e ES-060 pra Vitoria, maioria dos
dados nesses trechos na mapa fui coletado por mim, e provavelmente
conheço esse trecho melhor que maioria das pessoas nesse lista.


Desculpe, mas citar que conhece o trecho melhor que a maioria do pessoal da 
lista é para mim prepotência.
Muitos conhecem o trecho, inclusive eu que por sinal estarei trafegando por 
ele na próxima semana quando estarei novamente indo a Vila Velha.



Eu sei que ainda pode errar, e sei que não e ideal com roteamento
jogando voce dentro Vila Velha e Vitoria em vez passar o contorno. Me
deixa explicar esse trecho melhor para vocês, o contorno do Guarapari
tem parte condições física que pode ser mapeado como highway=motorway,
esse trecho tem velocidade alta (110 e 80), cruzamento sem nível,
canteiro central dividindo as faixas fisicamente, e restrições de
pedestres e ciclistas, mas ainda mapeado como highway=trunk porque
acho rediculo ter um motorway de somente 10 quilometros, continuando
ES-060 pra Vila Velha o velocidade e 80 (antigamente tinha 110 mais
parte do trecho, mas acho fui reduzido para 80 por caso do
urbanização), fora do 2 trechos limitados, um do pedágio e outro
urbano, ha algum radares, mas maioria deles e do 80km/h, tem algum
novos também, principalmente no um area onde ha desenvolvimento
urbano. 2 lugares tem pista lateral com velocidade reduzido (60), mas
pista central ainda tem 80. Nesse parte tem muitos semáforos, ja
tentei mapear tudo mas pode faltar algum ainda. Parte urbano do Vila
Velha e Vitoria tem muitos semáforos, e possível ainda eles falto.


Conhecendo bem a ES-060 deve ter se esquecido que a velocidade máxima no 
trecho da ES-060 onde se

Re: [Talk-br] classificação de subprefeituras.

[Marcio - Thundercel]

Ainda não tenho opinião formada a respeito até porque os aplicativos que 
conhecemos não descem a nível subdistrito.

Existe um debate interessante a respeito em  
http://forum.openstreetmap.org/viewtopic.php?id=26430 . Ele foi iniciado, mas 
não concluído.


-Mensagem Original- 
From: Nelson A. de Oliveira 
Sent: Sunday, June 14, 2015 1:21 AM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]classificação de subprefeituras. 

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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

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

[Marcio - Thundercel]

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

[Marcio - Thundercel]

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] São Carlos, SP

[Marcio - Thundercel]

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 - Thundercel]

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

[Marcio - Thundercel]

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