Publicar atributos no GeoJSON

[ppKrauss]

Por exemplo, conforme preserv-BR/data/ES/VilaVelha/_pk0007.01/make_conf.yaml temos atributo nsvia_name e outros, mas nenhum comparece no GeoJSON final.

PS: em casos como parcel de Vila Velha, sem numeração predial ou nome de rua, talvez seja relevante incluir o código de referência, que no caso seriam ref.CODGIS e ref.LOTE.

[0e1]

Por exemplo, conforme preserv-BR/data/ES/VilaVelha/_pk0007.01/make_conf.yaml temos atributo nsvia_name e outros, mas nenhum comparece no GeoJSON final.

• nsvia_name: não aparece pois não está em https://github.com/digital-guard/preserv/blob/main/src/ingest-step1-ini.sql#L1525. O que está é ns_name, que é mais comum nos make_conf (exemplo _pk0042.01). Falta documentação de atributos padronizados nesse caso (e para alguns outros layers, como building: docs/pt/ftypes.md).

• Outros: se não não forem atributos padronizados, teriamos que incluir todos os atributos que estiverem em proprietes para exibi-los no geojson final.

PS: em casos como parcel de Vila Velha, sem numeração predial ou nome de rua, talvez seja relevante incluir o código de referência, que no caso seriam ref.CODGIS e ref.LOTE.

Se não forem atributos padronizados, não há como inclui-los como ref. Ou a intensão e colocar todos os atributos listados e que são diferentes dos padronizados sob um chave ref no geojson final?

[ppKrauss]

Por hora vamos manter a "padronização legada", ou seja, precisa fazer alguma gambiarra para aceitar nsvia_name e outros. Pelo que entendi do código, basta incluir no jsonb_build_object, visto que elimina os NULLs depois.

[0e1]

Pelo meu entendimento as properties padronizadas (e variações legadas, tais como nsvia_name e ns_name) para cada ftype já estão sendo consideradas pela função ingest.feature_asis_export(p_file_id bigint) que prepara os dados para publicação.

No entanto a função desconsidera as propriedades que são diferentes das padronizadas.

Por exemplo, tomando o caso inicialmente citado de preserv-BR/data/ES/VilaVelha/_pk0007.01/make_conf.yaml e seu layer block:

  block:
        subtype: none 
        method: shp2sql
        file: 3
        sql_select: ['gid', 'DISTR', 'SETOR', 'QUADRA', 'CODGIS','geom'] 
        orig_filename: QUADRAS/QUADRAS
        codec: SHP~Latin1

Os 'DISTR', 'SETOR', 'QUADRA', 'CODGIS' não são padronizados e estarão em properties em feature_asis. Eles também devem constar nos arquivos publicados?

Se não, a issue pode ser fechada. Se sim, a função tem que ser ajustada impactando nas publicações já feitas. A impressão que fiquei das discussões foi ficar restrito as propriedades padronizadas e legadas.

[ppKrauss]

Os 'DISTR', 'SETOR', 'QUADRA', 'CODGIS' não são padronizados e estarão em properties em feature_asis. Eles também devem constar nos arquivos publicados?

Infelizmente não chegamos a padronizar tudo, quadras são informações secundárias e que ainda não foram padronizadas na AddressForAll... Ideal que tenha um identificador público, que se for conhecido pode ser name senão ref, cod_ref ou identifier.

É difícil avaliar o que cada fornecedor quis expressar com suas colunas, talvez consultas simples com COUNT(*) e COUNT(DISTINCT a,b) ajudem a tomar a decsão. Nesse exemplo DISTR deve ser distrito, SETOR e QUADRA concatenados devem compor um identificador único... No piro caso teríados :

       SELECT gid, concat(DISTR,':',SETOR,':',QUADRA) AS name, CODGIS AS ref,  geom  

[0e1]

Situação resolvida, conforme commits acima.