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?
~ Kurzov
(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
@histor
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.
Marcello.
Comment from héedaná on 7 October 2021 at 01:59
Something useful might be to open the ‘Map Data’ pane (hotkey: F) and under the ‘Map Features’ section deselect any feature types one isn’t currently interested in. Anyway, a thread about iD performance is ongoing in the software’s bug tracker; please don’t barrage them with comments that it’s not working well as it’s a known issue, but details about the behaviour may help…either way, following the issue can give you updates on progress to a fix: https://github.com/openstreetmap/iD/issues/8612
F
It would be sad if the version reverted to an older one, since I remember reading that the intent going forwards was to make the software more modular (such that perhaps OGF could remove parts only relevant to Earth instead of [unnamed planet]).
Comment from Luciano on 7 October 2021 at 12:39
@héedaná
Personally I’d like to see iD become even MORE modular - my long-term ideal would be that iD stands alone, even on a separate server, and no longer directly integrated to the rails port that provides the OSM (OGF) API.
I realize there are people who disagree (strongly!), and there are some exceptions, but I remain convinced that use of iD does not correlate well with high quality geofiction mapping styles. Therefore I am not of a personal inclination to encourage its use. To the extent it can be considered a separate application from the OGF rails port, it can be stand or fall on its own, too, as an application (perhaps even maintained / hosted by someone else).
