Refactoring attributes - Githubissues

andrixnet commented 8 years ago

Currently attributes are implemented using database table for attribute definition. And (at least) some translations. This makes nodes divergent after instalation.

Also there are (old) parts of the code that refer to attributes that no longer exist. https://github.com/opencaching/opencaching-pl/issues/380

I propose finalizing a reimplementation of the attribute subsystem, perhaps in a similar way to lib\Objects\GeoCache, to allow the following:

common superset of attributes as part of the code. All nodes are in sync. Also solves this https://github.com/opencaching/okapi/issues/402
individual attributes may be disabled on a certain node, same as forbidden_caches Allows nodes to disable supported attributes which they do not desire to feature.
implement in such way to allow node icon theme personalization in settings Also solves this https://github.com/opencaching/opencaching-pl/issues/97

andrixnet commented 8 years ago

Attributes can also be categorized as following:

INFORMATIONAL

magnetic
wherigo cartridge
available 24/7
nature preserve
monument
etc

RECOMMENDATIONS

bring your children
be stealth
etc

REQUIREMENTS

need a special tool
need a shovel / flashlight / UV light
field puzzle
access fee
etc

PERMISSIONS

dogs allowed
cars / vehicles forbidden (ie parks)
open fire forbidden
etc

AMENITIES / FACILITIES

parking available
drinking water available
fuel available
etc

HAZARDS

dangerous place
ticks
thorns

Categorization can be used internally (for grouping and sorting) and, optionally, publicly for better UI. It would also help with https://github.com/opencaching/okapi/issues/70

Some attributes, in principle, may have 3 states :

ATTRIBUTE SET
NOT ATTRIBUTE SET
UNSET

OPENCACHING-PL implemets only 2 states. However, careful design and categorization may be used to improve the attributes into a meaningful and useful set that provides better characterization for caches. Solves https://github.com/opencaching/opencaching-pl/issues/99

Some of the current attributes are less then optimal and imlpy less meaning for the cache, while other meanings are missing.

andrixnet commented 8 years ago

I will devise later an SQL query to analyze attribute usage on each node, such that the existing attribute meaningfulness can be evaluated.

andrixnet commented 8 years ago

The following code will generate a comparison matrix between the attributes (for the main languages PL EN NL RO) in your node's database:

select
  c1.language,c1.id,c1.text_short,
  c2.language,c2.id,c2.text_short,
  c3.language,c3.id,c3.text_short,
  c4.language,c4.id,c4.text_short
  from
    cache_attrib c1
    left join cache_attrib c2 on (c1.id=c2.id and c2.language='PL')
    left join cache_attrib c3 on (c1.id=c3.id and c3.language='NL')
    left join cache_attrib c4 on (c1.id=c4.id and c4.language='RO')
where
  c1.language='EN'

UNION 

select
  c1.language,c1.id,c1.text_short,
  c2.language,c2.id,c2.text_short,
  c3.language,c3.id,c3.text_short,
  c4.language,c4.id,c4.text_short
  from
    cache_attrib c2
    left join cache_attrib c1 on (c2.id=c1.id and c1.language='EN')
    left join cache_attrib c3 on (c2.id=c3.id and c3.language='NL')
    left join cache_attrib c4 on (c2.id=c4.id and c4.language='RO')
where
  c2.language='PL'

UNION 

select
  c1.language,c1.id,c1.text_short,
  c2.language,c2.id,c2.text_short,
  c3.language,c3.id,c3.text_short,
  c4.language,c4.id,c4.text_short
  from
    cache_attrib c3
    left join cache_attrib c1 on (c3.id=c1.id and c1.language='EN')
    left join cache_attrib c2 on (c3.id=c2.id and c2.language='PL')
    left join cache_attrib c4 on (c3.id=c4.id and c4.language='RO')
where
  c3.language='NL'

UNION 

select
  c1.language,c1.id,c1.text_short,
  c2.language,c2.id,c2.text_short,
  c3.language,c3.id,c3.text_short,
  c4.language,c4.id,c4.text_short
  from
    cache_attrib c4
    left join cache_attrib c1 on (c4.id=c1.id and c1.language='EN')
    left join cache_attrib c2 on (c4.id=c2.id and c2.language='PL')
    left join cache_attrib c3 on (c4.id=c3.id and c3.language='NL')
where
  c4.language='RO'

andrixnet commented 8 years ago

This is a CSV export showing the attributes matrix on OC RO.

attribute-matrix.txt

andrixnet commented 8 years ago

Use this query to generate attribute usage statistics according to your node:

select a.id,a.text_short,count(ca.attrib_id) as _cnt
from 
    cache_attrib a
    left join caches_attributes ca on (a.id=ca.attrib_id)
where
    a.language='RO'
    group by ca.attrib_id
    order by _cnt

