BGT Archives - Page 2 of 3 - vanderpol-consulting.com

7 April, 201012 February, 2018

Again involved in a BGT project

Besides the BGT-project in Limburg, what has evolved from Pilot into Production fase, I’m involved in a couple of other projects where the BGT is an important component.

In existing geo-information systems, DWG is often used as format for large scale basemaps. For other processes in the organisation DWG’s have to be converted into Shape- or SDF-files. We are currently executing a research how to store and use this data from a central geo-database and we would like the structure to be BGT-ready.
More posts about this topic soon.

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.

16 January, 201012 February, 2018

BGT-news

The previous year was the year of BGT-research. A strategy document has been developped and currently signed off the all concerning parties.
In the comming year the strategy will be transferred into final documentation.
On the website of the Ministry of Housing, Spatial Planning and the Environment ( VROM in Dutch ) you can download this strategy document ( in Dutch ).

In the field there has been a number of pilot-projects to try out procedures and the model. I was involved with one of these BGT-projects and we have shared our experiences in a meeting with Geonovum.

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.