qwaletee wrote:

doctorkb wrote:If you want a reason that really impacts you, then let's say the more geonodes on the screen, the more intensive it is for TB or WMECH to provide highlights in the editor.

I mention this one specifically, because I remember a thread where someone had spoken to Dev, and claimed that Waze said not to worry about it.

And, TO THEM, it may not matter.
The datapoint for the geonode must be stored on the server, so it absolutely takes up space, but that is not an impact on the efficiency of the server (in any significant way).
Rendering, once the tiles have been loaded, they are loaded. "Smoothing" eliminates the majority of geonodes from the app. Again, no significant impact on operation.
Routing, the routing server is simply looking at transit speed/time from endpoint to endpoint as well as junction entry/exit. Geonodes have ZERO impact on the routing server efficiency. The only impact is forced turn instructions produced using micro-doglegs.


*BUT*

The Devs are not editors. Oh, some may do some editing, but I can't imagine one being a very active editor in their spare time when they already spend 10-12 hours a day actually working for Waze.
So no... Geonodes have no impact from a typical Dev's perspective, but that doesn't mean that they have no impact at all.

doctorkb wrote:

qwaletee wrote:

doctorkb wrote:If you want a reason that really impacts you, then let's say the more geonodes on the screen, the more intensive it is for TB or WMECH to provide highlights in the editor.

I mention this one specifically, because I remember a thread where someone had spoken to Dev, and claimed that Waze said not to worry about it.

I'm suspecting you misquoted. Because I will tell you that the highlighting portions of the editor scripts will certainly have to work harder in your browser if there are more geonodes.

This was quoted properly as I recall the statement.
As I said in my post just above, from a Waze dev's perspective, it's not a problem.

It may not be a problem for Waze, but it is a problem for editors (and script authors)

doctorkb wrote:

taco909 wrote: This was quoted properly as I recall the statement.
As I said in my post just above, from a Waze dev's perspective, it's not a problem.

It may not be a problem for Waze, but it is a problem for editors (and script authors)

Well, not as much authors -- we have libraries to take care of it, so it's more just those who use our scripts.

Except that you get to listen to us complain when your script causes WME to lag

KuniaKid wrote:Since WME awards 1 edit per segment touched, instead of total actual edits, can we have simplified segments back?

Ditto.

Probably the most common use for me personally is when cleaning up "bbq" parking lots created by newbies.
Deleting the extra junctions is still there and works, but then the geonodes have to be cleaned up.

steveinark wrote:happily with the restriction to select only ONE segment at a time, was very helpful.

Or even multiple segments... but only selected segments, not all segments on the screen.

But if we can get it back only for a single selected segment, I'd be happy.

The simplify segment tool could easily be a one-segment-only thing and I'd be okay with it. Due to the lack of need for it ever to be used, it's just one of those tools that comes in handy when you're messing with a particular segment. Much like 'clear all geometry', except smart enough to save you a few nodes instead of killing them all, therefore resulting in a slight amount of time saved over the 'clear all geometry' tool.

I'm fine adding the additional restriction of one-segment-only instead of selected segments allowing you to do multiple at once. The multiple selection thing is too easily gotten around as far as an actual limitation.

I also think the screenwide tool is useless. It doesn't do anything for the map, or the editor. It just raises edit count and hardens soft turns. It should never be used. Frankly I think toolbox should remove it, period.

I'm not sure if single/multiple is even configurable in the first place, but if it is, I'd rather multiple be restricted to the higher levels like CM or 5.

Selecting every segment on the screen is pretty easy to do, so edit farming is still possible quite easily. And I wouldn't even care if it didn't do more damage than good (hardening soft turns that haven't been examined closely, basically.)

I love the warning idea, even the best of editors might overlook something and a prompt would be quite handy.

However, select in area isn't the only way to mass select segments quickly. =P

BellHouse wrote:

Thortok2000 wrote:And I wouldn't even care if it didn't do more damage than good (hardening soft turns that haven't been examined closely, basically.)

What does happen is that previously unedited basemap segments ("Last update: admin(staff)") are edited after a geometry node removal, resulting in these segments losing their ability to auto-adjust driving direction from actual drives. From the next release on, the simplify tool will therefore skip unedited basemap segments.

This may just be a semantics thing, because exactly what you just said, I have also heard referred to as 'hardening' the soft turns. It loses the ability to automatically adjust direction or turn restrictions based on drives, and if those directions or turn restrictions haven't been adjusted and confirmed for accuracy, they are now 'hardened' or locked in until manually edited in the future.

As far as the simplify tool simply ignoring segments in which this result would occur, I like that even better than the warning. Or some combination: After you run the tool, a popup says 'these segments must be confirmed before they can be simplified' and the selection changes to those segments which were not simplified and need examining.

You still have the edit farming issue and the mass edit issue, but if such a function were coded in, I wouldn't care if the screen-wide tool was available to AM's and above at that point, or at least CM's and above.

Still, it's not like it actually helps in 99% of situations anyway, so it's not like the loss of the tool is really a big thing. The amount of data saved by it is infinitesimal.

Throwing in my hat for wanting suppress unneeded junctions back.