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

[AlanOfTheBerg]

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.

Perhaps so, but even with panning/zooming, you're hitting a lot of cached data. And all the highlighting is done at the browser level only, once the data is loaded from the server.

[AlanOfTheBerg]

Clear UR (either Solved or Not Identified), zoom all the way out, and the pin disappears... The pins always used to stay until the page was refreshed (F5/Permalink/Refresh/etc)... The pins continue the old behavior in the Beta...

If you have JNF or URO installed, verify this behavior with them disabled. I know JNF hides the "show all connectivity arrows" when they are modified, so perhaps something like URO is also forcing the "closed" URs to be hidden right away too. (In fact, URO has checkboxes for this specifically.)

[AlanOfTheBerg]

While I agree that there is not a common city, the street name is the same on each segment; there IS a common street.

This is an instance of database vs. common use conflict. To us, it seems a commonality, but to Waze it is not. This is where the database street object as contrasted against the segment object comes into play. Every segment on the Waze map has an associated Primary Street ID. The Street objects are parents of all segment objects. The segment "inherits" it's name and city (and state, country) from the parent street object. Therefore, when you have selected two segments which differ only by city name, then to Waze's way of thinking (from the database POV), they do not share a common Street, which means they are not similar enough to for Waze to want to allow you to edit their information separately.

What is needed is perhaps some changing of the wording in the editor to be more clear on why the fields are being blanked out, or find out if there is some more coding which can be done to allow manipulation of the fields values which are common to both.

[AlanOfTheBerg]

...
"mouse-over shows the roads" data is vectorial data retrieved as json from waze.com/descartes/features. If this fails, you'll get roads images but none will be selectable. And no radars, no problems, none of those.
...

Hm... interesting point that I didn't bring up is that the WME color highlight extension DOES work.

That implies to me that WME could be made more efficient by dispensing entirely with the ROAD images and just using a method similar to the way the WME color highlight extension works.

That could dispense with the need for a LOT network traffic.

It would be quite heavy on the browser to draw all segments, including the direction arrows, and more importantly the road names and their position on the segment and the angle in vectorial mode. Not impossible though. It's still easier and cheaper to do it once on the server side.

The browser essentially does this now, though it doesn't actually produce the images for the visible road layer. But every road object is loaded from the server which allows us to manipulate that object. The browser is tracking it, panning it, zooming it, etc., with every movement of the map.

I would think we are closer to having the visible road layer rendered completely in the browser that we think. At least, I hope so!

[AlanOfTheBerg]

If we're speaking of graphically drawing things out, the browser is already doing this. The server just sends the raw data about the objects (coordinates, basically), then the browser renders everything through SVG data. The selectable road object is actually separate from the road that you see. It is an invisible vector object that gets manipulated as you select it or hover over it.
Because all objects are essentially data, and not graphics, we can create nifty add-ons, like timbones' color hightlights script, that can manipulate segments.
The only graphics that the server servers up is the Bing imagery, which comes from Bing servers, so it doesn't present an additional load on the Waze servers.

We are saying the same thing I think. What we see visually for the road layer, is a png, aligned with the actual SVG layer. What I'd like to see is the SVG layer only to be loaded, and have the browser draw the actual visible layer too.

In terms of the browser save causing a tile refresh, that is a capability of the current infrastructure and was one of the major features of the upgrade the US got a few months ago, and the World got this past week.

However, we do not want it to happen this quickly, at least, not so the app can download it right away or by default. Can you imagine a tile being saved 20 times in 5 minutes and the app downloading the tile 20 times? That would crush both the infrastrucutre network bandwidth and kill our data plan limits. It may be able to do that, but before we do, we need better, more restrictive default app tile download behavior.

[AlanOfTheBerg]

the app doesn't even update a tile until you route over it so it's pretty moot.

1/2 true. There is also a date associated with tiles and the app is supposed to download nearby tiles even when not routing if they have "expired."

[AlanOfTheBerg]

It's also possible that this new behavior is unique Int'l editor then. We've had the new infrastructure in place for several months. iainhouse, are you also using Firefox, or something else?

It's not unique to the int'l editor. I've seen this behavior for a couple days on the NA server.

I've been trying to nail down whether it's a userscript or not, too. Or related to the landmarks layer issues. A permalink usually fixes things a while, but it comes back. Turn off extensions seemed to clear it up, but then after 30 minutes of having the same extensions enabled, I haven't had the issue again.

Very elusive...

[AlanOfTheBerg]

I've been trying to nail down whether it's a userscript or not, too. Or related to the landmarks layer issues. A permalink usually fixes things a while, but it comes back. Turn off extensions seemed to clear it up, but then after 30 minutes of having the same extensions enabled, I haven't had the issue again.

Very elusive...

I've said before, for me it has nothing to do with scripts, only see it on Firefox not on Safari (yet), and happens when zooming in and the road reload happens, and I've seen it only today (which means it may be a couple of days, didn't spend much time editing yesterday)[/quote]
It's happening to me on Chrome/Win7.

[AlanOfTheBerg]

(...)I think it's happening only on Firefox(...)

[18:52:28.697] TypeError: wazeModel.cities.get(cityID) is undefined @ https://world.waze.com/editor/:105
--
[18:52:34.415] TypeError: e is undefined @ https://world.waze.com/editor/js/WME.min.js?v=785:1
[18:52:34.420] Empty string passed to getElementById(). @ https://world.waze.com/editor/js/libs.min.js?v=785:2
[18:52:34.696] TypeError: wazeModel.cities.get(cityID) is undefined @ https://world.waze.com/editor/:105

Just happened on Safari:



2wmech.js:134TypeError: 'undefined' is not an object (evaluating 'wazeModel.cities.get(cityID).isEmpty')
51The page at https://world.waze.com/editor/ displayed insecure content from http://www.bing.com/maps/i/spacer.gif.
6wmech.js:134TypeError: 'undefined' is not an object (evaluating 'wazeModel.cities.get(cityID).isEmpty')

Ok, that's very interesting and aligns with what I see when this happens from this angle:

I add a landmark and then, to set the landmark to the right city, I try clicking on a segment nearby to get the city name. But it just highlights blue but doesn't actually select it. So, I decide to go with my gut. I click on the landmark again and go to edit the city name, but I am shown an empty Country, State and city control. The select control for Country should have United States and State should show at least my local state, but they are both empty.

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.

[AlanOfTheBerg]

I think I found another bug... In the layers menu, you can move a few of the layers around, so they are on top of each other in a specific order... The layer at the top of the list is actually below the other layers and the layer at the bottom of the list is on the top of all the layers.

Design, and it is consistent with the rest of the layers menu. It isn't first glance logical however.

Always check that awesome documentation. http://www.waze.com/wiki/index.php/Map_ ... ols#Layers.

One clear indication of the expected order is that the Bing Aerials layer appears at the top of the layers menu.