date:20130520

2013/5/18 Fernando Trebien fernando.treb...@gmail.com:
 Para isso, acho que é necessário diferenciar mais claramente uma via
 não-track que seja de terra de uma via track. Um caso que me
 parece ambíguo é a diferença entre uma via tracktype=grade1 e outra
 que tivesse surface=sand e highway=unclassified.

Eu diria que largura da via (track de forma geral tem espaço para um
veículo, enquanto que ruas e estradas de terra suportam mais do que
um).
Mas eu já tracei vias com trechos que só permitem um veículo (ponte
estreita, túnel, cruzamento com trilhos, etc). Isso não faz delas uma
track, apenas uma estrada com lanes=1

 (http://wiki.openstreetmap.org/wiki/Key:tracktype). Talvez você
 encontre um dia uma via estreita, de terra compactada, que você não
 julgue como trilha. Então, qual o seu critério?

Na dúvida é melhor deixar como highway=unclassified e surface=unpaved
ao invés de track.
É melhor errar para cima do que para baixo em casos assim.

 Não queria divergir muito da discussão principal, mas o OsmAnd sempre
 me deu rotas inexplicavelmente distantes das rotas ótimas, mesmo antes
 de eu classificar as vias da minha cidade e de eliminar os erros no
 mapa que afetavam o roteamento. Uso principalmente o OSRM (mas não é
 para celular), cujo peso para vias do tipo track é parecido com o de
 outras vias (um pouco menor que uma residential, mas não tanto
 quanto living_street por exemplo). Cito também o Mapfactor Navigator
 (que é para celular Android e usa os mapas do OSM) que tem pesos
 configuráveis mas inicialmente parecidos com os do OSRM. Acho que
 devemos considerar parcialmente os produtos do mapa ao mapear, ou
 seja, considerar o efeito tanto no OsmAnd quanto no OSRM (e, como
 defendi antes, um pouco também no rederer), mas eu tenho a impressão
 de que o OsmAnd, apesar de conveniente, não usa um algoritmo que
 produz rotas ótimas, como o algoritmo de Dijkstra (sem heurísticas),
 ou o de contração de hierarquias, que o OSRM usa, então teria cuidado
 ao fazer alterações no mapa voltadas a fazer esse navegador específico
 funcionar melhor.

Note que o OSRM não roteia através de tracks! (para você ver como
alguns aplicativos dão peso zero a este tipo de via)
O osmand possui um algoritmo melhor (mas ainda experimental) nas
últimas versões.

E em nenhum momento eu defendi fazer alterações baseadas em algum programa ;-)
Eu defendo que os dados sejam sempre corretos no OSM, independente de
serem exibidos ou utilizados de uma forma inconveniente (não
diferenciar superfície), por exemplo.

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

Re: [Talk-br] Hierarquia das rodovias

Eu concordo com tudo que o Pedro e o Gerald disseram (com o que o
Vitor disse sobre as BR-4xx eu precisaria estudar mais) e achei os
fluxogramas muito bons.

Mas o problema que eu tentei abordar desde o começo é a ambiguidade
nas interpretações do que é comparativamente mais importante (qual o
raio de comparação?), do que é vicinal, do que é uma pequena
conurbação, e até o do que é paralela (pois nenhuma via é
absolutamente reta). Foi muito bom marcar as coisas ambíguas em
vermelho no fluxograma para guiar o debate, mas eu marcaria algumas
coisas a mais.

Acho melhor tentarmos nos concentrar nas características mensuráveis
da via para minimizar as nossas divergências. Parece que estamos nos
concentrando na classificação em área não-urbana, então vou considerar
apenas isso a seguir.

Parece que todos concordam que uma motorway precisa ter 2 pistas,
acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
faltar alguma dessas coisas, o máximo que ela poderia ser é trunk.

Para ser trunk, o Gerald e o Pedro parecem concordar que teria que ter
tudo isso exceto o canteiro central, e eu dispensaria a alta
velocidade também. (Em meio urbano, no entanto, uma trunk seria de
velocidade superior (80 km/h) à das avenidas principais (60 km/h) para
corresponder à definição no wiki.)

Isso faria com que as primárias do Gerald que fossem duplicadas e
tivessem acostamento se tornassem trunk e concordaria com os
fluxogramas do Pedro.

As primárias, então, seriam parecidas com as trunk, mas de pista
simples e com acostamento. Temos que pensar se o acostamento teria que
ser contínuo ou se aceitaríamos a sua ausência se houver refúgios com
certa frequência.

As secundárias poderiam ser as duplicadas sem acostamento. Isso
indicaria que ainda comportam bastante tráfego mas não foram tão bem
projetadas e podem oferecer alguns riscos. Nesse grupo entrariam
algumas estradas de praticamente todos os níveis administrativos.

(Acho que alguns prefeririam inverter essas duas definições anteriores
de acordo com o que acharem mais importante, segurança ou volume de
tráfego.)

As terciárias seriam então as de pista simples sem acostamento e pavimentadas.

As não-classificadas (unclassified) seriam as de pista simples não
pavimentadas e largas o bastante para fluxo de veículos nos dois
sentidos em quase todo o seu percurso. Seria uma via que bastaria
pavimentar (sem ampliar) para se tornar terciária.

Por fim, sobrariam as trilhas (track) que seriam as de pista simples,
não pavimentadas, onde apenas 1 veículo pode passar por vez.

O que acham? Isso poderia virar uma tabela bem simples para um
principiante seguir sem ter dúvidas.

2013/5/20 Gerald Weber gwebe...@gmail.com:
 Oi Pedro

 seus fluxogramas ficaram muito legais, parabéns pelo esforço interpretativo.

 2013/5/20 Pedro Geaquinto pedrodi...@gmail.com


 - Um muito próximo do que está escrito na wiki, que é a interpretação
 livre do Gerald: http://i.imgur.com/2IAfQT7.gif


 Eu notei que há várias partes na wiki descrevendo as hierarquias das
 rodovias e que não parecem consistentes entre sí. Acho que vamos ter de
 fazer uma busca geral.

 Sobre este fluxograma, acho que não ficou muito claro as caixas com
 vicinal no caso de rodovias não-pavimentadas e restrições  no caso de
 motorway. Eu trocaria restrições  por tem canteiro central, acessos
 especiais e não tem cruzamentos? ou algo assim.

 Trocaria vicinal por é de uso constante, larga e tem manutenção
 periódica?



 - Um intermediário da minha sugestão. Só com alguns parâmetros a mais que
 adicionei, para padronizar por exemplo o uso de unclassified:
 http://i.imgur.com/rcY2LC6.gif


 Ficou interessante também.



 - Minha sugestão. Com o conceito de importância que depende da
 interpretação da comunidade: http://i.imgur.com/MsqrZlp.gif


 Não querendo puxar a sardinha para a minha brasa, mas este fluxograma é o
 que melhor mostra a complexidade em optar por este esquema de classificação.




 Ah, e quanto a essa questão (meio off) de que se houvesse infraestrutura
 não haveria essa indagação: foi exatamente assim que eu comecei a me
 questionar. Essas vias que eu sugiro serem marcadas como trunk, por serem
 mais importantes que meras primary, deveriam ter sido duplicadas há tempos
 pelo tráfego pesado que recebem. Acaba que no Brasil temos corredores muito
 importantes com um formato totalmente desproporcional. É um atraso que temos
 no país, infelizmente.


 O país é gigante e pobre, e suas prioridades tem hora são muito estranhas.
 Não vejo como o resultado pudesse ser muito diferente.

 Nem por isto podemos marcar as rodovias pelo que elas deveriam ser, quer
 dizer, não faz sentido marcar uma rodovia como trunk por que ela deveria ser
 duplicada mas não é.

 mais uma vez obrigado por esta sistematização.

 abraço

 Gerald

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




-- 
Fernando Trebien
+55 (51) 9962-5409

Re: [Talk-br] Hierarquia das rodovias

2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
 Parece que todos concordam que uma motorway precisa ter 2 pistas,
 acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
 faltar alguma dessas coisas, o máximo que ela poderia ser é trunk.

OK.

 Para ser trunk, o Gerald e o Pedro parecem concordar que teria que ter
 tudo isso exceto o canteiro central, e eu dispensaria a alta
 velocidade também. (Em meio urbano, no entanto, uma trunk seria de
 velocidade superior (80 km/h) à das avenidas principais (60 km/h) para
 corresponder à definição no wiki.)

É o caso da SP-270 (Raposo Tavares): 2 faixas em cada sentido, sem
canteiro de separação (ou seja, lanes=4)
http://binged.it/19VHs60

Isso pra mim é trunk (por mais que seja duplicada e de alta
velocidade, eu não classifico com o mesmo porte de uma SP-310, SP-330,
SP-348, etc)

 As secundárias poderiam ser as duplicadas sem acostamento. Isso
 indicaria que ainda comportam bastante tráfego mas não foram tão bem
 projetadas e podem oferecer alguns riscos. Nesse grupo entrariam
 algumas estradas de praticamente todos os níveis administrativos.

Aqui fica estranho. Uma via de menor nível possui 2 faixas em um
sentido enquanto que uma maior (primary) não?

 O que acham? Isso poderia virar uma tabela bem simples para um
 principiante seguir sem ter dúvidas.

Eu acho bom dar exemplo em todas as definições, com imagens do Bing.

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

Re: [Talk-br] Hierarquia das rodovias

2013-05-20 Thread Arlindo Pereira

Opa,

duas faixas por sentido, até onde eu sei (posso estar enganado), é lanes=2,
não lanes=4.
[]s

2013/5/20 Nelson A. de Oliveira nao...@gmail.com

 2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
  Parece que todos concordam que uma motorway precisa ter 2 pistas,
  acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
  faltar alguma dessas coisas, o máximo que ela poderia ser é trunk.

 OK.

  Para ser trunk, o Gerald e o Pedro parecem concordar que teria que ter
  tudo isso exceto o canteiro central, e eu dispensaria a alta
  velocidade também. (Em meio urbano, no entanto, uma trunk seria de
  velocidade superior (80 km/h) à das avenidas principais (60 km/h) para
  corresponder à definição no wiki.)

 É o caso da SP-270 (Raposo Tavares): 2 faixas em cada sentido, sem
 canteiro de separação (ou seja, lanes=4)
 http://binged.it/19VHs60

 Isso pra mim é trunk (por mais que seja duplicada e de alta
 velocidade, eu não classifico com o mesmo porte de uma SP-310, SP-330,
 SP-348, etc)

  As secundárias poderiam ser as duplicadas sem acostamento. Isso
  indicaria que ainda comportam bastante tráfego mas não foram tão bem
  projetadas e podem oferecer alguns riscos. Nesse grupo entrariam
  algumas estradas de praticamente todos os níveis administrativos.

 Aqui fica estranho. Uma via de menor nível possui 2 faixas em um
 sentido enquanto que uma maior (primary) não?

  O que acham? Isso poderia virar uma tabela bem simples para um
  principiante seguir sem ter dúvidas.

 Eu acho bom dar exemplo em todas as definições, com imagens do Bing.

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

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

Re: [Talk-br] Hierarquia das rodovias

Posso estar enganado também, mas uma via de 4 faixas (2 em cada sentido) é
lanes=4.
Se a via com duas faixas fosse oneway, aí seria lanes=2
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Hierarquia das rodovias

Tem razão, eu escrevi rápido demais e pensei melhor depois. Inverteria a
definição de primária e secundária. Dessa forma fica inclusive mais de
acordo com a expectativa pros mesmos tipos de via em área urbana.
On May 20, 2013 1:22 PM, Nelson A. de Oliveira nao...@gmail.com wrote:

 2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
  Parece que todos concordam que uma motorway precisa ter 2 pistas,
  acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
  faltar alguma dessas coisas, o máximo que ela poderia ser é trunk.

 OK.

  Para ser trunk, o Gerald e o Pedro parecem concordar que teria que ter
  tudo isso exceto o canteiro central, e eu dispensaria a alta
  velocidade também. (Em meio urbano, no entanto, uma trunk seria de
  velocidade superior (80 km/h) à das avenidas principais (60 km/h) para
  corresponder à definição no wiki.)

 É o caso da SP-270 (Raposo Tavares): 2 faixas em cada sentido, sem
 canteiro de separação (ou seja, lanes=4)
 http://binged.it/19VHs60

 Isso pra mim é trunk (por mais que seja duplicada e de alta
 velocidade, eu não classifico com o mesmo porte de uma SP-310, SP-330,
 SP-348, etc)

  As secundárias poderiam ser as duplicadas sem acostamento. Isso
  indicaria que ainda comportam bastante tráfego mas não foram tão bem
  projetadas e podem oferecer alguns riscos. Nesse grupo entrariam
  algumas estradas de praticamente todos os níveis administrativos.

 Aqui fica estranho. Uma via de menor nível possui 2 faixas em um
 sentido enquanto que uma maior (primary) não?

  O que acham? Isso poderia virar uma tabela bem simples para um
  principiante seguir sem ter dúvidas.

 Eu acho bom dar exemplo em todas as definições, com imagens do Bing.

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

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

Re: [Talk-br] Hierarquia das rodovias

2013/5/20 Pedro Geaquinto pedrodi...@gmail.com:
 Não concordo em colocar na mesma medida acostamento com falta de
 cruzamentos! E falta de canteiros centrais em pequenos trechos não faz a via
 deixar de ser motorway como um semáforo faria: isso é uma convenção global
 no OSM.

Certo.
Trechos pequenos onde as vias mudam as suas características (número de
faixas, etc) devem ser desconsiderados e mantidos com a mesma
classificação geral da via. Isso deve valer pra todos os tipos de
vias.

 Excelente. A não ser quando liga dois municípios, aí é tertiary. Acho que
 vocês estão levando muito em consideração as caracterísiticas físicas! Para
 isso servem as tags lanes, shoulder, surface... A tag highway é
 primariamente para HIERARQUIA.

Isso, exato.
Todas as tags são importantes e devem ser utilizadas.
Só ainda não chegamos a um consenso de como classificar a hierarquia
das rodovias (pela importância, por classificação do governo, por
achismo, por características, etc).

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

Re: [Talk-br] Hierarquia das rodovias

Elas poderiam ser no máximo secundárias. Talvez seja mesmo melhor
tirar o texto até 80 km/h mesmo para ficar claro.

A idéia é que, apesar da velocidade alta, consideraríamos que a
estrutura da via não comportaria essa velocidade com a segurança
necessária/esperada - ou seja, que consideraríamos que a velocidade
máxima seria um erro de projeto da via.

On Mon, May 20, 2013 at 2:49 PM, Nelson A. de Oliveira nao...@gmail.com wrote:
 2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
 Que tal assim? 
 http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#M.C3.A9todo_objetivo_.282.C2.AA_proposta.29

 Essas velocidades até 80 Km/h que estão estranhas.
 As vias de 100 Km/h com 1 faixa por sentido, ficariam como?

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



-- 
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

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

Re: [Talk-br] Hierarquia das rodovias

Mas será que o tamanho da conurbação é um bom parâmetro?

Digamos que temos 2 vias idênticas - 1 pista, com acostamento, bem
sinalizadas. Uma das vias liga duas cidades de 1.000.000 de habitantes
sem conurbações no caminho. A outra liga outras duas cidades passando
por uma conurbação de 1.000 habitantes. As duas vias devem ter a mesma
classificação ou não? E se as duas tiverem tamanhos radicalmente
diferentes, a classificação mudaria?

