This option allows you to specify your own initial center for a
tileset, which is useful if your map is extremely asymmetric or
you don't really care about what's around the spawn.
Future work needs to be done on the JS side in order to fix the
fromWorldToLatLng and friends, as they're currently off by -24 in X
and +24 in Z direction.
Closes#1350.
Many things work, some don't. Notably, genPOI doesn't work, and
there's some signedness comparison stuff going on in the C extension.
This also completely drops support for Python 2, as maintaining a C
extension for both Python 2 and 3 is a pain and not worth it for the
9 months that Python 2 is still going to be supported upstream.
The documentation needs to be adjusted as well.
All of the few tests we have pass, and rendering a map works, both
with a configuration file and without. We can also use optimizeimages.
Concerns #1528.
Since Firefox 65 added support for WebP, users may be interested
in having maps that use WebP images. Support for this is added in
this commit, along with documentation for it.
A new option, "imglossless", controls whether we write out lossless
or lossy WebP images. The generic name "imglossless" as opposed to
a more specific "webplossless" was chosen in case future image
formats we also implement also support lossless/lossy modes in the
same format (JPEG-XL? AV1 image format?).
It's an okay meme but lossy mode really falls apart on our sorts
of images on the more zoomed out composite tiles, resulting in
pretty blurry messes. Might be due to a PSNR bias in the encoder,
which is to be expected from Google.
A side-effect of these changes is that \a no longer gets shown as
'\a', but '\0x07'. Some characters, i.e. \n and \t, are still shown
as '\n' and '\t' respectively, so this comes simply down to repr()
behaviour.
However, I do believe it's worth it to get rid of that ugly code
duplication.
The validator will now warn if it detects that a crushed output
is fed into something that is not a crusher.
The is_crusher method of an optimizer shall return True if the
optimisation process is lossless, and does try to find optimal
encoding parameters as opposed to only removing unneeded channels
or reducing palettes.
Before someone says this is incorrect because it only ever uses
pngcrush: The old code always used pngcrush and nothing else
anyway. This is absolutely correct and the old behaviour.
I also added a check to make sure it's a list, as some people might
forget the whole list thing.
I think it makes more logical sense now. Essentially, the default is
always used if the user doesn't specify a value. If there is no user
specified value and the default is None, then the action depends on the
value of required. required=True means raise an error. required=False
means silently omit that setting.
