Git Product home page Git Product logo

nik4's Introduction

Nik4

This is a mapnik-to-image exporting script. It requires only mapnik-python bindings. Install it with pip install nik4 or easy_install nik4 and run with -h option to see available options and their descriptions.

Why is it better

Nik4 takes great care to preserve values you feed it. If you say you need a 800×600 image, it won't take a pixel less or more. It won't shrink a bounding box or distort lines when specifying so called "scale factor". When you need a 300 dpi image, you tell it --ppi 300 and can be sure you will get what you intended.

For example, this is a sample rendering of an area in Tallinn on zoom 17, by Nik4, Nik2img and as seen on the default layer on osm.org:

nik4 - osm.org - nik2img

Also it can use real-world units, that is, millimeters (and prefers to). Specify dimensions for printing, choose bounding box and ppi scale — and the result won't disappoint. Options are intuitive and plenty, and you will be amazed how much tasks became simpler with Nik4.

How to use it

Again, run nik4.py -h to see the list of all available options. Here are some examples.

Watch a mapping party area

First, if you haven't already, install PostgreSQL+PostGIS and Mapnik, and use osm2pgsql to populate the database with a planet extract. For instructions see here or here. Get bounds by visiting osm.org: click "Export" and "Choose another region". Then:

nik4.py -b -0.009 51.47 0.013 51.484 -z 17 openstreetmap-carto/osm.xml party-before.png

Here osm.xml is the compiled Mapnik style. Then you can update you database and generate snapshots of an area as it is being mapped. Alternatively, you can specify an area with its center and desired image size in pixels:

nik4.py -c 0 51.477 --size-px 800 600 -z 17 openstreetmap-carto/osm.xml party-before.png

Even simpler, instead of --center and --zoom options, just grab an URL of a place:

nik4.py --url http://www.openstreetmap.org/#map=16/55.9865/37.2160 osm.xml screenshot.png

Make a georeferenced raster image

Some people prefer planning routes with OziExplorer or similar programs. Or want to take a big raster map with them on the road. For that a very big image is needed. Usually they turn to downloading and stitching hundreds of tiles, but with Nik4 you can make Mapnik produce a better looking map, faster and without bothering tile server administrators.

Since you are not bound to any tile provider, you should employ TileMill for customizing your map style: for example, remove forest on low zooms, add contrast to road lines, render more villages, highlight useful POI and cycling routes.

nik4.py -b 25 61.6 30.6 63.3 -z 13 custom.xml kuopio.png --ozi kuopio.map

This will render 16311×10709 image with a georeferencing file ready to open in OziExplorer. For a .wld file, which can be used in desktop GIS applications or for creating a GeoTIFF file, use --wld option. You can convert png+wld to geotiff with GDAL:

gdal_translate -of GTiff -a_srs epsg:4326 image.png image.tif

Make a BIG raster image

You would likely encounter out of memory error while trying to generate 16311×10709 image from the last chapter. Despair not:

nik4.py -b 25 61.6 30.6 63.3 -z 13 custom.xml kuopio.png --ozi kuopio.map --tiles 4

Voilà — now Mapnik has to generate 16 images of a manageable size 4078×2678. After that Nik4 will call montage from the Imagemagick package to stitch all tiles together.

What if montage cannot fit images into memory? There is a way, but you would need quite a lot of disk space, several gigabytes:

for i in *_kuopio.png; do convert $i `basename $i .png`.mpc; done
montage -geometry +0+0 -tile 4x4 *_kuopio.mpc kuopio.png
rm *_kuopio.{png,mpc,cache}

These lines will convert all images to Imagemagick's internal MPC format, from which montage reads directly. You would need more space for a similar MPC cache of the output file. Note that most software will have trouble opening an image surpassing 200 megapixels.

Get an image for printing

A4 options

Let's say you need a 1:5000 image of a city center for printing on a A4 sheet with margins.

nik4.py -s 5000 --ppi 300 -a 4 -c 24.1094 56.9488 --margin 10 ~/osm/krym/carto/osm.xml 4print.png

