OpenStreetMap logo OpenStreetMap

Pieren's Diary

Recent diary entries

Pour lier un numéro d’adresse avec sa rue, il existe deux modèles qui co-existent dans OSM: soit le nom de la rue est répété avec chaque adresse, qu’elle soit mise sur un noeud, un way fermé (souvent un “building”) ou une relation (par exemple une relation de type “site” ou “multipolygon”) en ajoutant le tag “addr:street” au tag “addr:housenumber”; soit on crée une relation de type “associatedStreet” et chaque élément portant un numéro (dans un noeud ou un way, plus rarement une autre relation) est ajouté dans la relation avec un role “house” et on associe la rue en ajoutant au moins un way de celle-ci avec le role “street”.

J’ai voulu voir s’il était possible de calculer l’usage de ces deux méthodes en France et de les comparer avec leur équivalent dans le monde entier uniquement avec l’outil taginfo. Les statistiques pour la France viennent du serveur taginfo.openstreetmap.fr alors que ceux pour le monde viennent du serveur taginfo.openstreetmap.org . Je ne connais pas les détails de l’installation sur osm.fr mais on peut penser que les données collectées débordent légèrement du cadre strict des frontières. On considérera cependant que les écarts que cela implique peuvent être faibles et négligés dans la petite étude suivante.

Il se trouve que l’outil taginfo construit ses statistiques d’usage différement entre tags sur éléments et “roles” sur relations. Il faut donc faire attention à bien distinguer les deux.

On commence avec taginfo France. Le tag “type=associatedStreet” s’y trouve ~48.000 fois sur des relations. Mais attention, une relation peut couvrir plusieurs adresses. Pour savoir ce que cela représente en nombre d’adresses individuelles, il faut aller sur la page comptant le nombre de roles “house”. On en décompte alors ~833.000 ce qui représente une moyenne de 17 adresses par relation, chiffre tout à fait plausible.

See full entry

I didn't know I worked for Mapbox

Posted by Pieren on 4 November 2013 in English.

Something I just noticed on an application using “Mapbox streets” map tiles. When you click on the “Terms & feedback” link, you fall down here: https://www.mapbox.com/about/maps/

And what I read is that “OpenStreetMap contributors create and improve our map data”. I find the “our data” “clumsy” for the best case or “dishonest” for the worst. When I contribute to OSM, I’m not improving the Mapbox map data, the “your” map data, displease you, Mapbox friends. I’m working for the OSM map data and you take advantage of it.

Please, check the current vote about a final tag for external and automated defibrillators. It’s here: osm.wiki/Proposed_features/automated_external_defibrillator#Voting_.282nd.29

Currently, we have 2 tags “medical=aed” and “emergency=aed” but the use of abbreviations and the move from “medical” to “emergency” has never been really approved by the community. Now you have the choice !

tourism=attraction

Posted by Pieren on 25 September 2013 in English.

In the (long) list of tags I don’t like, I should add the “tourism=attraction”. I find it sometimes on elements with just a name (a library in my case). It is just used to highlight something on the map when people are too lazy to search the right tag (amenity=library) -> “tourism=attraction” is a tag for the renderer and more important, is almost always subjective.

Fed up with abbreviations in tags

Posted by Pieren on 14 August 2013 in English.

English is not your native language ? but you like to contribute to OSM ? And you don’t know what means ‘asl’, ‘it’ or ‘ngo’ ? Your dictionnary doesn’t help you ? Who cares ! Return to Google Map Maker, moron !

That’s what I feel when I find OSM objects carrying such tags… And btw, all of such tags are always documented “as de facto” and never through a consensus process… Please think about the 75% of the world not using english as mother tongue.

addr:housenumber en France

Posted by Pieren on 26 April 2013 in French (Français).

Curieux. Quand on regarde les statistiques sur le tag “addr:housenumber” en France, on trouve ceci:
Numéro de maison || nombre d’exemplaires
3 || 45 282
4 || 44 402
2 || 44 222
1 || 44 086
5 || 42 374

