Excellent. I'll make sure our developer tries to make this as memory
efficient as possible.
Otherwise we can display a message to warn users for the impact if it can't
be helped.
Cheers
Rini
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Encoding-GML-and-Xlink-tp4930
Rini Angreani ha scritto:
> Hi all,
>
> Resurrecting this old thread. I've discussed this with Ben, who suggested to
> add an option for the users to enable automatic xlink:href at their own risk
> (of slowness). The issue has been raised here: GEOT-3094.
> I think it's a good idea, as done for GE
Hi all,
Resurrecting this old thread. I've discussed this with Ben, who suggested to
add an option for the users to enable automatic xlink:href at their own risk
(of slowness). The issue has been raised here: GEOT-3094.
I think it's a good idea, as done for GEOT-3046. Should we go ahead and do
th
Hi all,
Sorry for the late reply, I completely missed this discussion thread before.
Rob, this is a known problem in our internal JIRA, but I neglected to create
an issue in Geotools JIRA.
At the moment, it will always do it for complex attributes only, because I
only put the code that does this
To answer my own questions again: in my schema the namespace
declaration xmlns:xlink="http://www.w3.org/1999/xlink" was missing!
And from a previous post:
The gml:boundedBy element can be left out by using
ApplicationSchemaConfiguration config = new
ApplicationSchemaConfiguration(namespace,
On 21/04/10 14:58, Rob van Swol wrote:
> 1) changing SurfacePropertyType into GeometryPropertyType in the schema and
> creating an empty Geometry does the trick!
Well done, Rob, that is an excellent result!
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and Resourc
On 21/04/10 15:53, Andrea Aime wrote:
> Serving complex features is a performance nightmare, it's well known,
> whatever you do please try not to affect the simple case.
I think Rini made sure that we did not ... and this may be a case where
simple features are broken by *not* doing things the fu
Hi,
Perhaps I have not found the complete solution yet, because I just
noticed that a href attribute is used where I would expect a xlink:href
attribute. Also the xlink namespace definition is missing. Am I still
doing something wrong?
Thanks for your reaction.
Regards,
Rob van Swol
On 21-4-2
Ben Caradoc-Davies ha scritto:
> Andrea,
>
> is XSIdRegistry turned off for simple features, for performance and
> memory reasons? I recall a discussion ...
Not sure. I remember at one point something that kept in memory
every id of every feature encoded was added that increased dramatically
bot
Hi,
To answer my own question:
1) changing SurfacePropertyType into GeometryPropertyType in the
schema and creating an empty Geometry does the trick!
2) looking at the code I discovered that the check on existing id's is
done based on the id of the feature NOT on the id of the geometry! I am
Andrea,
is XSIdRegistry turned off for simple features, for performance and
memory reasons? I recall a discussion ...
Kind regards,
Ben.
On 20/04/10 20:46, Rob van Swol wrote:
> Hi,
> I have a simple GML3 Application schema which I use to encode a
> featurecollection to a gml document. Howeve
Hi,
I have a simple GML3 Application schema which I use to encode a
featurecollection to a gml document. However I do not succeed in
getting duplicate gml:id's in geometry elements to be replaced by
xlink:href attributes. Even worse: duplicate id's are accepted while I
thought that the XSDIdReg
12 matches
Mail list logo
