<p>Em relação ao import final acho que possivelmente o modo de fazer é gerar um osm com tudo e depois splitar e enviar pedaços de cada vez. Pelo que li nas listas é o que costumam fazer. </p>
<p>Vou-te deixar ver se descobres o que se passa com as ways duplicadas. Mas se precisares de ajuda avisa la. </p>
<p>Sem olhar o código o q se calhar está a acontecer é que como as ways não são iguais, mas tem pontos iguais, então o código não detecta isto. </p>
<div class="gmail_quote">On 16 Dec 2010 17:52, "Jorge Gustavo Rocha" <<a href="mailto:jgr@di.uminho.pt">jgr@di.uminho.pt</a>> wrote:<br type="attribution">> Olá João Paulo,<br>> <br>> Qui, 2010-12-16 às 17:23 +0000, Joao Carreiro escreveu:<br>
>> Boas Jorge,<br>>> <br>>> Eu acho que encontrei mais um erro.<br>> <br>> Fixe!<br>> <br>>> <br>>> Existem ways, por exemplo<br>>> <a href="http://www.openstreetmap.org/browse/way/89823424">http://www.openstreetmap.org/browse/way/89823424</a> e<br>
>> <a href="http://www.openstreetmap.org/browse/way/89839334">http://www.openstreetmap.org/browse/way/89839334</a> que estao estão na<br>>> mesma posicao, e neste caso acho que deveriam ser "merged" numa única<br>
>> way, mas com as duas relações, o que parece ser o caso noutros casos.<br>>> <br>> <br>> Pois... pensava que o ogr2osm conseguia detectar todas estas<br>> duplicações, mas pelos vistos não. Estou a usar o ogr2osm exactamente<br>
> por causa desta questão. Vou estudar melhor o assunto, mas suspeito que<br>> a forma original dos polígonos não ajuda. Pode ser que mais mais alguém<br>> teste a importação de forma diferente, com mais sucesso.<br>
> <br>>> Acho que nao importaste nenhuma fronteira de conselho, certo?<br>> <br>> Sim, nesta fase de teste, não tratei os limites de concelho, pois eles<br>> próprios também fazem parte dos limites do concelho adjacente.<br>
> <br>>> Possivelmente já sabes, mas há que ter em atencao q no caso de uma way<br>>> for a fronteira de uma freguesia e conselho, o admin_level deve ser 7.<br>>> <br>>> A ideia é fazer conselho por conselho, ou tudo de uma vez? Eu acho que<br>
>> terá ser tudo de uma vez, senão as fronteiras de conselho vao ser<br>>> duplicadas, não?<br>> <br>> Fico na dúvida. Para já, estamos em modo "teste" e tenho tantas ou mais<br>> dúvidas que tu. A ideia é mesmo ir experimentando e afinando as scripts,<br>
> à medida que se discutem estas questões. Carreguei as de Águeda, para<br>> ver essas questões na fronteira, mas até me parece que fez o upload duas<br>> vezes, já que na primeira me tinha dado um erro de ligação a meio. A API<br>
> falha em duas coisa que me parecem fundamentais: a falta de noção de<br>> "transacção" na base de dados, e a falta de um "delete changeset".<br>> <br>> No entanto, cada importação e respectiva anulação "custam" um bocado. No<br>
> mínimo uns 15 a 20 minutos de upload, e outro tanto para download e<br>> delete. Ou seja, desde ontem não fiz outra coisa. Não digam nada ao<br>> patrão.<br>> <br>> Quando for para o país todo, não podemos falhar. O mais provável é<br>
> termos que fazer vários changesets.<br>> <br>> Abraço,<br>> <br>> Jorge<br>> <br>> <br>>> <br>>> 2010/12/16 Jorge Gustavo Rocha <<a href="mailto:jgr@di.uminho.pt">jgr@di.uminho.pt</a>>:<br>
>> > Olá,<br>>> ><br>>> > De facto, cada um dos limites tem que estar etiquetado. Só tinha<br>>> > etiquetado as relações. Obrigado João Paulo pelo feedback.<br>>> ><br>>> > Desta forma, a importação, usando o ogr2osm, passa a ser feita em 3<br>
>> > passos, que são, grosso modo (para Sever do Vouga, por exemplo):<br>>> ><br>>> > python ogr2osm.py -t caop ../SeverDoVouga.shp<br>>> > recode latin1..utf8 SeverDoVouga.osm<br>>> > xmlstarlet tr tagways.xsl SeverDoVouga.osm > SeverDoVouga_ok.osm<br>
>> ><br>>> > e depois faz-se o upload através do JOSM, por exemplo, depois de se<br>>> > verificar que a transformação de coordenadas, os encodings, as<br>>> > etiquetas, etc, estão ok. Vou reescrever melhor a cábula de importação,<br>
>> > pois tive que mexer em vários programas.<br>>> ><br>>> > Vejam se gostam do resultado. Só importei a CAOP para Sever do Vouga.<br>>> ><br>>> > A mim, parece-me um apoio bem interessante para algumas coisas:<br>
>> > 1) para ver se determinados limites administrativos (não físicos) batem<br>>> > certo com determinados entidades geográficas (rios, ruas ou outros)<br>>> > 2) para se dividir trabalho entre nós e para apoiar as parties que se<br>
>> > vão organizar no futuro próximo<br>>> > 3) para se poder avaliar e medir freguesia a freguesia a cobertura do<br>>> > OSM em Portugal<br>>> > 4) Para ajudar a marcar e comparar com os nodos referentes aos centros<br>
>> > das freguesias (ainda há muitos por inserir)<br>>> ><br>>> > Como tudo é etiquetado de forma automática, depois é fácil identificar,<br>>> > actualizar ou remover esta mesma informação. Incluí uma tag source =<br>
>> > "IGP-CAOP-2010". A ideia é que ninguém a altere estes limites nas suas<br>>> > edições, pois é informação que provém do IGP e qualquer alterações aos<br>>> > limites tem que vir por essa via. Mesmo os nosmes das freguesias que<br>
>> > aqui constam, são os nomes oficiais e têm que bater certo com os do INE.<br>>> > Sempre que o IGP publicar nova CAOP, pode-se remover a anterior e<br>>> > importar a nova.<br>>> ><br>
>> > Antes de se importar a CAOP, gostava que mais gente se pronunciasse,<br>>> > pois é uma camada que terá o seu impacto no OSM-PT. Na ausência de mais<br>>> > feedback, eu e o João Paulo tratamos do assunto :-)<br>
>> ><br>>> > Já agora, em alternativa ou complemento, o IGP tem um serviço WMS com a<br>>> > CAOP, que pode ser utilizado como fundo no JOSM.<br>>> ><br>>> > Abraço a todos,<br>
>> ><br>>> > Jorge<br>>> ><br>>> > Qui, 2010-12-16 às 09:36 +0000, Joao Carreiro escreveu:<br>>> >> Boas Jorge,<br>>> >><br>>> >> Eu acho que o import não está correcto.<br>
>> >> Não colocaste nas ways as tags boundary e admin_level.<br>>> >> E segundo a wiki,<br>>> >> <a href="http://wiki.openstreetmap.org/wiki/Relation:boundary#Way_Tags">http://wiki.openstreetmap.org/wiki/Relation:boundary#Way_Tags</a> ,<br>
>> >> deverias ter colocado.<br>>> >> Acho que é por isso que não aparece no mapa.<br>>> >><br>>> >> João Paulo<br>>> >><br>>> >> On 16 Dec 2010 02:19, "Jorge Gustavo Rocha" <<a href="mailto:jgr@di.uminho.pt">jgr@di.uminho.pt</a>> wrote:<br>
>> >><br>>> >> _______________________________________________<br>>> >> Talk-pt mailing list<br>>> >> <a href="mailto:Talk-pt@openstreetmap.org">Talk-pt@openstreetmap.org</a><br>
>> >> <a href="http://lists.openstreetmap.org/listinfo/talk-pt">http://lists.openstreetmap.org/listinfo/talk-pt</a><br>>> ><br>>> > --<br>>> > Jorge Gustavo Rocha<br>>> > Departamento de Informática<br>
>> > Universidade do Minho<br>>> > 4710-057 Braga<br>>> > Tel: 253604430 (Geral), 253604479 (Gabinete)<br>>> > Fax: 253604471<br>>> > Móvel: 910333888<br>>> ><br>>> ><br>
>> ><br>>> > _______________________________________________<br>>> > Talk-pt mailing list<br>>> > <a href="mailto:Talk-pt@openstreetmap.org">Talk-pt@openstreetmap.org</a><br>>> > <a href="http://lists.openstreetmap.org/listinfo/talk-pt">http://lists.openstreetmap.org/listinfo/talk-pt</a><br>
>> ><br>>> <br>>> _______________________________________________<br>>> Talk-pt mailing list<br>>> <a href="mailto:Talk-pt@openstreetmap.org">Talk-pt@openstreetmap.org</a><br>>> <a href="http://lists.openstreetmap.org/listinfo/talk-pt">http://lists.openstreetmap.org/listinfo/talk-pt</a><br>
> <br>> -- <br>> Jorge Gustavo Rocha<br>> Departamento de Informática<br>> Universidade do Minho<br>> 4710-057 Braga<br>> Tel: 253604430 (Geral), 253604479 (Gabinete)<br>> Fax: 253604471<br>> Móvel: 910333888<br>
> <br>> <br>> <br>> _______________________________________________<br>> Talk-pt mailing list<br>> <a href="mailto:Talk-pt@openstreetmap.org">Talk-pt@openstreetmap.org</a><br>> <a href="http://lists.openstreetmap.org/listinfo/talk-pt">http://lists.openstreetmap.org/listinfo/talk-pt</a><br>
</div>