helium314 / scee Goto Github PK

How to Reproduce
Add multiple lines of text. Afterwards the coloring section cannot be reached

Expected Behavior
Edit windows or whole popup gets a max-height to enabled scrollbars when height gets bigger

Versions affected
50.1_ee

Use case
Want to use different custom overlay for different use cases and be able to switch between them

Why

• Defining the overlay can be quite complex, so I want to retain it (this could theoretically be done in any separate text app)
• Defining two custom overlays to quickly switch between them it currently not possible

Proposed Solution
In the editor:

• Add field to give it a name
• Add a delete button

In the list of overlays

• Store different custom overlays as separate entry
• Rename the "custom overlay" button to "edit"
• Make it sensitive to the selected quest
  • will edit the selected overlay
  • only enabled when a custom overlay is selected

What do you think about adding a "not singed" answers option like at the opening_hours quest for the phone and website quest?

Not exactly sure what kind of changes you want but picking up matkoniecz@ca3ecde (adding medical specialities) may be useful if you or other users would report missing specialities in iD presets and/or contribute translations to iD presets in their languages, making this quest more ready for wider release and testing is it even a really good idea.

Note that you can add only one at time, so multiple ones would require making a note.

So far as result of testing this code I opened openstreetmap/id-tagging-schema#778 openstreetmap/id-tagging-schema#779 https://www.openstreetmap.org/changeset/132128903 https://www.openstreetmap.org/note/3546322 (pain management - it seems we have no tag for that) when I tried to use it