2013/5/20 Vitor Sessak vitor1...@gmail.com:
 Ola Pedro,

 Eu achei bem legal seus esquemas, mas eu daria uma sugestao: trocar o termo
 acesso a pequenas conurbaçoes isoladas por acesso principal de zona
 urbana de mais de 1000 habitantes (e inverter o sim com o nao).

 A razao é que existem estradas de terra que nao sao acessos a nenhuma
 conurbaçao, so a fazendas isoladas. Levando seu esquema ao pé da letra, elas
 deveriam ser tertiary.

 Na minha opiniao, falta também a distinçao entre estradas de terra que
 servem principalmente como acesso a fazendas (mesmo se ela liga duas BRs ou
 duas cidades), com as que servem como acesso principal a uma regiao ou
 cidade...

 -Vitor

 2013/5/20 Pedro Geaquinto pedrodi...@gmail.com

 Oi pessoal.

 Como prometido, fiz os fluxogramas. Acho que ajudaria os iniciantes a se
 habituarem com nossas adaptações ao sistema inglês.
 Mesmo assim, vão haver muitos erros. Aqui no Rio percebo que os novatos
 não se importam muito com a hierarquia e muitas vias que devem ser
 tipicamente tertiary estão com a tag secondary. Só querem dizer que aquela
 rua é importante.
 Não é um problema muito grave, já que para quem está habituado é bem
 trivial entender o sistema e corrigir toda uma região de uma vez.

 Voltando aos fluxogramas, fiz 3 versões para o meio rural:

 - Um muito próximo do que está escrito na wiki, que é a interpretação
 livre do Gerald: http://i.imgur.com/2IAfQT7.gif
 - Um intermediário da minha sugestão. Só com alguns parâmetros a mais que
 adicionei, para padronizar por exemplo o uso de unclassified:
 http://i.imgur.com/rcY2LC6.gif
 - Minha sugestão. Com o conceito de importância que depende da
 interpretação da comunidade: http://i.imgur.com/MsqrZlp.gif

 Ah, e quanto a essa questão (meio off) de que se houvesse infraestrutura
 não haveria essa indagação: foi exatamente assim que eu comecei a me
 questionar. Essas vias que eu sugiro serem marcadas como trunk, por serem
 mais importantes que meras primary, deveriam ter sido duplicadas há tempos
 pelo tráfego pesado que recebem. Acaba que no Brasil temos corredores muito
 importantes com um formato totalmente desproporcional. É um atraso que temos
 no país, infelizmente.

 Um abraço!

 Pedro


 Em 19 de maio de 2013 01:26, Fernando Trebien fernando.treb...@gmail.com
 escreveu:

 Gerald, pensei mais um pouco sobre a questão, tentei refinar o texto
 que eu coloquei no wiki, e acho que concordo com você que motorways
 precisam ter acostamento e pelo menos 2 pistas, senão dirigir na
 velocidade máxima (e eventualmente ter que parar por causa de
 problemas com o veículo) seria de fato muito perigoso mesmo para um
 motorista habilidoso. Seria certamente um caso de velocidade
 incompatível com a via, um erro grosseiro do nosso governo, e a via
 não corresponderia aos requisitos mínimos de uma autoestrada pelos
 padrões internacionais. Para as trunk, que são de 80 km/h, acho
 possível que sejam de pista simples (como na sua segunda proposta), há
 muitas rodovias nacionais assim aqui no RS e elas são relativamente
 seguras. Eu fui tentar fundamentar melhor isso procurando nos artigos
 da Wikipédia sobre esses tipos de via pelas palavras acostamento e
 shoulder e só as encontrei no artigo referente a autoestradas.

 Estou relendo as suas propostas anteriores e pensando como posso
 conciliá-las com o que eu escrevi no wiki, aceito sugestões. Reli
 também algumas páginas no wiki, onde notei que o texto da sua proposta
 é bem parecido com o que está lá.

 2013/5/18 Fernando Trebien fernando.treb...@gmail.com:
  Concordo que é complicado para um iniciante (eu já fui um) e acho que
  o seu guia seria ideal para vias recém mapeadas, que ainda não constam
  no mapa. Desde o início eu senti falta de uma especificação mais clara
  do que cada coisa é.
 
  O meu problema é com as vias existentes. Há várias que não são primary
  e não têm uma tag note explicando o motivo da diferença. Como saber,
  então, se foram classificadas desta forma por um motivo
  suficientemente forte? Eu diria inclusive suficientemente
  coerente, compatível com as expectativas de um usuário do
  OpenStreetMap que, digamos, vem de outro país - por exemplo, turistas.
  Sei que a maioria deve estar com a classificação que resultou de algum
  processo de importação de dados em massa de alguma outra base de dados
  (cuja qualidade eu desconheço). Seria interessante que a importação
  estivesse descrita em algum lugar para sabermos quais os critérios que
  foram usados.
 
  Se você quiser, podemos, por exemplo, acrescentar à regra

Re: [Talk-br] Hierarquia das rodovias

2013-05-20 Thread Vitor Sessak

A minha idéia era usar o tamanho da conurbaçao so para diferenciar entre as
estradas de terra tertiary e unclassified. Para o resto é nao é um bom
critério.


2013/5/20 Fernando Trebien fernando.treb...@gmail.com

 Mas será que o tamanho da conurbação é um bom parâmetro?

 Digamos que temos 2 vias idênticas - 1 pista, com acostamento, bem
 sinalizadas. Uma das vias liga duas cidades de 1.000.000 de habitantes
 sem conurbações no caminho. A outra liga outras duas cidades passando
 por uma conurbação de 1.000 habitantes. As duas vias devem ter a mesma
 classificação ou não? E se as duas tiverem tamanhos radicalmente
 diferentes, a classificação mudaria?

 2013/5/20 Vitor Sessak vitor1...@gmail.com:
  Ola Pedro,
 
  Eu achei bem legal seus esquemas, mas eu daria uma sugestao: trocar o
 termo
  acesso a pequenas conurbaçoes isoladas por acesso principal de zona
  urbana de mais de 1000 habitantes (e inverter o sim com o nao).
 
  A razao é que existem estradas de terra que nao sao acessos a nenhuma
  conurbaçao, so a fazendas isoladas. Levando seu esquema ao pé da letra,
 elas
  deveriam ser tertiary.
 
  Na minha opiniao, falta também a distinçao entre estradas de terra que
  servem principalmente como acesso a fazendas (mesmo se ela liga duas BRs
 ou
  duas cidades), com as que servem como acesso principal a uma regiao ou
  cidade...
 
  -Vitor
 
  2013/5/20 Pedro Geaquinto pedrodi...@gmail.com
 
  Oi pessoal.
 
  Como prometido, fiz os fluxogramas. Acho que ajudaria os iniciantes a se
  habituarem com nossas adaptações ao sistema inglês.
  Mesmo assim, vão haver muitos erros. Aqui no Rio percebo que os novatos
  não se importam muito com a hierarquia e muitas vias que devem ser
  tipicamente tertiary estão com a tag secondary. Só querem dizer que
 aquela
  rua é importante.
  Não é um problema muito grave, já que para quem está habituado é bem
  trivial entender o sistema e corrigir toda uma região de uma vez.
 
  Voltando aos fluxogramas, fiz 3 versões para o meio rural:
 
  - Um muito próximo do que está escrito na wiki, que é a interpretação
  livre do Gerald: http://i.imgur.com/2IAfQT7.gif
  - Um intermediário da minha sugestão. Só com alguns parâmetros a mais
 que
  adicionei, para padronizar por exemplo o uso de unclassified:
  http://i.imgur.com/rcY2LC6.gif
  - Minha sugestão. Com o conceito de importância que depende da
  interpretação da comunidade: http://i.imgur.com/MsqrZlp.gif
 
  Ah, e quanto a essa questão (meio off) de que se houvesse infraestrutura
  não haveria essa indagação: foi exatamente assim que eu comecei a me
  questionar. Essas vias que eu sugiro serem marcadas como trunk, por
 serem
  mais importantes que meras primary, deveriam ter sido duplicadas há
 tempos
  pelo tráfego pesado que recebem. Acaba que no Brasil temos corredores
 muito
  importantes com um formato totalmente desproporcional. É um atraso que
 temos
  no país, infelizmente.
 
  Um abraço!
 
  Pedro
 
 
  Em 19 de maio de 2013 01:26, Fernando Trebien 
 fernando.treb...@gmail.com
  escreveu:
 
  Gerald, pensei mais um pouco sobre a questão, tentei refinar o texto
  que eu coloquei no wiki, e acho que concordo com você que motorways
  precisam ter acostamento e pelo menos 2 pistas, senão dirigir na
  velocidade máxima (e eventualmente ter que parar por causa de
  problemas com o veículo) seria de fato muito perigoso mesmo para um
  motorista habilidoso. Seria certamente um caso de velocidade
  incompatível com a via, um erro grosseiro do nosso governo, e a via
  não corresponderia aos requisitos mínimos de uma autoestrada pelos
  padrões internacionais. Para as trunk, que são de 80 km/h, acho
  possível que sejam de pista simples (como na sua segunda proposta), há
  muitas rodovias nacionais assim aqui no RS e elas são relativamente
  seguras. Eu fui tentar fundamentar melhor isso procurando nos artigos
  da Wikipédia sobre esses tipos de via pelas palavras acostamento e
  shoulder e só as encontrei no artigo referente a autoestradas.
 
  Estou relendo as suas propostas anteriores e pensando como posso
  conciliá-las com o que eu escrevi no wiki, aceito sugestões. Reli
  também algumas páginas no wiki, onde notei que o texto da sua proposta
  é bem parecido com o que está lá.
 
  2013/5/18 Fernando Trebien fernando.treb...@gmail.com:
   Concordo que é complicado para um iniciante (eu já fui um) e acho que
   o seu guia seria ideal para vias recém mapeadas, que ainda não
 constam
   no mapa. Desde o início eu senti falta de uma especificação mais
 clara
   do que cada coisa é.
  
   O meu problema é com as vias existentes. Há várias que não são
 primary
   e não têm uma tag note explicando o motivo da diferença. Como saber,
   então, se foram classificadas desta forma por um motivo
   suficientemente forte? Eu diria inclusive suficientemente
   coerente, compatível com as expectativas de um usuário do
   OpenStreetMap que, digamos, vem de outro país - por exemplo,
 turistas.
   Sei que a maioria deve estar com a

Re: [Talk-br] Hierarquia das rodovias

Acho que a sua definição de vicinal é bem próxima de ser uma via não
pavimentada onde apenas 1 veículo pode passar por vez. Eu entendo por
que você usaria track para vias em mau estado, mas daí não sei se o
melhor não seria usar a tag smoothness, proposta justamente pra isso
mas bem pouco usada (não sei de nenhum GPS que considere esse valor no
cálculo da rota).

Então na sua opinão a ocorrência de semáforos deveria ser uma
característica para diferenciar motorways de trunk, certo? Sem
problemas, desde que todos concordem, acrescentamos essa
característica como requisito para ser motorway além dos que já
foram contemplados.

O caso das pontes acho que seria uma exceção. Nesse caso, poderíamos
ignorar esse fator na classificação e, se ficarmos em dúvida entre 2
classes, escolhemos a mais próxima da classificação do restante da via
(antes e depois da ponte).

Eu assumo que as características sejam sempre predominantes e não
absolutas na via. Quer dizer, se houver um curto trecho em que uma
das características varia, isso não afeta a classificação de toda a
via - no máximo, afetaria a classificação daquele trecho, mas não
seria obrigatório. Agora se alguém decidir mudar o trecho baseado
nesses critérios, também não estaria errado.

Eu entendo e concordo que highway deve ser a hierarquia, mas o que
estamos tentando decidir é como estabelecer essa hierarquia. Eu e você
podemos discordar sobre o nível hierárquico (ou de importância) de uma
via. Eventualmente, discutiríamos e chegaríamos a um consenso. Alguns
meses depois, outra pessoa poderia vir e reabrir a discussão. E assim
ficaríamos discutindo eternamente, cada vez com uma pessoa diferente,
que tem um senso subjetivo de importância diferente, como ficou bem
claro pela quantidade de critérios diferentes propostos nessa
discussão até agora.

Você não concorda que a hierarquia tem efeitos colaterais sobre o
formato da via? Ou seja, que o formato diz alguma coisa (sem dizer
tudo, é claro) sobre a importância da via?

Quando você analisa o contexto local, você tem que ver que local
pode ser uma área muito pequena ou muito ampla, depende da pessoa que
está considerando. Por exemplo, se eu for calcular uma rota (com GPS
ou à olho) do Rio de Janeiro até Buenos Aires, o contexto local (a
relação hierárquica/de importância) das vias depende de comparações
numa área muito grande. Já se for fazer uma rota do Rio até Niterói a
relação hierárquica pode ser bem diferente porque as vias da região
são muito mais parecidas entre si.

2013/5/20 Pedro Geaquinto pedrodi...@gmail.com:
 A discussão está muito interessante! Desculpem pelo fluxograma estar meio
 mal explicado, podemos mudar juntos.
 Tentem fazer novas versões!

 Em 20 de maio de 2013 13:08, Fernando Trebien fernando.treb...@gmail.com
 escreveu:

 Eu concordo com tudo que o Pedro e o Gerald disseram (com o que o
 Vitor disse sobre as BR-4xx eu precisaria estudar mais) e achei os
 fluxogramas muito bons.

 Mas o problema que eu tentei abordar desde o começo é a ambiguidade
 nas interpretações do que é comparativamente mais importante (qual o
 raio de comparação?), do que é vicinal, do que é uma pequena
 conurbação, e até o do que é paralela (pois nenhuma via é
 absolutamente reta).


 Vicinal: eu imaginei vicinal todas aquelas pequenas estradinhas que passam
 entre os lotes de plantação (não sei o termo certo) e acessos a chácaras,
 sítios e sedes de fazenda. Eu também utilizo highway=track para ruas de
 terra em péssimas condições, mas posso mudar.

 Pequena conurbação: nesse caso fica meio fora do contexto apenas pequena
 conurbação, o termo que usei foi acesso a pequena conurbação isolada. A
 ênfase está em isolada, ou seja, um distrito ou concentração rural que não
 seja caminho para outro município.

 Paralela: imaginei uma cidade populosa com um caminho mais utilizado e um
 caminho alternativo.


 Foi muito bom marcar as coisas ambíguas em
 vermelho no fluxograma para guiar o debate, mas eu marcaria algumas
 coisas a mais.


 Eu marquei essas coisas a mais com preto! Leia a legenda no fluxograma que
 explica minha sugestão. Em preto são características que levam um pouco de
 reflexão, em cinza são características físicas (podem ganhar um predomina
 antes de cada pergunta) e em vermelho são características que devem ser
 discutidas por toda a comunidade.


 Acho melhor tentarmos nos concentrar nas características mensuráveis
 da via para minimizar as nossas divergências. Parece que estamos nos
 concentrando na classificação em área não-urbana, então vou considerar
 apenas isso a seguir.

 Parece que todos concordam que uma motorway precisa ter 2 pistas,
 acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
 faltar alguma dessas coisas, o máximo que ela poderia ser é trunk.


 Não concordo em colocar na mesma medida acostamento com falta de
 cruzamentos! E falta de canteiros centrais em pequenos trechos não faz a via
 deixar de ser motorway como um semáforo faria: isso é uma convenção global
 no

Re: [Talk-br] Hierarquia das rodovias

