Your script/github link returns a 404.
Correction: To delete /and/ select & deselect all ways.
Sorry, but I’m still not convinced displaying relations by default is user friendly. To delete them a way has to be selected first.
joost could you expand on your points. I’m struggling ot notice a difference.
I’ve tried getting used to relation tags being displayed as the default, but I still find it inconvenient, especially when checking for MPs tagged the ‘old’ way, ironically.
I understand how relations should be tagged. I’ve been doing it that way for years, which is why I’m surprised to hear the technique now described as ‘new’.
However, as with all relations, the tagging is usually an initial edit & only occasionally requires amending. I believe contributors will more likely want to check the polygon ways for (in)correct tags (valid tags can still be added to individual polygons), and to ensure the role is correct.
I look forward to the other improvements you mention.
Similar to @metatech I had problems with some shortcuts. For me ‘H’ history only worked on polygons, but it appears to have sorted itself. I’ll keep a check on it.
Simialr to @sulagaloh I’d prefer the way of a relation to be displayed as the default. I don’t think contributors need to amend relation tags that often. (A primary purpose of relations was to reduce tag editing)
I’m sorry to say I’m finding the Shift-drag to zoom irritating. Shift-selecting a way to insert a node in P2 is quite finickity. I find I often miss on the first click & it defaults to the window-zoom.
How many use this new way to zoom? I’m finding Left-click-pan & mouse wheel zoom more convenient. Zoom window is a hangover from AutoCAD in the nineties. Could an option to turn if off be added?
Thanks for implementing the non loading of data, but I’d be happy for it to kick in at level 15 instead of 13, especially over urban, heavily tagged areas where I’m still receiving the “problem loading data” dialog & a long delaying while panning.
Yeah, I was trying to get a locally stored image to display but obviously unsuccessfully.
Mapbox mappers complaining about “suspicious changes”?
Oh, the hypocrisy.
Mapbox needs to concentrate on improving their own editing before criticizing others. I’ve spent far to much of my OSM time contacting them about their dubious edits.
“Where is the source-code referred to, please?”
Why not join in on the community forum so you can ask for yourself & so find solutions to your queries on this collaborative project?
Please have a read of this:
“Is geospacial mathematics is resource intensive?”
“Not at all. Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.”
“As soon as there are
boundaries, multiple candidates don’t happen anymore, so that is_in:*
is ignored for all practical purposes.”
“Yes, if possible always draw boundaries. They are more precise and easier
to maintain. is_in is unnecessary.”
Regarding “doing no harm” please read this post regarding your ref:hectare tag:
Computers are very good at geospacial mathematics
Where does it say Nominatum uses is_in rather than boundaries?
Similar to your assertion that boundaries shouldn’t be be attached to other entities because they might change, boundary lines often get amended. Using the hard coded is_in tags means the entity will become inaccurate.
is_in:* is redundant when boundary=* is used.
OSM is geospacial. Mathematics can be used to determine if one area is within another.
Ah, don’t worry, I forgot that Overpass, for some reason, converts OSM to Geojson differently depending on whether the Turbo site or osmtogeojson is used. I deleted the unnecessary nodes & it works fine.
Thanks for a great utility.
woops. How do I post prettified code here?
Thanks for this. Looks like it could be useful, except:
It's a shame you've detailed what you think is there just to make it look pretty instead of what's actually there on the ground.