They can be usefull as 'landmark' to recognize the map.

So it sounds like Waze wants walking trails and is working on fixing the issues with them. That's a good thing and one where we need to make sure they are aware of all issues surrounding them and that they address all of those issues at the same time. Really, a walking trail should never be used when routing for any reason. Waze should treat is as if it isn't there at all. Once Waze decides to allow use of Waze for pedestrians and cyclists, then Waze can use it for routing only when in those modes. That really should be a quick and easy change to make in the routing server. If the road type = walking trail, ignore.

Ok, then we need to get them to remove the logic from the live app and leave it in beta until the time when we start using internal addressing. There's no need for it until then. And at that point, we avoid the problem by not having addresses on there except when there are supposed to be addresses and then their changes should work for those cases. Either way, they need to be made aware that what they are doing breaks the app. That will cause people to leave and that's a bad thing for an app that needs users to function. Just my opinion, anyhow.

I did some testing and verified that routing is broken if the closest "road" is a walking trail or a pedestrian boardwalk that is not connected to the regular roads. They need to fix that as there are definitely trails that should be mapped in my opinion. And we can't wait for internal addressing to be complete before it gets fixed. They need to put in logic for now that ignores non-driveable roads when determining a route. That's an easy thing to do, so I don't see any reason not to add the logic. And they can easily remove it when it's no longer needed once internal addressing is complete. Either that, or put in logic that says if the closest segment cannot be routed to because it's not connected, to try the next closest segment and so on, up to a certain distance. If you're over X distance away and can't find a connected road, then there isn't anything wrong with it failing. Maybe something like 1/4 mile? That would also fix any issues where someone left an unattached road segment when deleting an invalid road or driveway that then prevents routing to the location because it's closer than the actual road. That could easily be set up such that if you happen to be on a walking trail and navigate from there, it will navigate to the closest point on the trail by ignoring road segments because the road segments are not connected to where the user is (basically a reverse of the normal situation).

For the time being, maybe any trails that are already mapped and that we want to keep should be set to railroad since apparently that doesn't have this problem? It may not show in the client, but at least we wouldn't have to remove miles and miles of trails only to add them back again once this is fixed. It's easier to just change the type and then change it back. Thoughts? I haven't personally tested railroads to see if they break routing, but that's what was said earlier. Or maybe stairs? Kind of odd, I know, but if stairs show in the client and don't cause this routing problem, then that could be another option. Just tossing out some ideas. I'd rather not remove major trails completely.

slandrum wrote:Right, that's what I was responding to - I don't like adding a walking trail that doesn't exist to get from the parking spot to the POI. Even though it generally must be physically possible to walk from where you need to park to the POI, that doesn't mean there's a mappable walking trail. What if such a trail goes through an employee garage, uses an escalator, and a skywalk between two buildings? That really shouldn't be entered in Waze. Instead, the destination should be the parking lot, not the POI.

If I were the one designing the POI system (and this may still be how it's being designed), I would set up POIs the same way we do addresses. Have a POI location with a Stop Point that can be set to the parking lot. Then, instead of how POIs work everywhere else, we'd have a useful feature that I don't think anyone else has. We can be routed directly to the parking lot and still see the POI at the correct location on the map. I think others may just use the address for routing instead of the POI point, but even that can be invalid for some locations because the street address and the parking lot are not at the same location.

But I think the main issue here is how walking trails currently break routing such that you get an error saying you can't route to that address even though it clearly shows the address point at the right location. I don't like the idea of removing major trails that are already mapped, especially really long ones (Michigan has trails of up to at least 70 miles in length). But at the same time, we don't want those trails to break routing. That's why I asked if we might want to consider changing existing trails to Railroads until the problems with routing are fixed. That's a lot easier than deleting them and having to re-map 70 miles of trail at a later date. Maybe that's still not a good idea? I'm open to suggestions.

Timbones wrote:I've heard of cases where drivers are getting directed to rear service roads rather than to the customer carpark. This is when the POI is positioned on the building itself instead of the entrance. For example airport terminals.

The described behavior of walking trails could be used to fix this issue, where necessary. Perhaps we should document it and utilises it?

What really needs to be done is for the POI location point to be moved. This is difficult when the POI comes from another search engine, but I don't think hacking the service roads by replacing them with non-driveable types is a good idea. It will further muck up the maps when the underlying problem (the location of the POI) is corrected. And I really don't think it's appropriate to create a walking trail where one doesn't exist just to fool the navigation system into routing to where the POI should have been.

Right, that's what I was responding to - I don't like adding a walking trail that doesn't exist to get from the parking spot to the POI. Even though it generally must be physically possible to walk from where you need to park to the POI, that doesn't mean there's a mappable walking trail. What if such a trail goes through an employee garage, uses an escalator, and a skywalk between two buildings? That really shouldn't be entered in Waze. Instead, the destination should be the parking lot, not the POI.

If Waze's real purpose is driving navigation, then the POI pin in Waze should be placed where you need to park, not necessarily at the actual POI, unless there really is a useful and mappable walking trail. This is similar to street addresses, in the internal Waze database (if it ever goes live), there's where the address physically is, and there's the stopping point on the road connected to that address. Maybe POIs need a stopping point that is separate from their location pin.

People usually can figure out that what they want is the parking lot for the POI for places like airports, for instance, you should navigate to long term parking at the airport, or rental car return, or whatever, not to the runways or terminals, but it's not always obvious for other POIs.

It would seem that if there's no routing penalty for entering/exiting a service road, then perhaps the private road type should be used instead (and just have its category broadened to include service roads). But that's a completely different solution than marking them as not drive-able.

That's a separate issue from POI stopping points being on the service road when it should be elsewhere.

Timbones wrote:Deleting the service road completely is another way to solve this problem (in the general case).

But runs counter to Waze's stated goal of eventually including all driveable roads in the map.

I've heard of cases where drivers are getting directed to rear service roads rather than to the customer carpark. This is when the POI is positioned on the building itself instead of the entrance. For example airport terminals.

The described behavior of walking trails could be used to fix this issue, where necessary. Perhaps we should document it and utilises it?

via mobile