Hi,
More problems concerning the same issue.
The xlink:href in geometries issue actually existed out of two parts:
1) encoding xlink:href in geometries where specified in ClientProperties
(which is described below)
2) automatically encoding xlink:href in geometries when the encoder
finds an ID that has already been used before.
Another issue I encountered with (1) is that when an xlink:href is
manually encoded, it should be possible to leave the geometry empty.
This first caused a validation error (but, as we discussed in another
thread, validation is turned off now). However, this will also mean that
the GeometryAttribute has a 'null' value instead of a geometry object.
This is problematic for encoding the xlink:href because I can't put
these in the user data of the geometry if the geometry = empty! I solved
this for now by making an extension of Geometry called 'EmptyGeometry',
a geometry that is simply always empty. The null value is replaced by an
EmptyGeometry as a dummy value, with the attributes in the user data,
which is really the only purpose it is used for. A little bit of an ugly
solution, but the only other solution is to pass on the
GeometryAttribute as a whole to the encoder instead of unpacking it (but
this could have huge effects and I have no idea where that would lead me
to!)
The other problem with both (1) and (2) is that not all geometries are
bound using GeometryPropertyTypeBinding. For example a, sa:shape inside
a gsml:Borehole is bound with a CurvePropertyTypeBinding. Apart from
that also these exist bindings for the following property types:
PointPropertyType
LineStringPropertyType
MultiSurfacePropertyType
MultiPolygonPropertyType
MultiLineStringPropertyType
SurfacePropertyType
PolygonPropertyType
LocationPropertyType
MultiPointPropertyType
MultiCurvePropertyType
Although I haven't seen any sample data that uses these. Looking at the
gsml specication though, they should all be supporting XLINK properties.
I did not want to copy paste 11 times the same code (particularly for
(2) it is necessary to change the classes, not just the methods they
call in gml3encodingutils); so I made all of these bindings derive of a
common abstract class for the purpose of their their common behaviour,
called GeometriesAbstractPropertyTypeBinding. This should not be
confused with AbstractGeometryPropertyTypeBinding (which is not an
abstract class but a binding for the abstractgeometrypropertytype - all
geometries will be bound with it /afterwards/, for their encoding the
'inner' tags, it is not relevant for the xlink properties). Bad name
choice, I know, but I couldn't think of anything else.
Is anyone still following? (Or even reading?)
I do need some comments on what I am doing here =)
One more thing, a dodgy effect of the EmptyGeometry thing is that with
the special bindings, like say for example the CurvePropertyBinding, the
encoder will try to convert the geometry to a LineString. This will
fail, and the encoder will not try to encode anymore, however it will
still ask for properties, which makes the result still good. So I'm not
superhappy with this solution, but I don't have much choice.
Thanks,
Niels
On 29/09/10 22:10, Justin Deoliveira wrote:
Hi Neils,
On Tue, Sep 28, 2010 at 9:08 PM, Niels <[email protected]> wrote:
Hi,
I am currently working on this issue:
http://jira.codehaus.org/browse/GEOT-3219
More specifically, the href part (encoding href in geometries).
The problem is that any properties specified with the
<ClientProperty> tag in the mapping file for geometries aren't
encoded.
There are two issues:
App-schema writes the clientproperties in the userdata of the
geometry object.
The Binding classes CurvePropertyTypeBinding and
GeometryPropertyTypeBinding do not pick these up to encode them.
This I can change (it's in the xsd-gml3 module).
Sounds good.
However there is another issue. Geometries can be converted before
they are encoded. For example, a MultiLineString is converted to a
LineString. THis happens in the GeometryTypeConverterFactory class
(main module). The source object is then thrown away, which would
contain the clientproperties in their userdata put their by
app-schema. I think it would be a good idea to copy userData from
source to target when doing geometry conversion. This way the
popertytypebindings will be able to pick the properties up.
This sounds good too. I think any code that transforms a geometry in a
way that results in a new geometry object should mainain its user
data. I know i have done this is in places before.
I will be working on a patch for this issue. I don't think this
will effect anything else or cause backward compatibility issues.
Let me know any remarks though.
With Regards,
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
