PesachZ wrote:Again, this isn't my decision, but I may be able to offer an explanation. Up until now the toolbox developer team had the sole responsibility of setting permissions. They would add and remove features as they saw fit based on community feedback. With that strategy this is just another example of a tool being removed based on community feedback. However they are now offering the opportunity for any country to override the default settings via the TbCC.

Ok, I understand what you're saying, and agree that it makes a certain amount of sense.

The process for deciding on a TbCC is delineated in the first posts above starting this thread. The champs of the country will nominate a single coordinator for that country, and notify the toolbox team who that coordinator is.

I have an issue with a small(ish), closed group of people making that decision without any input from the community, or at least editors that are at SM status or higher. And no, not just because I'm a SM who would like to be involved in that discussion.

Issues/concerns that I have with this:

• What is the procedure that said coordinator should follow for turning on/off various functions based on whatever?
• What happens if a "bad" choice is made and we end up with someone who over-restricts a tool based on their own personal opinion and/or agenda as to who should be able to use it?
  • Is there a procedure in place for removing such a person in such a case and replacing them with another one?
• Why was this version pushed out when the TbCC for each country that wants to have one hasn't yet even been chosen?
• Why would the default value for something as useful as the segment simplify tool, especially in light of Waze's desire to have excess geometry nodes reduced whenever possible, be off rather than on?

Maybe you don't have the answer to any of the above... but I'd sure like to see an answer from someone who does.

[...Frodo-p's suggestion...]That could be a valid compromise, keeping the country permissions conversation in the scripts forum but individual threads.
The name don't even need the version number it could be:
[Script] WME Toolbox Permissions USA
[Script] WME Toolbox Permissions MX or MEXICO
[Script] WME Toolbox Permissions UK
[Script] WME Toolbox Permissions CANADA

This, I like. That way, at least it's kept here in the Addons forum, where it's easier to find.

PesachZ wrote:Speculation: This tool alone has been the topic of several heated debates and occupies many pages of the TB thread. It is controversial by anyone measure. Whether it's benefits outweigh it's disadvantages is up to debate. I can understand why the team wants to eat their hands of it, and let each country choose for itself.

I think you meant "wash their hands..."

They restricted the mass editing part of it to R5+, and I believe that you have to be a R3 and/or AM in order to use the tedious "click on each segment, simplify, repeat," function, so it seems to me that the potential for damage has been mitigated very well at this point, and I would thus advocate that its benefits far outweigh any possible disadvantages to it. Waze has stated that geonodes take up database space and affect rendering in the app, etc., and that they'd like them kept to a minimum necessary to show the roads correctly (at least, that's what I've seen mentioned, since I don't have direct access to them - so I can only go based on what I've seen stated here). That's what caused that particular tool to come into existence in the first place. Otherwise, the way of doing it pretty much consists of:

1. Select road segment
2. Hover mouse over desired geonode
3. Press "d" to delete it
4. Save, see if highlighting clears or Validator still complains about segment simplification based on Tb highlight
   1. If clear, you're done with the segment
   2. If not, repeat steps 1-3

Repeat again as needed for every other segment being highlighted by that Tb layer.

I can pretty much guarantee you that without the tool, interest by the vast majority of editors (at least, those who are aware of the situation and are making an effort to do something about it as they work on other things in an area) to do anything about reducing excessive geonodes will drop to just about 0%.

I've seen statements made by certain editors in WME chat that "back in the day," they did whole swaths of map that way, the gist of which was that this somehow made them "real editors." That's great, and it's good that they were able to accomplish so much without such tools. "Back in the day," we used to have to rub sticks together to make fire. Then someone came along and invented matches and lighters. Tools to make your work easier are not a bad thing, and using them doesn't make you any less of a "real" editor. So I hope that if "those that are deciding these things" actually want to help Waze out with that stated desire, that they make the tool available again, even if restricted as it has been previously.

-+-+-+-+-+-+-+-+-+-+-

One suggestion that I would make regarding this whole "permissions set by country," etc., thing is that if a tool is going to be unavailable to a given editor (based on whatever criteria in whatever country), to remove the check for that item from the Toolbox Highlight Layers menu. There's really no point in highlighting a problem if the tool that can be used to fix it isn't going to be available to that editor. Yes, I realize that an editor can just turn that check off, but it really serves no purpose to even have the check available if the editor in question can't do anything about it because the corresponding tool is unavailable to them (whichever tool that is).

driving79 wrote:

SuperDave1426 wrote:Waze has stated that geonodes take up database space and affect rendering in the app, etc., and that they'd like them kept to a minimum necessary to show the roads correctly (at least, that's what I've seen mentioned, since I don't have direct access to them - so I can only go based on what I've seen stated here).

Waze has NOT said that, in fact they said the opposite when they were asked. I'm not sure where you're getting that info from, but it is not correct. Some editors have speculated that it makes logical sense it might, but waze said no.

Waze said no to what, specifically? That it affects the app? That it affects database size? That they'd like to keep geometry nodes limited to that which are needed and not a lot of extra ones? All of the above?

PesachZ already stated that it doesn't have an affect on the app, which I accept, but also stated that the number of geonodes does affect the database size. Which makes sense, since such things are in fact a point of data being stored - and in a database, data does require a bit of storage to, well, store.

Please be specific as to what it was that Waze was asked, that they said "no" to. I'm not being obtuse, I just want to understand clearly what you're referring to. Thanks.

HavanaDay wrote:As a strong opponent of simseg I thought this had died down. It appears now that it has been removed as the default which is a little surprising to me. Not complaining, BTW, just surprised. I was the one who asked about geonodes and their affect. I will not tell you who the replier out of respect was (they can chime in here if they want) but it was from Waze HQ

Fair enough, on that last part.

One thing I noticed just today is that PesachZ stated that in that spreadsheet linked to in the first post of this thread, that the default options settings are in a "Default" tab. I looked there, and while there's the simseg highlight entry, there isn't one at all for the simseg tool (even one with all the checkboxes turned off (empty)). I don't know if that was an omission, or if it means that the tool has been removed completely from Tb. If the latter, then I renew my suggestion to remove the highlighting of them, since there's no point in calling attention to it if you can't have the tool to fix it. Regardless of that, I'll probably just end up turning the check off so that I'm not being frustrated by having something pointed out that I'm not going to be able to fix. No, I have no interest at all in clicking individual segments and deleting geonodes one at a time. I have only a certain amount of time available to me to edit the map, and if I were doing that, I'd have no time to actually make more important edits.

As bart99gt mentioned in his post, it's easy to make a mistake and delete too much via that method (yes, you can undo). Along the lines of the other thing he mentioned, there are still huge swaths of Nevada where it's still basemap with tons of extraneous geonodes, unknown directions, incorrect turn restrictions and so on. Most of which are in extremely rural areas, which makes them a low priority to fix, but I still try to go through those places every now and then. Having the tool helped to really streamline the process (at least as regards to the geonodes part) and use what time I have efficiently. It's not being a "button pusher" - it's being an editor who uses a tool to help a process be more efficient. The two are not mutually exclusive.

I also don't rub sticks together when I need to start a fire; I use a match (also a tool).

My question was (Direct quote):
This is in regards to geometry nodes. How do geometry nodes affect the performance of A) the editor B) the app C) the servers. I guess what I am asking is their a noticeable difference if a segment has say 20 geometry nodes compared to 10 in any of the above.

