beersh wrote:Since the new version when place is selected and you try to move the map a little dragging move the map to different area dozens of miles away.

Yet another seemingly innocent little tweak in the way the native objects are handled by WME, causing yet another script error...

In this latest version of WME, the extra UI elements (e.g. drag points for adjusting the place outline) shown when you select a place are now added into the W.map.landmarkLayer.features[] array as additional objects - in previous versions of WME, and in this version if no place is currently selected, the array contained ONLY the place objects themselves, and so each entry in the array could be safely be tested for those properties we know are common to all place objects. Now that WME is spewing UI objects into that array as well, attempting to access place properties from a UI object leads to a script error, which in turn leads to the accelerated scrolling bug.

Thanks for the report, this has now been fixed in the development code and should be released "soon"...

Right now on the ROW server, I can't save any changes to places regardless of which scripts are or aren't running, so I can't verify this issue just yet - the server is throwing back a HTTP 500 error with the internal error code 719 and description string "Failed to update details of venue..."

The server seems to be behaving itself again, and place editing appears to be working OK with the development version of URO+ enabled...

PesachZ wrote:

PesachZ wrote:[BUG REPORT]

Please change the link you use (in the pop-up) to open a UR in a new tab/window. The format you are using no longer opens the UR. See complaint in WME thread

Sent using Tapatalk for Android 4.4.2

Disregard, this morning the old link (&showur...&endshow) style is working again, in NA

That's because it was fixed in 3.24

PesachZ wrote:WME natively does not support changing from public to private or vice versa, it will cause a save error.

Public to private is allowed, provided the place has been given a house number.

PesachZ wrote:Converting from area to point and vice versa does work with URO+, but not properly.

From area to point, the area button remains depressed after clicking point until after a save.

From point to area, the point button remains depressed until after a save. Governed it appears to have done nothing because the save counter is not visually incremented and the save button remains faded if there are no other edits. Once you make an unrelated edit, say add a new road (even if you immediately hit undo on that new edit), you'll see the save button fill in, with the proper edit count. You can then save the conversion.

Thanks for the detailed description, I'm pleased to say I'm quite unable to replicate these with the development code, so I suspect they were all being triggered by the same bug that beersh noted previously.

PesachZ wrote: Did you change the link? I'm curious because you're still not using the ...&mapupdaterequest... Style link.

The links are the same, because handling the &showur/&showproblem part of the URL is also done by URO+...

elljay23 wrote:First of all, thanks Twister-UK for your work on this script - it's invaluable.

I clicked the "Open in new WME tab" on 3.24 and a couple of times the new tab has ended up centred on Bloomsbury! Then I noticed that the link has a couple of "NaN"s in it e.g: https://www.waze.com/en-GB/editor/?zoom ... ayers=4071

It happens with for example this place: here. It doesn't seem to matter how far zoomed in or out I am.

Interesting... pretty sure it was working on all the place update markers I checked prior to releasing 3.24, yet all the ones I've checked today are missing the position properties URO+ is looking for to generate the lon/lat data.

Good news is that these markers all have the lon/data data stored as a property already, so it's an easy fix, but a bit concerning that stuff still seems to be changing behind the scenes a bit too frequently for my liking.

Twister-UK wrote:pretty sure it was working on all the place update markers I checked prior to releasing 3.24, yet all the ones I've checked today are missing the position properties URO+ is looking for to generate the lon/lat data.

Mystery resolved... all of the first wave of update markers seemed to be for point places, whereas there are now also markers appearing for area places. Point place markers still have the position properties I was originally using in URO (and also the new properties I'm now using), whereas area place markers have only the new properties.

3.25 fixes the various problems noted above with place editing, and with the place updates popup link not always including lat/lon values. It also provides a "vanilla" permalink in the popups, as requested by PesachZ.

One final addition can also be found about halfway down the Misc tab, as a special treat for those editors who aren't terribly fond of the colour green... enjoy



Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

PesachZ wrote:

Twister-UK wrote:It also provides a "vanilla" permalink in the popups, as requested by PesachZ.

I finally had a chance to glance at the editor, the permalink text doesn't include a UR reference. It's essentially a stripped UR of just the location.

What I was looking for was a permalink which would open the UR on any browser, even if URO+ wasn't installed. Using the " &mapUpdateRequest=0000000" instead of "&showur....&end show". The UR ID is the same.

For example
https://www.waze.com/editor/?zoom=5&lat ... 21&env=usa

Sent using Tapatalk for Android 4.4.2

Ah, gotcha... Dev build now generates native permalinks for URs and standard map problems, however turn problems continue to be handled by URO+ as I can't find a native method for having these opened via a PL.