O modo como é feita a hierarquia das rodovias pelo ministério dos
transportes 
(http://www2.transportes.gov.br/bit/01-inicial/07-download/rodo2012.pdf)
parece ser:

Vias pavimentadas duplicadas  pavimentadas  sem pavimentação

Que é basicamente onde estamos chegando (e fica uma hierarquia
razoavelmente boa).
Exemplo: 
http://www2.transportes.gov.br/bit/01-inicial/01-estadual/estados/port/sp.htm

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

Re: [Talk-br] Hierarquia das rodovias

2013/5/20 Pedro Geaquinto pedrodi...@gmail.com:
 4- Utilizem o bom senso para adicionar vias de maior hierarquia que as
 próprias vias de acesso à cidade. Se a cidade não tem uma grande
 infraestrutura rodoviária (como rodoanéis ou arcos e uma rede de vias
 rápidas), não tem porque utilizar uma hierarquia maior. Vejam por exemplo:
 Votuporanga [3] e Fernandópolis [4] no interior de SP. Não é exatamente um
 erro, mas faz pouco sentido chamar de trunk todas as vias da cidade.

Eu já conversei com algumas pessoas que mapeiam as vias principais da
cidade como trunk (como os exemplos que você citou) e basicamente
dizem que é o certo, porque está na wiki
(http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Categoriza.C3.A7.C3.A3o_de_vias).
(eu não tenho paciência pra discutir o que é certo ou não é)

Só minha opinião, mas cidade deveria ser mapeada de baixo para cima:
ruas da cidade como residential, ruas mais importante em tertiary,
caso necessário, vias maiores e principais como secondary e assim por
diante. É uma hierarquia, afinal. Caso não haja necessidade em se
utilizar uma classificação maior (primary ou trunk), então deixa sem
(e não começar mapeando já utilizando de cara uma via com
classificação maior, como trunk).
Podem dizer que é um critério muito subjetivo, mas eu ainda acredito
que para áreas urbanas é o que encaixa melhor. Funciona muito bem em
cidades menores, por exemplo (onde claramente existem as ruas
principais (tertiary) e as avenidas duplicadas (secondary)).

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

Re: [Talk-br] Hierarquia das rodovias

Justamente: eu tenho paciência para decidir a regra geral. Para tratar
de cada caso eu prefiro ter um guia bastante claro pra não ter que
ficar batendo boca com quem tem a boa intenção de colaborar. Se
tivesse que fazer assim, eu simplesmente desistiria de colaborar -
primeiro porque haveria várias pessoas opininando de formas
contraditórias sobre as minhas edições, e depois porque eu teria que
fazer a mesma coisa com várias outras pessoas.

Eu concordo que classificar de baixo pra cima faz sentido pelo menos
para os níveis mais baixos da classificação (que no Brasil são
relativamente livres). Já os niveis mais altos (a partir de primary)
eu acho que outras características têm mais impacto. Isso porque a
classificação afeta a renderização do mapa (vias de classificação
menor não aparecem nos níveis de ampliação mais altos) e também o
roteamento (roteadores diferentes tendem a certas velocidades por tipo
de via, e existe até um artigo no wiki estabelecendo qual velocidade
presumir por via).

Se dissociarmos completamente desses efeitos, então teremos que:
- adicionar a tag maxspeed a todas as vias (muito mais trabalho para
que o roteamento funcione coerentemente) e decidir como preencher esse
valor quando não houver sinalização relativa à velocidade
- assumir que a forma com que a via é desenhada pouco indica as suas
características gerais (acho que reduziria drasticamente o valor
utilidade do mapa para o usuário final)
- assumir que algumas vias importantes (subjetivo) não serão
exibidas em certos níveis de ampliação, e outras menos importantes
serão (seria o caso de uma rodovia que, em certo trecho, talvez até
longo, só cruza vias residenciais - classificando de baixo para cima,
à risca, o trecho seria uma terciária)

Enfim, acho que devemos nos orientar pela utilidade dos critérios sugeridos.

Eu penso que para um motorista médio o útil é usar estradas mais
rápidas (contemplado na maioria dos GPSs) e mais seguras
(geralmente negligenciado por mapas e por GPSs). Pavimentação, número
de pistas e acostamento afetam a segurança. Pavimentação, número de
pistas e frequência das obstruções (semáforos e cruzamentos sem
preferência) afetam a velocidade. Estar pavimentado, nesse caso, quer
dizer sem muitos buracos (e isso abriria outro ramo da discussão...).
Ser rápido significaria ter pouco trânsito (abrindo ainda outro ramo).
Talvez esses dois fatores não sejam mensuráveis e não devessem ser
considerados a menos que tivéssemos fontes confiáveis.

Não importa muito se a via liga duas cidades grandes ou se liga uma
via maior a uma conurbação pequena, o caminho simplesmente é bom se
essas características forem favoráveis para os principais objetivos
(velocidade e segurança).

Eu acho que uma via que termine numa cidade pequena poderia ter
classificação mais livre desde que fosse o único caminho até ela. Mas
se alguém um dia contruir uma continuação até outra via, a
classificação poderia mudar. Se nos basearmos mais em características
mensuráveis, a tendência seria de não mudar.

2013/5/20 Nelson A. de Oliveira nao...@gmail.com:
 2013/5/20 Pedro Geaquinto pedrodi...@gmail.com:
 4- Utilizem o bom senso para adicionar vias de maior hierarquia que as
 próprias vias de acesso à cidade. Se a cidade não tem uma grande
 infraestrutura rodoviária (como rodoanéis ou arcos e uma rede de vias
 rápidas), não tem porque utilizar uma hierarquia maior. Vejam por exemplo:
 Votuporanga [3] e Fernandópolis [4] no interior de SP. Não é exatamente um
 erro, mas faz pouco sentido chamar de trunk todas as vias da cidade.

 Eu já conversei com algumas pessoas que mapeiam as vias principais da
 cidade como trunk (como os exemplos que você citou) e basicamente
 dizem que é o certo, porque está na wiki
 (http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Categoriza.C3.A7.C3.A3o_de_vias).
 (eu não tenho paciência pra discutir o que é certo ou não é)

 Só minha opinião, mas cidade deveria ser mapeada de baixo para cima:
 ruas da cidade como residential, ruas mais importante em tertiary,
 caso necessário, vias maiores e principais como secondary e assim por
 diante. É uma hierarquia, afinal. Caso não haja necessidade em se
 utilizar uma classificação maior (primary ou trunk), então deixa sem
 (e não começar mapeando já utilizando de cara uma via com
 classificação maior, como trunk).
 Podem dizer que é um critério muito subjetivo, mas eu ainda acredito
 que para áreas urbanas é o que encaixa melhor. Funciona muito bem em
 cidades menores, por exemplo (onde claramente existem as ruas
 principais (tertiary) e as avenidas duplicadas (secondary)).

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



--
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

___
Talk-br mailing list

Re: [Talk-br] Hierarquia das rodovias

Que interessante! A classificação do Ministério dos Transportes (que
não usa termos abstratos) devia ser considerada extremamente relevante
na nossa forma de classificar, afinal, eles são os especialistas no
assunto. Se essa é a informação publicada por eles, é porque
provavelmente é a mais requisitada - ou seja, a mais útil para os
usuários dessas vias.

Encontrei o link principal dentro do site que leva aos links que você
postou, para que as pessoas possam ver os mapas de seus estados
independentemente.

Se usarmos essa fonte de informação e atribuirmos uma correspondência
com as vias do OpenStreetMap baseada nessas características, quase não
restarão ambiguidades. Acho que todos sairiam ganhando assim, tanto
quem faz o mapa (nós) quanto quem o consome (nós e mais um monte de
gente).

2013/5/20 Nelson A. de Oliveira nao...@gmail.com:
 O modo como é feita a hierarquia das rodovias pelo ministério dos
 transportes 
 (http://www2.transportes.gov.br/bit/01-inicial/07-download/rodo2012.pdf)
 parece ser:

 Vias pavimentadas duplicadas  pavimentadas  sem pavimentação

 Que é basicamente onde estamos chegando (e fica uma hierarquia
 razoavelmente boa).
 Exemplo: 
 http://www2.transportes.gov.br/bit/01-inicial/01-estadual/estados/port/sp.htm

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



--
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

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

Re: [Talk-br] Hierarquia das rodovias

Pedro, concordo que os quadrados vermelhos podem continuar sendo
discutidos. Eu disse que gostaria que alguns dos pretos também fossem
discutidos porque acho alguns deles ambíguos. O meu objetivo sim é
(super)simplificar para que os colaboradores não tenham que ter
doutorado em engenharia de tráfego para tomarem essas decisões. O
mesmo para os usuários finais, leigos, para quem as cores das vias
devem representar algo útil e fácil de explicar.

Vou levantar algumas questões pra você citando pedaços do que você escreveu.

... preferencialmente com acostamento : preferencialmente significa
no mínimo 50% do percurso? 80%? 95%? 99%?

tertiary .. para acesso de conurbações pequenas isoladas ... quando
não pavimentada liga municípios e depois unclassified ... não
pavimentada para acesso de conurbações pequenas isoladas : então duas
coisas aparentemente similares à primeira vista (vias não pavimentadas
e provavelmente de pouco movimento) teriam representações notavelmente
diferentes. Como explicar isso para um leigo de forma que lhe seja
imediatamente útil? Toda vez que o leigo quiser pensar numa rota por
lugares pavimentados ele vai ter que verificar se a via pela qual ele
pensa em passar se conecta a outra ou se termina num lugar isolado. Se
ele tiver que mudar a camada do mapa para ter essa informação, para
que lhe serve a classificação das vias? Serve apenas para planejadores
rodoviários e engenheiros de tráfego defenderem seus pontos de vista
teóricos sobre importância relativa?

Se for pra supersimplificar esse assunto, causando menos dúvidas,
prefiro até que utilizamos todas as BRs pavimentadas como no mínimo
trunk e todas as BRs não pavimentadas como secondary. Esse conceito é
utilizado para as RNs da Argentina e rodovias nacionais na Austrália,
e creio que seja copiado no Uruguai (esse último a hierarquia não tem
normas formais na wiki). 

O fato de eles supersimplificarem me sugere que provavelmente já
discutiram essas questões e acharam melhor se focar em aspectos
concretos, mensuráveis e óbvios, sem ambiguidades. Eles certamente têm
algo que nós não temos: infraestrutura de qualidade. Eu gostaria muito
(muito mesmo) que pudéssemos chegar a definições totalmente
compatíveis com as deles, mas receio que eles não estejam seguindo
exatamente os mesmos princípios uns dos outros, então penso que temos
que tentar aproximar as nossas definições com ligeiras adaptações
próprias que sejam úteis no nosso contexto (ou seja, buscar o meio
termo ideal entre a integração total e a utilidade para nós). Talvez
as nossas adaptações um dia inspirem eles a mudar ligeiramente a sua
forma de classificar. Mas imagino que pelo menos as decisões maiores
já foram tomadas por quem já está envolvido há mais tempo.

Pessoalmente, acho um desperdício usar apenas 3 de 7 classificações
possíveis. Podemos definir 3 classes principais e as variações sob os
aspectos que consideramos mais importantes. Isso resultaria num mapa
mais rico, mais orgânico, e enfim, mais útil. Acho que já estamos bem
a caminho disso, eu, você e os demais.

Sempre apliquem o predominantemente : concordo plenamente. Mas seria
bom definir melhor o que é (ou quanto é, aproximadamente) o
predominantemente.

Utilizem o bom senso : eu acho melhor dizer utilizem o consenso
porque o bom senso tem me parecido totalmente subjetivo e diferente de
um pra outro. :P

2013/5/20 Pedro Geaquinto pedrodi...@gmail.com:
 Concordo com você Fernando. Só acho que o termo importância (parâmetros
 vermelhos) pode continuar sendo discutido. Estamos caminhando para um
 consenso intermediário [1], inclusive criando convenções para tags como
 unclassified e track.

 Tirando da discussão podemos dizer que:

 motorway: via pavimentada; obrigatoriamente 2 faixas por sentido;
 obrigatoriamente sem cruzamentos, semáforos ou lombadas; predominantemente
 com canteiro central; preferencialmente com acostamento; acessos e saídas
 especiais.
 tertiary: via pavimentada para acesso de conurbações pequenas isoladas, ou
 seja, que não sejam caminho para uma cidade; quando não pavimentada liga
 municípios.
 unclassified: via não pavimentada para acesso de conurbações pequenas
 isoladas.
 track: via não pavimentada onde só um veículo pode passar por vez.
 geralmente são as vias vicinais, aquelas que ficam entre os campos de
 plantação, ou dão acesso a uma sede de fazenda.

 Agora espero uma maior discussão para trunk, primary e secondary. Se for pra
 supersimplificar esse assunto, causando menos dúvidas, prefiro até que
 utilizamos todas as BRs pavimentadas como no mínimo trunk e todas as BRs não
 pavimentadas como secondary. Esse conceito é utilizado para as RNs da
 Argentina e rodovias nacionais na Austrália, e creio que seja copiado no
 Uruguai (esse último a hierarquia não tem normas formais na wiki).
 Claro que nas demais vias manteríamos os conceitos gerais de trunk, primary
 e secondary. O que acham?

 E entrando pela primeira vez no meio urbano aqui, acho MUITO bom o conceito
 de hierarquia que

Re: [Talk-br] Hierarquia das rodovias

Para comparação, tentei estabelecer uma associação entre o que eu já
tinha colocado no wiki (que é parecido com o que o Pedro expressou nos
seus fluxogramas) e a descrição que o DNIT dá para a terminologia
usada no BIT:
http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#M.C3.A9todo_objetivo_.282.C2.AA_proposta.29

Fiquei na dúvida em relação à aplicação do termo leito natural.
Encontrei um TCC
(http://www.projetos.unijui.edu.br/petegc/wp-content/uploads/2010/03/TCC-Juliano-Reis-Wallau.pdf)
onde diz que a diferença entre leito natural e implantada seria a
estabilidade do solo da via, que teria relação com a compactação do
solo. Isso certamente teria impacto sobre a probabilidade de atolar
num dia de chuva. Acho difícil de medir isso por imagens de satélite,
mas por fotos a partir do chão deve ser relativamente fácil decidir
(no entanto, a opinião de um morador ou frequentador do local deveria
prevalecer). No entanto, é um pouco diferente do critério de track
com o qual havíamos concordado (via de terra e estreita).

Outras opções (algumas já propostas) para tentar uma aproximação com a
classificação do BIT seriam:

- primary = 2 faixas sem acostamento OU 1 faixa com acostamento;
secondary = 1 faixa sem acostamento; tertiary = não-pavimentada com
terra bem compactada; unclassified = não-pavimentada larga com terra
insuficientemente compactada (potencial para atolamento); track =
não-pavimentada estreita

- trunk = 2 faixas; primary = 1 faixa com acostamento; secondary = 1
faixa sem acostamento (possivelmente menos segura); tertiary =
não-pavimentada com terra bem compactada; etc.

Que tal?

2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
Que interessante! A classificação do Ministério dos Transportes (que
não usa termos abstratos) devia ser considerada extremamente relevante
na nossa forma de classificar, afinal, eles são os especialistas no
assunto. Se essa é a informação publicada por eles, é porque
provavelmente é a mais requisitada - ou seja, a mais útil para os
usuários dessas vias.

Encontrei o link principal dentro do site que leva aos links que você
postou, para que as pessoas possam ver os mapas de seus estados
independentemente.

Se usarmos essa fonte de informação e atribuirmos uma correspondência
com as vias do OpenStreetMap baseada nessas características, quase não
restarão ambiguidades. Acho que todos sairiam ganhando assim, tanto
quem faz o mapa (nós) quanto quem o consome (nós e mais um monte de
gente).

2013/5/20 Nelson A. de Oliveira nao...@gmail.com:
O modo como é feita a hierarquia das rodovias pelo ministério dos
transportes
(http://www2.transportes.gov.br/bit/01-inicial/07-download/rodo2012.pdf)
parece ser:

Vias pavimentadas duplicadas pavimentadas sem pavimentação

Que é basicamente onde estamos chegando (e fica uma hierarquia
razoavelmente boa).
Exemplo:
http://www2.transportes.gov.br/bit/01-inicial/01-estadual/estados/port/sp.htm

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

--
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

--
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

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

Re: [Talk-br] Hierarquia das rodovias

2013-05-20 Thread Vítor Rodrigo Dias

Fiquei na dúvida em relação à aplicação do termo leito
natural. Encontrei um TCC (
http://www.projetos.unijui.edu.br/petegc/wp-content/uploads/2010/03/TCC-Juliano-Reis-Wallau.pdf)
onde
diz que a diferença entre leito natural e implantada seria
a estabilidade do solo da via, que teria relação com a compactação do solo.
Isso certamente teria impacto sobre a probabilidade de atolar num dia de
chuva. Acho difícil de medir isso por imagens de satélite, mas por fotos a
partir do chão deve ser relativamente fácil decidir (no entanto, a opinião
de um morador ou frequentador do local deveria prevalecer). No entanto, é
um pouco diferente do critério de track com o qual havíamos concordado
(via de terra e estreita).

Fernando, pelo menos o DER-MG, na sua listagem de rodovias, especifica
quais rodovias não-pavimentadas estão em leito natural e quais estão
implantadas.

Abraços!

Vítor Rodrigo Dias
Revisor de textos
Tradutor port/ing/port e port/esp/port
Telefone: (31) 9895-3975 - TIM


Em 20 de maio de 2013 22:56, Fernando Trebien
fernando.treb...@gmail.comescreveu:

 Para comparação, tentei estabelecer uma associação entre o que eu já
 tinha colocado no wiki (que é parecido com o que o Pedro expressou nos
 seus fluxogramas) e a descrição que o DNIT dá para a terminologia
 usada no BIT:
 http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#M.C3.A9todo_objetivo_.282.C2.AA_proposta.29

 Fiquei na dúvida em relação à aplicação do termo leito natural.
 Encontrei um TCC
 (
 http://www.projetos.unijui.edu.br/petegc/wp-content/uploads/2010/03/TCC-Juliano-Reis-Wallau.pdf
 )
 onde diz que a diferença entre leito natural e implantada seria a
 estabilidade do solo da via, que teria relação com a compactação do
 solo. Isso certamente teria impacto sobre a probabilidade de atolar
 num dia de chuva. Acho difícil de medir isso por imagens de satélite,
 mas por fotos a partir do chão deve ser relativamente fácil decidir
 (no entanto, a opinião de um morador ou frequentador do local deveria
 prevalecer). No entanto, é um pouco diferente do critério de track
 com o qual havíamos concordado (via de terra e estreita).

 Outras opções (algumas já propostas) para tentar uma aproximação com a
 classificação do BIT seriam:

 - primary = 2 faixas sem acostamento OU 1 faixa com acostamento;
 secondary = 1 faixa sem acostamento; tertiary = não-pavimentada com
 terra bem compactada; unclassified = não-pavimentada larga com terra
 insuficientemente compactada (potencial para atolamento); track =
 não-pavimentada estreita

 - trunk = 2 faixas; primary = 1 faixa com acostamento; secondary = 1
 faixa sem acostamento (possivelmente menos segura); tertiary =
 não-pavimentada com terra bem compactada; etc.

 Que tal?

 2013/5/20 Fernando Trebien fernando.treb...@gmail.com:
  Que interessante! A classificação do Ministério dos Transportes (que
  não usa termos abstratos) devia ser considerada extremamente relevante
  na nossa forma de classificar, afinal, eles são os especialistas no
  assunto. Se essa é a informação publicada por eles, é porque
  provavelmente é a mais requisitada - ou seja, a mais útil para os
  usuários dessas vias.
 
  Encontrei o link principal dentro do site que leva aos links que você
  postou, para que as pessoas possam ver os mapas de seus estados
  independentemente.
 
  Se usarmos essa fonte de informação e atribuirmos uma correspondência
  com as vias do OpenStreetMap baseada nessas características, quase não
  restarão ambiguidades. Acho que todos sairiam ganhando assim, tanto
  quem faz o mapa (nós) quanto quem o consome (nós e mais um monte de
  gente).
 
  2013/5/20 Nelson A. de Oliveira nao...@gmail.com:
  O modo como é feita a hierarquia das rodovias pelo ministério dos
  transportes (
 http://www2.transportes.gov.br/bit/01-inicial/07-download/rodo2012.pdf)
  parece ser:
 
  Vias pavimentadas duplicadas  pavimentadas  sem pavimentação
 
  Que é basicamente onde estamos chegando (e fica uma hierarquia
  razoavelmente boa).
  Exemplo:
 http://www2.transportes.gov.br/bit/01-inicial/01-estadual/estados/port/sp.htm
 
  ___
  Talk-br mailing list
  Talk-br@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-br
 
 
 
  --
  Fernando Trebien
  +55 (51) 9962-5409
 
  The speed of computer chips doubles every 18 months. (Moore's law)
  The speed of software halves every 18 months. (Gates' law)



 --
 Fernando Trebien
 +55 (51) 9962-5409

 The speed of computer chips doubles every 18 months. (Moore's law)
 The speed of software halves every 18 months. (Gates' law)

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

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

Re: [Talk-de] Ist der ID Editor reif für osm.org?

2013-05-20 Thread Manuel Reimer


On 05/17/2013 08:25 PM, Frederik Ramm wrote:

JavaScript ist ausserdem wesentlich verbreiteter als Flash/ActionScript,
und iD setzt, soweit ich weiss, durchweg verbreitete
Standardbibliotheken ein - das sind also eigentlich wesentliche bessere
Voraussetzungen fuer die Beteiligung neuer Programmierer, als sie bei
Potlatch gegeben waren.


Sehe ich genauso. Flash hat definitiv keine Zukunft. Selbst Adobe 
behandelt Flash nur noch halbherzig. Der Zug ist einfach abgefahren. 
Spätestens seit der vielen Mobilplattformen mit beschränkten Ressourcen 
will keiner mehr irgendwelche Browser-Plugins haben.


Ein HTML5-Editor war überfällig, denn die Zeit, in der man mehr oder 
weniger als gegeben annehmen kann, dass jemand das Flash-Plugin 
installiert hat, ist vorbei.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Neuer OSM Flyer

2013-05-20 Thread Tobias Hobmeier

Hi hi,

wir wollten uns einen eingenen Flyer basteln und suchen quasi als
Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode
äquivalent :-D
hat jemand einen link für mich?

Gruß Tobi

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neuer OSM Flyer

2013-05-20 Thread gmbo


Am 20.05.2013 17:56, schrieb Tobias Hobmeier:

Hi hi,

wir wollten uns einen eingenen Flyer basteln und suchen quasi als
Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode
äquivalent :-D
hat jemand einen link für mich?

Gruß Tobi

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


schau mal hier

http://gis.19327.n5.nabble.com/ODBL-Flyer-td5733001.html

LG Gisbert

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neuer OSM Flyer

2013-05-20 Thread Stefan Keller

http://wiki.openstreetmap.org/wiki/Flyers_and_posters#Flyers

LG, Stefan

-- 

...
FOSSGIS 2013 - Die Konferenz für Open Source GIS mit OpenData
und OpenStreetMap erstmals in der Schweiz! 12.-14. Juni, HSR, Rapperswil
http://www.fossgis.de/konferenz/2013/



Am 20. Mai 2013 17:56 schrieb Tobias Hobmeier tob...@antifuse.de:
 Hi hi,

 wir wollten uns einen eingenen Flyer basteln und suchen quasi als
 Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode
 äquivalent :-D
 hat jemand einen link für mich?

 Gruß Tobi

 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Nicht mehr existente Gleise, Bahnhöfe, Haltestellen

2013-05-20 Thread Thorsten Alge

Hi,

sorry für die späte Antwort aber ich war im Ausland und hatte leider
keine Zeit die Liste zu lesen. Ich habe mir die Antworten durchgelesen
und vieles hilfreiches entdeckt. Ich werde mal mit dem betreffenden User
Kontakt aufnehmen.

Gruß

Thorsten

On 2013-05-14 19:01, Martin Koppenhoefer wrote:
 Am 14. Mai 2013 17:18 schrieb Tobias Knerr o...@tobias-knerr.de:
 
 Ersteres ist allerdings konsistent mit der dokumentierten Empfehlung
 zur Verwendung eines Präfix im Falle von disused:
 http://wiki.openstreetmap.org/wiki/Key:disused


 
 ja, bei disused funktioniert das aber auch besser, weil das nicht als key
 in Gebrauch ist.
 
 Gruß Martin
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de
 

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neuer OSM Flyer

2013-05-20 Thread bkmap


Am 20.05.2013 17:56, schrieb Tobias Hobmeier:

Hi hi,

wir wollten uns einen eingenen Flyer basteln und suchen quasi als
Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode
äquivalent :-D
hat jemand einen link für mich?


http://svn.openstreetmap.org/misc/pr_material/german_flyer_2013_01/

Guß Burkhard





___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-in] admin boundaries

2013-05-20 Thread Mikel Maron

Hi

I'm looking for Indian state admin boundaries, both current, and from previous 
reorganizations.

Does anyone here know of how the admin boundaries in OSM were imported? From 
what source?

Searching, I've also found this conveniently, derived from Natural Earth. Do 
these more or less look correct for present boundaries?
http://geocommons.com/overlays/73828

 
Thanks
Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron___
Talk-in mailing list
Talk-in@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] 2024

2013-05-20 Thread pjhooker

Complimenti Maurizio!



--
View this message in context: 
http://gis.19327.n5.nabble.com/2024-tp5761682p5761841.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

Il 19/05/2013 21:25, Alessandro ha scritto:
 Come scrive Martin, non ti scoraggiare e inizia a mappare. Solitamente
 s'innescano processi inversi a quello detto 'della finestra rotta':
 finchè non si inizia ad apparire qualcosa di significativo nessuno,
 seppur ti sostenga coi 'mi piace', si unisce ai mappatori.
 Magari parti da una zona relativamente più semplice e circoscritta:
 mappa con più dettagli che puoi una piccola parte per portarla come
 esempio. Parti dalle direttrici principali dove il GPS aggancia il
 segnale, poi potresti usare il servizio di fieldpapers.org per entrare
 nel dettaglio dei vicoli.

 Alessandro a.k.a. Ale_zena_IT
Tranquilli non mi sono scoraggiato. Solamente che avendo mappato
totalmente da solo Salcito, mi rode abbastanza che la mappa sia
totalmente inutilizzabile per mancanza dei nomi delle vie. Pertanto dal
mio precedente post trapelava un po' di bollore :-)

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

Il 20/05/2013 11:47, Edoardo Yossef Marascalchi ha scritto:
 Perché non organizzare li un mapping party, magari contattanto l'APT
 del luogo per avere supporto logistico? sicuramente qualche mappatore
 delle zone limitrofe, se organizzi anche una cenetta, si fa vedere... 
Cosa è un APT?

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

2013-05-20 Thread Edoardo Yossef Marascalchi

Azienda di Promozione Turistica



Il giorno 20 maggio 2013 13:03, Caterpillar caterpilla...@gmail.com ha
scritto:

 Il 20/05/2013 11:47, Edoardo Yossef Marascalchi ha scritto:
  Perché non organizzare li un mapping party, magari contattanto l'APT
  del luogo per avere supporto logistico? sicuramente qualche mappatore
  delle zone limitrofe, se organizzi anche una cenetta, si fa vedere...
 Cosa è un APT?

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it




-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

Il 20/05/2013 12:05, Edoardo Yossef Marascalchi ha scritto:
 Azienda di Promozione Turistica
Ah le ProLoco. Riproverò, visto che neanche mi risposero

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Enel in OSM

2013-05-20 Thread Fabri

Anche il punto Enel a Roma, viale regina margherita, è un po in mezzo
alla strada e probabilmente una ventina di metri traslato dall'edificio.
in caso controllo e lo sposto o faccio la segnalazione?


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

2013/5/20 Caterpillar caterpilla...@gmail.com

 Solamente che avendo mappato
 totalmente da solo Salcito, mi rode abbastanza che la mappa sia
 totalmente inutilizzabile per mancanza dei nomi delle vie.



Se sei di zona ci puoi fare un rilievo, mi sembra fattibile di prendere i
nomi delle vie, sensi unici, superfici delle strade, limiti di velocità,
divieti di svolta, scale, principali POI come panificio, macellaio, ecc. in
una mezza giornata (o forse anche meno).

Se ti posso suggerire una cosa: quando le strade sono molto strette ai
centri storici metterei highway=service e service=alley invece di
residential.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Enel in OSM

2013/5/20 Fabri erfab...@gmail.com

 Anche il punto Enel a Roma, viale regina margherita, è un po in mezzo
 alla strada e probabilmente una ventina di metri traslato dall'edificio.
 in caso controllo e lo sposto o faccio la segnalazione?



sposta lo ;-) Poi se vuoi, segnala anche all'Enel, ma loro potrebbero
comunque anche senza segnalazione vedere da OSM che qualcuno ha spostato il
nodo (e quindi poi indagare).

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Enel in OSM

2013-05-20 Thread David Riccitelli

Grazie Fabri,

Puoi segnalarci la modifica anche su
http://enelopendata.insideout.io/#/feedback/PuntoEnel_Lazio_9 ? In questo
modo possiamo aggiornare il dato anche nell'elenco dei Punto Enel ed
evitare di sovrascrivere la tua modifica (stiamo comunque verificando un
modo di acquisire automaticamente le modifiche applicate direttamente su
OSM).

Grazie,
David


2013/5/20 Martin Koppenhoefer dieterdre...@gmail.com




 2013/5/20 Fabri erfab...@gmail.com

 Anche il punto Enel a Roma, viale regina margherita, è un po in mezzo
 alla strada e probabilmente una ventina di metri traslato dall'edificio.
 in caso controllo e lo sposto o faccio la segnalazione?



 sposta lo ;-) Poi se vuoi, segnala anche all'Enel, ma loro potrebbero
 comunque anche senza segnalazione vedere da OSM che qualcuno ha spostato il
 nodo (e quindi poi indagare).

 ciao,
 Martin

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it




-- 
David Riccitelli

-- check the Swagger for WordLift http://bit.ly/VtoM5H

InsideOut10 s.r.l.
P.IVA: IT-11381771002
Fax: +39 0110708239
---
LinkedIn: http://it.linkedin.com/in/riccitelli
Twitter: ziodave
---
Layar Partner 
Networkhttp://www.layar.com/publishing/developers/list/?page=1country=city=keyword=insideout10lpn=1

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Enel in OSM

2013-05-20 Thread Maurizio Napolitano

Solo come promemoria: i dati che riprenderete indietro cambieranno licenzs
in ODbL
Il giorno 20/mag/2013 12:58, David Riccitelli da...@insideout.io ha
scritto:

 Grazie Fabri,

 Puoi segnalarci la modifica anche su
 http://enelopendata.insideout.io/#/feedback/PuntoEnel_Lazio_9 ? In questo
 modo possiamo aggiornare il dato anche nell'elenco dei Punto Enel ed
 evitare di sovrascrivere la tua modifica (stiamo comunque verificando un
 modo di acquisire automaticamente le modifiche applicate direttamente su
 OSM).

 Grazie,
 David


 2013/5/20 Martin Koppenhoefer dieterdre...@gmail.com




 2013/5/20 Fabri erfab...@gmail.com

 Anche il punto Enel a Roma, viale regina margherita, è un po in mezzo
 alla strada e probabilmente una ventina di metri traslato dall'edificio.
 in caso controllo e lo sposto o faccio la segnalazione?



 sposta lo ;-) Poi se vuoi, segnala anche all'Enel, ma loro potrebbero
 comunque anche senza segnalazione vedere da OSM che qualcuno ha spostato il
 nodo (e quindi poi indagare).

 ciao,
 Martin

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it




 --
 David Riccitelli

 -- check the Swagger for WordLift http://bit.ly/VtoM5H

 
 InsideOut10 s.r.l.
 P.IVA: IT-11381771002
 Fax: +39 0110708239
 ---
 LinkedIn: http://it.linkedin.com/in/riccitelli
 Twitter: ziodave
 ---
 Layar Partner 
 Networkhttp://www.layar.com/publishing/developers/list/?page=1country=city=keyword=insideout10lpn=1

 

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Enel in OSM

2013-05-20 Thread David Riccitelli

Ciao Napo,

Ok grazie, stiamo verificando le specifiche all'indirizzo
http://opendatacommons.org/licenses/odbl/ e provvederemo ad aggiungere un
collegamento dal sito
http://enelopendata.insideout.io/#/PuntoEnel_Lazio_9alla licenza
http://opendatacommons.org/licenses/odbl/.

Ciao,
David




2013/5/20 Maurizio Napolitano napoo...@gmail.com

 Solo come promemoria: i dati che riprenderete indietro cambieranno licenzs
 in ODbL
 Il giorno 20/mag/2013 12:58, David Riccitelli da...@insideout.io ha
 scritto:

 Grazie Fabri,

 Puoi segnalarci la modifica anche su
 http://enelopendata.insideout.io/#/feedback/PuntoEnel_Lazio_9 ? In
 questo modo possiamo aggiornare il dato anche nell'elenco dei Punto Enel ed
 evitare di sovrascrivere la tua modifica (stiamo comunque verificando un
 modo di acquisire automaticamente le modifiche applicate direttamente su
 OSM).

 Grazie,
 David


 2013/5/20 Martin Koppenhoefer dieterdre...@gmail.com




 2013/5/20 Fabri erfab...@gmail.com

 Anche il punto Enel a Roma, viale regina margherita, è un po in mezzo
 alla strada e probabilmente una ventina di metri traslato dall'edificio.
 in caso controllo e lo sposto o faccio la segnalazione?



 sposta lo ;-) Poi se vuoi, segnala anche all'Enel, ma loro potrebbero
 comunque anche senza segnalazione vedere da OSM che qualcuno ha spostato il
 nodo (e quindi poi indagare).

 ciao,
 Martin

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it




 --
 David Riccitelli

 -- check the Swagger for WordLift http://bit.ly/VtoM5H

 
 InsideOut10 s.r.l.
 P.IVA: IT-11381771002
 Fax: +39 0110708239
 ---
 LinkedIn: http://it.linkedin.com/in/riccitelli
 Twitter: ziodave
 ---
 Layar Partner 
 Networkhttp://www.layar.com/publishing/developers/list/?page=1country=city=keyword=insideout10lpn=1

 

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it


 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it




-- 
David Riccitelli

-- check the Swagger for WordLift http://bit.ly/VtoM5H

InsideOut10 s.r.l.
P.IVA: IT-11381771002
Fax: +39 0110708239
---
LinkedIn: http://it.linkedin.com/in/riccitelli
Twitter: ziodave
---
Layar Partner 
Networkhttp://www.layar.com/publishing/developers/list/?page=1country=city=keyword=insideout10lpn=1

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

Il 20/05/2013 12:30, Martin Koppenhoefer ha scritto:

 2013/5/20 Caterpillar caterpilla...@gmail.com
 mailto:caterpilla...@gmail.com

 Solamente che avendo mappato
 totalmente da solo Salcito, mi rode abbastanza che la mappa sia
 totalmente inutilizzabile per mancanza dei nomi delle vie.



 Se sei di zona ci puoi fare un rilievo, mi sembra fattibile di
 prendere i nomi delle vie, sensi unici, superfici delle strade, limiti
 di velocità, divieti di svolta, scale, principali POI come panificio,
 macellaio, ecc. in una mezza giornata (o forse anche meno).

 Se ti posso suggerire una cosa: quando le strade sono molto strette ai
 centri storici metterei highway=service e service=alley invece di
 residential.

 ciao,
 Martin


 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it
Abito a centinaia di km di distanza
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: I siti italiani dell'unesco escono in opendata

2013-05-20 Thread Paolo Monegato


Il 18/05/2013 12:02, Martin Koppenhoefer ha scritto:

On 18/mag/2013, at 09:44, Maurizio Daniele maurizio.dani...@gmail.com wrote:

Si può fare una relazione site di cose distanti un centinaio di km l'un 
dall'altro?

nel tuo caso lo sconsiglio, l'insieme non è un sito, ma più siti. In generale è 
meglio non usare una relazione ma invece trovare dei tags specifici che hanno 
in comune.


È vero che le relazioni non sono da intendersi come categorie, però nel 
caso specifico (ed in molti altri) non sarebbe il massimo mettere il ref 
dell'UNESCO sul singolo sito dato che ad essere identificato con quel 
ref è l'insieme dei siti.
Dunque se non si vuole usare una relazione va cercata un'altra 
soluzione... (heritage:part=* ?)


ciao
Paolo M

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

2013/5/20 Caterpillar caterpilla...@gmail.com

  Il 20/05/2013 12:30, Martin Koppenhoefer ha scritto:

  Se sei di zona ci puoi fare un rilievo, mi sembra fattibile di prendere
 i nomi delle vie, sensi unici, superfici delle strade, limiti di velocità,
 divieti di svolta, scale, principali POI come panificio, macellaio, ecc. in
 una mezza giornata (o forse anche meno).



 Abito a centinaia di km di distanza



come dicono sul wiki: OpenStreetMap isn't a computer project, it's an
outdoors activity. ;-)

La cosa migliore (senza diminuire il tuo contributo a Salcito, ammetto che
anch'io faccio parecchio mapping in remoto dove non conosco i posti)
sarebbe di mappare in posti che hai rilevato o che puoi rilevare perché
sono vicini.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

2013-05-20 Thread Edoardo Yossef Marascalchi

Quindi mapping party! :)
On May 20, 2013 6:34 PM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:




 2013/5/20 Caterpillar caterpilla...@gmail.com

  Il 20/05/2013 12:30, Martin Koppenhoefer ha scritto:

  Se sei di zona ci puoi fare un rilievo, mi sembra fattibile di prendere
 i nomi delle vie, sensi unici, superfici delle strade, limiti di velocità,
 divieti di svolta, scale, principali POI come panificio, macellaio, ecc. in
 una mezza giornata (o forse anche meno).



  Abito a centinaia di km di distanza



 come dicono sul wiki: OpenStreetMap isn't a computer project, it's an
 outdoors activity. ;-)

 La cosa migliore (senza diminuire il tuo contributo a Salcito, ammetto che
 anch'io faccio parecchio mapping in remoto dove non conosco i posti)
 sarebbe di mappare in posti che hai rilevato o che puoi rilevare perché
 sono vicini.

 ciao,
 Martin

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: I siti italiani dell'unesco escono in opendata

2013/5/20 Paolo Monegato gato.selvad...@gmail.com

 È vero che le relazioni non sono da intendersi come categorie, però nel
 caso specifico (ed in molti altri) non sarebbe il massimo mettere il ref
 dell'UNESCO sul singolo sito dato che ad essere identificato con quel ref è
 l'insieme dei siti.



non lo so. Se questo è un aspetto importante da conservare nei dati (che
tutti insieme costituiscono il patrimonio, mentre la singola parte non ne
merita), allora volendo un multipoligono (molto esteso) o anche un site? Il
multipoligono ha il vantaggio che non si porta in dietro la semantica del
site. Oggetti estesi credo che potrebbero forse creare effetti laterali non
previsti.



 Dunque se non si vuole usare una relazione va cercata un'altra
 soluzione... (heritage:part=* ?)



volendo si. Io finora ho fatto come se la parte fosse l'unico monumento,
quindi ho inserito per dire 2 siti numero 43 (in città diversi) anche se in
realtà facevano insieme un monumento unesco col numero 43.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Termoli

Il 20/05/2013 17:33, Martin Koppenhoefer ha scritto:
 come dicono sul wiki: OpenStreetMap isn't a computer project, it's an
 outdoors activity. ;-)

 La cosa migliore (senza diminuire il tuo contributo a Salcito, ammetto
 che anch'io faccio parecchio mapping in remoto dove non conosco i
 posti) sarebbe di mappare in posti che hai rilevato o che puoi
 rilevare perché sono vicini.

 ciao,
 Martin

Ogni tanto vado in quel paese, quindi male che vada, prenderò io stesso
i nomi delle vie. Solamente che nel frattempo, chissà quanti mesi
passeranno.


Il 20/05/2013 17:40, Edoardo Yossef Marascalchi ha scritto:

 Quindi mapping party! :)

Per mapping party intendi un LanParty dove tutti si incontrano e
mappano, oppure una cosa in remoto allo stesso giorno e orario?

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ed anche il comune di Cesena ha aperto i dati

2013-05-20 Thread Gianmario Mengozzi

ciao a tutti,

ho dei problemi a visualizzare il layer Numeri_civici , estratto da
https://servizi.comune.cesena.fc.it/opendata/statistica.jsp?TABLE_ID=223
,  in QGIS 1.8.0 .

dopo aver convertito lo shape in WGS84 , mi da errore quando tento di
aprire l'openlayer plugin di OSM.

capita anche a voi?

--
Gianmario



Il 18 maggio 2013 16:34, Daniele Forsi dfo...@gmail.com ha scritto:
 Il 18 maggio 2013 14:56, Gianmario Mengozzi ha scritto:

 A breve vi chiederò aiuto per l'importazione dei civici

 se può essere utile, ho aggiunto Cesena nel confronto dei nomi
 http://www.forsi.it/osm/spellcheck/highway/stradario/

 sai a cosa si riferisce il tipo CIO in in questa riga?
 Codice via;Tipo;Denominazione;Località;Quartieri;Estremi;
 8738;CIO;BADEN POWELL;CENTRO;5   Oltre Savio;prospicente il tratto
 finale di via Fausto Coppi , e argine del fiume Savio;
 negli altri casi tipo è VLE, PZA, ecc.

 Per Cesena ci sono 1219 nomi che si trovano sia in OSM che nei dati
 del Comune, 138 solo in OSM e 632 solo nei dati del Comune.
 Anche in questo caso faccia delle modifiche solo chi conosce i luoghi.
 --
 Daniele Forsi

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-it



--
- Gianmario

___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-co] Imagen de la semana: Proyecto La Boquilla

