Vincent de Phily has commented on the following diary entries

Post When Comment
Question regarding deletion of some tracks/paths.. about 1 month ago is a handy tool to grab more monitoring links. It'd be great to keep it updated with other tools.

Most OSM contributors have areas they specially care about, but don't get too hung up about people editing "your" data specifically. The OSM data is constantly in flux, with some occasional setbacks in quality but generally moving in the right direction. It's better to worry/care about a specific region/topic than about the particular set of objects you edited.

suppression compte about 1 month ago

Pour supprimer un compte Il faut envoyer un mail à

Cela dit, supprimer un compte qui n'a eu aucune activité ne sert pas à grand-chose. Vous trouverez peut-être plus interessant d'aller sur's/account pour changer l'email et/ou le nom affiché pour votre compte.

On Being Trumped about 2 months ago

Pretty much all OSM surveyer have to deal with that. I find that giving lots of info when locals get curious/suspicious works best.

Be cheerful and use it as an opportunity to evangelize about OSM. Print some small flyers to hand out. Show osm on your smartphone. Show the photos you've taken. Be ready to answer the usual "it's a private road" (It's actually public, no trespassing needed), "what company do you works for" (it's a worldwide community of volunteers), "we've had burglaries here recently" (I can understand why you were worried when you initally saw me). Compare with Google Map/StreetView (more pervasive privacy issues, harder to fix, lower quality data...). Etc

recherche 2 months ago

Un peu vague comme question. Quel critère définis la personne recherchée ?

UK Unadopted Roads - What are the Accepted Mapping Keys? 3 months ago

Getting back on the subject of using the right OSM medium for the right purpose, may I suggest for questions like this ? It's made for that, it uses your login, you'll get (in my experience) better feedback than on a diary post, and the questions and answers feed a searchable knowledge base.

UK Unadopted Roads - What are the Accepted Mapping Keys? 3 months ago

Regarding the original question, it seems that "unadopted" is purely an ownership/maintainership distinction, and is orthogonal to all the other tags we frequently use (highway=residential/service/track, access=private, surface=*, etc).

So I'd say tag all those first, since they cover all the attributes that OSMers usually care about. Then go ahead and add unadopted=yes, if you know this fact for sure. Just don't make it imply any physical attribute of the road.

There are currently 89 unadopted=yes in the db. It'd be great if you had the time to write a wiki page explaining what it is, as it's unlikely to be understood outside of the UK.

UK Unadopted Roads - What are the Accepted Mapping Keys? 3 months ago

What's an "unadopted road" ?

Also, remember that noexit=yes is only useful as an aid to mappers in unclear cases, and doesn't actually need to be added to cul de sacs. A bit like oneway=no. Noname=yes is different, because that information can't be infered from the rest of the data.

Today's Spam 3 months ago

Checking the wiki spam page history, the last batch of spam cleanup was in march. Not great indeed, I thought it was more frequent than this.

It may be effective, but I don't think that diaries are the right medium for spam warnings : people reading them are looking for news about OSM, not routine admin stuff.

Hopefully and its associated PR will be solved/merged soon, so that we finally have a decent reporting system.

Today's Spam 3 months ago

Probably better to edit

My Ambitious South Philly Mapping Journey 3 months ago

Gah - stop reminding me ! I know I need to get my act together and work on myself :p

[edited] 4 months ago

Could have been meant in a lighthearted way, just forgot the ":)" at the end. But the place still needs to be mapped.

Milestone 4 months ago

