jasonh300 wrote:I'd say they could come in with just an import of the cities layer, however, in many cases it's wrong, or not practical and a lot of work has been done to fix those things also....work that would also probably be undone.

Yeah, I was thinking 'just an import of the cities layer', if anything. But I agree that ultimately, probably the best we have even with large changes to fix is 'What we have on the roads layer', now what with enough editor's eyes on the maps. Would you suggest in that case just having all of the city polygons generated at tile update time (as I think it works on the World server)?

skbun wrote:Would you suggest in that case just having all of the city polygons generated at tile update time (as I think it works on the World server)?

Personally, I think it would all be far more maintainable if city names didn't come from the segments, but were in a separate landmark layer that is only accessible to AMs & CMs.

[EDIT] The forum ate this post the first time I made it. I see someone else has already suggested a city polygon layer [/EDIT]

Yeah, and I was in on that thread too. If Waze were willing, I would be totally behind a CM-only editable 'state' and 'country' polygon layer. If it WORKED that way, renaming a city, or merging an annex into an existing one would be much much easier, city smudging would be a thing of the past, and much more effort would go toward segments and street (with alt street) naming, the heart of routing.

They could import the current 2010 Census base map polygons for cities in, and there DO exist 'Shapefiles representing states', that could go in its own layer.

Going that route would also put a leg up on say, Google maps, whose cities still show boundaries that ALSO look like they're from the 2000 Census import. Example. Google Maps's Auburn, WA? Still shows in Google in its pre-2008 annexation shape, where Lea Hill is a separate CDP.

City annexes, changes, whatever? The polygon layer gets changed by a CM, and it's up to date. In a week. And in the same way that roads get that feeling of 'keeping up fast'...then so do cities, right? Waze win.

(Oh, also? Here's a vote for making 'waterways' current to 2010, incorporating all creeks, streams, seas, lakes, whatever...merging the current waterways on the landmarks level INTO said layer...and then this 'waterways' layer editable as well. I've named lots of waterways in my area and made most I've done accurate to about 20-100m, but ask me how long it takes to make those polygons from scratch...)

AndyPoms wrote:Hmmm... That would be nice to do in a small state such as Connecticut...

Yeah...unfortunately, it appears that allowNewCities is a property on a country, and doesn't exist on a state. They'd probably have to mess with the database internals to allow that to happen on a state level, below 'United States'. Not that I'd object if they did!

The U.S. is the fifth largest country in the world by area, even without Alaska. Add Alaska in, and we're up to #4. Then you compare that to the Netherlands, which is the size of only Virginia, in area.

AndyPoms wrote:I was leaning more towards the automatic removal of a specific set of data (i.e. I can provide the official list of Cities & Towns, and Waze can removed everything not on that list from City & Alt Name fields)... The locking would be nice, but once we have the map correct, we can then easily see when new (incorrect) cities are added & just manually handle them...

You know, I slept on this, and I thought of another completely trivial thing Waze could implement inside the NA city creation routine that would solve 90% of these problems, forever.

"If the name of the city is less than three characters, and I'm being asked to create that city, throw an error and refuse to do it."

Inside http://en.wikipedia.org/wiki/List_of_short_place_names , here are all the cases in North America:B, a village in central Ohio, United States (Can't even find its location Googling for it)D, a river in Oregon, United States (Landmark, doesn't matter, but once listed as 'shortest river in the world', which is pretty cool)Y, a settlement in Alaska, United States (Exists on segments, done)Ai, a ghost town in Ohio, United States (Doesn't matter)Oz, a community in Kentucky, United States (https://www.waze.com/editor/?zoom=3&lat ... TTTTTTTTFT - this one would need to be created on about three segments, and, done)Ti, a settlement in Oklahoma, United States (https://www.waze.com/editor/?zoom=4&lat ... TTTTTTTTFT - again, create a few segments, and I think we're done here)Yp, a desert in the western United States (Landmark, doesn't matter)

...and that's it. For that matter, there are only a couple hundred such places in the entire world, and THEY could probably be checked and created in a couple hours. Do a one time 'Delete any other CityIDs with two characters or less', and we're done here.

jasonh300 wrote:Only want to add that it should throw up the same type of error that you get if you try to hit Apply without actually filling in either the street or city field. It should not be an error that you get when you save...50 edits later.

+1!

Ohhh, yes yes yes. Besides, at 'Apply' time for changing country, city, state, whatever, a bunch of checks for validity of a city name can be checked right there. Some I found are possible and shouldn't be, (like, < 3 characters, special characters, double spacing in a name...)...it could throw that error right then and there. You don't have to see what's in the database to know that those things are no-gos.

jasonh300 wrote:The city polygons have updated again. The couple of experimental things that I didn't want anymore in the area here are now gone, and then an inexperienced editor created a city right in the middle of New Orleans called "New" with a street created yesterday.

And D'Lberville is gone now...only about 10 hours after I removed it from the editor!

Update, yay! (Goes to check his own changes...)

This is just me thinking out loud here...so this may be a completely silly idea anyway.

I wonder how bad it would really be if we DID lock the U.S. down to allowNewCities:no, and ask Waze to remove the sticky/uneditable/basemap city layer after that's done, so all cities are generated by segment hits. We're in a unique position in the United States, because cities were pulled in BY the basemap import. (In most countries, this was not the case, I think?)

- The rampant creation of false cities would end- With the sticky layer gone, we can in practice delete unwanted cities by deleting all their segments

How cities are added after that, maybe Waze could help, if and when the time came? Locked down to high level editors, or something.-------------------------On a different subject, granting it is completely impossible for us to get this information without scraping the United States ten square miles at a time, I wonder how hard it'd be for Waze to dump out a table that's like CityID---CityName---State---Country---Lat/Long of name put on map---*Number of assigned streets

* (Number of assigned streets is only practical if CityIDs are keyed in such a way that you can say 'Tell me streets associated with this CityID' in the database. Very helpful but not strictly necessary.)

(You really don't want to know the digging I did over time to know all of this. Buuuuuuuut....)

Okay. So there is a gray cities layer, and a layer that shows names of cities for the gray layer. If memory serves me, they're 'cities_01' and 'cities_names'. As best I can reverse engineer, these are only generated at map tile generation time. They're used in the following ways:Waze client (Android at least): BOTHWaze Livemap: Only the placement of city names

You can verify this by checking for the presence of a city name in both the client and livemap, and you'll see they're always rendered in the same spots regardless of zoom.

There's another layer - the one WE call the 'city layer' in the context of WME. That's cities_p, with its own name layer that matches those polygons. It's rendered in multiple colors.

If the above is how this works, and Waze could tell us either way, right?, IMHO, it'd be to our advantage to have cities_p update as often as Waze will do it. Two big reasons:1. The closer to real time this layer is run, the more often we can check the cities layer to see if smears have been resolved or new bogus cities have appeared - particularly if they increase the number of colors and boldness of borders to make them easier to see; and they may be caught/removed before they're ever even seen on the clients. But, especially,2. I'm almost certain that 'The highlighted road is too far from the city it was added to' is dependant on the cities_p layer, not the one we see on the live map tiles. Put another way, if the city polygon layer for WME were run with each edit, we'd never have the 'M, Ohio covers half the state' problem ever again**. In any case, the more often it runs, the less we'll see it. I can happily add a fictitious 'T, California' on two segments, between saves, 150 miles away from one another, so this really leans toward 'It's about that multicolored polygon layer'. To me, it seems Waze doesn't know 'how far too far is' unless there's a polygon to check against.

Notes: * Segments in this newly created city were touched on 11/23, after the newest tile update of 11/22. https://www.waze.com/editor/?zoom=3&lat ... FFTFTTTTFT* Its polygon shape is visible in the multicolor layer, but not in the gray and 'City is here' layers of Livemap or clients, so it's a test case where the city exists in WME but not in the live client.* If I try to add Rosewood a sufficiently far enough distance away from this location, I get the 'too far away' error.* There was a WME map tile update less than 24 hours ago, which I know because another tiny city that had a small footprint got larger overnight based on edits I'd done yesterday.** This is, of course, assuming Waze fixes the 'Too far from city isn't checked against alt streetnames as well as the primary' issue.

yippeekyaa wrote:skbun, what you are saying make sense. In one area I had a "k" city layer. Using WME highlighter tool, i found the offending K named streets and corrected them last week. The K is still showing as being in the area but when I turn on the city option on WME it's not showing as a colored polygon anywhere on the map. But alas, the K is still there.

Is the 'K' in WME, or just in the Waze client? If only in Waze, it'll disappear when the next tile update happens. If you made your changes after Sunday night, you'll have to wait for the next WME city layer update to be sure it's gone.

yippeekyaa wrote:I have a layer incorrectly named "flat rock(2)". I've changed every street to the correct city name yet the flat rock(2) layer still remains.

Remember, it WILL remain until at least the WME polygons update, if you see it in WME. The last pass I know it ran was Sunday evening.

yippeekyaa wrote:I've spent a couple hours scanning for any remaining incorrect city names and none appears to exist. Does the city layer use alternate addresses to determine this layer? someone mentioned that the highlighter can highlight the alternate addresses, yet I can't seem to figure out how exactly that is done. Advice?

I think it may, yes. I don't have authoritative proof, but I 'strongly suspect'. That said...try adding an alt address with 'no city' to any city segment. Doesn't mater which. Then highlight both 'your city', and 'No city' in order. You'll see that if the alt address matches, it'll be a yellow dashed/hashed line, not a solid.

ohiostmusicman wrote:If this is the case, then why is M, Ohio still appearing in the client?

Even though "M" is not showing at this zoom level, that giant kite shape laying waste to the great state of Ohio is the aforementioned "M, Ohio". GizmoGuy and I took care of this by Nov. 19, it no longer appears in the colored WME City layer, and here it is still in the client. And yes, I refreshed the tiles...

Hm. I can't see the M blotch easily on my client, zooming in and out some. What if you completely wipe your cache and data, maybe...?

This isn't completely related to city tiles in WME, but it's something else I noticed while troubleshooting a UR - and, anyway, at least related to the general topic of tile generation.

Is it my imagination, or is the Livemap's functions kind of 'half there', in that if you know two exact points to use on the map, you can use the Livemap to test routes with it - but that the visual appearance of the livemap tiles themselves is weeks out of date? (I worked this out by trial and error by like...moving to points beyond where segment structures had changed and I knew a predictable route should begin, and got this to work.)

I can't tell precisely how far back, but I'm fairly certain it's not showing changes from 'after at least October 13'.