Oct 6 2019
Sep 1 2019
Commons-on-OSM is only the frontend that I maintain, so I can't solve the problems of the backend of project geocommons ( https://tools.wmflabs.org/geocommons/kml?bbox=-0.3,-0.3,0.3,0.3 )
@sladen is perhaps the only active maintainer of project geocommons.
Jun 18 2019
Apr 5 2019
For me it seems so that kmlexport needs new maintainer. I wrote @Dvorapa a mail but he makes a break until July, if his user-page is correct. With osm4wiki it looks better but it doesn't work without kmlexport.
As far as I know, the osm4wiki use as backend the project kmlexport, which is not running after server move to stretch . So deactivating is in my eyes no problem.
For clarification I'm not a developer of osm4wiki, aim of co-maintenance was to be able to restating a server if necessary. I have no access to project kmlexport and both maintainer have a break or are inactive. It's not so nice as osm4wiki is linked inside different articles in German Wikipedia.
Mar 1 2019
@GTirloni @jcrespo The issue still exist but now it's necessary to import the data as the database was deleted by T216441.
I try to import Ukrainian Wiki a file with 4.3 GB and lost during the import the connection to the database:
Feb 25 2019
Main problem with repair is that the table "info" is away and this was created by hand and I have no idea about it's structure as it was many years ago. I have the hope that the other tables are generated by script.
Feb 24 2019
A repair on s51071__templatetiger_p would be nice. The easiest way to do this, would be allow me to import me new data from dumps but this is blocked by https://phabricator.wikimedia.org/T184126.
Dump files are here: /data/project/templatetiger/public_html/dumps/
Dec 7 2018
@GTirloni : Thanks for the cleanup script.
Dec 1 2018
Clean up done.
Sep 13 2018
Fine it's working. Thanks.
Sep 12 2018
It works now fine high zoom levels. Thanks.
Sep 8 2018
Sorry I was longer time AFK.
Aug 29 2018
@Bstorm: I think "copy" should import the unpacked file:
copy wp_coords_red0 from '/home/wp-world/new_red0';
Than I can start some some other sql-commands to create the other tables *red2,*red3 and *red4
Aug 24 2018
Luckily I have dumps (primarily as service for external users):
Further personal SQL-Commands:
@Bstorm : Yes the ticket is still a problem. You can self see that under database "gis" that my tables "wp_coords.." are still missing. This is also the error report of my script.
If the data was moved to an other database like u_kolossos a hint would be nice and I would need help how to access the other database (see above).
Aug 9 2018
On parts of my tool I'm still have a strong interest to maintain it.
But I deactivated the googlemaps proxy as I'm no expert on XSS security https://phabricator.wikimedia.org/T182341 .
The source code of the script is:
So if somebody would be able to repair it it would be nice.
Aug 8 2018
Jun 25 2018
After starting it with jsub (without autocommit=0) it lose the connection to the database during the LOAD DATA LOCAL.
Jun 24 2018
The line by line execution shows that the LOAD DATA LOCAL line was the point where it breaks.
Jun 14 2018
The import of some GB need some time. This was no problem in the past because I use "/* SLOW_OK */" in the sql-statement.
Jun 8 2018
Hello, it's cleaned up.
Mar 25 2018
I have two points, first the relation between Wikimedia Movement and OSM and second my opinion what we should do with gpsies and apemap as the largest external users.
Changed to wmflabs tiles.
Jan 11 2018
It's really seems related to T180380, but there is no solution.
Jan 3 2018
Jan 2 2018
May 20 2017
Cleaned up to 95 GB.
Feb 16 2017
@yuvipanda Yes it works fine.
Feb 15 2017
@yuvipanda Thank you. Fine.
I update the db to 2017. Everything works fine.
Now the database seems to be deleted/disappear. Anyone any idea?
Feb 10 2017
I would say the community should decides this question in each language. For me as a German it's e.g. ok to get English labels as fallback, for someone in eastern European projects it's perhaps better to get Russian as fallback.
It's in my eyes impossible to configure this from a central point.
Offcourse each user has different background which languages he can read. Each user have different usecase, e.g. sometimes he want to compare the map with real street signs on the street, so he need the pure name-tags. Sometimes he really need the labels in his own languages.
Dec 17 2016
I take I look in my old php-code of templatetiger and must say that it's horrible. There are wild string-construction to generate sql-queries. It's simply not to modify anymore.
I think it could need a complete rewrite in something like Python/Pandas and a complete new UI.
Oct 31 2016
Please, don't use Property P402 !!!
We show it on WIWOSM  project that we don't need it to link from Kartographer to an geometry in OSM.
We can use Wikipedia and Wikidata-Tags in OSM and are so more flexible to suport also points and lines without and relation-id. The relation ID's in OSM are not stable.
so please change Kartograher to support OSM data without P402.
Sep 13 2016
@yuvipanda : Do you know why templatetiger doesn't work and why I can't bring it back by restarting webserver?
I get an "502 Bad Gateway" . Thanks
Sep 10 2016
I reduced the volume to the minimum of 150 GB by deleting old files manually.
With the often broken dump files I have no better strategy.
Jul 29 2016
The osm-style have to be reduced to have place and clearance for additional overlays.
May 25 2016
templatetiger should be after cleanup now at under 140GB on file system.
templatetiger should be after cleanup now at under 140GB.
Feb 17 2016
I can recreate all data inside templatetiger, in the case of a disaster.
Jan 30 2016
To the first point: Yes to maintain a labs project would be to much overhead for me. Normally templatetiger is only a little php script and a database. The trouble with to sort script cames later.
Jan 27 2016
I will try now -T /tmp/sort. So the temporal dir should be local tmp .
I code this stuff, often after my regular job. So sometimes I'm fine if things seems to work, also if it's not optimal. Sorry if such things happen.
Is it true that "/tmp/" is locally on a server randomly choosen by jstart? So how can I use this files later in the next job to import it to database?
Sorry, I read this too late.
I will sort now to "/tmp/sort/" and hope thats ok.
Sep 22 2015
This task is also know as multilingual maps:
Should work in the future with vector tiles.
Sep 14 2015
Jul 27 2015
Thanks, it seems to work.
Jul 25 2015
Ping? The problem still exist.
Jul 3 2015
No I change only the scripts we have in production inside Wikipedia and Commons.
This doesn't also help maps that base on hikebikemap-tiles or blackwhite-map.
Jul 2 2015
I switch the standard tiles to osm.org:
Jun 6 2015
I (Kolossos) and Plenz are only developers for the frontend. We have no access about the backend, also if I asked Para to get access to it.
I believe he code in Python, to query the database about Categories and Subcategories.
So I believe the subcategories are perhaps the performance killer and someone should replace these part of code by using CatGraph or something eise.
Sorry that I'm also very busy in the moment. So perhaps somebody else can help. Perhaps @dschwen has an idea.
May 18 2015
May 11 2015
Mar 19 2015
The idea was to merge Wikiminiatlas and OSM-Gadget to a commons tool that is powered by Leaflet or OpenLayers3.
Now it seems both developers (me and DSchwen) have other things to do. So some support for an update would be nice.
Tiles in WikiminiAtlas have a different projection.
Mar 4 2015
Mar 3 2015
I think as big solution we should use OpenStreetMap-Software stack (editor, Database, Rendering and APIs) for our own data. The rules we can change than. A lot of objects like "Interstate5" are already in OpenstreetMap and we have with the project WIWOSM over 400.000 links between these objects and Wikidata. The own OSM-Software should be only for objects that are out of scope from the OpenStreetMap (OSM) project, like fuzzy objects e.g. bird habitats. For historical objects that also out of scope from OSM we are in contact with openhistoricalmap project.