Now SchemaOrg have eg. https://pending.schema.org/termCode to complement a name in the context of DefinedTerm or CategoryCode.

Use also temporalCoverage, but checking the best format for CSV interchange. For ISO 3601 the open-end is possible by ".." in the future ISO version.

Suggestion:

[state|code ascii text +PK2;temporalCoverage +PK3; name text; region_code text; wd_id int +PK; ibge_id int +PK4; lexLabel ascii text +PK3; isCurrent boolean; info JSONb{bg:tomato}]

[region|code ascii text +PK2;temporalCoverage +PK3; name text;fullname text;wd_id int +PK;lexLabel ascii text  +PK3;isCurrent boolean; info JSONb]

[city|name text;state_code ascii text +PK2;temporalCoverage +PK2; wd_id int +PK;ibge_id int +PK3;lexLabel ascii text +PK2;isCurrent boolean; info JSONb{bg:sandybrown}]

[wd_synonym|name text +PK; synonym_type ascii text  +PK;wd_id int +PK;ref;isOfficial boolean;info JSONb]

[state]2..*---1[region]
[city]1..*--->in[state]

[wd_synonym]*----1[state]
[wd_synonym]*----1[city]
[wd_synonym]*----1[region]

Está sendo usada como sigla complementar em https://github.com/OSMBrasil/CRP

Estudar o caso...

No CSV:

ZM,Região da,Zona Metropolitana de São Paulo,36,,Q1415666,zona.metropolitana.sao.paulo,,,Region,,,,,for use as CEP range [01000-000	09999-999]

Ops, faltou critério de "order by" em br-region-codes.csv... E melhor evitar uso da data, usar nome completo ou abreviação como critério de ordenação. Tal como nos estados, em 2 grandes grupos, primeiro as regiões vigentes depois as extintas.

Rebatizar regiões extintas conforme seu ano de criação, com prefixo RG seguido do ano.
Por exemplo RG1940-NE para a antiga Região Nordeste, definida em 1940.

Foi atribuído código de relation do município ao invés de estado.

Sugestão: criar página ou tabela.md com links e instruções para poder rapidamente conferir mapas, visualmente. Se for possível gravar thumbs com algum recurso OSM melhor.

A decisão por uso de data arbitrária como referência para organização do dataset (fundação da República) é razoável, mas como existe ainda vigente uma legislação relativa à ordem de precedência entre os estados brasileiros, convém dar preferência para esta última.

Segundo wikipedia:

• Bahia (1534)
• Rio de Janeiro (1565)
• Maranhão (1534, reconquistado em 1615)
• Pará (1616)
• Pernambuco (1534, reconquistado em 1643)
• São Paulo (1709)
• Minas Gerais (1720)
• Goiás (1748)
• Mato Grosso (1748)
• Rio Grande do Sul (1760)
• Ceará (1799)
• Paraíba (1799)
• Espírito Santo (1810)
• Piauí (1811)
• Rio Grande do Norte (1817)
• Santa Catarina (1738)
• Alagoas(1817)
• Sergipe(1820)
• Amazonas (1850)
• Paraná (1853)
• Acre (1962)
• Mato Grosso do Sul (1979)
• Rondônia (1982)
• Tocantins (1988)
• Roraima (1988)
• Amapá (1988)
• Distrito Federal (1960)

For linguistic use, "Estado do Acre", "Estado de São Paulo", etc.

