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

Bug - NaN Map Dimensions are handled silently and inconsistently #990

Open
NickStafford opened this issue Nov 9, 2023 · 0 comments
Open

Comments

@NickStafford
Copy link

Hi,

Feel free to explain if this is intended behaviour but it definitely looks like a bug to me.

What happened

When creating a new Map() if NaN values get in to the dimensions (e.g. new Map(NaN, NaN)) then a Map object is created with no warnings.

If you zoom such a Map object using zoomToBox(), you get a Map object with inconsistent extents.

This causes problems later on when trying to manipulate the Map.

Example

testFunction() {
    console.log('Creating map...');

    if (mapnik.register_default_input_plugins) mapnik.register_default_input_plugins();

    var srs = '+init=epsg:4326';
    var map = new mapnik.Map(NaN, NaN, srs);

    console.log('Map created...');
    console.log(map);

    map.loadSync(resolve('./samples/stylesheet.xml'));
    console.log('Map stylesheet loaded...');

    map.zoomToBox(0, 0, 5000000, 5000000);
    console.log('Map zoomed...');

    console.log(map.extent);

    map.renderFileSync('/tmp/map.png');
    console.log('Map rendered...');

    let data = fs.readFileSync('/tmp/map.png');
    console.log('Map data read...');

    await SaveToS3('map.png', data);
    console.log('Map data saved to S3...');
}

The above function results in the following output:
image

Note how the x dimension extents are limited to NaN and the y coordinates are not.

What I expected

I expected Maps with NaN dimensions to be invalid and error, or at the very least produce a warning.

I would also expect that even if the Map is created in this situation, since both Map dimensions are NaN it would treat the x and y parts of the zoom consistently and either they would all assign correctly, or they would all NaN (or even better produce an error / warning feedback as to what was going on).

Ideally I'd say situations like this should reject creating the map.

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

1 participant