Migração software novo

[0e1]

Descrever nessa issue o processo de migração e seus impactos.

A principio em duas etapas:

• 1ª etapa: científico
• 2ª etapa: logístico

Lista:

• Avaliar a real necessidade de ST_AsGeoJSONb no retorno de api;
• Avaliar o melhor local para a versão simplificada de str_geouri_decode
• Avaliar a simplificação de api, removendo o parametro grid
• Avaliar mvwjurisdiction_synonym_default_abbrev: com a reformulação ficou mais fácil retornar um array com todas as abreviações disponíveis. Com isso, no site a seção para geocódigos equivalentes pode ser populada com todas as abreviações disponíveis.

Contribuem com lentidão:

• ST_Transform_Resilient: piora em +/- 2 vezes o retorno de api.

Necessidade de conversão para C:

• b32nvu_to_vbit
• vbit_to_strstd
• reduxseq_to_list
• natcod.vbit_to_baseh (necessidade especifica para encode SV logístico)
• natcod.baseh_to_vbit (necessidade especifica para decode SV logístico)

[ppKrauss]

Atenção: estamos migrando para o git privado, DNGS_WS ou DNGS_framework.

• Sobre ST_AsGeoJSONb, a principal motivação é suprir parametricamente as limitações de ST_AsGeoJSON, por exemplo incluindo sempre properties e name. Quanto a ser JSONb e não JSON, é uma questão de uso, se nunca for operar internamente e for sempre despachar dados para a API (necessariamente texto JSON em HTTP), pode sim manter tudo em JSON.
• Sobre str_geouri_decode: lembrar que houve sobrecarga no NGINX, queremos aos poucos migrar as decisões sintáticas para as funções internas, tanto por questões de performance (em caso de milhares de requisições) como por questões de mensagem de erro mais ricas e manutenabioidade (mais fácil no lado PostgreSQL).
• Simplificação de API: simplificar ao máximo numa primeira versão, depois vamos enriquecendo com calma. Ver com Camarões o que é essencial.