When it comes to publishing data with GeoServer the most common case is to publish layers that one owns and that can store and serve fully from the local premises.
There are however cases in which a dataset with a uniform structure is handled by several different entities, each one making it available to others, but with no unified view of the data itself.
This might be due to geographical distribution of the stakeholders, separate ownerships, administrative subdivisions: a typical case is a set of local public administrations, all publishing the same, or similar, data set in a independent way.
For this use case we have developed the aggregating data store, a GeoTools store in which features pertaining to the same layer/feature type are coming from several different other stores: the store unifies all of them in a centralized view that can be accessed as a seamless whole.
The store requires the source types to be very similar, but not necessarily identical:
- they can have a different layer names
- may lack some attributes, or have some that are not shared with others
- may not have a perfect type match (e.g., the same attribute can be an integer in one store and a string in another, a conversion to unify the two will be attempted).
A "default" store is appointed that defines the structure of the whole, and every other feature is remapped onto that structure.
Each data access is performed in parallel in order to minimize data loading time, and the store can be configured to tolerate the occasional disappearance of one of the data sources.
This new store is now made available as a GeoServer community plugin for the trunk series, and can be downloaded from the nightly builds repository along with a GeoServer trunk build that allows to use it.
We are still not managing attribute renaming, though it would be quite a nice feature to add. If you are interested in the topic contact us and let's see how we can work together to improve the store.
Regards,
the GeoSolutions Team.
the GeoSolutions Team.
