Pt:Qualquer etiqueta que desejar

Sinta-se à vontade para inventar novas etiquetas! Se você quiser marcar algo que seja Verificabilidade e mapeável no OpenStreetMap, mas não exista um esquema de marcação para isso, você pode inventar e usar novas etiquetas. Mesmo etiquetas que são populares hoje em dia já foram usadas pela primeira vez, muitas vezes sem passar pelo processo de proposta.

No entanto, isso não significa "sinta-se à vontade para ignorar os esquemas de etiquetas existentes e começar a marcar farmácias com unicorn=parking_lot". Além disso, não é aceitável usar Mapear para o renderizador – não use etiquetas bem estabelecidas indevidamente apenas para forçar algum comportamento em algum consumidor de dados. E, claro, alterar unilateralmente a definição de etiquetas ou chaves existentes não é aceitável, portanto, tenha cuidado ao inventar um novo valor para uma chave existente.

Observe que a maioria dos recursos de interesse geral já são recursos de mapa estabelecidos e é recomendável usar as Etiquetas fornecidas. Caso contrário, outros usuários podem eventualmente converter suas contribuições para se adequarem a esse esquema.

Documentando tags que não estão nos recursos do mapa

Artigo principal: Criando uma página descrevendo chave ou valor

Então você seguiu as boas práticas e pesquisou no Wiki, características do mapa, características propostas, características rejeitadas, relações propostas e arquivos das listas de discussão e ainda não consegue encontrar uma etiqueta para o que gostaria de mapear? Taginfo é provavelmente o repositório mais útil de sugestões de etiquetas. Ele lista as etiquetas realmente usadas no banco de dados e com que frequência elas foram usadas. Também lista outras etiquetas que foram usadas em combinação com qualquer etiqueta específica em um único objeto.

Lembre-se de que o OpenStreetMap não possui nenhuma restrição de conteúdo sobre etiquetas que podem ser atribuídas a nós, vias ou áreas. Você pode usar qualquer eituqueta que desejar, mas por favor, documente-as aqui no wiki do OpenStreetMap, mesmo que sejam autoexplicativas. A documentação permite que outras pessoas encontrem suas feições ou até mesmo corrijam erros de mapeamento que encontrarem perto de você.

A documentação é especialmente útil posteriormente, se alguém propor uma marcação para o superconjunto da funcionalidade que você está adicionando. Assim, suas experiências e funcionalidades podem ser incorporadas ao processo de proposta e, em casos extremos, até mesmo convertidas para o novo esquema, se aceito. Documentar essas novas marcações não é obrigatório, mas é útil e proveitoso.

Escolhendo etiquestas para usar

Por exemplo, se você quisesse mapear todos os ninhos do esquilo voador siberiano, em perigo de extinção, bastaria criar uma página endangered_nest=Siberian_flying_squirrel e documentar nessa página aquela página para que ela é usada. Esteja preparado para que alguém possa posteriormente propor um esquema diferente e mais estruturado para documentar outros aspectos da vida de espécies ameaçadas, uma etiqueta que permita documentar também as descobertas de seus excrementos – um caso usado para proteger áreas de qualquer construção – e você acabaria convertendo suas entradas antigas.

Você pode consultar, por exemplo, o padrões IOF para padrões de classificação usados ​​em mapas de orientação, para ver se eles são úteis e se sua nova etiqueta pode ser compatível com as necessidades desses usuários. É provável que existam outros documentos semelhantes.

Quando criar uma proposta

Você deve criar uma proposta para sua feição se:

1. Sua feição for de interesse geral, ou
2. Você não tiver certeza de como modelá-la, ou
3. A última proposta de etiqueta foi rejeitada, ou
4. Você quiser alterar o significado de uma etiqueta já em uso
5. Você quiser coletar feedback de outros mapeadores, incluindo pessoas de diferentes regiões

