The database import has finished and the rendering daemon is running again.
The Openstreetmap and German Carto stiles have been updated to their most recent releases, so rendererd maps should finally look the same as on openstreetmap.org and .de again. The rest of the styles will follow today.
Database updates still need some work, so for now map data is of last Thursday, the time of the last full planet export.
I will have to do another full import again, causing about a day of outage and some more before the MapOSMatic service instance is fully up to data again.
Starting tonight (Friday April 13th, 2018) at 21:00 UTC the GIS database will be offline, so no new rendering jobs will be processed until for a while. The web frontend will still work most of the time, already rendered Maps will still be available, and submission of new jobs may be possible, but these will only be queued then, and will only be processed after the database import, and some additional changes like stylesheet updates, have finished.
The reason this time is not that I did something wrong on the previous import, or on the minutely diffs import to keep the database up to date. This time it is neAeded to apply the necessary schema changes needed to finally support current OSM Carto default style releases again. OSM Carto v4.0 changed the database requirements in a non-backwards-compatible way, so a re-import is needed to not be stuck on v3.x forever, and to make the default style look the same as on openstreetmap.org again.
To be able to still support all the other older styles again, and to provide better internatiolization and localization features in the near future, I’ll actually be using the hstore-only schema used by the current German OSM style maintained by Sven Geggus, with database views on top that then provide the right schema for each style.
All this works fine in my test environment already, it just needs to be applied to the big machine now, and the re-import is the biggest step of that. I’ll be working on this during the upcoming Berlin OSM Hackweekend, and hope to have everything up and running again Saturday evening, but it may take parts of Sunday, too.
So far street names that start or end in a number were sorted in simple textual order, e.g. 1-10-11-…-19-2-20-21-…
Now, with the help of the Python “natsort” package, these will be listed in “natural” order, like 1-2-…-10-11-…-19-20-21-…
At first this only worked for ASCII / Latin numbers, but with two little fixes to the “natsort” package it should now work for all numeric unicode characters (tested with Persian/Farsi so far).
I started to work on a RESTish/JSONish API for direct automated submission of rendering requests. This is all still work in progress, and subject to further changes, so I don’t want to make it publicly available yet.
If you are interested in draft documentation, example code, and a test account please drop me a mail on <email@example.com>
There have been a few small, but very useful user interface changes recently:
- When accessing the service for the first time the map will be centered to your current location, when detactable. The old “Bielefeld” default will only be used when location data is not available
- From there on the map will be centered to the the area you last used for creating a map
- The layout, style, and overlay you had used in your last request will be remembered and used as default choices, instead of just pre-selecting the first choice.
Umap overlay support hat a slightly bumpy start, so I may have put it on the public server too early, but should now be fully usable in single page mode.
Fixes and improvements applied during the last two days include:
- rendering doesn’t fail anymore when certain properties are not found
- per-layer defaults are now taken into account in addition to global ones
- the “circle” and “ball” markers are now rendered properly
- whether a marker icon should be black or white is now reliably detected
- external marker icons referenced by http: or https: URLs are now downloaded and displayed
- dash patterns are supported when rendering lines
- the map title field is pre-filled with the Umap map name
- when the umap file uses a tile layer style supported by this MapOSMatic instance it is auto selected
Things that are still missing or need to be fixed:
- Umap overlay rendering in multi page format
- handling of label display options
- vertical marker positioning may still be minimally too low or high
As an alternative to GPX uploads it is now also possible to uploaed saved Umap maps and render the contents as an overlay.
Continue reading “Umap overlay support added”
Finally implemented a feature long overdue: the footer text now not only contains information about the software and the data source, but also about the style used to render the map, and about all overlay styles used on top of it.
After hopefully having sorted out all problems caused by the rusher migration to a new, faster server I’ve now finally figured out how to improve the user interface for GPX uploads.
Continue reading “GPX upload improvements”
There are still a few small things not working well on the new machine yet, as due to the failure of the old machine ahead of time.
Problems that I’m aware of right now: