It is the gt-wfs-ng module we are concerned with, the other one should be removed next release cycle.
There are a couple constraints / guidance at the schema level on if a geometry is allowed to be null, or if it can be optional (min occurs=0, max occurs=1). The GML encoder should be respecting these settings during encoding / decoding. The same "binding" system is used for both encoding and decoding, you can read more about it here: http://docs.geotools.org/latest/userguide/library/xml/internal/index.html I guess I would start by reproducing your problem as a test case. On 6 September 2016 at 16:58, Andreas Watermeyer < andreas.waterme...@its-telco.de> wrote: > Hi Jody, > > thank you very much for your response! > > I guess gt-wfs resp. gt-wfs-ng is responsible for the client side? > > I would suggest to fix the server side first, because it will be of > advantage for other clients, too. > Apart from that it would of course be nice if the client would not encode > null values. > > Best regards, > Andreas > > > 2016-09-06 3:57 GMT+02:00 Jody Garnett <jody.garn...@gmail.com>: > >> That is interesting, I would assume null values would not be encoded at >> all? >> >> A fix would be welcomed, the gt-wfs-ng module has received a bit of >> attention lately as it takes over duty from the outgoing gt-wfs module. >> >> -- >> Jody Garnett >> >> On 5 September 2016 at 18:53, Andreas Watermeyer < >> andreas.waterme...@its-telco.de> wrote: >> >>> Hi all, >>> >>> I am using GeoTools WFS-Plugin to write an WFS-T client. On the >>> serverside GeoServer is used. >>> >>> I have a problem with the current handling of null values: >>> >>> When I create features on the client side, all null attributes are >>> transmitted as empty elements by GT. >>> >>> On the serverside all those empty elements are turned into empty >>> strings. Next, a feature is created containing all the empty strings in its >>> attributes, regardless of the attribute type. Even on numeric, boolean, ... >>> attributes. All contain those empty strings. >>> >>> I am using sort of GeoServer transaction plugin to postprocess the >>> features. Now there is apparently a mismatch between the >>> AttributeDescriptors type information and the runtime type of those >>> attributes. >>> >>> I would like to have this problem fixed and could provide a pull >>> request. >>> >>> Question: >>> 1) As a fix might break existing applications, currently expecting empty >>> strings, is the GeoTools team willing to accept such a "dangerous" change? >>> >>> 2) What do you think is the best approach to fix this? Suggestions: >>> >>> a) Currently the org.geotools.gml2.bindings.GML2ParsingUtils discard >>> null values returned by converters when creating the feature. A special >>> case for empty strings will probably have the desired effect in a save way >>> (in terms of side effects). >>> >>> b) org.geotools.xml.impl.ParseExecutor discards null values being the >>> result of parsing by the bindings. This might be changed, because the >>> binding might be actually in charge of converting XML to Objects properly. >>> However, the parsing seems quite complicated, I can not foresee which side >>> effects might occur. >>> >>> I propose option a). Any comments are welcome. >>> >>> But most important: Are you willing to accept such a change? >>> >>> Best regards, >>> Andreas >>> >>> >>> -- >>> Andreas >>> >>> ------------------------------------------------------------ >>> ------------------ >>> >>> _______________________________________________ >>> GeoTools-Devel mailing list >>> GeoTools-Devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >> > > > -- > Andreas Watermeyer > office: +49 (0)221 820 07 14 > ---------------------------------------------------------------- > ITS Telco Services GmbH > GIS Services & Solutions > Telecommunications Division > Dillenburger Str. 77 > D-51105 Köln > Tel.: +49 (0)221 820 07 00 > Fax : +49 (0)221 820 07 22 > Mail: i...@its-telco.de > Web : http://www.its-telco.de > ---------------------------------------------------------------- > Sitz der Gesellschaft: Köln > Amtsgericht Köln, HRB 59310 > Geschäftsführer: Gunnar Haack, Ralf Petersilka, Michael Schnepf, Kai > Schriewer, Ludger Schulte > ---------------------------------------------------------------- > > Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der > richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, > informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist > nicht gestattet. > > This e-mail may contain confidential information. If you are not the > intended recipient (or have received this e-mail in error) please notify > the sender immediately and destroy this e-mail. Any unauthorised copying, > disclosure or distribution of the material in this e-mail is strictly > forbidden. >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
