You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to allow hiding of features in the overlays. A user who systematically wants to work through some overlay, could hide the features that have been fixed allowing the use of the site as a to-do-list.
It is not intended to send this information to the server in any way. Something like that would be much more difficult, the server would have to update its database, generate new tiles, incorporate this information when updating from new OSM data etc. Instead this would only store a tuple (layer_url, feature_id) in the web browsers local store and suppress displaying features in this database.
The text was updated successfully, but these errors were encountered:
We could allow the server to optionally set a URL of an API end-point that allows sending "problem solved" or "false positive" messages to the server. But lets first see whether any servers actually would implement this...
Data source can add optional fields to layer description containing a status URL or URLs and possibly a list of available "states". The URL(s) can contain place holders (something like "{id}") for attributes of features in the layer.
When Osmoscope finds this information in the layer description, it adds buttons to the "Selection" box whenever somebody clicks on a feature. When those buttons are pressed, the URLs are completed using the attributes of the feature and a POST request is sent.
We still need to figure out how to influence displaying of the feature on the map. Does Osmoscope just hide the object (or display it in a different color or so) or does it have to re-load the data source somehow to get updated data.
It would be nice to allow hiding of features in the overlays. A user who systematically wants to work through some overlay, could hide the features that have been fixed allowing the use of the site as a to-do-list.
It is not intended to send this information to the server in any way. Something like that would be much more difficult, the server would have to update its database, generate new tiles, incorporate this information when updating from new OSM data etc. Instead this would only store a tuple (layer_url, feature_id) in the web browsers local store and suppress displaying features in this database.
The text was updated successfully, but these errors were encountered: