Hi Marcus,

Actually I found out how to fix it without joining. The issue with xlink:href 
happens because there are multiple rows that are unordered (the xlink:href-ed 
rows weren't grouped with the rows with the same gml:id).
This means you need to index your data by the gml:id. I forgot about this 
requirement, but it's actually on the warning part here: 
http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#denormalised-sources

"Warning Denormalised sources must grouped so that features with duplicate IDs 
are provided without any intervening features. This can be achieved by ensuring 
that denormalised source features are sorted by ID. Failure to observe this 
restriction will result in data corruption. This restriction is however not 
necessary when using Joining Support For Performance because then ordering will 
happen automatically."

Best bet is to use joining. Non-joining is the old, less reliable 
implementation maintained for backward compatibility. 
I am working on making joining set by default to make it easier for others in 
the future.

Cheers
Rini

-----Original Message-----
From: Sen, Marcus A. [mailto:m...@bgs.ac.uk] 
Sent: Wednesday, 6 March 2013 8:17 PM
To: Angreani, Rini (CESRE, Kensington); Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 
3.2 application schema) tests

> -----Original Message-----
> From: rini.angre...@csiro.au [mailto:rini.angre...@csiro.au]
> Sent: 06 March 2013 06:52

> I could recreate the invalid xlink:href problems without joining.
> With joining, I couldn't recreate the problem. It would be faster with 
> joining too.
> I guess it's about time I make joining the default behaviour.
> Also, I think the problem with your filters should be solved with 
> joining.
> Please let me know otherwise.
I didn't have joining enabled so I tried enabling it (now using 2.3-RC1) and 
can confirm this fixes both the xlink:href problem and getting the correct 
results with my filters (for WFS 1.1.0 requests).

The documentation notes some restrictions on capabilities with joining set. 
These don't affect anything I'm currently doing but I don't know whether they 
affect anyone else. So I don't know whether an issue should still be raised to 
get correct behaviour without joining set or instead to make joining always be 
set.

Marcus


This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to