Korrekt topologi er et meget viktig kriterium for at det skal være mulig å lage en fornuftig eksport til SOSI-formatet.
SOSI-formatet er et GIS –format, og har en helt annen oppbygging av geometri enn hva man finner i DAK –systemer. Det er enkelt å tegne noe som ser bra ut i AutoCAD, men når man skal i gang å overføre de spatiale dataene over til et GIS-format som SOSI, så må man på et vis sørge for at geometrien i DAK-systemet er tegnet korrekt.
Følgende regler må følges for at SOSI-eksporten kan oversette geometrien korrekt til SOSI;
Grenselinjer av samme SOSI-objekttype skal ikke ligge dobbelt noe sted. Men grenselinjer av forskjellige SOSI-objekttyper må gjerne ligge dobbelt. Planens begrensning skal for eksempel ligge oppå formålsgrensene som ligger i planens yttergrenser.
Det skal ikke forekomme noen løse ender eller blindnoder. (Med unntak av juridiske linjer). Det betyr at alle start- og endepunkter på grenselinjene skal treffe nøyaktig en annen grenselinje eller seg selv. Det anbefales å bruke ”Snap to Nearest” for å treffe nøyaktig dersom man skal legge et område inntil et annet, og knutepunktene ikke legges til et eksisterende knekkpunkt på grenselinjen. Det vil lages et nytt knutepunkt på den grenselinja som snappes til automatisk.
Dersom disse to reglene følges når man tegner grenselinjer, vil man ha en sammenhengende topologi av grenselinjer som avgrenser ”vanntette skott”, som så skal fylles med flater.
For flatene er det en regel som må følges, og det er at alle grip-punktene (de blå punktene som kommer opp når flaten er valgt), må være sammenfallende med grippunktet til grenselinjen(e) som avgrenser flaten.
Dersom det mangler et grippunkt i flaten, eller det er et for mye, kan man markere flaten, høyreklikke med musa, og velge legg til eller fjern punkt.
For hver type grenselinje finnes det en tilsvarende flatetype. I tillegg har man juridiske linjer og andre typer linjer som ikke har tilhørende flater.
De ulike grenselinjetypene med tilhørende flater ligger på uavhengige lag som vist i figuren under.
Norm for fremstilling av reguleringsplan etter PBL 1985 - farge og skravur. Tilsvarende gjelder de ulike objekttypene etter PBL 2008, men her er det mange flere slike uavhengige lag ettersom det er mange flere objekttyper definert i objektmodellen til SOSI 4.1, 4.2, 4.3 og 4.5.
Ved å ha et eget verktøy for å tegne hver av disse objekttypene, vil man kunne skille ut de forskjellige objektlagene som er vist i figuren, som uavhengig av hverandre. Verktøy for å legge ut flater, ser kun grenselinjer av tilsvarende objekttype når flatens utstrekning skal finnes, og grenselinjer ser kun andre grenselinjer av samme objekttype når man beregner knutepunkter hvor linjene møtes.
Knutepunkt i kryss
For å illustrere forskjellen på disse tegneverktøyene/SOSI-objekttypene, kan man gjøre den enkle øvingen som er vist i Figur 11. Tegn først to kryssende linjer av typen RbFormålGrense, og se at de får et felles knutepunkt der de krysses. Tegn så en RbFormålGrense og en RbFareGrense, og se at de ikke får noe knutepunkt der de krysses. De ”ser” hverandre ikke, og kan derfor ligge på uavhengige lag som vist i figuren under.
Overlappende flater av ulike objekttyper
En annen måte å illustrere det på, er å gjøre øvingen som er vist i figuren over. Tegn et avgrenset område med funksjonen RpFormålGrense, og et annet avgrenset område med funksjonen RpFareGrense.
Prøv deretter å fylle formålgrensen med en flate av typen RpFormålOmråde, og se at den ikke ser faregrensen, men fyller området som er avgrenset av formålsgrensen. Tilsvarende for faregrensen som kan fylles av en flate med objekttypen RpFareOmråde.
Man kan ikke fylle området som er avgrenset av formålsgrensen med en flate av typen RpFareOmråde ved hjelp av verktøyene på knapperaden.
Dersom dynamisk geometrikontroll er skrudd på i «Prosjektinnstillinger» -ribbonpanelet, så vil programmet sørge for at linjer brytes i knutepunkter, doble linjer fjernes, linjer som skal henge sammen joines, flater oppdateres og feil påvises.
En del kommuner benytter nå WinMap eller GisLine for å kontrollere planen fremfor eller i tillegg til SosiKontroll.
Det man kan få problemer med da, er at punkter som ligger snappet til plangrensen i AutoCAD, feiler kontrollen i nevnte programmer fordi de etter eksport til sosi havner utenfor plangrensen. Dette skjer fordi koordinatverdiene avrundes til nærmeste hele centimeter (om man har valgt ..ENHET 0.01 på eksport), eller hele millimeter (..ENHET 0.001).
Dersom sosiformatet hadde benyttet full flyttallspresisjon på koordinatverdiene slik som er vanlig i spatial-databaser og i GML-formatet, samt internt i GIS- og DAK-systemene, så ville problematikken vært unngått.
Vi har forhørt oss med Miljøverndepartementet og statens kartverk, og har fått følgende svar:
Avrundingsproblem og nøyaktighetskrav på
arealplaner.
MD kommer til å sørge for at det blir en klarere
formulering i veiledningsmateriellet ved neste revisjonsrunde rundt denne
problemstillingen.
I NPAD del 1 står: " Arealformålsflater danner en
sammenhengende «mosaikk» innenfor planavgrensningen til planen. Alle arealformål
i ytterkant av planen, skal ha formålsgrense mot planavgrensningen og denne
formålsgrensen skal ha identiske koordinater med
planavgrensningen."
Dette kan løses på 2 måter når det gjelder linjer:
1.
Forlange at det er et eksakt punkt på
planavgrensningskanten
2.
Tåle en avrundingsfeil på linjer, at de ikke blir eksakt sammenfallende med
planavgrensningen. (unøyaktighet er så liten at den ikke betyr noe for planen
uansett).
MD mener at det er tilstrekkelig å velge alternativ 2 for linjegeometri.
Når det gjelder alle typer flater (som for eksempel hensynssoner og formålsflater)må disse sammenfalle eksakt med planavgrensningen. Her er det ikke rom for unøyaktigheter.
En reguleringsplan bør operere med nøyaktighet på cm nivå, og ikke mer detaljert enn det.
Med vennlig hilsen
Hilde Johansen Bakken
seniorrådgiver
Miljøverndepartementet
Avdeling for regional planlegging
Vi har aktivert kontrollen "Legg til punkter på geometri som overlapper knekkpunkter i annen geometri" som standard i Focus Arealplan slik at man får lagt inn punkter langs plangrensen automatisk når man bruker plangrensefunksjon og geometrikontroll.
Funksjonaliteten er en to-stegs prosess:
Første steg er å få oppdatert plangrensen via plangrensefunksjonen slik at denne følger formålgrensene.
Andre steg er bakt inn i selve geometrikontroll-funksjonen hvor punkter fra plangrensen legges inn i objekter som følger plangrenseforløpet, og punkter fra linjer som ligger på plangrensen blir satt inn på plangrensen:
Vi får på den måten tilfredsstilt kravet om eksakt plangrenseforløp for all linje-geometri som ligger på plangrensen. Vi har valgt å inkludere juridiske linjer i dette systemet selv om MD sier det er greit å lempe på kravene her fordi kontrollen til WinMap ikke gjør dette skillet. Vi behandler også alle objekter innad i planen med denne metoden.
Når man øker kompleksiteten og legger til bestemmelsesgrense, og frisiktlinje, så øker også antall punkter som må legges inn i alle topologi-lagene:
Det kan være nødvendig å oppdatere plangrensen underveis når man legger til nye objekttype-lag som ligger på plangrensen slik at plangrenen gjenspeiler punktene fra dette laget.
Alternativt til automatisk innsetting av punkter, har man og mulighet for kun påvisning av nødvendige punkter i henhold til alternativ 2.
"Marker punkt som mangler på plangrense..." markerer punkter som mangler på plangrensen og i øvrige objektyper som ligger på plangrensen. Denne funksjonen kan benyttes om man ikke har aktivert "Legg til punkter på geometri langs plangrense" dersom man ønsker å legge inn punktene manuelt.
Rutinen som markerer punkt som mangler på plangrense går igjennom alle objekter som ligger på plangrensen, og ser etter punkter som ikke finnes på plangrensen:
Vi får mer markert to punkter som mangler på plangrensen.
Vi har og en kontroll som går igjennom alle linjer som ligger på plangrense og markerer punkter fra plangrensen som ikke er gjenspeilet i linjen:
Punkt markert med grønt representerer manglende punkt på linje hvor det finnes punkt på plangrensen.