Foi feita correção na Wikidata-SP corrindo polígono (ver #10) e, para demais estados, foi detectada atribuição equivocada de código wikidata,

• mudar tabela de colaborativa e oficial br-state-codes.csv
• atualizar dump_wikidata e dump_osm de SP
• atualizar demais suspeitos: AL, AM, GO, MG e talvez outros.

Sugestão: validar código IBGE contra dados Wikidata para garantir consistência.

Merge de #19, #20 e inclusão de novos campos. Definições:

• km2: territorial area in km2. http://wikidata.org/entity/P2046

• borders: subdivisions that this item borders, by land. http://wikidata.org/entity/P47

• centroid_geohash: Centroid of the area, expressed as Geohash. http://wikidata.org/entity/Q511093

• utm_zones: UTM zones used to map in UTM system. http://wikidata.org/entity/Q56839305

• bounds_geohash: minimum bounding box rectangle, diagonal points expressed as Geohashes. http://wikidata.org/entity/Q6865426

• bounds_lat: minimum bounding box rectangle, extreme latitudes. http://wikidata.org/entity/Q6865426

• bounds_long: minimum bounding box rectangle, extreme longitudes. http://wikidata.org/entity/Q6865426

Incluir lib SQL e queries no src.

Assim que fixar padrão final para br-city-synonyms.csv, criar tabela similar (br-state-synonyms) para simplificar análise e recuperação de dados. A tabela de sinônimos também reforça a questão do controle terminológico — deixando a questão dos desmembramentos e redefinições espaciais por conta talvez de uma futura tabela (unificando estados e regiões tendo em vista que são espacialmente acoplados).

usar JSON canônico ou (supondo sempre JSONb portanto objetos canônicos) normalizado.
Por hora fechar na convenção do PHP. depois conferir com padrões.

Check where the upgraded GeoJSONs of OSM... See problems (wrong boundary lines) of this old backup... Example with an AC zoom case:

http://Wikidata.org é a nossa principal fonte de dados depois que nomes e códigos estão devidamente homologados. O presente repositório, a principio, é apenas um backup dos dados Wikidata. Pode também ser um recurso para manter versões estáveis da Wikidata, se houverem algoritmos de consistência e auditoria das atualizações realizadas.

Incluir cópias dos dados JSON em /data/wikidata como arquivos nomeEstado.json, e manter o atualizador de backups como state-codes/src/etc/dumpWikidata.php. Muito parecido com city-codes/src/etc/dumpWikidata.php.

Quando usuário Windows colabora, há risco de gerar modificação não-intencional sistemática nos arquivos, por inclusão do CRLF. Medidas para evitar o problema:

1. Convenção global do datasets-br, usar LF (Unix end-o-line)
2. Boa prática no git, git config --global core.autocrlf input
3. (mais importante!) mudar o .gitattributes

Convenção:

# Plase configure your git as Linux to properly handle line endings
#  git config --global core.autocrlf input

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Declare files that will always have LF line endings (Linux mode) on checkout.
* text eol=lf

# Denote all files that are truly binary and should not be modified.
*.pdf binary
*.png binary
*.jpg binary
*.zip binary

As regiões do brasil agrupam os estados, e portanto devem ser também listadas com suas respectivas siglas, N, NE, S, SE e CO.

Lembrar que os dados JSON são dataset dumps de outras fontes. Para enfatizar isso renomear data/wikidata para data/dump_wikidata.

• na pasta data/dump_wikidata usar as siglas de Estado que são mais populares que os próprios nomes nos web-services, solicitações de dados, etc.

• criar uma pasta nova data/dump_osm para incluir polígonos GeoJSON dos estados, obtidos por exemplo em polygons.openstreetmap.fr?get_geojson.py?id=326266, com o código da relação (326266) obtido via Wikidata-P402. Gravar os arquivos com extensão .geojson que o Github gera visualização automaticamente.

NOTA SOBRE COMPLETEZA DOS DADOS

Reparar que auditando, por simples
grep P402 data/dump_wikidata/* | wc -l (resultou em 24 na v1.2.0)
a falta de referência aos polígonos pode ser evidenciada. Algum trabalho de revisão e homologação também precisa ser feito antes de lançar a v1.3.0 com os polígonos.

• UFs correntes sem polígono indicado na Wikidata: AM, DF, MA.
• Idem todos os mapas históricos: FN, GB, GU, IG, PP, RB.

Principais sugestões pendentes no controle de qualidade e consistência com outros repositórios:

• reunir num só SQL conforme modelo https://github.com/datasets-br/datasets-br

• validar código IBGE contra dados Wikidata para garantir consistência. (já lembrado antes na issue #11)

• Cruzamento e consistência com municípios e com demais dados Wikidata.

• Avaliar se vale mudar campos de nome para manter padrão já usado por outros como https://github.com/mapaslivres/localidades ou fontes oficiais IBGE

• Avaliar o que fazer com dumps: passar para git OSM-BR ou manter por aqui (PostGIS com shapes IBGE).

Complemento à issue #15, referente a área. A zona utm é um código com demanda ainda nos dias de hoje, e fácil de se obter a partir dos dados PostGIS, que podem ser de origem do OpenStreetMap ou outra fonte.

Teste com NaturalEarth-10m-cultural

wget https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_admin_1_states_provinces.zip
unzip ne_10m_admin_1_states_provinces.zip
shp2pgsql ne_10m_admin_1_states_provinces.shp | psql postgres trydatasets

SELECT iso_3166_2, 
               round(st_area(geom,true)::numeric/1000000.0) area_km2, 
               array_to_string(  get_utmzone_names(geom), ' ') utm_name  
FROM  ne_10m_admin_1_states_provinces 
WHERE iso_3166_2 like 'BR-%';

Resultados: problema com área, compare com Wikidata,

lib

CREATE FUNCTION get_srname(p_srid int, p_reduce int default 0) RETURNS text AS $f$
   SELECT trim( (regexp_matches(srtext,CASE
      WHEN $2=1 THEN 'PROJCS\["[^"]*/([^"]+)"'
      WHEN $2=2 THEN 'PROJCS\["[^"]*/\s*UTM zone\s*([^"]+)"'
      ELSE 'PROJCS\["([^"]+)"' END
   ))[1] )
   FROM spatial_ref_sys
   WHERE srid=$1
