Este site http://wiki.osgeo.org/wiki/Brazilian_Coordinate_Reference_Systems afirma que os parâmetros do SAD69 no QGIS / gdal estão errados. Por isso eu recomendo usar as duas possibilidades acima (opção -p no ogr2osm) e decidir visualmente qual alinha melhor com as imagens de satélite (supostamente seria a 1a. opção). Elas têm uma diferença de uns 5 metros, se eu me lembro bem. Usar o ogr2osm para a conversão dispensa o uso do QGIS (ambos usam as mesmas bibliotecas para os cálculos; a qualidade da saída deve ser a mesma).
Um pouco antes recebi uma resposta do Vitor George informando que a projeção é 4618.
Utilizei o org2osm e fez um ajuste bem mais próximo das imagens do Bing. Imaginem um sobrado geminado. A diferença foi de uma casa geminada entre o traçado dos edifícios e imagem. Antes a diferença era um pouco maior que uma quadra.
Neste último canal de youtube que postei o mapeador cita, num dos exemplos sobre NY, que preferiu o alinhamento dos dados da Prefeitura.
Neste caso é preciso saber se o valor mais preciso é mesmo o da prefeitura. Em caso positivo há o risco de gerar erros de vias sobre/sob edifícios em um processo sem a revisão manual.
No caso de NY não sei dizer como trataram este caso.
Relembro que não estou fazendo novas importações enquanto conversamos a respeito.
Esse deslocamento é mais ou menos uniforme ao longo de todo o dataset? Em caso positivo, e se a nossa escolha for acreditar nas imagens de satélite para o alinhamento, dá para futricar no parâmetro +towgs84=-67.35,3.88,… Estes dois números são um deslocamento em metros na direção x e y respectivamente.
Acho que para decidir isso é preciso comparar as imagens do Bing (ou Mapbox) com o mundo real usando um GPS. Se as imagens do Bing estiverem um pouco deslocadas, seria possível medir esse deslocamento e aplicar a devida correção no JOSM. Mas nesse caso tudo o que foi traçado sobre as imagens não corrigidas ficaria deslocado…
Nos EUA e Europa, eu acho que o alinhamento e ortorretificação das imagens de satélite é bem melhor que no resto do mundo (e isso provavelmente vale tanto para as imagens disponíveis para os mapeadores do OSM quanto para as imagens que as prefeituras compram). Assim, eu não imaginho que eles tenham tido muito problema com essas coisas por lá.
Esse é o valor oficial (dá para encontar isso nalgum lugar no site do IBGE, e também no link no post #43 acima). E, como eu disse acima, estes parâmetros estão errados nas bibliotecas usadas pelo QGIS e ogr2osm, por isso não se deve usar a opção -e 4618
O certo seria não mudar, mas se você quiser aplicar um deslocamento uniforme em todo o dataset (para alinhar com as imagens de satélite e com o que já está no OSM), daria para mudar aqueles dois primeiros números.
Dá para colocar essas imagens em algum lugar na wiki do osm ou no https://imgur.com/
Acho que o próximo passo seria descobrir se esse deslocamento que estamos vendo é uniforme em todo o dataset ou se é um problema envolvendo a ortorretificação ou coisas do tipo.
Você poderia fazer o seguinte teste? Escolha umas 3 ou 4 áreas bem planas da cidade e afastadas umas das outras, e, usando sempre a projeção 2, compare os dados da prefeitura com as imagens do BIng como fizeste acima. Também seria útil fazer o mesmo teste em uma ou duas regiões de morros.
Apenas para citar, pois acho que o tema merece uma discussão a parte, estou tentando conseguir os dados de CEP dos correios.
Essa idéia surgiu a ver os outros exemplos de importação citados, onde o código postal estava atribuído aos prédios. Verifiquei que as ruas mapeadas no Butantã (SP/SP) não contém o CEP. Antes de copiar os dados do site dos correios resolvi perguntar se é possível baixar a base e utilizá-la.
A primeira resposta foi que a base é proprietária e é vendida. Agora perguntei se posso copiar o resultado de uma busca realizada no site. Também questionei o acesso citando a lei de acesso à informação (12.527 de 18.11.11).
Não encontrei algo neste forum e o que achei na Talk-br não parece ser conclusivo.
O **Augusto S **me alertou que a permisão de uso que o Vitor George conseguiu é para um outro link.
Dessa forma, até segundo aviso, aguardem para utilizar os dados do link anterior.
Fiz um cadastro no sistema e-SIC da Prefeitura e aguardo resposta sobre a restrição de uso.
[]s,
P.S. 1 (13:34:51) : Um mês no banco de espera:
" O seu pedido de informação deverá ser processado no prazo de 20 (vinte) dias, conforme estabelecido no § 2º do art. 18 do Decreto Municipal 53.523/2012, podendo esse prazo ser prorrogado por mais 10 (dez) dias, mediante justificativa expressa, conforme dispõe o art. 19. "
P.S. 2 (13:59)
No meu entendimento, na resposta que o Vitor recebeu da Prefeitura informa que os dados da página “Dados Abertos” pode ser utilizada de forma livre, bastando fazer citação da fonte. A divergência é que o link hoje (27.08.14) não aponta mais para a mesma página.
Além de reduzir a burocracia, já que o VItor George já checou que este arquivo está OK para importação, este arquivo contém a altura dos prédios, informação esta que pode ser retida na chave height=* http://wiki.openstreetmap.org/wiki/Key:height.
Eu tenho a impressão que esse arquivo usa coordadas UTM, então a opção certa no ogr2osm seria -p ‘+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-67.35,3.88,-38.22,0,0,0,0 +units=m +no_defs’
O arquivo que pode conter a altura dos prédios, conforme indicado pelo Augusto S, tem 611 Mb. A minha impressão é que levaria um noite inteira para o JOSM apenas ler o conteúdo.
Fiz um teste com um arquivo menor com dados de logradouros, pois ainda quero conseguir a base de CEPs, e foi necessário cerca de 20min para abrir o arquivo. A tela do JOSM ficou preta sem mostrar qualquer informação. Fiz a conversão do shapefile para osm com a projeção sugerida e o resultado foi o mesmo.
É preciso verifcar como Vitor George está fazendo para ler os dados.
Aí vai um “translation script” do ogr2osm que extrai um setor do shapefile de 611MB
# -*- coding: utf-8 -*-
import re
def filterFeature(ogrfeature, fieldNames, reproject):
if not ogrfeature:
return
if ogrfeature.GetFieldAsString('COD_SETOR_') == "106":
return ogrfeature
else:
return
def filterTags(attrs):
if not attrs:
return
tags = {}
if float(attrs['ALTURA_EDI']) > 0:
tags['height'] = str(float(attrs['ALTURA_EDI']))
tags['building'] = 'yes'
return tags
Depois de salvar o código acima como sampa-buildings.py, obter o arquivo DEINFO_EDIFICACAO.shp do zip de 1.5GB (link acima) e instalar o ogr2osm https://github.com/pnorman/ogr2osm, vocé pode rodar
Iterando sobre todos os valores de COD_SETOR_, geraríamos algumas centenas de arquivos osm, cada um com em torno de 10MB. Isso provavelmente é grande demais para manipular de forma prática. Outra forma de quebrar o shapefile de 600MB é usar o script chunk.py disponível aqui https://github.com/osmlab/nycbuildings/ juntamente com o arquivo DEINFO_QUADRA_PREDIAL.shp. Isso iria querar os shapefile de edifícios em 60 mil shapefile-zinhos, um para quadra da cidade. Pode parecer pequeno demais, mas talvez isso funcione muito bem junto com o Tasking Manager.
A propósito, eu notei que os dados da prefeitura se alinham perfeitamente com as imagens do Mapbox, mas há um deslocamento de cerca de 5m com relação às imagens do Bing. Alguém de SP saberia confirmar que as imagens do Mapbox estão corretas e as do Bing deslocadas?
Nota: Descobri agora que o pessoal em Nova York quebrou o dataset deles em 5285 pedaços https://www.openstreetmap.org/user/lxbarth/diary/23588. Eles usaram distritos eleitorais para fazer essa subdivisão. Em SP eu não achei nada intermediário entre quadras (60 mil) e setores (algumas centenas). Alguma idéia?
Nenhuma das duas regiões abragidas pelas imagens que você postou acima está estritamente contida na outra (e a semelhança no número de linhas só pode ter sido coincidência.) São simplesmente duas formas diferentes, mas igualmente válidas, de quebrar o arquivo.
Eu estou conseguindo usar o chunk.py para quebrar o shapezão de 611MB por quadras. Em breve eu vou fornecer uma amostra.
O servidor task vai ser uma mão na roda. Vai facilitar bastante a nossa vida, assim como facilitou para o pessoal em Nova York.
Eu cheguei neste SRID 4618 fazendo vários testes. No caso, eu usei a base de rios. Eu sabia a posição do córrego in loco e este foi o sistema de coordenadas que dava o local correto. Mas eu não fiz um teste em outras regiões como foi proposto aqui.
Antes de analisar achava que esta imagem era composta apenas pelo código 082.
Dessa forma, quebrar por quadras pode ser uma boa escolha.
Outro resultado que posso inferir é que a liberação que o Vitor George conseguiu também serve para o Mapa Digital da Cidade, uma vez que este é apenas uma divisão em unidades menores do arquivo “DEINFO”.
