Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

request: regional scoring cell borders #741

Closed
viljoviitanen opened this issue Jan 17, 2014 · 13 comments
Closed

request: regional scoring cell borders #741

viljoviitanen opened this issue Jan 17, 2014 · 13 comments

Comments

@viljoviitanen
Copy link

For sure it would be nice to see the regional scoring cell borders and names in an iitc plugin! There´s obviously some work to gather the info, but that probably could be "crowdsourced" if there was a way to report them.

@jonatkins
Copy link
Collaborator

Already on it

So far, we know that the grid is a level 6 s2 grid

The exact mapping between the IDs this would use and the names will need to be worked out, but doesn't look too tricky.

@fkloft
Copy link
Collaborator

fkloft commented Jan 18, 2014

@jonatkins I don't know whether you made something like this yourself, but just in case it may be helpful:
Germany

I also have some raw data, but no algorithm yet.

@jonatkins
Copy link
Collaborator

OK, I have enough information to complete this now - it's just a matter of writing the code.

Cell ID to name mapping:

Face (first 3 bits):

  • NR = Northern Hemisphere: This is the top face of the cube. It encompasses most of Canada, Europe, and Russia.
  • ST = Southern hemisphere: This is the bottom face of the cube. Not much here. Africa and Australia do not extend far enough south. Tasmania does, however.
  • AM = Americas: The face is centered over North and South America.
  • AF = Africa: This face covers Africa.
  • AS = Asia: This face covers southern Asia.
  • PA = Pacific: This face covers parts of Australia and all of Hawaii.

[EDIT: corrected encoding]
First 4 bits of cell 'i' value: 01 to 16

First 4 bits of cell 'j' value:

  • ALPHA
  • BRAVO
  • CHARLIE
  • DELTA
  • ECHO
  • FOXTROT
  • GOLF
  • HOTEL
  • JULIET
  • KILO
  • LIMA
  • MIKE
  • NOVEMBER
  • PAPA
  • ROMEO
  • SIERRA

Cell ID bits: skip first 8 bits (handled above on i/j bits instead), then 4 bits as 00 to 15

Additionally, some regions (AS, possibly PA and ST too) flip the cell I/J values before running the above.

So far I have most of the needed maths written. Final bit to implement is the Hilbert space-filling curve - the reference C++ code is heavily optimised and assumes unsigned 64 bit integers, so can't directly port this.

@fkloft
Copy link
Collaborator

fkloft commented Jan 18, 2014

Do you have a latlng conversion algorithm?

@jonatkins
Copy link
Collaborator

I've pushed my work in progress - 0afd23c

If you look at the presentation linked above, I've basically got as far as slide 8

The last stage, if following the source directly, requires 64 bit integers. Javascript only has floats, so not possible to directly convert. I'm thinking of handling the cell ID as an array - possibly [face,4bits,4bits,4bits,...]

@fkloft
Copy link
Collaborator

fkloft commented Jan 18, 2014

At least Firefox has UInt64 objects, but I don't know about chrome/WebView...

@jonatkins
Copy link
Collaborator

as of e63678c names are working, as far as I can tell, correctly in

  • NR (northern)
  • AM (america)
  • AF (africa) - only obe example seen though

It is NOT working in

  • AS (asia) - the name/number components are swapped: e.g. AS12-Echo-03 (Mumbai (India west coast) decode to AS05-Mike-01

No examples found for

  • PA (pacific)
  • ST (southern)

Asia could probably be 'fixed' by swapping the I/J components - but I want to be sure there's not an underlying issue in the s2cell code before doing this in the name decoding.

@jonatkins
Copy link
Collaborator

example problem areas:

@MonoTovarisj
Copy link

@jonatkins
Copy link
Collaborator

yes, @MonoTovarisj - they've been very helpful too

as of 022a918 and d645064 I believe the cell names are now correct. AS (asia) now works correctly. Not seen examples of PA or ST, but IngressCells says the same fix should work for PA (pacific) too. I've assumed it's also needed for ST (southern) but have not yet seen an example.

@vita10gy
Copy link
Contributor

Here's hoping they just directly add this info to the intel site. The local scoreboard rides again.

@DazzaJay
Copy link

Not sure if it helps, but Hobart is located in ST
I think it might though. it seems that the entire ST side is innaccurate.

Hobart: http://ingress-cells.appspot.com/?q=Hobart
The block over Hobart in the Cell map is ST14-Alpha-07
The one in the test build of the script is ST01-Papa-07

Portland, Victoria
http://ingress-cells.appspot.com/?q=Portland%2C%20Vic
The block over Portland, VIC in the Cell map is ST15-Alpha-14
The one in the test build of the script is ST01-Romeo-14

Hope this helps.


SCRATCH THAT!
Just heard from a Tasmanian Agent, IITC is correct.
and ingress-cells.appspot is incorrect in the ST zone.

@jonatkins
Copy link
Collaborator

The core functionality is done. and I've had confirmation from each of the six 'faces' that IITC is correct now.

I may still make dome display improvements, particularly in positioning of the names when zoomed in, but will close this issue.

Hopefully the stock intel site gets an update to show the scores soon, so IITC can then do the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants