Overlappende hensynsoner

Fra Focus Arealplan
Revisjon per 25. aug. 2019 kl. 18:20 av Øystein (diskusjon | bidrag)
Hopp til: navigasjon, søk

Hensynsoner av samme type men ulik kodeverdi (formål) kan overlappe hverandre, og dermed krysse hverandres grenser. Focus Arealplan har opprinnelig håndterte dette ved hjelp av et system for å legge til ekstra representasjonspunkter for flatene slik at geometrikontrollen sørger for at flaten får anledning til å krysse en annen flates grense som vist på denne siden Legg til rep.punkt.

Vi har imidlertid fått tilbakemelding fra kartverket at grenselinjer for hensynsoner ikke skal brytes i knutepunkter, og vi har derfor lagt til en ny innstilling i Options/Focus Arealplan:

Splitthensyngrenser.png

Når 'Splitt hensyngrenser for hensynsoner' er deaktivert vil geometrikontollen unngå å bryte grenser for hensynsoner i knutepunktene slik at de kan danne lukkede polygoner rundt hensynsonene. Hensynsonene kan dermed være overlappende uten bruk av ekstra representasjonspunkter.

Det finnes tilfeller, spesielt langs plangrensen der man vil ende opp med dobbel geometri for disse grenselinjene, og man vil da få feil i SOSI-kontroll. Disse feilmeldningene skal i følge kartverket sees bort ifra.

Mal:Pre2


Hei!

Det er riktig som dere påpeker at sosi-formatet krever at kryssende linjer med samme objekttype skal splittes, men for plandata kan denne regelen ikke anvendes på hensynssoneflater. Man risikerer å lage flater som ikke finnes i plankartet, og man kan vanskelig etablere korrekte flater hvis flaten(e) av en eller annen grunn fjernes eller blir borte. Hvilke linjer hører til flaten?

For henssynssoner må man av denne grunn akseptere multiple flater som overlapper og der flategrensene gir melding om dobbel geometri. I sosi-kontroll må man aktivere «Benytte objekttype i dobbel geometri» som vist nedenfor. Hvis man likevel får melding om doble linjer, skal melding om doble hensynssonegrenser aksepteres (selv om SOSI-kontroll melder feil, er ikke det nødvendigvis riktig). SOSI-kontroll er ikke så intelligent at dette kan kodes inn i def-filene. Hvis SOSI-kontroll skal fange dette må man hardkode det i programmet. Siden SOSI-kontroll nå skal videreutvikles til å omfatte også GML vil ikke det skje med det første, dessuten er Plan 5.0 er på trappene  I Plan 5.0 er det aktuelt å bruke heleid geometri for hensynssoner, og da vil denne problemstillingen ikke være aktuell.


Hilsen


Berit N