-
Notifications
You must be signed in to change notification settings - Fork 1
Used datasets
Initially we were briefed to utilize the landcover data for a part of the municipality of Valkenswaard. The data, including its ontology, was published as Linked Data and queryable through a SPARQL endpoint. However, it seemed the data schema was fairly complex and the terminology was very domain-specific. That's why this would have cost us a tremendous amount of time to master the data and continue the research on top of this data. After discussing this with Linda, we agreed on using a simpler dataset.
After a quick search we found a suitable dataset, which contains all Dutch municipalities, quarters and neighborhoods. This dataset is provided by the CBS, which is a Dutch governmental institution that gathers statistical information about the Netherlands. Some of the advantages of using this dataset:
- The data is provided as an ESRI Shapefile, which is a very simple format to work with.
- The data is hierarchical, which allows us to make hierarchical pages and (internal) links.
- The data is easy to draw on a visual map.
- The data is easy to understand for non-geo people.
Source: CBS Wijk- en Buurtkaart 2015
To be able to do more experiments, we decided to add another dataset. Because we were eager to use something related to the Dutch Environmental Act, we looked at the landcover data as published on "Ruimtelijkeplannen.nl". Because the data-volume was very high (due to its granularity), we decided to use just one part of the data, called "Bestemmingsplangebieden". The data was provided as a GML file, which is pretty easy to utilize.
Source: Bestemmingsplangebieden GML
For serving our web frontend application and API, we stored the geo-data in Elasticsearch, which is a document store optimized for searching and aggregation. Unfortunately, the data we converted from both data sources could not be fully indexed, because the engine complained about documents not being fully compliant with the OGC SFA spec. It appeared that not all geo processing packages interpret the spec the same. Because we didn't want to waste too much time on this issue, we simply ignored non-compliant feature documents.