INSPIRE WMS setup with deegree3

[Just van den Broecke]

Hi,

I am wondering if anyone has already setup an INSPIRE compliant WMS with
deegree3. With "INSPIRE compliant" I mean adhering to the Layer naming
and Portrayal (SLD) guidelines as specified in [1] and each Annex data
specification [2]. Such a setup would be highly reusable if we share the
WMS config files. I am looking for this at least for the Annex I themes
AU,CP,GN,HY and TN.

kind regards / met vriendelijke groet,

--Just

Just van den Broecke
www.justobjects.nl

[1] Technical Guidance for INSPIRE View services (Version 2.12)
http://inspire.jrc.ec.europa.eu/index.cfm/pageid/5
[2] http://inspire.jrc.ec.europa.eu/index.cfm/pageid/2

[Markus Schneider]

Hi Just,

did you see the default WMS/style configuration of deegree inspireNode?

There may still be some issues, but we tried to configure AD and CP layers and styles in an INSPIRE- compliant way. We were able to use the original SE snippets from the annexes with only slight modifications.

We would be very interested to make the default config of inspireNode fully compliant, so please let us know if you add/improve anything.

Best regards,
Markus

[Just van den Broecke]

Hi Markus,

Yes I am aware of that work, though had some trouble finding it in the
deegree SCM, only found http://tinyurl.com/4srqbam (was looking for the
deegree-inspire-node source). CP and AD are the simpler cases but a good
start. Things get complex with e.g. HY and TN themes. See for example
http://tinyurl.com/4m9hhvs (Tom is on this list as well).

All the more a reason to work jointly on this and assemble the WMS
configuration files (wms.xml + SLDs) in a single place where we all can
contribute. This also gives a chance to merge the existing webapps (2x
in inspire-foss project) and build via Maven specific webapps from a
basic one (deegree-inspire-node) available as a Maven artefact (have to
figure that out). One issue is that we/I don't have access to the
deegree repo.

best,

Just van den Broecke

[Markus Schneider]

Hi Just,

Am 13.01.2011 19:37, schrieb Just van den Broecke:
> Hi Markus,
>
> Yes I am aware of that work, though had some trouble finding it in the
> deegree SCM, only found http://tinyurl.com/4srqbam (was looking for the
> deegree-inspire-node source).

Current version can be found here [1].

> CP and AD are the simpler cases but a good
> start. Things get complex with e.g. HY and TN themes. See for example
> http://tinyurl.com/4m9hhvs (Tom is on this list as well).

Sorry -- I don't get that at first reading :-( Can you try to explain
Tom's problem again?

> All the more a reason to work jointly on this and assemble the WMS
> configuration files (wms.xml + SLDs) in a single place where we all can
> contribute. This also gives a chance to merge the existing webapps (2x
> in inspire-foss project) and build via Maven specific webapps from a
> basic one (deegree-inspire-node) available as a Maven artefact (have to
> figure that out). One issue is that we/I don't have access to the
> deegree repo.

Keeping the config file in a single place sounds like a great plan.

The deegree project welcomes committers [1], but I would also be open to
contribute to the configuration if it is maintained at inspire-foss.

Actually, providing deegree 3 configurations (workspaces) will become
much easier in deegree 3.1 (planned for end of February). We will stop
having different downloads of deegree 3 that only differ in the
workspace configuration (utahDemo, inspireNode, wpsDemo, cswDemo).
Instead, we will have a single (unconfigured) deegree 3.1 web services
download. Additionally, the services console will have a new view for
managing workspaces. This view is able to retrieve a list of available
workspaces from an http server, and the user can pick any of them (or
specify a URL for downloading a workspace from a different location),
The workspace will be downloaded and activated. This means that getting
a deegree 3.1 (inspire) configuration will be as easy as:

- Download deegree 3.1 webservices and start
- Go to workspace manager and choose one of the "official" workspaces
provided by deegree or enter URL for downloading a custom workspace

