Hi, I’m a regular user of iD. Yeah, I know, I know, JOSM is the superior editor for most use cases, but I just find very useful the ability to use the web interface and edit wherever I need to without having to go through the process of managing my existing edits. The portability of it all is nice.
Prior to the revamp (a very welcome update, I may add!) the editor was running… well, quickly enough. Now that OGF’s iD editor is now up-to-date with OSM (or at least a far newer version is in place) iD seems to be far laggier than it used to be. I’m getting noticeable, albeit not lengthy, delays whenever I start editing and make my first changes, and the delays get worse the more tiles I load and the more ways/nodes I allow iD to load.
To be clear, it’s definitely not an issue with the OGF site - OSM’s modern iD configuration also gives me these delays to some extent. I was wondering if there was a known way that I can do on my end to make iD less… bloaty, I guess is the best way to describe it? Especially when working in urban areas. I’m avoiding other heavy-resource browser tabs/websites while editing already…
Secondly, re: custom OGF features, I’m aware that the staff-recommended way to allow the OGF map to appear in iD is to use the custom tile field and inputting the OGF tile server. Is the reason for this that the iD will actually “keep up” (a good thing) with new releases of the interface, thusly making any OGF-related customizations (preloaded background maps, customized brand autofilling, etc, etc) to the interface completely unfeasible? Or will iD stay static as it used to do?
(P.S. - is the forum up yet or will that take some further time to get up and running?)
Comment from Luciano on 9 September 2021 at 12:42
The new, up-to-date version of iD embedded in the new rails port is definitely bloatier. In theory, it might be possible to replace it with an older version of iD if this became a major problem (e.g. a copy of the version that had been running on the old website… )
The decision to leave the iD set-up “generic” was for 3 reasons:
1) customizing the various pieces of iD was a large coding task which our team wasn’t ready to take on. iD is coded in a different computer language than the rest of the OSM website, so it requires learning and understanding new, different ways of doing things before being able to make changes and customizations.
2) as you observe, we are hoping that by leaving iD “generic” it will be easier to update when new releases come out
3) there was of course the philosophical stance that JOSM encourages a more reflective, planned out approach mapping which is to the benefit of the community.
Comment from histor on 12 September 2021 at 09:25
Maybe JOSM are the better soloution - I think there are a lot of mappers using ID as editor in the past. The “old” ID was a very comfortable tool - the “new” ID to me looks poor. So I think, there can be an update of ID very helpful.
Comment from Luciano on 12 September 2021 at 18:56
I think “update” to iD is not helpful, but rather, that’s the problem. The iD on the old OGF was very old. The iD on the new OGF is very new. And so it is more “specific” to OSM, which makes it harder to use for OGF for many mappers. So actually we would need to reverse the update, to get an iD that users were comfortable with.
Anyway, sorry about that. Welcome to the new site - happy mapping!
Comment from Marcello on 13 September 2021 at 09:20
Just to balance the discussion:
As a user who has used P2, ID and JOSM, I honestly have few issues with the ‘new’ (OSM -based) ID we have now on OGF. It may be that I also map on OSM, it may be that I map quite slowly. My only issue is that it is very small -scale work and for larger items (landuse etc.) I have to switch to JOSM per sé.
The discussion on whether JOSM is better as in encouraging more reflective and planned - thus better - mapping is still a strange one to me.