In fact, the MapQuest service returns strange results that don't match
the osmid we have in our database, so most results are
unusable. Switch back to the original Nominatim service.
The original is _always_ better than the copy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
This commit implements a new item on the right of the MapOSMatic
website, which gives users the current time delta between our GIS
database and the official OSM database.
In order to implement this, we created a small gisdb.py module which
factorizes the work of connecting to the GIS database, now used by
both the Nominatim code and our new code that fetches the last update
of the GIS database through the maposmatic_admin table.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
Contrary to what we initially thought, there is no way to know if
Nominatim has further results or not. Even if the first results
returned by Nominatim are limited to 5 results (i.e less than the
maximum number of results Nominatim can return on a single page), it
does not mean that Nominatim has no further results.
So, we just assume that Nominatim may have further results.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
Nominatim returns some search results that are not appropriate for
MaOSMatic because they do not have an administrative boundary. We show
those results so that users aren't confused, but we also display a
message explaining why those results can't be used. This commit
implements this message.
Instead of putting the message in the Javascript, which would require
interfacing the Javascript code with the Django translation/locale
system, the message is stored in an hidden <span> element in the HTML
code (and is therefore translated like all the rest of the HTML text
by the Django translation infrastructure). This message is copied by
the Javascript code at the right place when needed. We were already
doing the same thing for the #noresultsinfo message.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
The doQuery() Javascript function takes as argument the list of places
to excludes from the list (necessary to implement and next and
previous buttons), but we were not calling it with this argument when
the user was typing text in the input box.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
On the website, the language selector dropdown list was ordered in a
more or less random way, depending on how languages were listed in the
MAP_LANGUAGES array of the settings.py file. This had the unfortunate
effect of proposing a language which is not necessarily the most
common language for the country in which the city to be rendered
is. For example, for all cities located in France, the language
proposed was Catalan (because ca_FR is before fr_FR in the
alphabetically-sorted list of locales).
Therefore, this commit does two things to solve this problem:
* The MAP_LANGUAGES array in settings.py is now statically sorted by
country rather by language, and then the different languages of a
given country must be manually sorted (by the developer who adds
them) from the most widely used language in the country to the
least widely used language.
* The Javascript code is modified so that the order of the languages
in MAP_LANGUAGES is preserved. For this, a new jQuery function
called reverse() has been added.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
Very old jobs rendered by administrative boundary didn't store the
corresponding OSM ID, so we can't easily find them back to see if a
rendering already exists when recreating a map. This led to weird
behavior when recreating a map where the user would get redirected to a
completely different map (the most recent map rendered by administrative
boundary).
This fixes bug #31175.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Very old jobs rendered by administrative boundary didn't store the
corresponding OSM ID, so we can't easily find them back to see if a
rendering already exists when recreating a map. This led to weird
behavior when recreating a map where the user would get redirected to a
completely different map (the most recent map rendered by administrative
boundary).
This fixes bug #31175.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Added a few instructions in INSTALL to test. Also added instructions
in the config templates to help customize the python search path.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
When an error occurs while processing the form's data, cleaning up the
data can result in attempting to delete non existent keys. This patch
should make the code tolerant to the half-created form data we have to
deal with in that case.
The problem happened 5 or 6 times within the last 3 weeks.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
This patch makes sure that we can work on the exact same city envelopes
in maposmatic and ocitysmap: we now share ocitysmap's
get_geometry_from_osmid(). Previously, get_bbox_from_osmid crashed if
the osm ID was present multiple times in the polygon table, and
ignored the line table. This patch fixes both, by basing itself on
ocitysmap's 093b95bcf6f54e855b781a9ccd60ce8117b35976.
Thomas Petazzoni