is there any way we can get the bbox and scale of what is to be rendered by the map? the zoomToBox zooms the image to fit the bounds of map, but if say you produce a 800X600 image based on a zoomToBox that's 16:9 then the rendered bounding box will be significantly different to the original 16:9. I'm trying to manipulate the data layer to exclude any label on the edge of the map but without knowing what the true bounding box is and without knowing the scale will be makes this difficult. any ideas here?

Not sure what is going on here but cannot complete the installation steps because make test fails on imagecreatefromstring() image.phpt.

Naturally, the first thing I checked is the presence of gd and it was present. Next I copied the imagecreatefromstring() example from the PHP docs into a regular .php file and, oddly enough, it works as expected.

php_test_results_20160416_1939.txt

Most strange :S

-Peter

Hey @garrettrayj I saw your post on the mapnik dev mailing list, I don't have to give a big review but thought I would open a few tickets on your repo here on issues that I might see.

The first issue I see is that you have all your source in the main directory, its not required but its a lot easier if you put it all in a directory. Is this something required by phpize?

Confused by this as it shouldn't be any issue: Do NOT compile Boost with C++11. On Mac at least, you'll have a bad time with missing symbols.

Hi When I call ProjTransform->backward() or ProjTransform->forward() with any projection different from 4326 and 3857 i get segmentation fault. Mapnik compiled from source with proj4 support, tested on debian and alpine. example:

$boundingBox = new Box2D($minX, $minY, $maxX, $maxY);
$source = new Projection('+init=epsg:4326');
$destination = new Projection('+init=epsg:32638');
$transform = new ProjTransform($source, $destination);
$tileBoundingBox = $transform->backward($boundingBox);

The './configure --with-mapnik' part of the installation process will fail unless mapnik-config is available. It seems to be packaged separately from mapnik3.0 on Ubuntu.

-Peter

I would highly suggest for the ease of users who might use your library that you make the agg render method a part of the map object. We do that in node-mapnik, so that you can do map.render(...). I wouldn't suggest that the C++ interface be directly ported basically, I would write it so that the code is more in a "PHP" style.

After PHP 7.1.17 update from Webtatic repository (https://webtatic.com/news/2018/05/latest-updates-php-7.2.5-7.1.17-7.0.30-5.6.36/) issues with loading GD and the image.phpt test appeared. This change is a quick fix that simply skips that test if GD is not loaded. It may never be loaded as the --EXTENTIONS-- section of the test can't seem to find the module.

As an end-user I want php7-mapnik available in PECL, so I may easily install it with a one liner.

Feasibility

Mapnik requires a tall stack of dependencies that can be hit or miss in repos. While availability has continuously improved, it's still very common to compile from source code. Does it make sense to package the extension when its main dependency is often compiled itself?

The project may need to be renamed and relicensed (PHP License 3.0.1) to comply with PECL standards...

Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

...and...

We strongly encourage contributors to choose the PHP License 3.01 for their extensions, in order to avoid possible troubles for end-users of the extension.

Todo

• [ ] Reach out to pecl-dev mailing list. Inquire about license and project name.
• [ ] Research packaging a C++ extension... Pyrus, pickle, package.xml, etc.

Currently PHP7 Mapnik only implements the bare minimum requirements for constructing Box2D objects. There's plenty of low hanging fruit in the C++ API that would make working with envelopes easier...

• width() and height()
• expand_to_include()
• contains()
• intersects()
• re_center()
• clip()
• pad()
• etc.

Should probably do a PHP implementation of the coord class before tackling this.