TLDR: Excellent - I agree that AttributeDescriptor and AttributeType is the way forward.
Sorry if my quick of assumption of code list was a blind ally. Digging into the what I was looking for ... I found it in Param and Parameter to support distinct strings. Sorry the two designs are similar (open ended to experiment, and then make a method when a specific use becomes popular). See Params OPTIONS <https://docs.geotools.org/stable/javadocs/org/geotools/data/Parameter.html#OPTIONS> . The rest of the email is me checking the code to confirm the approach, and a request if you see an opportunity: - With respect to the filter, your proposal is exactly what ECQL does for inPredicate <https://github.com/geotools/geotools/blob/master/modules/library/cql/src/main/java/org/geotools/filter/text/ecql/ECQLFilterBuilder.java#L154> - This is great as the result should look good when converted to ECQL: *property IN ('option1','option2',...'optionN')* - One "trick" with AttributeTypeBuilder lengthRestriction( int ) <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/AttributeTypeBuilder.java#L566> is the use of ff.propertyName(".") - which is the only option as AttributeType can be used by maple AttributeDescriptors. - This is odd enough that we end up with Types validate( ... ) <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/type/Types.java#L147>methods to apply these in a consistent fashion. If we need better error messages this is place to do it. - I also see a lot of dead code in Descriptors <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/type/Descriptors.java>, DescriptorsValidator <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/type/DescriptorValidator.java> :( - You did not mention it in your summary, but AttributeBuilder.lengthRestriction( int ) for easy encode of length, while FeatureTypes.getFieldLength( ... ) <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/FeatureTypes.java#L135> is for easy decode of field length. - clarification: I do not see any reason to limit filter to Strings, as Java binding is already indicated by AttributeType - out of scope: In your initial description I was concerned you need LUT functionality (stores numbers, display text). This could be handled by the combination of filter restricting numbers stored, and a user map entry providing the text to display. If you seen an opportunity to place your implementation in FeatureTypes I think it will be easier to manage (rather than split between FeatureTypes and AttributeTypeBuilder). - FeatureTypes.getFieldOptions( descriptor ): Object[] - FeatureTypes.createFieldOption( Object ... ): Filter On Thu, Apr 30, 2020 at 10:08 AM Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi all, > as discussed during the last meeting I'm looking into adding support for > enum columns in GeoPackage. > Enumerations are made possible by the schema options, and in particular, > by the gpkg_data_columns > table along with the gpkg_data_column_constraints one. > > The latter can contain an association between integer value and their > description, allowing to build an enumeration. > > During the meeting Jody mentioned CodeList as a possible way to represent > an enumeration, so I looked > into it. A CodeList is an abstract class representing an extensible > enumeration: > https://github.com/geotools/geotools/blob/25015cd04354e315913961bbc5b9bd3db87c6242/modules/library/opengis/src/main/java/org/opengis/util/CodeList.java#L34 > The class has many subclasses, one for each type of extensible enumeration > the code wants to handle .e.g.: > > [image: image.png] > > This implies the name and initial contents of the enumeration must be > known at compile time, while > in GeoPackage we'll discover them at runtime. It does not seem the way to > go, a new enumeration could > have to be created for each column and table in a GeoPackage (this is an > extreme, but in my use case > I have tables with 6-7 different enumerated columns, and various tables > using enumerations in general). > > The enumeration definition must not keep permanent space, or it would turn > into a memory leak in a long > running application processing many different GeoPackages. Also, their > values are best handled by all > other formats and stores without too many modifications. > > Looking around it seems the simplest solution is to go with String > representations, along with a pool of > values that would make most of those String objects just pointers to > common objects (the store would > take care of that), and leverate the AttributeDescriptor restriction. This > approach is already currently > used for the column length restrictions: > > https://github.com/geotools/geotools/blob/93442c6b374b1d14169f43841955bb2b695127c5/modules/library/main/src/main/java/org/geotools/feature/AttributeTypeBuilder.java#L392 > in particular, a Filter looking like "LengthFunction(attribute) <= > maxLenght" is built to represent the situation, > and a utility method in FeatureTypes is used to extract the max lenght of > a field, here: > https://github.com/geotools/geotools/blob/029dc5c8ccc503de3cfd7f4d1c939d8056c260c4/modules/library/main/src/main/java/org/geotools/feature/FeatureTypes.java#L135 > > I plan to do the same, have an OR filter with equalities with the possible > values to represent the enum possible > values, and a method in FeatureTypes to easily extract said list. Maybe > extend the attribute and feature type > builders with an easy way to build an enumerated attribute too. How does > that sound? > > Cheers > Andrea > > == GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > <https://www.google.com/maps/search/Via+di+Montramito+3%2FA%0D%0A55054++Massarosa?entry=gmail&source=g> > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > _______________________________________________ > 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
