Map Editor version (August 12, 2012) Official Feedback

[jeberhard]

Maybe newbies need to be limited to x number of edits per day/week for a certain time period/edit total before they can be let loose. By limiting them it prevents mass vandalism or cluelessness and it gives the more experienced editors a chance to evaluate their work and nip any problems from the start.

[daknife]

You exactly named the problem, which is that AM rights were provided to anybody who asked.

Which was/is a good thing, not a problem. When I started there were about three active editors in my entire state and they all were focused on just a couple large population centers. I started, figured out how to edit, read the guidelines and started editing, I quickly fixed everything withing the 1 mile scope of my drives but saw many more things that needed to be fixed and so I asked to be AM. Based on some of the suggested approval criteria I wouldn't have wasted the time, and as a result the Roads in Utah would still be trash. There is still lots to do, but I've gotten many of the towns and cities navigable. I've also spent a good deal of time working on cleaning up Las Vegas and a few other cities in Nevada, why? because nobody else is doing it. Now I've passed the million point mark, and the former number one editor in the state is only about 50,000 points further along than when I started.

If every city or region had an over-abundance of active editors then restricting AM status would be a good idea. But there are many areas where nobody local is doing anything. Some are more rural, others probably the basemaps are just so bad that people try it, see that Waze can't route for a darn and quit. Keeping AM status open to anyone who's willing to try it has some risks but in my opinion those risks are far outweighed by the benefit of getting maps that work.

Keep AM easy, it only gets you so much area. Maybe put a sliding scale of how much terrain an AM can manage based on how many edits they do. Anyone can get a single max zoom permalink block of terrain to AM, but to add more blocks will rely on how many edits they've done, and perhaps a community approval system. But we'll miss more good editors if Waze makes it too hard to edit in the first place. Far more good editors than bad editors who will be blocked by strict application criteria.

[bgodette]

So just for clarification, what exactly does lock do today? Only restrict users of a lesser level from modifying it or its junctions?

That is the majority of my understanding.

I've read that it "more stringently enforces" or adds "additional penalty" to routing against a turn restriction, but that may be just a rumor and shouldn't be taken as anything close to a fact.

Pretty much. There's been no firm testing through an expanded test rig that shows locking as it was a few months ago did anything other than prevent lower level editors for editing the segment and associated turn restrictions if it was outside their AM area (if they had one). There's anecdotal reports that locking adds a higher penalty, but I know of no one that's done a controlled test to confirm/deny.

The wiki is also mistaken about locking's effect on direction updates. According to testing by jasonh300, locking has no effect on the automatic systems updating directionality. I have a test rig that will test aspects of the automatic systems with the next map update, after that I can reset it to test with the segments locked and confirm jasonh300's testing.

[porubcan]

There is no way we are going to get an adjustment to the current situation which will make everyone happy or satisfied. There is no way to keep the high value segments locked (if they are already locked), while also keeping other segment types locked if they are special or "locked for a reason" as someone wrote. The logic for that just doesn't exist. Could harling's idea of "unless it was locked in the last year" idea work? Maybe, but there are plenty of segments which have been improperly locked in the last year which should be unlocked anyway. If it's a junction between any segment type and a high value segment, the turn restrictions should still be preserved. It's the street-to-street ones which may be compromised in this unlock process.

We also cannot just lock segments down to a "level 2" without also specifying the user to lock it to. That imaginary user doesn't exist and this would need extensive testing first. We need a faster solution. I assume all Area Managers and CMs are reading all the unlock/update threads and handling them as appropriate? Well, some are.

moreover you will not be able to manage L3 promotions. it should be no problem to cheat to get 100k and get higher level rights for someone, who will do more harm than good...

Waze is supposed to be "social" app which relies on "community".
Why don't you handle the problem that way?

This is interesting as in some countries, AMs are allowed only after vetting and process built by the community and managed by country managers. This "cheating to get higher level rights" doesn't work there. And soon, it won't work in other countries either as more and more jump on this bandwagon. This is the "community" way to make that work. There isn't, unfortunately, a community way to handle the thousands of unlock requests in a month. That process is breaking down under the scale of unlocks required right now.

