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

Reply via email to