Replace the language value with PL or NL (according to your node being OC PL or OC NL) to obtain your own statistics correctly based on your attributes matrix.

andrixnet commented 8 years ago

Attribute usage stats for OC RO (total of 309 cache analyzed) attribute_usage.txt

wrygiel commented 8 years ago

I propose finalizing a reimplementation of the attribute subsystem

This has already been done once, in OKAPI. How about reusing OKAPI's implementation?

wrygiel commented 8 years ago

In general, if you decided that you want to reuse it, it would work like this:

You would drop the table with the dictionary of attributes from your development databases.
You would need to fill OKAPI's attribute-definitions.xml file with all the fields which has been dropped. Some of them are already there.
I would then fix OKAPI implementation so that it would reuse the fields you have added (if you added any).
In all the places in OCPL where the dropped table has been used, you would need to replace it with proper calls to OKAPI's services/attrs/attributes method. Such calls should be fast, because all attribute-related data will be cached in memory.

wrygiel commented 8 years ago

The following code will generate a comparison matrix between the attributes (for the main languages PL EN NL RO) in your node's database

I have implemented a similar feature in OKAPI. See here:

http://opencaching.pl/okapi/devel/attrlist http://www.opencaching.ro/okapi/devel/attrlist http://www.opencaching.de/okapi/devel/attrlist etc.

andrixnet commented 8 years ago

The goals of this issue :

unify attributes across existing OPENCACHING-PL nodes, even if not all are in actual use
resolve attribute ID overlaps
unify attributes in OKAPI attribute-definitions.xml such that only schema="OCDE" and schema="OCPL" are valid (per opencaching implementation rather then per node)
implement forbiddenAttributes feature in OPENCACHING-PL
move attribute definitions from DB to code
configure each node with it's desired set of attributes
implement new attributes
implement new features

andrixnet commented 8 years ago

I also suggest making a survey with OKAPI and OCDE such that attributes with same meaning share the same ID and attibutes with different meanings, found in only one codebase, don't share the same ID, then update both OKAPI and our databases.

This is quite simple with a few queries, I just solved 2 such cases for OCRO.

following5 commented 5 years ago

I have started working on these steps, which will refactor attribute definitions from database to code:

Renumber conflicting and redundante OC UK attribute IDs; see #806. Also in OKAPI.
Add NL, RO and UK attribute names to translation files; see #1852.
Clarify the meaning of some ambiguous attributes; see #1852 and #1244.
Switch translation from DB to files.
Add defintion of all attributes (IDs and image names) to e.g. GeoCacheCommons.
Add configuration of available attributes to Config / OcConfig.
Switch GeoCache::getCacheAttributesList() to the new attribute definitions and config.
Refactor all access of the cache_attrib table to GeoCache::getCacheAttributesList().

The configuration of available attributes can also determine the order in which they are displayed.

andrixnet commented 5 years ago

I shall add:

allow attribute themes on per node basis (ie each node has it's own icon set for attributes)

andrixnet commented 5 years ago

As part of OCNA migration I have created a huge table with all attributes from all sites, including GC equivalents, valid the day I am writing this.

From this I am building a common numbering scheme for all attributes and assembling a common superset of attributes from which each node just has to enable/disable it's own. The numbering scheme follows OCPL, OCDE, GC, OCGS schemes in ways to simplify things overall.

I shall document all as soon as I arrive at a stable set at opencaching.eu wiki. (currently a stub)

andrixnet commented 5 years ago

Next step is to create SQL updates for each node to unify node IDs.

andrixnet commented 2 years ago

@kojoty @deg-pl let's continue attributes discussions here :-)

kojoty commented 2 years ago

@andrixnet what is a purpose of icon names? I mean that I would like to update them a little bit and update the same on your wiki - is the icon names important shomehow?

andrixnet commented 2 years ago

Icon names are important for several reasons. First, to give the ability of having icon themes. Each theme will then consist of a series of images with predefined names according to the meaning and since the icons are defined in the code, the code will know where to find the proper image to display from 2 informations: theme and attribute name.

Second, from a "good practices" viewpoint, I would recommend that each attribute be defined in the code with a suitable name and the same name be used to identify that attribute across the code and themes:

attribute name (code part)
attribute translation string name
attribute icon (at least)

what I have already listed on the wiki is based on existing icon file names, with some adjustments in few places and similar way of naming newly defined icons.

On 2021-11-01 12:41 PM, kojoty wrote:

@andrixnet https://github.com/andrixnet what is a purpose of icon names? I mean that I would like to update them a little bit and update the same on your wiki - is the icon names important shomehow?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opencaching/opencaching-pl/issues/462#issuecomment-956123011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZZ36KRWZM6ODF6COW7YBTUJZVFLANCNFSM4B73XYNA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

opencaching / opencaching-pl

Refactoring attributes #462