Open andrixnet opened 8 years ago
Attributes can also be categorized as following:
INFORMATIONAL
RECOMMENDATIONS
REQUIREMENTS
PERMISSIONS
AMENITIES / FACILITIES
HAZARDS
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 :
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.
I will devise later an SQL query to analyze attribute usage on each node, such that the existing attribute meaningfulness can be evaluated.
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'
This is a CSV export showing the attributes matrix on OC RO.
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.
Attribute usage stats for OC RO (total of 309 cache analyzed) attribute_usage.txt
I propose finalizing a reimplementation of the attribute subsystem
This has already been done once, in OKAPI. How about reusing OKAPI's implementation?
In general, if you decided that you want to reuse it, it would work like this:
attribute-definitions.xml
file with all the fields which has been dropped. Some of them are already there.services/attrs/attributes
method. Such calls should be fast, because all attribute-related data will be cached in memory.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.
The goals of this issue :
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.
I have started working on these steps, which will refactor attribute definitions from database to code:
GeoCache::getCacheAttributesList()
to the new attribute definitions and config.cache_attrib
table to GeoCache::getCacheAttributesList()
.The configuration of available attributes can also determine the order in which they are displayed.
I shall add:
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)
Next step is to create SQL updates for each node to unify node IDs.
@kojoty @deg-pl let's continue attributes discussions here :-)
@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?
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:
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.
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: