[Talk-br] [Cocar] Contribuintes para cidades do RJ no OSM

Quinta Dezembro 19 19:55:06 UTC 2013

"No tocante ao georeferenciamento da imagem do Bing precisamos
primeiro validar esse georeferenciamento na área que iremos trabalhar
para depois sim, aplicar tolerância lateral."

Concordo totalmente, e a comunidade recomenda isso também,
especialmente para mapeamento no interior. Mas mesmo sem validação,
pode ficar tranquilo que em todas as maiores cidades brasileiras a
imagem está suficientemente alinhada.

"Tem certeza disso? Onde está escrito? Lembro que estamos nos
referindo a área de quadriculas empregadas em imagens satélites."

Isso é fruto da minha experiência com o Bing até o momento.

"Não quero criticar o trabalho do pessoal do Bing, Google e outros,
mas em mensagem anterior já apresentei distorção de quadricula."

Por incrível que pareça, essa quadrícula não está tão mal
georreferenciada assim. Nesse mesmo caso que você citou, em todos os
pontos em que uma via se conecta de uma quadrícula para outra (na
verdade, de uma foto para outra, elas não caem exatamente na borda das
quadrículas), o erro máximo que eu consegui detectar visualmente foi
de um pouco mais de 6 metros. Procure pelas conexões entre as vias (a
maioria estradas de terra) um pouco mais ao norte e um pouco mais ao
sul do lago.

Então, existe um pouco de erro nessa área? Existe. Quão significativo
ele é? Não tanto a ponto de se cobrar o georreferenciamento ou um
survey da área, seria mais importante ter um mapeamento prévio feito o
quanto antes possível, e a forma mais rápida seria desenhar sobre as
imagens. Mas dá pra georreferenciar ou mapear em campo? Claro, é o
ideal! Mas demora mais tempo. E existe distorção? Pouquíssima, e bem
suave e uniforme ao longo de cada foto. Mas em relação à precisão
típica de uma carta náutica? Está pior, sem dúvida, mas não é
descartável. O pior mesmo é quando o Bing não tem uma imagem com
resolução suficiente para se distinguir onde estão as vias (daí apenas
uma inspeção em campo resolve, e nesse caso é necessário fazer como
você indica, mapeando várias vezes), mas não é esse o caso aqui.

O lago parece cortado porque as duas fotos foram tiradas em momentos
diferentes e porque o lago é sazonal. Veja o mesmo no Google (basta
procurar no Google Maps por "-5.5505 -40.7334"). Poucas pessoas
sabem/se preocupam com isso, mas o contorno da separação terra/água
idealmente deve ser a média de vários contornos obtidos ao longo dos
últimos 19 anos (li esta "regra" num fórum francês uns tempos atrás).
No caso de um lago sazonal, a área que às vezes é molhada e às vezes é
seca pode ser demarcada com a tag natural=wetland. Mas esse nível de
preociosismo dificilmente poderia ser esperado por um colaborador
"eventual" do OSM, cujas prioridades/preocupações quase sempre são
outras. Porém, fontes oficiais como o IBGE podem já ter calculado o
contorno seguindo alguma regra parecida, e por isso é importantíssimo
colocar a tag "source" nos elementos importados dessas fontes
oficiais.

Como rodovias não são sazonais, o mesmo problema não as afeta nesse
caso, mesmo as fotos tendo idades diferentes e tendo uma grande
descontinuidade (porém não desalinhada) mais ao sul. Apesar da
descotinuidade, em vários pontos aqui seria aceitável aproximar o
contorno real de muitas das vias simplesmente com linhas retas - ao
menos temporariamente, até que uma foto melhor esteja disponível.
Claro, se você fizer um survey do local com equipamento especializado,
alcançará um resultado melhor, mas não "muito" melhor, e essa área
(por ser afastada) não é tão urgente pro usuário médio, só para uns
poucos que estariam passando por ela.

