The use of complex features is mostly confined to the app-schema module, and that is a good source of test cases and examples.
I helped setup the feature model to enable the app-schema team but did not get a chance to work on it beyond that. The toString representations are just to aid with debugging, the important asspect is the relationship between the classes to ensure they form a complete descriptive type system. Some additional comments inline: On Tue, Aug 31, 2021 at 1:21 AM Roar Brænden <roar.brenden...@gmail.com> wrote: > I have a WFS source that I try to fetch features from. The response is > quite complex, and I've been > using org.geotools.data.wfs.impl.WFSDataAccessFactory within gt-wfs-ng. > I have not tried gt-wfs-ng with complex features myself I am curious how this will go. I feel there is something wrong about how this xml are represented as a > object graph of Property, but there are so many JUnit tests confirming this > structure, so I'm not sure how to make it better. There is also a lack of > documentation / examples on how the structure should be. > The data structure forms a graph of properties; just the same way you could form a data structure using maps and key/value pairs; or layout a java object in memory. They properties do support some use of user data if you need to hang additional information on the data structuring during processing or parsing etc… The type system describes how the layout should be in order to be valid. It is also responsible for defining the meaning of the values with associated description and other “metadata” details. As a side effect the metadata can also describe default values (useful when setting up a new data), or additional filters (that can be used to validate that the data makes sense). The last aspect of the data model is the ability to query values out. In addition to traversing the data structures this was designed for access via xpath (to support WFS xpath property access). I key test of this as a dynamic type system is if the feature type system describes the data structure well enough that you can construct a xpath expression to retrieve the content you wish. Here is an example of what the xml looks like: > > <wfs:member> > <app:Kommune xmlns:app=" > http://skjema.geonorge.no/SOSI/produktspesifikasjon/AdmEnheter/4.1"; > gml:id="kommune_view.357"> > <app:identifikasjon> > <app:Identifikasjon> > <app:lokalId>173103</app:lokalId> > <app:navnerom> > https://data.geonorge.no/sosi/administrativeenheter/fylker_kommuner</app:navnerom> > <app:versjonId>4.1</app:versjonId> > </app:Identifikasjon> > </app:identifikasjon> > <app:oppdateringsdato>2020-02-07T00:00:00</app:oppdateringsdato> > <app:datauttaksdato>2021-01-04T10:07:10</app:datauttaksdato> > <app:område> > <!--Inlined geometry 'kommune_view.357_APP_OMRÅDE'--> > <gml:Polygon gml:id="kommune_view.357_APP_OMRÅDE" > srsName="urn:ogc:def:crs:EPSG::4258"> > <gml:exterior> > <gml:LinearRing> > <gml:posList>58.426581 6.605405 .....</gml:posList> > </gml:LinearRing> > </gml:exterior> > </gml:Polygon> > </app:område> > <app:kommunenummer>4207</app:kommunenummer> > <app:kommunenavn> > <app:AdministrativEnhetNavn> > <app:navn>Flekkefjord</app:navn> > <app:språk>nor</app:språk> > </app:AdministrativEnhetNavn> > </app:kommunenavn> > <app:samiskForvaltningsområde>false</app:samiskForvaltningsområde> > </app:Kommune> > </wfs:member> > > > The <wfs:member><app:Kommune> is the root for a singe Feature. When > calling getProperties you will get all the child elements of Kommune > represented as a subclass of Property. That contains a name, value and > binding. This works great for ordinary values as string, dates, boolean > and geometry. The problem is when there's a child element, like for > instance <app:kommunenavn>. > This is represented as a ComplexAttribute and has a Collection as a value. > The Collection is actually a Collection of Property's. > I am confused here, do you mean that more than one kommunenavn is allowed? Like min occurs 0, max occurs N? If so you should get repeated individual properties rather than a single one with a collection value. Underneath I've tried to represent this. Ordinary Attribute's are written > as: "name [type] : value", while ComplexAttribute's are written "name {" > with new indentation for their nested properties: > > samiskForvaltningsområde [java.lang.Boolean]: false > IdentifikasjonPropertyType { > Identifikasjon { > IdentifikasjonType { > lokalId [java.lang.String]: 173103 > navnerom [java.lang.String]: https://data.geonorge.no/sosi/ > versjonId [java.lang.String]: 4.1 > } > } > } > kommunenummer [java.lang.String]: 4207 > AdministrativEnhetNavnPropertyType { > AdministrativEnhetNavn { > AdministrativEnhetNavnType { > navn [java.lang.String]: Flekkefjord > språk [java.lang.String]: nor > } > } > } > oppdateringsdato [java.sql.Timestamp]: 2020-02-07 01:00:00.0 > område [org.locationtech.jts.geom.Polygon]: POLYGON ((58.426581 6.605405, > datauttaksdato [java.sql.Timestamp]: 2021-01-04 11:07:10.0 > If you have suggestions for the toStirng representations we welcome pull requests; they are mostly used to aid in debugging. With GML and JSON used between systems. I would like "IdentifikasjonPropertyType" to have the name > "identifikasjon", and the property IdentifikasjonType is superfluous. > I do not understand, the property is the only real thing (ie data structure). The property type describes how it operates. Do anyone have an idea why it's done like it is today, or do anyone have an > opinion about my changes? It would be nice to hear about them. > Thanks for this discussion I hope we can sort out how to accomplish what you wish. Jody -- -- Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