Afterwards, the user has to make the usual adjustments (e.g. edit JDBC
connections / setup tables), to get the inspire services up and running.

Maybe it would make sense to have the "official" deegree inspire
workspace provided by inspire-foss, but we have to check back with
deegree PSC first.

Best regards,
Markus

[1]
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/applications/deegree-inspire-node/trunk/deegree-inspire-node/?root=deegree
[2] http://wiki.deegree.org/deegreeWiki/HowToGetCommitAccessToSVN

[Andreas Schmitz]

Markus Schneider wrote:

Hi,

>> CP and AD are the simpler cases but a good
>> start. Things get complex with e.g. HY and TN themes. See for example
>> http://tinyurl.com/4m9hhvs (Tom is on this list as well).
>
> Sorry -- I don't get that at first reading :-( Can you try to explain
> Tom's problem again?

I think the possibility of deegree WMS to address a complex feature
model including nested features and multiple/no geometries at all will
solve all of the problems Tom had with MapServer. Regarding featureinfo
I'm not sure what the problem is, but in general I think there should be
no problem either (by default a GML2 representation of the original data
will be returned).

On the other hand, we had to modify the original SLDs slightly, because
they contained some small errors originally, so maybe some of the
problems come from using the unmodified ones.

Best regards, Andreas
--
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 18496-0 fax ++49 +228 18496-29
http://www.lat-lon.de http://www.deegree.org

[Just van den Broecke]

Hi Markus,

On 13-01-11 23:30, Markus Schneider wrote:
> Hi Just,
>
> Am 13.01.2011 19:37, schrieb Just van den Broecke:
>> Hi Markus,
>>
>> Yes I am aware of that work, though had some trouble finding it in the
>> deegree SCM, only found http://tinyurl.com/4srqbam (was looking for the
>> deegree-inspire-node source).
>
> Current version can be found here [1].

Aha (I was looking under trunk/deegree3). This looks good: layer naming
and styles according to INSPIRE. This is a good starting point.

>
>> CP and AD are the simpler cases but a good
>> start. Things get complex with e.g. HY and TN themes. See for example
>> http://tinyurl.com/4m9hhvs (Tom is on this list as well).
>
> Sorry -- I don't get that at first reading :-( Can you try to explain
> Tom's problem again?