2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
> Ferramentas de validação de georreferenciamento?
> Em que pese que estava me referindo a validação da tolerância dos 3m,
> georeferenciamento de um ponto é validado sim.
> Não me vem a cabeça a quantidade de pontos aeronáuticos por mim validados em
> vôo para que pudessem ser empregados nas cartas aeronáuticas. Lembro que
> antes já citei que fui piloto inspetor do Sistema de Controle do Espaço
> Aéreo Brasileiro. Para validação das aerovias e Waypoints empregávamos a
> aeronave laboratório do Geiv equipada com todos os equipamentos necessário
> as validações das informações no mapa desenvolvidas por cartógrafos do
> Instituto de Cartografia Aeronáutica.
> No tocante ao georeferenciamento da imagem do Bing precisamos primeiro
> validar esse georeferenciamento na área que iremos trabalhar para depois
> sim, aplicar tolerância lateral.
>
> A curvatura da terra é pouquíssimo significativa dentro de uma mesma
> quadrícula com um nível suficiente de aproximação (por exemplo, num nível em
> que se visualiza uma cidade inteira). E mesmo assim, o processo de
> ortorretificação do Bing compensa isso.
> Tem certeza disso? Onde está escrito? Lembro que estamos nos referindo a
> área de quadriculas empregadas em imagens satélites.
>
> Entre quadrículas adjacentes também não há esse problema: o Bing faz um bom
> trabalho em fazer as imagens se corresponderem.
> Não quero criticar o trabalho do pessoal do Bing, Google e outros, mas em
> mensagem anterior já apresentei distorção de quadricula.
> Veja novamente em
> http://www.openstreetmap.org/edit#map=16/-5.5505/-40.7334
> Nesse local da lagoa vá navegando para sul e vai acompanhar a abertura da
> quadricula
> Voltando a citar ter eu encontrado eu muitos erros desse tipo na cobertura
> do Brasil.
>
>
>
> From: Fernando Trebien
> Sent: Thursday, December 19, 2013 3:55 PM
> To: Cooperativa de Cartografia Digital Livre
> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>
> "Uma regra eficiente e eficaz deve e pode ser aplicada para todo o Brasil
> desde que se tenha ferramentas de validação."
>
> Ferramentas de validação de georreferenciamento?
>
> "Deveria, mas na pratica não é devido a curvatura da terra.
> Aprendi muito sobre isso quando fui apresentado a conceitos da
> Aerofotogrametria já que realizei alguns voos em suporte a ela. Também tive
> de aprender sobre o efeito da curvatura da terra na elaboração de vídeos
> mapas para emprego em radar de navegação aérea.
> Além da influencia da curvatura da terra devemos considerar os erros de
> união das quadriculas na imagem.
> Decididamente o georeferenciamento não é uniforme."
>
> A curvatura da terra é pouquíssimo significativa dentro de uma mesma
> quadrícula com um nível suficiente de aproximação (por exemplo, num nível em
> que se visualiza uma cidade inteira). E mesmo assim, o processo de
> ortorretificação do Bing compensa isso.
>
> O que acho mais impressionante é que ela compensa muito bem as distorções do
> relevo também, mesmo que as fotos sejam tiradas lateralmente, tanto que
> nunca notei uma distorção significativa (nada que "salte aos olhos"). Diria
> com certeza quase absoluta que, na mesma quadrícula, essa distorção deve
> ficar dentro de uns poucos centímetros. Ao longo da quadrícula, se houver
> alguma distorção, ela varia tão suavemente que nunca percebi.
>
> Entre quadrículas adjacentes também não há esse problema: o Bing faz um bom
> trabalho em fazer as imagens se corresponderem. Na borda de duas
> quadrículas, o erro máximo que eu já encontrei é inferior à largura de uma
> calçada, e isso é visível claramente na imagem.
>
> Sendo assim, uma área tão grande quanto Porto Alegre poderia ser
> inteiramente mapeada sobre o Bing e por fim receber um único deslocamento
> uniforme (igual para todos os pontos) para corrigir o erro de
> georreferenciamento, com possíveis distorções sendo pequenas demais para
> serem relevantes. Isso foi feito em praticamente todas as grandes avenidas
> daqui (daquelas que têm as mãos separadas). O resultado (que eu uso
> diariamente para navegação) é tão bom que nunca meu GPS identificou que eu
> estava na pista de sentido oposto (e ele me mostra tanto a minha posição
> projetada na pista quanto a minha posição real). Assim, a prática me garante
> que essas distorções (que não foram georreferenciadas por mim) estão bem
> abaixo dos 6m em boa parte da imagem.
>
> O Google Maps certamente faz melhor, mas os parâmetros do Bing já são muito
> bons por si só (novamente, varia por localidade, mas nas grandes cidades
> está ok). Em relação ao Google, algo que notei no Bing é que muitas imagens
> são tiradas com um certo ângulo lateral (dá pra ver as paredes dos
> edifícios). O que quer dizer que, ao mapear um edifício, depois de desenhar
> sobre o telhado, eu movo o polígono para que este coincida com a base do
> edifício. Mas nem todos os usuários sabem disso. Contudo, muitos mapeiam a
> parte superior do edifício sem cuidado com esses detalhes (que nesse caso,
> seria relativamente óbvio). O que temos são colaboradores com os mais
> variados graus de compreensão de tecnologia de mapeamento, e é importante
> ter paciência com eles.
>
>
> 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>
>>
>> Calma. Os 3m que eu respeito não incluem os erros de georeferenciamento
>> das imagens. O erro total das coisas que eu mapeio é bem superior a isso
>> (deve estar em torno de 12m aqui em porto alegre).
>> Aí está o conceito de eficiência x eficácia que citei anteriormente.
>> Aplicando tolerância de 3m sobre uma referencia errada, poderemos,
>> dependendo do lado aplicado, estar agregando mais 3m ao erro existente.
>> Estaremos sendo eficientes em manter em 3 metros um traçado (eficiente)
>> tendo como referencia outro traçado errado (ineficaz).
>> Lembra o exemplo que dei e veja se não é bem similar a isso:
>> “um piloto faz excelente pouso (eficiente), mas no aeroporto errado
>> (ineficaz)”
>>
>> O erro total das coisas que eu mapeio é bem superior a isso (deve estar em
>> torno de 12m aqui em porto alegre).
>> Nesse aspecto acredito que ganho de você porque aqui no Rio tenho mapeado
>> com erros bem menores porque a imagem satélite aqui, na minha opinião, está
>> perfeita.
>> Mas não devemos levar esses locais em consideração porque não estamos
>> mapeando só neles. Devemos ter uma noção geral, de todo o Brasil e isso lhe
>> garanto que tenho pelo fato de emprego de posicionamento de pontos de alerta
>> para o MapaRadar já citado por mim anteriormente.
>> Uma regra eficiente e eficaz deve e pode ser aplicada para todo o Brasil
>> desde que se tenha ferramentas de validação. Em não existindo considero essa
>> regra ineficaz.
>>
>> Pense que o erro total inclui: erro de georeferenciamento + erro de
>> mapeamento. Se conseguíssemos eliminar o erro de georeferenciamento, o ideal
>> é que erro restante (desvios em relação ao eixo na imagem, desvios
>> resultantes da simplificação, etc.) ficasse próximo de 3m.
>> Em se eliminando erro de georeferenciamento eu sou mais perfeccionista e
>> iria buscar empregar valor inferior a esse dos 3m. Espero estar vivo ainda
>> para ver esse dia chegar.
>>
>> Isso é porque o erro de georefereciamento geralmente é uniforme
>> Deveria, mas na pratica não é devido a curvatura da terra.
>> Aprendi muito sobre isso quando fui apresentado a conceitos da
>> Aerofotogrametria já que realizei alguns voos em suporte a ela. Também tive
>> de aprender sobre o efeito da curvatura da terra na elaboração de vídeos
>> mapas para emprego em radar de navegação aérea.
>> Além da influencia da curvatura da terra devemos considerar os erros de
>> união das quadriculas na imagem.
>> Decididamente o georeferenciamento não é uniforme.
>>
>> Aí entra um detalhe interessante no OSM. Para que os outros saibam que o
>> que está no mapa foi obtido por essa metodologia, você deve se preocupar em
>> colocar a tag "source" nos elementos que você mapear. Se estiver traçando
>> sobre a imagem do Bing, coloque source=Bing (ou não
>> coloque nada e todos entenderão que foi usando o Bing ou outra fonte menos
>> confiável). Se estiver coletando tracklogs, coloque source=survey. Se a
>> fonte for outra (digamos, um mapa de uma prefeitura), coloque source=[nome
>> da prefeitura]. Essa tag serve tanto como informação como para detectar
>> plágio (por exemplo, source=Google é proibido).
>> Gostei dessa informação. Muito util. Eu não sabia.
>> Geralmente  traço via após coleta de tracks, Não imagine o que já rodei no
>> Rio de Janeiro só coletando tracks,
>> Claro que aprendi a técnica de jogar a imagem satélite como background e
>> alinha-la pela média dos tracks.
>> Custei a adquirir essa experiência e no inicio, quando iniciei o
>> desenvolvimento de mapas, muitos erros de alinhamento cometi.
>>
>> Para que tenha i´deia, nesse ultimo final de semana estava eu tão
>> incomodado com a situação de circulação no centro do Rio devido as obras
>> para a copa que decidi pegar o carro e ir lá rodar e levantar tracks para
>> registrar e desenhar as vias inauguradas, interditadas definitivamente e a
>> circulação de um modo geral.
>>
>> Em chegando em casa revisei tudo que vi e editei a região do centro do Rio
>> no OSM mas sem o source= porque não sabia. Depois corrijo lá.
>>
>> -----Mensagem Original-----
>> From: Fernando Trebien
>> Sent: Thursday, December 19, 2013 2:33 PM
>> To: Cooperativa de Cartografia Digital Livre
>> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>>
>> "Se tem você conseguido cumprir essa recomendação dos 3m parabéns! Eu,
>> mesmo com a experiência que detenho em desenvolvimento de mapa, com as
>> ferramentas ora disponíveis, não consigo!"
>>
>> Calma. Os 3m que eu respeito não incluem os erros de
>> georeferenciamento das imagens. O erro total das coisas que eu mapeio
>> é bem superior a isso (deve estar em torno de 12m aqui em porto
>> alegre).
>>
>> Pense que o erro total inclui: erro de georeferenciamento + erro de
>> mapeamento. Se conseguíssemos eliminar o erro de georeferenciamento, o
>> ideal é que erro restante (desvios em relação ao eixo na imagem,
>> desvios resultantes da simplificação, etc.) ficasse próximo de 3m.
>>
>> Isso é porque o erro de georefereciamento geralmente é uniforme: mesma
>> distância e direção para uma área muito grande. Removê-lo consiste em
>> apenas descobrir o deslocamento a ser aplicado e a qual área. Feito
>> isso, basta selecionar todos os pontos e aplicar o deslocamento
>> inverso. Já um erro de mapeamento precisa ser corrigido caso a caso,
>> ponto por ponto, e é muito mais trabalhoso.
>>
>> Se o seu GPS tivesse precisão absoluta, você estaria introduzindo
>> erros por fazer uma amostragem da sua posição a cada 7m. Esse erro
>> sempre existe, independente de quão preciso seja o equipamento. Com o
>> celular que eu uso, o erro fica quase sempre dentro de 8m. O fato de
>> ter AGPS às vezes prejudica essa métrica (chegando a 20m), mas é algo
>> que no fim das contas faz pouca diferença porque, antes de fazer o
>> upload, eu vou invariavelmente ajustar os pontos à imagem ao Bing -
>> que, se estiver mal georeferenciada, pode ser corrigida depois com um
>> simples deslocamento.
>>
>> Certamente, isso se torna mais preocupante nos lugares onde o
>> georeferenciamento do Bing está muito mal, como nesses casos que você
>> cita que chegam a 450 metros. Nesses sim a sua técnica de percorrer
>> várias vezes e calcular uma média é muito mais eficiente E eficaz. O
>> pessoal que mapeia rodovias (e não vias em grandes cidades, onde o
>> Bing é suficiente) usa essa técnica justamente por isso.
>>
>> Aí entra um detalhe interessante no OSM. Para que os outros saibam que
>> o que está no mapa foi obtido por essa metodologia, você deve se
>> preocupar em colocar a tag "source" nos elementos que você mapear. Se
>> estiver traçando sobre a imagem do Bing, coloque source=Bing (ou não
>> coloque nada e todos entenderão que foi usando o Bing ou outra fonte
>> menos confiável). Se estiver coletando tracklogs, coloque
>> source=survey. Se a fonte for outra (digamos, um mapa de uma
>> prefeitura), coloque source=[nome da prefeitura]. Essa tag serve tanto
>> como informação como para detectar plágio (por exemplo, source=Google
>> é proibido).
>>
>> 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
>> > Creio que novamente e em outro assunto eu não consegui me fazer
>> > entender.
>> >
>> > Assim vamos a um exemplo pratico com imagem do BING.
>> >
>> > Observe em http://www.openstreetmap.org/edit#map=15/-5.5482/-40.7387
>> >
>> > A para uma lagoa onde as quadriculas da imagem do BING estão defasadas.
>> >
>> > Com isso acredito que você já possa concluir que uma das quadriculas
>> > adjacentes não está bem georeferenciada.
>> >
>> > Essa situação, por si só, já impede a aplicação de qualquer tolerância
>> > “lateral”, ainda mais de 3m. Nem vou comentar sobre o traçado da estrada
>> > de
>> > terra existente a NW dessa lagoa e constante no mapa OSM.
>> >
>> > Independente disso volto a lembrar que não tem lógica a aplicação de
>> > tolerância “lateral” de 3 onde, por enquanto, só existe como referencia
>> > para
>> > aplicação imagem satélite que você mesmo já citou que contem erros de 6m
>> > ou
>> > mais. Lembro que encontrei erro de 450m.
>> >
>> > Nem nossos GPS automotivos tem essa precisão de 3m e por essa razão que
>> > nos
>> > navegadores gps existem tolerâncias de erros laterais da via desenhada
>> > no
>> > mapa. No Garmin e no iGO é de 50m, nos demais não sei ainda porque não
>> > testei, mas está nos meus planos.
>> >
>> > Me perdoe, mas para mim essa orientação de 3m é eficiente, mas de
>> > impraticável cumprimento em nosso território. Por essa razão que citei
>> > eficiente, mas ineficaz.
>> >
>> > Se tem você conseguido cumprir essa recomendação dos 3m parabéns! Eu,
>> > mesmo
>> > com a experiência que detenho em desenvolvimento de mapa, com as
>> > ferramentas
>> > ora disponíveis, não consigo!
>> >
>> >
>> >
>> > -----Mensagem Original-----
>> > From: Fernando Trebien
>> > Sent: Thursday, December 19, 2013 1:19 PM
>> > To: Cooperativa de Cartografia Digital Livre
>> > Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>> >
>> > "Existindo esse objetivo diria que o OSM  está perseguindo a
>> > eficiência, mas de forma ineficaz."
>> >
>> > Por que seria ineficaz? Tem sido muito eficaz no que eu tenho feito,
>> > no que tem sido feito no Brasil e em vários países do mundo (Alemanha,
>> > Inglaterra, Rússia, e outros próximos desses 3 grandes pólos).
>> >
>> > Se você aproximar a imagem do Bing, você consegue ver as faixas
>> > separando as pistas. Bem, aqui em Porto Alegre e no Rio dá pra ver, em
>> > outros lugares varia com a qualidade da imagem disponível. Ainda
>> > assim, se você mapear ao longo do centro da pista, você sabe que pode
>> > errar dentro de 3m de distância desse centro aproximado, e que não é
>> > muito bom errar muito mais do que isso. (Já vi mapeamentos manuais
>> > muito mal feitos, piores que desenho de criança.)
>> >
>> > Como ficar medindo ponto a ponto é trabalhoso e tedioso, o que eu faço
>> > é o seguinte (onde a via não é simplesmente reta): mapeio a curva com
>> > muito mais pontos que o necessário (seria bem similar a gerar um
>> > tracklog com um intervalo bem curto - acredito que os seus 7m são
>> > suficientes pra grande maioria dos casos), daí aplico o simplificador
>> > (deixo o JOSM decidir pra mim o que cai dentro desse limiar de 3m e
>> > descartar o resto), faço uns últimos ajustes onde for necessário
>> > (evitando inserir novos pontos, apenas movendo os que resultaram da
>> > simplificação), e daí faço o upload pro mapa oficial. Pra vias de
>> > veículos, isso funciona muito bem. Onde há um pouco de trabalho a ser
>> > feito é em vias paralelas (ou vias separadas), onde o melhor é, depois
>> > da simplificação, fazer com que os pontos que o JOSM escolheu fiquem
>> > alinhados em ambos os lados da via - assim:
>> > http://wiki.openstreetmap.org/w/images/d/d7/Paralel_aligned.png
>> >
>> > Agora, sei que algumas pessoas nem usam esse simplificador, mas se
>> > acostumaram com um nível de detalhe similar e o produzem naturalmente
>> > sem pensar muito. Absolutamente ok fazer assim. Usar o simplificador
>> > pra mim é um "sanity check" pra não usar nem pontos de menos, nem
>> > demais. Mas enfim, isso não tem nada a ver com a taxa de coleta ao
>> > produzir um tracklog, que é ao que você se refere com a medida de 7m
>> > (alguns sistemas não usam a distância e sim um intervalo de tempo
>> > entre duas coletas consecutivas).
>> >
>> > 2013/12/19 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
>> >> De certa forma compreendi sua explicação, mas continuo em duvida, em
>> >> especial quando utiliza como referência faixa de pista.
>> >> Estou aqui tentando identificar como um desenvolvedor identifica na
>> >> imagem
>> >> satélite do BING  uma faixa de pista para obter referencia.
>> >> Me perdoe, mas continuo em duvida quanto a praticidade dessa tolerância
>> >> de
>> >> 3m.
>> >>
>> >> Pode ser que em futuro, quando tivermos melhor qualidade e precisão das
>> >> imagens, possamos atender a esse objetivo de tolerância lateral de 3m,
>> >> mas
>> >> por enquanto desconheço ferramenta disponível que permita isso.
>> >>
>> >> Existindo esse objetivo diria que o OSM  está perseguindo a eficiência,
>> >> mas
>> >> de forma ineficaz.
>> >>
>> >> Tenho um jargão sobre isso:
>> >> "Um piloto fazendo excelente pouso (eficiente), mas no aeroporto errado
>> >> (ineficaz).
>> >>
>> >>
>> >> -----Mensagem Original----- From: Fernando Trebien
>> >> Sent: Thursday, December 19, 2013 11:36 AM
>> >>
>> >> To: Cooperativa de Cartografia Digital Livre
>> >> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>> >>
>> >> "Continua você se referindo a precisão dos 3m lateral e ainda não me
>> >> respondeu como extrair essa tolerância."
>> >>
>> >> Na verdade, não existe um "método" oficial. Isso é mais um objetivo a
>> >> ser seguido. No JOSM, você pode calcular distâncias simplesmente
>> >> iniciando o traçado de uma linha e observando a distância total da
>> >> linha na barra de status (na parte de baixo da janela). Mas isso
>> >> geralmente não é necessário, basta lembrar que uma faixa costuma ter
>> >> 3m de largura, então você deve se preocupar que o seu traçado não caia
>> >> a mais de 1 faixa de distância da faixa central. Fora isso, essa
>> >> medida serve mais para justificar a possibilidade de simplificar a via
>> >> usando o JOSM.
>> >>
>> >> Digamos que alguém se preocupou em detalhar muito uma curva e usou
>> >> pontos demais. Por causa desse princípio, qualquer outra pessoa
>> >> poderia simplificar essa curva usando o simplificador do JOSM (ou
>> >> qualquer outro método), mas não além desse limite de 3m em relação ao
>> >> que já estava mapeado (o que significaria tirar detalhe relevante e,
>> >> dependendo de quanto foi retirado, poderia em alguns casos extremos
>> >> até ser visto como uma espécie de "vandalismo").
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > 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)
>
>
>
>
> --
> 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)