(StreetComplete issue is at streetcomplete#1020 )

30 meters is a small distance even for small shopping centers. Sometimes there are POIs that are added to OSM automatically only based on the address, so they are placed randomly in the building. For example, the company RocketData adds to stores in the CIS in this way.

Use case

Support validation of large set of to-be-imported POIs

Proposed Solution

Osmose already supports fix nodes with id = 0. The quest could also support this

I am generally wondering if this is feasible. Does the StreetComplete infrastructure allow creating and uploading new POIs?

POI:
https://www.openstreetmap.org/way/23244458

43.0-beta1
Android 12, OneUI 4.1

Backlinking to streetcomplete#48 (comment)

The sc ee feature "notify about nearby quests" correctly shows notifications after disabling batery saving for sc ee.
There is a permanent notification as "watchdog" + another one when quests are nearby.

Problems I faced:

• first some-hundred meters / minutes the nearby notification did not show up at all (although I walked next to quests)
• notification did not play any sound or vibration ever
• radius is imho set too big. While walking around it notified about ~50m far quests as "nearby". Resulting in the notification beeing often permanently present (with my chosen preset).

Use case

Currently it is possible to replace the map by satellite imagery. However in my country there's a governmental service that produces aerial imagery once a year using a helicopter. Of course this imagery is much more detailed than the satellite imagery.
So it would be great if I could change the URL of the imagery used.

Proposed Solution

Well, I'm not exactly an expert in the inner workings of SC and/or SC-ee but in Vespucci and in JOSM it is possible to select imagery from a list that is included in the software and additionally in JOSM it is even possible to add an URL, provided that the user knows how a valid URL is constructed.

When creating new note, icon for taking a picture is obscured by OSM button.

How to Reproduce

• long press on map
• choose create new note
• start typing text
• notice that OSM button is now overlaying camera button

See picture:

Versions affected

• Android 10 on Huawei P30 Pro.
• H3 fork from app-release_43.2.apk - which for some reason identifies itself as v43.1 in About window, which is probably another bug (also, clicking on Version history in About, shows changelog for v43.2 and v44.0 too, and seems to contain v44 features like GPX track recording)

sc34.0b1.apk
Android 5.1.1
Samsung Galaxy j1

1. Long press on the map.
2. Click to create a note
3. Crash

Thanks for the fork! ❤️ You've made features that StreetComplete is missing.

Use case

In v48.0-beta1_ee there is now a option to see picture that was taker for a note!

BTW is that original picture, or downsized one (i.e. the one that would be sent to the server) ?

Proposed Solution

If that is (hopefully) same picture which would be uploaded to server and downloaded by other users later, it would be great to allow zooming in/out the picture to check if texts on it are actually readable (e.g. addresses, opening hours, etc).

That would basically implement streetcomplete#2497, so might be even PR'd to the upstream.

Use case

It would be nice, if quests made in the modified version could be counted like quests made with the normal version count for the modified version

https://github.com/Helium314/SCEE#changeset-differences-compared-to-streetcomplete

Seems to not apply: ae65fce - and https://github.com/Helium314/SCEE/blob/modified/app/src/main/java/de/westnordost/streetcomplete/quests/smoothness/AddPathSmoothness.kt seems to be the current state

How to Reproduce

• Click on menu / About / Give feedback
• get a 404 "page not found error"

Expected Behavior
Probably should open a discussions (after enabling them)?

Versions affected
v45.0_ee

Use case
Coloring the left and right side of a street instead of it's center
E.g. for a custom bicycle overlay

Why
Coloring custom overlay based on tags is nice, but creates too many colors when left, right and both is included in the keys.

Proposed Solution
When coloring key matches a key containing :left, :right or :both, colors the left, right or both side(s) of the street instead (like the bicycle or sidewalk quest)

With the overlays, team mode was moved below "scan for quests" button. Due to the small button size it's rather easy to accidentally enable team mode when trying to scan for quests.

@mnalis I think you had some solution for this. Does it actually work, or was it just a mockup?

For example one asking about leisure=track surface (it was track in a military base https://www.openstreetmap.org/changeset/132535766 )

This is weird... the button is basically a copy of the ok button, so the problem should also occur for the ok button, but apparently doesn't.
Differences:

1. hide button is smaller
2. hide button is aligned to start instead of end (i.e. left instead of right)
3. ok button is invisible in the beginning, while hide button isn't
4. hide button is (unnecessarily) set to become visible once quest fragment is created, while ok button becomes visible later

My best guess is that the problem is 3: the button might be created before some navigation bar checks are done.
So I'll set it to be invisible at the start and you can tell me whether it helps.

Originally posted by @Helium314 in #367 (comment)

How to Reproduce

https://www.openstreetmap.org/node/747815025

I got a streetWidth quest for the way which includes the node.
This node got a nice but inappropriate island icon in the highlighting.

Does it happen in normal StreetComplete?

The node does not got a highlighting in SC, only the way itself.

Versions affected
51.0

https://github.com/Helium314/SCEE

Maye "StreetComplete expanded with more complicated editing features, not intended for users new to OpenStreetMap"?

If I use the Expert Edition and add some Information to OSM, the counter for "Last 7 days" and also "When you have mapped in the last time" isn't working.
If I do this with the "normal" App (mo Expert Edition) it works as expected.

Android 13
Street Complete v49.0_ee

https://f-droid.org/en/packages/de.westnordost.streetcomplete.expert/ has

Due to the different name used in changesets, edits made with this version do not contribute to the displayed StreetComplete statistics and star count.

but that is just a technical method, not actual reason for that

Maybe

Due to extra features that may significantly affect how objects are edited, edits made with this version do not contribute to the displayed StreetComplete statistics and star count.

would be better?

I would make a PR but failed to locate where this text is defined, even if it is defined in the repository

Got a bug report for 47.0_ee

Describe how to reproduce it here:

Measure road width using the camera

Thread: ImageStreamHandler
App version: 47.0_ee
Device: Sony XQ-CC54, Android 12
Locale: de_DE
Stack trace:
java.lang.IllegalStateException: maxImages (16) has already been acquired, call #close before acquiring more.
at android.media.ImageReader.acquireNextImage(ImageReader.java:560)
at android.media.ImageReader.acquireLatestImage(ImageReader.java:441)
at dcy.onImageAvailable(PG:10)
at android.media.ImageReader$1.run(ImageReader.java:836)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:346)
at android.os.Looper.loop(Looper.java:475)
at android.os.HandlerThread.run(HandlerThread.java:67)

I have no idea what is going on, as I don't have Play Services and thus never tried AR measurements. No SC code in the crash report doesn't help...
Apparently one can take photos in AR mode, and maybe after taking 16 photos it crashes? Can anyone test this?

Use case

While it is legally required in the Netherlands to accept cash payments, according to research done by an organisation for senior/elderly citizens about 2-5% of the shops only accepts electronic payments. They focused on shops but it might be equally valid for other places where payments are accepted.

(Update: according to another newspaper article it isn't even legally required in the Netherlands for places to accept cash payments, so I now wonder why that quest is disabled in the Netherlands.

Proposed Solution

Enabling the 'Is cash payment accepted here?' quest in the Netherlands (may be also in other EU countries) seems to be an appropriate choice.

via streetcomplete#2396

It seems that the expert edition of StreetComplete can afford the settings item to save photos to the device in full quality and request additional permission for this.

Downloading from https://github.com/Helium314/StreetComplete/releases/download/v43.2/app-release_43.2.apk, one would expect version based on upstream v43.2. Instead:

• it identifies itself as v43.1 in About window
• also, clicking on Version history in About, shows changelog for v43.2 and v44.0 too

Code itself does seems to contain v44 features like GPX track recording

Perhaps it would be good to base local changes based on upstream v43.2 (or whichever) git tag (instead on of what happens to be the master branch at the moment)?

Versions affected

• version from https://github.com/Helium314/StreetComplete/releases/download/v43.2/app-release_43.2.apk

Use case

Currently, GitHub releases are all named app-release.apk. This is not ideal.

Proposed Solution

Upstream releases are named like StreetComplete-v45.2.apk.
It would be great if we also could name them like StreetComplete-EE-v45.2.apk or similar.

There was an issue for this at the sc repo but I think the main problem is that there is no tag for when there is no sign and that it's a bit complicate to find the right sign. streetcomplete#3806

Would that still be conceivable in scee?

https://wiki.openstreetmap.org/wiki/Key:destination

Hello, is it possible to display the quests in the system language of the device? I would also like to support this just because I unfortunately don't like how.

Doing about anything (like going to settings) causes an immediate crash. The app actually does not crash permanently but enters a "minimized" state and when "maximized" again it shows that the app has crashed previously and sometimes offers to send an E-mail with debug information, which I pasted below, but it is possible to resume the activity. So the crash apparently is not fatal, but it is annoying and interrupts workflow.

How to Reproduce

As far as I can tell there's nothing specific needed. Just do an action and it crashes.

Expected Behavior

I don't want to see crashes.

Versions affected

Version 48 on Android 10.

The app suggests the following is useful:

Thread: main
App version: 48.0_ee
Device: OPPO OP4F2F, Android 10
Locale: nl
Stack trace:
java.lang.AbstractMethodError: abstract method "void android.location.LocationListener.onProviderDisabled(java.lang.String)"
at android.location.LocationManager$ListenerTransport._handleMessage(LocationManager.java:365)
at android.location.LocationManager$ListenerTransport.access$000(LocationManager.java:275)
at android.location.LocationManager$ListenerTransport$1.handleMessage(LocationManager.java:291)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:240)
at android.app.ActivityThread.main(ActivityThread.java:7829)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:512)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1027)

