(err, by "change", I mean, divergence from their initial expectations)

Compdude: much easier for established users like us to get used to the change (seriously - I was used to it after about three clicks), than for incoming newbies who will, be definition, never get used to any change.

Les voila ! osm.org/go/eqfnAGerQ-- :)

Serieusement, comment tu vas faire, en visitant les sites directement ? Ca a l'air sympa.

"it" meaning, the name, or the street? If the street never existed, how would you tag that? not:highway=residential?

It updates fairly infrequently. I don't know if there's a regular cycle, but something like every 2-3 weeks is typical I think.

I've done it a couple of times. Once I went and did all the laneways, footpaths and bike paths here: osm.org/go/uG4Ggq7K. I just drew a map from what I'd traced from imagery, then wrote notes on it. It was a bit tedious and fiddly, but I was riding a bike, and stopping every 50m is like that...

Nice fine print there. "Quit whining. Even though all your nearmap-sourced contributions will be deleted when OSM goes ODBL, you should rejoice in the fact that you can at least tick a box. Hundreds of hours of work deleted, but you get to TICK A BOX."

Or maybe I'm misunderstanding you.

Btw it's good to ask these quetsions on the official question site, http://help.openstreetmap.org/ .

C'est-à-dire ?

The strange thing I keep seeing again and again is the attitudes of people on the two sides: there's a cold, harsh, unsympathetic attitude from the pro-licence-change people. There are frustrated, well-meaning but impotent pleas from the other side. It's very sad to see good people go.

I've tried and failed to understand the licence issues. I can't believe it could be so complicated, but there has been a real failing of the people involved to communicate honestly and in good faith about the changes. Yes, the mailing lists are open. That's not the same thing. Dismissing the complaints of "the Australians", who will lose vast amounts of data (myself, hundreds of hours of work) as "FUDing trolls" is not good faith.

It's sad, but I don't see many people expressing sadness - I see the kind of vengeful "good riddance" comments exemplified above.

Hi Alex, no worries about being a 'back seat driver' - it's open source after all. You can see the code here: http://trac.openstreetmap.org/browser/applications/editors/potlatch2/net/systemeD/potlatch2/tools/Circularise.as

That mindprod.com link you post also suggests that the use of Math.pow to compute squares could be causing a problem.

One other thing to remember about this issue, though, is that the goal is usability: to compute a circle that reflects as closely as possible what the user wanted. So this very simplistic algorithm I've implemented has some deficiencies (eg, a way with lots of nodes at one place, and a single outlier, will produce a circle clustered around all the nodes) - but they're not necessarily bad for usability. So I think the needs of a centroid computation for Circularise are different from the needs of the WayUI centroid computation (which has to put the label for a way in the "middle" of it...)

Ok, I've added this in http://trac.openstreetmap.org/changeset/25276.

Hmm, interesting, I just implemented the naive "average X and Y" algorithm the OP suggested and...it works great. Perfect results every time. I'll have to do some more testing to make sure I'm not missing anything, but it seems a lot simpler than the "mathematically correct" algorithm currently implemented, and without the bugs.

(Btw the WayUI algorithm is buggy in the same way as the Circularise one, but presumably the results just aren't as noticeable.)

Had a closer look. Actually, circularise seems to work most of the time for me (at least in the development version). But I found some cases (mostly rectangles) where it is calculating the distance wrong, and probably the centre too (which would cause the distance miscalculation). With some of these, nudging the whole rectangle up or down a tiny amount would cause huge differences in the calculations - shifting the centre east or west of the original centre.

I think the best solution will be to move the centroid calculation from WayUI into Way (as already suggested in the code), and to use that in Circularise. Rather than having two different centroid calculations, at least one of which is clearly buggy.

Nice writeup. Circle has never worked for me in P2, but others claim that it does. The centroid is already calculated for every closed way. The only issue in implementing what you suggest is potentially losing history of some of the nodes, since you're basically talking about discarding all the old nodes and creating new ones.

I do like your thinking though.

But do you understand and agree with the new Contributor Terms?

Cool, je tombe par hasard sur cette page. En 2001-2 j'ai passé un an à Saint Martin d'Hères, dans la rue Louise Michel. (c'est tout)

Brilliant stuff. Presumably if they're using open source tools, any new software they write (interface, rendering etc) will also be open source? The more of these things around, the easier it gets for local governments that aren't quite so cutting edge...

This is a big problem that needs addressing. I'm a one-week newbie, and fell into the trap myself. Suggestions:
1) WARN PEOPLE IN BIG SHOUTY LETTERS wherever there is discussion of how to use imagery. Perhaps even in Potlatch itself. In my case it's Nearmap, not Yahoo.
2) Alert people to the fact you can align the imagery to the existing maps (space+drag in potlatch).
3) Add mechanisms to lock nodes?
4) Add warnings whenever a newbie tries to move existing nodes.
5) Store local imagery offsets? For example, if it's known that in the local area, the yahoo images are off by (3.5, -2.0) metres, then display them that way?

It's a serious problem because it's so hard to correct, and once the newbie discovers what they're doing wrong, they're going to be seriously discouraged from any further fiddling in case they mess up again.

The problem I find is when you're adding new stuff in a mapped area...you can't ignore the imagery, and you can't ignore the existing stuff. I tried just ignoring a mapped bike path, and tracing a building...but the bike path then goes through the building. What can you do? (Other than slide the imagery around as mentioned...but you have to be careful not to let it slide too far)

Several times I've caused duplicate ways/nodes. The reason is Potlatch occasionally failing to retrieve data from the server. Unfortunately, there is no visual distinction between "this area is unmapped" and "this area is mapped, but the data hasn't been downloaded yet". So you end up mapping the area, then some time later (maybe after browser refresh), the real data comes through...and now you have two sets.

(Though come to think of it, you're talking about real duplicates, not near-duplicates. Hmm.)