(Observe que criar uma proposta não é um requisito para que sua feição apareça no mapa principal, nem um processo de proposta bem-sucedido é uma maneira garantida de colocar sua feição no mapa principal. No entanto, se sua feição passou pelo processo de proposta e foi aceita pela maioria, é claro que você terá muito mais pessoas solicitando que a feição seja exibida, aumentando assim as chances de ela ser renderizada nos mapas principais.)

O que não mapear

As entidades no banco de dados do OpenStreetMap devem estar relacionadas a alguma propriedade geográfica ou objeto com características geográficas. Por exemplo, adicionar a localização de uma estação base de hotspot WLAN é considerado aceitável, mas marcar muitos nós ao redor dela com os níveis de sinal percebidos é indesejável. É melhor armazenar essas informações em um serviço separado.

Considere o consenso da comunidade documentado na página de boas práticas sobre verificabilidade. Não mapeie características históricas, temporárias ou hipotéticas, dados opinativos como classificações ou legislação.

Observe as limitações no mapeamento de informações privadas.

Como nomear novas etiquetas

Esta é uma tentativa de documentar as convenções existentes usadas por quem inventa novas etiquetas, com base nas etiquetas em recursos de mapas atuais e propostas recentes. Correções e formas adicionais que as pessoas tenham visto em uso generalizado serão aceitas com prazer!

Uma Etiqueta é um par de strings Unicode obrigatório por software (chave, valor), geralmente escrito como chave=valor em discussões.

Dependendo se o que você deseja se encaixa em alguma categoria já definida, você pode definir uma nova chave principal, um novo valor para uma chave existente, uma nova propriedade modificando uma ou mais combinações de chave/valor ou um novo método de refinamento.

Em caso de dúvida sobre definir algo totalmente novo ou usar alguma combinação existente com novas propriedades ou refinamentos, considere:

• novas propriedades não devem modificar características estabelecidas de maneiras que contradigam as expectativas de senso comum sobre elas
• a menos que esta seja uma definição muito específica, com limites culturais e geográficos que não fariam sentido em outro país, tente ter uma visão global (não centrada na Europa, não centrada na Grã-Bretanha, não centrada nos EUA...) para evitar que a tag se torne skunked.

Convenções sintáticas para novas etiquetas

As strings escolhidas para a parte chave têm algumas formas convencionais:

• Idealmente, uma chave é uma palavra, em letras minúsculas, usando o inglês britânico, se possível.
• Quando isso não for possível, uma chave deve ser um conceito, cujas palavras são separadas por sublinhado. Isso evita alguns problemas de espaços em branco e geralmente ocorre porque os profissionais do OSM também tendem a ser programadores e gostam da sintaxe.
• Alguns caracteres têm significados especiais em vários contextos, e usá-los em chaves provavelmente causará todos os tipos de problemas. Os seguintes caracteres estão entre os desaconselhados para uso em chaves: =, +, /, &, &, &, > ;, ', ", ?, %, #, @, \, . e ,.
• É preferível evitar também espaços em branco como caracteres na chave (espaços, enters, tabulações e assim por diante) e outros caracteres estranhos, como caracteres não imprimíveis.
• Algumas chaves mais complexas são construídas a partir de várias palavras ou conceitos separados por dois pontos. Eles devem ser legíveis naturalmente da esquerda para a direita; alguns padrões já são amplamente utilizados:
  1. Prefixo simples namespace, em um estilo semelhante ao de algumas linguagens de programação. Agrupa informações vagamente relacionadas de uma forma que não conflita com outras tags OSM. Ideal para importação de dados de outras fontes!
     • tiger:county=*, tiger:upload_uuid=* - tudo a ver com uploads de dados do US TIGER
     • KSJ2:lat=*, KSJ2:curve_id=* - etiquetas do Japan KSJ2 import
  2. Conjuntos de informações intimamente relacionadas, que juntas expressam um único fato composto por vários campos. Quase como uma propriedade. Ótimo para endereços e padrões de nomenclatura incomuns.
     • name:left=*, name:right=* - ruas com nomes diferentes em lados diferentes (w.r.t. forward way direction)
     • addr:housenumber=*, addr:street=* - tudo relacionado ao endereço de um lugar
  3. Qualificações por código de idioma. Veja Pt:Names#Localização
     • name:en=*, name:cy=* - os nomes em inglês e galês para um recurso
     • note:ja=* - uma nota especificamente em japonês
  4. Relativamente incomum. Padrão 2, mas feito de forma generativa, onde subpartes se referem a outras chaves definidas. Isso é quase meta-marcação. Quase.
     • source:name=* - a source para a etiqueta name é ...
     • source:ref=* - a source para a etiqueta ref é ...

