| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
The JOSM button now contacts JOSM on http://localhost:8111/ if the taginfo page
is using http and https://localhost:8112/ if it is using https. This way we
don't have a problem with mixed content.
Also the way JOSM is called now works without the iframes which were a hack
around the (then) missing CORS ability.
|
| |
|
|
|
| |
This commit adds the new tab and new report but doesn't activate them, because
they will not work until the database backend is updated.
|
| | |
|
| |
|
|
| |
Superseded by the new Project tab.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Any kind of project using OSM tags can create a json-formatted taginfo project
file and after its URL is added to the taginfo config, taginfo will integrate
this data into its database.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Some data was HTML-escaped in the API results. Now data in API results is
(hopefully) all raw and clients have to escape as needed. One client is,
obviously, taginfo itself and a few places have been changed to do the
right escaping now.
Fixes #19.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Key and tag wiki pages can contain images. Until now we only got the titles of
those images. Now we also get the URL to the image, URL to thumbnails, width,
height, and mime type. This information is now exposed in the API and it is
used to show the images in the Overview tab of the key and tag pages.
While we are changing the update process anyway, I changed the program that
gets the list of all pages to also output the time those pages changed last.
This information is currently not used, but it could be used to cache those
pages locally making the update much faster and adding less strain to the
wiki server.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes there are not results for some query and you'll end up with an empty
table. It would be nice if no empty table appears in this case but instead some
nice message. But we can't simply remove the table, because if people use the
search-inside-table function and that was the result of the empty table they
loose the ability to change the search term.
We could only draw the table in the first place if there will be something in
it. But just finding out whether there will be something in the table can be
quite expensive, for instance with searches for values. So we don't want to do
this twice (once in the template to find out whether to draw the table in the
first place and once in the API call filling the table.) So we are currently
stuck with what we have until somebody invents a better way.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Old versions are marked as deprecated. All new API calls are documented.
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
are created dynamically according to the language.
|