Their answer was A) No B) No and C) No. This is not a direct quote. So you will either have to take my word that was said or draw your own conclusions. Now as driving has said some debated the validity of those statements which I get but this was there answer.

You haven't given me any reason to think you would lie about it, regardless of your personal feelings on the matter, so I'll accept that at face value for now.

It's kind of counter-intuitive that they said "no" regarding any type of server impact, though. I'm by no means a database expert, but I've worked with them enough to know that when you store data, it takes space up in the database. Geonodes are data points, and thus need to be stored. Ten million of them are going to take up more space to store than 100. It's simple physics.

But if what they're saying is that it's not something that we need to worry about, then cool, I'll stop worrying about it. I only became concerned (ok, maybe "obsessed" is a better word ) on the matter when it was posted somewhere here in the forums (not in the TB thread, specifically) quite a while ago that we should try to minimize the amount of geometry nodes for reasons of database, etc. Since, from my understanding of what you're saying here, that's not something we need to concern ourselves with, I'll just turn off the highlighting for that particular issue and no longer concern myself with it, and I don't like to have it bugging me about a non-issue.

Personally, I will give you my two cents. Using the statement above, I think it is a pretty useless tool and just can be used for quick edits and to easily lead to careless edits that could effect a multitude of issues. We had several examples at the time this was brought up where it got rid of some micro doglegs and destroyed routing. This also was from L4+ editors if my memory serves me correct. Plus it did (and still does?) confirm turns (whether they are restricted or not).

Maybe that was an earlier version of it? I didn't start using it right away; wasn't aware of it at first. But in my experience with using it, it's done neither of those things - I haven't seen it either confirm unconfirmed turns nor have I seen it remove micro-doglegs. While I might miss the unconfirmed turns, I use micro-doglegs a lot for routing purposes and would pretty quickly notice if simseg was removing them. Maybe I've just been lucky?

So in my opinion I still think it is a detrimental tool to have in an editors arsenal. As you probably know SD (not to you specifically), I have said it several times in WME chat and various other places, you can be an editor or be a button pusher. I also am not here to down talk Toolbox as much as just this particular tool.

With regards to not knowing about the discussion. I am not sure there was an actual decision that was made to remove it. The last I heard on the subject matter was that it was to remain in. As far as I know we may have been the only dissenting opinion on this particular tool so that the developers took it out, out of caution for the US. I will say I made it pretty clear in my region what was and wasn't acceptable.

