[proposal] Reducing number of map objects loaded in ID

[pedjas]

OSM map grew a lot. In areas I work on number of objects is expanding on exponential basis. ID editor cannot handle that any more. It slows down tremendously.

I tried using Map Features option to reduce number of objects on map but it does not help. I found out that Map Feature just reduces number of displayed objects but they are all loaded in memory anyways.

It is also hard to work in ID because too many objects are displayed and everything is clogged on the map.

There are four things that could be done:

1. Changing way how ID loads data from OSM database. It should load only objects that are necessary / generally those that are going to be actually displayed.

2. Having more granulated options for user to select which objects to display and which not. Map Feature is to broad and does not provide tool for user to remove objects he does not need, and keep those that he does need.

For example, option Points (of Interests) is not selective. User can either remove all points of interests or none of them. there is no option to select some points of interests. Same goes with other options offered within Map Features.

Maybe new option could be introduced for user to provide some kind of filtering rules like ones used in overpass-turbo. That would let user to very specifically choose type of objects he wants to be loaded.

3. It would be good for users to have option to set ID not to update objects on the map automatically, but only on demand. That would help a lot. Now, even slightest move of the map causes reload of the objects which is painfully slow.

User could have an option to work like on JOSM - get some data, work on it, and then get some more when he decides he needs it. That would reduce number of map data reloads and would really speed up things especially for situations that user does not have to edit locations, but just editing tags of already existing objects.

[1ec5]

Changing way how ID loads data from OSM database. It should load only objects that are necessary / generally those that are going to be actually displayed.

Choosing the features to display in the editor is always a tradeoff of performance over safety, regardless of the editor or API endpoint. It’s already the case that, due to enabled filters, sometimes iD and JOSM users unknowingly perform edits that semantically conflict with existing data (even if from there’s no conflict a purely data model standpoint). iD has some mechanisms to avoid the semantic conflicts, such as disallowing splits of features connected to hidden features. But increased customizability in this regard would probably overwhelm those safety measures, so such an enhancement would require considerable thought.

For example, option Points (of Interests) is not selective. User can either remove all points of interests or none of them. there is no option to select some points of interests. Same goes with other options offered within Map Features.

Maybe there could be subfilters under “Points of interest” for common categories of POIs. Selecting some of those subfilters but not others would put “Points of interest” in a mixed selection state. This improvement could probably happen even with the current implementation, improving map/UI rendering performance in dense areas without necessarily dealing with the bandwidth or memory concerns.

It would be good for users to have option to set ID not to update objects on the map automatically, but only on demand. That would help a lot. Now, even slightest move of the map causes reload of the objects which is painfully slow.

A change along these lines would facilitate a “low data mode”: #7788. In my opinion, it probably should not be enabled by default, because a lot of users (myself included) make roving changesets and don’t necessarily plan them out ahead of time. Having to continually trigger a refresh could get annoying fast.

[pedjas]

Choosing the features to display in the editor is always a tradeoff of performance over safety, regardless of the editor or API endpoint. It’s already the case that, due to enabled filters, sometimes iD and JOSM users unknowingly perform edits that semantically conflict with existing data (even if from there’s no conflict a purely data model standpoint). iD has some mechanisms to avoid the semantic conflicts, such as disallowing splits of features connected to hidden features. But increased customizability in this regard would probably overwhelm those safety measures, so such an enhancement would require considerable thought.

Sure, but this would considered as advanced feature for those who know what they are doing.

Look it form perspective of an editor that fills in tags information on the map, not editing geographical positions. He edits existing objects.

My main point is that editing in ID (and other editing tools too) becomes painfully slow due to too much details on the map. Something has to be done.

For example, option Points (of Interests) is not selective. User can either remove all points of interests or none of them. there is no option to select some points of interests. Same goes with other options offered within Map Features.

Maybe there could be subfilters under “Points of interest” for common categories of POIs. Selecting some of those subfilters but not others would put “Points of interest” in a mixed selection state. This improvement could probably happen even with the current implementation, improving map/UI rendering performance in dense areas without necessarily dealing with the bandwidth or memory concerns.

Exactly. Map become very detailed. Single trees are mapped, street lamps, semaphores, 3d modeling data is more and more added. I even found out sidewalk fence stones are mapped - each and singe one. Having more details on map is always good - except when you do not need them and they are just clogging the workspace.

And there is significant drawback: Map Features option does not free Id from objects. Objects are always loaded (which slows it down). It just does not display them.

The other day I had to edit single tag on some object. It was in the middle of the urban area so I knew that would be an issue. So I zoomed in to the maximum to reduce loaded map area. I also turned off all Map Features. ID loaded over 70.000 hidden objects! ID does not allow editing tags until whole map is loaded so I ended up waiting for a long time for ID to load all objects (that it did not even show in map editor) just to edit a single tag.

I guess there is a way for ID to decide what objects must be loadeded to avoid issues you point to. It is not problem if ID loads more objects than what user needs because it is required for safety of data entry. Problem is loading object that are not needed at all and just slow editor.

It would be good for users to have option to set ID not to update objects on the map automatically, but only on demand. That would help a lot. Now, even slightest move of the map causes reload of the objects which is painfully slow.

A change along these lines would facilitate a “low data mode”: #7788. In my opinion, it probably should not be enabled by default, because a lot of users (myself included) make roving changesets and don’t necessarily plan them out ahead of time. Having to continually trigger a refresh could get annoying fast.

I did search for similar issue case opened before i posted this but found nothing. Thanks for pointing this one. Yes, it is on the same page is this one.

Of course, this should not be forced change in functionality but optional. Option for user that faces this problem in very detailed map areas to reduce number of objects loaded.

After all we are just users. We are pointing out problem. Our ideas how to solve them are just guessing how it could be done. The main point is that developers became aware of this problem that ID is close to became unusable due to more and more amount of data on the map. I am pretty sure they would come up with some solutions.