2013-05-20 Thread Vladimir Montealegre Estailes


Bien!!!

Felicitaciones!!!


El 20/05/2013 09:05 a.m., hyan...@gmail.com escribió:

Hola maper@s:

Me place anunciarles que el Proyecto La Boquilla es la imagen de la 
semana en la wiki de OpenStreetMap:


http://wiki.openstreetmap.org/wiki/Main_Page

Buenos días,

Humberto Yances


___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co


___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-co] Imagen de la semana: Proyecto La Boquilla

2013-05-20 Thread Javier Carranza

Felicitaciones a Humberto, siempre tan activo y trbajador...por cierto,
existe una propuesta de hacer un hackathon de mapeos a partir de Agosto con
OSM Chile y Guatemala, alguien se interesa?

Saludos, Javier


On Mon, May 20, 2013 at 9:05 AM, hyan...@gmail.com hyan...@gmail.comwrote:

 Hola maper@s:

 Me place anunciarles que el Proyecto La Boquilla es la imagen de la semana
 en la wiki de OpenStreetMap:

 http://wiki.openstreetmap.org/wiki/Main_Page

 Buenos días,

 Humberto Yances

 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co


___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-co] Imagen de la semana: Proyecto La Boquilla

2013-05-20 Thread hyan...@gmail.com

