Port your library to other languages

[tspoke]

Hey,

I'm looking for the JS version of your library and after our conversation about the TileArea, I was thinking to port it in Typescript/Javascript.

What do you suggest ?

• PR into this repository ? (need re-organization)
• Your own repository
• Please, don't !

Nice work !

[bocops]

Thanks - and definitely do! ;)

Either would work for me, in case of adding to this repo, what sort of re-organization do you think would make most sense?

[tspoke]

Ok, cool :)

I was thinking you can re-organize your repository as the OLC repository did. Make a global Readme and have for each languages a folder (redirection to another repository or directly the code).

open-geotiling/
    /java
    /javascript
    /python
	README.md
    ...

What do you think ?

[bocops]

That structure, as well as the idea to redirect to other repos via README.md sounds like great middle ground to me. That way, you could act as the maintainer of your own code better than I ever could. ;)

I will create a CONTRIBUTING.md over the weekend, outlining the above. Feel free to send a PR for restructuring (or the repo of your port), or I'll get to it eventually.

[bocops]

I created an initial CONTRIBUTING.md, outlining a process that I think might work well for everyone involved. Basically

• fork
• add your port to your fork
• add a link to your port to a <language>/PORTS.md file
• send a pull request for that file, but currently not the full implementation.

That should keep you in control of your own implementation (and free me from having to maintain those languages I might not now too much about ;)). It would also allow changing this policy later, and accept PR for full implementations.

I hope this works for you? Let me know if you think anything should be worded differently. :)

[tspoke]

I forgot to really fork the project; I will to submit a PR with the PORT.md file asap I finish the port if it's ok for you.

I had 2 issues porting the library (actually many more because the OLC Java implementation is different than the Javascript, but I did it ;) ) :

• Test testValidPolygonSquare does not work; see Corners are not inside tspoke/open-geotiling-typescript#1
• Test testMaximumMerge does not work. Probably the same bug. It founds 9 tiles for each dataset.

All other tests work perfectly. Do you have an idea for the bug above ? I will try again tomorrow but in case...
Does your tests pass in Java ?

[bocops]

I think the former is basically an issue with the still missing "edge strategy" (issue #2). I will also comment on your issue with more details.

All tests that are not commented out currently pass for me. If your result list contains exactly 9 tiles for each of the three different builds, I assume that it incorrectly merges to a bigger size even before all 400 sub-tiles exist:

In the area [0.9 .. 2.1[ x [0.9 .. 2.1[, there should be one full big tile in the middle ([1.0 .. 2.0[ x [1.0 .. 2.0[), and two rows and columns of smaller ones surrounding it. The first two TileArea defined in the test should merge the big tile, so the resulting array should have a size of ~1 big + 176 surrounding small tiles (give or take, the other issue might lead to less tiles here). The third definition should not merge, so should contain ~400+176 tiles.