When a map search that doesn't yield any results is performed, the
entire list of maps was displayed instead of an information message
because of a programming error.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Each completed job now features a "Recreate map" button that reschedules
a similar map on the queue. The button only appears for completed maps
(status >= 2), and triggers a rendering_already_exists() check before
creating a new MapRenderingJob.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
In preparation for the "Recreate Map" feature, extend the
rendering_already_exists method to work on bounding boxes as well,
making it possible to redirect to a recent rendering for the exact same
bounding box.
The original method was split in two distinct methods,
rendering_already_exists_by_osmid and rendering_already_exists_by_bbox,
each working in one of the map selection modes. A new
rendering_already_exists method replaces the old one, now working on on
MapRenderingJob object, and handling the dispatch between the two new
rendering_already_exists_by_{osmid,bbox} methods.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
When no map has been rendered in the last 24 hours, the RSS feed can be
empty, which is not good. Fall back to the last 10 entries, regardless
of any time limit, when this happens.
If no map at all was ever rendered, well we don't have much choice but
to send back an empty feed.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
It is useful to know first-hand when the rendering daemon is not running
anymore. When this is the case, this will display a warning banner below
the menu.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
The renderer threads did not handle exceptions happening during the
data preparation phase. This commit fixes this, avoiding the daemon to
vanish when asking a rendering that fails (most common cause is GEOS
intersect errors).
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Restore the bounding box input fields to directly enter the boundaries
of an area to render.
Re-implemented the Control+drag selection method to select an area to
render.
Added a small help-text about the special zoomIn/selectControl features
of the slippy map.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Integrate MapOSMatic Spanish translation, contributed by:
* Jean-Guilhem Cailton <jgc@arkemie.com>
* Sebastian Borgwardt <sebastian.borgwardt@aonikenk.com>
* Julio Costa Zambelli <julio.costa@openstreetmap.cl>
The following countries where Spanish is either the official language or
a major secondary language have been added to the list of available map
localizations for Spanish: Argentina, Bolivia, Chile, Costa Rica,
Dominican Republic, Salvador, Guatemala, Honduras, Mexico, Nicaragua,
Panama, Paraguay, Peru, Puerto Rico, USA, Uruguay and Venezuela.
The Spanish translation of the website is also now available from the
language selection drop-down.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
I receive annoying django error emails about EmptyPage being
unresolved. This patch should fix this problem.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
When no information is available to create an index, only the maps are
generated. We must handle this case when presenting the job information
on the website.
French translation was updated, other languages need updates.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
This dbck utility, run through the environment wrapper, checks and
cleans the MapOSMatic job database. This first version provides the
following checks/repairs capabilities:
* obsolete status
* mutually exclusive admin/bbox data
* missing map language
A --dry-run option is also available to only look at what operations
would be done.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
The render module, originally a simple extract of the render_job
function from the old daemon, has been rewriten to expose a more
sensible API and to provide self-contained timeout support.
Two classes are now available, exposing the same public API for seamless
use of any of the two:
* JobRenderer is a simple, blocking job renderer. It can be threaded
if the caller decides to call start() instead of run().
* TimingOutJobRenderer, as its name suggests, is a timing out job
renderer that makes use of the threading capability of JobRenderer
to handle a timeout on the rendering process and kill the rendering
thread, whatever it is doing, if the given timeout is reached.
The render module also now exposes a few public RESULT_ constants that
can be used to identify the result of a job rendering. This is used in
the daemon to infer an appropriate resultmsg.
As a standalone process, the job renderer now takes an optional second
argument: the timeout, in seconds.
.../scripts/wrapper.py scripts/render.py <jobid> [timeout]
As of now, the daemon is fully usable in production with the same level
of functionality as before.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
This is the first step of the rewrite of the MapOSMatic rendering
daemon. The long-term objective is to get a more flexible rendering
daemon that would support the rendering of several jobs in parallel, and
with an overall more Python-y and maintainable code.
This first shot brings a completely new, simpler MapOSMatic daemon with
the same level of functionality as the previous daemon in terms of
serial rendering of the job queue. Three major changes happen here:
1. the bash-based wrapper script has been removed, in favor of a more
clever Python wrapper. Cleaner, and more importantly more portable.
The wrapper still needs a bit of configuration, and after the
config.py-template has been tweaked into a valid config.py file,
the daemon can be started by:
.../scripts/wrapper.py scripts/daemon.py
2. the externalization of the rendering routine into a 'render'
module. This module does not access the database - only the daemon
does. The sole purpose of the render module is to encapsulate the
rendering process and its errors+exceptions handling.
It can also be used as a standalone, job-ID-based renderer:
.../scripts/wrapper.py scripts/render.py <jobid>
3. the cleanup mechanism now runs in a separate thread, in the
background.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Following the API change in OCitySMap to improve paralellization of
OCitySMap rendering processes, we now need to provide the prefix to the
map_areas table name. We use here 'maposmaticd_PID_'.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
To go with the Polish translation of OCitySMap by Łukasz Jernaś
<deejay1@srem.org>, offer Poland in the list of map languages available
when creating a map.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
The actual ways of getting the list of feed items to render was to
resource-consuming (two to three database queries). This change
simplifies it to list all successfull jobs from the last 24 hours.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
This change introduces a RSS feeds for the successfully rendered maps
that still have their files available (status=2) from the last 24 hours
(or more to get at least 10 items when possible), using the Django
syndication framework.
It uses a custom map-feed.html template instead of the map.html in order
to include styling information directly in the HTML an accomodate for
the variable naming from the syndication framework.
This new MapOSMatic maps feed is now available from a traditional RSS
icon link on the maps page.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
The rendered files sizes information was added to the job template, but
not to the map template for the maps page. This change fixes that, so we
have the info everywhere.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
When a map is made in bounding box mode, the list of available countries
is quite long and without any specific order. We now sort countries in
alphabetical order.
Maxime Petazzoni