[Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Peter Krauss]

Oi gente, concordo com o Paulo. Precisando fazemos o algoritmo em PostiGIS,
estou com o Planet de Curitiba.


On Tue, Nov 6, 2018 at 8:01 AM Paulo Carvalho <paulo.r.m.carvalho em gmail.com>
wrote:

> Pessoal, bom dia,
>
>      Para calcular um ponto representativo que:
> 1) Esteja dentro do polígono;
> 2) Esteja próximo de uma linha;
>
>     Eis um algoritmo:
>
> https://gis.stackexchange.com/questions/70628/automatically-create-point-based-on-location-of-polygon-using-arcgis-desktop
>
>      Embora implementado para Arc-Gis, o autor se deu ao trabalho de
> descrever o algoritmo, ou seja, alguém poderia implementá-lo em outra
> linguagem.
>
> abcs,
>
> PC
>
>
> Em seg, 5 de nov de 2018 às 23:32, Sérgio V. <svolk2 em hotmail.com>
> escreveu:
>
>> A princípio não acho bom mapear lotes, sobretudo urbanos.
>> O que recebe uma numeração da prefeitura é a construção, pelo menos em
>> PoA, onde a numeração depende de projeto de edificação para aprovação.
>> Pode haver mais de um número por lote, conforme quantos tipos de
>> estabelecimento com matrículas individualizadas houver no lote:
>> residencias, comerciais...
>> O santamariense registrou na wiki que o centróide é pra gerar o nó para a
>> numeração, e que este nó será movido para próximo da face do terreno junto
>> ao logradouro, que é a "testada".
>> E pelo mesmo motivo da numeração ser dada ao prédio correspondendo à
>> distância em metros medida aproximadamente na intersecção da projeção na
>> testada até o início da rua, indica que o ponto de medição não é pelo
>> centro do prédio (centróide), mas pelo centro da projeção na testada.
>> Se colocar numeração no polígono de prédio ou lote, acabaria sendo sempre
>> considerado pelo centróide. Aí dá problema em polígonos, lotes e/ou
>> prédios, que atravessam quadras e tem frente para 2 ou mais logradouros.
>> Seria conveniente colocar numeração sempre em um nó, que marca o local
>> aproximado do centro da testada no respectivo logradouro, não em polígono
>> de prédio ou lote. Assim como a prefeitura dá o número e proprietário
>> coloca a tabuleta num lugar +/- próximo da entrada, dificilmente exatamente
>> na medida exata.
>>
>> - - - - - - - - - - - - - - - -
>>
>> Sérgio - http://www.openstreetmap.org/user/smaprs
>>
>> ------------------------------
>> *De:* Fernando Trebien <fernando.trebien em gmail.com>
>> *Enviado:* segunda-feira, 5 de novembro de 2018 21:31
>> *Para:* OSM talk-br
>> *Assunto:* Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de
>> Curitiba / Importação de numeração predial
>>
>> On Mon, Nov 5, 2018 at 8:36 PM santamariense <imagens.sm em gmail.com>
>> wrote:
>> > > 2. Atribuir o endereço à entrada do lote, do lado de dentro. É feito
>> > > assim em Berlim, Amsterdã, Paris, Madri e partes de Londres e Nova
>> > > Iorque.
>> >
>> > É essa que está sendo proposta.
>>
>> Por ora eu acho ok. Mas gostaria de desdobrar esse ponto para o longo
>> prazo, não só em Curitiba mas também em outras cidades.
>>
>> O centróide do lote é diferente da entrada. Colocar o endereço na
>> entrada reduz o número de erros de projeção do endereço na via (mais
>> comuns nas esquinas), que é a primeira etapa do roteamento. Ainda
>> sobram casos particulares, mas menos.
>>
>> A minha questão, então, é se seria preferível no OSM, no longo prazo,
>> mover os pontos do centróide para a entrada, ou até mesmo eliminar o
>> ponto do centróide e transferir o endereço para o edifício ou lote
>> quando estiver mapeado.
>>
>> --
>> Fernando Trebien
>>
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20181106/b8011f74/attachment.html>