I was surprised by its disappearance, too, which was why I had asked here. Last I heard was that even though there were people like yourself and (I believe) Txemt who were opposed to the tool, that it was going to be allowed to remain as it had been. So it was a surprise when it disappeared, with no notice whatsoever, from this version.

Last time I checked, the RC for the region that I do my editing in didn't/doesn't have a problem with using the tool. If he did, I would have stopped using it then out of respect for his wishes (I'm a big believer in while being free to express my opinion on something and being willing to debate a point that I disagree with, my actions in the area(s) I edit/manage will be in accordance with the preferences of the RC for that region).

But if it's your assertion that Waze actually doesn't care, based on your earlier conversation with them, about the amount of data being stored for geonodes and so on, then it's a moot point and I'll no longer concern myself with it either. Like I said earlier, I was only concerned with it because I thought that Waze had expressed a desire to keep geonode counts down when possible. If that's not the case, then I can better spend my time with other issues.

Edit: To fix a typo.

BellHouse wrote:

Fredo-p wrote:Also, as SuperDave mentioned, can we keep the scripts convo to the scripts thread? I think it would be easier to use country code in the beginning. Like this:

[Script] WME Toolbox (1.6.0) USA
[Script] WME Toolbox (1.6.0) MX or MEXICO
[Script] WME Toolbox (1.6.0) UK
[Script] WME Toolbox (1.6.0) CANADA

I think that's a really good idea. But, I think these threads should be in a separate forum within the Scripts forum (to easier find them). I'll challenge the forum admins on that one.

PesachZ actually came up with a better name suggestion (at least, IMO) for the topics/threads here within the Addons/Scripts forum:

PesachZ wrote: That could be a valid compromise, keeping the country permissions conversation in the scripts forum but individual threads.
The name don't even need the version number it could be:
[Script] WME Toolbox Permissions USA
[Script] WME Toolbox Permissions MX or MEXICO
[Script] WME Toolbox Permissions UK
[Script] WME Toolbox Permissions CANADA

HavanaDay wrote:

I also don't rub sticks together when I need to start a fire; I use a match (also a tool).

And it is a lot easier to burn a house down with a match then with sticks. Just takes longer with sticks. But I digress.

And yet we haven't outlawed matches just because someone might do something stupid with them....

Last time I checked, the RC for the region that I do my editing in didn't/doesn't have a problem with using the tool. If he did, I would have stopped using it then out of respect for his wishes (I'm a big believer in while being free to express my opinion on something and being willing to debate a point that I disagree with, my actions in the area(s) I edit/manage will be in accordance with the preferences for the RC of that region).

That is a perfectly acceptable answer. Which was basically the choice I was given and the actions I took. There are way to many debatable points to be listed here in a post regarding the general release of Toolbox. Perhaps another discussion.

Agreed.

PesachZ wrote: Well said, in simple terms; additional nodes obviously must increase storage to some extent. But we have been assured it doesn't negatively affect performance of the server, WME, or the client. Staff is not overly concerned about it either, so neither should we be.

Take home message,
1) don't go around just creating a million extra geometry nodes for fun, it's wasted effort since they will be simplified before going to the client regardless.
2) don't spend lots of time simplifying existing nodes, do something more important, there are automated processes in place to handle these geometry nodes. Your time is much better spent fixing issues, responding to URs, PURs, etc.

Agreed. And now that I understand that geonode count isn't the impact that I thought it was based on earlier comments made months ago, I'm not going to sweat them anymore, nor will you see me here complaining about the lack of a simplify segment tool. I've turned of Tb's highlighting of simplifiable segments, since I see no point in being alerted about something that's a non-issue.

Thanks to those who took the time to provide the additional information!

taco909 wrote:I agree with you Steve, but this is something to impress upon your RC so those feelings can be forwarded to the US TbCC.

Has such a person been decided on yet for the US?

BaerGrizzling wrote:[...]If you don't have such a domain yet, I would offer to donate a subdomain of one of my domains ...

Which would then effectively give you access to anything stored there, including being able to make unauthorized changes to that spreadsheet?

I'm not saying you would do something like that, but there's no way they (TB author/maintainers) would do that. It would be nice if they could narrow down the access to something like docs.google.com, but the problem is that when you try to access something like that, Google redirects you to http://www.google.com/{blah}/docs. So that's not something they can do.

Not sure there's an easy solution here, other than to maybe recommend that they just go back to hard-coding the stuff for permalinks and all that back into the addon - which would mean that even for a minor change to the table, they'd have to push out a new version of the addon. It's a tradeoff, for sure....

This may have already been suggested here, but it case it hasn't, I figured I'd mention it.

Now that we have speed limits on roads, is there a way that an additional highlighting check could be added for "Roads with no speed limit data" or something like that?

We've currently got a checkbox for "Roads with house numbers" and for "Roads with names but no house numbers" - I was thinking of something along those lines. Some roads (like PLRs) don't have a place to enter speed limit data, so those would need to not trigger the highlight, of course.

But I think it would be really useful to have a way to have non-speedlimit-data road show up easily.