dgterritorio / RECART

GNU Affero General Public License v3.0
24 stars 15 forks source link

Objectos e classificações não obrigatórias #99

Closed SrNetoChan closed 3 years ago

SrNetoChan commented 3 years ago

As dúvidas deste issue report vêm da análise de um relatório na componente Consistência do domínio com os seguinte erros:

image

Gostaria de obter esclarecimento em relação a como proceder em casos de objectos previstos no modelo, mas não obrigatório para o nível de detalhe respectivo. Por exemplo, objectos de elementos associados à agua, como furos (6), camaras de visita (10) e sumidoros (11), estão previstos no modelo, mas não são obrigatórios para nenhum dos níveis de detalhe. Mas se forem recolhidos, podem ou não ser incluídos na base de dados?

Se podem ser incluídos, a que se refere estes erros?

image

Se não podem ser incluídos, qual o sentido de estarem previstos no modelo?

De igual forma, existem determinadas classificações não obrigatórias que também levantam dúvidas de como proceder. Por exemplo, nos edifícios, o ValorCondiçãoConstante prevê a classificação "Funcional", que não é obrigatória de indicar. No entanto, ficamos sem perceber se podemos ou não usá-la. A nosso entender, já que existe no modelo, achamos que faz sentido, no entanto o relatório de erros parece ter uma opinião contrária. O mesmo acontece com o ValorEstadoViaRodov, que tem multiplicidade 1 no entanto usar o valor 'Funcional' levantou erros no relatório.

Obrigado e bom trabalho

aserronha commented 3 years ago

Boa tarde,

Antes de mais, gostaríamos de frisar que este espaço ao ser utilizado como fórum pretende ser dedicado a questões das especificações técnicas. Questões relacionadas com o processo de homologação desta cartografia, nomeadamente aspetos específicos dos relatórios devem ser dirigidos para os contactos estabelecidos na tramitação do processo ou para homologacao@dgterritorio.pt.

A cartografia é constituída por um conjunto de objetos e atributos, organizados segundo o modelo de dados. A sua representação pode ser obrigatória ou opcional, estando esta possibilidade devidamente sinalizada no Dicionário de Objetos, em função do Nível de Detalhe. Nos processos de homologação de cartografia topográfica, a avaliação da DGT cinge-se à validação da conformidade relativa aos objetos e atributos obrigatórios, de acordo com as Normas e Especificações Técnicas publicadas pela DGT através do Aviso nº 11918/2019, de 24 de julho, e disponibilizadas na sua página da Internet em: https://www.dgterritorio.gov.pt/cartografia/cartografia-topografica/normas-especificacoes-tecnicas Assim, objetos ou atributos não obrigatórios que estejam representados, não são avaliados. Podem ser feitas algumas considerações no relatório de verificação de homologação sobre situações envolvendo estes elementos, mas não relevam para a concessão de homologação, a menos que se trate de um erro grosseiro detetado nas análises realizadas.

Não vamos detalhar cada item que apresentou mas daremos alguns exemplos genéricos de como são tratados no âmbito do processo de homologação. Assim: • valorElementoEdificioZ = 9 “Ponto mais alto” é erro porque a multiplicidade do atributo é 1 e o valor obrigatório para os 2 NdD é o valor 14 = “Topo do edifício”;

valorEstadoViaRodov= 3 “Em desuso” ou 5 “Funcional” não é erro. Haverá lugar a uma nota onde se indica que não é obrigatório e apenas deve ser usado quando há certeza desse estado. Não será considerado para efeitos de homologação.

valorCondicaoConst = 6 “Funcional” não é erro. Haverá lugar a uma nota onde se indica que não é obrigatório e apenas deve ser usado quando há certeza desse estado. Não será considerado para efeitos de homologação.

• Para a representação de objetos não obrigatórios e valores de atributos também não obrigatórios haverá lugar a uma nota onde se indica que a representação não é obrigatória. Não será considerado para efeitos de homologação.

O modelo destas especificações não pretende ser condicionador da representação cartográfica, mas pretende normalizar o suficiente para que a cartografia tenha uma utilização tão transversal quanto possível.

Cumprimentos

SrNetoChan commented 3 years ago

@aserronha Obrigado pela pronta e extensa resposta. Desculpa se a pergunta de alguma forma extravasou o objectivo deste bug tracker.

Em relação ao modelo, tendo em conta o que referiste em relação ao ValorEstadoViaRodov, penso que no dicionário de objectos a multiplicidade para esse campo deverá ser de [0...1], não?

Agora que reparo, aparentemente na base de dados (no DDL) o campo não está como NOT NULL confirmando essa ideia.

aserronha commented 3 years ago

@SrNetoChan compreendemos as dúvidas porque a abrangência deste modelo serve múltiplos propósitos. A resposta anterior foi editada para simplificar um pouco. O que está escrito como "erro" em cabeçalhos do relatório por vezes pode ter uma conotação diferente nos resultados desse âmbito.

Para efeitos de homologação, não é considerado como erro a representação de objectos ou utilização de atributos não obrigatórios nas Especificações Técnicas. Esta opção foi suportada pelas solicitações das empresas justificando que os clientes pretendem mais informação do que a prevista no modelo obrigatório e pelo facto de não querermos que a cartografia homologada seja muito diversa da que se usa efetivamente no dia-a-dia.

No âmbito da Homologação temos o cuidado de tentar diferenciar alguns atributos que consideramos mais suscetíveis. Assim, alguns objectos ou atributos identificados na análise automática não são considerados erro mas, dada a importância de alguns atributos como o “Funcional”, para estes, no relatório de Homologação segue uma anotação em que se chama a atenção para esse aspeto.

A coerência dos dados num momento futuro em que os queiramos usar estará baseado no modelo obrigatório.

Agora quanto à questão, primeiro tem de se olhar para a multiplicidade em abstrato, considerando os fenómenos no mundo real. Uma estrada tem sempre apenas um dos estados definidos, não fazendo sentido ter vários nem não ter nenhum, mas devido às opções de produção dessa informação, apenas um valor da lista de códigos é permitido. Na maior parte dos casos este campo vai estar vazio, o que obriga a que, embora a multiplicidade do objeto seja 1, o campo na base de dados possa ser nulo. O dicionário de objetos reflete o modelo lógico e físico e tenta de alguma forma esclarecer obrigatoriedades. Na base de dados é suposto já estar espelhado o que pode ou não ser nulo na implementação física.

Referência: https://www.dgterritorio.gov.pt/recart/TRANSPORTES%20(Transporte%20rodovi%C3%A1rio)/SegViaRodov.html#page_valorEstadoViaRodov