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

Quinta Fevereiro 13 14:46:40 UTC 2014

Acho que essa informação poderia ficar no addr:housename mesmo.

Na renderização isso poderia ficar bem interessante, imagino um prédio
comercial com addr:housenumber e as lojas com addr:housenumber e
addr:housename; como o addr:housename tem maior peso na renderização,
apareceria "Loja A", "Loja B" etc., se os POIs não forem renderizados com
um ícone. O mesmo para uma vila, a área da vila como landuse=residential e
addr:housenumber e as casas com addr:housenumber e addr:housename.

Como vocês acham que podemos sugerir na wiki? "Loja A" ou "A"? "Casa 1" ou
"1"?

Num primeiro momento penso que a primeira opção seria melhor, mas o
addr:housenumber é marcado só com o número, portanto poderia fazer sentido
marcar o addr:housename só com o número/letra da casa/loja.

[]s

2014-02-13 12:33 GMT-02:00 John Packer <john.packer7 em gmail.com>:

>
> Eu quase traduzi o "123" por "Nº de porta" (um termo que andou circulando
>> bastante por aqui). Se quiserem, posso alterar lá.
>
> Acho que se for pra trocar, deveria ser ou "Nº" ou "Número", pois pelo
> menos aqui não é chamado de "Nº de porta", mas geralmente de "Nº da casa"
> ou o equivalente.
>
>
> Por tudo isso, acho que addr:housename acaba sendo mais prática, e não se
>> perde informação com ela, e não se ganha nada com as outras duas  tags.
>>
> Ok, estou convencido que addr:housename pode ser utilizado como o
> "Complemento" no Brasil.
>
> Devemos então oficializar isso e documentar na wiki.
>
> Creio que seja útil, em adição ao addr:housename, adicionar (manualmente)
> o addr:door e addr:unit quando for o caso.
> O que acham?
>
>
> Em 13 de fevereiro de 2014 12:13, Fernando Trebien <
> fernando.trebien em gmail.com> escreveu:
>
> Eu quase traduzi o "123" por "Nº de porta" (um termo que andou
>> circulando bastante por aqui). Se quiserem, posso alterar lá. Acho que
>> mostrar a informação correta nesses campos já deve resolver mais de
>> 95% dos casos em que são usados de forma incorreta. Eu não trocaria
>> "Complemento" por "Apt/Sala/Conjunto" porque isso daria a impressão de
>> que só esses 3 são complementos válidos.
>>
>> Addr:door e addr:unit não são interpoláveis (pois podem ter letras),
>> logo não afetam o geocoding, logo servem apenas para informação, tal
>> como addr:housename. Somadas, essas duas não chegaram a 7 mil usos
>> desde que a proposta foi aprovada em 2011, contra 225 mil usos da tag
>> addr:housename. Nesse ritmo, é provável que nunca sejam suportadas por
>> aplicações, enquanto que addr:housename já é suportada por algumas.
>> Ela quase sempre se combina com addr:housenumber, sugerindo a mesma
>> função do nosso "complemento" brasileiro:
>> http://taginfo.openstreetmap.org/keys/addr%3Ahousename#combinations
>>
>> A vantagem de se usar addr:housename como complemento é que daria pra
>> especificá-lo da mesma forma que se usa em endereços postais, com os
>> mesmos termos usados pelo proprietário
>> (bloco/conjunto/apartamento/sala/etc.). Pode haver casos em que se tem
>> mais de 2 níveis de subdivisão da propriedade, e nesses casos
>> addr:door e addr:unit não seriam suficientes, mas addr:housename sim.
>> Por tudo isso, acho que addr:housename acaba sendo mais prática, e não
>> se perde informação com ela, e não se ganha nada com as outras duas
>> tags.
>>
>> 2014-02-12 23:17 GMT-02:00 John Packer <john.packer7 em gmail.com>:
>> >
>> >> Eu mudei a tradução de "nome da casa" para "complemento", isso já deve
>> >> ajudar.
>> >
>> > Sim, foi uma boa idéia, vai ajudar um pouco.
>> > Falando nisso, estava pensando se não seria melhor no addr:housenumber
>> > colocar "Número" ou "Nº" ao invés de "123". O que acha?
>> >
>> >> Eu duvido que eles localizem a interface (com tantas coisas ainda por
>> >> fazer), já que na maioria dos países europeus e na América do Norte
>> essa é a
>> >> ordem dos campos do endereço.
>> >
>> > Pois é, eu estava vendo o número gigantesco de coisas que eles têm a
>> fazer.
>> > Vou tentar "colocar a mão na massa" pra fazer isso ir pra frente.
>> > Eu pretendo esperar mais ou menos 1 semana por uma resposta deles.
>> Depois
>> > disso eu vou alterar o código e mandar pra eles corrigirem. Já dei uma
>> > olhada onde tem que alterar, só estou um pouco preocupado que o código
>> não
>> > ficaria muito limpo colocando um caso específico para a linguagem
>> português
>> > brasileiro no meio(isso tenho que ver com eles).
>> >
>> > Falando nisso, alguém sabe se os endereços dos outros países da América
>> > Latina são parecidos? E de Portugal?
>> >
>> >
>> >> Alguma aplicação já suporta a tag addr:door? O que iria nessa tag,
>> >> apenas um número ou uma descrição como "Sala 204", "Salas 204 e 205"
>> >> ou "Conjunto 501"?
>> >
>> > Não sei se tem alguma aplicação que utiliza(não sei nem se o Nominatim
>> > suporta), porém ela está documentada na wiki.
>> > Como valor iria somente "204" do "Sala 204", "204;205" do "Salas 204 e
>> 205".
>> > Quando ao "Conjunto 501", teria que ser addr:unit=501.
>> > Peraí, então o addr:door não funciona pra todos os casos? Exatamente,
>> não
>> > tem nenhuma etiqueta que cubra todos os casos para o "Complemento" de um
>> > endereço(que seria um addr:additional_information=*); creio que o mais
>> perto
>> > é colocar o endereço completo no addr:full.
>> > Eu estou aberto a sugestões, mas vou jogar duas idéias aqui:
>> > 1. Retirar o campo para "Complemento". (falando nisso, alguém sabe onde
>> os
>> > usuários atualmente colocam o complemento? Provavelmente no
>> addr:housename,
>> > certo?
>> > 2. Ao invés de colocar o campo "Complemento", colocar "Apt/Sala" E
>> > "Conjunto".
>> >
>> >
>> >
>> > Em 12 de fevereiro de 2014 20:36, Fernando Trebien
>> > <fernando.trebien em gmail.com> escreveu:
>> >>
>> >> Eu mudei a tradução de "nome da casa" para "complemento", isso já deve
>> >> ajudar.
>> >>
>> >>
>> >> Eu duvido que eles localizem a interface (com tantas coisas ainda por
>> >> fazer), já que na maioria dos países europeus e na América do Norte
>> >> essa é a ordem dos campos do endereço.
>> >>
>> >> Alguma aplicação já suporta a tag addr:door? O que iria nessa tag,
>> >> apenas um número ou uma descrição como "Sala 204", "Salas 204 e 205"
>> >> ou "Conjunto 501"?
>> >>
>> >> 2014-02-12 18:17 GMT-02:00 John Packer <john.packer7 em gmail.com>:
>> >> > Pessoal,
>> >> >
>> >> > Eu abri um relatório de bug para o editor iD, e gostaria que se
>> possível
>> >> > fizessem algum comentário que achem relevante na página do relatório.
>> >> >
>> >> > O relatório está no Github no seguinte link:
>> >> > https://github.com/openstreetmap/iD/issues/2124
>> >> >
>> >> > Abs,
>> >> > João
>> >> >
>> >> > _______________________________________________
>> >> > 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)
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> 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)
>>
>> _______________________________________________
>> 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/20140213/c29c2e35/attachment.html>