Replies: 3 comments 1 reply
-
Note: despite having the data locally, these tend to be resource-intensive to process. See #2803, for example, which was a result of some relations being really huge.
I suspect it will be on a case-by-case basis. So what I would do is post a list of ideas, see which ones there is more interest in, and only put in effort to refine those. |
Beta Was this translation helpful? Give feedback.
-
To be honest I think we should go in the other direction use little to none of the surrounding objects to decide which quests to ask, and instead just always ask the quest. A road might have both an on-road lane or other infrastructure plus there might be an adjacent off road track, SC would never know unless it asks. |
Beta Was this translation helpful? Give feedback.
-
So most comments are about nearby objects. What about checking for adjacent objects? |
Beta Was this translation helpful? Give feedback.
-
There are already some quests which make use of surrounding elements for filtering. One example is the cycleway quest, which excludes roads where a cycle-able path is near and aligned.
What do you think of using similar logic also for other quests? Now that quests are created locally and not via overpass anymore, this should have become simpler and faster.
I have a lot of ideas on how to improve certain filters by having a look at other elements. Most of them are even much simpler than the isNearAndAligned stuff. But before I put effort in refining those ideas, testing them with example overpass queries and opening issues, I'd like to ask if this approach is desired.
The use case I see is mainly the filters which are currently very restrictive to avoid spam, so they do also miss some good quest candidates.
Beta Was this translation helpful? Give feedback.
All reactions