Would it be conceivable that the modified Streetcomplete will become available in F-Droid?

Currently preferences added in EE are simply a long list, and probably soon it's going to be a very long list.

It would make sense to group the settings into a few meaningful categories, and have a (sub)menu for each category.
Help / suggesions with arrangement of groups and actual implementation is very welcome.

When creating a new profile, choosing to create EMPTY PROFILE should create profile with no quests selected. Instead, newly create profile has 128/162 quests enabled.

How to Reproduce

• go to Manage profiles
• click + to create a new profile
• choose EMPTY PROFILE from bottom right
• type the name of the profile, confirm and select it
• notice that the newly create profile is not empty

Versions affected
H3 fork from app-release_43.2.apk - which for some reason identifies itself as v43.1 in About window, which is probably another bug (also, clicking on Version history in About, shows changelog for v43.2 and v44.0 too, and seems to contain v44 features like GPX track recording)

Instead of needing to press first the "..." button, be able to direcly press this, as it is the 99% use case here.

Answer bar is otherwise anyhow empty for custom overlays.

Nice fork :-)

I installed https://github.com/Helium314/StreetComplete/releases/download/v43.0-beta1/app-release_43.0.apk
and it shows the same app icon and name and so is hard to distinguish from the official app.

Can we rename it to "Mod StreetComplete" or something like that?

Currently settings import / export happens by copying the shared preferences file. This assumes that the file is located in the default location, which works at least for my test devices. But this may not be the case for all Android versions and device manufacturers.

I expect a proper implementation would be safer, not require app restart on import, and allow to merge settings instead of just overwriting the existing ones on import.

Use case

Many of changes in my fork are basically relaxing the quest selection query to return more quests than it would usually do.

Proposed Solution
Adding a global preference like ask_more_quests=true/false, which can easily be queried in each quest, would allow for easy implementation of those quests. It would also allow users easy switching between more/less quests (e.g. they might want to enable it only where they are in already-well-surveyed area)

(Possible alternative might be adding per-quest preference checkbox for that, but those seem to be global in current H3 fork, and would need to be per-preset instead, so user could duplicate preset and change only those. But while more powerful it seems like it would be making managing presets much harder - and it is hard enough already, so this is probably not a good alternative).

