Hi
Why this
.Did not Appears in the
Announcment?
Thanks AlanOfTheBerg.
I assume that the visual on the Waze application still looks the same.
For example, when I search for and route to a specific Place Point, this is what I see on the application. It routes me to the front of the store since the Place Point has been nudged closer to the Road Segment.
So from your McDonald’s example, even though the Place Point is closer to the drive-thru segment, the placement of the Entry Point at the front of the store means that the Waze route stops there. So it functions exactly as if we moved the Place Point to the front of the store.
Doesn’t this mean that both a Stop Point for an Area Place and a Entry Point for a Place Point and Residential Place Point performs the same function? If so, can we not name them the same - either Stop Point or Entry Point? Naming them differently brings to mind that these two perform different functions.
They should be named the same. MapSir has used the name probably because that is what the devs call it. For now, we would call it a Stop Point. (In the future, Places will have multiple navigation points, and probably can be designated entry and/or exit points.)
Sent from my iPhone using Tapatalk
Thanks, however that doesn’t explain my original question: What does the position of the point place represent? I would expect to see the finish flag at the position of the place, while the end of the route at the position of the “entry point”. As abc1357 pointed out, it seems that only the position of the entry point matters when navigating to a point place, and the position of the place itself is ignored. So this is why I don’t see the function of two different positions associated with a place.
Correct, Devs call in Entry point 
Trivia211 - The race flag in the app will always represent the end point of the route, not the location of your venue/Address.
The option to set an entry/stop point without moving the actual place has many advantages.
- New editors would sometimes move the place to the “right” location, and mess up the navigation.
- Client users who send PUR’s can be matched better with the relevant venue in place. avoiding images being attached to the wrong venue.
- In the future, we’ll introduce multiple entry points.
The way I see it, the Point Place’s location is purely for the editors’ sake while the stop point is for the driver.
Looking forward to multiple entry points!
It’s also for the Ads campaigns. Because we match Ad pin to place location.
If the place will be off there is a chance the system won’t match the Pin correctly.
This isn’t new in this release - it has been in production for months (since at least March), although it would have been nice to get a release note for it when it was released. Just be careful doing anything with the duplicate…if you delete the duplicate instead of accepting/rejecting the PUR the original Place gets deleted as well.
MapSir answered this from an functionality POV. From a mapping standpoint, we want to represent the actual business locations correctly. However, when that location doesn’t result in a good navigation or end-point result, we had no choice but to make the map more inaccurate by moving the Point Place to the segment we desired to end navigation at. That is not ideal. Now, we can leave the business marker where it should be, and still end navigation where it should be.
One thing I’ve noticed about the new stop point for PPs feature is that once the stop point has been moved independent of the PP, it appears the two will always be separated and can no longer be moved together. Not a huge deal, but I was wondering if there was a way for the two to be rejoined.
The other thing is with the new feature, you will no longer be able to see at a glance the stop point placement of multiple PPs, like at a shopping center or mall. You will now need to click each PP individually to see if the stop point is where it should be. Again, not a huge deal, but it might require some more effort on the editor’s part to see that stops points are where they should be. Perhaps someone could create a script that could allow editors to see stop points for multiple PPs, or perhaps an indicator that the stop point is no longer in the same position as the PP.
Overall, I think this is a very nice new feature for WME.
I think I can help with that. Won’t be able to get to it until next week, though.
Ctrl+C doesn’t work anywhere. I cann’t copy text and have to use mouse copy any text
I am not seeing this. Can you do a video snap of this happening? I tried copying text from general display on the left panel, in text fields, the permalink field, etc.
You didn’t assign Ctrl+c to a shortcut did you?
OK, I find out where is the problem. It’s one script which I installed yesterday.
Sorry.
I understand. I think it would be useful to show the finish flag at the actual location of the venue, so Wazers could see where to go after parking their cars.
I agree. That would make the feature even more useful.
Please feel free to post a suggestion in the app forum. :geek:
I really like the separation of the PP/RPP location and navigation endpoint. Huge. Thanks for this, HQ.
Now that is something I am wanting to see soon!
It needs to be mentioned, I believe, that the new “Entry Point” (i.e. stop point) feature for Point Places has a severe downside: it’s now impossible to tell at a glance which Point Places will route incorrectly.
I have corrected hundreds of Point Places in the past simply by noticing questionable placements while I happened to be scanning an area. Now I have to click on every Point Place to verify correct entry/stop points; that’s not a good use of energy, and it’s no fun either. From a maintenance and verification standpoint, honestly I liked it better the way it was.
Within the volunteer community, as well as within Waze itself, there is enthusiasm for taking maximum advantage of new features and an expectation that long-term map maintenance and verification will take care of itself. That’s an understandable perspective, but I worry it doesn’t give enough weight to the ever-increasing volunteer workload that’s resulted from some recent features. Granted our volunteer scripts are amazing and go a long way towards compensating for these issues, but they can never be more than band-aids on what Waze provides. Not to mention Waze’s regular habit of ripping those band-aids off.
I’ve heard that Waze is concerned that action alerts in some areas are appearing faster than local editors are dealing with them. If Waze wants to improve volunteer productivity, it needs to take into account volunteer efficiency!
I hope future releases can address these maintenance & verification issues.