$f$ LANGUAGE SQL IMMUTABLE;

CREATE FUNCTION get_utmzone(
  p_geom geometry(POINT)
) RETURNS integer AS $f$
  SELECT CASE
    WHEN p_geom IS NULL OR GeometryType(p_geom) != 'POINT' THEN NULL
    ELSE floor((ST_X(p_geom)+180.0)/6.0)::int
         + CASE WHEN ST_Y(p_geom)>0.0 THEN 32601 ELSE 32701 END
    END
$f$ LANGUAGE SQL IMMUTABLE;

CREATE FUNCTION get_utmzone_bydump(p_geom geometry) RETURNS integer[] AS $f$
  SELECT array_agg( DISTINCT get_utmzone(geom) )
  FROM ST_DumpPoints( p_geom )
$f$ LANGUAGE SQL IMMUTABLE;

CREATE FUNCTION get_utmzone_names(
  p_geom geometry, 
  p_type int DEFAULT 2
) RETURNS text[] AS $wrap$
  SELECT array_agg(get_srname(x,p_type)) 
  FROM unnest(get_utmzone_bydump(p_geom)) t(x)
$wrap$ LANGUAGE SQL IMMUTABLE;

Conforme log de atualização,

• DF: Q119158 ERROR, no osmId or P402 for DF. ERROR, empty json for DF.
• MA: Q1155409 ERROR, no osmId or P402 for MA. ERROR, empty json for MA.

Usando mapa oficial do IBGE de 2017.

CREATE FUNCTION lib.id_ibge2uf(p_id text) REtURNS text AS $$
  SELECT ('{
    "12":"AC", "27":"AL", "13":"AM", "16":"AP", "29":"BA", "23":"CE", 
    "53":"DF", "32":"ES", "52":"GO", "21":"MA", "31":"MG", "50":"MS", 
    "51":"MT", "15":"PA", "25":"PB", "26":"PE", "22":"PI", "41":"PR", 
    "33":"RJ", "24":"RN", "11":"RO", "14":"RR", "43":"RS", "42":"SC", 
    "28":"SE", "35":"SP", "17":"TO"
  }'::jsonb)->>$1
$$ language SQL immutable;

SELECT a_nm, array_to_string(array_agg(b_nm),' ') faz_fronteira_com 
FROM (
  SELECT DISTINCT a_nm, b_nm 
  FROM (
     SELECT lib.id_ibge2uf(a.cd_geocuf) a_nm, 
                    lib.id_ibge2uf(b.cd_geocuf) b_nm, 
                    ST_Relate(a.geom,b.geom) rel 
     FROM brufe250gc_sir a, brufe250gc_sir b 
     WHERE a.cd_geocuf!=b.cd_geocuf AND a.geom && b.geom
  ) t 
WHERE rel!='FF2FF1212'
ORDER BY 1,2) tt  group by 1 order by 1

Pode-se conferir os valores rel com a função lib.ST_Relate_summary().

PS: as relações são reduzidas a interseções de área com st_buffer(a.geom,0.0001), restando 51 casos de interseção tipo rel='212101212'.

Add time zones of each state.

Uma vez em produção e com comunidade usando, não podemos mais correr risco nem criar insegurança para a comunidade de usuários.

https://guides.github.com/introduction/flow/

A população corrente de uma divisão territorial revela a sua importância, segundo diversos critérios:

• Relevância humana: quanto maior a população, maior a quantidade de indivíduos merecedores do mesmo "direito à vida" e demais direitos fundamentais. A maioria dos indicadores de demanda por recursos básicos (ex. saúde e educação) também é proporcional à população.

• Democrática: quanto maior a população, maior a expressividade eleitoral dentro da nação.

• Econômica: forte correlação entre riqueza e população, dentro de uma região com mesmo perfil de distribuição de renda.

• etc.

De modo que filtros simples para interface, etc. podem requerer o uso de dados sobre população. Como a densidade de habitantes é uma métrica derivada igualmente importante, e a própria área da região outro parâmetro interessante para filtros básicos... Convém acrescentar ambas, área e população, viabilizando o cálculo da densidade populacional.

Problema de completeza com a Wikidata, no metadado de population (P1082) dos estados: grep P1082 data/dump_wikidata/*.json | wc -l resultando em 14.

Por hora a Wikidata seria apenas referência de validação, a fonte principal continua sendo IBGE.