What you get is a raster image, which when printed on an A4 with 300 dpi resolution, would have 10 mm margins and scale of exactly 50 m in a cm. See the picture above for explanation of margins and other options. Formats can be a0-a9, letter, card and so on. The paper orientation depends on a bbox; to force landscape or portrait orientation prepend the format with + or - characters. Or don't bother and enter numbers by hand: -d 150 100 will export a 15×10 postcard map.

Wait, what's that again, about dimensions?

Dimensions you specify in --size (-d) and --size-px (-x) arguments are not exactly width and height in that order: they will be swapped if a bounding box would fit better. For example, when you export "landscape" bbox and specify -d 200 400, the image would be 40 cm wide and 20 cm tall. To prevent this behaviour, use --norotate option: with it, that image would be 20 cm wide, with the bounding box expanded vertically.

When you don't want your bounding box altered, use 0 for one of dimension values. The first one in that case is considered a long side length, the second is for shorter side. With --norotate option, they are width and height respectively. For example, -x 1024 0 --norotate would make the resulting image 1024 pixels wide regardless of bounding box proportions.

Print a route

On the image above there is a route. Nik4 cannot parse GPX files or draw anything on top of exported images, but it can manage layers in Mapnik style file. And Mapnik (via OGR plugin) can draw a lot of things, including GPX, GeoJSON, CSV, KML. Just add your route to the style like this:

<Style name="route" filter-mode="first">
  <Rule>
    <LineSymbolizer stroke-width="5" stroke="#012d64" stroke-linejoin="round" stroke-linecap="round" />
  </Rule>
</Style>
<Layer name="route" status="off" srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs">
    <StyleName>route</StyleName>
    <Datasource>
       <Parameter name="type">ogr</Parameter>
       <Parameter name="file">/home/user/route.gpx</Parameter>
       <Parameter name="layer">tracks</Parameter>
    </Datasource>
  </Layer>

Note that you can add it in any place: for example, between road and label layers, so the route does not obscure any text. Also note status="off": this layer won't be drawn by default. So if you want to export a clean map for the extent of your route (or any other) layer, use those options:

nik4.py --fit route --size-px 400 700 osm.xml route_area.png

To enable drawing of the layer, use --add-layers option:

nik4.py --fit route --add-layers route,stops --ppi 150 -a 6 osm.xml route.png

You can list many layers, separating them with commas. And you can hide some layers: --hide-layers contours,shields. Obviously you can fit several layers at once, as well as specify a bounding box to include on a map. All layer names are case-sensitive, so if something does not appear, check your style file for exact layer names.

Print a different route each time

Nik4 supports variables in XML styles: ${name:default} defines a variable with the given name and its default value (which can be omitted, along with :). To substitute variable definitions with values or defaults, use --vars parameter. For example, let's make stroke width in the last example configurable, and request GPX file name:

    <LineSymbolizer stroke-width="${width:5}" stroke="#012d64" stroke-linejoin="round" stroke-linecap="round" />
    ...
      <Parameter name="file">${route}</Parameter>

Now to make an image of a route, use this command:

nik4.py --fit route --ppi 150 -a 6 osm.xml route.png --vars width=8 route=~/routes/day2.gpx

Note that path would likely to be resolved relative to the XML file location. If you omit route variable in this example, you'll get an error message.

Generate a vector drawing from a map

It's as easy as adding an .svg extension to the output file name.

nik4.py --fit route -a -5 --factor 4 osm.xml map.svg