As far as I can recall, the issues ("..a complex feature
model including nested features and multiple/no geometries..") that
Andreas indicated in the follow-up mail and the fact that a single
featuretype may have multiple and mixed geometries (like in NL a river
has both a polyline and polygon). But this may related to the use of
MapServer (wonder about GeoServer as well). Since deegree WMS SLD may
use XPath expressions (I thought) this may not be a problem. We just
should start defining and see if/where we get stuck. Hopefully Tom is
listening and may enlighten us...and may contribute (HY is on my list as
well).

>
>> All the more a reason to work jointly on this and assemble the WMS
>> configuration files (wms.xml + SLDs) in a single place where we all can
>> contribute. This also gives a chance to merge the existing webapps (2x
>> in inspire-foss project) and build via Maven specific webapps from a
>> basic one (deegree-inspire-node) available as a Maven artefact (have to
>> figure that out). One issue is that we/I don't have access to the
>> deegree repo.
>
> Keeping the config file in a single place sounds like a great plan.
>
> The deegree project welcomes committers [1], but I would also be open to
> contribute to the configuration if it is maintained at inspire-foss.

For me that is ok (becoming deegree committer). I should also give some
background on the sudden interest in INSPIRE WMS: within ESDIN WP11 we
have been trying to get WFS-es of member states (NMAs) connected and
visualized in OpenLayers (GeoExt). Offcourse this wouldn't scale, so the
next move is to connect to WMS-es, but these need to be compliant at
least for layer naming and preferably portrayal. CP is the first theme.
So I hope to attract some NMAs to participate in inspire-foss to
contribute. It would then be easier to add people to the inspire-foss
project. But we can always keep in sync with SVN externals properties
one way or another.

>
> Actually, providing deegree 3 configurations (workspaces) will become
> much easier in deegree 3.1 (planned for end of February). We will stop
> having different downloads of deegree 3 that only differ in the
> workspace configuration (utahDemo, inspireNode, wpsDemo, cswDemo).
> Instead, we will have a single (unconfigured) deegree 3.1 web services
> download. Additionally, the services console will have a new view for
> managing workspaces. This view is able to retrieve a list of available
> workspaces from an http server, and the user can pick any of them (or
> specify a URL for downloading a workspace from a different location),
> The workspace will be downloaded and activated. This means that getting
> a deegree 3.1 (inspire) configuration will be as easy as:
>
> - Download deegree 3.1 webservices and start
> - Go to workspace manager and choose one of the "official" workspaces
> provided by deegree or enter URL for downloading a custom workspace
>
> Afterwards, the user has to make the usual adjustments (e.g. edit JDBC
> connections / setup tables), to get the inspire services up and running.

This sounds very good! One question: when redeploying a .war, will the
configuration be saved outside the .war ?

>
> Maybe it would make sense to have the "official" deegree inspire
> workspace provided by inspire-foss, but we have to check back with
> deegree PSC first.

Ok. If we are able to attract more INSPIRE experts inspire-foss would
make more sense. Plus there is more: e.g. ESDIN ExM (LS+MSS) which is
now constantly changing with distribution by email from the authors.
ALso we somehow need to be able to create Theme subsets without having a
workspace for each subset otherwise without creating there are too many
empty layers.
>
> Best regards,
> Markus
Best regards,

Just

[Andreas Schmitz]

Just van den Broecke wrote:

Hi,

>> Actually, providing deegree 3 configurations (workspaces) will become
>> much easier in deegree 3.1 (planned for end of February). We will stop
>> having different downloads of deegree 3 that only differ in the
>> workspace configuration (utahDemo, inspireNode, wpsDemo, cswDemo).
>> Instead, we will have a single (unconfigured) deegree 3.1 web services
>> download. Additionally, the services console will have a new view for
>> managing workspaces. This view is able to retrieve a list of available
>> workspaces from an http server, and the user can pick any of them (or
>> specify a URL for downloading a workspace from a different location),
>> The workspace will be downloaded and activated. This means that getting
>> a deegree 3.1 (inspire) configuration will be as easy as:
>>
>> - Download deegree 3.1 webservices and start
>> - Go to workspace manager and choose one of the "official" workspaces
>> provided by deegree or enter URL for downloading a custom workspace
>>
>> Afterwards, the user has to make the usual adjustments (e.g. edit JDBC
>> connections / setup tables), to get the inspire services up and running.
> This sounds very good! One question: when redeploying a .war, will the
> configuration be saved outside the .war ?

yes, the workspaces would normally be saved in $HOME/.deegree/ once
they're downloaded. It is possible to switch a workspace with one click
if you have them available ($HOME/.deegree/ is automatically scanned
for local workspaces).

[stefano.parodi]

I have recently setup the WMS for the Protected Sites.
I have defined a bunch of layers with associated styles.
One is the main layer corresponding to the whole INSPIRE FeatureType
with the default styling (that is by the way the default base inspire
style)
Then there are 3 other layers, one for each of the original datasets.
These latter styles are not defined in the Inspire specs.

In the next days I'm going to setup a public server with the deegree
inspire services for Regione Liguria. As soon as I have it I'll tell
you the url.

Best Regards.

Stefano.

[Just van den Broecke]

Hi Stefano,

This is very good to hear ! Let us knwo whenever you are ready.

If possible can you share the config in SVN (http://tinyurl.com/4en8wpm)
? For now this bundles all configs for many themes, but in time we can
setup a mechanism to assemble a deegree .war with only those
themes/feature types/services required for a particular application. I
also hope to add some WMS configs for other themes shortly.

best,

Just

[stefano.parodi]

I have Just uploaded the sld files in SVN and upgraded the etl files
to the current (hopefully final) version.

Best Regards.

Stefano.

[Just van den Broecke]

Hi,

I am trying to proceed with setting up a WMS based on the data in my
WFS, but I am running in some projection and axis problems. The code is
under
http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fwebapps%2Fdeegree3

My data is in EPSG:4258, one of the required INSPIRE CRSs and stored as
lat/lon using deegree 3.0.3 w. PostGIS. Two problems I found:

- the WMS console assumes the projection EPSG:90013 (Google) but somehow
the data from the WFS is not converted/reprojected when requested. NL is
appearing on the eastcoast of Africa (near the Somalian pirates)

- if requested in the native projection EPSG:4258 I am back in NL but
mirrored: the OL client's axis order is assuming lon/lat from deegree
WMS, both when requesting WMS 1.1.0 and 1.3.0 and with the SRS encoding
urn:ogc:def:crs:EPSG::4258 (I am just thinking that this is an
OpenLayers setting "yx:true" in the OL Layer object
(http://dev.openlayers.org/docs/files/OpenLayers/Layer/WMS-js.html) so
the wms console wms.js could take this into account)

The above seems when trying the deegree inspire node v1.0.3 out of the
box but there the (Address) features are in lon/lat ordering.

I know the "axis ordering" is a nasty beast! Think we are bitten twice
here...

best,

Just van den Broecke
www.justobjects.nl

[stefano parodi]

Hi Just. I'm at home so I can't check my settings, but:
My data is in 4258 too (lat/lon). I have not yet tried any web-based
tool, but I remember having some problem (e.g with QGIS) related to
the axis order. There is an old thread with a summary
(http://groups.google.com/group/inspire-foss-devel/browse_thread/thread/720cb745dbeb007e).

Usually an axis problem don't cause a mirroring of the image but more
likely a displacement in another part of the world, usually in Africa
for the European countries (e.g a lon=10° became a lat of just 10°
North the equator) this explain well you first case (NL in East
Africa) but not the second.
I've never experienced a mirroring (is quite a strange effect, as if
Greenwich was east of NL), maybe the inversion of the xmin and xmax in
the BBOX parameter can cause an effect like this?

Do you have some example GetMap request? In OL is possible to print
the WMS request.

best regards.

Stefano.

2011/3/16 Just van den Broecke <ju...@justobjects.nl>:

--
Ciao.
Stefano.

[Just van den Broecke]

Hi All,

I am still puzzled, since this does not seem to be an axis ordering
issue as the offset/rotation is not consistent. I have attached an
example. The small yellow polygons are Admin Units that should be within
the Netherlands (one near rotterdam). The effects I see:

- when zooming in/out the polygons move out of view to seemingly random
places
- I tried reversing axis orderfrom within OpenLayers different WMS
versions (1.3.0/1.1.1). In most cases I did not see anything.

The attached image has the following layer def:
new OpenLayers.Layer.WMS("INSPIRE Admin Units (all)",
GeoViewer.Catalog.urls.DEEGREE_LOCAL_WMS,
{layers: "AU.AdministrativeUnit", format: "image/png", transparent:
true, version: '1.3.0'},
{isBaseLayer: false, singleTile: true, visibility: false, alpha:true
,featureInfoFormat: "application/vnd.ogc.gml", yx: ['EPSG:4258']}
)

An example WMS request is:
http://localhost:8080/deegree3/services?LAYERS=AU.AdministrativeUnit&FORMAT=image%2Fpng&TRANSPARENT=true&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&CRS=EPSG%3A4258&BBOX=50.569848522067,3.1118821456782,51.780058105075,8.3090599660396&WIDTH=1159&HEIGHT=270

Sometimes an error in the deegree WMS:
[11:18:01] WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had
null coordinate system.
[11:18:01] WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had
null coordinate system.
Error: Could not load mediaLib accelerator wrapper classes. Continuing
in pure Java mode.
Occurs in: com.sun.media.jai.mlib.MediaLibAccessor
com.sun.media.jai.mlib.MediaLibLoadException

deegree version is 3.0.3

It is easy to setup, as I have checked-in the entire viewer in SVN:
http://code.google.com/p/inspire-foss/source/browse/#svn%2Ftrunk%2Fwebapps%2Fviewer

And testdata can be inserted easily as follows using the etl scripts:
http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/bin/testdata-etl.sh

I am runnng the viewer directly using the deegree local WFS/WMS that can
be run at:
http://code.google.com/p/inspire-foss/source/browse/trunk/#trunk%2Fwebapps%2Fdeegree3
using "runnit.sh"

Any help appreciated. I need to give a workshop next wednesday for all
major data providers in The Netherlands and I know this has worked before.

best,

Just

[Andreas Schmitz]

Just van den Broecke wrote:

Hi Just,

> I am still puzzled, since this does not seem to be an axis ordering
> issue as the offset/rotation is not consistent. I have attached an
> example. The small yellow polygons are Admin Units that should be within
> the Netherlands (one near rotterdam). The effects I see:
>
> - when zooming in/out the polygons move out of view to seemingly random
> places
> - I tried reversing axis orderfrom within OpenLayers different WMS
> versions (1.3.0/1.1.1). In most cases I did not see anything.

I think it's usually best to stick with WMS 1.1.1 if possible, as some
clients do have axis ordering trouble with 1.3.0 (I know this to be true
at least for qgis). But still, the effects you're seeing are very
strange indeed.

> The attached image has the following layer def:
> new OpenLayers.Layer.WMS("INSPIRE Admin Units (all)",
> GeoViewer.Catalog.urls.DEEGREE_LOCAL_WMS,
> {layers: "AU.AdministrativeUnit", format: "image/png", transparent:
> true, version: '1.3.0'},
> {isBaseLayer: false, singleTile: true, visibility: false, alpha:true
> ,featureInfoFormat: "application/vnd.ogc.gml", yx: ['EPSG:4258']}
> )
>
> An example WMS request is:
> http://localhost:8080/deegree3/services?LAYERS=AU.AdministrativeUnit&FORMAT=image%2Fpng&TRANSPARENT=true&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&CRS=EPSG%3A4258&BBOX=50.569848522067,3.1118821456782,51.780058105075,8.3090599660396&WIDTH=1159&HEIGHT=270
>
> Sometimes an error in the deegree WMS:
> [11:18:01] WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had
> null coordinate system.
> [11:18:01] WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had
> null coordinate system.

These errors usually indicate that you will miss some geometries/see
them in strange places in case the storage crs is different from the
request crs (which in your case seem to be identical, so no problem
here).

> Error: Could not load mediaLib accelerator wrapper classes. Continuing
> in pure Java mode.
> Occurs in: com.sun.media.jai.mlib.MediaLibAccessor
> com.sun.media.jai.mlib.MediaLibLoadException

That's a JAI warning that occurs only once per server startup and can be
safely ignored.

> Any help appreciated. I need to give a workshop next wednesday for all
> major data providers in The Netherlands and I know this has worked
> before.

I'll have a look at the problem this week, promise ;-)

[Just van den Broecke]

Hi Andreas,

Thanks. I will try WMS 1.1.1 as well. What could maybe also be of
influence is that we changed both the SRS encoding (now
"urn:ogc:def:crs:EPSG::4258" iso EPS:4258) and lon/lat ordering (now
lat/lon) for GML that is inserted (via FSLoader). See example (this is
the actual AU data from the image):
http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/AdministrativeUnits/test/gemeente-au.xml

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

[Andreas Schmitz]

Just van den Broecke wrote:

Hi,

> Thanks. I will try WMS 1.1.1 as well. What could maybe also be of
> influence is that we changed both the SRS encoding (now
> "urn:ogc:def:crs:EPSG::4258" iso EPS:4258) and lon/lat ordering (now
> lat/lon) for GML that is inserted (via FSLoader). See example (this is
> the actual AU data from the image):
> http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/AdministrativeUnits/test/gemeente-au.xml

I think that's indeed an axis order issue, possibly related to the
switch between urn and EPSG: form.

I've just tried to request the WFS with urn:ogc:def:crs:EPSG::4258 and
urn:ogc:def:crs:EPSG::4326, and the axis are swapped! We'll need to have
a closer look at what's going wrong on Monday, but I think it's related
to a broken axis order configuration for 4258 srs in deegree.

[Just van den Broecke]

An additional strange behavior is:

- example DB contains 3 feature types au:AdministrativeUnit,
cp:Cadastralparcel and tn-ro:RoadLink
- WFS requests work ok for each
- WMS works ok (still with Axis problem though) for AU+CP
- for WMS TN.RoadLink layer (coupled via SLD to feature type
tn-ro:RoadLink) I get _all_ features (AU, CP and TN) from the DB with
RoadLinks's drawn as Points (should be Curves) and AU as Polygons, CP as
Lines (?), also still out of place.

Settings for WMS and Viewer as under
http://code.google.com/p/inspire-foss/source/browse/trunk/webapps
(deegree3 and viewer/index.html)

best,

Just

[Markus Schneider]

Hi Just,

I had a quick look into the style files and realized that in
"TN_RoadLink_Default.xml" the namespace prefix ("tn-ro") for the feature
type ("tn-ro:RoadLink") is not bound. In all other files, this seems to
be the case.

I am not sure if this is the cause of the problem, but it is certainly
possible. Does the log say anything about unresolvable / unknown feature
type names when requesting the TN layer?

Best regards,
Markus

[Just van den Broecke]

Hi Markus,

I'm not sure what you mean with "not bound".

"tn-ro" ("TN-RO") is the NS through which the RoadLink features are
stored. See http://tinyurl.com/6hmho42 . Background is an inheritance
hierarchy (complex in comparison to other themes like AU, CP): RoadLink
has the following NSs:

xmlns:NET="urn:x-inspire:specification:gmlas:Network:3.2"
xmlns:TN="urn:x-inspire:specification:gmlas:CommonTransportElements:3.0"
xmlns:TN-RO="urn:xinspire:specification:gmlas:RoadTransportNetwork:3.0">

I have followed this convention also in the inserted features. So a
"RoadLink" feature has properties from NET (e.g.
net:centrelineGeometry), TN and TN-RO (as in the XSD:
http://tinyurl.com/68vxn2m).

I did not see the error you mention. Only if I change "TN-RO:" to "TN:"
I see

INFO: [StyleRegistry] Style file
'/Users/just/project/customers/kadaster/svn/project/inspire-foss/trunk/webapps/deegree3/src/main/webapp/WEB-INF/workspace/styles/TN.RoadLink_Default.xml'
for layer 'TN.RoadLink' could not be found:
'/Users/just/project/customers/kadaster/svn/project/inspire-foss/trunk/webapps/deegree3/src/main/webapp/WEB-INF/workspace/styles/TN.RoadLink_Default.xml
(No such file or directory)'

If I change everything to "TN-RO" in layer/style naming I still get all
features and a warning:

WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had null
coordinate system.
WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had null
coordinate system.

I've just checked-in all current settings. Maybe the issue comes from
mixed/multiple NSs within a single feature type ?

best,

Just

[Markus Schneider]

Hi Just,

Am 27.03.2011 20:51, schrieb Just van den Broecke:
> I'm not sure what you mean with "not bound".

by "not bound", I mean that the prefix "TN-RO:" used in element

...
<se:FeatureTypeName>TN-RO:RoadLink</se:FeatureTypeName>
...

is not bound using XML namespace mechanisms (xmlns-attributes). As the
content of the element is a QName, used prefices generally need to be
bound in the same way as one needs to do it for qualified element names.
You could use

...
<se:FeatureTypeName
xmlns:TN-RO="urn:x-inspire:specification:gmlas:RoadTransportNetwork:3.0">TN-RO:RoadLink</se:FeatureTypeName>
...

> "tn-ro" ("TN-RO") is the NS through which the RoadLink features are
> stored. See http://tinyurl.com/6hmho42 . Background is an inheritance
> hierarchy (complex in comparison to other themes like AU, CP):
> RoadLink has the following NSs:
>
> xmlns:NET="urn:x-inspire:specification:gmlas:Network:3.2"
> xmlns:TN="urn:x-inspire:specification:gmlas:CommonTransportElements:3.0"
> xmlns:TN-RO="urn:xinspire:specification:gmlas:RoadTransportNetwork:3.0">
>
> I have followed this convention also in the inserted features. So a
> "RoadLink" feature has properties from NET (e.g.
> net:centrelineGeometry), TN and TN-RO (as in the XSD:
> http://tinyurl.com/68vxn2m).
>
> I did not see the error you mention. Only if I change "TN-RO:" to
> "TN:" I see
>
> INFO: [StyleRegistry] Style file
> '/Users/just/project/customers/kadaster/svn/project/inspire-foss/trunk/webapps/deegree3/src/main/webapp/WEB-INF/workspace/styles/TN.RoadLink_Default.xml'
> for layer 'TN.RoadLink' could not be found:
> '/Users/just/project/customers/kadaster/svn/project/inspire-foss/trunk/webapps/deegree3/src/main/webapp/WEB-INF/workspace/styles/TN.RoadLink_Default.xml
> (No such file or directory)'

Where did you change "TN-RO:" to "TN:"? IMHO, the only case when the
above error message can occur is when the WMS configuration (wms.xml)
refers to a non-existing style-file, e.g. it contains

...
<File>../styles/TN-RO.RoadLink_Default.xml</File>
...

but there is no such file. Actually, looking at the current state of the
SVN, there is no file called "TN-RO.RoadLink_Default.xml" checked in.
However, there is a file called "TN-RO.RoadLink_Default.xml".

I think this is one scenario that can lead to the errors you observe. If
a layer configuration doesn't refer to a style file (or the style file
is missing), then default styling rules apply. In this case, all feature
types are drawn using default symbolizers. I think this behaviour stems
from WMS/SLD/SE specifications (Andreas?).

> If I change everything to "TN-RO" in layer/style naming I still get
> all features and a warning:
> WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had null
> coordinate system.
> WARN: [Java2DRenderer] Geometry of type 'DefaultPolygon' had null
> coordinate system.

I don't think that these messages relate to the observed styling
problem. However, it would be good to have a way to reproduce them, so
we can analyze them further (and get rid of them).

> I've just checked-in all current settings. Maybe the issue comes from
> mixed/multiple NSs within a single feature type ?

As described above, the current state in trunk seems to be inconsistent.
Does the problem persist after fixing both the style file reference
*and* the feature type name qualification in the style file?

I don't think that the multiple namespaces cause a problem. We have been
using such configurations on a regular basis (e.g. INSPIRE / German
XPlanung) and never encountered any problems here.

Best regards,
Markus

[Andreas Schmitz]

Andreas Schmitz wrote:

Hi,

> > Thanks. I will try WMS 1.1.1 as well. What could maybe also be of
> > influence is that we changed both the SRS encoding (now
> > "urn:ogc:def:crs:EPSG::4258" iso EPS:4258) and lon/lat ordering (now
> > lat/lon) for GML that is inserted (via FSLoader). See example (this is
> > the actual AU data from the image):
> > http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/AdministrativeUnits/test/gemeente-au.xml
>
> I think that's indeed an axis order issue, possibly related to the
> switch between urn and EPSG: form.
>
> I've just tried to request the WFS with urn:ogc:def:crs:EPSG::4258 and
> urn:ogc:def:crs:EPSG::4326, and the axis are swapped! We'll need to have
> a closer look at what's going wrong on Monday, but I think it's related
> to a broken axis order configuration for 4258 srs in deegree.

ok, there have been two issues here. The 4258 srs was indeed not defined
with proper axis order in both 3.1 and 3.0, I've fixed this.

The second issue was that the StorageCRS of the PostGIS feature store
forced x/y axis order, which resulted in WMS/WFS not being able to
properly transform/flip axes as required, and the wrong DB bounding
boxes being calculated. I've also fixed this for 3.0 and 3.1.

So to get it running, you'll have to

* switch to 3.0-SNAPSHOT (3.0.4 will include the fix once it's released)
* rebuild the DB (drop/create or delete and reinsert all features)

I've managed to get proper results for WMS and WFS after dropping the DB
and running your loader script. Let us know if you run into more
trouble.

[Just van den Broecke]

Hi Andreas,

Thanks. I rebuilt both FSLoader and deegree WFS with 3.0-SNAPSHOT,
deleted the tables and did a new "Setup Tables", inserted testdata, but
still see the same issues as before: axis swapped/bboxes mismatch, plus
for tn-ro:RoadLink I see all the features from the DB.

I have checked in all related resources:

data e.g.
http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/AdministrativeUnits/test/gemeente-au.xml

webapps:
http://code.google.com/p/inspire-foss/source/browse/trunk/webapps

I use deegree3 .war with a
http://code.google.com/p/inspire-foss/source/browse/trunk/webapps/viewer/index.html
I've also tried various settings within the viewer but to no avail. The
viewer uses WMS 1.3 with EPSG:4258 and xy swapped.

What is the setup/setting that you used ? workspace WMS/WFS settings
(CRSs), WMS version, EPSG format, axis swap settings ?

best,

Just

--

[Andreas Schmitz]

Just van den Broecke wrote:

Hi,

> Thanks. I rebuilt both FSLoader and deegree WFS with 3.0-SNAPSHOT,

> deleted the tables and did a new "Setup Tables", inserted testdata, but
> still see the same issues as before: axis swapped/bboxes mismatch, plus
> for tn-ro:RoadLink I see all the features from the DB.
>
> I have checked in all related resources:
>
> data e.g.
> http://code.google.com/p/inspire-foss/source/browse/trunk/etl/NL.Kadaster/AdministrativeUnits/test/gemeente-au.xml
>
> webapps:
> http://code.google.com/p/inspire-foss/source/browse/trunk/webapps
>
> I use deegree3 .war with a
> http://code.google.com/p/inspire-foss/source/browse/trunk/webapps/viewer/index.html
> I've also tried various settings within the viewer but to no avail. The
> viewer uses WMS 1.3 with EPSG:4258 and xy swapped.

yes, that's a problem. I've only tested with 1.1.1.

> What is the setup/setting that you used ? workspace WMS/WFS settings
> (CRSs), WMS version, EPSG format, axis swap settings ?

There is something dark and ugly still lurking in the depths of deegree
axis swapping code: for y/x axis ordered EPSG codes, there are two
variants in the CRS DB. EPSG:xxxx with x/y order and urn:... as well as
http://... variants and others with proper y/x axis order. So to solve
the problem quickly, you should switch to urn notation in the WMS <CRS>
section if possible, use a custom CRS DB or switch to 1.1.1. If you use
the EPSG:xxxx variant, the 1.3.0 WMS will currently not use y/x axis
ordering.

Sorry about that, I should've mentioned that earlier...

[Just van den Broecke]

Yes WMS 1.3.0 with axis ordering works now, also for EPSG:4258. thanks!
best,

Just

--