Actually there is possible better way. not easy one, maybe not satisfying every one, but maybe better. And you just named it above. Vetting process for AMs. if this is working, we would not need to protect map from AMs, only from inexperienced users. and it would be no problem to give AM full control within his AM area.

In my country (Slovakia) there is vetting process for AMs established:
to grant AM rights, user must show his edits, have at least 2k of them, be active on forum (min. 20 posts; communication is vital for future cooperation) have at least 10k of points and be a member for particular period of time (couple of months). there might be exceptions, of course.
user is asking for AM rights for particular area via forum thread (so everyone else is able to see his request and react).
then his request is evaluated and if accepted, guri211 (Waze Chanp member) is asking support for granting AM rights for him.
even this process is in place, support is granting AM rights to any user who asked. so we faced problems with new AMs too. but there was still option to ask support to remove their rights.

so now it would be better to revert the permission change, (community should) create list of AMs who should have their rights remained and remove AM rights to all other current AMs. and any new AM requests handle via vetting process.

[porubcan]

You exactly named the problem, which is that AM rights were provided to anybody who asked.

Which was/is a good thing, not a problem. When I started there were about three active editors in my entire state and they all were focused on just a couple large population centers. I started, figured out how to edit, read the guidelines and started editing, I quickly fixed everything withing the 1 mile scope of my drives but saw many more things that needed to be fixed and so I asked to be AM. Based on some of the suggested approval criteria I wouldn't have wasted the time, and as a result the Roads in Utah would still be trash. There is still lots to do, but I've gotten many of the towns and cities navigable. I've also spent a good deal of time working on cleaning up Las Vegas and a few other cities in Nevada, why? because nobody else is doing it. Now I've passed the million point mark, and the former number one editor in the state is only about 50,000 points further along than when I started.

If every city or region had an over-abundance of active editors then restricting AM status would be a good idea. But there are many areas where nobody local is doing anything. Some are more rural, others probably the basemaps are just so bad that people try it, see that Waze can't route for a darn and quit. Keeping AM status open to anyone who's willing to try it has some risks but in my opinion those risks are far outweighed by the benefit of getting maps that work.

Keep AM easy, it only gets you so much area. Maybe put a sliding scale of how much terrain an AM can manage based on how many edits they do. Anyone can get a single max zoom permalink block of terrain to AM, but to add more blocks will rely on how many edits they've done, and perhaps a community approval system. But we'll miss more good editors if Waze makes it too hard to edit in the first place. Far more good editors than bad editors who will be blocked by strict application criteria.

before I was granted AM rights, I had to prove my experience within "1-mile" corridor. sometimes I was just taking alternative routes just to enlarge my editable area.
User should prove his experience prior getting AM rights.
if the problem is just small area for new users, just consider extending area from 1-mile to 2, 3 or 4-miles. but still without right to override locks, which should be preserved for AMs. it is Area MANAGER, not someone who just came across.
if you keep AM just simple - user with limited rights within small area you need to take apart experienced editors to give them better rights. and overriding locks is one of those. but I haven't seen any solution for those.

[FreeMan12]

So just for clarification, what exactly does lock do today? Only restrict users of a lesser level from modifying it or its junctions?

That is the majority of my understanding.

I've read that it "more stringently enforces" or adds "additional penalty" to routing against a turn restriction, but that may be just a rumor and shouldn't be taken as anything close to a fact.

Pretty much. There's been no firm testing through an expanded test rig that shows locking as it was a few months ago did anything other than prevent lower level editors for editing the segment and associated turn restrictions if it was outside their AM area (if they had one). There's anecdotal reports that locking adds a higher penalty, but I know of no one that's done a controlled test to confirm/deny.

The wiki is also mistaken about locking's effect on direction updates. According to testing by jasonh300, locking has no effect on the automatic systems updating directionality. I have a test rig that will test aspects of the automatic systems with the next map update, after that I can reset it to test with the segments locked and confirm jasonh300's testing.

