Attribute duplicates across nodes

andrixnet commented 7 years ago

Attribute "Recommended for kids" is listed as having id=41. According to OKAPI, OCDE has the same attribute with id=59 (unused by OCPL-current) The result is two A code mappings in OKAPI for the same attribute.

All OCPL-current nodes should have the same attribute ID for all attributes that form a common set and all attributes that differ should not overlap with other attribute IDs either from OCPL or OCDE. This is the only way to achieve consistency in the long run.

With the entry of OCUK to OCPL-current, OCUK brings many attributes that differ from OCPL-current, some similar to OCDE, some completely new. OCUK already has attribute "Not available at high tide" id=41. Knowing the overlap (thanks to OKAPI), this can be easily resolved quickly and elegantly:

According to http://opencaching.pl//okapi/devel/attrlist and http://www.opencaching.nl/okapi/devel/attrlist there is no attribute id=59 in use.

Same goes for Letterbox attribute. Same goes for "Dangerous area" attribute. Same goes for "Special tool required" attribute.

All these can safely be merged.

OCPL and OCNL: Run the following queries on your servers (and in devel machines) :
Recommended for kids:

update cache_attrib set id=59 where id=41;  
update caches_attributes set attrib_id=59 where attrib_id=41;

Letterbox

update cache_attrib set id=8 where id=56;  
update caches_attributes set attrib_id=8 where attrib_id=56;

Dangerous area

update cache_attrib set id=9 where id=90;  
update caches_attributes set attrib_id=9 where attrib_id=90;

Special tool required

update cache_attrib set id=46 where id=83;  
update caches_attributes set attrib_id=46 where attrib_id=83;

andrixnet commented 7 years ago

OKAPI fix requested by https://github.com/opencaching/okapi/issues/445

andrixnet commented 7 years ago

There are more attribute id duplications and overlaps, but for the time being, these area the easies to solve. (and among the ones with priority for integrating OCUK properly)

deg-pl commented 7 years ago

I think is MUCH easier to change one site - OC DE, not 4 different sites (NL, RO, PL, UK)

andrixnet commented 7 years ago

I can handle RO, help Harrie with NL, you can handle UK and (probably) PL. Anyway, AFAIK things seem to happen much faster at OCPL development then OCDE.

deg-pl commented 7 years ago

I'm afraid malfunctioning OKAPI during changes. Is it possible to include dual attributes (with old and new ID)? @wrygiel What do you think about it?

andrixnet commented 7 years ago

DO you mean the same ID fo rhte same OC site written in 2 A codes?

deg-pl commented 7 years ago

No. One A-code assigned to two ID (new and old). But it was a question. I don't know that it is possible. I don't know OKAPI well.

wrygiel commented 7 years ago

I'm afraid malfunctioning OKAPI during changes.

I will be leaving for holidays very soon, and I won't be able to help you much! However, you shouldn't be too afraid - only a couple of apps make use of attributes, so even if you break something, the impact will be minimal.

No. One A-code assigned to two ID (new and old). But it was a question. I don't know that it is possible.

Yes, it's okay to assign many internal IDs to a single A-code.

andrixnet commented 7 years ago

The above mapping changes are set on OCRO and defined in OKAPI here https://github.com/opencaching/okapi/pull/444

andrixnet commented 7 years ago

Please notify when OCNL and OCPL make their updates.

Afterwards, the other attribute IDs which are / may be in conflict will be dealt with.

andrixnet commented 7 years ago

following5 commented 5 years ago

This issue must be solved, before translations can be eliminated from the database, which will allow to enable any language at any OC site.

PL, RO and NL meanwhile have compatible IDs. UK has nine conflicting IDs. When the new DB update system is active, we can renumber those IDs. For example:

Access restrictions:

40 => 92: Not recommended at night
41 => 93: Not available during high tide
43 => 94: Nature reserve / Breeding season
44 => 95: Available during winter

Tools:

49 => 87: Climbing gear required
50 => 88: Cave equipment required
51 => 89: Scuba gear required

Cache type:

54 => 63: Investigation required
55 => 64: Mathematical problem

US may be done later in the same manner.

following5 commented 5 years ago

Besides of the conflicting UK ids, there are some redundant IDs:

RO/UK 8 = PL/NL 56: Letterbox
RO/UK 9 = PL/NL 90: Dangerous area / dangerous cace
RO/UK 59 = PL/NL 41: Suitable for children

I suggest to renumber the RO/UK attributes to 56 and 90 and 41.

Also there is this conglomerate:

PL/RO 80: Periodical/paid
NL/RO/UK 39: Only at certain times of day or week
UK 36: Access or parking fee

PL/RO 80 and NL/RO/UK 39 all have clock symbols, and most users chose attributes by their icons. Therefore I suggest this solution:

36: Access or parking fee (from UK 36 and RO 80; may also be enabled at PL)
80: Only at certain times of day or week (from PL 80 and NL/RO/UK 39)

harrieklomp commented 5 years ago

Perhaps i am wrong but i like do a suggestion. We use mostly GC attributes. We can change attribute ID in DB or later in code. For changing existing caches a SQLalter can be used to update them. Why not use the same ID numbers like GC uses and use OC attributes above ID -> 100? For example: OC-ONLY attribute have ID 6 and could be 106 because GSAK knows it as ID 106.

following5 commented 5 years ago

That's not possible, because GC attributes are three-state. E.g. "24/7" and "not 24/7" are both GC ID 13 (with additional flag "inc = 1" or "inc = 0"). For OC these are two attributes with different IDs.

harrieklomp commented 5 years ago

The GC ID is always as a Yes. "13 = Available at all times". For "Not 24/7" we can use ID 113 or even 913? https://forums.geocaching.com/GC/index.php?/topic/325495-are-attributes-officially-numbered/&do=findComment&comment=5701506

following5 commented 5 years ago

Okay, we could do that. But why? It would be a huge renumbering, and I don't see a benefit. The only place where GC IDs are needed are the three PHP scripts (including Okapi) where GPX files are created, and they already have translation tables for that.

When attribute refactoring is done, you will never again see any attribute IDs, except if you become a developer and want to change the GPX code. :-)

Those OC attribute IDs are just arbitrary numbers without any meaning.

following5 commented 5 years ago

Is it possible to use this when making a cache?

Yes, that's possible, but it is independend from what IDs the attributes have, and how they are stored internally. It's just a matter of user interface design.

harrieklomp commented 5 years ago

Sorry, i deleted my last post because it was not at the subject :-)

andrixnet commented 5 years ago

Any changes in attributes anywhere results in a code/dependency/documentation/maintenance nightnamre, that is why I am working on unifying the numbering.

following5 commented 5 years ago

The reason for the nightmare is not how the IDs are numbered, but the existence of a cache_attrib table which any sysadmin can edit. To get rid of the nightmare, attributes must be defined globally in code instead of locally in the database.

In preparation for that, I already created a unified ID set for all sites except US. The definitions are here:

https://github.com/opencaching/opencaching-pl/blob/master/lib/languages/en.php#L1923

Well, I run out of time to finish that. :( So maybe it is better that you continue to do it your way.

andrixnet commented 5 years ago

Work is well under way.

opencaching / opencaching-pl

Attribute duplicates across nodes #806