[Talk-br] Fwd: Problema de usabilidade do editor de endereços do iD

Fernando Trebien fernando.trebien em gmail.com
Sábado Fevereiro 15 01:06:17 UTC 2014


Ah, fui excluir o exemplo e só daí entendi exatamente o que você quis
dizer. Tinha entendido que os escritórios (que eu pensei que seriam
mapeados como pontos dentro do edifício, por serem muitos) tinham
menos prioridade que o próprio edifício. Vou copiar pra lista porque
acho que pode interessar a mais gente.

Eu nunca analisei isso a fundo, mas já fiquei várias vezes com a
impressão de que, quando os objetos são de mesmo tipo e tentam ocupar
o mesmo espaço, o Mapnik opta por desenhar o mais antigo. Se ambos
vieram no mesmo changeset, seria o primeiro que você desenhou.

Aqui tem um problema em definir "importância", já que as tags são
essencialmente as mesmas. A melhor maneira de fazer isso (e aposto que
é o que o Google faz) seria com uma estatística do número de buscas
por cada um dos dois locais. Se formos fazer manualmente, sempre
haverá divergências sobre qual é mais importante, e variações de
importância de um momento para o outro.

Num lugar muito densamente mapeado, o provável é que quase todos os
nomes de edifícios vizinhos entrem em conflito (mesmo no maior nível
de ampliação) e com isso nenhum ou quase nenhum acabe sendo exibido -
exceto quando a regra de desenho for influenciada por outro fator
(como o tipo de estabelecimento dentro do edifício).

Desde o começo me pareceu que o estilo padrão do Mapnik privilegia
coisas ligadas ao turismo. Por exemplo, a tag tourism=attraction faz o
título ganhar bastante destaque e ter prioridade sobre praticamente
tudo que está à sua volta. Restaurantes, bares e afins também são
mapeados com bastante destaque, nem que seja um boteco de esquina ao
lado de um grande prédio comercial de 20 andares. Veja só:
http://www.openstreetmap.org/#map=17/-30.11251/-51.23857

> 2014-02-14 0:55 GMT-02:00 Augusto Stoffel <arstoffel em gmail.com>:
>> Eu acho que é sim licença poética interpretar housename como complemento, e
>> eu não teria levantado nenhuma objeção se não fosse o fato de que e a
>> interpretação mais estrita de housename como "nome da estrutura física"
>> possui alguns usos interessantes, como eu mencionei no meu primeiro
>> email para a lista.
>>
>> Enfim, talvez esses dois usos do housename, como nome da estrutura
>> física ou como complemento, possam coexistir, pelo menos enquanto uma
>> tag específica para complemento não surge.
>>
>> A razão pela qual eu gostaria de colocar nomes de prédios (que eu
>> considero uma informação secundária) no housename seria evitar situações
>> assim, em que uma informação meio bobinha ("Edifício Poente do Guahyba")
>> sobrepõe o nome dos Escritórios Importantes:
>> http://www.openstreetmap.org/way/261455744#map=18/-30.11330/-51.23711.
>>
>>
>>
>> On Thu, 2014-02-13 at 21:53 -0200, Fernando Trebien wrote:
>>> O Mapnik optaria corretamente pelo nome da escola porque o Mapnik
>>> considera várias áreas como "contêiners" de edifícios (possivelmente
>>> nomeados) - entre elas, áreas de escolas, universidades, parques,
>>> etc., e dá prioridade ao nome desses contêiners. Como lembro de ter
>>> visto isso mas não achei nenhum exemplo, e também resolvi estudar a
>>> questão name vs addr:housename vs addr:housenumber, resolvi fazer um
>>> pequeno teste temporário (que vou desfazer depois dessa discussão):
>>> http://www.openstreetmap.org/changeset/20549103
>>>
>>> Veja como o nome "Escola Teste" sempre tem prioridade sobre "Prédio
>>> Central": http://www.openstreetmap.org/way/261455744
>>>
>>> Veja também que:
>>> 1. O Mapnik prefere name (www.openstreetmap.org/browse/way/261459601),
>>> depois housenumber (http://www.openstreetmap.org/way/261455746), e só
>>> por último housename (exemplo incompleto em outro lugar:
>>> http://www.openstreetmap.org/#map=18/-30.10691/-51.12497); o estilo
>>> visual de housename é igual ao de housenumber (sugerindo que são
>>> similares ou equivalentes)
>>> 2. O Nominatim considera name e housename equivalentes
>>> (http://www.openstreetmap.org/search?query=trebien%20poa) na linha de
>>> endereço, prefere name (ou seja, suprime housename quando ambos estão
>>> presentes), e sempre exibe housenumber para ambos
>>>
>>> Então, só daria problema usar housename como complemento com o Mapnik
>>> se o complemento fosse a única coisa que se conhece sobre o endereço
>>> (ou seja, se faltasse addr:housenumber). Se o complemento for junto em
>>> addr:housenumber, ele será renderizado junto nos casos em que não
>>> houver name (algo um tanto comum). Não me parece que o Mapnik foi
>>> feito pra representar essa informação desse jeito.
>>>
>>> De volta ao Nominatim
>>> (http://www.openstreetmap.org/search?query=trebien%20poa), os
>>> resultados correspondem a:
>>> 1. housename, housenumber, street, ...
>>> 2. name, housenumber, street, ...
>>> 3. name, housenumber, street, ... (housename presente mas ignorado)
>>>
>>> Se housename fosse considerado equivalente a housenumber, um
>>> substituiria o outro, ou ocupariam a mesma posição no endereço. Mas
>>> não, housename é considerado equivalente a name, e ocupa a mesma
>>> posição quando name está faltando.
>>>
>>> Se colocarmos o complemento em housenumber, o complemento sempre vai
>>> aparecer (independente de quão longo for). Se colocarmos em housename,
>>> só aparece e só é pesquisável se name estiver faltando. Mas pesquisar
>>> pelo complemento é algo raro, e a necessidade de vê-lo na lista de
>>> resultados é discutível (número e rua são suficientes em 99,9% dos
>>> casos), até porque você pode clicar no resultado e visualizar a tag
>>> addr:housename.
>>>
>>> Relendo o wiki (mais uma vez) o que eu entendo do texto: housename
>>> pode ser tanto equivalente a housenumber (caso este esteja ausente -
>>> "instead of") OU complementar a este (caso esteja presente - "in
>>> addition to"). Pra mim isso representa uma subordinação, não uma
>>> equivalência (caso em que se diria que é equivalente mesmo que a outra
>>> tag esteja presente). Essa interpretação explicaria boa parte do
>>> comportamento tanto do Nominatim quanto do Mapnik. O do Mapnik ainda
>>> sugere que deve-se tentar usar "name" sempre que possível.
>>>
>>> Mas então, se temos uma casa (building=house) com um nome, o nome deve
>>> ir em addr:housename ou name? Seguindo os demais casos (o nome da
>>> escola vai em "name", o nome do bairro vai em "name", o nome da rua
>>> vai em "name"), iria em "name". Em todos os outros casos, em
>>> "addr:housename" vai informação complementar de "endereço". A idéia é
>>> que o que está em "name" existe dentro da "casa" especificada com
>>> "addr:housename". "Name" é a informação final, "addr:housename" é uma
>>> anotação, inclusive endereços aparecem no grupo Annotation no JOSM. A
>>> casa dentro da própria casa parece ilógico pra mim.
>>>
>>> Vamos a um caso mais extremo: e se tivermos um condomínio que se
>>> subdivide em áreas, depois em prédios (cada um com um nome próprio),
>>> depois em blocos (2 ou 3 por prédio) e por fim em apartamentos onde,
>>> digamos, existe um escritório, como ficariam as tags de cada coisa e
>>> do escritório? O endereço completo de um apartamento seria "Rua X,
>>> 1200, área 5, prédio 3, bloco sul, apartamento 407". O nome da "casa"
>>> seria "bloco 2"? "Apartamento 407"? As nossas opções são:
>>> 1. name=Meu Escritório + addr:housenumber=1200 + addr:housename=Área
>>> 5, Prédio 3, Bloco Sul, Apartamento 407
>>> - Mapnik: renderiza "Meu Escritório"
>>> - Nominatim: retorna "Meu Escritório, 1200, Rua X"
>>>
>>> 2. name=Meu Escritório + addr:housenumber=1200 + addr:housename=Prédio
>>> Amarelo + addr:unit=Sul + addr:door:407
>>> - Mapnik: renderiza "Meu Escritório"
>>> - Nominatim: retorna "Meu Escritório, 1200, Rua X"
>>>
>>> Se o escritório não tiver nome (um tanto comum) ou a pessoa esqueceu
>>> de colocá-lo:
>>> 3. addr:housenumber=1200 + addr:housename=Área 5, Prédio 3, Bloco Sul,
>>> Apartamento 407
>>> - Mapnik: renderiza "1200"
>>> - Nominatim: retorna "Área 5, Prédio 3, Bloco Sul, Apartamento 407, 1200, Rua X"
>>>
>>> 4. addr:housenumber=1200 + addr:housename=Prédio Amarelo +
>>> addr:unit=Bloco Sul + addr:door=Apartamento 407
>>> - Mapnik: renderiza "1200"
>>> - Nominatim: retorna "Prédio Amarelo, 1200, Rua X" (ou mesmo
>>> "Apartamento 407, Bloco Sul, Prédio Amarelo, 1200, Rua X")
>>>
>>> Aqui sim tem uma diferença fazer de um jeito ou de outro. No segundo
>>> caso, falta o número da área (pra qual não existiria tag). No
>>> primeiro, está inteiramente capturada (ainda que fora de ordem).
>>>
>>> Digamos que o geocoder consiga extrair addr:housenumber das áreas onde
>>> o objeto está contido (e deveria conseguir fazer isso). Daí o elemento
>>> não teria addr:housenumber e ambas as opções levariam a um render
>>> errado (ambas seriam o housename), mas de novo a primeira daria um
>>> resultado mais compreensível na busca.
>>>
>>> Quando que um caso extremo assim ocorre? Quase nunca. Ocorre?
>>> Provavelmente, umas poucas vezes. Pra maioria dos casos, as tags novas
>>> de endereço devem ser suficientes. Em qualquer caso, uma solução
>>> genérica precisa ou de um geocoder muito inteligente, ou de relações
>>> para expressar que uma área está dentro da outra (tipo a relação
>>> site), ou de uma tag pra representar uma porção intermediária do
>>> complemento onde existam subdivisões não previstas. Se você usar uma
>>> única tag pro complemento (exceto a parte final) e uma tag "name" pra
>>> expressar a parte final (que é o que acaba sendo renderizado), você
>>> evita esse problema todo por completo.
>>>
>>> 2014-02-13 18:40 GMT-02:00 Augusto Stoffel <arstoffel em yahoo.com.br>:
>>> > On Thu, 2014-02-13 at 17:37 -0200, Fernando Trebien wrote:
>>> >> Eu mapearia esse colégio de um jeito um pouco diferente. O nome do
>>> >> prédio iria no objeto que representa o prédio (que tem um buraco no
>>> >> meio onde fica o pátio) e o da escola iria na objeto que representa a
>>> >> escola (a área inteira, incluindo prédio, pátio e quadras). Eu
>>> >> pensaria em fazer como você fez se eu pudesse combinar os dois objetos
>>> >> num só, mas nesse caso, não dá, e é até melhor porque assim cada
>>> >> atributo é atribuído à coisa a que ele realmente se refere.
>>> >
>>> > Bem, não está muito claro se se deve associar os números aos prédios ou
>>> > aos lotes no Brasil; talvez o correto fosse pôr o endereço no prédio e a
>>> > tag amenity=school no lote (afinal, uma escola pode ter mais de um
>>> > prédio com diferentes endereços).  Mas do jeito que tu sugeres mapear,
>>> > ficaria difícil para o Mapnik decidir se deve exibir "Colégio Militar"
>>> > ou "Casarão da Várzea", e aqui a coisa certa é exibir "Colégio Militar";
>>> > logo eu ainda assim deixaria Casarão da Várzea como housename: não está
>>> > errado e ajuda o renderizador.
>>> >
>>> >>
>>> >> Pelo que você constatou, o Nominatim de fato vê addr:housename como
>>> >> alternativa a name e não como alternativa a addr:housenumber. Ele
>>> >> também prioriza short_name em cada uma das partes do nome, por isso
>>> >> retorna "RS" ao invés de "Rio Grande do Sul". Acho que o motivo é
>>> >> fazer tudo caber no espaço curto à esquerda e em dispositivos mobile.
>>> >>
>>> >> Além disso, o Mapnik renderiza addr:housename caso name esteja
>>> >> faltando. Faltando espaço, renderiza addr:housenumber, se houver. A
>>> >> prioridade nele é name, depois addr:housename, depois
>>> >> addr:housenumber.
>>> >>
>>> >
>>> > Pela descrição que tu dás do comportamento do Mapnik, ele não considera
>>> > o housename como uma subinformação do housenumber; se esse fosse o caso,
>>> > ele mostraria o housename em adição ao housenumber, e não no lugar dele,
>>> > quando há espaço.
>>> >
>>> > O Nominatim parece ignorar o housename se há um housenumber:
>>> >
>>> > http://www.openstreetmap.org/search?query=Zimbabwe+House
>>> > http://www.openstreetmap.org/search?query=casarão+da+várzea
>>> >
>>> > Ou seja, o Mapnik considera housename como hierarquicamente equivalente
>>> > ao housenumber, mas "menos útil" para o usuário, e só o exibe na falta
>>> > de um housenumber.
>>> >
>>> > Olha essa busca:
>>> >
>>> > http://www.openstreetmap.org/search?query=FOSPA%2C+porto+alegre
>>> >
>>> > Ele não retorna algo como
>>> >
>>> >         FOSPA, Sala 305, 805, Rua 24 de Outubro, Moinhos de Vento, Porto
>>> >         Alegre, Microregion of Porto Alegre, Metropolitan Region of
>>> >         Porto Alegre, Metropolitan Mesoregion of Porto Alegre, RS, South
>>> >         Region, 90510-000, Brazil
>>> >
>>> > o qual seria o resultado esperado para o uso que está sendo feito de
>>> > housename.
>>> >
>>> >> Voltando ao que diz no wiki sobre addr:housename:
>>> >>
>>> >> "The name of a house. This is sometimes used in some countries like
>>> >> England instead of (or in addition to) a house number."
>>> >>
>>> >> Então addr:housename pode ser usada no lugar de addr:housenumber
>>> >> quando houver um nome e não um número ("instead of") e como acréscimo
>>> >> a ele ("in addition to"), ou seja, como sub-informação mesmo. No
>>> >> Brasil essa sub-informação corresponde essencialmente ao complemento
>>> >> (que pode ter várias subdivisões com nomes diferentes e em ordens
>>> >> diferentes em cada lugar), embora nem sempre seja apenas um nome (pode
>>> >> ser vários concatenados). "House" aqui é pouco exato (já que se aplica
>>> >> a coisas também a coisas que não são casas), então não tem por que
>>> >> "name" significar apenas a parte final do complemento ou se restringir
>>> >> a um título oficial. As tags addr:unit e addr:door tentam tornar essa
>>> >> subdivisão mais regular, e como são aprovadas, claro que podem ser
>>> >> usadas. Sugiro inclusive que testem e verifiquem se alguém já as usa
>>> >> (acho que não). Se não usarem, eu recomendaria usar addr:housename por
>>> >> enquanto. Pra mim, como usuário, mapeador e programador, essa  parece
>>> >> ser uma complexidade desnecessária, e fazendo assim se perde a
>>> >> informação da denominação das subdivisões caso a caso.
>>> >
>>> > Eu concordo que não tem porque ter tanta estrutura para o complemento,
>>> > uma tag com formato livre bastaria.  Mas não me parece que housename é o
>>> > lugar correto para fazê-lo, porque ela tem a semântica de ser
>>> > hierarquicamente equivalente ao housenumber (como eu acabei de me
>>> > convencer e espero ter te convencido).
>>> >
>>> > Se é para usar housename de uma forma que nenhuma aplicação entende,
>>> > então que usemos uma nova tag addr:complement, e deixemos o housename
>>> > para o que ele realmente serve: o nome da estrutura física,
>>> > funcionalmente equivalente a um número de porta.
>>> >
>>> > Voltando ao exemplo da FOSPA acima, se a gente remover o housename e
>>> > etiquetar "addr:housenumber=805 Sala 305", ou
>>> > "addr:housenumber=805/305" (nota que o nó da FOSPA está dentro de um
>>> > objeto com housenumber=805), o resultado da busca no Nominatim vai ser
>>> > bem razoável:
>>> >
>>> >         FOSPA, 805 Sala 305, Rua 24 de Outubro, Moinhos de Vento, Porto
>>> >         Alegre, Microregion of Porto Alegre, Metropolitan Region of
>>> >         Porto Alegre, Metropolitan Mesoregion of Porto Alegre, RS, South
>>> >         Region, 90510-000, Brazil
>>> >
>>> > É por isso que eu sugeri usar o próprio housenumber para complemento na
>>> > mensagem anterior.  Nota que se existe um objeto com
>>> > "addr:housenumber=XXX Sala YYY", tipicamente existirá um outro objeto
>>> > com onde pôr "addr:housenumber=XXX".
>>> >
>>> >>
>>> >> O Nominatim foi implementado com regras genéricas, sem qualquer tipo
>>> >> de localização de formato (só o das tags name:[idioma]). Até dá pra
>>> >> pedir que façam.
>>> >
>>> > Basicamente, a gente está pedindo que o iD faça isso, é obvio que o
>>> > Nominatim deve fazer.
>>> >
>>> >>
>>> >> Talvez dê pra pensar que todo limite administrativo precisaria ter
>>> >> associado a ele um "centro administrativo" (um governo, uma prefeitura
>>> >> ou subrefeitura, uma administração regional, ou quem sabe até uma
>>> >> associação de moradores) com poderes de deliberar sobre a área. (Só o
>>> >> caso dos bairros seria difícil de encaixar nessa visão, e é por isso
>>> >> que geralmente não usamos a role "admin_centre" nas relações deles.)
>>> >> Pensando assim, as micro e mesorregiões não seriam limites
>>> >> "administrativos". Elas são apenas subdiviões estatísticas segundo a
>>> >> Wikipédia, embora na prática possam ser consideradas subdivisões
>>> >> políticas (http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical).
>>> >
>>> > Eu acho que isso está bacana como está, é o Nominatim que tem que
>>> > entender as peculiaridades de cada país.
>>> >
>>> >>
>>> >> Algo parecido valeria para os bairros, mas daí eu acho que vários
>>> >> sistemas deixariam de funcionar se mapeássemos de forma diferente da
>>> >> atual.
>>> >>
>>> >> 2014-02-13 14:07 GMT-02:00 Augusto Stoffel <arstoffel em yahoo.com.br>:
>>> >> > On Thu, 2014-02-13 at 13:38 -0200, Fernando Trebien wrote:
>>> >> >> Eu vinha colocando nomes de edifícios na tag "name" mesmo. Nunca
>>> >> >> encontrei um caso em que o edifício teria um nome e também abrigaria
>>> >> >> inteiramente 1 estabelecimento (e somente 1) com um nome diferente.
>>> >> >> Nesse caso, eu provavelmente mapearia a "coisa" como ponto dentro do
>>> >> >> edifício, mas pela descrição no wiki daria pra usar addr:housename.
>>> >> >
>>> >> > Aqui tem mais um exemplo:  http://www.openstreetmap.org/way/234164668
>>> >> >
>>> >> > Além disso, eu estou argumentando que mesmo que as tags name e
>>> >> > addr:housename não coexistam no mesmo elemento, a distinção semântica é
>>> >> > útil (e, na minha leitura, está implícita na definição dessas tags, de
>>> >> > forma que várias aplicações efetivamente façam essa distinção).
>>> >> >
>>> >> >>
>>> >> >> Caso o nome do edifício seja considerado parte do complemento (mas
>>> >> >> nunca vi), eu acabaria replicando o valor de name na tag
>>> >> >> addr:housename do edifício, mas nas coisas que ficam dentro do
>>> >> >> edifício essa tag teria mais informações. Por exemplo, poderia ter
>>> >> >> "Edifício JK, 10º Andar, Sala Sul, Área 2B".
>>> >> >>
>>> >> >> A descrição de housename no wiki: "The name of a house.  This is
>>> >> >> sometimes used in some countries like England instead of (or in
>>> >> >> addition to) a house number."
>>> >> >
>>> >> > A minha leitura é que o housename não é uma subinformação do
>>> >> > housenumber, e sim que estas são informações alternativas, mais ou menos
>>> >> > equivalentes.  Se aplicativos interpretam do jeito que eu interpreto
>>> >> > (não sei se é o caso), pode dar problema usar o housename como
>>> >> > complemento.
>>> >> >
>>> >> >>
>>> >> >> O nosso "complemento" seria sempre um "in addition to".
>>> >> >>
>>> >> >> Posso testar como o Nominatim se comporta, mas acho que ele geraria um
>>> >> >> resultado com name, addr:housename e as demais tags de endereço nesse
>>> >> >> formato: [name], [addr:housename], [addr:housenumber], [addr:street],
>>> >> >> [name com admin_level=10], [name com admin_level=9], etc.
>>> >> >
>>> >> > No caso do colégio militar, ele retorna
>>> >> >
>>> >> >         School CMPA, 363, Avenida José Bonifácio, Farroupilha, Porto
>>> >> >         Alegre, Microregion of Porto Alegre, Metropolitan Region of
>>> >> >         Porto Alegre, Metropolitan Mesoregion of Porto Alegre, RS, South
>>> >> >         Region, 90040-130, Brazil
>>> >> >
>>> >> > Parece ter ignorado o housename, e não sei porque está dando o
>>> >> > short_name em vez do name.  A propósito, microregião, região
>>> >> > metropolitana, mesoregião e região são totalmente inúteis para 99.873%
>>> >> > das pesquisas.  O nominatim devesse suportar formatar endereços de
>>> >> > acordo com a área (resolvendo também o problema da ordem do número e
>>> >> > rua).  No nosso caso, seria rua, número, cidade, estado, cep, país (ou
>>> >> > cep antes do estado, não parece ter uma convenção 100% aceita).
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> 2014-02-13 13:16 GMT-02:00 Nelson A. de Oliveira <naoliv em gmail.com>:
>>> >> >> > 2014-02-13 12:51 GMT-02:00 Augusto Stoffel <arstoffel em yahoo.com.br>:
>>> >> >> >> Outra possibilidade seria usar a tag addr:housename literalmente, para
>>> >> >> >> denotar o nome do edifício, e nunca o complemento.
>>> >> >> >
>>> >> >> > É dessa forma que eu sempre enxerguei essa tag.
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > Talk-br mailing list
>>> >> >> > Talk-br em openstreetmap.org
>>> >> >> > https://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)


-- 
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)



Mais detalhes sobre a lista de discussão Talk-br