Re: [OSM-dev] Tile Fonts
On Tue, Sep 8, 2009 at 2:45 PM, Richard Ive wrote: > > > 2009/9/8 Richard Ive >> >> Sorry. I've found the solution: >> >> >> http://wiki.openstreetmap.org/wiki/Mapnik#Optional:_CJK_font_fallback_support >> >> 2009/9/8 Richard Ive >>> >>> Excuse me for being a noob. >>> >>> I'm using mod_tile, and when I start the renderd daemon it say: >>> >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerif-BoldItalic.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-Italic.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSans-BoldOblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-Oblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSans-Oblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansMono.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-BoldOblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-Bold.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-Bold.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansMono-Oblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerif-Italic.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSans-Bold.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/unifont-5.1.20080907.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-BoldItalic.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerif.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansMono-Bold.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSans-ExtraLight.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSansMono-BoldOblique.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSans.ttf >>> renderd[5748]: DEBUG: Loading font: >>> /usr/local/lib/mapnik/fonts/DejaVuSerif-Bold.ttf >>> >>> (I've highlighted the line to show you i've add the unifont) >>> >>> However, it's still playing up. Should I do anything else, other than >>> gunzip the ttf file to /usr/local/lib/mapnik/fonts/ ? >>> >>> >>> 2009/9/7 Stephan Knauss Richard Ive wrote: > Do you think it is the fonts, or a language issue? 100% the font. Install the unifont. For Tilesathome there was a discussion to use SVG-Fonts. For me this sounds like a good idea as with distributed rendering it would guarantee all using the same font. Your rendering looks like mapnik, so just having a font with the glyphs is all you need, could be any you like. Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev >>> >>> >>> >>> -- >>> Regards, >>> Richard Ive. >> >> >> >> -- >> Regards, >> Richard Ive. > > > > -- > Regards, > Richard Ive. > > ___ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > > To get i18n rendering going you need to: 1. Install unifont and have renderd load it (as you appear to have done) 2. Use osm-template-fontset.xml or another mapnik stylesheet that actually uses the fonts. Once you've done that things should work. However if you rendered any tiles /before/ doing this the old tiles may still be left over so you won't see the fonts being used if you're looking at the same areas again. Have you experied (rm -rf'd) your old tiles? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Hi 2009/9/8 Frederik Ramm > Your idea suffers from the fundamental problem that it only counts those > having last touched an object. No, it doesn't. I thought of a mechanism to avoid that: >Users adding ways/pois get a score of 3 per way/poi added, >users adding more tags to existing way/pois get a score-point of 1 for each edit. >Import sources get a 0.1 score-point per way/poi. One could also think of more sophisticated factors to calculate score-points. - initial creation: 3 score-point factor - adding name: 2 - adding other tag: 1 - import sources: 0.1 - mass changes: 0.1 / change - bots: 0 What about a limit for score-point gaining per hour/day for a user? * Of course, the score-point factors are subject to fine-tuning! They must be adjusted, when one creates such a solution. Regards Micha ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Richard Ive wrote: > Is it easy to run a cron that downloads the daily diff which you can > then run an: > ./osm2pgsql -a -m -d gis ../planet-date.osm.gz on? (I'd assume you add > the -a to add the data, rather than clear the db) my setup uses osmosis to read the diffs and pipe the results to osm2pgsql. Mind to use the slim mode on initial import to support updates. Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql slim mode, postgis, and hard disk spindles
Richard Weait wrote: > Jaunty, osm2pgsql from svn, > p4, 3.4GHz > single 150GB hard drive > 50 hours. Wow, 50 hours to apply the changes from a day. I would be interested in having a wiki page to compare the typical runtime. It would help a lot to determine what performance to expect from a machine and to compare the own setup, so discover misconfiguration better. In case we could get some comparable results I would set up a wiki page. Here my measurements again. I did run an incremental update: *** Old mapnik db timestamp 2009-09-07T07:00:00Z *** Start update 08:37 INFO: Osmosis Version 0.31.2 osm2pgsql SVN version 0.66-16423M Mid: pgsql, scale=100, cache=3800MB, maxblocks=486401*8192 Node stats: total(3264066), max(489240074) Way stats: total(106990), max(40421741) Relation stats: total(2780), max(233957) *** End update 15:52 *** New mapnik db timestamp 2009-09-08T06:00:00Z So that are 435 minutes. i7 920, 12GB, HW-Raid with high sequential speed I tried to tune the DB with these settings (others are default): effective_cache_size 8000MB random_page_cost 6.0 maintenance_work_mem 2000MB shared_buffers 2000MB temp_buffers 100MB work_mem 100MB max_fsm_pages 204800 fsync off wal_buffers 128kB checkpoint_segments 64 autovacuum off With databases that huge as ours I suspect the disk subsystem being the limiting factor. What would be a typical workload so to set up an iometer (www.iometer.org) bench to compare the results? Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Hi, Micha Ruh wrote: > Last night I dreamed about a solution to the cc-by-sa attribution > problem. It would be soo nice to have appropriate attribution displayed > in OpenLayer while browsing the map. Your idea suffers from the fundamental problem that it only counts those having last touched an object. The guy who went there on his bike and painstakingly recorded the geometry - zero points. The guy who later added an "is_in" tag - 100 points. We already have users who upload tens of thousands of objects completely unchanged just so that their name comes out on top (see http://www.openstreetmap.org/user/pfoten-weg/edits) - I don't want to encourage that by giving the last-editing user an even more prominent place. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 19:41, Graham Jones wrote: > This would work for a single 'main' server, but I like the idea of it > being distributed with lots of little ones (for example the computer in > my attic could serve Northern England, someone else could do Belgium > etc.). I don't know how to deal with re-directing the requests without > a central main server though...any ideas? That kind of distribution is, in my opinion, a terrible idea. Such a system will just never be reliable. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
I would like to look into a distributed version of XAPI - I agree with Tom that the current XAPI server is not ideal (but this may be because I can't work out how it works). I envisage an XAPI server utilising a 'standard' PostgreSQL database produced by osmosis, kept up to date by the daily/hourly diffs etc, along with a simple web server front-end to do the XAPI to SQL translation. I made a start coding a simply python based server to do this, but haven't got very far (made the mistake of deciding not to write my own parser but use a parser generator - terrible mistake!). Maybe I should give up and write it in C - I'm sure the production version will be in C for speed anyway This would work for a single 'main' server, but I like the idea of it being distributed with lots of little ones (for example the computer in my attic could serve Northern England, someone else could do Belgium etc.). I don't know how to deal with re-directing the requests without a central main server though...any ideas? Having a nice fast XAPI system would make more dynamic maps (e.g. a vector layer of POIs obtained from XAPI over a static mapnik background) a bit more usable - all of the examples I have seen so far are a bit sluggish. Graham 2009/9/8 Tom Hughes > On 08/09/09 08:02, Patrick Petschge Kilian wrote: > > > The first one would be a (decently fast) OSMXAPI server. Since the 0.6 > API > > switch there seems to be a shortage of XAPI servers. If there was a > > stable, fast and up to date XAPI server it would help lots of people and > > it might reduce load on the main API. > > We've already given XAPI a server, and before we give it any more > hardware I would need some serious convincing that XAPI as it currently > exists is actually workable and scalable in some sensible way because as > far as I can tell at the moment it isn't. > > As I understand it the database takes so long to load that if there are > any working servers they are way out of date, and even when a server is > working it can only serve a couple of users at a time which, when a XAPI > query can often take minutes or hours to run is clearly not practical > for serving a large community. > > There are also issues with the run time that the code uses - it's > horrible ancient and crufty and requires various kernel security > features to be turned off. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://www.compton.nu/ > > ___ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > -- Dr. Graham Jones Hartlepool, UK email: grahamjones...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tile Fonts
2009/9/8 Richard Ive > Sorry. I've found the solution: > > > http://wiki.openstreetmap.org/wiki/Mapnik#Optional:_CJK_font_fallback_support > > 2009/9/8 Richard Ive > > Excuse me for being a noob. >> >> I'm using mod_tile, and when I start the renderd daemon it say: >> >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerif-BoldItalic.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-Italic.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSans-BoldOblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-Oblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSans-Oblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansMono.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-BoldOblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansCondensed-Bold.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-Bold.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansMono-Oblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerif-Italic.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSans-Bold.ttf >> *renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/unifont-5.1.20080907.ttf* >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerifCondensed-BoldItalic.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerif.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansMono-Bold.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSans-ExtraLight.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSansMono-BoldOblique.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSans.ttf >> renderd[5748]: DEBUG: Loading font: >> /usr/local/lib/mapnik/fonts/DejaVuSerif-Bold.ttf >> >> (I've highlighted the line to show you i've add the unifont) >> >> However, it's still playing up. Should I do anything else, other than >> gunzip the ttf file to /usr/local/lib/mapnik/fonts/ ? >> >> >> 2009/9/7 Stephan Knauss >> >> Richard Ive wrote: >>> > Do you think it is the fonts, or a language issue? >>> >>> 100% the font. Install the unifont. >>> >>> For Tilesathome there was a discussion to use SVG-Fonts. For me this >>> sounds like a good idea as with distributed rendering it would guarantee >>> all using the same font. >>> >>> Your rendering looks like mapnik, so just having a font with the glyphs >>> is all you need, could be any you like. >>> >>> Stephan >>> >>> ___ >>> dev mailing list >>> dev@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/dev >>> >> >> >> >> -- >> Regards, >> Richard Ive. >> > > > > -- > Regards, > Richard Ive. > -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feed reader stupidities with our Atom feeds
On Mon, 7 Sep 2009 15:35:26 + Ævar Arnfjörð Bjarmason wrote: > I use Liferea as my feed reader and I discovered that when I double > click on a feed link I get the osmChange XML. > > This is because Liferea is using one variable internally to keep track > of the href for each feed entry. When confronted with multiple > elements will overwrite this variable each time it sees a new > one. So it always ends up using the last . > > Here's a snip from one of our feeds for reference: > > href="http://www.openstreetmap.org/browse/changeset/2395774"; > rel="alternate"/> > href="http://www.openstreetmap.org/api/0.6/changeset/2395774"; > type="application/osm+xml" rel="alternate"/> href="http://www.openstreetmap.org/api/0.6/changeset/2395774/download"; > type="application/osmChange+xml" rel="alternate"/> > I think that might have been the markup I gave you when you put them together. > I thought I'd move the the text/html link to the end to work around > this. But that might trip up some other feed readers which implement a > different flavor of stupid. > Feed readers (when I last tested for them a few years back) implement all kinds of flavours of stupid. They make web browser testing seem like a birthday present. This sounds like a bug to be logged with the Liferea project. All you can really do for feeds (as with web IMHO) is throw up your hands and say "sod it, I'm following the standard". Which you've done. Still your workaround is probably harmless, as you are asking us to test for you. Ahem … > So can you (yes you!) please test our feeds in your favorite feed > reader and see how this (and other things) work or don't work and > reply to this mail with the results. > I use Liferea too (only because Akregator keeps crashing), but I'll check on Feedreader for Windows tomorrow @ work. The other biggie is maybe Google Reader. I can't do that for you, but thousands can. :~) > Here's an example feed to play with: > http://www.openstreetmap.org/user/%C3%86var%20Arnfj%C3%B6r%C3%B0%20Bjarmason/edits/feed > Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Iván Sánchez Ortega wrote: > Supposing that we get the rack space, what kind of machine and services would > you like us to host here? Just a mapnik renderer to balance load and improve > tile serving uptime? I'd suggest: * A localised front page * Cacheing proxy of the main Mapnik render * A localised render -- Jonathan (Jonobennett) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 Iván Sánchez Ortega : > El Martes, 8 de Septiembre de 2009, John Smith escribió: >> Maybe the embedded stuff needs to be on it's own hostname instead of >> www so that the basic html and js can be duplicated across multiple >> sites that also host tile servers etc. > > DNS load balancing should be able to take care of that. Exactly, but the embedded stuff is only a couple of files so the entire website wouldn't need to be duplicated. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
El Martes, 8 de Septiembre de 2009, John Smith escribió: > Maybe the embedded stuff needs to be on it's own hostname instead of > www so that the basic html and js can be duplicated across multiple > sites that also host tile servers etc. DNS load balancing should be able to take care of that. -- -- Iván Sánchez Ortega Aviso: Este e-mail es confidencial y no debería ser usado por nadie que no sea el destinatario original. No se permite la reproducción mediante fotocopia, walkie-talkie, emisora de radioaficionado, satélite, televisión por cable, proyector, señales de humo, código morse, braille, lenguaje de signos, taquigrafía o cualquier otro medio. Bajo ningún concepto debe traducirse al francés este e-mail. Este e-mail no puede ser ridiculizado, parodiado, juzgado en una competición, o leído en voz alta con un acento gracioso llevando un bigote falso y/o cualquier tipo de sombrero, incluyendo pero no limitándose a pañuelos. No inciten ni provoquen a este e-mail. Si está medicándose, puede experimentar nauseas, desorientación, histeria, vómitos, pérdida temporal de la memoria a corto plazo y malestar general al leer este e-mail. Consulte a su médico o farmacéutico antes de leer este e-mail. Todas las modelos descritas en este e-mail son mayores de 18 años. Si ha recibido este e-mail por error es probablemente porque estaba borracho cuando escribí la dirección del destinatario. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 Thomas Wood : > 2009/9/8 John Smith : >> Hosting OpenLayers.js and some kind of web page would be useful as >> well so people with simple web pages could embed a map in an iframe. > > * osm.org > * Export tab > * Select Embeddable Html Maybe the embedded stuff needs to be on it's own hostname instead of www so that the basic html and js can be duplicated across multiple sites that also host tile servers etc. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 Iván Sánchez Ortega : > Have you actually had a look at the export tab? This whole topic is about servers, and if the map server goes down that embedded option is of no use. I should have been clearer in my previous email. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
El Martes, 8 de Septiembre de 2009, John Smith escribió: > I'm not suggesting a limited subset of OSM as a static image. It would > be nice if there was a full dynamic embedable iframe option. Have you actually had a look at the export tab? -- -- Iván Sánchez Ortega Aviso: Este e-mail es confidencial y no debería ser usado por nadie que no sea el destinatario original. No se permite la reproducción mediante fotocopia, walkie-talkie, emisora de radioaficionado, satélite, televisión por cable, proyector, señales de humo, código morse, braille, lenguaje de signos, taquigrafía o cualquier otro medio. Bajo ningún concepto debe traducirse al francés este e-mail. Este e-mail no puede ser ridiculizado, parodiado, juzgado en una competición, o leído en voz alta con un acento gracioso llevando un bigote falso y/o cualquier tipo de sombrero, incluyendo pero no limitándose a pañuelos. No inciten ni provoquen a este e-mail. Si está medicándose, puede experimentar nauseas, desorientación, histeria, vómitos, pérdida temporal de la memoria a corto plazo y malestar general al leer este e-mail. Consulte a su médico o farmacéutico antes de leer este e-mail. Todas las modelos descritas en este e-mail son mayores de 18 años. Si ha recibido este e-mail por error es probablemente porque estaba borracho cuando escribí la dirección del destinatario. <>___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 John Smith : > 2009/9/8 Thomas Wood : >> 2009/9/8 John Smith : >>> Hosting OpenLayers.js and some kind of web page would be useful as >>> well so people with simple web pages could embed a map in an iframe. >> >> * osm.org >> * Export tab >> * Select Embeddable Html > > I'm not suggesting a limited subset of OSM as a static image. It would > be nice if there was a full dynamic embedable iframe option. > Sorry, I meant the whole point of having distributed servers is to allow for greater uptime of this, using a static image is the only way to get that uptime at present. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 Thomas Wood : > 2009/9/8 John Smith : >> Hosting OpenLayers.js and some kind of web page would be useful as >> well so people with simple web pages could embed a map in an iframe. > > * osm.org > * Export tab > * Select Embeddable Html I'm not suggesting a limited subset of OSM as a static image. It would be nice if there was a full dynamic embedable iframe option. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 22/07/28164 20:59, Iván Sánchez Ortega wrote: > El Martes, 8 de Septiembre de 2009, Grant Slater escribió: >> We also get slightly more OSM operated hardware outside UCL soon. Any >> friendly large hosts out there that can offer us some well bandwidth >> fed hardware/rack space? Maybe a university in North America? > > The spanish local chapter *may* be able to get some rack space and connection > to a backbone, either free or dirty cheap. > > Supposing that we get the rack space, what kind of machine and services would > you like us to host here? Just a mapnik renderer to balance load and improve > tile serving uptime? My guess would be that providing a caching proxy for mapnik tiles and potentially the wiki would be the easiest for some external hosting. It would help quite a bit with bandwidth (and hopefully also with uptime) as the mediawiki proxy test showed and should be comparatively moderate on server hardware and admin time. Setting up a global mapnik render server would need alot more server power and might not be worth it unless you want to offer localised or alternative rendering styles. Kai > ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Am 08.09.2009 um 12:38 schrieb Iván Sánchez Ortega : > El Martes, 8 de Septiembre de 2009, Grant Slater escribió: >> We also get slightly more OSM operated hardware outside UCL soon. Any >> friendly large hosts out there that can offer us some well bandwidth >> fed hardware/rack space? Maybe a university in North America? > > The spanish local chapter *may* be able to get some rack space and > connection > to a backbone, either free or dirty cheap. > > Supposing that we get the rack space, what kind of machine and > services would > you like us to host here? Just a mapnik renderer to balance load and > improve > tile serving uptime? We also have an offer for a server including traffic and hardware from a german ISP for a few month now. Grant also knows already about this for a while. Jonas > > -- > -- > Iván Sánchez Ortega > > http://ivan.sanchezortega.es > Proudly running Debian Linux with 2.6.30-1-amd64 kernel, KDE 3.5.10, > and PHP > 5.2.10-2.2 generating this signature. > Uptime: 12:32:40 up 2 days, 19:42, 4 users, load average: 1.22, > 0.92, 0.90 > > ___ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 John Smith : > Hosting OpenLayers.js and some kind of web page would be useful as > well so people with simple web pages could embed a map in an iframe. * osm.org * Export tab * Select Embeddable Html -- Regards, Thomas Wood (Edgemaster) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
El Martes, 8 de Septiembre de 2009, Micha Ruh escribió: [...] > A server calculates user contribution for sets of 3x3 tiles (supertiles) > for each zoom level 12-18. Meh. Precalculating all that would be too time-consuming. I'd rather go 8x8 mod_tile-like meta-tiles and a real-time API for z>12, with a cache on top. Heck, you could even do just z12 tiles and get away with that. > The calculation is done once a week (maybe done by t...@h clients). Meh. Mark the cache as dirty every week. And if mod_tile+mapnik can render stuff in near-real-time, there is no reason you could not just count stuff in near-real-time. Heck, mod_tile has to load data for 8x8 meta-tiles every time a meta-tile is marked dirty. Use that opportunity to count the attribution data there: just add a couple of fields to osm2pgsql and make mod_tile count the attribution data. > Users adding ways/pois get a score of 3 per way/poi > added, users adding more tags to existing way/pois get a score-point of 1 > for each edit. Import sources get a 0.1 score-point per way/poi. Good luck telling those apart, given a planet dump. Why not just 1 node/way/relation = 1 point?? > OpenLayer gets extended in a way that while requesting tiles an additional > request to the attribution-db is issued, contributors for the corresponding > supertile get loaded and nicely presented in the lower right corner of the > view. No need to. A bit of javascript magic can do that. Cheers, -- -- Iván Sánchez Ortega http://ivan.sanchezortega.es Proudly running Debian Linux with 2.6.30-1-amd64 kernel, KDE 3.5.10, and PHP 5.2.10-2.2 generating this signature. Uptime: 12:39:41 up 2 days, 19:49, 4 users, load average: 0.95, 0.96, 0.92 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
2009/9/8 Iván Sánchez Ortega : > Supposing that we get the rack space, what kind of machine and services would > you like us to host here? Just a mapnik renderer to balance load and improve > tile serving uptime? Hosting OpenLayers.js and some kind of web page would be useful as well so people with simple web pages could embed a map in an iframe. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
El Martes, 8 de Septiembre de 2009, Grant Slater escribió: > We also get slightly more OSM operated hardware outside UCL soon. Any > friendly large hosts out there that can offer us some well bandwidth > fed hardware/rack space? Maybe a university in North America? The spanish local chapter *may* be able to get some rack space and connection to a backbone, either free or dirty cheap. Supposing that we get the rack space, what kind of machine and services would you like us to host here? Just a mapnik renderer to balance load and improve tile serving uptime? -- -- Iván Sánchez Ortega http://ivan.sanchezortega.es Proudly running Debian Linux with 2.6.30-1-amd64 kernel, KDE 3.5.10, and PHP 5.2.10-2.2 generating this signature. Uptime: 12:32:40 up 2 days, 19:42, 4 users, load average: 1.22, 0.92, 0.90 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Keeping .osm database up-to-date
Having got mod_tile working nicely (Thanks everyone for their help!) I was wondering what the best method of keeping the database up-to-date using osm2pgsql is. Is it easy to run a cron that downloads the daily diff which you can then run an: ./osm2pgsql -a -m -d gis ../planet-date.osm.gz on? (I'd assume you add the -a to add the data, rather than clear the db) -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 08:02, Patrick Petschge Kilian wrote: > The first one would be a (decently fast) OSMXAPI server. Since the 0.6 API > switch there seems to be a shortage of XAPI servers. If there was a > stable, fast and up to date XAPI server it would help lots of people and > it might reduce load on the main API. We've already given XAPI a server, and before we give it any more hardware I would need some serious convincing that XAPI as it currently exists is actually workable and scalable in some sensible way because as far as I can tell at the moment it isn't. As I understand it the database takes so long to load that if there are any working servers they are way out of date, and even when a server is working it can only serve a couple of users at a time which, when a XAPI query can often take minutes or hours to run is clearly not practical for serving a large community. There are also issues with the run time that the code uses - it's horrible ancient and crufty and requires various kernel security features to be turned off. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 08:21, Florian Lohoff wrote: > Sometimes i'd like to actively contact mappers in that distant region and > mostly i dont care what they are called - simply - send email to top most > recently active mappers in that region. This has been discussed a number of times - it's not something that needs any new hardware though. The problems with it are all about software and about the risk of it being abused. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On Tue, Sep 08, 2009 at 05:47:04AM +0200, Micha Ruh wrote: > Score-points get calculated per supertile, top 4 contributors for each > supertile including their score-points get stored in a database, the > attribution-db. Keys and indexes on zoom level and new supertile index > (maybe central tile x/y). > > OpenLayer gets extended in a way that while requesting tiles an additional > request to the attribution-db is issued, contributors for the corresponding > supertile get loaded and nicely presented in the lower right corner of the > view. > > OSM runs the attribution-db and spreads the extended OpenLayer lib. Sometimes i'd like to actively contact mappers in that distant region and mostly i dont care what they are called - simply - send email to top most recently active mappers in that region. Flo -- Florian Lohoff f...@rfc822.org "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Hi all, > We have recently had: db (smaug new) (1), rails (sarel, norbert & draco. > extra cpu) (2), tile (yevaud new), dev (errol new), xapi > (fafnir. 2x300GB 10kRPM WD Raptor) (2), pg_namefinder (katie. 2x300GB > 10kRPM WD Raptor) (2, 5), OSMF (Ridley. 2x750GB WD) (2) and soon wiki (?. > HPDL360G4P,2xDualCPU2.8Ghz4MB,12GB,2x73GB 10kRPM, OOB iLO). (3) > > After all of that First of all: Thanks you (and all the other) for the work you put into it to make the current setup work. > What is next? What are we going to need next? Faster Web Frontend? Better > Load-Balancing (with fuchur) (4), Faster api/map call?, > something complete different something new? Two ideas come to my mind: (ok, actually three) The first one would be a (decently fast) OSMXAPI server. Since the 0.6 API switch there seems to be a shortage of XAPI servers. If there was a stable, fast and up to date XAPI server it would help lots of people and it might reduce load on the main API. The second one would be another tile server (say b.tile.. and d.tile...) located network topologically far away. That should provide faster loading time for many users and would be the first step towards a redundant setup. Biggest problem is probably going to be hosting. The third one would be a faster namefinder / geocoder. But that is most likely not a server but a software issue. Perhaps one of the developers could speak up how far there efforts have gotten and what kind of server they would need. Patrick "Petschge" Kilian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
