Support for ESDIN ExM large scale Application Schemas

[Just van den Broecke]

Hi,

I am seeking ideas for the following: Within ESDIN (www.esdin.eu)
application schemas are defined for pan-european topography called ExM.
One for small/medium scale and one for large scale (< 1:50000). These
schemas extend (by inheritance mainly) from the existing INSPIRE data
themes AU,GN,CP,HY and TN. In theory new properties and constraints
(e.g. mandatory properties that are optional in INSPIRE) are added.

Now the interesting thing for ExM large scale is that the actual schemas
are identical to those from INSPIRE. They just do an extend but without
any additions (confirmed by Clemens Portele). You can find them here:
http://schemas.kademo.nl/esdin/exm/v0.4 (ExM*.xsd files).
To support these ExM schemas we effectively only need a namespace change
e.g. au: becomes xau: (for AU theme).

Given that we already have transformed/stored Annex I data for
AU,GN,CP,HY,TN with deegree3/postgis blob IMO it is a waist of
effort/resources in the long term to do this entire ETL again for ExM.
Especially when we think on a European scale.

So what could be a solution using deegree v3 ? In v2 there were XSLT
filters. Is this something or are there other ideas ? Also for
small/medium scale ExM there are actual new properties added so we may
need some kind of filtering as well. The plus is, that if we can provide
a solution with deegree, this is another step forward in INSPIRE support.

A long mail but wanted to make the issues clear with some background.
best,

--Just

[Markus Schneider]

If I understand this correctly, then the favored approach would be to use
(for ExM) the same database that has been populated by the INSPIRE Annex I
ETL. Differences are minor: Only the namespace (for the feature types?) is
different.

deegree 3 tries to stay away from XSL, but there is another customization
layer that's even more powerful: Pluggable WFS input/output formats.

Basically, one can write an implementation of interface
org.deegree.services.wfs.WFSController.CustomFormat and activate it via
the WFS config. DescribeFeatureType, GetFeature and GetGmlObject requests
are then handled by this class, allowing all kinds of manipulation.
Changing namespaces should be pretty simple.

Best regards,
Markus

P.S.: If you don't want to do this yourself / need assistance, you may
want to consider contracting lat/lon here.

[Markus Schneider]

Of course, the filter requirement (omitting properties) is also a piece of
cake in a custom output format implementation...

[Just van den Broecke]

On 25-11-10 12:12, Markus Schneider wrote:
> If I understand this correctly, then the favored approach would be to use
> (for ExM) the same database that has been populated by the INSPIRE Annex I
> ETL. Differences are minor: Only the namespace (for the feature types?) is
> different.

Yes, only for the Feature Types. A bit silly but true.

>
> deegree 3 tries to stay away from XSL, but there is another customization
> layer that's even more powerful: Pluggable WFS input/output formats.
>
> Basically, one can write an implementation of interface
> org.deegree.services.wfs.WFSController.CustomFormat and activate it via
> the WFS config. DescribeFeatureType, GetFeature and GetGmlObject requests
> are then handled by this class, allowing all kinds of manipulation.
> Changing namespaces should be pretty simple.

Cool ! This sounds as a way to go.

>
> Best regards,
> Markus
>
> P.S.: If you don't want to do this yourself / need assistance, you may
> want to consider contracting lat/lon here.

Ok.

--
kind regards / met vriendelijke groet,

--Just

Just van den Broecke ju...@justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands http://www.justobjects.nl

[Just van den Broecke]

As time/budget is constraining I have started a poor-man's solution
using the ultimate transformation tool: sed :-)

All under:
http://code.google.com/p/inspire-foss/source/browse/#svn/trunk/etl/NL.Kadaster/ExM

best,

Just