Category: osm

Data area bounds revisited

Do you remember my earlier post on data area bounds ?

Turns out I was a bit too naive on believing that the largest administrative bounds polygon in an extract always equals what the extract is actually supposed to be containing.

This assumption can be false for many different reasons:

  • there may be a larger admin polygon that just happens to be part of the extract as it intersects with its bounding box, but extends far beyond it
  • the largest polygon may not actually be included as it’s extending beyond the bounding box slightly, e.g. due to the bounding box being based on an older version of this border polygon
  • the extract may just be a real rectangular area extract after all

This sometimes lead to a wrong admin polygon being shown as assumed data bounds, often one that only represents a small subset of the actual data.

So the bounds logic has now been changed to only assume that the largest contained admin polygons bounding box width and height are both witin 75% and 110% of the total data bounding box width and height. Otherwise the bounds shown on the slippy maps will just be that of the full data bounding box.

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.