pieleric has commented on the following diary entries

Post When Comment
Cleaning up the streets. 7 months ago

Thanks for doing this clean-up! I am also a bit disturbed by these inconsistencies, and especially around Xi'an, but didn't how to deal with them "on the large scale".

@SomeoneElse, I wouldn't blame user in particular, as it's really a common mistake for beginners in countries with non Latin alphabet. Honestly, the rule/convention that only the local language(s) should be used is not highlighted in any guide I've seen. Especially, many tourist maps, including some based on OSM data do display both local and English name. So, even if the rule makes sense when you think of it, it's easy to mistake.

Motorcycle / Scooter support for Taiwan 8 months ago

I don't know about the mapping conventions for Taiwan, however at first thought, I'd suggest to use the moped tag instead. Historically this implies a little bit different type of motorbike, but I think the idea of this tag is to describe "motorcycles with limited power", which should fit well the scooters as they are used in Taiwan.

Unmapped tertiary roads 8 months ago

Hi, It's nice, I like to do some armchair mapping, but don't always where to start. It's a good motivation to know that someone might find it useful :-) I've just started to contribute, with a couple of roads :-)

Limites communales terminées over 3 years ago

Bravo! Bravo! :-)

Ajman Street names in Arabic over 3 years ago

You can do that, but that's not the advised way.

The official recommandations are there:

Basically, you put "name= " in the local language (not sure which country you're mapping, but I guess, it's arabic). You can repeat the same name as "name:ar=" (useful for programs only, to detect that the name= is in arabic), and the english version goes into "name:en=".

You're right that the default map on only display "name= ", but there are other maps which more clever and use the name:xx= tags. For instance, you can see the map in arabic only there:

Taguer des bornes de recharge pour véhicules électriques dans OSM (découverte du jour) over 3 years ago

Le problème de amenity=fuel, c'est qu'en général on s'attend à y trouver une pompe à essence. Alors pour bien faire il faut aussi mettre fuel:XXX=no (il y en a une bonne dizaines). En plus, je n'ai vu aucun programme qui sache faire la différence (et avec OsmAnd je me suis même retrouvé une fois devant une borne de chargement alors que je voulais faire le plein).

Conclusion, moi je préfère de loin la nouvelle manière: charging_station. Tant que sur le terrain c'est grosso-modo qu'une prise électrique, c'est aussi bien qu'on les tague différemment des stations services.

Where does this user get his data from? almost 4 years ago

Please report this to the Data Working Group. The easiest is to send them an email:

It indeed looks pretty suspicious. The fact that locations are spread all over the world is one thing (but there is Bing), adding names of streets is much more suspicious. Also, he has no GPS traces, and no changeset description.

That said, it might be actual survey data from someone who happen to travel a lot, so better be cautious. My own changes could look almost as suspicious if I didn't fill in the changeset description with the data source and upload GPS traces from time to time :-) It can be a hint to compare his changes to Bing imagery and see if they match (alignment + stop on the border of the imagery). Also, he might not speak English, and therefore just have no idea what your messages are about.

Just tried the new iD OSM Editor... about 4 years ago

Same thing here. With Firefox on Ubuntu 13.04 64 bits (dual core with 4Gb of RAM). JOSM is super smooth, potlatch works okayish, iD is dog slow keeping one CPU at 100% almost all the time :-(

Advanced rendering of tags about 4 years ago

@seav: My main advice is: "take it easy" :-)

Currently, all this has to be taken with a grain of salt. * Firstly, the rendering you're seeing has been coded by Christian, on his own initiative, and mostly for demonstration purpose. It's not the most clever rendering ever (yet), and doesn't set in stone the meaning of any tag. * Secondly, like most of the tags in OSM, the semantic of the leisure=pitch tag is not fully specified. The wiki page gives a pretty good rough idea, but what matters most is how contributers use it to map the reality to the OSM database. I'm sure currently you can find in OSM both interpretations of what a "pitch" represents: either the whole group of courts (easier to map), or just one court (easier to render, and more precise).

