---------- Отправлено с моего телефона Nokia
------Исходное сообщение------ От: <[email protected]> Кому: <[email protected]>,<[email protected]> Дата: 16 Сентябрь 2011 г. 15:40:34 GMT+00:00 Тема: Maps-l Digest, Vol 29, Issue 4 Send Maps-l mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/maps-l or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Maps-l digest..." Today's Topics: 1. Re: Starting of re-rendering all tiles (Tim Alder) 2. Re: Starting of re-rendering all tiles (Stephan Knauss) 3. Re: Starting of re-rendering all tiles (Kai Krueger) 4. Re: Starting of re-rendering all tiles +Performance (Tim Alder) 5. Re: Starting of re-rendering all tiles (Stephan Knauss) 6. Re: Starting of re-rendering all tiles (Julian Picht) 7. Re: Starting of re-rendering all tiles (Tim Alder) 8. Other OpenLayer maps (OpenSeaMap) (church.of.emacs.ml) 9. Re: Other OpenLayer maps (OpenSeaMap) (Tim Alder) 10. Possible tirex render queue bug? (Kay Drangmeister) ---------------------------------------------------------------------- Message: 1 Date: Sun, 11 Sep 2011 11:49:55 +0200 From: Tim Alder <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: Map integration <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Am 10.09.2011 01:44, schrieb Kay Drangmeister: > Hi Kolossos, > > http://munin.toolserver.org/OSM/ptolemy/tirex_status_queued_requests.html > > What is filling the "dirty" queue? The re-render should only > fill the "systema" queue, shouldn't it? Currently the "dirty" > queue is 11k entries. mod_tile is still running and filling the queue. I restarted tirex an hour ago and set prio of this dirty files to 99. I had the hope that it so ignored by tirex, but doesn't work. We are rendering now high density areas around amsterdam and running with many styles in timeouts at zoom-level 9 (x=264 y=160). I will think about to remove zoom-level 9 from my list. Other ideas? What's not good is that we have in the moment 70 seq. scans and 12 index scans. "vacuum full" was broken after 2.5 day. I hope somebody else could install the postgres_upgrade_fix. > > Next question, what is filling the bulk queue (4k entries)? :-) I don't know. > how is the age being calculated in the queues? I don't know. Is this important? Greetings Kolossos > > Kind regards, > Kay > > ------------------------------ Message: 2 Date: Sun, 11 Sep 2011 19:33:39 +0200 From: Stephan Knauss <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11.09.2011 11:49, Tim Alder wrote: > I hope somebody else could install the postgres_upgrade_fix. was there an upgrade? If so then I understand the wiki we need a re-import as the db can not be repaired. The script is to prevent damage. Stephan ------------------------------ Message: 3 Date: Mon, 12 Sep 2011 10:29:15 -0600 From: Kai Krueger <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: Map integration <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 9/11/11 3:49 AM, Tim Alder wrote: > > > What's not good is that we have in the moment 70 seq. scans and 12 index > scans. > > "vacuum full" was broken after 2.5 day. > I hope somebody else could install the postgres_upgrade_fix. That's not so good either. If I understood it correctly the postgres_upgrade_fix is only relevant if one updates postgresql. However, as far as I know, postgresql wasn't upgraded and it is still running 8.3. So I doubt this will fix anything. So the question is how do we fix the database corruption? Is it necessary to do a full reimport? In the mean time, until the corruption is fixed, can we turn off diff-imports. They are always erroring anyway and are adding load to the db, that could probably better be spent on rendering. Kai ------------------------------ Message: 4 Date: Mon, 12 Sep 2011 23:22:19 +0200 From: Tim Alder <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles +Performance To: Map integration <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I stopped load-import. Tim Am 12.09.2011 18:29, schrieb Kai Krueger: > In the mean time, until the corruption is fixed, can we turn off > diff-imports. They are always erroring anyway and are adding load to the > db, that could probably better be spent on rendering. ------------------------------ Message: 5 Date: Mon, 12 Sep 2011 23:46:35 +0200 From: Stephan Knauss <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 12.09.2011 18:29, Kai Krueger wrote: >> I hope somebody else could install the postgres_upgrade_fix. > That's not so good either. > If I understood it correctly the postgres_upgrade_fix is only relevant > if one updates postgresql. However, as far as I know, postgresql wasn't > upgraded and it is still running 8.3. So I doubt this will fix anything. I had asked before. So if no upgrade happened this can't be the cause of the corruption. The script would also only prevent it from getting corrupted. If we don't have a backup then I sound like the db needs to be rebuild. BTW: PostgreSQL 9.1 was just released... and osm2pgsql main development branch no longer supports intarray. This migration also needed a re-import. Is this a hint that we should do a big upgrade? Could wait for the rendering to complete so we have some tiles still to deliver while the db rebuilds for a day or two. Stephan ------------------------------ Message: 6 Date: Mon, 12 Sep 2011 23:51:19 +0200 From: Julian Picht <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: Map integration <[email protected]> Message-ID: <camqqaj_9ankbv6eqmzxmmat2fqxbgd-z75hqspe5ehj1unm...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Couldn't we install the 9.1 and the new osm2pgsql in parallel, do a fresh import there and than switch over? Or isn't there enough disk space? Julian 2011/9/12 Stephan Knauss <[email protected]> > On 12.09.2011 18:29, Kai Krueger wrote: > >> I hope somebody else could install the postgres_upgrade_fix. > > That's not so good either. > > If I understood it correctly the postgres_upgrade_fix is only relevant > > if one updates postgresql. However, as far as I know, postgresql wasn't > > upgraded and it is still running 8.3. So I doubt this will fix anything. > I had asked before. So if no upgrade happened this can't be the cause of > the corruption. The script would also only prevent it from getting > corrupted. > If we don't have a backup then I sound like the db needs to be rebuild. > > BTW: PostgreSQL 9.1 was just released... > and osm2pgsql main development branch no longer supports intarray. This > migration also needed a re-import. > > Is this a hint that we should do a big upgrade? > Could wait for the rendering to complete so we have some tiles still to > deliver while the db rebuilds for a day or two. > > > Stephan > > _______________________________________________ > Maps-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/maps-l > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wikimedia.org/pipermail/maps-l/attachments/20110912/ab670649/attachment-0001.htm ------------------------------ Message: 7 Date: Tue, 13 Sep 2011 00:08:51 +0200 From: Tim Alder <[email protected]> Subject: Re: [Maps-l] Starting of re-rendering all tiles To: Map integration <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed If we keep only the four old tables we need for rendering we should have enough space for upgrade, but it would slow down the process. Would be nice if my db for wikipedia-POIs could run during the process. I big update would have also the benefit that we would have a fresh DB. I hear for different sides that the updating process over long time brings undefined rubbish in DB and increase the size. So I could live with an update. Greetings Kolossos Am 12.09.2011 23:51, schrieb Julian Picht: > Couldn't we install the 9.1 and the new osm2pgsql in parallel, do a > fresh import there and than switch over? Or isn't there enough disk space? > > Julian ------------------------------ Message: 8 Date: Thu, 15 Sep 2011 14:20:56 +0200 From: "church.of.emacs.ml" <[email protected]> Subject: [Maps-l] Other OpenLayer maps (OpenSeaMap) To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Hi, so, Wikipedia has had OpenStreetMap for some time now. What about other OpenLayer-based free maps? Specifically, OpenSeaMap? http://openseamap.org/index.php?id=openseamap&L=1 Regards, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://lists.wikimedia.org/pipermail/maps-l/attachments/20110915/6d1a74fe/attachment-0001.pgp ------------------------------ Message: 9 Date: Thu, 15 Sep 2011 19:39:35 +0200 From: Tim Alder <[email protected]> Subject: Re: [Maps-l] Other OpenLayer maps (OpenSeaMap) To: Map integration <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, for me is the question how many people read Wikipedia on a boat and would have a benefit from OpenSeaMap. I'm interested to keep the OSM-Integration in Wikipedia simple and useful also for new users. We support now standard-style (for general orientation and traveling by car) and hikebikemap (for walker and biker). I see a potential for a public transport and off course satellite images would be nice (if free available). I'm in contact with Markus from OpenSeaMap and would have no problem if OpenSeaMap would also provided our Wikipedia-POI Layer. Greetings Tim Am 15.09.2011 14:20, schrieb church.of.emacs.ml: > Hi, > > so, Wikipedia has had OpenStreetMap for some time now. What about other > OpenLayer-based free maps? > Specifically, OpenSeaMap? http://openseamap.org/index.php?id=openseamap&L=1 > > Regards, > Tobias > > > > > _______________________________________________ > Maps-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/maps-l ------------------------------ Message: 10 Date: Fri, 16 Sep 2011 17:40:40 +0200 From: "Kay Drangmeister" <[email protected]> Subject: [Maps-l] Possible tirex render queue bug? To: "Map integration" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Hi. I noticed that a lot has been done re-organizing the rendering queues on the toolserver. YAY! http://munin.toolserver.org/OSM/ptolemy/tirex_status_queued_requests.html looks now very colorful - mostly green (background). Thanks to everyone working on this. Many of the tiles I waited for have been rendered now. However - there seems to be some buggish behaviour: looking at http://toolserver.org/~mazder/tirex-status/?short=1&extended=0&refresh=0 it currently shows: Tirex Master Status (updated=2011-09-16 15:33:12) Master server: started=2011-09-11 06:28:53 pid=4623 Queue: Prio Size Maxsize Age 1 0 427 2 65 181 0:01-1:20 <- *** Size increasing *** 10 3025 3614 7742:24-7647:13 <- *** Size decreasing *** 99 50149 50149 1:26-7744:02 all 53239 53323 0:01-7744:02 Buckets: (load=3.75) Name Priority Rendering MaxRend Maxload Active Can Queued Age missing 1- 1 1 6 20 yes yes 0 systema 2- 2 4 5 8 yes no 65 0:01-1:20 dirty 3- 9 0 4 8 yes no 0 bulk 10- 19 0 6 6 yes yes 3025 7742:24-7647:13 background 20- 0 3 4 yes no 50149 1:26-7744:02 Currently rendering: (num=5) Map X Y Z Prio Age default 164568 85216 18 1 1 hikebike 33904 22840 16 2 6 hikebike 33912 22840 16 2 4 default 4224 2856 13 2 3 default 8448 5712 14 2 2 From what I see, queue systema (prio 2) is filled (65) and rendering. But when I refresh the page, I can see that the "bulk" queue Size is decreasing. So tirex must (realy?) be rendering Prio 10 tiles as well, but it's never showing in the "Currently rendering" table, there I can see only Prio 1 and 2 tiles. How is this possible? Kind regards, Kay ------------------------------ _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l End of Maps-l Digest, Vol 29, Issue 4 ************************************* _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l
