Reusable XSLT

[Just van den Broecke]

On XSLT Transformations: I have started using XSLT callable (named)
parameterized templates to generate generic INSPIRE XML constructs. The
advantage is that these can be reusable: over different INSPIRE themes,
like InspireId, GeographicalName and even over NMCAs. Think of these as
subroutines with parameters.

Within etl/NL.Kadaster I have started placing common XSL in /xsl and
have named common INSPIRE Feature callable templates capitalized
according to their theme, e.g. GeographicalNames.xsl contains callable
templates to generate a NamedPlace or GeographicalName. Locally (Dutch)
specific XSLT scripts are named in lowercase. In time we may move these
up to a general level. I am already internally reusing many common elements.

This week I will be concentrating on HY and TN.

best,

Just

[Markus Schneider]

Interesting. I believe that this is starting to become pretty
professional -- after all the combination GDAL / XSL sounds pretty
pragmatic and flexible. How do you actually run the XSL? Using a Java
program?

Best regards,
Markus

[Just van den Broecke]

XSLT tools: basically "xsltproc" available in standard Mac OS/Unix/Linux
packages:
http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/bin/xslt.sh
but later on we may use Saxon or something when e.g. we need to call
scripts/Java functions from within XSL or vice versa.

Yes, so what I am working towards is that only part of the
transformation is specific to the local source data. The part where
valid INSPIRE GML is generated is decoupled from local transforms.

Some notes:
What I found so far is that the combination GDAL+XSLT with the addition
of Unix tools like awk, sed, iconv, all orchestrated by Unix/Linux shell
scripts is very very lightweight and flexible.
Like:
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.shtml

I know that there are ETL tools out there that in theory could do the
same transforms, but again and again I found nasty little issues,
usually within the source data that required finetuned control over
transforms, for example most (Dutch) source data had CP1252 (Windows
Latin1) encoding, so "iconv -f CP1252 -t UTF-8" to the rescue

Additional issues not yet covered are:
- generalisation: e.g.Dutch Admin units municipalities are
concatenations of _all_ cadastral borders, making up for huge multi-polygons
- geometry transforms: e.g. source data may contain polygons while
INSPIRE requires Points

best,

Just

--
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