Update: new server not fully ready yet, while old one falls apart. Hope to have everything ready for switchover by tomorrow, June 30th
My MapOSMatic server ran into some performance issues last week 🙁
This already started on Monday, but being on vacation away from home last week, and mostly offline, I only really noticed this late Thursday, and couldn’t do much about it before today.
Service should mostly be restored by now, but there were a few casualties:
- contour line and hillshade layers are unavailable for now
- there will be no further OSM data updates on this machine, so latest changes will not show on generated maps
I did not put too much effort into bringing the server back into a fully working state as I had planned to replace it with a slightly more powerful (and at the same time a bit more affordable) machine by the end of the month anyway.
So for now a few features will be missing, but by end of the week latest everything should be fully working again as before, plus some small additional things, when I switch over to the new server.
Right now the new machine is still busy doing the initial full OSM planet imports for the main and the waymarked trails databases, after that I’ll have to move over the full history of rendered jobs, and perform some testing.
My most optimistic estimate, if nothing goes wrong, would be that the new server can take over by tomorrow, Tuesday June 23rd in the european evening …
Page preview now shows an estimate for what parts of the selected paper size will be filled by the actual selected area:
Continue reading “Page size preview improvements”
Ubuntu 20.04 LTS “Focal Fossa” was released this week, and I’ve taken the opportunity to update the maposmatic-vagrant test setup to this long term support version, too.
During the Karlsruhe Hack Weekend hosted by Geofabrik, I made it possible to upload more than just one GPX track or Umap export file per MapOSMatic map render request. The screenshot shows a preview with three GPX tracks, colored in red, green and blue.
The file upload user interface has also changed slightly: instead of separate form tabs for GPX and Umap files, there’s now just one form tab where multiple files can be uploaded. The file types will be auto detected now so there’s no need for multiple upload tabs anymore.
The code still needs some minor polishing, but all the major steps are in place, so it will probably go live on the public instance tomorrow …
There will be some upcoming changes to the paper size form step during the weekend, hopefully making the paper size selection a bit more intuitive.
This is roughly how it will look like:
Compared to the current radio button based solution:
Continue reading “Upcoming: new papersize form step”
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.
It is now possible to enter a custom paper width and height, so that map prints are no longer limited to the predefined paper sizes.
This can especially be useful when creating maps for different materials like textiles, customized jigsaw puzzles, etc. where the form factor does not match regular paper sizes.
As the headline says: this service has just received and processed its hundred thousands map render request.
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:
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 …