Menu
▾
▴
Re: [Geotools-devel] encoding href in geometries
|
From: Niels <nie...@cs...> - 2010-10-15 07:09:39
|
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 <nie...@cs...> 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 > Geo...@li... > <mailto:Geo...@li...> > 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 |