I though about implementing something like that in my fork, maybe would be welcome also here?

Note that it would likely require maintaining long list of valid shop values (I would write script listing all shops with OSM Wiki pages or find already existing one doing this)

It cannot go into base SC as often the correct solution would be documenting shop value on OSM Wiki or inventing a new tagging scheme to retag shop as subtype of more widely used value

See https://taginfo.openstreetmap.org/keys/shop#values (shop=Mapbox, shop=opał etc)

At least the simplest tags editing🙏

Hi @Helium314 and @mnalis I really much like the changes done in your fork. Here is another improvement:

Use case
Less clicks - more focused experiance

Proposed Solution
When there are multiple quests per object you are already showing them in the left.
Now when clicking "ok" to answer one and there are still some left, directly open the (any) next quest for this object.

In dark mode, almost everything has a black background, except the permanently visible buttons on main screen. I've been testing to switch them to black in dark mode (with white drawings), and find it works well.
But making this optional (i.e. button color independent of theme) would be considerably more work.

@mnalis would it be ok to non-optionally couple button background to theme? It would go against the general aim of making everything optional, but I can't really see why one would actually want white buttons on a dark theme.

https://www.google.pl/maps/@50.1440269,19.9084778,3a,75y,154.07h,74.44t/data=!3m6!1e1!3m4!1sVMT2md9QADrtfvRA7dHkew!2e0!7i13312!8i6656

this is present already in my Zażółć fork (if accepted may try to submit PR, though no promises on doing it immediately)

This should never be uploaded

The description of the package of edits when manually editing tags looks alarming for other mappers.:)

I was at a really narrow residential street and wanted to measure its width.
It would be nice to have this for all streets as an option.

How to Reproduce
Enable Osmose quest
Does not show up

Expected Behavior
Quest appears

Versions affected
v45.1_ee / Android 12

Exception

08-15 20:29:36.023 15982 16003 I osmose  : downloading for bbox: BoundingBox(min=LatLon(latitude=8.95019282586578, longitude=38.7652587890625), max=LatLon(latitude=8.966471298599469, longitude=38.7762451171875)) using request https://osmose.openstreetmap.fr/en/issues/open.csv?zoom=17&item=xxxx&level=1&limit=500&bbox=38.7652587890625%2C8.95019282586578%2C38.7762451171875%2C8.966471298599469
08-15 20:29:36.232 15982 16003 E osmose  : exception: CLEARTEXT communication to osmose.openstreetmap.fr not permitted by network security policy
08-15 20:29:36.232 15982 16003 E osmose  : java.net.UnknownServiceException: CLEARTEXT communication to osmose.openstreetmap.fr not permitted by network security policy
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:164)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.java:224)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.java:108)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.java:88)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.Transmitter.newExchange(Transmitter.java:169)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:41)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:94)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:88)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:142)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:117)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:229)
08-15 20:29:36.232 15982 16003 E osmose  : 	at okhttp3.RealCall.execute(RealCall.java:81)
08-15 20:29:36.232 15982 16003 E osmose  : 	at de.westnordost.streetcomplete.quests.osmose.OsmoseDao.download(OsmoseDao.kt:45)
08-15 20:29:36.232 15982 16003 E osmose  : 	at de.westnordost.streetcomplete.data.download.Downloader$download$2$1$4.invokeSuspend(Downloader.kt:49)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
08-15 20:29:36.232 15982 16003 E osmose  : 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

Happens sometimes, but only if Show nearby quests is set to Show all quest types or Show all types and hidden quests, and the related element is not a node.
It seems that OsmoseDao doesn't find the quest inside the given bounding box, even though the quest pin clearly indicates that there is a quest at this position.
This is rather low priority, as it only happens rarely and with specific settings, and it does not cause any real problems.

Use case
I saved the standard osm.org tile server, because the familiar appearance helps me concentrate, the surrounding features help me orient myself, and it's more aesthetic. The road names from the app overlap with the names from the tiles; if it were feasible to disallow the app from printing the road names, it would be nice.

Proposed Solution
A setting to disallow the app from printing road names.

Use case
I have used the "Add POI" button to create a barrier on some footpath. But the app has only created an isolated node, instead of vertex, a node that is part of the actual way, as an obstacle on the footpath.

It would also be useful to create entrance nodes (as part of building way)

Proposed Solution
We can know about the nodes that can be vertexes from ID presets. So maybe a "snap to way" button on the POIs that could be vertex, that highlights nearby ways add let you choose one of them ?