(source : http://taginfo.openstreetmap.fr/keys/addr:housenumber#values)

Ca veut dire qu’en France, soit il y a moins d’adresses en no 1 et no 2, soit on ne les trouve pas. Ou alors, j’ai peut-être une autre explication : le cadastre omet souvent de mettre les numéros d’adresses à proximité des intersections, sans que je comprenne bien pourquoi. Mais ceci explique peut-être cela ;-)

Incidement, on constate que le nombre d’exemplaires baisse lorsque le numéro de maison augmente, ce qu’on peut comprendre puisqu’on cumule les grandes rues et les petites rues. Sauf. sauf, pour le numéro 10 qui passe devant le numéro 9:
10 || 34 118
9 || 33 818

C’est d’ailleurs une tendance qu’on constate aussi sur les statistiques mondiales: http://taginfo.openstreetmap.org/keys/addr:housenumber#values

Et là, je ne vois aucune explication rationnelle à ce mystère…

Michelin is not only the 2nd largest tyre manufacturer in the world. It is also a famous publisher of tourist guides and road maps.

This month, Michelin is releasing its first paper map based on OSM ! It is centered on Clermond-Ferrand city (Michelin’s headquarter) at a 1/12.000e scale.

Attribution and licence seem to be compliant: https://twitter.com/RatZillaS/status/314788399095631872/photo/1

You can see the price at some online shops. For instance, here: http://livre.fnac.com/a5152703/Collectif-Clermont-Ferrand

Récemment, un fil de discussion sur la liste talk-fr soulève une nouvelle fois la question de savoir si un certain type de données peut ou ne peut pas figurer dans OSM. En l’occurence ici, il s’agit des zones de risques sismiques tels que définis par l’administration (http://lists.openstreetmap.org/pipermail/talk-fr/2013-March/055764.html). Certains pensent que ce type d’information pourrait s’afficher avec des applications extérieures de type u{map}(http://umap.fluv.io/), sans pouvoir définir clairement sur quel critère on peut décider que telle ou telle information irait ou n’irait pas dans la base de données OSM.
Christian Quest se demande aussi pourquoi nous accepterions les AOC dans le vignoble et pas les zones sismiques. Son argument étant que l’information est utile et qu’il faut trouver un équilibre entre contributeurs et utilisateurs, le principal étant que cela soit “facile à intégrer et mettre à jour” pour les contributeurs et “facile à exploiter” pour les ré-utilisateurs (par là il veut sans doute dire un balisage clair, documenté et une modélisation simple).

See full entry

Currently French community members importing buildings into OSM are blocked by the DWG (Data Working Group) if they don’t use a separate user account. The problem is that the French community explaines since weeks to the DWG why this requirement, altough making sens for big mechanical import, does not make sens in this case because the imports are limited on small areas (villages), in numbers (between 1000 up to 10000 buildings in worst cases), in types of objects (only buildings) and damages (none if the user follows the import guideline) and more importantly, is crowdsourced, means that everyone is invited to participate to the import if they have a mimimum of experience in JOSM. The funny thing is that the imports are performed like this since years without problems. Until the DWG set-up its own tools detecting big changesets. Whatever is good or bad in the changesets, they request a separate user account, some rule established im a totally opaque way. In early days, when we got problems like users failing to upload or not following our guidelines, the French community was big enough to check, communicate and fix things himself. What is even more funny is how the dialog with the DWG members is:

– hey, DWG, we import buildings since years. Your request for a separate account is painful for a delta contributors who is maybe uploading just his village and next one into OSM (a second user account requires a second email address, you cannot use the same email as your first account)

– (DWG) : no, the rule is “use a separate account for imports”

– but we accept and use this rules for big imports or when it is completely mechanical. Here we ask people to verify on JOSM and integrate with the existing. Most of the time, it will improve the old data and improve the future contributions. Uploads are rarely isolated with 100% original data.

– (DWG) : no, the rule is “use a separate account for imports”

See full entry