This strikes me as a major failure on Waze's part. I wasn't around in the very beginning, but from what I can ascertain, it seems that they created a blank wiki template and left it to users to complete. We now refer people to a "definitive" wiki (most people think of it as such) for their answers, but nobody knows if the answers are correct. We give people advice here in the forums, but it's based solely on "best guess" and intentionally fudged road segments that we're forced to set up for testing purposes to try to reverse-engineer the system.

I understand that waze has spent untold millions(?) of dollars developing the mobile clients, web front-end and all the back-end server infrastructure, and they are looking for a way to be able to make a profit off of it. If they don't, none of our complaints, suggestions and editing work will be worth the electrons used to store them, since they'll close down. However, I believe that they can share information on what a "lock" does without giving away any trade secrets. As a matter of fact, it should increase revenue options because with the editor base having a better understanding of how the routing system works, they'll have better maps and a bigger user base to use as sales leverage.

[bgodette]

However, I believe that they can share information on what a "lock" does without giving away any trade secrets.

The problem is in the past when information like that has been released, either something gets lost in translation or isn't explained well enough or is the design but not the actual implementation, and what we end up reading doesn't match reality as seen through testing. Until the base cost test rig, it was assumed all segments had the same default speed, it was what we were told, turned out each Type has a different default speed. People still believe that long routes won't consider segments Typed below a certain threshold depending on how long that route is, as the map has matured this has been shown not to be entirely true.

Fortunately the last few changes have broken that trend. The change to Private road behavior and then Parking Lot worked exactly as described to us. Toll roads have worked exactly as described to us. ROTW gas stations worked mostly right with a few rounds of bug fixes and now seems to work as intended. The change to the permission systems works exactly as described in so far as the ability to edit a segment is concerned, with side effects TBD.

[FreeMan12]

However, I believe that they can share information on what a "lock" does without giving away any trade secrets.

The problem is in the past when information like that has been released, either something gets lost in translation or isn't explained well enough or is the design but not the actual implementation, and what we end up reading doesn't match reality as seen through testing. Until the base cost test rig, it was assumed all segments had the same default speed, it was what we were told, turned out each Type has a different default speed. People still believe that long routes won't consider segments Typed below a certain threshold depending on how long that route is, as the map has matured this has been shown not to be entirely true.

Fortunately the last few changes have broken that trend. The change to Private road behavior and then Parking Lot worked exactly as described to us. Toll roads have worked exactly as described to us. ROTW gas stations worked mostly right with a few rounds of bug fixes and now seems to work as intended. The change to the permission systems works exactly as described in so far as the ability to edit a segment is concerned, with side effects TBD.

This strikes me as a major failure on Waze's part.

OK, I've been a programmer for 20+ years, I understand things don't always go to plan and that specs change along the way. If someone official makes an announcement on how a new feature works or how an existing feature is changing, the thread should be monitored to ensure the community understood correctly, if not the Waze official should step back in to correct misunderstandings. Not to slap us on the wrist, but to keep the free labor heading in the right direction so they can make (more) money off our efforts. Same goes if the specs change between when the feature is announced and when it's delivered.

My main point is that all our work is done on best guess and/or time consuming reverse-engineering when a bit of communication from the mother-ship would simplify and speed up the work of the community; be authoritative (even if course changed mid voyage); and all-in-all be more conducive to a user-friendly end-product that would be more marketable.

[AndyPoms]

After seeing the useful message that the USER sees when their requests are closed, EVEN IF the closure is a 'not identified', I am of the opinion that if the request can not be 'fixed', it should be closed as 'not identified' asap, NOT left open hoping someone else will 'solve it'.

New editors should leave URs they don't understand alone because some of these URs obviously have something wrong, but are just confusing to figure out how to fix it. A more senior editor can probably fix it in a matter of minutes (or seconds), or the new editor can edit some other things and then they realize how to fix it. That being said, URs shouldn't be left for excessively long periods of time.

I am of the opinion that outstanding 'very old URs' reflect poorly upon WAZE and the WAZE volunteers.

They most certainly do. That's why a lot of us work very hard on our areas of the maps. If you look at my parts of CT (if you can), you'll see there are 4 open URs... 1 Support asked for (to work on the undated UR from LiveMap issue), and the other 3 popped up in the last day or two and are all at one of the casinos, an area I need to completely rebuild but I'm just not focused enough to do it right now.