Javier, chévere que lideres el hackatón para Colombia, creo que podemos
mejorar las estadísticas con tu apoyo.

http://osmstats.altogetherlost.com/index.php?item=countries


El 20 de mayo de 2013 12:17, Javier Carranza
javier.carra...@geocensos.comescribió:

 Felicitaciones a Humberto, siempre tan activo y trbajador...por cierto,
 existe una propuesta de hacer un hackathon de mapeos a partir de Agosto con
 OSM Chile y Guatemala, alguien se interesa?

 Saludos, Javier


 On Mon, May 20, 2013 at 9:05 AM, hyan...@gmail.com hyan...@gmail.comwrote:

 Hola maper@s:

 Me place anunciarles que el Proyecto La Boquilla es la imagen de la
 semana en la wiki de OpenStreetMap:

 http://wiki.openstreetmap.org/wiki/Main_Page

 Buenos días,

 Humberto Yances

 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co



 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co


___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-co] Imagen de la semana: Proyecto La Boquilla

2013-05-20 Thread Leonardo Gutierrez

Que bueno Humberto. Muy merecido.

Algo out of topic, aprovecho para agradecerte el tiempo que nos dedicarte
en tu ciudad a mi familia y a mi.

Ojala todo te salga bien en tus proyectos.
El 20/05/2013 13:06, hyan...@gmail.com hyan...@gmail.com escribió:

 Javier, chévere que lideres el hackatón para Colombia, creo que podemos
 mejorar las estadísticas con tu apoyo.

 http://osmstats.altogetherlost.com/index.php?item=countries


 El 20 de mayo de 2013 12:17, Javier Carranza 
 javier.carra...@geocensos.com escribió:

 Felicitaciones a Humberto, siempre tan activo y trbajador...por cierto,
 existe una propuesta de hacer un hackathon de mapeos a partir de Agosto con
 OSM Chile y Guatemala, alguien se interesa?

 Saludos, Javier


 On Mon, May 20, 2013 at 9:05 AM, hyan...@gmail.com hyan...@gmail.comwrote:

 Hola maper@s:

 Me place anunciarles que el Proyecto La Boquilla es la imagen de la
 semana en la wiki de OpenStreetMap:

 http://wiki.openstreetmap.org/wiki/Main_Page

 Buenos días,

 Humberto Yances

 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co



 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co



 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co


___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-uy] Datos de Canelones y San Jose

2013-05-20 Thread Germán Iglesias

 

Se pueden descargar los datos solicitando el acceso tal como lo
indica el documento: 

Documento de Acceso al Conjunto de Datos
Provisorios -CDP-. (.odt 87.2 KB) 

que se encuentra en:


http://agesic.gub.uy/innovaportal/v/679/1/agesic/descargas.html [1]


Por lo que tengo oído no se niega a nadie el acceso, simplemente
quieren llevar un registro. 

Saludos, 

Germán 

El 2013-05-20 00:25,
mural...@montevideo.com.uy escribió: 

 Estimados:
 
 En el Geoportal
de IMM http://geoweb.montevideo.gub.uy/geonetwork/srv/es/main.home hay
capas de los departamentos de Canelones y San Jose, que para la descarga
manda a www.ide.gub.uy.
 Algunos pueden resultar utiles en general como
los numeros de puerta, y otros puntualmente, como las calles, en
localidades donde las imagenes aereas de Bing no son adecuadas.
 
 En
ide.gub.uy no encontre ningun lugar para descarga, ni licencia que se
publican para ver si puede ser compatible con OSM.
 ¿Habra que hacer
una solicitud basandose en la ley de derecho de acceso a la informacion
publica?
http://200.40.229.134/leyes/AccesoTextoLey.asp?Ley=18381Anchor=
 

Saludos,
 M. 
 

---


 Todos los libros digitales (ebooks) y de papel en
www.NosGustaLeer.com
 

---

-

El
presente correo electrónico y cualquier posible archivo adjunto está
dirigido únicamente al destinatario del mismo y contiene información que
puede ser confidencial. Si Ud. no es el destinatario correcto por favor
notifique al remitente respondiendo este mensaje y elimine
inmediatamente de su sistema, el correo electrónico y los posibles
archivos adjuntos al mismo. Está prohibida cualquier utilización,
difusión o copia de este correo electrónico por cualquier persona o
entidad que no sean las específicas destinatarias del mensaje. La
Intendencia de Montevideo no acepta ninguna responsabilidad con respecto
a cualquier comunicación que haya sido emitida incumpliendo nuestra
normativa municipal, así como lo previsto en la Ley 18.331 de Protección
de Datos Personales y la Ley 18.381 de Acceso a la Información Pública.


This e-mail and any attachment is confidential and is intended solely
for the addressee(s). If you are not intended recipient please inform
the sender immediately, answering this e-mail and delete it as well as
the attached files. Any use, circulation or copy of this e-mail by any
person or entity that is not the specific addressee(s) is prohibited.
The City Council of Montevideo is not responsible for any communication
emitted without respecting our Organization Policy or the Data
Protection Act and Habeas Data Action No. 18.331 and the Information
Access Act Nº 18.381. 

Links:
--
[1]
http://agesic.gub.uy/innovaportal/v/679/1/agesic/descargas.html
___
Talk-uy mailing list
Talk-uy@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-uy

Re: [Talk-dk] Oversættelse af ordet waypoint i JOSM

2013-05-20 Thread Sonny B. Andersen

Nej, sådan hænger det ikke sammen, i hvert fald ikke når det drejer sig om
GPS'er: Et spor er en streg, der forbinder de punkter man har opsamlet
(logget), mens man gik, mens en rute er en liste over de waypoints, man
planlægger at følge. En rute vil derfor som regel have væsentligt færre
punkter end et spor. - Man kan også sige at et spor er fortid, mens en rute
er fremtid.

 

Men tingene er godt rodet sammen, så punkterne tagges forskelligt i
xml-filerne og de opfører sig også forskelligt på GPS'en, fx kan man i nyere
GPS'er godt gå efter et spor, men man kan ikke se eller fjerne punkterne
undervejs; de optræder simpelthen ikke på waypoint-listen.

 

Så jeg går stadig ind for waypoints, men jeg er meget enig med Jonas i, at
man lige skal se på den konkrete anvendelse ...

 

Hilsen,

sba-dk

 

Fra: Nick Østergaard [mailto:oe.n...@gmail.com] 
Sendt: 19. maj 2013 21:15
Til: OpenStreetMap Denmark
Emne: Re: [Talk-dk] Oversættelse af ordet waypoint i JOSM

 

Hej Sonny

Nu vil jeg mene at et spor et et subsæt af en rute, hvorfor at et rutepunk
vil dække bægge. Desuden snakker ud om PIO's som jo også vil være en del af
en rute når man vil navigere til det.

Nick Østergaard

 

Den 19. maj 2013 12.41 skrev Sonny B. Andersen s...@bukhmark.dk:

Hej Jonas,-

Hvis du med spot-on oversættelse mener en dækkende oversættelse er jeg
ikke enig. I forbindelse med frilufts-GPS'er så indgår et waypoint i både
ruter og spor, og det kan også være et POI (interessant punkt) eller
koordinater på en bil-GPS. At oversætte waypoint til rutepunkt vil
derfor ikke være dækkende.

I denne forbindelse vil det nok være bedst at bibeholde waypoint, eller evt.
nøjes med punkt. Hvis jeg skulle starte helt forfra ville jeg overveje at
oversætte det til sted.

Hilsen,
sba-dk

-Oprindelig meddelelse-
Fra: Jonas Häggqvist [mailto:ras...@rasher.dk]
Sendt: 18. maj 2013 23:59

Til: OpenStreetMap Denmark
Emne: Re: [Talk-dk] Oversættelse af ordet waypoint i JOSM

On 15-05-2013 22:18, Anders Lund wrote:
 Onsdag den 15. maj 2013 18:30:24 skrev John Plate:
 rutepunkt kan da ikke passe bedre. waypoint er lidt fantasiløst.

 Det er vel nærmest usansynligt at et punkt i josm er en del af en rute
 :0

 Personligt synes jeg punkt er fint i josm, ellers går jeg ind for
 waypoint.

Hvorfor er det usandsynligt? Har du kigget på hvor det rent faktisk bliver
brugt i JOSM?

I mine øjne er rutepunkt en spot-on oversættelse af waypoint.

--
Jonas Häggqvist
rasher(at)rasher(dot)dk

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk



-
Ingen virus fundet i denne meddelelse.
Kontrolleret af AVG - www.avg.com
Version: 2013.0.2904 / Virusdatabase: 3162/6329 tel:3162%2F6329  -
Udgivelsesdato: 16-05-2013




___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

 

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Oversættelse af ordet waypoint i JOSM

2013-05-20 Thread Nick Østergaard

Den 20. maj 2013 11.18 skrev Sonny B. Andersen s...@bukhmark.dk:

 Nej, sådan hænger det ikke sammen, i hvert fald ikke når det drejer sig om
 GPS'er: Et spor er en streg, der forbinder de punkter man har opsamlet
 (logget), mens man gik, mens en rute er en liste over de waypoints, man
 planlægger at følge. En rute vil derfor som regel have væsentligt færre
 punkter end et spor. - Man kan også sige at et spor er fortid, mens en rute
 er fremtid.


Man kunne godt vælge at skelne mellem spor og rute som henholdsvis fortid
og fremtid, men det ændrer ikke på at et spor er i subsæt af en rute som
jeg påstår. Skal vi binde det sammen med tid kunne man jo betragte et spor
som et subsæt af en rute afhængig af tid, hvorfor at et spor er et subsæt
af en rute.

Du siger at et spor er en streg der forbinder punkter man har logget, det
er vel ok, men en rute er jo for så vidt også en streg forbundet mellem
nogle punkter man har speceficeret -- også selvom at der er kommet flere
mindre punker, i form at at den f.eks. følger et vejnet.

I og med at alt der tegnes i OSM kan betrages som fremtid (når nogen bruger
dataene på f.eks. en GPS endhed) er det jo et argument for at kalde det
rutepunkt.
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

[Talk-es] Mapping Party de Badajoz celebrada

2013-05-20 Thread Francisco Hernández Castaño



Este fin de semana pasado se ha celebrado nuestra primera Mapping Party a pesar 
de la amenaza de lluvia y el frío. 



El encuentro ha servido para muchas cosas. En primer lugar nos ha servido a la 
mayoría para conocer las herramientas de trabajo como OSMTracker y JOSM, de las 
cuales, casi todos hemos coincidido en que nos queda mucho por explorar por lo 
amplio de ambos programas . Pero sobre todo nos ha servido para conocer parte 
de las tripas de OpenStreetMap y comprender su metodología y sobre todo su 
filosofía. 

En estos próximos días iremos introduciendo datos que nos quedaron por pasar, 
ya que la tarde se hizo bastante corta para la ingente cantidad de datos 
recabados. 



También ha sido una oportunidad para conocer a gente que está interesada en 
este mundillo, si me lo permitís os copio la palabra, los geoinquietos. Me 
encantó escuchar ideas que a muchos se les iba ocurriendo sobre cosas que 
querían subir a la plataforma, a nivel particular unas y abiertas a todo el 
público otras. 



Desde la Diputación de Badajoz queremos dar las gracias a todos los que 
participaron y especialmente a Juan Ramón Tamayo, Carlos Dávila y Jonás Andrada 
de quienes hemos po did o aprender mucho y que, además, tanto nos han ayudado 
en la organización. 



Enhorabuena a todos los que colaborais en este proyecto porque de verdad es una 
plataforma util, participativa, completa y lo que es mejor al alcance de todos 
los que tengan un mínimo interés, tanto por ser gratuita como por no requerir 
conocimientos excesivamente elevados. 



Gracias y hasta pronto 

  
__ 

Francisco Javier Hernández Castaño 
Jefe de Unidad Cartográfica 
Diputación de Badajoz - O. A. Área de Igualdad y Desarrollo Local 
Servicio de Información Geográfica (SIGcBA) 
  
Avda. Antonio Masa Campos 28 (antiguo jardin infantil) 
06011 - Badajoz 
  
Correo-e: fhernan...@dip-badajoz.es 
Teléfono: +34 924 212 242 
Fax: +34 924 212 260 
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

[Talk-ro] CLC stricat la nord de brasov

2013-05-20 Thread Razvan


Salutare
Userul costinmap iar a sters la nord de brasov din CLC pe way:87386092 
chiar langa strada Nicolae Labis. Acolo am descoperit ca este intrerupt 
dar nu stiu unde sa il unesc . Am incercat sa ma prind cu el de toate 
liniile de delimitare din zona dar niciuna se pare ca nu e parte din 
acelasi multipoligon deoarece nu se reintregeste bucla ( nu se face 
galbena).


___
Talk-ro mailing list
Talk-ro@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

Re: [Talk-ro] CLC stricat la nord de brasov

2013-05-20 Thread Razvan


Gata l-am reparat si pe asta  :D

On 20.05.2013 10:16, Razvan wrote:

Salutare
Userul costinmap iar a sters la nord de brasov din CLC pe way:87386092 
chiar langa strada Nicolae Labis. Acolo am descoperit ca este 
intrerupt dar nu stiu unde sa il unesc . Am incercat sa ma prind cu el 
de toate liniile de delimitare din zona dar niciuna se pare ca nu e 
parte din acelasi multipoligon deoarece nu se reintregeste bucla ( nu 
se face galbena).



