Form submission switching to multi page format …

I’m not really sure what’s going wrong with it, but apparently the paper layout is sometimes automatically switching to multi page format on submission of single page render requests, and the choice is made “sticky”, too, so the next time you create a map from the same browser multi-page layout is pre-selected.

I’ve experienced that a few times myself now, even with witnesses looking over my shoulder when it happened, but I have no idea by what this may be triggered yet.

Unfortunately I don’t have the time to debug this either right now, but I hopefully will get this tracked down by the end of the week.

Meanwhile, if you are interested, you may subscribe to the related github issue report:

https://github.com/hholzgra/maposmatic/issues/40

New printer … recommendations?

Unfortunately my good old DesignJet printer acted up again on 36c3, being in on-and-off mode during most of day one, and breaking down totally on day two after just a few prints in the morning. Maybe it took the “Resource Exhaustion” congress motto too literal?

Anyway, the printer is some six years old by now, and was a discontinued model by the time I bought it already. So while I may be able to get it back to life once more by replacing another print head (with an originial this time, as with the refurbished once I tried there seems to be a one in four chance of immediate failure ….), I’m not going to move it around anymore.

So I’m currently thinking about a new Din A1 / 24″ roll printer for printing maps on events. The wishlist features would include:

  • affordable initial price of purchase
  • affordable consumable costs
  • sturdy design, less fragile than the DesignJet
  • not wider than ~96cm, so that it fits into a standard 1m flight case
  • able to print to it directly from Linux

Right now I think that of the current Din A1 models, the Epson SC-T3100N comes closes, but I’d very much be interested in hearing from anyone having first hand experience with it or with one of the alternative models.

What I know about it by now is:

  • acceptable price point, starting at slightly < 1000€
  • original ink seems to be at about half the price per ml as what I have to pay for the DesignJet
  • no need to replace print heads, just the ink cartridges themselves
  • nice cuboid case design, no parts sticking out, both the paper roll and A4 single page feeder are inside the case (roll holder and A4 feed sticking out on the outside are exactly why I don’t consider getting one of the more recent HP DesignJets at all)
  • seems to be just small enough to indeed fit into a standard flight case
  • not sure about the Linux part, but it seems to be able to emulate a HP DesignJet 500, so that should work out if there are no native drivers indeed
  • the ink is water resistant and is not supposed to bleach out when exposed to sunlight

The price point for this setup would be somewhat like:

  • ~1000€ for the printer itself
  • ~300€ for a flight case large enough for the printer and supplies
  • ~240€ for a full set of ink cartridges, good for about 100 A1 prints (assuming I get the same amount of paper covered per ml as with the current HP printer)

When also adding a small laptop to the mix, a full “ready to use” conference package should be doable for under 2000€ … a bit too much for myself to cover privately, but there seem to be options to get that solved …

DarkSlateGray

For some unknown reasons Mapnik has a problem with the color name DarkSlateGray, if this name occurs in a GeoJson color or fillColor attribute rendering will just fail with an exception.

Searching over the error logs I found that it is always just this one color name that makes rendering fail, but as I’m not sure about this being the only color name with a problem, I’ve now changed the Umap Json preprocessing code to do color name lookups on the python side already and replace them with their respective hex color code, so that Mapnik will never have to resolve color names by itself when processing GeoJson data files.

Umap improvements

Depending on how an UMAP map was created some default attribute settings like colors and shapes were ignored, and the default global fallbacks were used, leading to all-blue results.

This should be solved now, my umap format parser should now be able to handle all variants of the umap json export format, so that correct colors, line widths and icon shapes should be shown in the rendered maps.

Vagrant setup: refactoring

If you are using the Maposmatic Vagrant test setup, you may notice that its directory layout has changed a bit over the last days.

Aside from the elevation model related changes mentioned in the previous post, most change really just reorganized paths and changed directory and file names.

Some of the more notable changes beside the renames:

  • Style and overlay install scripts now no loner write out ocitysmap.cnf snippets, instead for each style setup .sh file there is now also an .ini file containing the ocitysmap.cnf style declaration block only. The ocitysmap-conf.sh script then creates a new ocitysmap.cnf file when run, by collecting all the .ini files from the styles and overlays sub directories, creating the available_styles: and available_overlays: lists from this, and concatenating all the .ini snippets to the end of the config file. As the config file is now re-created from scratch each time now this should be more robust than the previous approach.
  • The README.md file is more detailed now, including information on e.g. file system layout, adding new styles, or provisioning real servers …
  • The number of “red” lines shown during provisioning has been reduced as much as possible, and the remaining ones that can’t be avoided are listed in the README. Anything mentioned there can be considered OK, any other red lines should be considered a failure that someone should look into

Vagrant setup: hill shading and contour line setup

Originally the provisioning of the Vagrant test setup just installed hill shading and contour lines for a fixed area (parts of Germany).

From now on during provisioning the actual area covered by the imported OSM data file gets determined, then all the SRTM 90m zone files overlapping with the data bounding box are downloaded and processed to produce hill shading, relief, and contour lines data for the data area.

Depending on the size of your import datas bounding box this may slow down provisioning a bit, but on the pro side you get your actual data area covered instead of just a part of Germany you may not even be interested in.