In fact, I have read some URs from frustrated users that indicate that they have submitted the same requests, over and over, and seen no response.
If someone had bothered to 'not identified' it, then they would have at least gotten an e-mail explaining things.

We see the same style UR when the user repeatedly reports something that warrants a "not identified", not because it isn't an issue, it's something we can't fix (i.e. time based restrictions)

If someone actually fixed it, then the USER gets a message warning them that it may take a while before the fix is visible to them. This is also a good idea and reduces some to the frustration of the users.

The users don't read that far in the email... Just look at the repeated URs about the same issue that was solved over the course of days (well within the "10 days or so" window the email clearly states).

When I was supervising programmers, I would always remind them that 'It is the programmer's job to make things easier for the users. It is NOT the USER's job to make things easier for the programmers!'

With WAZE, the primary USERS are the drivers. The maps are not to look pretty, they are to give the drivers the proper instructions so that they get from A to B.

If 'turn only lanes' are present on the ground and drivers are complaining about bad junctions or bad driving directions or turn not allowed because they were in the wrong lane when they hit the intersection or WAZE is posting Problem Reports asking for roads to be drawn, then WE (the editors, acting as programmers) need to add the lanes, even if it 'looks messy' in the editor. I have had other editors 'simplify' intersections after I had added lanes to in response to URs or in response to my driving the route and getting wrong instructions. An intersection or road should NEVER be 'simplified' unless wrong driving instructions are being produced!

Ever hear of a PEBKAC error? We should not be idiot proofing the maps... Waze give (in the US) a 1 mile warning ("In one mile prepare to turn [right]"), if the user is too stupid to understand that that means they need to get in the [right] lane so they can make the turn they shouldn't be driving in the first place.

First rule of programming, or mapping, or anything really: KISS - Keep It Simple Stupid (for the record, I'm not calling you or anyone else stupid, it's just an expression). Yes, some intersections need turn lanes added to them, most don't. I had to rip up a two mile stretch of minor highway because someone decided to add turn lanes into and out of EVERY SINGLE parking lot & side street on the road. It didn't route properly at all. Once I simplified it, it routes perfectly.

There are a few places were directions don't make sense. Let's say a Freeway ends and there are 3 choices, A (to the left), B (straight ahead), and C (to the right). Waze doesn't support stay straight, so there are different ways to try to force the directions to work correctly, something I'm experimenting with right now (waiting on map updates to see if more URs come in after the change makes the map).

[skbun]

My main point is that all our work is done on best guess and/or time consuming reverse-engineering when a bit of communication from the mother-ship would simplify and speed up the work of the community; be authoritative (even if course changed mid voyage); and all-in-all be more conducive to a user-friendly end-product that would be more marketable.

I agree. We're not asking Waze to release the internals of say, 'finding the optimal route from A to B', which I'd guess is a trade secret. That said, I would like to know 'Waze's definition of presenting any given route best' - even if it changes over time, which can then be populated with Waze's proprietary traffic data and routing decisions behind the scenes. The reason is simple: because we the map editors, soup to nuts, are tasked with giving Waze exactly this.

If the user community were only asked to use the client and find bugs in it (basically, Google's model), I really wouldn't care how roads are done under the hood. "Magic happens" and I'm routed. But that's not what we're doing here.

Here's a perfect example of what I'm talking about. http://www.waze.com/forum/viewtopic.php?f=15&t=23517

In this thread, there is speculation on:
* At what speed roads disappear or reappear based on type
* What a street whose assumed speed is greater than the above should be classified as to avoid it disappearing (or even if that's a 'bug' at all!)
* What the definition of a 'primary street' or 'minor highway' is, semantically, because roads like this often have high speed limits but it's not known what to class them as

Now I've discovered that different road types have different assumed baseline speeds, from this thread. That would have been a good thing to know in this discussion. If it were included in this page, http://www.waze.com/wiki/index.php/Map_Legend, the thread above might have ended with 'Just call it a [TYPE X] and the right thing will happen. Don't worry about what the class name is'. Again...reverse engineering.