___
Talk-ro mailing list
Talk-ro@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ro

Re: [Talk-cz] značky na map1.eu

2013-05-20 Thread Marián Kyral



-- Původní zpráva --
Od: Karel Volný ka...@seznam.cz
Datum: 20. 5. 2013
Předmět: Re: [Talk-cz] značky na map1.eu

 mtbmap mají nejaký podivný pidi
 symbol (dlouho jsem si nebyl jistý, co to vlastně je).

to je právě ten turistický symbol - tady by to ale asi stálo za to 
navrhnout, 
aby mtbmap rozlišovala styl pro mobilní zařízení a styl pro velký monitor ..
. 
na pidi displayi telefonu, který držím těsně před xichtem, je to asi akorát,

ale když na to koukám na monitoru, tak musím souhlasit, že je to pidi a 
nesrozumitelné



Tohle spíše vypadá jako semaforová věž ze Zeměplochy. Něco lepšího by 
nebylo? :-D

Marián



___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz;___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk-fr] Rendu FR: les évolutions des dernières semaines...

Il est toujours possible de consulter la page commits de github,
mais voici un résumé des modifications récentes, certaines n'ayant pas
été abordées ici mais seulement sur trac:

- ajout d'un symbole (la barrière levante) sur les péages
- ajout du symbole des déchetteries et de l'emprise de celles-ci
- ajout du rendu de landuse=greenhouse_horticulture et building=greenhouse
- mise en évidence des monuments historiques (seulement pour
heritage=1 pour l'instant) avec un nom en gras brun (utilisé par ce
qui touche au tourisme)
- correction du rendu des sommets/volcans/cols avec l'altitude et
arrondi de celle-ci
- de nombreux symboles passés en SVG (il en reste encore à transformer)
- nouveaux symboles pour les zoos, les magasins d'ameublement, les
stations essence avec GPL, pour le shopping (departmentstore et
mall)
- rendu des passages à niveaux et buttoirs
- landuse=farm un peu plus clair...
- contraste sur les voies ferrées (et différence entre les voies
principales et de service)

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu françafrique


Bonjour,

Il y a quelques mois, on discutait dans HOT de la classification des 
rares routes en Afrique. Je me disais que ça serait sympa d'avoir un 
rendu spécifique qui ferait ressortir les routes plus tôt quand on 
zoome. Ou qui permette facilement de distinguer les routes goudronnées 
de celles qui ne le sont pas.


Je me suis aussi rendu compte que le rendu osm-fr dépassait largement 
les frontières de l'hexagone.


Enfin, j'ai constaté que Mapquest Open avait des rendus différents 
suivant les zones de la planète. Par exemple, les routes n'ont pas les 
mêmes couleurs dans les îles britanniques et en Europe continentale.


Alors, ne pourrait-on pas dans OSM-Fr avoir un rendu spécifique pour 
l'Afrique?


J'ai plein d'idées, dont certaines pourraient d'ailleurs s'appliquer en 
France.




Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Où est la carte officielle des radars ?

2013-05-20 Thread Pierre-Alain Dorange

Gad.Jo perche...@gmail.com wrote:

 On ne peut donc plus récupérer l'identifiant de la sécurité routière ?

Je ne sais pas.
Pas sur ue la sécurité routière participe à l'OpenData.

 Sinon sur ton site il manque ce radar de feu rouge que j'ai vu lors de mes
 déplacements dans le Gard :
 http://www.openstreetmap.org/browse/node/2208604685

Crée le lendemain de la mise à jour, donc il n'y est pas.
Il est par contre normalement sur la carte freeroute.

 Si je comprend bien, on n'a pas de carte officielle mais uniquement les
 relevés que font les contributeurs ?

Oui, c'est ça.
Les 2 cartes sont des extraits de ce qui a été saisie dans OSM par nous
contributeurs.

-- 
Pierre-Alain Dorange
OSM experiences : http://www.leretourdelautruche.com/map/


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique

2013-05-20 Thread Yohan Boniface


Bonjour,

C'est pas exactement un «rendu Françafrique», mais, autour de HOT 
justement, on est en train de bosser sur un rendu HDM [1] (aka 
Humanitarian Data Model), qui est le nom de code du travail de 
modélisation fait par HOT pour OSM. Et en gros l'objectif est d'avoir un 
rendu optimisé pour les pays en voie de développement: en particulier 
rendu des routes plus adapté (prendre en compte la surface, la 
condition...), et un set d'icônes ad hoc (puits sans pompe, puits avec 
pompe manuelle, puits avec pompe automatique...), plus moult détails 
(afficher les gués, afficher la saisonnalité des cours d'eau, etc.).
Pour l'instant, on a surtout concentré nos efforts sur le nettoyage de 
la modélisation elle-même, plus un rendu JOSM (toujours en cours de 
finition) [2], notamment avec la création d'un set d'icônes [3].
Mais on devrait très bientôt commencer à voir un style CartoCSS open 
sourcé et dispo pour la participation de la communauté [4] :)
A voir ensuite avec les tyrans (humour) d'OSM-fr pour savoir si on 
pourra l'héberger sur les serveurs de l'asso ;)



Yohan

[1] http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags
[2] https://github.com/hotosm/HDM-JOSM-style
[3] http://hot.openstreetmap.org/hdm_icons_set_call_for_proposals
[4] http://hot.openstreetmap.org/hdm_cartocss_style_call_for_proposals



On 05/20/2013 08:53 AM, Eric SIBERT wrote:

 Bonjour,

Il y a quelques mois, on discutait dans HOT de la classification des
rares routes en Afrique. Je me disais que ça serait sympa d'avoir un
rendu spécifique qui ferait ressortir les routes plus tôt quand on
zoome. Ou qui permette facilement de distinguer les routes goudronnées
de celles qui ne le sont pas.

Je me suis aussi rendu compte que le rendu osm-fr dépassait largement
les frontières de l'hexagone.

Enfin, j'ai constaté que Mapquest Open avait des rendus différents
suivant les zones de la planète. Par exemple, les routes n'ont pas les
mêmes couleurs dans les îles britanniques et en Europe continentale.

Alors, ne pourrait-on pas dans OSM-Fr avoir un rendu spécifique pour
l'Afrique?

J'ai plein d'idées, dont certaines pourraient d'ailleurs s'appliquer en
France.



Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique

Je plussois j'ai tracé pas mal de piste dans le cercle de Kayes autour de
Manantali. *J'ai utilisé la structure par défau*t de classification des
routes (primary à mineur) *pour avoir une compréhension générale de
l'importance de chaque axe* mais 90% des axes ne semble pas goudronné :
http://www.openstreetmap.org/?lat=13.3201lon=-10.7213zoom=13layers=M

Pour l'avoir emprunter en 2010, l'axe primary menant à Manantali est en
latérite (piste) avec quelques grosse excavation. L'accès est réglementé
par des barrières de pluie pendant la saison humide.

Cela peut induire en erreur quand à la praticabilité de ces axes. Pouvez
m'indiquer les tags que vous utilisez pour l'Afrique ? Je pensai indiquer
le type de surface (sable, latérite, roche, piste aménagée et entretenue)
mais vue du ciel je serait approximatif.


Le 20 mai 2013 09:18, Yohan Boniface yohanbonif...@free.fr a écrit :

 Bonjour,

 C'est pas exactement un «rendu Françafrique», mais, autour de HOT
 justement, on est en train de bosser sur un rendu HDM [1] (aka
 Humanitarian Data Model), qui est le nom de code du travail de
 modélisation fait par HOT pour OSM. Et en gros l'objectif est d'avoir un
 rendu optimisé pour les pays en voie de développement: en particulier rendu
 des routes plus adapté (prendre en compte la surface, la condition...), et
 un set d'icônes ad hoc (puits sans pompe, puits avec pompe manuelle, puits
 avec pompe automatique...), plus moult détails (afficher les gués, afficher
 la saisonnalité des cours d'eau, etc.).
 Pour l'instant, on a surtout concentré nos efforts sur le nettoyage de la
 modélisation elle-même, plus un rendu JOSM (toujours en cours de finition)
 [2], notamment avec la création d'un set d'icônes [3].
 Mais on devrait très bientôt commencer à voir un style CartoCSS open
 sourcé et dispo pour la participation de la communauté [4] :)
 A voir ensuite avec les tyrans (humour) d'OSM-fr pour savoir si on pourra
 l'héberger sur les serveurs de l'asso ;)


 Yohan

 [1] 
 http://wiki.openstreetmap.org/**wiki/Humanitarian_OSM_Tagshttp://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags
 [2] 
 https://github.com/hotosm/HDM-**JOSM-stylehttps://github.com/hotosm/HDM-JOSM-style
 [3] 
 http://hot.openstreetmap.org/**hdm_icons_set_call_for_**proposalshttp://hot.openstreetmap.org/hdm_icons_set_call_for_proposals
 [4] 
 http://hot.openstreetmap.org/**hdm_cartocss_style_call_for_**proposalshttp://hot.openstreetmap.org/hdm_cartocss_style_call_for_proposals




 On 05/20/2013 08:53 AM, Eric SIBERT wrote:

  Bonjour,

 Il y a quelques mois, on discutait dans HOT de la classification des
 rares routes en Afrique. Je me disais que ça serait sympa d'avoir un
 rendu spécifique qui ferait ressortir les routes plus tôt quand on
 zoome. Ou qui permette facilement de distinguer les routes goudronnées
 de celles qui ne le sont pas.

 Je me suis aussi rendu compte que le rendu osm-fr dépassait largement
 les frontières de l'hexagone.

 Enfin, j'ai constaté que Mapquest Open avait des rendus différents
 suivant les zones de la planète. Par exemple, les routes n'ont pas les
 mêmes couleurs dans les îles britanniques et en Europe continentale.

 Alors, ne pourrait-on pas dans OSM-Fr avoir un rendu spécifique pour
 l'Afrique?

 J'ai plein d'idées, dont certaines pourraient d'ailleurs s'appliquer en
 France.



 Éric

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Où est la carte officielle des radars ?

Ok je comprend mieux. Il y a en tellement que ça affole le processeur et il
y a des ralentissement à l'affichage ;-/

Je ne sais pas si c'est la meilleur méthode mais voici ce que j'ai fait
pour faire un contrôle visuel sur ces éléments :
http://overpass-turbo.eu/s/bX

Cela permet de contrôler visuellement :
 - La présence de 3 éléments pour chaque relation enforcement (device,
from, to) ;
 - Si il y a qu'un seul point, seul le radar est présent physiquement et il
faut créer une relation enforcement pour indiquer la zone surveillée.

Je débute avec overpass, si tu a des méthode à faire découvrir (via
overpass turbo), je suis demandeur.


Le 20 mai 2013 09:10, Pierre-Alain Dorange pdora...@mac.com a écrit :

 Gad.Jo perche...@gmail.com wrote:

  On ne peut donc plus récupérer l'identifiant de la sécurité routière ?

 Je ne sais pas.
 Pas sur ue la sécurité routière participe à l'OpenData.

  Sinon sur ton site il manque ce radar de feu rouge que j'ai vu lors de
 mes
  déplacements dans le Gard :
  http://www.openstreetmap.org/browse/node/2208604685

 Crée le lendemain de la mise à jour, donc il n'y est pas.
 Il est par contre normalement sur la carte freeroute.

  Si je comprend bien, on n'a pas de carte officielle mais uniquement les
  relevés que font les contributeurs ?

 Oui, c'est ça.
 Les 2 cartes sont des extraits de ce qui a été saisie dans OSM par nous
 contributeurs.

 --
 Pierre-Alain Dorange
 OSM experiences : http://www.leretourdelautruche.com/map/


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr intégration des icones ou layers

2013-05-20 Thread Ista Pouss

Le 19 mai 2013 17:13, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le plus complexe est en fait de trouver un équilibre valable quelle
 que soit la zone, car par endroit on a une très forte densité d'info,
 et donc besoin de repousser au zoom suivant l'affichage de certains
 objets, alors qu'à d'autre endroits il faudrait les faire apparaitre
 un peu plus tôt pour ne pas avoir un rendu trop vide.


Ça c'est le plus complexe d'un point de vue technique et design, ce qui est
déjà bien.

Mais un rendu français donne réponse à une recherche de français. Donc il
suppose une réflexion sur ce qu'attendent les français. Comme c'est toi qui
fait ça c'est toi qui voit bien sûr, aussi je peux me tromper.

À lire cette liste on peut se faire une idée, probablement fausse, mais bon
: un truc très orienté administratif (alors que les français passent leur
temps à gueuler contre l'administration), matiné de quelques considérations
écologiques, avec les logos des entreprises françaises, et répondant aux
modes porteuses des appels d'offres, tels l' handicap.

Et même la françafrique qui repointe le bout de son nez. (quand j'ai vu
ça de la part d'humanitaires j'ai sauté au plafond)

Ainsi va la France...

Je pense que le substrat administratif est (malheureusement) un point dur
des conceptions françaises, et qu'il peut constituer la base du rendu
générique. Les logos des entreprises françaises aussi, c'est aussi un
point dur, ce n'est pas si mal. Mais attention que les logos changent.

On peut discuter sur les considérations écologiques ; il y a quelque chose
de profond dans la société française là dessus je pense, mais j'avoue ne
pas trop savoir quoi. Le nucléaïre est une valeur écologique pour beaucoup
de français... à vérifier.

Par contre je crois qu'il vaudrait mieux rejeter les modes porteuse du
business sur des rendus vectoriels, et donc tout ce qui concerne
l'handicap, par exemple (en ce moment). Elles sont vraiment trop floues et
ponctuelles, et la plupart du temps complètement en dehors du sujet
qu'elles prétendent traiter.

Et, quand à la françafrique... on attendra que les humanitaires se
débarrassent eux mêmes de cette notion, et ensuite on y réfléchira aussi,
c'est mon opinion.

Hugh (surtout que je fais rien). (merci Christian)


-- 
Les dérives de rue :
Profession émotion http://drivrsdu.fr/profession-emotion/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr intégration des icones ou layers

2013-05-20 Thread Philippe Verdy

Tout à fait d'accord. Et pas plus non plus l'Anglafrique ou la Portafrique
d'ailleurs, car les besoins sont ailleurs et n'ont pas à être définis
d'Europe mais devraient répondre à des expressions de besoins locaux pour
leur appropriation par ces populations.

Mais on connait des éléments majeurs pour eux :
- la toponymie dans plus de langues que les langues nationales ou
officielles
- la gestion des déchets et les décharges sauvages
- l'accès à l'eau potable et les traitements des eaux usées
- l'accès local à l'électricité ou d'autres énergies (pas ou peu de réseau
de distribution)
- les équipements sanitaires collectifs (à commencer par les écoles)
- les zones d'éducation primaire(surtout en milieu rural où les distances
peuvent être considérables) ou de santé (couverture des hôpitaux et
dispensaires ou de la médecine itinérante)
- l'accès aux médicaments fiables (hors des marchés non contrôlés)
- les cheptels et zones de nomadisme
- la vie citoyenne locale non officielle qui ne figure pas sur les cartes
administratives officielles
- les groupes ethniques et linguistiques

Des tas de choses en revanche ne sont pas normalisées : il y a beaucoup de
spécificités locales à prendre en compte pourtant, mais le gros du travail
c'et d'abord un relevé plus ou moins qualitatif avant que cela devienne
normalisable. Quand des choses ont été codifiées, c'est souvent à partie
de schémas étrangers importants très incomplets et souvent incompatibles
entre eux. non libres, et difficile à réactualiser. OSM peut être
prescripteur de solutions communes et d'échanges là où les normes
propriétaires ou importées d'autres pays ont échoué (ou sont trop chères à
mettre en oeuvre).

Le 20 mai 2013 10:28, Ista Pouss ista...@gmail.com a écrit :

 Et, quand à la françafrique... on attendra que les humanitaires se
 débarrassent eux mêmes de cette notion, et ensuite on y réfléchira aussi,
 c'est mon opinion.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Cadastre: divergence entre différentes sources

2013-05-20 Thread RainerU

Bonjour,

Je viens de constater que le découpage des parcelles cadastrales n'est pas le
même sur cadastre.gouv.fr que sur le géoportail IGN, par exemple ici [1]. Est-ce
que ça veut dire que les données sur le géoporatil sont plus à jour ou qu'elles
ne sont pas correctes ?

Rainer

[1]
http://www.openstreetmap.org/?lat=42.6936985amp;lon=2.8798795amp;zoom=18amp;layers=Mamp;mlat=42.69384amp;mlon=2.87958


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Inselbergs Guyane

2013-05-20 Thread Romain MEHUT

Bonjour Stéphane,

