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 <arstof...@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 <arstof...@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 <arstof...@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 <nao...@gmail.com>: >>> >> >> > 2014-02-13 12:51 GMT-02:00 Augusto Stoffel <arstof...@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@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) _______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