Why did I use --factor (it's the same as using --ppi 362.8, which is 90.7 * 4)? Shouldn't vector images be independent of the resolution? Well, the problem is in label kerning:

SVG labels quality

Left image was exported with --factor 1. You can see in "ali", "sis", "Uus" that distance between letters is varying unpredictably, not like the font instructs. That's because Mapnik rounds letter widths to nearest integers, that is, to pixels. By increasing the resolution, you make that granularity finer, so rounding errors are much less prominent. Labels would become slightly longer, that's why they are different in the second image.

You can export a map to PDF and be done with it, but often you'd want to do some postprocessing: move labels away from roads, highlight features, draw additional labels and arrows. For that I recommend processing the SVG file with mapnik-group-text, which would allow for easier label movement.

See also

For generating tiles, see polytiles.py.

Author and license

The script was written by Ilya Zverev and published under WTFPL.

nik4's People

Contributors

amdmi3 avatar knowname avatar nakaner avatar phyks avatar sebastic avatar woodpeck avatar zverik avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nik4's Issues

Add unit tests

The code which calculates the bounding box, scale, scale factor etc. has become quite long and it is likely to break something if you fix/add something different. @Zverik moved it into its own function recently. However, a few unit tests would benefit the project.

I started working on testability today. You can see progress in the branch unittest in my fork of this repository. To make testing easier, I created a new class Nik4Image. I will move more and more code from the main nik4.py file into it.

Feedback is welcome.

Error every time

Not sure what I am doing wrong but I always get an error when trying to run Nik4.

For example running this:
/nik4.py -c 0 51.477 --size-px 800 600 -z 17 turkart.xml test.png

Returns this:
Traceback (most recent call last):
File "./nik4.py", line 306, in
style_xml = xml_vars(style_xml, options.vars)
File "./nik4.py", line 154, in xml_vars
for kv in variables:
TypeError: 'NoneType' object is not iterable

Thank you! <3

Hi @Zverik,

I just wanted to say “Thank you” for a really great program. I can’t live without it in my OSM work anymore :-). Keep up the good work! ❤️

Greetings
Marvin

Mind the CDATA when xml-escaping variables

Can someone please explain why some chars in the vars-parameters are replaced by nik4 (line 157)? This way Postgresql throws an error, because the single quotes in the given sql-fragment are replaced by ' Are there any side-effects if we remove the single-quote replacement?

<Layer status="off" name="xxx" srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"> <StyleName>xxx</StyleName> <Datasource base="xxx"> <Parameter name="table"><![CDATA[(SELECT id, the_geom FROM xxx WHERE ST_Contains(${sql_poly}, the_geom)) as foo]]></Parameter> <Parameter name="key_field"><![CDATA[id]]></Parameter> <Parameter name="geometry_field"><![CDATA[the_geom]]></Parameter> </Datasource> </Layer>
nik4.py --vars sql_poly="ST_GeomFromText('POLYGON((9.6101188659668 53.324516580827, 9.6933746337891 53.323081133135, 9.6933746337891 53.294875047878, 9.6104621887207 53.297440007518, 9.6101188659668 53.324516580827))',4326)" ...

Extend -a option to support more paper formats

Make it accept any string, which is a paper format; prefixed with + for landscape and - for portrait, default depends on bbox. Would allow for -0. Leave numbers as a fallback to ISO An, and add other popular formats, like US Letter, Bn (for books), 4A0 and 2A0, business cards, photo papers etc.

The synonim would be --paper.

tiles option leads to rendering artefacts

The usage of the tiles option (e.g. --tiles 2) leads to rendering artefacts.

bildschirmfoto 2018-11-27 um 07 10 17

If the aim is to create one large image (e.g. 25000x25000 pixels) the tiles option isn't necessary at all. mapnik has (as far as I know) no size limit. It seems that the problem comes in with the resize function (which seems to be limited [16384?]):

...
    # for layer processing we need to create the Map object
    m = mapnik.Map(100, 100)  # temporary size, will be changed before output
    mapnik.load_map_from_string(m, style_xml.encode("utf-8"), False, style_path)
    m.srs = proj_target.params()
...
    # export image
    m.aspect_fix_mode = mapnik.aspect_fix_mode.GROW_BBOX
    m.resize(size[0], size[1])
    m.zoom_to_box(bbox)

A possible solution to avoid the rendering artefacts (if the aim is to create one large image) is to avoid tiling and resizing.

...
    # for layer processing we need to create the Map object
    m = mapnik.Map(size[0], size[1])
    mapnik.load_map_from_string(m, style_xml.encode("utf-8"), False, style_path)
    m.srs = proj_target.params()
