If that was his landing, the FAA would like to talk to him.

That's a taxiway!

BTW: Cute name on that runway.
Doesn't exactly match up with best practices, but I like it!

I guess that one should be closed as "unresolved"... that problem will NEVER be "solved"

<Not There> and done

sketch wrote:

sockslabs wrote:This is why Waze should be allowed on airline flights. Rather than driving 4500+ miles, instead it would have directed him to the nearest international airport.

Freakin Google Maps does this now! What a pain!!

I don't know if it is still active, but there is or was a GM easter egg.
Origin "The Shire" destination "Mordor" and select routing on foot.
GM's response "One does not simply walk into Mordor"

bgodette wrote:This is something that may be possible in the near future. There's supposedly in testing a (national?) system for querying gate status for rail crossings. If that system has a public query api or private access can by negotiated by Google/Waze, it's certainly feasible to implement.

That would be great, but what kind of time buffer would we be looking at? With Waze client alert update times taking up to 5 minutes to distribute, and in my city, a typical commuter train gate activation only lasts 45-90 seconds, it seems that it would only be helpful when a crossing is closed for an unusually extended time period such as for switching operations.
I haven't taken the time to look it up, but I was told by one of my trainers 20 years ago that it was illegal for the railroad to block a grade crossing for more than 5 minutes without notifying the local emergency service providers.

I absolutely agree, but the client/server communication routines would need to be tweaked to increase the polling frequency for at least this one alert, and this would impact data usage (already low but it's a concern).
I guess the server could "push" only the RR alerts to users in the immediate area plus those running a route that passes through the crossing.

The basic architecture is in place, just the present way of handling alerts needs a complete overhaul, ie:
"accident ahead>minor accident>reported by waze 8 hours ago" accident was cleared in 30 minutes... some alerts "stick" for too long.
Alerts appear on the map but there is no warning given.
Alert on the map, verbal warning given, but no popup so no ability to thank or report "not there" (I've been encountering a LOT of this in the last week)

And of course, the latency in the alerts being distributed to the clients, plus the time delay encountered by the routing server in calculating a bypass, then determining if the bypass is faster than the delay from historical RR blockage times.

When it comes to delay-driven short detour rerouting, we have problems today that need to be corrected before adding yet another source of issues. I'm constantly finding URs reporting drivers being directed to make a right turn, then a u-turn, only to come back to where they were.
At first these "detours" only avoided left turns, but the last couple of weeks I've been seeing them appear where the driver is continuing straight.
Adding another detour-promoter is going to complicate fixing these issues.

I would have accepted that and just made the edit.
The photo appears to be what Waze wants.

Challenger3802 wrote:It's probably also the allure of receiving 18 points for every photo submission (of a destination). Most of the ones I've rejected are for home addresses where the picture is a random shot down a street, with "pin-the-tail-on-the-donkey" luck of which house do I want?

You can't add a place without taking a photo.
Some may want to add the place with the address but prefer not to take a photo... and if there are any vehicles in the driveway, we can't accept them anyways due to license plates.

So instead of taking a photo of a house that will be rejected, or taking a photo of a house that they do not want posted on what they believe will be public, they simply take a shot of the street, or the inside of their car or front door.

It's a problem with the implementation of the feature... not the user.

I tried to add a new place yesterday, but the app INSISTED that the photo and description merge with an existing area place (poorly drawn) that overlapped the place I was trying to add.
I did not have the option to update or add... it forced the update, and since I'm above L1, it applied it immediately without approval.

Many editors have been complaining that airports and other major area-place landmarks are being corrupted by this... it's a big problem.

AlanOfTheBerg wrote:

Taco909 wrote:You can't add a place without taking a photo.

True, but one can easily update all other details of a place without having to take a photo. But it isn't clear to everyone how to do it, so ... users are doing it the only way they see which is obvious. Waze needs to re-work how Places get updated.

How? The app went directly to the camera when I tapped the "Place" button on report and my only options were to take a picture or cancel the report.
I had no option to update w/o photo, or to add a new place separate from the area place that I was within.

I just tried one from my home and AFTER taking the picture, it gave me the option of updating several landmarks near me or creating a new one, but that option did not appear yesterday when I was inside of an existing area place that was poorly drawn.