I have a rendering problem that I am desparately trying to hunt down.
Please have a look at low zoom tiles (I use the (modified for b/w) original
osm stylesheet, the newest one, for mapnik 2.0). Of course I use mapnik2
Look at parts of Australia missing. I confirmed it has nothing to do
with recent remapping efforts in that area :-)
Zooming to Fiji at Z4: http://drangmeister.net/osm/wz4.png you see that
the islands are missing.
Zooming further in to Z10 they appear: http://drangmeister.net/osm/wz10.png
So it looks as if there's a vertical strip worth about 1 tile wide around
the 0° / 360° longitude that is not rendered, independent of the zoom. I.e.
at Z0 halve australia is missing, at Z4 only Fiji and NZ is missing, at
Z10 only maybe an island of Fiji is missing.
Here is the relevant part of the stylesheet for rendering:
<Layer name="world" status="on" srs="+proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null
If I rename shoreline_300.shp away then I cannot render anything due
to errors, so it's the correct file being used.
It also appears to be no problem of the database, because as with Fiji,
the data is there, just not being rendered in Z4.
Is there a "render bounding box" somewhere I don't know, maybe in tirex?
There's nothing suspicious in the /etc/tirex config files.
with the osm gadget working nicely in a number of Wikipedias, I was
wondering if it would make sense to add an "edit" link to it? A link
that would get you directly to the OpenStreetMap edit functionality for
the displayed area.
I would guess that quite a number of wikipedia users / editors will not
have heard of OpenStreetMap before and are thus not aware that you can
edit and improve the maps just like one can improve the articles.
Adding an edit link to the osm gadget would potentially increase this
awareness and therefore might help improve the quality of the maps
included in Wikipedia. Especially if wikipedia editors would use the
functionality, the maps would be improved in a way relevant to the
articles. For example add missing footpaths leading up to the monument
described in an article, or add the names in different languages.
Therefore this would hopefully be a win both for Wikipedia and for
There are however possibly a couple of down sides as well. For one, it
might be confusing to wikipedians that you need a separate OpenStreetMap
user account in order to edit the maps, as the Wikipedia account will
obviously not do. Secondly, a lot of the embedded maps are by default
zoomed out so far (e.g. city level) that it is not feasible to edit at
that zoom level. The edit link would therefore have to be restricted to
higher zoom levels. Thirdly, one would have to make sure people are
aware that they are not only editing the map for this one article, but
editing a world wide map database used for many purposes. I.e. make sure
people don't for example delete some points of interest, because they
think it makes the rendering in this article cluttered or
in-appropriate, or add labels for non existent objects to make them show
up on the map for the article.
So the question is, what do others think? Would this be a good idea
overall? How would an edit link best be presented in the osm gadget? Any
other thoughts on this topic?
my name is Klaus Bechtold from Berlin, the guy behind the hobby project
and one-man-show GPSies.com (http://www.gpsies.com/). As you know, many
of the map mashups or community must change from Google Maps to
alternatives (because we're over the limit of 25.000 API calls a day).
I just changed to the new JS API from Cloudmade, called Leaflet and I am
using the free MapQuest maps (which are good, but not good enough for
outdoor people). I'm also using also some other maps, like OpenCycleMaps
or the great hikebike maps of Colin Marquardt.
Next time I'm planning to produce own tiles for GPSies.com. The (3 new)
servers are running and we must now configure it, but this will take
Now to my question. I just called Colin (hikebikemap.org) and I asked
him, if GPSies.com (only the website, no mobile devices) could deliver
the tiles by a caching proxy of hikebikemap.org - as the new standard
maps of GPSies.com. Colin said, he had no problem with it, but I should
ask you, if it would be ok for the load and traffic of the toolserver
GPSies has about 30.000 (winter) to 100.000 (sommer) page views with
maps a day. Most of the users are from Germany (50%). Most of the tracks
are from almost the same regions.
I'd be appreciate, if you would allow my the tiles caching of your
server. I also like to donate.
Best regards from Berlin, Germany
I want to use the beginning of the new year to collect our projects and
project ideas to get an overview to the priorities for 2012.
So please take a look to the new page:
Please add your name as supporter for projects you want really like to
see. You can also add your own project ideas.
like already announced after the last maintenance, the next maintenance will
Wednesday, 7 December between 19:00 and 1:00 UTC.
The roots will collect what they will do at  until Sunday night. If you
have something for us to do (like a software-update) please open a bugreport
at JIRA and make sure to add the label "maintaince-window" until Sunday noon.
The roots plan to finish the configuration of Apache until Wednesday too, but
there will be no switch yet to give you all some time for testing (I will send
a eMail with more details when the time is right).
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello, for the russian map we have the OK from an ru.wp-admin so we can
I did try to activate the russian style for all zoomlevels but missing
tiles didn't go to the "missing"-queue of tirex. So I reset the change.
Am 03.01.2012 13:39, schrieb Kai Krueger:
> On 01/02/2012 01:57 PM, Tim Alder wrote:
>> People from ru.wp ask me to support russian but I did affraid that it
>> will be too much load for us. But now is russian map so popular that
>> it is perhaps usefull, we should use pre-rendering for it.
> We should probably test it to see how it goes.
> Who would be the people on the russian wikipedia to talk to, to see what
> they need? Also, should any changes take effect, who can tel us if
> everything is working out and if the changes are positively received?
>> |Kay: Please excuse my ignorance, but what is "default"? Is it the same as
>> Greetings Kolossos
>> Zitat von Kai Krueger<kakrueger(a)gmail.com>:
>>> Hello everyone,
>>> Over the past month, the server has been busy trying to re-render all of
>>> the tiles to try to ensure more up-to date maps. This process is more or
>>> less complete now and all of the map tiles should then be at least from
>>> the 1st of December 2011.
>>> As one month old tiles is still not overly satisfying, I am now trying
>>> to re-activate diff based tile expiry again.
>>> The full expiry of all styles remains infeasible for the moment and so I
>>> am trying to introduce expiry slowly to see how far it can be pushed.
>>> As a start, I have activated tile expiry only for the highest zoom
>>> levels (z15 - z18) and then only for the styles that currently are
>>> embedded in one of the wikipedias.
>>> As far as I can tell these are the following styles:
>>> osm-no-labels osm-labels-de osm-labels-ca osm-labels-bg osm-labels-da
>>> osm-labels-el osm-labels-es osm-labels-fa osm-labels-fr osm-labels-it
>>> osm-labels-lv osm-labels-nl osm-labels-no osm-labels-pl osm-labels-ru
>>> germany default hikebike
>>> If anyone knows of a language that I have forgotten, please let me know
>>> and I will include it as well.
>>> So far, it looks like the server can cope with this, although I have
>>> only activated it earlier today. Should it remain this way, I will try
>>> and expand the zoom levels.
>>> As it is critical to reduce the number of low zoom tiles rendered, as
>>> those still kill performance, lower zoom tiles will probably not be
>>> expired as frequently. E.g. perhaps Z14 - Z11 on a daily basis, below
>>> that even only in the background.
>>> We will have to see, though, how performance behaves over time.
>>> Happy new year,
>>> Maps-l mailing list
>> Maps-l mailing list
I was wondering if there currently is something like a "tile usage
policy". I.e. a policy about who can use tiles served from the
toolserver and how many tiles they are allowed to request?
Other tileservers like the one at osm.org, have had problems with "tile
scrapers", usually smart phone applications that download large areas of
tiles systematically for later offline use. They have had to enforce
their policy either by throttling or outright banning applications and
users, as a few tile scrapers can quickly overwhelm the resources of a
So far I don't think this has been much of an issue on the toolserver
tileserver and there hasn't really been a need to enforce or limit
access yet. I did see some behaviour that looked suspiciously like large
scale tile scraping today though (systematic rendering of large number
of empty hikebike tiles at Z14) and so it might be good to have a policy
in place before it becomes an issue in the future.
OpenStreetMap's tile usage policy can be found at
http://wiki.openstreetmap.org/wiki/Tile_usage_policy for reference.