Le 16 mai 2013 22:34, Stéphane MARTIN st3ph.mar...@laposte.net a écrit :

 Salut,

 Petite vérification d'étiquettes SVP.

 Romain Mehut m'avait indiqué une page il y a quelques temps. Merci Romain
 :-)
 http://www.guyane.**developpement-durable.gouv.fr/**
 journees-inspire-en-guyane-**a746.htmlhttp://www.guyane.developpement-durable.gouv.fr/journees-inspire-en-guyane-a746.html
 Il semblerait que la page soit protégée maintenant :-(


Tu as essayé d'appeler la DEAL? cf.
http://www.guyane.developpement-durable.gouv.fr/IMG/pdf/Programme_Journees_INSPIRE.pdf

Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmecum aux champs pour la randonnée à pied, à vélo ou à cheval

2013-05-20 Thread Romain MEHUT

Bonjour,

Pour info, j'ai mis en ligne l'osmecum pour la randonnée:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum#en_randonn.C3.A9e

Romain

Le 3 septembre 2012 09:18, jb...@mailoo.org a écrit :

 **

 Mes quelques remarques à la relecture :

  - L'emplacement du Glossaire (je ne comprends pas ce qu'il fait là quand
 je tombe dessus. Au début, à la fin ?)

  - Points d'intérêt, lieu-dit, hameau : place=* (c'est bien locality,
 hamlet, etc, qu'on y met ?). En lisant, j'aurais tendance à y mettre le nom
 du lieu directement. J'ajouterai donc la liste place=hamlet, etc, et le tag
 name=*.

  - Équipement, Abri : Si on s'adresse à des randonneurs, j'ajouterais au
 moins tourism=wilderness_hut pour les abris pour dormir. Dans
 amenity=shelter, on voit un peu tout passer, en passant au moins par
 l'abribus.

  - Itinéraire, network=*. J'ajouterais la liste des valeurs à utiliser.

  - Itinéraire, distance=*. Non pas la distance de l'itinéraire (distance à
 quoi ?), mais plutôt la longueur total…

 Voilà voilà,

 JB

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un robot pour séparer les frontières des autres éléments

2013-05-20 Thread Pieren

2013/5/19 Romain MEHUT romain.me...@gmail.com:
 Rectificatif:
 http://lists.openstreetmap.org/pipermail/talk-fr/2013-May/058594.html


Attention. Dans ce message, je précise juste que la séparation est
nécessaire s'il y a divergence entre cadastre et réalité du terrain
(ou imagerie Bing), comme un lit de cour d'eau qui, ponctuellement, se
déplace (érosion naturelle, précipitations exceptionnelles, travaux,
etc).
Si la limite naturelle correspond exactement à la limite
administrative, je ne me prononce sur la solution à adopter et on
revient aux deux méthodes listées sur le wiki. Je veux juste signaler
qu'un bot ne serait pas une bonne solution car une personne imposerait
une des deux solutions à tout le monde alors que je crois qu'il faut
laisser le choix aux contributeurs (techniquement, les deux sont
valides).

Par contre, ce qui n'est pas dans le wiki, c'est que la solution des
deux ways avec des noeuds superposés ne résoud pas un problème majeur
sur ces limites à la fois naturelles (routes,cours d'eau) et
administratives. La plupart sont et seront déplacées par de nouveaux
contributeurs qui pensent bien faire en ajustant la limite sur une
image aérienne ou trace GPS quelconque, sans se demander si ça n'est
pas leur nouvelle source qui est décalée et pas le way déjà dans OSM.
Quelle que soit la solution adoptée, way unique ou ways dupliqués avec
noeuds partagés, la limite administrative est alors détériorée et ne
corrspond plus au cadastre. Pour éviter cela, la moins pire des
solutions serait de mettre un way complétement indépendant, sans
noeuds partagés avec l'élément naturel. Mais sachant combien il
devient difficile (et irritant) d'interpréter et éditer une carte avec
ce genre de ways qui se chevauchent plus ou moins, je n'irais pas
jusqu'à en faire une troisième option sur le wiki. Reste donc à être
vigilant sur ces limites qu'il faudra particulièrement surveiller dans
le futur (ça, c'est un truc qu'un bot peut faire ;-)

 Le 18/05/2013 22:41, Vincent de Château-Thierry a écrit :

 il suffit de se baiser pour en trouver.
Voila une nouvelle perspective sur les cartoparties que je n'avais pas
encore envisagé :-) Merci pour cette franche poilade.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique


Le 20/05/2013 09:18, Yohan Boniface a écrit :

Bonjour,

C'est pas exactement un «rendu Françafrique», mais, autour de HOT
justement, on est en train de bosser sur un rendu HDM [1] (aka
Humanitarian Data Model), qui est le nom de code du travail de
modélisation fait par HOT pour OSM.


Le message que j'avais mis dans un coin en me disant qu'il faudrait 
peut-être que je le lise à tête reposée quand j'aurai du temps :-p



Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un robot pour séparer les frontières des autres éléments

Hier j'ai passé l'après midi à indiquer des maxspeed entre Valence et
Montpellier et à certains endroit les frontières étaient fusionnée avec les
routes et rivière. J'ai du consulter le cadastre pour chaque commune pour
être certains que je n'allais pas faire d'impair.

Certaines fois la frontière était très proche de la route ou rivière et
j'ai laissé fusionné, d'autre fois c'était la route qui suivait la
frontière sans suivre l'imagerie (rare cas) et plus souvent l'inverse
(frontière qui ne respecte plus le cadastre). A la fin j'ai baissé les bras
et tout laissé tel quel pour le prochain contributeur qui devra faire le
tris lui même.

J'ai simplement fait des découpage sans déplacement pour ajouter mes
maxspeed au bon endroit. Dommage ça aurait été l'occasion de faire des
ajustements plus fin avec l'imagerie Bing mais le travail de contrôle du
cadastre était trop important.


Le 20 mai 2013 12:14, Pieren pier...@gmail.com a écrit :

 2013/5/19 Romain MEHUT romain.me...@gmail.com:
  Rectificatif:
  http://lists.openstreetmap.org/pipermail/talk-fr/2013-May/058594.html
 

 Attention. Dans ce message, je précise juste que la séparation est
 nécessaire s'il y a divergence entre cadastre et réalité du terrain
 (ou imagerie Bing), comme un lit de cour d'eau qui, ponctuellement, se
 déplace (érosion naturelle, précipitations exceptionnelles, travaux,
 etc).
 Si la limite naturelle correspond exactement à la limite
 administrative, je ne me prononce sur la solution à adopter et on
 revient aux deux méthodes listées sur le wiki. Je veux juste signaler
 qu'un bot ne serait pas une bonne solution car une personne imposerait
 une des deux solutions à tout le monde alors que je crois qu'il faut
 laisser le choix aux contributeurs (techniquement, les deux sont
 valides).

 Par contre, ce qui n'est pas dans le wiki, c'est que la solution des
 deux ways avec des noeuds superposés ne résoud pas un problème majeur
 sur ces limites à la fois naturelles (routes,cours d'eau) et
 administratives. La plupart sont et seront déplacées par de nouveaux
 contributeurs qui pensent bien faire en ajustant la limite sur une
 image aérienne ou trace GPS quelconque, sans se demander si ça n'est
 pas leur nouvelle source qui est décalée et pas le way déjà dans OSM.
 Quelle que soit la solution adoptée, way unique ou ways dupliqués avec
 noeuds partagés, la limite administrative est alors détériorée et ne
 corrspond plus au cadastre. Pour éviter cela, la moins pire des
 solutions serait de mettre un way complétement indépendant, sans
 noeuds partagés avec l'élément naturel. Mais sachant combien il
 devient difficile (et irritant) d'interpréter et éditer une carte avec
 ce genre de ways qui se chevauchent plus ou moins, je n'irais pas
 jusqu'à en faire une troisième option sur le wiki. Reste donc à être
 vigilant sur ces limites qu'il faudra particulièrement surveiller dans
 le futur (ça, c'est un truc qu'un bot peut faire ;-)

  Le 18/05/2013 22:41, Vincent de Château-Thierry a écrit :
 
  il suffit de se baiser pour en trouver.
 Voila une nouvelle perspective sur les cartoparties que je n'avais pas
 encore envisagé :-) Merci pour cette franche poilade.

 Pieren

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique


Cela peut induire en erreur quand à la praticabilité de ces axes. Pouvez
m'indiquer les tags que vous utilisez pour l'Afrique ?


Ce que j'utilise pour Madagascar :

http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#.C3.89tat_de_surface

Je n'ai pas vérifier si c'était en accord avec HDM.


Je pensai
indiquer le type de surface (sable, latérite, roche, piste aménagée et
entretenue) mais vue du ciel je serait approximatif.


Tu peux toujours commencer par paved/unpaved.


 Pour l'avoir emprunter en 2010, l'axe primary menant à Manantali est en
 latérite (piste) avec quelques grosse excavation. L'accès est réglementé
 par des barrières de pluie pendant la saison humide.

seasonal=yes

access:conditional=no @ Dec-Apr : Cette piste est habituellement fermée 
de décembre à avril (ou ouverte de mai à novembre).


Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Maxspeed : Où en êtes vous sur le projet du mois ?

Bonjour,


À dix jours de la fin du mois et de son projet maxspeed, où en êtes vous ?

De mon coté ça avance très fort depuis que je suis de retour dans le sud.
Je suis en train de finir l'intégration des différents pointage que j'ai
fait entre la Drôme et l'Aude. Étant l'un des rare à utiliser
OpenStreetBug, j'ai rempli la carte de rapport de bug indiquant les vitesse
qui sont tous en train d'être pris en compte (80% fini ITO Map n'affiche
pas encore les derniers ajouts).

J'ai également profité des radars pour ajouter les limitations de vitesse
dans leur environnement proche.

Pour finir voici quelques principaux axes qui sont mis à jour et les villes
ayant quelques axes mis à jour :

   - A 75 = A 750 (Béziers - Montpellier) ;
   - A 9 (Narbonne - Montpellier) ;
   - A 61 (Narbonne - Castelnaudary) ;
   - D 986 (Montpellier - St Martin de Londre) ;
   - D 610 = N 106 (Montpellier - Alès - La Grande Combes) ;
   - D 906 (hauteurs de Alès et St Ambroix) ;
   - D 6 = N 86 = D 994 (Alès - Bagnol s/ Cèze - Bollène) ;
   - N 7 (Bollène - Montélimar - Portes les Valences) ;
   - D 11 = D 5 (Béziers - Carcassonne) ;
   - D 6113 (Narbonne - Lézignan - Carcassonne) ;
   - D 6009 (Narbonne - Perpignan) ;
   - D 612 (Béziers - Sète) ;
   - D 614 (Argelès s/ Mer - Perpignan)
   - D 627 = D 6009 = D 611 (Leucate - Sigean - Durban Corbières) ;
   - D 611 = D 606 (Durban Corbières - Lézignan) ;
   - Partie Est du département de l'Aude et Narbonne (40 % finalisé)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr intégration des icones ou layers

2013-05-20 Thread Pierre-Alain Dorange

Ista Pouss ista...@gmail.com wrote:

 [...]
 Je pense que le substrat administratif est (malheureusement) un point dur
 des conceptions françaises, et qu'il peut constituer la base du rendu
 générique.

En dehors de la Franceafrique (qui me fait aussi frémir), quand je lis
ça je suis aussi très désapointé... Comme quoi...

mais on entre là dans des considérations politiques qu'il vaudrait
mieux ne pas développer. Je t'enjoins donc a ne pas en rajouter sur ce
sujet qui semble de décevoir.

Tu peux penser ce que tu veux (heureusement), mais la notion de
services publics est (ou a longtemps été) une des matrices de la
société française, c'est donc normal que ça se voit sur la cartographie,
c'est très structurant.

-- 
Pierre-Alain Dorange
OSM experiences : http://www.leretourdelautruche.com/map/


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique

Merci je vais utiliser le paved/unpaved c'est un bon début.

Pour l'accès, j'étais en saison sèche mais je suppose que cela concerne les
poids lourds. A moins qu'il y ai un droit de passage pour ces véhicules.
J'imagine mal l'accès principal fermé aux véhicule léger.

Le 20 mai 2013 12:53, Eric SIBERT courr...@eric.sibert.fr a écrit :

Cela peut induire en erreur quand à la praticabilité de ces axes. Pouvez
m'indiquer les tags que vous utilisez pour l'Afrique ?

Ce que j'utilise pour Madagascar :

http://wiki.openstreetmap.org/**wiki/FR:WikiProject_**
Madagascar#.C3.89tat_de_**surfacehttp://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#.C3.89tat_de_surface

Je n'ai pas vérifier si c'était en accord avec HDM.

Je pensai
indiquer le type de surface (sable, latérite, roche, piste aménagée et
entretenue) mais vue du ciel je serait approximatif.

Tu peux toujours commencer par paved/unpaved.

Pour l'avoir emprunter en 2010, l'axe primary menant à Manantali est en
latérite (piste) avec quelques grosse excavation. L'accès est réglementé
par des barrières de pluie pendant la saison humide.

seasonal=yes

access:conditional=no @ Dec-Apr : Cette piste est habituellement fermée de
décembre à avril (ou ouverte de mai à novembre).

Éric

__**_
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique ;-)

Je vous mets un smiley dans le titre vu que certains ont foncé droit 
dans le panneau ;-)


Je précise aussi que je ne fais pas dans l'humanitaire. C'est juste 
qu'on travaille sur les mêmes terrains alors j'essaie de mutualiser les 
efforts de réalisation de carte. Je n'ai pas non plus proposé de mettre 
des logos Areva/Total un peu partout :-)



Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique


Pour l'accès, j'étais en saison sèche


Un peu pareil pour moi.

 mais je suppose que cela concerne

les poids lourds. A moins qu'il y ai un droit de passage pour ces
véhicules. J'imagine mal l'accès principal fermé aux véhicule léger.


Si, si, il y a des trucs impraticables pour tout le monde ou presque. 
Style ça passe juste en quad/charrette à zébu avec 2 jours pour faire 50 km.


Après, on doit pouvoir coder des restrictions spécifiques avec 
conditional restrictions:

http://wiki.openstreetmap.org/wiki/Conditional_restrictions

Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr intégration des icones ou layers

2013-05-20 Thread ZIMMY

Je suis assez troublé par l'expression qui consiste à dire que valoriser les
informations sur la cartographie permettant de mieux traiter le handicap est
une mode.

Afficher les places handicapés est pour moi aussi important que mettre en
évidence les stationnements camping-car (mode touristique?) que les
stationnements autocars (mode transports?).
Je pense que la capacité à représenter le réel n'est pas une mode mais une
finesse de description qui se veut objective.

Il y a déjà eu des débat interminables sur ceux qui contestaient le fait de
mettre les fastfood de type MacDo ... pour moi ce qui est important c'est
l'effet levier.

Aujourd'hui, il y a un vide : seul OpenStreetMap est capable de lever une
exertise à l'échelle mondiale de façon aussi fine. Saisissons cette occasion
pour étonner, intriguer et du coup susciter le désir d'une appropriation.

Monter en gamme et améliorer nos expertises est plus qu'une mode un soucis
de démarche qualité.
En témoignent les nombreux articles publiés ces derniers temps mettant enfin
en lumière le côté laboratoire d'OSM.

Ista Pouss wrote
Le 19 mai 2013 17:13, Christian Quest lt;

cquest@

gt; a écrit :

Le plus complexe est en fait de trouver un équilibre valable quelle
que soit la zone, car par endroit on a une très forte densité d'info,
et donc besoin de repousser au zoom suivant l'affichage de certains
objets, alors qu'à d'autre endroits il faudrait les faire apparaitre
un peu plus tôt pour ne pas avoir un rendu trop vide.

Ça c'est le plus complexe d'un point de vue technique et design, ce qui
est
déjà bien.

Mais un rendu français donne réponse à une recherche de français. Donc il
suppose une réflexion sur ce qu'attendent les français. Comme c'est toi
qui
fait ça c'est toi qui voit bien sûr, aussi je peux me tromper.

