Mikel Maron | 22 Apr 14:34 2014

[OSM-dev] replication database advice


I'm helping someone out. We're looking to set up a geographically filtered replication from minutely or hourly planet diffs. The replicated, local read-only db will be used to field large area map API queries locally, and make extracts. Intention is to contribute changes back to OSM, so all relevant information needs to be maintained. 

Is there a guide or best practice to setting something like this up?
Looking at the osmosis documentation, and seems like a pipeline of --merge-replication-files  --bounding-box and --write-apidb-change tasks would do it. But wonder if this is the most efficient way. Note, only need the current state of features, not history, but don't see an option for that in osmosis (only populateCurrentTables flag, nothing to turn off history).

Also, on the local API side, don't really want to keep the whole rails app running. What are some of the alternative API servers out there?


* Mikel Maron * +14152835207 <at> mikel s:mikelmaron
dev mailing list
dev <at> openstreetmap.org
Jon Burgess | 18 Apr 18:50 2014

[OSM-dev] glitch in minutely replication stream

The minutely replication stream was blocked for 12 hours due to a server
problem. The broken sequence number was 834038, with 038.state.txt and
038.osc.gz being zero length files. When the replication was restarted
these files were replaced with real data.

Unfortunately this has caused a problem for using osmosis to fetch these
changes automatically. Once the replication resumed it appears that
osmosis skipped the changes in the new '038 files and downloaded '039

This affected the OSM rendering servers (Yevaud & Orm) and I have forced
them back to process everything from '037+ again to ensure the changes
in the 038 file are rendered. Anyone else running services using the
minutely diffs might need to do the same.

Giuseppe Ricci | 12 Apr 16:11 2014

[OSM-dev] More points on Leaflet map

Hi guys,

I'm new on OSM and, in particular, with Leaflet. I have some problem to create a map with more points/markers: I have an array (a matrix) where I have latitude, longitude and description. I have 50 points of interest to show on the map.
I use for 1 point this code:

<div id="map">
        #map { height: 500px; }
        <script type="text/javascript">
        var map = L.map('map').setView([<? echo $dati[1][5]; ?>, <? echo $dati[1][6];?>], 9);
