centroids Archives - vanderpol-consulting.com

26 February, 201012 February, 2018

BGT-boundary, a pragmatic approach

I’ve written a couple of posts about the BGT-project which I’m working on lately. A recurrent topic, when speaking about the BGT, is: “where should the border polygon be situated ?”

Frist suggestion is the cadastral border. This is also an authentic registration and a good solution for two municiplalities. I’m involved with a project at one of the provinces and they “slice” through municipalities with their provincial roads, that makes the cadastral border less useful.

Users of the provincial map are among others the departments of road- and greenmanagement. Besides surveying the topography, that is situated in a corridor along the road, the road- and greenobjects are important for these maintenance maps. Sometimes there is more green managed than is owned by the province – imagine a ditch that is mown completely, while the cadastral borderline is in the center of the ditch. Currently many road crossings are tranferred into roundabouts, and therefore the province needs to buy pieces of land from municipalities or private owners. The new cadastral situation will take some time to become established and therefore the cadastral border isn’t up-to-date.

In our project we’ve taken a pragmatic approach: we use the outside topographic lines in the corridor maps to build the polygons. In some cases we have to add supporting-lines to close the polygons. If the BGT border polygon has been defined than we will know which polygons needs to be splitted. The current maintenance and cadastral borders are left out of the proces for now. Also buildings, fences, roadlines that a partly on the map, but outside the provincial maintenance area are left out of polygon creation.

With this approach we can create the object oriented map and use the geometry of road- and greenobjects to connect to maintenance-data.
In the meantime still discussing with the GBKN Foundation, municipalities, waterboards, National Road Administration and the Ministry of Housing, Spatial Planning and the Environment about the BGT border polygon.

18 December, 200912 February, 2018

BGT-meeting with Geonovum

In my previous post about the BGT-project which I’m working on lately, I wrote about the interest from the various local & regional discussion groups and the meeting that had been planned with Geonovum.
This post is a very short recap of that very interesting meeting.

After the introduction of the workflow ( see previous posts ) the discussion was started around the question: “where should the border polygon for the BGT be situated ?”
The current drawings are along provincial roads, including the roads, cycle-tracks, ditches, terrains etc. They have more data than strictly inside the cadastral parcel of the province.
If we use the cadastral parcels as boundary, than we are using a polygon that is also part of an other national registration. We know from the pilot that sometimes areas outside the parcels are maintained by the province, also the reverse is true. It is also not practical to put the boundary on top of other topographic lines, because un-expected results can happen during cleanup and polygon creation.
Right now it is the idea to use virtual boundaries. For the future it is important to store them in the registry as well.

In the pilot was proven that there is sufficient classification in the current drawings to define the borders of the IMGeo-areas. Centroides are used to classify the areas themselves.
There is a need to add more attributes to the centroides, than strictly necessary for the IMGeo-model.
It is of course no problem to store more info in the own database, if these attributes are translated into the desired attributes when uploading into the national registry.
Also the province has a greater level of detail in their point symbols, than strictly necessary.
No problem as well.

It is also possible to send those extra information to Geonovum. They could discuss to see if the model can be extended. In the summer of 2010 the BGT model will be established and there will be a new version of IMGeo.

29 November, 200912 February, 2018

From AutoCAD Map DWG to BGT conform IMGeo ( part 2 )

I’ve already blogged a couple of times about the BGT-project which I’m working on lately.

Structuring of the data goes very well, the first test-migrations with AcClassify into the Oracle Spatial database has been successful last week and the data can be viewed in ArcGIS-desktop and the webviewers.
That I was clumsy enough not to config the database limits properly and that the Oracle tables have to be registered into SDE, that’s peanuts 😉

They’re looking over our schoulders from the various local & regional discussion groups, because the BGT keeps ( almost ) everyone busy these days.
In two weeks there is a meeting where people from Geonovum – the brains behind the IMGeo-model – will attend as well, because they are very interested in feedback from the field.

27 October, 200912 February, 2018

AutoCAD Map – Centroids, Topology and Polygons

In my previous post AutoCAD Map – Break, Trim and CleanUp I’ve blogged about the process to structure the drawings.
This blog is about classification and creation of the polygons.

First we’ve created the centroids, AutoCAD points with attribute information in conformity with the IMGeo-model.
Such a centroid for a Wegdeel contains for example attributes like IDentificatie, objectBeginTijd, status, relatieveHoogteligging, typeWeg etc.
Next to it there are centroids for Spoorbaandeel, Waterdeel, Terreindeel, Kunstwerkdeel and Pand. These Pand-objects come from the Basisregistratie Adressen Gebouwen ( BAG ) by the way.

Further a Polygon Topology has to be created. Herewith we also use a Wizzard interface, where the structured linework are the links which the centroids are joined.
If there are lines not properly closed, than the Topology process comes with an error. Likewise if centroides are missing or double.
The Topology model is converted into MPolygons, with the IMGeo classification from the centroids copied to them. These MPolygons are migrated as polygons into the Oracle database using AcClassify.

more about that in the next post