I remember reaching that milestone in my hometown too, years ago. Quite a giddy feeling :) The next steps (housenumbers and buildings, in my case) can take a looooong time (I'm still working on it here). And POIs are never finished.

What, if anything, should I do about this? 4 months ago

Can't read the message you posted, it is only readable by you.

It's common enough for people to look at OSM and be surprised that part of their private property is mapped, and think that it shouldn't be. Each time I encountered this, a quick explanation was enough to convince the property owner, and often even gain some local knowledge to improve the map.

As long as you're only using public data (satellite imagery, non-trespassing survey...), are tagging things properly (don't forget to add access tags when necessary, especially to prevent routers from suggesting a driveway as a shortcut between two road, but most driveways don't need that), and are not including private information (such as "John Woo lives there" or similar), it's normal to have it in OSM.

Start by explaining this to Dreganius. Whether he is or knows the owner isn't actually important for the purpose of deciding what goes into OSM or not, what matters is the previous paragraph. Everybody benefits from a complete map; it would be pretty stupid for all the neighbouring houses/driveways to be mapped except this one.

After that, re-add the driveway, tagging it as access=private/destination if necessary. Local knowledge is needed before readding the name tag. If it is the name of the house, then putting it in addr:housename is probably the right thing to do. If it is the name of the people living there, then I agree that it is out of scope for OSM.

Nothing personal, just GPS tracks 4 months ago

Currently all those track repositories are data silos, even in the rare case when the license allows extraction. It'd be great to have a sevice which would be good enough to be used by any willing party (say all osm-based satnav apps) in just a few lines of code.

Top of the head requirements:

  • Anonymising (cut first and last part of trip, don't export lone tracks...)
  • Dead-simple upload API (REST, no account...)
  • Permissive license (PD ? Ability to wipe own data ?)
  • Pre-filters for HDOP, timestamps...
  • Post-filters for speed, date, hdop...
  • Auto-classify transport mode.
  • Export/render point clouds, flow direction, speed histogram...
  • Cheaply scalable

Ouch, that's actually a sizable amount of work. But it'd be worth it if it improves uppon the very fragmented sources that we currently have.

Lodestone Golf Course 4 months ago

Shouldn't you add at least a name to so that OSM users can search for that particular golf course ?

Entry for 2016 08 03: Familiarization with OSM and JOSM 4 months ago

You might be interested in

Do Not Bother to Post a JOSM Bug-Report for a Plugin 5 months ago

It'd be great for somebody to help maintain this plugin.

Some background: Getting the source (no need for an account): svn co Another attempt at a terracer plugin (maybe not the only one):

No need for permission to start hacking the code, only to upload to one of the osm-controled repos. Or if you don't like svn, you could do like derickr and put your version on github or similar. Then work with derickr and pull patches from each other, and don't forget to get your plugin listed in josm once it's in demonstrably better shape than the original one.

BTW I'm not (much of) an OSM dev, I got all this info in a couple of minutes just by searching the wiki and the net, it was yours for the taking as soon as you started getting annoyed that fixing the terracer plugin wasn't happening fast enough.

Do Not Bother to Post a JOSM Bug-Report for a Plugin 5 months ago

My experience of JOSM bug reporting isn't that bad, reporting is certainly worth the time.

Concerning the "use latest snapshot" requirement, it is pretty standard as many projects use this to ward off duplicates and false positives. And in your case it should be pretty easy to grab that josm-latest and report using an up to date stacktrace ?

The problem of unmaintained plugins is frustrating, but it's hard to blame the JOSM devs for code that they didn't write (and apparently don't use) and sits outside their repository. Terracer is really usefull and I'd like to see it in core... But that's a feature request, not a bug report. I'm not sure what can be done to reduce the problem of onmaintained plugins.

Seeing no progress being done on a bug that affects you is of course frustrating. But venting that frustration by re-posting near-identical bug reports (1 2 3 4) is counter-productive. It wastes developer's limited time and hurts motivation. It's not surprising that it feels like spam to them.

If you've got new information, you should add it to the existing report instead of creating a new one, that's a basic principle of bugtracking. If many months have passed with no reply it's acceptable to add a polite "any news ?" comment on a report, but unless you're a paying customer you should be prepared for a "sorry, no time, patches welcome" reply. Sometimes you get no reply, and that has the same implicit meaning.

Let's pretend like contribution is an import. 5 months ago

An import and an editor are completely different things, you can't applie the guidelines of one for the other. Sounds like you're just looking for a justification to effectively ban contribbutors. A simplistic "solution" to a complex problem, hiding it instead of fixing it.

I agree that there are things that do make contributions often sub-par (compared to the average newbie on other editors) : using old / incomplete data, and not interfacing with the osm community as much.

But these differences are not bugs, they are usecases. They need to be handled, not abandoned. Opening up editing to people who can only use offline data, or non-geeks who'd never read a full wiki page is an important thing to do for the OSM project, and I applaud for working on it.

Some issues are being worked on (more frequent data updates, multilingual names...) Some issues are trickyer (Improving the changeset discussion reply rate, foolproofing presets...). Some things are sorely needed but outside the scope of (better tools to detect and help newbies).

Don't condemn, help them. They're just the messenger of things to come, of practices that OSM needs to become ubiquitous. Other apps, like navme, arguably waste more OSM contibutor time than even though they only post notes.

As for the team: great work so far, but a lot more is needed :) And fix bug 3623 ASAP, it'll reduce the community flak.

GPS Coordinate shortener: what3words vs Mapcode 5 months ago

I stay away from w3w, mostly because it isn't free but also because it has only one precision, and is rooted in one language (they make other languages available, but converting is no fun).

IMHO a Lat/Long encoding shoud:

  • be completely free
  • be short enough to remember
  • be language neutral
  • have a variable precision
  • have an error correction

I don't think that having nearby locations share similar codes is that important, since you're going to ask your device to show you the map anyway, and the error correction protects you. But most elligible systems have that property anyway.

The problem is that we have so many competing similar solutions, and that none have a clear popularity advantage. Some are backed by a company, which helps adoption (sadly w3w seems so far to be winning the marketing game) and some are pure free systems.

Another annoyance is that because they are all similar, it's hard to tell one code from another (say an openpostcode one vs an openlocationcode one).

These days I'm kind of tempted to follow openlocationcode. It doesn't define an error correction code, but its Google backing makes it more likely than others to reach critical mass. Country-specific codes like openpostcode are still atractive, though.