In my opinion, every contributor has his own right to pick the interpretation he likes most, at least until there is a consensus which emerges. So I think for now the most important rules are: try to stay consistent with yourself (decide how you want to tag things and try to stick to it for some time), and respect the work done by other contributors by not changing their tagging just to fit your interpretation.

Advanced rendering of tags about 4 years ago

I'm absolutely not involved in the project, but indeed it seems it's based on CartoCSS:

You can contact Christian Quest for more information :-)

The postman must hate Monteith Row over 4 years ago

There is a 179 between 77 and 83. Isn't this a typo? It looks like it should be 79 (it doesn't look like the ordering is that bad).

On implied turn restrictions and armchair mapping over 4 years ago

Hi NE2, It seems Paul Johnson has really carefully put (and put again) the turn restriction there, and pretty unlikely that the people who made this cross road ever envisioned the movement you've described as being acceptable. I agree with you that local knowledge always has priority, but the opposite side seems to have a point.

So I'd highly recommend you to not go onto the "edit war" path. Especially, it is not advisable to mention "vendalism" in your commits messages for such behavior: it's pretty obvious that Paul Johnson is not willfully damaging the map.

The best is that you continue discussing this case on the mailing list, where a discussion is already going on:

Coastline I edited is not being updated by the renderer over 4 years ago

It seems that, as Vlad described, the coastline has been updated, but because no data has been changed since the update, the tiles haven't been refreshed.

I've just forced the refresh at zoom 17, and the coastline is now correct. So apparently it's eventually going to appear fine, but will take time, unless you force a refresh at each zoom level.

Reversed Engineering of Data Model over 4 years ago

On the wiki they state that they follow IHO S-57, which can be fully downloaded there: In the appendices there is a list of all objects and attributes possible.

Isn't it enough information? Maybe you could explain exactly the type of information you're missing on


Building with two different names. How to solve over 4 years ago

I'd follow Vincent advice. The name of the building is the "Palazzo Pamphilji", which will always be this even if the owner changes (and maybe also a tag tourism=attraction as EdLoach suggested). Then you add a POI inside the building with the embassy amenity. If the Brazilian embassy decides to move, it'll be just a matter of moving the POI.

Wierd stuff with the rendering over 4 years ago

Sometimes the changes in the map are not detected by the renderer. You can force it by adding /dirty after the url of a tile. I've just done this, and I think it's now fixed for each zoom level (you still need to refresh the page in your browser).

Drawn my first road almost 5 years ago

Just a tips in addition to Sander's comments. In Potlatch you can connect two ways by doing the following: * click on the way you want to connect * drag the node at the end of the way on top of the other way * press "J" (like "join") * you should now see that the connection node is bigger than other nodes of this road.

BTW, you usually don't need to fill all the information on the street. If it's the "standard" value, you don't need to mention it. For instance, if it's allowed to go in both direction on the street, it's usual to not mention anything about "oneway". "oneway=no" is fine, but not necessary. Same goes for motor_vehicles, access, foot, maxspeed...

Have fun editing :-)

WOF#5. importing id's and refs from external databases. about 5 years ago

Hello, I agree with almost all your analysis. However for "externaldatabase:id", I'd be more prudent. In particular, there might be "databases" that can be complementary to OSM. We don't want to store everything in OSM, and they don't want to store everything related to location on earth. I have in mind the "wikipedia" tags, see


Mapping request of Norway's villages about 5 years ago

@Gnonthgol Could you explain more the problem, I'm not sure I'm following. You mean that the imagery is correctly aligned for the coastline, but for everything in altitude it becomes shifted (due to the view from the plane in "diagonal")?

For villages, which are in many cases situated at low altitude on relatively flat areas, shouldn't this distortion be small? Isn't having the streets and their intersections approximately situated better than nothing at all? Especially, with a couple of GPS traces, it should be possible to realign all the streets of a village?

Worst OSM Fixer about 5 years ago

Hello, Concerning the S/N roads. I believe "S/N" stands for "Sin Nombre" which is Spanish for "Without Name". So it's probably there to mean that in the import the name was unknown. I doubt it means it's a service road (and if you look on the imagery, many road called "S/N" are pretty big roads).