OpenStreetMap

Pieren's diary

Recent diary entries

Relation "associatedStreet" ou tag "addr:street" sur chaque adresse ?

Posted by Pieren on 14 November 2013 in French (Français)

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.

Pour connaitre ensuite le nombre d'adresses qui ne sont pas identifiées par une relation, il suffit de chercher le nombre d'éléments utiliisant le tag "addr:street", soit ~760.000

Résumé du match en France : 833.000 adresses en relations "associatedStreet" contre 760.000 tagguées avec "addr:street".

Si on applique les mêmes requêtes dans taginfo pour le monde, on obtient les résultats suivants: 2.100.000 adresses en relations "associatedStreet" contre 23.090.000 tagguées avec "addr:street".

Conclusion :
- 40% des adresses tagguées avec la relation "associatedStreet" dans le monde le sont en France (833m/2100m).
- en France, on est à peu près à 50-50 entre les deux méthodes avec un léger avantage pour la relation.
- sur l'ensemble du monde, les relations "associatedStreet" ne représentent que 9% des adresses modélisées (2.1M/23M).

Biais : cette méthode a ses limites et ne tient pas compte de certains facteurs qui peuvent altérer les résultats. Par exemple, il arrive que certaines adresses soient tagguées avec les deux méthodes simultanément.

I didn't know I worked for Mapbox

Posted by Pieren on 4 November 2013 in English (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.

Artwork : only for tourists

Posted by Pieren on 18 October 2013 in English (English)

If you search 'artwork' in OSM, you find the tag "tourism=artwork". Which means that art is reserved for tourists in OSM ! Funny

Le "commisariat de poliz" à Nanterre

Posted by Pieren on 7 October 2013 in French (Français)

(à lire avec l'accent allemand) Ach, à Nanderre, ils zont un "Commisariat de Police de Nanterre": http://www.openstreetmap.org/browse/way/52625961

Ausweispapier bitte ! ^^

Give your opinion about the proposed tag "emergency=aed/defibrillator"

Posted by Pieren on 2 October 2013 in English (English)

Please, check the current vote about a final tag for external and automated defibrillators. It's here: http://wiki.openstreetmap.org/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 (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.

LOL : bus and bikes sharing a lane

Posted by Pieren on 24 September 2013 in English (English)

You have to know that in OSM, a way shared by bus and bikes is primarily a "cycleway":

http://wiki.openstreetmap.org/wiki/Template:Map_Features:cycleway

Buses are just tolerated there ^^ Who said that OSM is cyclists centric ?

.

Posted by Pieren on 24 September 2013 in English (English)

.

ASL

Posted by Pieren on 4 September 2013 in English (English)

No, no, no. Someone asked me if "ASL" is for "asshole", based on its pronunciation. No, it's not. It's neither for "Above See Level", nor for "American Signed Language". No, no, no. In the OSM community, "ASL" is for "Advanced Stop Line" and is only provided for cyclists.

Fed up with abbreviations in tags

Posted by Pieren on 14 August 2013 in English (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.

Railroad switch causing French train crash

Posted by Pieren on 15 July 2013 in English (English)

Do you know any other map that is able to show the exact railroad switch responsible of the train crash last week-end ?

http://www.openstreetmap.org/browse/node/1097986616

Seen here : https://twitter.com/cq94/status/355809199982247936

Location: Résidence de Cossigny, Brétigny-sur-Orge, Palaiseau, Essonne, Ile-de-France, Metropolitan France, 91220, France

Don't trust your car sat nav when it's not using OSM

Posted by Pieren on 10 July 2013 in English (English)

lol, an american tourist trusting his GPS sat nav instructions in Switzerland and falling in steps:

http://www.20min.ch/ro/news/suisse/story/Il-suit-son-GPS-et-s-engage-dans-des-escaliers-24926325

Btw, the steps are clearly indicated in OSM: http://www.openstreetmap.org/?way=134989608

What to do with general "notes" ?

Posted by Pieren on 30 April 2013 in English (English)

I discovered some new (anonymous) "notes" which are not very specific. Something like "addresses are missing here" or "add buildings please". What should we do with such "notes" ? is there any policy specifying how we can decide to close a "note" (which cannot be unclosed afterwards) ?

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 publishing a first paper map based on OSM !

Posted by Pieren on 21 March 2013 in English (English)

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

Qu'est ce qui peut aller dans OSM (ou pas)

Posted by Pieren on 5 March 2013 in French (Français)

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).

A mon avis, ça n'est pas tellement une question de "facile à" qui compte. Les limites de ce qui peut aller dans OSM (ou pas) sera un débat sans fin comme il l'est dans wikipedia. Mais contrairement à wikipedia où le seul risque est de faire exploser le nombre d'articles que personne ne lira, nous travaillons tous sur la "même feuille de papier" lorsqu'on contribue sur une zone géographique dans OSM. L'idée que plus il y aura de données et plus il faudra mettre en place des outils de filtrage pour faciliter le travail d'édition ne tient malheureusement pas. On voit que les données sont souvent interconnectées entre elles. On ne peut facilement toucher à un way sans affecter par exemple toutes les relations qui l'utilisent. Ou un noeud seul s'il faut partie d'un ou plusieurs ways. Il faudra sans doute chercher de nouveaux critères qui définissent la pertinence d'une contribution, au delà des "compatible ODbL", "le terrain", "le présent", "être stable" et "vérifiable".

Est-ce que l'un de ces critères sera le nombre de ré-utilisateurs ? Par exemple, quelques uns souhaiteraient ajouter leur itinéraire maison - lieu de travail pour, par exemple, chercher des opportunités de co-voiturage. Le nombre de ré-utilisateur par itinéraire est très faible (une personne). Il y a pourtant là un potentiel pour développer une application de recherche de co-voiture qui peut intéresser beaucoup de monde. Malgré cela, il y aura une forte rétissance de la communauté à voir fleurire un nombre de plus en plus important d'itinéraires maison-travail. D'abord parce que ça n'intéresse pas grand monde. Ensuite, parce que cela va affecter des données que tout le monde utilise (les routes qui seront découpées et rattachées à de multiples relations).

Un autre critère sera peut-être la densité des données. Au delà d'un certain seuil, il devient très difficile voir impossible de comprendre les données sur l'éditeur. S'il y a trop de lignes qui se croisent, l'impossibilité de tout afficher avec des couleurs diffèrentes, des polygones qui se superposent, se croisent ou ont des formes complexes avec des enclaves et/ou des exclaves, le cerveau humain n'est plus capable d'appréhender toutes ces données. On voit le phénomène apparaître dans les zones urbaines fortement cartographiées. On a déjà du mal avec le bâti et la voirie, les boutiques et les landuses. Qu'est-ce que cela deviendra avec les zones de couverture des caméras de surveillance, les réseaux souterrains d'eaux propres et eaux usées, les lignes téléphoniques, électriques et fibres optiques, les zones de couverture wifi ou 3G/4G, les bâtiments en 3D et leur cartographie intérieure, le détail de chaque voie de circulation, etc. Les milieux urbains seront alors tellement chargés qu'il ne sera plus possible de travailler qu'à très grande échelle, sur des zones de plus en plus petites qui ne dépasseront plus le paté de quelques maisons.

Comme on le voit, la question reste encore ouverte et nécessitera d'avantage de règles si on veut éviter une trop grande complexité dans le projet et une plus grande difficulté à recruter de nouveaux contributeurs si cela arrivait.

delete

Posted by Pieren on 5 March 2013 in French (Français)

delete plz

Voies sur berge à Paris

Posted by Pieren on 1 February 2013 in French (Français)

Est-ce que la fermeture d'une partie de la voie express rive gauche à Paris est correctement prise en compte dans OSM ?

Kids city map carpet

Posted by Pieren on 8 January 2013 in English (English)

Since dec 2012, a small French startup is selling a city map carpet for kids. Choose your area in OSM slippymap, 2 clics and the customized carpet will be produced just for you. Cost is 59€ + transport. Colours and zoom are optimized for kids playing with their toys. Carpet size is 128x80cm.

http://www.aberlaas.com/fr/FR

in the local newspaper

dressmaker in action

NB: website internationalisation is planned. More customization too (e.g. colours). For each sale, 1€ is donated to French OSM-fr local chapter. They already received complains from parents that street names are not printed ! Hey, dad, it's for your kid, not for you :-)

Separate account requirement for all imports, even small ones (erg, what is small ?)

Posted by Pieren on 19 October 2012 in English (English)

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"

-- but the process implies that we should constantly switch from one account to the other (since we also contribute manually for the integration). This would be very painful...

-- (DWG) : no, the rule is "use a separate account for imports"

-- and you send a warning message to contributors in English when our public is the crowd. Most of them will not understand your message...

-- (DWG) : then translate our message saying the rule of "use a separate account for imports"

-- but, hey, who decided that the separate account is not mandatory when it was just a recommendation for years ? Is it not a gouvernance problem in the project that a very small group, the DWG, decides for all of us ? Does not the foundation claims everywhere that they do not interfer with contributions ?

-- (DWG) : We can discuss gouvernance in a couple of months or years. But till then, the rule is "use a separate account for imports".

-- and what do you think about the compromise coming for a third party saying that we could identify such uploads with a specific tag on the changeset itself, thus, it would not require to switch from one account to another ?

-- (DWG) your building imports takes so much resources. Cannot you not make this effort to follow the rule "use a separate account for imports" ?

As you can see, the dialog is impossible. It is very sad that the only group able to block users, DWG, is behaving like this. We really get the impression that DWG is a teacher admonishing children. The OSM gouvernance is really going to the bad way.

Older Entries | Newer Entries