À lire cette liste on peut se faire une idée, probablement fausse, mais
bon
: un truc très orienté administratif (alors que les français passent leur
temps à gueuler contre l'administration), matiné de quelques
considérations
écologiques, avec les logos des entreprises françaises, et répondant aux
modes porteuses des appels d'offres, tels l' handicap.

Et même la françafrique qui repointe le bout de son nez. (quand j'ai vu
ça de la part d'humanitaires j'ai sauté au plafond)

Ainsi va la France...

Je pense que le substrat administratif est (malheureusement) un point dur
des conceptions françaises, et qu'il peut constituer la base du rendu
générique. Les logos des entreprises françaises aussi, c'est aussi un
point dur, ce n'est pas si mal. Mais attention que les logos changent.

On peut discuter sur les considérations écologiques ; il y a quelque chose
de profond dans la société française là dessus je pense, mais j'avoue ne
pas trop savoir quoi. Le nucléaïre est une valeur écologique pour beaucoup
de français... à vérifier.

Par contre je crois qu'il vaudrait mieux rejeter les modes porteuse du
business sur des rendus vectoriels, et donc tout ce qui concerne
l'handicap, par exemple (en ce moment). Elles sont vraiment trop floues et
ponctuelles, et la plupart du temps complètement en dehors du sujet
qu'elles prétendent traiter.

Et, quand à la françafrique... on attendra que les humanitaires se
débarrassent eux mêmes de cette notion, et ensuite on y réfléchira aussi,
c'est mon opinion.

Hugh (surtout que je fais rien). (merci Christian)

--
Les dérives de rue :
Profession émotion lt;http://drivrsdu.fr/profession-emotion/gt;

___
Talk-fr mailing list

Talk-fr@

http://lists.openstreetmap.org/listinfo/talk-fr

-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context:
http://gis.19327.n5.nabble.com/tile-osm-fr-integration-des-icones-ou-layers-tp5761783p5761876.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu françafrique

Ha mince autant que ça ? Je comprend mieux pourquoi l'armée française
mettait 24H pour faire 70 km dans la région de Gao. C'est à savoir pour mon
prochain séjour là bas. A chaque fois j'y fait en poids lourd, ça risque
d'être un vaste champ de boue rempli de moustique.


Le 20 mai 2013 13:36, Eric SIBERT courr...@eric.sibert.fr a écrit :

 Pour l'accès, j'étais en saison sèche


 Un peu pareil pour moi.


  mais je suppose que cela concerne

 les poids lourds. A moins qu'il y ai un droit de passage pour ces
 véhicules. J'imagine mal l'accès principal fermé aux véhicule léger.


 Si, si, il y a des trucs impraticables pour tout le monde ou presque.
 Style ça passe juste en quad/charrette à zébu avec 2 jours pour faire 50 km.

 Après, on doit pouvoir coder des restrictions spécifiques avec
 conditional restrictions:
 http://wiki.openstreetmap.org/**wiki/Conditional_restrictionshttp://wiki.openstreetmap.org/wiki/Conditional_restrictions


 Éric

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cadastre: divergence entre différentes sources

Par expérience, Geoportail est moins à jour que cadastre.gouv.fr.
J'avais par exemple toujours un cadastre raster pour ma commune alors
qu'il était disponible en vectoriel depuis déjà quelques temps.

Geoportail fait aussi une conflation pour faire coincider les
cadastres là où il ne coincident pas...


Le 20 mai 2013 11:19, RainerU ra...@sfr.fr a écrit :
 Bonjour,

 Je viens de constater que le découpage des parcelles cadastrales n'est pas le
 même sur cadastre.gouv.fr que sur le géoportail IGN, par exemple ici [1]. 
 Est-ce
 que ça veut dire que les données sur le géoporatil sont plus à jour ou 
 qu'elles
 ne sont pas correctes ?

 Rainer

 [1]
 http://www.openstreetmap.org/?lat=42.6936985amp;lon=2.8798795amp;zoom=18amp;layers=Mamp;mlat=42.69384amp;mlon=2.87958


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm déchèteries

2013-05-20 Thread Teuxe

À ce propos, le terme français approprié pour ces lieux est « déchèterie 
». Le mot « déchetterie » étant une marque déposée par l'Ademe (je me 
demande quel est l'intérêt de déposer une telle marque nommée), je pense 
qu'il est préférable d'éviter son usage dans OSM.

http://fr.wikipedia.org/wiki/D%C3%A9ch%C3%A8terie#cite_note-1

Teuxe

Le 19/05/2013 12:05, ZIMMY a écrit :

Au risque d'être redondant : il me semble important d'agrandir les pictos,
car il est tellement soigné dans son dessin qu'il en devient quasi illisible
dans tile.openstreetmap.fr

Dans son affichage réel
http://optigede.ademe.fr/sites/default/files/fichiers/LogoDecheterie.jpg
Une chose est importante c'est que ce pictogramme est normalement mis sur un
panneau d'entrée de déchetterie donc avec une taille qui est au moins de
50cm.

Quelques exemples
gravats
http://www.google.fr/imgres?sa=Xbiw=1241bih=606tbm=ischtbnid=T6oSORfELRlmTM:imgrefurl=http://www.ville-bagneresdebigorre.fr/pages/page.php%3Fnom%3Ddecheterie.htmldocid=BWS6sUb915cvvMimgurl=http://www.ville-bagneresdebigorre.fr/pages/services%252520techniques/dechetterie.JPGw=1136h=856ei=SKOYUZjwH5OFhQfo-IGACgzoom=1iact=hcvpx=944vpy=216dur=619hovh=196hovw=260tx=128ty=72page=1tbnh=142tbnw=188start=0ndsp=18ved=1t:429,r:5,s:0,i:178
entrée de déchetterie
http://www.sorgues-du-comtat.com/images/stories/environnement_om/dechetterie_2.jpg


A défaut d'agrandir le picto, pour l'instant je trouve le symbole universel
de reyclage plus compréhensible en terme de lisibilité.



-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/tile-osm-decheteries-tp5761612p5761760.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm déchèteries

2013-05-20 Thread Eric

Bonjour,

+1, j'allais justement écrire la même chose : peut être que dans les
derniers niveaux de zoom, il serait possible de doubler H et L des
icônes (donc un x4 du coup). Au vu de la place dispo à ces niveaux de
zoom, ça devrait garder toute sa lisibilité. Je ne sais si c'est
simple par contre 


Le 19 mai 2013 12:05, ZIMMY jeanlouis.zimmerm...@laposte.net a écrit :

 Au risque d'être redondant : il me semble important d'agrandir les pictos,
 car il est tellement soigné dans son dessin qu'il en devient quasi illisible
 dans tile.openstreetmap.fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu pour touristes

2013-05-20 Thread kimaidou

Bonjour

Pour répondre bièvement à Christian, dans Lizpoi, j'ai une table dans
laquelle j'exporte des tables planet_osm_point, polygone et line les
éléments d'OSM qui contiennent des infos sur les tags que je suis. Je ne
prends que le centroide pour les polygones et lignes (oui je sais, un
centroid de ligne...)

Ensuite, je stocke les arbres dans une table, avec hiérarchie, et les
correspondances entre 1 item de l'arbre et des tags OSM dans une autre
table. Une requête dynamique permet de récupérer assez rapidement les
objets OSM qui correspondent.

Donc en gros, 1 table avec les objets OSM intéressants, 1 table avec la
description des arbres, 1 table pour faire la correspondance entre 1 item
de l'arbre et des tags OSM.

On peut gérer les cas où plusieurs associations tag/valeur permettent de
décrire un objet, par exemple pour les bornes à incendie
(amenity=fire_hydrant OU emergency=fire_hydrant).


Si plusieurs cases sont cochées dans un arbre Lizpoi, c'est à chaque fois
une seule requête qui est faite au serveur (lorsqu'on zoome ou qu'on se
déplace), et non une requête par case cochée.

On pourrait faire une sorte de système de drivers pour permettre de gérer
plusieurs sources. Par exemple un driver osm2pgsql = le fonctionnement
actuel. Qui permet de ne pas charger les serveurs de la fondation ou de
l'association car s'appuyant sur une bdd locale. On pourrait avoir un
driver overpass qui lancerait les requêtes à l'api de l'overpass, et
ainsi avoir un lizpoi plus portable car ne nécessitant pas de bdd locale.

Au sujet du clustering, nous n'avons pas fait ce choix car comme indiqué,
il faut de toute façon que le code Javascript lancé sur le navigateur fasse
le calcul sur l'ensemble des éléments avant de faire le regroupement, donc
cela n'allège en rien le code. Par contre, cela peut en effet apporter un
confort pour l'utilisateur. Mais il faut bien choisir de regrouper des
éléments semblables, sinon ce n'est pas pertinent (par exemple on
clusterise tous les shop ensemble). Si on commence à mélanger des
torchons et des serviettes, on perd le côté thématique.
Ce serait intéressant de faire du clustering côté serveur. On a pas encore
eu/pris le temps de regarder.

Et je disais plus haut pour répondre brièvement. C'est loupé :)

Michael


Le 19 mai 2013 15:35, Marc Sibert m...@sibert.fr a écrit :

  Le 17/05/2013 10:33, Christian Quest a écrit :

 Et le clustering ?

 leaflet a un plugin de clustering qui semble assez efficace.
 openlayers n'a pas ça ?

 Exemple: http://csvmap.logisima.com/carte/c5badf4d-4f6b-434d-b42d-0a3878c82cec



 Il faudrait peut être daller les requêtes vers l'overpass quand on
 dézoome beaucoup, couplé au clustering ça permettrait d'afficher
 progressivement le centre de la carte puis en différé le reste autour
 ce qui resterai acceptable pour l'expérience utilisateur. Juste une
 idée en mode yaka ;)


  Il n'y a pas de question bête... heu tant qu'elle n'est pas posée... ;-)

 Ben le clustering client side nécessite bien de tout charger avant de
 regrouper les noeuds. Expérience faite personnellement avec OpenLayers. Il
 n'y a pas d'autre choix que de faire des regroupement server side *avant*
 l'envoi des données au navigateur et, pour éviter la charge API, faire un
 peu de cache de requêtes.

 Tout ça nécessite donc de limiter par programme le nombre de types de POI
 dans la requete ou de faire un pré-traitement côté serveur en avance.
 Une idée comme ça en passant... faire des couches vectorielles variables
 suivant le niveau de zoom :

- sur vue nationale : nombre de POI par région : afficher des valeurs
dans des polygones régions ;
- sur vue régionale : la même chose avec les départements
- sur vue locales : mettre le détail des POI.


 Mes 0.02 € (limite HS)

 --
 Marc Sibertmailto:m...@sibert.fr m...@sibert.fr


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.osm.fr intégration des icones ou layers

2013-05-20 Thread Ista Pouss

Bon alors je réponds à Pierre-Alain Dorange et à ZIMMY.

Pour ma remarque sur le substrat administratif malheureusement, je
voulais dire par rapport à la géographie ; je veux dire que nous avons
tendance à voir les choses autour de nous par le biais des classifications
administratives, à les considérer comme concrètes.

Exemple les départements : on discute pour savoir leur utilité, mais s'il
n'y a pas les départements sur une carte de la france, ce n'est pas une
carte de la france, croit-on.

C'est vrai que j'aimerais bien qu'on puisse voir les choses autrement, mais
je l'admets et je dis +1 pour le mettre au rendu générique, y compris des
services tels anpe, sec soc, police, pompiers, etc. (ce qui est déjà fait,
en plus, je crois) (donc c'est une bonne proposition)

Pour ma remarque sur la mode du handicap, moi je dis que c'est une mode,
mais on peut très bien dire autre chose évidemment. (sauf peut être que je
traite les handicapés comme des restos mac donald, mais j'imagine que c'est
dans le feu de l'argumentation).

Je dis que c'est une mode, parce que j'en vois de plus en plus dans les
publicités, pour valoriser des produits ou une action municipale ; un truc
est considéré bon au seul motif qu'il est compatible handicapé. J'imagine
que les publicitaires et décideurs ont fait des études d'opinion qui ont
montré que cette cause était porteuse ?

Et de toutes façons je ne suis même pas contre la mode. Je dis qu'il vaut
mieux la mettre sur les niveaux rendu vectoriel.

Le rendu vectoriel - dont personne n'a encore dit qu'il existait, mais je
suppose qu'à force d'en parler ce sera le cas ? - n'empêche pas de montrer
la réalité, ni la force de osm.

Cordialement.




Le 20 mai 2013 13:52, ZIMMY jeanlouis.zimmerm...@laposte.net a écrit :

 Je suis assez troublé par l'expression qui consiste à dire que valoriser
 les
 informations sur la cartographie permettant de mieux traiter le handicap
 est
 une mode.

 Afficher les places handicapés est pour moi aussi important que mettre en
 évidence les stationnements camping-car (mode touristique?) que les
 stationnements autocars (mode transports?).
 Je pense que la capacité à représenter le réel n'est pas une mode mais une
 finesse de description qui se veut objective.

 Il y a déjà eu des débat interminables sur ceux qui contestaient le fait de
 mettre les fastfood de type MacDo ... pour moi ce qui est important c'est
 l'effet levier.

 Aujourd'hui, il y a un vide : seul OpenStreetMap est capable de lever une
 exertise à l'échelle mondiale de façon aussi fine. Saisissons cette
 occasion
 pour étonner, intriguer et du coup susciter le désir d'une appropriation.

 Monter en gamme et améliorer nos expertises est plus qu'une mode un soucis
 de démarche qualité.
 En témoignent les nombreux articles publiés ces derniers temps mettant
 enfin
 en lumière le côté laboratoire d'OSM.



 Ista Pouss wrote
  Le 19 mai 2013 17:13, Christian Quest lt;

  cquest@

  gt; a écrit :
 
  Le plus complexe est en fait de trouver un équilibre valable quelle
  que soit la zone, car par endroit on a une très forte densité d'info,
  et donc besoin de repousser au zoom suivant l'affichage de certains
  objets, alors qu'à d'autre endroits il faudrait les faire apparaitre
  un peu plus tôt pour ne pas avoir un rendu trop vide.
 
 
  Ça c'est le plus complexe d'un point de vue technique et design, ce qui
  est
  déjà bien.
 
  Mais un rendu français donne réponse à une recherche de français. Donc il
  suppose une réflexion sur ce qu'attendent les français. Comme c'est toi
  qui
  fait ça c'est toi qui voit bien sûr, aussi je peux me tromper.
 
  À lire cette liste on peut se faire une idée, probablement fausse, mais
  bon
  : un truc très orienté administratif (alors que les français passent leur
  temps à gueuler contre l'administration), matiné de quelques
  considérations
  écologiques, avec les logos des entreprises françaises, et répondant aux
  modes porteuses des appels d'offres, tels l' handicap.
 
  Et même la françafrique qui repointe le bout de son nez. (quand j'ai vu
  ça de la part d'humanitaires j'ai sauté au plafond)
 
  Ainsi va la France...
 
  Je pense que le substrat administratif est (malheureusement) un point dur
  des conceptions françaises, et qu'il peut constituer la base du rendu
  générique. Les logos des entreprises françaises aussi, c'est aussi un
  point dur, ce n'est pas si mal. Mais attention que les logos changent.
 
  On peut discuter sur les considérations écologiques ; il y a quelque
 chose
  de profond dans la société française là dessus je pense, mais j'avoue ne
  pas trop savoir quoi. Le nucléaïre est une valeur écologique pour
 beaucoup
  de français... à vérifier.
 
  Par contre je crois qu'il vaudrait mieux rejeter les modes porteuse du
  business sur des rendus vectoriels, et donc tout ce qui concerne
  l'handicap, par exemple (en ce moment). Elles sont vraiment trop floues
 et
  ponctuelles, et la plupart du temps complètement en dehors du sujet

Re: [OSM-talk-fr] Cadastre: divergence entre différentes sources

2013-05-20 Thread Landry Breuil

2013/5/20 Christian Quest cqu...@openstreetmap.fr

 Par expérience, Geoportail est moins à jour que cadastre.gouv.fr.
 J'avais par exemple toujours un cadastre raster pour ma commune alors
 qu'il était disponible en vectoriel depuis déjà quelques temps.

 Geoportail fait aussi une conflation pour faire coincider les
 cadastres là où il ne coincident pas...


 Le 20 mai 2013 11:19, RainerU ra...@sfr.fr a écrit :
  Bonjour,
 
  Je viens de constater que le découpage des parcelles cadastrales n'est
 pas le
  même sur cadastre.gouv.fr que sur le géoportail IGN, par exemple ici
 [1]. Est-ce
  que ça veut dire que les données sur le géoporatil sont plus à jour ou
 qu'elles
  ne sont pas correctes ?


Plus exactement, cadastre.gouv;fr montre une donnée qui s'appelle le PCI
vecteur et qui correspond au cadastre officiel maintenu par la DGFiP. Le
geoportail montre la BD Parcellaire, qui est un produit IGN crée a partir
de la déformation et de l'assemblage du PCI  vecteur pour faire un produit
homogène sur la france. Le PCI vecteur est souvent mal géolocalisé, et
n'est pas du tout homogène entre les communes (ie, ca ne colle pas si on
essaie de mettre coté a coté 2 sections cadastrales de 2 communes voisines).

Landry
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [contact] [Remarque, suggestion à propos de ce site] vos cartes

Ces formats de fichiers sont-ils documentés quelque part ?

Si ils le sont, il suffit d'écrire un convertisseur, si ils ne le sont
pas, il va falloir faire du reverse engineering pour déterminer leur
structure avant de pouvoir écrire un convertisseur. C'est ce qui a été
fait pour le format utilisé par Garmin, mais à ma connaissance c'est
le seul format où quelqu'un s'est donné la peine de faire cet énorme
travail.

Pour iGO, j'ai cherché (rapidement) et rien trouvé.


Le 20 mai 2013 16:47,  mic...@bersio.com a écrit :
 michel bersio (mic...@bersio.com) a envoyé un message en utilisant le
 formulaire de contact suivant : http://openstreetmap.fr/contact.

 bonjour,pourquoi ne trove t -on pas des cartes au fichier map de
 ozi,compegps
 ,ou fbl de igo quand on saitque igo est le logiciel le plus utilisé sur les
 gps de nouvelle génération et sur les tablettes
 cordialement
 michel


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes

2013-05-20 Thread Cyrille Giquello

Salut,

Cette données de population n'est elle pas utilisée pour le rendu ? Pour
savoir quelles villes écrire sur la carte en fonction du zoom ?



Le 3 janvier 2013 23:12, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 3 janvier 2013 16:43, Vincent de Chateau-Thierry v...@laposte.net a
 écrit :
  Maintenant, la cible, c'est, plutôt qu'à la main, le passage, au moins
 une fois l'an,
  d'un bot qui ajouterait ou mettrait à jour le tag population, sur la foi
 des résultats de
  recensement publiés par l'INSEE. Une fois cette mécanique en place, il
 n'y aura plus de
  valeur ajoutée à faire ça à la main. Et on s'économisera :-)

 Cela fait partie des choses que l'INSEE envisage de faire EUX MEME :)

 Maintenir à jour dans OSM les informations qu'il produisent. Cela fait
 partie des discussions que j'ai eu le mois dernier lors d'une première
 réunion informelle.

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr




-- 
Cyrille.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Carrément HS] Les Jojos

2013-05-20 Thread Pieren

2013/5/19 Art Penteur art.pent...@gmail.com:

 Pouvez-vous envisager un Jo d'ici et
 Jo d'ailleurs ? Ou bien Jo du sud et Jo du nord ?

Si seulement il venait de la ville d'Alton:
http://www.openstreetmap.org/?lat=38.89051lon=-90.1827zoom=17layers=M

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes