Page 1 of 1

Residential Place Points (RPPs) and how to make them work

Posted: Sun Jan 13, 2019 9:04 pm
by subs5
This weekend a few editors asked me about RPPs so thought I would put the information down in a forum post.

Residential Place Points (RPPs) are discussed in the Wazeopedia in the following sections for Places and House Numbers.

The best way to get a RPP to work is to have the following:
1) The RPP's ADDRESSs should have:
a. STREET name
b. HOUSE NUMBER
c. CITY (may get an auto fill, verify it is correct city)
d. STATE (should auto fill)
e. COUNTRY (should auto fill)
2) An ENTRY/EXIT point should be added. (Adjust the point location, if necessary, so it directs to the place on the desired segment where the arrival announcement should be made.)
3) Create an RPP (residence/business address) by converting a Place Point (PP) with the link at the bottom of the PP's left screen. Link is "Convert to residential/private (address only)". This makes the round PP into a triangle RPP in the editor.
4) (Optional for WME Production) Click the appropriate lock level for the region's guidance. As of 13 Jan 2019, the lock level disappears in the WME Production editor after a RPP is saved.
5) Save the RPP.
6) Ensure a nearby segment has the exact STREET name / CITY name pair, either as primary or alternate, as listed in the RPP.

This should ensure that the RPP works the vast majority of the time (since nothing is ever 100% in Waze as intentional and inadvertent code changes occur a lot).

Also, if there is an existing HN (base import or editor added) then an RPP can't be saved greater than 50 m (>50m) from the HN's anchor point.

To resolve this:
1) Delete the HN.
2) Then,
a. Save the RPP as a PP in the correct location. After two tile updates (TUs) have occurred, convert the PP to an RPP (see above).
OR
b. Save the RPP within 50 m of the HN's anchor point. After two TUs have occurred, move the RPP to the correct location.
3) Put an MC over the RPP in progress for other editors then use the UR MP script to locate it after the two TUs have occurred.

But hey subs5, I have a RPP that is working without an entry/exit point. Yes some RPPs will work w/o an entry/exit point, but not sure what stars and planets need to align to have it happen.

This does not happen consistently for Waze app users or editors, so instead of making a change and then having to go back and verify that it works or even in a month get the UR with the "Hey the fix to my address is not working anymore" - isn't it better to just click the entry/exit point and not have to spend the additional time to solve a problem more than once? The Wazeopedia RPP guidance was written so that the entry/exit point is required so that the fix works consisently. You can try it w/o the entry/exit point but then need to go back and check it to verify that it works and might need to periodically check after changes which seems like a lot more work. And you consider Clint Eastwood's line from Dirty Harry "You've got to ask yourself one question. Do I feel lucky? Well, do ya, punk?" :D

Remember the user has to search with the same street and city name pairing for the RPP to work so it should normally be the USPS street and city pairing since the vast majority of people use that. Local guidance on Census Data Places, Townships, Parishes, or other names. If more than one city name is used in the local vernacular then there should be more than RPP for the location and ensure the street/city pairings are each listed on the local road.

I have had to alter a few RPPs several times over the years to get them to work properly after various changes to the back end. So here is the history of RPPs as subs5 remembers it:
There needed to be a way to have people routed to an address that was not anchored to the named road like House Numbers (HNs), so Waze come up with RPPs.
Original iteration of RPPs: You just needed to have the STREET name, HOUSE NUMBER, STATE, and COUNTRY. The CITY was used if there were primary CITY names on the road segments, but in the rural areas where the primary city was "None" then the city was not needed on the RPP. This worked for the stored that are quite a few Parking Lot Roads away from the named street or the places with vanity addresses but the actual entrance was on another street.
Second iteration of RPPs: Then RPPs were changed to where they needed to be nudged. You had to move them ever so slightly (sort of like the imported House Number used to have to be nudged to work). Magic script even had this as an error. I did receive several URs for RPPs that I had added before with the original guidance that had been confirmed to work in my app; therefore I nudged the RPP and then it worked again. These were confirmed by the user and myself in the app.
Third (current) iteration of RPP: RPPs no longer needed to be nudged! Yeah! RPPs now need to have a City and that City needs to be on a nearby road segment with the street/city pairing AND RPPs need the entry/exit point. Not so yeah.... So have received URs from RPPs fixed for the nudge above that no longer worked. Also URs from original RPPs that no longer worked. Once they had the city added, the city added as an alternate name to the road segment, and the entry/exit point both earlier iterations of RPPs worked.

Can't merge RPPs One last thing, Places now have merge capability between PPs and APs, but not RPPs. RPPs just have basic information and two RPPs should really only vary in city name used and pictures. You can edit the city name if need be or there can be two different city names used for the area so there needs to be two different RPPs. The only real drawback is you can't merge RPPs to transfer pictures. So now you know why you can't get that great Holiday Light Display from a new PP submission into the existing RPP.