-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map Maintenance with StreetComplete #1998
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Extended element filter syntaxI generified the syntax a bit. Following queries are now valid:
I wanted to use the same date / relative date format for both the comparison operator ( |
Status updateUntested, but most quests that should be resurveyable are now implemented. However, from the original list in the wiki, I removed AddBikeParkingType, AddBenchBackrest and AddCrossingType because these will usually only change if the whole object is removed or replaced. So it would be better to have (in the future) quest types that specifically ask and only ask if "object x still here?". There are many more objects for which such a thing could be asked, like phone boxes, traffic lights, bins, benches, well, etc etc. But to enable that, StreetComplete would first need to learn how to remove elements so this is out of scope for now. The remaining quests to do are AddRecyclingContainerMaterials, AddRailwayCrossingBarrier, AddOpeningHours (PR), AddCycleway, AddMaxSpeed and AddTactilePavingCrosswalk. For a few of them, there are some open questions:
|
ad maxspeed - all seem acceptable and all have different benefits |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Here is a good reason for using |
Yep, I guess having |
This comment has been minimized.
This comment has been minimized.
No re-survey for
|
Just to connect two dots here, I saw the idea of using |
StreetComplete currently lacks the ability to remove elements, this is mainly what blocks these kind of quests. Regarding |
Yes, check_date:existence=* is basically just the same as check_date=*. I thought it would be useful to make that more explicit, especially since the wiki gives a counter intuitive example:
|
Here are my comments, tried to post them on the list but it was too long:
There is no real argument: you simply should keep what is there, if it is correct (yes, you would have to evaluate all of these 4 keys) or change the maxspeed to a signed value and remove the implicit tag
clearly yes, because zones already either imply an implicit limit or a position inside a builtup area. Again, do not remove any of these tags which are not wrong
in a German zone (20/30) there cannot be explicit signs. If on the other hand the zone tags denote a builtup area, the tags should be kept
no, zone:traffic is, as far as I can see, used to indicate position inside or outside a settlement, so this should not be changed unless it is wrong, and should never be removed unless there will be general agreement that it is not the solution that we want
do not remove or modify these tags, let the users decide whether they are correct (keep) or wrong (modify)
You could get the suitable values for a jurisdiction by looking at the values used for a specific country code before the colon (and a threshold) Admittedly someone in the US has torpedoed the system by omitting the country codes.
the maxspeed is either correctly tagged (same as on the ground) or not. maxspeed is not for advisory speed limits, is it?
this depends which tags you consider maxspeed related, those tags referring to zones for example are somehow related but should not be removed. It is not “clear” that walking speed is implicit for a living street, as soon as you leave Germany.
or explicitly ask people to check it.
again, don’t automatically remove these tags, but ask mapper whether to keep or remove
this is clearly wrong, at least for source:maxspeed. The documentation always asked to explicitly tag “maxspeed” values. Potentially conflicting information is ok because it can be automatically detected and fixed, much easier than plain wrong non-conflicting tagging.
indeed. You should rather ask: what is the maxspeed? And as a secondary question whether there is a sign or it is an implicit limit. Thereby you can then find all potential problems (maxspeed not correlated to the implicit indication), or someone else can do it.
encourage the users to fix the maxspeed by checking and eventually modifying its value
just let the users check both values, the implicit /source and the explicit values. They must know the locally used values, not you. For you it is sufficient to know all used values (with some usage, to exclude typos) Cheers Martin |
This comment has been minimized.
This comment has been minimized.
Answers on your answers. I've taken the liberty to sum up my statements and your answers each in one sentence in a chat-like manner because otherwise it's going to be so much text that noone will be able to follow:
Yes, it just adds complexity.
Okay, this is not how I understand the wiki but I would totally be in favour of it being defined this way. Your interpretation also adds ambiguity:
Sure, you can say that this is a prerequisite, but StreetComplete never shows raw tags to its users because it should not be a prerequisite for surveying for OpenStreetMap to know all the tags and maxspeed legislations. This (point 3) is one of the main problems why this information cannot be re-surveyed using StreetComplete - it requires either the user or the software itself to know all about the different legal maxspeed road categories and the tag value to use for them. The former is nothing that StreetComplete would impose upon its users, the latter is impossible for the reasons given. Furthermore, the mentioned legal maxspeed road categories are not even defined anywhere for every country and also never will be.
Yes, it just adds complexity.
Fair enough, the first part would be doable albeit it adds more complexity, the second part is point 3 again. How will the user be able to check if a certain displayed speed limit is correct for a living street if the speed limit is not specified explicitly on the living street sign? - in Germany for example it isnt. -> Only by knowing the legal situation in the country he is mapping in currently OR if the app would know it in the user's stead. The former is nothing that StreetComplete imposes on its users, the latter is probably doable, but adds even more complexity.
Right, here we are, I see you belong to the third group and like advocates of any of these groupes, you claim that your method must reign supreme. But this doesn't really change anything on the situation though. On the second point: The app asks only its users on-site verifiable information that do not require the surveyors to have any specialist knowledge. It's point 3 again. Let's say you are in France, on a rural road, there are no signs. Answering it correctly with "80 kph" requires you to know exactly the legal maxspeed road categories valid in the country you are currently in. So instead, what the app (should) ask is "Is there a sign? If yes, what's written on it?" but it can't because there is no tag for "there is no sign here". So in a nutshell, my reply is: It would be quite easy implementation-wise to write a tool that lets craft mappers that know about the maxspeed traffic rules re-survey the speed limits. But StreetComplete isn't that tool because it does not require its users to have specialist knowledge (in this case: for example a drivers license in the country they are in currently). Edit: But anyway, thank you for reading and responding on every point of that long explanation |
Summary of all re-survey enabled quests with intervals, element selection and notes what is taggedManual review of these is very very welcome! Any bugs or issues found now will not pop up later in the beta phase In the the table below, you can expand the fields "Asked for Elements..." and "Overpass Query" by clicking on that arrow. If the former is available, the latter is actually just an automatic tranpilation into Overpass QL, so it is easier to understand if you just look at "Asked for Elements...". Following the remarks expressed on the tagging mailing list, all quests below only add or update a Whenever adding, updating or deleting a AddRecyclingContainerMaterials
Overpass Query
AddRoadSurface
Asked For Elements...
Overpass Query
AddRailwayCrossingBarrier
Overpass Query
AddPostboxCollectionTimes
Asked For Elements...
Overpass Query
AddBikeParkingCapacity
Asked For Elements...
Overpass Query
AddCrossingType
Asked For Elements...
Overpass Query
AddBusStopShelter
Asked For Elements...
Overpass Query
AddVegetarian
Asked For Elements...
Overpass Query
AddVegan
Asked For Elements...
Overpass Query
AddInternetAccess
Asked For Elements...
Overpass Query
AddParkingFee
Asked For Elements...
Overpass Query
AddMotorcycleParkingCapacity
Asked For Elements...
Overpass Query
AddPathSurface
Asked For Elements...
Overpass Query
AddTracktype
Asked For Elements...
Overpass Query
AddWheelchairAccessToilets
Asked For Elements...
Overpass Query
AddWayLit
Asked For Elements...
Overpass Query
AddTactilePavingCrosswalk
Overpass Query
AddTrafficSignalsSound
Asked For Elements...
Overpass Query
AddWheelchairAccessPublicTransport
Asked For Elements...
Overpass Query
AddWheelchairAccessOutside
Asked For Elements...
Overpass Query
AddTactilePavingBusStop
Asked For Elements...
Overpass Query
AddCyclewaySegregation
Asked For Elements...
Overpass Query
AddHandrail
Asked For Elements...
Overpass Query
AddCyclewayPartSurface
Asked For Elements...
Overpass Query
AddFootwayPartSurface
Asked For Elements...
Overpass Query
AddWheelchairAccessToiletsPart
Asked For Elements...
Overpass Query
|
@westnordost Am I missing something or is and |
It's still work in progress, that is why it is not in the list. |
Order by importance/how sure I am.
Asking for Asking about
I it possible to ask quicker if it conflicts with surface?
Is it showing what was tagged? I noticed that in some regions all postboxes are tagged with the same hour. Two years seems a bit too often for me.
Seems significantly too frequent to me.
I would ask once 16 years if tagged as with handrail |
Because a concrete road might turn into an asphalt road at some point. I don't see the problem with 8 years. It's a really long time.
Again, I think the suggested hours by @westnordost are fair. A lot of things can happen in 4 or even 8 years! |
I think that chances of *other than pedestrian/living_street/service |
Sorry if I got something wrong, but is there a quest that will ask is POI (mostly like shop/cafe that open/closes frequently) is still in place? I had issue with OSM maps several times spending my time to walk to the shop and it was closed already for a long time. |
No, it will not. StreetComplete currently lacks the ability to delete POIs, by I intend to add this later - not as part of the "Map Maintenance with StreetComplete" project sponsored by the OSMF though. If you are thinking about a new quest where the app would tag a vacant shop as |
Anyone interested in testing the new StreetComplete version with the map maintainance (resurvey) feature? I just released an alpha. you can simply install the APK linked here over your Google Play install: https://github.com/westnordost/StreetComplete/releases/tag/v23.0-alpha1 (If you got the app from F-Droid, you need to uninstall it first) |
Quick comment on the overpass queries: it would probably make sense to use is_date to make sure that a tag value contains a valid timestamp. Otherwise a date comparison may behave in unexpected ways for garbage input data. |
Noted, thank you. Though I think I'll leave it as it is because I see no reason to exclude objects from resurvey forever because someone supplied the check date in an invalid format. If garbage data leads to the quest being asked again, the better. The best would be if it was asked especially if it is in an unparsable format, but I didn't find a way to express this in a compact query. |
You don’t need to exclude invalid ones, just make sure that the date comparison is meaningful: ( !is_date( t[ ...]) || date(t['cycleway:surface:check_date']) < date('2012-08-20')) |
Does |
I haven’t tested it but is_tag() should be able to cover this case. |
This is the final report for the OSMF: https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Map_Maintenance_with_StreetComplete/Report |
I created a draft to propose a change in the tagging of implicit maxspeed values to fix this issue: https://wiki.openstreetmap.org/wiki/Proposed_features/implicit_maxspeed |
I answered in the discussion section. The Proposal as it is will not solve the issue. |
Am Di., 7. Sept. 2021 um 12:08 Uhr schrieb Tobias Zwick <
***@***.***>:
I answered in the discussion section. The Proposal as it is will not solve
the issue.
same
|
This ticket shall serve as a FAQ and discussion hub for what is implemented for the feature Map Maintenance with StreetComplete.
None of the below is set in stone yet.
Any information your are missing here?
Project information
Time Frame
It is aimed to go live with this feature by the end of August 2020 but no guarantee.
Milestones
nodes, ways with opening_hours older 1.5 years
and implement transpilation to OverpassQL. Further, provide utility functions to handle understanding and updating the
check_date
tags. (Feedback on the syntax is welcome)check_date
tags where applicable. (See Proposed Resurvey Intervals)FAQ
How will the things be marked as surveyed?
If the thing (f.e. opening hours) has changed, then simply the new opening hours will be tagged and nothing else. After discussion on the tagging mailing list, many people expressed the preference of not adding more tags that are absolutely necessary to support a re-survey like this.
If the thing hasn't changed,
check_date:[key]=[current date]
(f.e.check_date:opening_hours=2020-08-05
) will be used to mark the opening hours as checked at that date.On the mentioned discussion on the mailing list, there was a slight preference towards
[key]:check_date
because it is displayed right next to the key it references to so it is more likely people will keep it up to date. However, later during implementation, I noticed that[key]:check_date
could collide with other:
namespaces and thus make it more difficult or introduce bugs for other software. So, not a problem for humans to understand, but for software, for example:recycling:check_date
(= you can recycle check_dates here?),cycleway:check_date
(= a cycleway on the "check_date" side?)While StreetComplete will set the mentioned tag, it will also understand and correctly process at least
check_date:[key]
,lastcheck:[key]
and[key]:lastcheck
. Other "this has been surveyed at..." tags don't seem to be used much on a per-tag level.As an outlook, all those "this has been surveyed at..." tags may become obsolete if the OSM database and API is extended to include this information in the metadata. When this happens, StreetComplete will also be extended to use this metadata in the future rather than the tags.
What are the intervals in which quests are asked again? For which quests is it enabled?
This will depend on the quest type. Only a fraction of quest types is eligible to be asked again. Housenumbers and building types for example are never asked again. Those that are are sorted into categories like "related to a business" and those categories are assigned rough average life times on which the intervals are based.
Also, specifically the maxspeed quest, will not be asked again, explanation here: #1998 (comment)
You can contribute to finding the best intervals by writing your experience and making suggestions here: Proposed Resurvey Intervals
Also, you will be able to select in the settings to be asked less (/2) or to be asked more often (x2) about resurvey.
Will resurvey-quests be specially indicated in any way on the map?
No.
This would be substantially more effort while I do not see any useful use case for it.
The user doesn't need to know whether he is contributing new information or updating information. I reckon there might be the notion that it is better to first "complete" the map and then proceed to maintaining it, maybe because of the fear that there may be too few contributors to be able to complete the map when one cannot keep up maintaining it.
The case against this notion is exactly what I wrote in the last sentence actually: If there are not enough people who can maintain the map up-to-date at the current level of detail, then adding even more details will make it even worse. When is the Wikipedia complete? We have to live with the fact that there will always be something new that could be added to the map, our limit is (only) our manpower and our ability to maintain it.
Someone in the forum, I forgot who, had a memorable signature, it went something like
If one contributes volatile information (f.e. opening hours), it goes without saying that its value deteriorates over time and must be refreshed regularly. It is up to each individual to decide if he or she wants to contribute this kind of information and subsequently also be asked to refresh it or not, it is possible to disable certain quest types in the settings.
Will the resurvey-intervals be shown in the app per quest type?
Probably not. It wouldn't be much effort, but then again I see no reason to expose such information to the users in the app, especially if they have no way of seeing whether a quest they are answering is a re-survey quest or not.
I think this is information that may well go into the wiki.
How will the interface for resurvey quest look like?
In most cases, the interface will be exactly the same as if the question has never been answered before. In most cases, the user will not be asked first if the thing (for example, "Is the surface of this road still asphalt?") is still correct and if not, be prompted to select the new value in a second step. There are several reasons for that:
The text was updated successfully, but these errors were encountered: