Fine: - https://www.dropbox.com/s/egwue6op3gch4r4/DSC06212.jpg?dl=0 - https://www.dropbox.com/s/zyvfq10k5wygeyu/DSC06213.JPG?dl=0
-- Jody Garnett On 14 November 2016 at 19:57, Ben Caradoc-Davies <b...@transient.nz> wrote: > Nuno, > > I have no objection to the encoder supporting non-GML encoding patterns, > if the change does not impact complexity or performance. The encoder is > intended to support XSDs other than just GML, hence the module name. > Before any change is merged, I would like to run the GeoServer > app-schema online test suite on your pull request. > > Instead of "striping", perhaps terminology that refers to the GML > "object-property model" for clarity? > > This method is already very long. I once printed the Encoder source in > six-point and wrapped Justin Deoliveira in it. Jody has the photo. > > Kind regards, > Ben. > > On 15/11/16 13:52, Nuno Oliveira wrote: > > Andrea, Stefano Ben and Rob sorry for the delay and thanks for the > > feedback, much appreciated :) > > > > I dived in app-schema and GML complex features encoder code, follow the > > provided mailing list discussions and perform some tests and I got > > confused about all of this :| ... I redone all of this and found some > > answers and questions :) > > > > In my current use case I will actually build a top schema that will be > > GML based but needs to include entities from a schema that is not GML > > based. Answering Ben question the schema is this one: > > http://www.datex2.eu/schema/2/2_3/DATEXIISchema_2_2_3.xsd > > > > App-schema seems to be able to handle the mapping of XSD elements that > > doesn't respect the GML "striping" rule, i.e. it correctly builds the > > complex feature type, the complex feature and seems to handle filtering > > correctly too. So "the problem" was that the GML complex encoder was not > > encoding the elements that didn't respect the "stripping" rule. > > > > That said, I would like to relax the GML complex encoder to be able to > > encode complex features that map to a schema that didn't respect the GML > > "stripping" rule. > > > > When the GML "stripping" rule is not respected, app-schema will build a > > complex feature where the type will contain a feature of the same type. > > Using the stations example, this means that we will have a Measurement > > containing Measurement elements, this happens because the containing > > element was a XSD element of type Measurement. The encoder expected to > > receive a MeasurementProperty containing a Measurement, where the > > containing XSD element was of type MeasurementProperty. > > > > The solution I propose is basically to detect when we have a complex > > feature property the matches the pattern described above and to actually > > encode the contained properties which are the properties we are > > interested in. Mapping this to code, this would basically happen here: > > https://github.com/nmco/geotools/blob/fc6d8db315240dabad2daf0160316d > 51c1e33c2f/modules/extension/xsd/xsd-core/src/main/java/ > org/geotools/xml/Encoder.java#L747 > > > > > > Instead of just adding the current complex attribute, we could check if > > the current complex attribute is actually a non "striped" GML entity and > > encode only the contained entities: > > > > if (isNonSttrippedNestedEntity(next)) { > > for (Property property : ((ComplexAttribute) next).getProperties()) { > > encoded.push(new EncodingEntry(property, element, entry)); > > } > > } else { > > encoded.push(new EncodingEntry(next, element, entry)); > > } > > > > > > I have performed some tests with this and it seems to work fine. I was > > able to encode the stations data read from a MongoDB store using the > > original non valid GML schema (result attached). > > > > We can also have a flag that will control if the encoder should work in > > a relaxed way or not. > > > > What do you think about this solution ? What did I miss ? > > > > Regarding Rob comment about the result mime type, what are others > > opinion on this ? > > > > Thanks, > > > > Nuno Oliveira > > > > On 11/02/2016 02:42 PM, Nuno Oliveira wrote: > >> Thanks for the feedback Stefano and Andrea. > >> > >> So it doesn't matter how I try to map the entities, i.e. the > >> app-schema mappings, the problem is with the schema :( > >> > >> Stefano I tried to find the discussion you refer on the mailing lists > >> but could not find it, better I found to much information > >> about this, can you pass me the link :) > >> > >> You say that you already stepped on something like this how did you > >> manage to work around it ? > >> > >> Thanks, > >> > >> Nuno Oliveira > >> > >> One doubt remain, and this one is for the app-schema experts :), is > >> there a > >> > >> On 11/02/2016 10:09 AM, Nuno Oliveira wrote: > >>> Hi, > >>> > >>> I have a doubt regarding the way GML complex features encoder handles > >>> a sub collection of features, i.e. chained features. > >>> > >>> The example use case is the representation of some meteorological > >>> stations measurements in GML. The complex feature > >>> represents a station were the measurements are represented as a sub > >>> collection of features. The XML expected representation > >>> would be something like this: > >>> > >>> <?xml version="1.0" encoding="UTF-8"?> > >>> <wfs:FeatureCollection ...> > >>> <st:featureMember> > >>> <st:StationFeature gml:id="1"> > >>> <st:name>station 1</st:name> > >>> <st:contact> > >>> <st:mail>stati...@mail.com</st:mail> > >>> </st:contact> > >>> <st:measurement> > >>> <st:name>temp</st:name> > >>> <st:unit>c</st:unit> > >>> <st:value>35.5</st:value> > >>> </st:measurement> > >>> <st:measurement> > >>> <st:name>wind</st:name> > >>> <st:unit>km/h</st:unit> > >>> <st:value>110.5</st:value> > >>> </st:measurement> > >>> <st:geometry> > >>> <gml:Point > >>> srsName="http://www.opengis.net/gml/srs/epsg.xml#4326";> > >>> <gml:coordinates>50.0,60.0</gml:coordinates> > >>> </gml:Point> > >>> </st:geometry> > >>> </st:StationFeature> > >>> </gml:featureMember> > >>> </wfs:FeatureCollection> > >>> > >>> The first GML based schema I wrote for this didn't work, i.e. the > >>> measurements sub collection was not encoded by > >>> the encoder, please find that schema attached with name > >>> stations1.xsd. After some investigation I found that my > >>> problem was in this piece of code: > >>> > >>> https://github.com/geotools/geotools/blob/master/modules/ > extension/xsd/xsd-gml3/src/main/java/org/geotools/gml3/bindings/ > ComplexSupportXSAnyTypeBinding.java#L176-L177 > >>> > >>> > >>> Basically no child elements were extracted, and in this case the > >>> child elements were the station measurements. After checking > >>> the app-schema examples I came up with this second schema that > >>> worked, please find that schema attached with name stations2.xsd. > >>> > >>> The main difference is that I wrapped the measurement element with > >>> the MeasurmentPropertyType: > >>> > >>> <xs:complexType name="MeasurementPropertyType"> > >>> <xs:sequence minOccurs="0"> > >>> <xs:element ref="st:Measurement"/> > >>> </xs:sequence> > >>> <xs:attributeGroup ref="gml:AssociationAttributeGroup"/> > >>> </xs:complexType> > >>> > >>> This stations use case is just an example, I have a much more complex > >>> use case with the same problem were I cannot change the schema. > >>> So I'm wondering, did anyone had a similar use case ? did I made > >>> something wrong in the app-schema mappings-file ? is this something is > >>> just not supported by the encoder ? and did my first schema actually > >>> makes sense (in my point of view it looks sane) ? > >>> > >>> Any help with this will be very very welcomed :) > >>> > >>> Regards, > >>> > >>> Nuno Oliveira > >>> > >>> > >>> > >>> ------------------------------------------------------------ > ------------------ > >>> > >>> Developer Access Program for Intel Xeon Phi Processors > >>> Access to Intel Xeon Phi processor-based developer platforms. > >>> With one year of Intel Parallel Studio XE. > >>> Training and support from Colfax. > >>> Order your platform today.http://sdm.link/xeonphi > >>> > >>> > >>> _______________________________________________ > >>> GeoTools-Devel mailing list > >>> GeoTools-Devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >> > >> -- > >> == > >> GeoServer Professional Services from the experts! > >> Visithttp://goo.gl/it488V for more information. > >> == > >> Nuno Miguel Carvalho Oliveira > >> @nmcoliveira > >> Software Engineer > >> > >> GeoSolutions S.A.S. > >> Via di Montramito 3/A > >> 55054 Massarosa (LU) > >> Italy > >> > >> phone: +39 0584 962313 > >> fax: +39 0584 1660272 > >> mob: +39 333 8128928 > >> > >> http://www.geo-solutions.it > >> http://twitter.com/geosolutions_it > >> > >> ------------------------------------------------------- > >> > >> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 > >> Le informazioni contenute in questo messaggio di posta elettronica e/o > >> nel/i file/s allegato/i sono > >> da considerarsi strettamente riservate. Il loro utilizzo è consentito > >> esclusivamente al destinatario del messaggio, per le finalità indicate > >> nel messaggio stesso. Qualora riceviate questo messaggio senza esserne > >> il destinatario, Vi preghiamo cortesemente di darcene notizia via e > >> -mail e di procedere alla distruzione del messaggio stesso, > >> cancellandolo dal Vostro sistema. Conservare il messaggio stesso, > >> divulgarlo > >> anche in parte, distribuirlo ad altri soggetti, copiarlo, od > >> utilizzarlo per finalità diverse, costituisce comportamento contrario ai > >> principi dettati dal D.Lgs. 196/2003. > >> The information in this message and/or attachments, is intended > >> solely for the attention and use of > >> the named addressee(s) and may be confidential or proprietary in > >> nature or covered by the provisions of privacy act (Legislative Decree > >> June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not > >> in accord with its purpose, any disclosure, reproduction, copying, > >> distribution, or either dissemination, either whole or partial, is > >> strictly forbidden except previous formal approval of the named > >> addressee(s). If you are not the intended recipient, please contact > >> immediately the sender by telephone, fax or e-mail and delete the > >> information in this message that has been received in error. The > >> sender does not give any warranty or accept liability as the content, > >> accuracy or completeness of sent messages and accepts no > >> responsibility for changes made after they were sent or for other > >> risks which > >> arise as a result of e-mail transmission, viruses, etc. > >> > >> > >> ------------------------------------------------------------ > ------------------ > >> > >> Developer Access Program for Intel Xeon Phi Processors > >> Access to Intel Xeon Phi processor-based developer platforms. > >> With one year of Intel Parallel Studio XE. > >> Training and support from Colfax. > >> Order your platform today. http://sdm.link/xeonphi > >> > >> > >> _______________________________________________ > >> GeoTools-Devel mailing list > >> GeoTools-Devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > > > > > ------------------------------------------------------------ > ------------------ > > > > > > > > _______________________________________________ > > GeoTools-Devel mailing list > > GeoTools-Devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > Ben Caradoc-Davies <b...@transient.nz> > Director > Transient Software Limited <http://transient.nz/> > New Zealand > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