//        var map = L.map('map').setView([40.784027, 17.238874], 15);
// 41.133333, 16.85

        L.tileLayer('http://{s}.tile.cloudmade.com/88ed710d6b7e41d2aad93a3cce1e10d3/997/256/{z}/{x}/{y}.png', {
            attribution: 'Map data &copy; <a href="http://openstreetmap.org">OpenStreetMap</a> contributors, <a href="http://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>, Imagery © <a href="http://cloudmade.com">CloudMade</a>',
            maxZoom: 18
        var marker = L.marker([<? echo $dati[1][5]; ?>, <? echo $dati[1][6]; ?>]).addTo(map);
 //       marker.bindPopup("<b><? echo $dati[1][2]; ?></b><br><? echo $dati[1][3]; ?>").openPopup();
        marker.bindPopup("<b><? echo $dati[1][2]; ?></b><br><? echo $dati[1][7]; ?>").openPopup();

as suggested in Leaflet Quick Start Guide. If I want to show 50 points (stored in $dati matrix), what code can I use?
I realized if the description to show in the popup is  long, Leaflet don't creates the map, how can I solve this problem?
I'm using PHP.
dev mailing list
dev <at> openstreetmap.org
Johannes Weskamm | 11 Apr 10:39 2014

[OSM-dev] Osm2pgsql - expire list incomplete / misses tiles


I have a problem with the results of the expire.list, which is generated 
by Osm2pgsql after importing a diff file from OSM.
The list contains not all tiles that need to be expired / refreshed. And 
it may be that it even contains wrong tiles.

The version i use:
Osm2pgsql 0.83.0 (64bit id space)

I use the load-next script to import the diff data. The script itself 
launches the import with the following command:

$OSM2PGSQL --append --slim --cache 1024 --merc --prefix $PREFIX --style 
$STYLE --host $HOST --database $DB --username $USER -e 0-19 -o 
expire.list --verbose "$CURRENT" 1>&2 2> "$PSQLLOG"

The imported data is correct and contains all updates that were given by 
the diff file.
The problem is, that the expire list does not contain some of the tiles 
that should be marked as expired, and i have no clue why.

It seems that the regions where updates happend in the database are hit, 
as there are a "few" expired tiles in the updated regions. But lots of 
tiles which should be expired are missing in the list.

Is there something wrong with the command (could "-e 0-19" be a 
problem?), or is this even a bug in osm2pgsql? Does somebody have / had 
similar issues?

Thanks in advance,

J. Weskamm
Simon Poole | 11 Apr 09:53 2014

Re: [OSM-dev] Heartbleed

Am 10.04.2014 23:42, schrieb Grant Slater:
> The probability is extremely low that any user data was compromised,
> but I would not discourage anyone from changing their password if they
> are concerned.

There are some indications (as was to be expected) that the
vulnerability was known well before the public announcement


dev mailing list
dev <at> openstreetmap.org
Andrew Hain | 10 Apr 21:53 2014

[OSM-dev] Heartbleed

What if anything has been the effect of the Heartbleed bug on the OSM family
of websites and what do people need to do in response?

Martin Koppenhoefer | 10 Apr 18:36 2014

Re: [OSM-dev] Nominatim geocoding for Japanese address

2014-04-10 17:06 GMT+02:00 Satoshi IIDA <nyampire <at> gmail.com>:
> Taginfo reports that there are more addr:block_number than addr:blocknumber
> but that might be unrelated.

"addr:blocknumber" is used in Japan, and
"addr:block_number" is used in Philippine.
(only here http://overpass-turbo.eu/s/32h)

"addr:block_number"(PH) is not documented & discussed & used in 2 month.
Hence, "addr:blocknumber"(JP) is a few used but be discussed a bit well. (from my view...)

It may, perhaps be possible to change "addr:blocknumber"(JP) to "addr:block_number"(PH) by telling Japanese mappers.
Your thought?

yes, I'd suggest that you discuss this and if you can reach consensus, change the docu to addr:block_number (if the usage is the same, you should ask the Philippine comunity about this). There are only ~200 addr:blocknumber but ~5000 addr:block_number currently in the database. Also blocknumber does not seem to be English, but block number seems to be (according to a google search).

If the usage / definition is not the same, you should still change the tag, because if 2 tags are so similar, it will create a lot of confusion.

dev mailing list
dev <at> openstreetmap.org
Rob Nickerson | 10 Apr 15:17 2014

[OSM-dev] Wiki - VisualEditor

There is an issue open for this in trac. There was a stopper at the time but now that's been resolved I would also like to see the plugin added (it is default on Wikipedia)



dev mailing list
dev <at> openstreetmap.org
amrit karmacharya | 10 Apr 10:34 2014

[OSM-dev] How to Get full object of older versions?

dev mailing list
dev <at> openstreetmap.org
Sarah Hoffmann | 9 Apr 20:23 2014

Re: [OSM-dev] Nominatim geocoding for Japanese address


On Wed, Apr 09, 2014 at 12:52:49AM +0900, Satoshi IIDA wrote:
> > Japanese address system
> I made Japanese address structure for OSM, last year.
> And got consensus between Japanese mappers. also reported in Tagging ML.
> https://lists.openstreetmap.org/pipermail/tagging/2013-September/014816.html

I rememeber this mail but obviously misunderstood that it is an
finished proposal. I also cannot find much data that follows the schema.
Taginfo reports that there are more addr:block_number than addr:blocknumber
but that might be unrelated.

> Documentation is written in Japanese, but certainly need more easy
> description.
> http://wiki.openstreetmap.org/wiki/JA:Key:addr#.E6.97.A5.E6.9C.AC.E3.81.AE.E4.BD.8F.E6.89.80.E8.A1.A8.E8.A8.98.E3.81.AB.E3.81.A4.E3.81.84.E3.81.A6
> Block structure detail (too complex, sorry)
> http://wiki.openstreetmap.org/wiki/JA:Addresses

It's easy enough to understand but it would be really helpful if
you could translate the page to English. I fear that the translation
with Google is not accurate enough.

> Problem is the absence of address data on Japanese area.
> As my early mail, most of admin boundary relation is broken.

Indeed, that makes it more difficult bu I believe that many
place nodes are already there and they are good enough to start with.

> But if we could do so detailed search on OSM, I'm very happy to encourage
> to collect address data on Japan :)

I don't think it will be difficult to implement this schema in Nominatim.
I would kindly suggest that you translate the wiki page, then, if you
have not done that yet, enter the data for one or two of these lower 
neighbourhoods into OSM and then again send a mail to tagging <at>  for 
discussion (and maybe open a trac ticket for Nominatim at the same
time, I do notmally not follow tagging <at> ). There are some details which
are not clear but it is probably easier to discuss on a concrete example.
Also, there are other parts in the world that use block-based addressing
and it would be great if the tagging can be used there as well.

Andreas Goss | 9 Apr 00:00 2014

[OSM-dev] Wiki - VisualEditor

Can we install the Visual Editor in the Wiki?

I think this would make editing a lot easier for everybody, especially 
new users who are unfamiliar with the formatting.


dev mailing list
dev <at> openstreetmap.org