...
    # export image
    m.aspect_fix_mode = mapnik.aspect_fix_mode.GROW_BBOX
    m.zoom_to_box(bbox)
...

Streaming output image to stdout doesn't work

Executing nik4.py --fit route --padding 30 --add-layers route,stops --vars route=/path/to/route.json --ppi 100 -a +4 /path/to/osm.xml - outputs the following traceback:

Traceback (most recent call last):
  File "/path/to/nik4.py", line 677, in <module>
    run(options)
  File "/path/to/nik4.py", line 520, in run
    im.save(outfile, fmt)
Boost.Python.ArgumentError: Python argument types in
    Image.save(Image, _io.BufferedRandom, str)
did not match C++ signature:
    save(mapnik::image_any, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, mapnik::rgba_palette)
    save(mapnik::image_any, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
    save(mapnik::image_any, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)

While nik4.py --fit route --padding 30 --add-layers route,stops --vars route=/path/to/route.json --ppi 100 -a +4 /path/to/osm.xml /path/to/out.png works fine.
Is this a problem with Nik4 or perhaps with the way it or some dependency is packaged? I could try installing it via pip on Arch Linux if you think that this may help.
I'm running the latest version 1.7.

Segmentation fault (core dumped) with GeoJSON

I am trying to render a GeoJSON with Nik4. Can you reproduce the following setup?

Command

nik4.py -p 550 -b 11.79656982421875 55.41810255439062 13.4417724609375 56.07356844648383 -z 11 test.xml map.png

Error message

Segmentation fault (core dumped)

GeoJSON test.geojson
https://gist.github.com/anonymous/567c1138bb1327662a0b

Stylesheet test.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Map[]>
<Map srs="+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over" maximum-extent="-20037508.34,-20037508.34,20037508.34,20037508.34">

<Parameters>
  <Parameter name="bounds">-180,-85.05112877980659,180,85.05112877980659</Parameter>
  <Parameter name="center">0,0,2</Parameter>
  <Parameter name="format">png8</Parameter>
  <Parameter name="minzoom">0</Parameter>
  <Parameter name="maxzoom">22</Parameter>
  <Parameter name="scale">1</Parameter>
  <Parameter name="metatile">2</Parameter>
  <Parameter name="id"><![CDATA[test1]]></Parameter>
  <Parameter name="_updated">1402561991000</Parameter>
  <Parameter name="tilejson"><![CDATA[2.0.0]]></Parameter>
  <Parameter name="scheme"><![CDATA[xyz]]></Parameter>
</Parameters>


<Style name="test" filter-mode="first">
  <Rule>
    <MarkersSymbolizer width="6" fill="#ff4455" stroke="#881133" allow-overlap="true" ignore-placement="true" />
  </Rule>
</Style>
<Layer name="test"
  srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs">
    <StyleName>test</StyleName>
    <Datasource>
       <Parameter name="file"><![CDATA[/home/uli/Documents/MapBox/project/test1/layers/test.geojson]]></Parameter>
       <Parameter name="layer"><![CDATA[OGRGeoJSON]]></Parameter>
       <Parameter name="type"><![CDATA[ogr]]></Parameter>
    </Datasource>
  </Layer>

</Map>

add-layers feature not working

It seems that the --add-layers option isn't working in Nik4 1.6.

In the xml file I have this:

<Layer name="printmaps_point" status="off" srs="+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs">
    <StyleName>printmaps_point</StyleName>
    <Datasource>
       <Parameter name="type">ogr</Parameter>
       <Parameter name="file">${point_file:no_default}</Parameter>
       <Parameter name="layer">${point_layer:no_default}</Parameter>
    </Datasource>
</Layer>

But the layer isn't activated with this program call:

nik4.py --add-layers printmaps_point --zoom 15 ...

scale=4.70980476192
scale_factor=1.01433296582
size=2173,2173
bbox=Box2d(833675.160253,6787056.39383,843909.566001,6797290.79957)
bbox_wgs84=Box2d(7.48903138446,51.9276621344,7.58096861553,51.9843199662)
layers=coast-poly,waterarea,buildings,highways

PS: Everything works fine if I activate (status="on") the layer direct in the xml file.

Regards Klaus

Edit / additional info: I'm using Mapnik 3.0.9.

Publish release tags

Please publish release tags for new versions.

This well help downstream users to be notified of new releases.

Cannot input both ppi and scale_factor

When inputing both ppi and scale_factor, scale_factor is overwritten.
The "zoom-level" used (which is passed to mapnik through the scale_factor) seems to not be changeable at a given dpi and scale (which is not not self-contradicting).
Probably the same that you cannot input both zoom and scale (scale is overwritten).
Is it too specialised (or badly-understood) a problem to be taken into account?
(I'm usually using options: paper, dpi, scale, factor, center)

Add "tiled" mode

It's impossible to create images 10k × 20k because of memory limits. But we can create smaller tiles, like 4 images of 5k × 10k, and stitch them together. So check for imagemagick for stitching and add --tiled N options, where N is a number of tiles: 1 for disabled, 2 for 2×2 etc.

Add option to specify parameters in stylesheet.xml

I like to run a query inside my stylesheet to get a certain feature from my database. It would be nice if I could specify a parameter (e.g. an ID) that will be used inside the function in the Style-sheet.

scale_factor is misused?

Привет, Зверик :)

I may be totally wrong but from my observations current implementation of scale_factor doesn't seem to work as expected.

Let's take an example invocation:

nik4.py -b 36.6481408595 55.9508668696 36.8974386671 56.127082206 -z 15 osm.xml out.png

This generates an image with dimensions 5809x7350 with unscaled features.

So I'm gonna get use of documented scale_factor which is implemented in Nik4 as --factor parameter:

nik4.py -b 36.6481408595 55.9508668696 36.8974386671 56.127082206 -z 15 --factor 2 osm.xml out.png

and I get a double-sized image: 11618x14701. Yet, labels (and the rest) are very tiny — which is pretty expected as the scale_factor is not enough. But increasing it up to 6 or more leads to even bigger images which requires --tiles to be used - which is not an option. This happens also if the target is set to PDF.

After brief code review I saw that scale_factor variable takes part in calculating map scale and the size of the resulting image. Which made me think that it is sorta misused: the only actual purpose of scale_factor — is to scale features. So I'd expect my image to be of the same 5809x7350 size but with scaled text and features.

In attempt to figure out an alternative approach of doing things I patched Nik4 by adding an additional parameter --factor2 which is then passed to mapnik.render() directly. As I expected the image size was preserved (5809x7350) and the features were scaled. But this was not flawless, as lot of features began to disappear :(

For example, this rule from placenames.mss:

#placenames-small::hamlet {
  [place = 'hamlet'],
  [place = 'locality'],
  [place = 'neighbourhood'],
  [place = 'isolated_dwelling'],
  [place = 'farm'] {
    [zoom >= 15] {
      text-name: "[name]";
      text-size: 19;
      text-fill: @placenames;
      text-face-name: @book-fonts;
      text-halo-radius: 1.5;
      text-halo-fill: rgba(255,255,255,0.6);
      text-wrap-width: 45;
      text-min-distance: 10;
    }
    /* ... */
  }
}

is not triggered at all at -z 15 and I had to change it to [zoom >= 12] { to get those features back.

Well, any ideas?
Че делать-та?

Python 3 support

Please add support for Python 3, running nik4.py with Python3 currently fails with a SyntaxError:

  File "nik4.py", line 379
    print 'scale={}'.format(scale)
                   ^
SyntaxError: invalid syntax

Support different projections in OziExplorer file

Hi and thanks very much for taking the time to create this useful script.

In Great Britain, Ordnance Survey maps (used by many hikers etc.) use the British National Grid (EPSG:27700). This system is widely used to specify co-ordinates and so it is useful to be able to use this projection and co-ordinate system in Mapnik.

It would be great if Nik4 was able to generate an OziExplorer file which automatically grabs the projection from the Mapnik XML file so that projections such as this could be supported. This currently seems to be hardcoded here.

"status=off" breaks "--fit"-Option since mapnik commit e26570d

Since e26570d mapnik does not instanciate layers with "status=off" in the stylefile anymore.
This causes Nik4 to break if you try to use the "--fit" options as described in the example of the README:

nik4.py --fit route --add-layers route,stops --ppi 150 -a 6 osm.xml route.png

I suggest to add a "status=initialize" (or "status=load") to the style and update mapnik accordingly.

Tiling along a route

Hi,

First of all, thanks a lot for this wonderful tool which is, so far, the best tool I know to export maps for print!

In particular, I'm a huge fan of the "print route" feature, to output daily maps of bicycle trips. One issue I have so far is however that it requires quite a lot of manual handling to split a multi-day GPX track and output pages per day, while fitting my printing capacities (only A4 / A3 for instance). This, or exporting a very large picture and tiling manually in an editing software aftewards.

A feature which would be a really nice addition would be to be able to tile along a route with a given paper size. That is tell Nik4 a paper size (typically A4) and a route to fit (--fit route style for the simplest, could be refined afterwards to not take only the bounds into account but the true shape as well) and a padding. It would output a set of tiles (each of size A4) along the route.

What do you think about this?
Thanks!

--url

Add --url option for an OSM url. Take center coords and zoom from it, add default size (1280×1024). So basically one could run nik4.py --url <url> style.xml output.png.

DPI and zoom levels

Hi,

I don't get how zoom level is computed. I would have expected

python ./nik4.py --dpi 600 -a 4 --fit route --add-layers route ../cyclosm-cartocss-style/mapnik.xml a4.png --vars gpxroute=/tmp/route.gpx

and

python ./nik4.py --dpi 300 -a 2 --fit route --add-layers route ../cyclosm-cartocss-style/mapnik.xml a2.png --vars gpxroute=/tmp/route.gpx

and

python ./nik4.py --factor 2 --dpi 600 -a 4 --fit route --add-layers route ../cyclosm-cartocss-style/mapnik.xml a4.png --vars gpxroute=/tmp/route.gpx

to give the same output as an A2 paper is twice an A4 paper in each dimension.

Changing factor and DPIs gives the same result (that is a wider image but showing the same thing, at the same zoom level, as a --dpi 300 -a 4 image). Switching to A2 paper size however gets a different result, with a different zoom level in use. However, all of the generated images (A4 or A2 with the above commands) do have the same number of pixels.

Why does dpi does not have any effect on the zoom level in use?

Thanks!

Problem using fit route with specified format

Hello,

we are trying to use Nik4 for exporting map pdfs witih our custom map style. Using fit route together with a specified format (in this example Din A4) we are not getting the correct mearurements:

nik4.py -a 4 --padding 10 --fit route --add-layers route /home/osm/gs_sommer_web/project.xml /var/www/osm/test.pdf --fonts /usr/share/fonts

This resulted in a pdf with the size 374,3 x 264,6,instead of 297 mm x 210 mm (landscape)
Can you help us with this issue? Is there any parameter missing?

Thank you so much for your assistance

NameError with -c option

Hello,

thanks for your work on nik4, it is very useful. There seems to be a small problem with the -c option, though:

$ nik4.py -c 7.5 52.0 -s 5000 --margin 10 --ppi 300 -a 4 mapnik.xml print.png
Traceback (most recent call last):
  File "/home/ug/.virtualenvs/maps/bin/nik4.py", line 289, in <module>
    scale = scale / math.cos(math.radians(center.y))
NameError: name 'center' is not defined

If I understand correctly, center.y should be replaced by options.center[1], at least this makes the code run through (or is it necessary to apply some transform here?).

Padding in real meters

Hi,

When fitting a route, a typical use case I have for padding is to include "as much X kilometers along the route". What about providing an alternative padding option using (OSM) meters as unit instead of paper units?

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.