Report bad editors

[bigbear3764]

Just based on this discussion, and me trying to fix some of these (fixed a whole bunch of Alabama and "Other" state alt names), I noticed a lot of roads have the same name in the Alt field. So real name and Alt name are exactly the same (Except maybe the state field). Seems like a waste of database entries.

Kinda wish there was a script that automatically deleted alt names if the the street and city match the regular name.

Bet someone changed the road name on WME before they gave us the ability to edit the Alt names. They didn't feel like or want to go into Cartoche to do it.

[AlanOfTheBerg]

Bet someone changed the road name on WME before they gave us the ability to edit the Alt names. They didn't feel like or want to go into Cartoche to do it.

Very likely, yes. The alternate street was added in Cartouche when the segment properties were wrong, such as wrong state, then saved. Alt inherits the primary. Even if they change the primary segment info in Cartouche or WME, the alt info isn't changed, and in Cartouche, you couldn't see what City was attached.

This is more evidence that, IMO, the alternate segments should always, and automatically inherit by default, all the primary segment meta info (city/state/country). This includes if the primary segment has its city/state/country changed, the WME should automatically change all alt streets. It's just cleaner and less prone to errors.

Some other editors have argued that for roads which are on city borders (one city owns one-half of the road split down the middle), that we should set alternate names for the other city. I say, "rubbish." That's not going to make any difference to driving. Waze doesn't care what city that segment is for navigation. I haven't yet heard a valid reason for having alternate streets have different city name than the primary.

[PhantomSoul]

Some other editors have argued that for roads which are on city borders (one city owns one-half of the road split down the middle), that we should set alternate names for the other city.

This is probably not so important now, since addresses are resolved through Bing, but ultimately when Waze itself can resolve addresses, it will somehow need to know that one side of the street is one city while the other side is a different city, since that will be reflected in the street's addresses.

[shawndoc]

This is probably not so important now, since addresses are resolved through Bing, but ultimately when Waze itself can resolve addresses, it will somehow need to know that one side of the street is one city while the other side is a different city, since that will be reflected in the street's addresses.

You are forgetting that often the "City" associated with an address and the actual city limits don't always match.

We'll have to see, but I'm guessing the new system won't care the name of the street associated with a segment.

[PhantomSoul]

In New Jersey, we have to go by Postal City, or zip code boundaries, since township names can and do repeat across the state so long as their mailing addresses are unique to the state. A single zip code may be assigned by USPS to use only one city name, though the zip code can span several nearby municipalities - sometimes even in a neighboring county, especially in less urban areas.

Here, this is the more practical method anyway, since the City feature will most likely be used for address resolution eventually, making actual political boundaries (actual city limits, county lines, etc) less relevant than address zip code boundaries.

[CBenson]

I disagree. I hope that City feature is never used as the sole criteria for address resolution or if it is that the search algorithms are as robust as the current address search that will find the destination regardless of whether you use the actual community name or the name associated with the ZIP code. Unless we have word from waze that they are going to need the zip code boundaries entered to resolve address searches, I don't think we should default to zip code boundaries.

[shawndoc]

My hope with the new system is it works like this:

- Bing (or whoever) continues to be the primary provider of address lookup coordinates
- Waze maintains an "override" database of addresses that have been entered by Waze editors to correct bad address location info provided by Bing.

We already know the addresses are no longer going to be tied to segments, and instead will be pinpoints. It would be insane if Waze expects editors to enter in every address in the world manually one by one, especially when there are 3rd party address sources already out there.

This allows Waze editors to correct addresses much quicker than the current "submit to Bing/3rd party and pray" methodology, it also allows us to position addresses where the entrance actually is. In many places, the address is on street X, however the main access is provided off of street Y for various reasons. It would also solve the Bing issues where the GPS coordinates are properly located on the building, however the building is closer to an alley/street behind the location, causing Waze to route there instead of the main entrance in front (often caused by parking lots between the street and the building).

The search methodology on the back-end would first check the Waze maintained database on an address lookup, and if found, use the Waze entered pinpoint coordinated for navigation, if not found in the Waze database, it would then forward the query to Bing/3rd Party as it does now.

[DaveHolzmann]

In many places, the address is on street X, however the main access is provided off of street Y for various reasons.

That reminds me of a time a number of years ago, when I worked in a retail store in a fairly large outdoor mall (it took up most of a rather large block - https://www.waze.com/editor/?zoom=4&lat ... 7,70693355.)

The Mall Mgmt. wanted to tear down our building, so they had us move to another building. The original store was closer to Showers Dr (about the middle of the block), but faced San Antonio Rd. The new store was slightly closer to El Camino, but quite a bit closer to San Antonio Rd, and faced El Camino.

All my Vendor Reps asked, "So what's your new address going to be?" The answer: Exactly the same. We're just physically moving with no change in address.

Then, about a year after the move, I had to notify all my Vendors that we were getting a new address. So, the natural question was, "So where are you moving NOW?" The answer: We're not physically moving, just getting a new address.

And the funny thing about the address shift was: originally the store (although closer to Showers Drive and facing San Antonio) had an El Camino Address, but after the move and subsequent address change, the store (even though it now faced El Camino and was further from Showers Dr.) had a Showers Drive address!

[PhantomSoul]

Unfortunately in New Jersey, we have several different Washington Townships, Springfield Townships, Union Townships, etc, which Waze thinks are all the same city, and now even places pins where it sees disconnected town names. These are not, however, the same towns/cities, and should not be contained within the same polygon.

Postal zip codes - and the official city names they represent are the only way, currently, to ensure the above does not happen. Besides, unless at least one zip code within a township goes by the township name itself (often none, do), nobody really knows the area by the township name anyway, making it less useful in the traffic reports as well.

Perhaps in other parts of the country or world, actual political boundaries mark out areas that actually have unique names within their region/state. New Jersey, however, doesn't work that way...

[bgodette]

Unfortunately in New Jersey, we have several different Washington Townships, Springfield Townships, Union Townships, etc, which Waze thinks are all the same city, and now even places pins where it sees disconnected town names. These are not, however, the same towns/cities, and should not be contained within the same polygon.

Postal zip codes - and the official city names they represent are the only way, currently, to ensure the above does not happen. Besides, unless at least one zip code within a township goes by the township name itself (often none, do), nobody really knows the area by the township name anyway, making it less useful in the traffic reports as well.

Perhaps in other parts of the country or world, actual political boundaries mark out areas that actually have unique names within their region/state. New Jersey, however, doesn't work that way...

Deal with it much like ROTW and include the county/province/state in the city name? At least I'm assuming the identical city names are in different counties within NJ.