Open andrixnet opened 7 years ago
Moved here from https://github.com/opencaching/opencaching-pl/issues/1242
Please post this or a reference to this at OCDE development https://github.com/OpencachingDeutschland/oc-server3 , I can't do it myself.
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.
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.
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.
Okay. geokrety.org does not need the attribute IDs.
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?
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.
Finished collecting attribute ID information from all opencaching-pl
nodes.
Now working on first stage remapping.
Finished collecting attribute ID information from all opencaching-pl nodes.
I already did that. The result are here: https://github.com/opencaching/opencaching-pl/blob/master/lib/format.gpx.inc.php#L253. Especially see the UK and US mappings starting at line 363.
I hour that you are not still planning a complete renumbering of all OCPL attributes. I don't see any benefits from that. Just makes lots of work and can introduce bugs.
Actually exactly that, and it is a first step towards a unified attribute handling in the code. As said here, https://github.com/opencaching/opencaching-pl/issues/806#issuecomment-490364162 work is well under way. There will be SQL alters for each individual node that renumbers attributes to the same numbering. This will be documented in the common wiki (all attribs, all nodes).
Then, some attributes will be removed from various nodes and some added (US, UK, RO at least).
Then all english strings will be unified to say the same thing, based on the common documentation. (currently opencaching-pl strings say one thing, OKAPI says something else, a.s.o.).
Note: I have found a greater number of differences between nodes, not just UK/US.
It will be much easier then to write them into the code.
Documentation in progress.
Documentation ready (general form, number assignments) here: https://wiki.opencaching.eu/index.php?title=Cache_attributes
OKAPI atttribute-definitions.xml ready here https://github.com/andrixnet/okapi/commit/fe0d99673a0e709b3516cbe82b5e56cb066bbc27 (will become pull request when ready to deploy)
opencaching-pl code changes ready here https://github.com/andrixnet/opencaching-pl/commit/1b3b16ce16864b6e0692cede97bbfceadecbe697 (will become pull request when ready to deploy)
Database contents for each node ready here https://github.com/andrixnet/opencaching-pl/commit/7c6677837a9d538d9ce516e68cddc9ade9fd4038 (will become pull request when ready to deploy)
Pull requests deployed. Awaiting review and merge.
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):
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:
=================================== Roadmap to acomplish this: