Map Editor major ver (Nov 5, 2012) Official Feedback

The place to get information and ask questions about everything to do with properly and successfully editing the Waze Map.

Use this forum for all general editing questions, and the sub-forums for specific types of Waze Map Editor features.

Moderators: Unholy, bextein

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Wed Nov 14, 2012 9:39 pm

douglasr007 wrote:I'm glad I'm not the only one who has problems with selecting road segments on the WME. The only way to "fix" it is to deselect the road segment, zoom all of the out, and zoom all of the way back in to the section you're editing and hope the segment can be changed when you select it again.

Also, I thought it was a conflict with WME Color Highlights script but it's definitely the server causing these issues.


Try this, because it doesn't seem to help whether landmarks in view have names or even addresses: just turn your landmark layer off and work like that.

I'm betting it'll be fine, until they fix this on their end. It doesn't seem to help whether landmarks in view have names or even addresses, which means that's a red herring, so there's really nothing we can do.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Wed Nov 14, 2012 9:16 pm

Yeah, okay, nailed it. Here's the deal.

THIS Permalink (don't move, just zoom in and out), will generate exceptions.
https://www.waze.com/editor/?zoom=5&lat ... FFTFTTTTFT

THIS one (again, just zoom in and out), won't.
https://www.waze.com/editor/?zoom=5&lat ... FFTFTTTTFT

It's the same location, but in the one where the exception is thrown, the landmarks layer is turned on.

When Waze enabled addresses for landmarks a week or so back:
* All landmarks by default appear to have a cityID of (null).
* When the landmarks layer is turned on, landmarks are polled for their cityIDs.
* There is no error checking for the condition in which (null) is the city ID (it really should be ignored), so an error happens, and now you have to re-zoom, or reload the page to edit.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Wed Nov 14, 2012 8:53 pm

AlanOfTheBerg wrote:For some reason, the browser data seems to be getting corrupted and it can't figure out where the view on the map is located? :? Weird.


Okay, I can make this happen completely predictably, now. It's a slightly different error, but I'll bet money the two are related -- and the result (segments don't load) is exactly the same.

Go to this Permalink:
https://www.waze.com/editor/?zoom=10&la ... FFTFTTTTFT

Now. Zoom out one click at a time, not moving where you're centered. When you get to the second to last out, you will get:
Code: Select all
Uncaught TypeError: Cannot read property 'countryID' of undefined
Waze.Control.Chat.OpenLayers.Class.getTopCity WME.min.js:1
Waze.Control.Chat.OpenLayers.Class.onMergeEnd WME.min.js:1
OpenLayers.Events.OpenLayers.Class.triggerEvent OL.min.js:1
Waze.DataModel.OpenLayers.Class.mergeObjects WME.min.js:1
Waze.Controller.OpenLayers.Class.onFeatureRead WME.min.js:1
Waze.Protocol.OpenLayers.Class.handleRead WME.min.js:1
(anonymous function) OL.min.js:1
(anonymous function) OL.min.js:1
OpenLayers.Request.runCallbacks OL.min.js:1
f.onreadystatechange OL.min.js:1
c.dispatchEvent OL.min.js:1
b OL.min.js:1
_object.onreadystatechange


You won't be able to select MUCH this zoomed out, but click one of the Trans-Canada highway segments. Ta-da! Blown. Now...you can zoom IN, and it'll work again, because it'll poll for features and country, and will figure it out again.

It's like a bounds problem. When it gets far enough out that there are two countries in view, and it can't decide which is the right one, it doesn't 'pick one of the two', say; it just barfs out.

Although I can't prove it yet, I'd lay money on that the same kind of 'undefined' error happens near state borders, and near city borders, at respectively lower zooms. If I find an example, I'll follow up with it.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Thu Nov 08, 2012 6:56 pm

wroadd wrote:As I see there was a change in the WME, new fields are available for gas stations(and ny othre landmarks) for country (state) and city


In all seriousness, I've been trying to come up with methodologies to deal with city smudges recently, and it's really dang hard to do. At this point, I really wish there were ways to identify a numerical CityID, and just have it spit out 'all segments and lat/long of one of its connected nodes' at me, so I can get rid of the dang things. At this point, it'd surely be less taxing on the database server than having to scroll around, zooming in and out, querying thousands of segments with the highlighting script -- and even then not finding it. ;)
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Thu Nov 08, 2012 6:20 pm

AlanOfTheBerg wrote:
AndyPoms wrote:
wroadd wrote:As I see there was a change in the WME, new fields are available for gas stations(and ny othre landmarks) for country (state) and city
Can you select a country? There is nothing in that dropdown here in the US...

I show United States for landmarks where I was just editing.


Oh, geez almighty. Looks like I get to fudge with the highlighting script again and add landmarks to city highlighting. ;)
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Wed Nov 07, 2012 1:12 am

bgodette wrote:
skbun wrote:http://www.waze.com/wiki/index.php/Map_Editor_Interface_and_Controls#Segment_Edit_Detail:

An alternate name street must also have the same city as the primary segment. (My emphasis added)
So there's no Street anywhere in the world that belongs to two cities or a city with two official names. Somehow I doubt that.

The automatic default for an alternate street's city *should* be the same as the primary street ID, but there definitely should be the ability to change it.


Well, if that's what's decided, then any segment's alt streets should get the same error checking that primary streets do, before a save. Right now, I can change any alt street to any city in the state it's in, no matter how far away, and Waze won't bat an eye, and I'm pretty sure it doesn't check CityIDs against states, in the case of smudged cities, either. Whether 'One segment, one city' or 'One segment, multiple cities' is decided, IMHO, some error checking badly needs to be added on the WME internals side.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: City names in alt names not checked at save

Postby skbun » Tue Nov 06, 2012 8:53 pm

AlanOfTheBerg wrote:
skbun wrote:An alternate name street must also have the same city as the primary segment. (My emphasis added)

This may be a best practice, but it's not enforced by WME. Here's some bullet points of what's possible.

Yes, there are lots of things which we have as guidelines/best practices which the editor does not enforce. This is one of them.


Agh, I realize how this might have sounded now, as you were the one who wrote that portion of the Wiki! Trust me when I say, sorry! :oops:

I agree wholeheartedly with you that primary and alt must match is the way to go. I'm pointing out the details to Waze so it could be fixed, because this mismatch problem can be really hard to find with our existing tools, and it -does- cause real problems we have to edit out.

I'm pretty sure, to Waze, It wouldn't really be that hard, either. At 'Apply' time on the Edit Segment dialog, force the CityID of any alt name to be the same as the primary, regardless of what the user did in the meantime. Simple as that?
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

City names in alt names not checked at save

Postby skbun » Tue Nov 06, 2012 8:20 pm

http://www.waze.com/wiki/index.php/Map_Editor_Interface_and_Controls#Segment_Edit_Detail:

An alternate name street must also have the same city as the primary segment. (My emphasis added)

This may be a best practice, but it's not enforced by WME. Here's some bullet points of what's possible:

(When you click a segment, it has either a City (CityID) or (None), and a state as its primary, as we know.)
* If the primary segment has 'None' for a city, clicking 'alternate name' will put in a City field with 'None' checked, but you can uncheck it. This means alt can have a city even if the primary does not.
* If the box is unchecked, the suggested added city is the same as the primary segment, but the field is editable. You can change it to anything you like, including:
- A city name that doesn't exist in your state, which creates a new CityID (includes misspells)
- A city way way far away from where you are - a condition that's caught by checking the primary segment, but alt segments aren't checked (i.e, I could add an alt segment in Grand Coulee, WA to one in Burien, WA, and confirmed it has the same CityID with Timbones's highlight script)

Implicitly, the state and country of the segment you are working on is added to the alt text when you add that alt text. I suspect that if you live in an area where an irrational state or country is present (smudging), and add an alt text with that bad default in place, you'll add a city/state/country matching that bad data in the alt. You then MAY get an error when you try to save (primary segment is checked of course), but I'd bet money the alt text still has the bad CityID even if you fix the primary and save.

Research shows me that Timbones's highlighting script knows to 'get cities' with bad alt text, because it's a general 'show me all the cities in this area' query. However, it does not check alt properties, so if an alt text is smudging a city/state/country, that tool can't find it.

On that subject, there already exist segments with these properties; have a look at https://www.waze.com/editor/?zoom=6&lat=47.47196&lon=-122.31685&layers=BTTFFTTTFTTFTFFTFTTTTFT&segments=54594585, segment 54594585.

Primary: Des Moines Way S, Burien, Washington, United States
Alt: Des Moines Memorial Dr, SeaTac
Alt2: Des Moines Way S, SeaTac

Since this was created in 2009 and last edited in February 2012, I must presume that this kind of 'bad city/state/country alt bounds checking' existed in Cartouche as it does here. We may need to be checking alt segment city, state, and country names for smudging, and I'm not even sure how we can do that at this point. Can Waze Colour Highlighting and WME Extended Tools be modified to check for these things?

Well, the thrust of this whole huge paragraph is, the javascript making alt street names in the first place has to lock down city to match exactly what the primary segment has. If the CityIDs don't match at save time, error out. We've got countless mismatches already, but now that we're down to one editor, at least we can stop more of them from showing up! Once that bounds checking is in place, It may also be worth Waze scrubbing all segments to make any alt CityID match the primary in that segment. It would save us countless hours of work.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: Map Editor major ver (Nov 5, 2012) Official Feedback

Postby skbun » Tue Nov 06, 2012 12:35 am

AlanOfTheBerg wrote:Also, the primary name is used for shield creation, but alternate names can hold a local name if the route name is the most popular local name.


It would really be nice if the behaviour was that primary AND alt names should be scanned for something that generates a shield; and that basically, 'most popular local name' IS the primary -- because that's invariably what's on street signs for turn by turn directions.

In almost all cases in my local area, you will see (for example) 'Main St' on all intersection signage on state routes - thus that's what really needs to be said by TTS navigation directions, but you will also see the occasional 'SR-500' shield. In a case like that, you really need to have 'Main St' as the primary, and the SR as an alt.

So far as that goes, in pretty much any city, a state or US highway will tend to have a 'City name' inside a city, and will only be referred to as 'US-41' as primary in rural areas.

See https://www.waze.com/editor/?zoom=7&lat ... s=63218443 for an example of what I'm talking about.
Image

AM in SW Shasta, NW Tehama, Central Trinity Counties, CA; Mt Rainier Nat'l Park, WA
skbun
 
Posts: 850
Joined: Sun May 06, 2012 12:27 am
Location: Seattle/Tacoma WA
Has thanked: 27 times
Been thanked: 48 times

Re: WME major version released to production

Postby sjthespian » Tue Nov 06, 2012 4:29 pm

AlanOfTheBerg wrote:
sjthespian wrote:If I select an problem report that has a route and GPS trace then zoom the map, the directional arrows go away on the route and trace. The only way I have found to get them back is to close and reopen the report.

If you zoom out to a certain level, they have always disappeared (zoom level 4). But they do reappear for me when zooming back in (Chrome/Win7). If you can confirm they positively do not appear when zoomed in to level 5 or higher?


Odd, today they reappear when I zoom back in, yesterday they wouldn't reappear until I closed and reopened the report.
sjthespian
 
Posts: 5
Joined: Mon Nov 30, 2009 7:46 pm
Has thanked: 0 time
Been thanked: 0 time

PreviousNext

Return to Waze Map Editor

Who is online

Users browsing this forum: AlObaili, jm6087