Refactoring attribute IDs

andrixnet commented 7 years ago

I propose a more radical overhaul, that will bring consistency across OCPL and OCDE and greatly simplify exports and OKAPI and exchanging data. It requires a bit of cooperation between OCPL and OCDE developers and each node admin because there will be changes in the data.

Here is my proposal (for a complete overhaul):

all OC attributes that have equivalent meaning to a GC attribute to use the same numeric ID (while the meaning is equivalent, the exact wording of it's name need not be the same. examples are "bring your children / suitable for children / kids friendly / etc")
all OC attributes that have equivalent meaning to a negated GC attribute to use the same numeric ID with 9000 added. (for example: "available 24/7" is ID 13. "NOT available 24/7" to be ID 9013.)
all OC attributes that have equivalent meaning on both PL and DE branches to have numeric IDs in the range 100 - 199
all OC attributes that are PL branch specific to have numeric IDs in the range 200 - 299
all OC attributes that are DE branch specific to have numeric IDs in the range 300 - 399
all OC attributes that have the meaning of a negated OC attribute to use the same numeric ID on the least significant 3 digits, the fourth digit be the branch designator (according to applicability) and the fifth (most significant digit) be 9. (hypothetical generic example: "available during high tide" ID 241 - PL branch (UK), "NOT available during high tide" ID 9241 - PL branch)

The only special processing to handle OC/GC differences might be regarding the negated GC attribute to set GC specific negation with non-prefixed ID in GPX file. The introduction of in GPX export is very helpful in this regard too. All IDs documented properly at https://wiki.opencaching.eu/index.php/Cache_attributes

What does this acomplish:

a consistent export of data with non-overlapping numerical identificators regardless of the source site
a consistent and well documented set of data for third party application builders to rely upon
a consistent export of data compatible with GC aware apps

=================================== Roadmap to acomplish this:

[x] collect all existing information from all nodes about attributes
[x] renumber all attributes (and create well documented correspondency tables);
[x] document new scheme at https://wiki.opencaching.eu/index.php/Cache_attributes
[x] implement the code changes
[x] create SQL files FOR EACH NODE to alter the database definition tables and cache<=>attrib mapping tables to avoid overlaps, simply add 1000 to all existing IDs, then individually remap each.
[x] verify correctness.
[x] prepare OKAPI update
[x] prepare GPX format exporter update
[ ] coordinate with all node admins for production deployment
[ ] point third party developers to https://wiki.opencaching.eu/index.php/Cache_attributes

andrixnet commented 7 years ago

Moved here from https://github.com/opencaching/opencaching-pl/issues/1242

andrixnet commented 7 years ago

Please post this or a reference to this at OCDE development https://github.com/OpencachingDeutschland/oc-server3 , I can't do it myself.

following5 commented 7 years ago

I don't think we need to change anything at OCDE.

There are only two things were conflicts can arise between OCPL and OCDE attribute IDs:

The old XML interface, which exposes those IDs. But we cannot change that due to backward compatibility: It would break existing XML-interface clients if we change the attribute IDs.
An OCPL-based site decides to switch to OCDE code. I think this is very unlikely - and then, it may be solved by some migration function in OCDE code. OCDE itself will definitely stay with its own code forever.

following5 commented 7 years ago

Of course it may also break OCPL XML-interface clients if you change the IDs. But the XML-interface installations are half-broken anyway at all OCPL sites (zipping does not work due to server configuration flaws), and there may be no applications which use those IDs. At OCDE the XML interface is healthy and in use.

kojoty commented 7 years ago

BTW I've checked logs at OCPL server some time ago the only app which used our XML-interface is geokrety.org. Probably no one of us know much about this part of the code - it's not dropped yet only because of geokrety site.

following5 commented 7 years ago

Okay. geokrety.org does not need the attribute IDs.

following5 commented 7 years ago

all OC attributes that have equivalent meaning to a GC attribute to use the same numeric ID

This can change over time. E.g. GC may add the DE+PL attribute "Compass required".

all OC attributes that have equivalent meaning on both PL and DE branches to have numeric IDs in the range 1000 - 1999

That can change over time. E.g. DE may add the PL attribute "Near a Survey Marker".

How to deal with that?

following5 commented 5 years ago

There is no need to adjust OCPL <-> OCDE, because their attribute IDs will never be combined. For conflicting OCPL attributes there is issue #806.

The GC mapping problem meanwhile is solved: This mapping is active in OCPL code and OKAPI.

So I think this issue can be closed.