Inclusão de itens relevantes

[ppKrauss]

A partir dos municípios-amostra pode-se eleger os tipos de geometria que serão submetidos ao "backup stable". Critérios obtidos por análise das contagens:

• apresentar minimamente tag wikidata ou tags name e type.
• quando não houver Wikidata, tipos permitidos:
  de relation: multipolygon, route, ou boundary;
  de way: building.

Os itens serão armazenados cada qual no seu arquivo GeoJSON, de modo que a nomenclatura das pastas e dos arquivos precisa ser controlada. Resumo:

• 1o nível de pasta, UF;
• 2o nível de pasta: nome do município convertido a partir do lexlabel em camel-case.
• 3o nível de pasta: tipo geral de map-feature: route, boundary, building, etc.
• 4o nível de pasta (conforme demanda): prefixo de Geohash (das geometrias depositadas na pasta).
• nome de arquivo: identificador permanente, iniciado por Q (wikidata) ou p (perma_id); ou identificador temporário, iniciado pela letra correspondente (r, w ou n).

Contagens de elementos interiores

Seleção de geometrias "inside", inteiramente contidas dentro dos limites do município.

São Paulo, stable.vw_sampa_test_report01

osm_type	tagtype	n	n_wikidata	n_name
r	boundary	104	99	104
r	multipolygon	12.693	31	369
r	route	553	23	541
w	building	12	1	1
w	site	2	0	2
w		1.597.580	548	83.042

Demais cidades do conjunto-teste, stable.vw_city_test_report01:

osm_type	tagtype	n	n_wikidata	n_name
r	boundary	138	15	138
r	multipolygon	369	12	89
r	route	149	1	143
w	busway	4	0	4
w	sewage	2	0	0
w	water	1	0	1
w		132.178	92	28.294

---

SQLs:

CREATE or replace VIEW stable.vw_city_test_report01 AS
  WITH t AS (
    SELECT DISTINCT 'Cidades' escopo, osm_id
     FROM stable.city_test_inside
     WHERE city_id != stable.getcity_rels_id('SP/SaoPaulo')
    UNION
    SELECT 'Sampa' escopo, osm_id
     FROM stable.city_test_inside
     WHERE city_id=stable.getcity_rels_id('SP/SaoPaulo')
  )
  SELECT t.escopo, 'r' as osm_type, tags->>'type' as tagtype
    ,count(*) num
    ,count(*) FILTER(WHERE tags?'wikidata') AS num_wikidata
    ,count(*) FILTER(WHERE tags?'name') AS num_name
  FROM planet_osm_rels INNER JOIN t ON t.osm_id=-id
  group by 1,2,3
  UNION
  SELECT t.escopo, 'w' as osm_type, tags->>'type' as tagtype
    ,count(*) n
    ,count(*) FILTER(WHERE tags?'wikidata') AS n_wikidata
    ,count(*) FILTER(WHERE tags?'name') AS n_name
  FROM planet_osm_ways INNER JOIN t ON t.osm_id=id
  group by 1,2,3

  ORDER BY 1,2,3,4
;

[ppKrauss]

Revisando:

1. Conforme definido no escopo desta primeria fase (ver README root) publicaremos apenas:
   pontos de endereçamento, designando ponto de interesse com dados de endereço postal;
   linhas relativas a vias que potencialmente apoiam endereçamento ou descrevam equipamentos sociais (portanto todas as roads incluindo ferrovias porém ainda não hidrovias); e
   polígonos dos municípios (menor jurisdição).

2. As tags serão utilizadas como filtro e classificador de grupo (juntando varias geometrias num só arquivo de GeoJSON).

3. O prefixo de Geohash será utilizado como classificador de grupo, e garantindo uma referência textual de proximidade entre endereços e suas roads

4. O prefixo de ref será utilizado como classificador de grupo nas roads estaduais e municipais.
   PS: é um tanto experimental, depende estritamente do que for convencionado "inside" e "outside" do município. Convém fazer isso primeiro apenas no estado PR. Cabe também rastrear todos os trechos de mesma ref, e por fim verificar o impacto sobre endereços, pois trechos municipais são rebatizados para nomes.

A seguir a sugestão final de convenções.

---

Convenções de filtragem adotadas

Além da restrição primária do item 1 acima, as tags permitem as seguintes filtragens e agrupamentos, conforme o tipo.

Filtragem de pontos:

• presença de key addr:street;
• presença de key addr:housenumber.

Filtragem de roads:

• presença da key highway ou da key railway;
• ausência da key boundary (determinam "falsa road").

Filtragem de polygon de município: tags IBGE, boundary, etc. auditadas e em conformidade com http://datasets.ok.org.br/city-codes.

Convenções para nome de arquivo

• Nome de "arquivo de cache": recebe o prefixo kx_. Qualquer que seja o tipo de arquivo, se for informação redundante ou metadados (ou seja não consiste em parte da representação stable do OSM), será considerado cache de dados. Caches típicos são aqueles que podem ser calculados por SQL a partir dos dados brutos fornecidos pelos demais arquivos.
  Exemplo: data/PR/kx_sumario.csv.

• Nome de arquivo de município. Dentro do path do município, arquivo único, formato data/${uf}/${municipio}/municipio.geojson.
  Exemplo: data/PR/Curitiba/municipio.geojson.

• Nome de arquivo de pontos. Dentro do path do município, diversos arquivos na forma data/${uf}/${municipio}/pt-${prefGeohash}.csv.
  Exemplo: data/PR/Curitiba/pt-6gky.csv.

• Nome de arquivo de roads. Dentro do path do município, diversos arquivos na forma data/${uf}/${municipio}/${roadTypeLabel}-${prefGeohash}.csv.
  Exemplo: data/PR/Curitiba/highway-6gky.geojson.
  - O rótulo de roadTypeLabel é determinado pelas keys disjuntas highway e railway, concatenando-se à key layer quando presente. Exemplos: highway, highway_layer, railway.
  - O prefixo Geohash da road (prefGeohash) é determinado pelo ST_PointOnSurface, que depois é aplicado a ST_Geohash, truncado nos 1 a 4 primeiros dígitos. No exemplo: 6gky. Eventualmente agrupamentos geohash podem representar intervalos (ex. 6g9-6gx) para balancear o tamanho dos arquivos.

• Nome de arquivo cache de road estadual. Dentro do path do estado (jurisdição estadual), diversos arquivos na forma data/${uf}/kx_roads/${roadTypeLabel}-${nome}.csv.
  Exemplo: data/PR/kx_roads/highway-PR-012.geojson.

• Nome de arquivo cache de road federal. Dentro do path raiz (jurisdição federal), diversos arquivos na forma data/kx_roads/${roadTypeLabel}-${nome}.csv.
  Exemplo: data/kx_roads/highway-BR-116.geojson.