Convenções sintáticas para novos valores

O formato e as convenções dependem se a etiqueta representa um recurso ou uma propriedade.

• Uma etiqueta pode representar um recurso separado (como highway) ou uma propriedade de um recurso (como width).

• Propriedades podem ter um grande número de valores possíveis, ou podem ser numéricas (por exemplo, width=2) ou podem ter uma pequena lista de valores válidos.
  • Nomes são um exemplo de valor de propriedade (por exemplo, a tag name=*), e esses valores são não estruturados e flexíveis, geralmente contendo maiúsculas e minúsculas, espaços e outros caracteres especiais.

• Características frequentemente assumem valores que refinam ainda mais a categoria do objeto do mapa (por exemplo, highway=motorway).
  • Para as etiquetas objetos, o valor segue convenções de formatação semelhantes às usadas para chaves:
  • Idealmente, o valor de uma etiqueta de objeto é uma palavra, em letras minúsculas, usando o inglês britânico, se possível.
  • Quando isso não for possível, o valor de uma etiqueta de objeto deve ser um conceito, cujas palavras são separadas por sublinhado.

• Às vezes, o ponto e vírgula ";" é interpretado como separador de vários valores – veja separador de valores de ponto e vírgula.

Refinamento e namespaces

Há um padrão comum de refinamento iterativo em uso em muitos esquemas de marcação, que tem a vantagem de que o esquema pode crescer ao longo do tempo para ser cada vez mais descritivo, embora ainda seja compatível com versões anteriores:

office=government

government=emergency

Cuidado com conflitos com outros esquemas de etiquetas ao seguir este padrão. O refinamento também pode ser feito por meio do uso de namespace.

Caracteres

O banco de dados aceita quaisquer caracteres Unicode (UTF-8) para chaves e valores. No entanto, a prática recomendada é que chaves (como highway) e valores de classificação (como trunk_link) usem caracteres ASCII minúsculos, sublinhados e dois pontos. É uma boa ideia evitar caracteres que causarão problemas em vários softwares para estas strings:

• Espaço em branco  : Use sublinhados '_' em vez de espaços em branco, evite espaços em branco no início e no fim das chaves;
• <>&/+?#%'"\ : Caracteres especiais em XML, HTML e/ou URLs ou usados ​​para citações devem ser evitados;
• =  : Como ele é usado em muitos lugares como caractere de separação entre a chave da tag e o valor da tag, evite o sinal de igual;
• ;  : O uso de ponto e vírgula está em discussão.

Valores de formato livre (por exemplo, como os usados ​​para a chave name) usam quaisquer caracteres que você possa imaginar. Evite espaços em branco no início e no final dos valores.

Guia de estilo?

Você pode tratar isso como um guia de estilo, se quiser, mas na verdade não é. Em última análise, a interpretação fica a critério do usuário, e o único princípio que realmente se aplica é KISS ("Mantenha a simplicidade, estúpido!"), ou, alternativamente, "Faça a coisa mais simples que possa funcionar". Quanto mais conciso e simples, melhor, se você quiser que mais pessoas adotem sua etiqueta/proposta.

Veja também

• Just map
• Boas práticas
• Proposal process
• How to invent tags by Jochen Topf
• Creating a page describing key or value
• Order of key parts
• Homonymous keys

Termos relacionados: ‹ any tags you want › ‹ whatever tags you want › ‹ whatever tags you like ›