StreetComplete queries Overpass on the fly so yes, if you add opening hours every subsequent query from StreetComplete will see it.

That’s not correct anymore for some time now. StreetComplete uses the OSM API to fetch all data in a bounding box, then performs some post processing on the mobile device. So data will be even more up to date, as the OSM API doesn’t have any delay at all.

You should check out Protomaps, it’s really easy to use, very fast, and doesn’t require any email registration like the Export Tool. You can even upload your own shape file.

Supported formats include raw data osm.pbf format (https://protomaps.com/downloads/osm ) as well as vector tile formats (see https://protomaps.com/downloads )

Re.: “Deleting a diary post”: you need to get in touch with a moderator (or administrator). Both roles can hide diary posts, as well as hide any comments.

You can also find plenty of example queries:

• on the OSM Wiki: osm.wiki/Overpass_API/Overpass_API_by_Example
• on the dev blog: https://dev.overpass-api.de/blog/

I’d recommend adding four leading space characters in each line to fix the formatting of your queries. Also, putting your queries on the OSM Wiki might be a good idea.

Without 4 leading spaces

( way[“highway”~”unclassified|residential|tertiary|secondary”]“postal_code”!~”.*”; );

With 4 leading spaces

(
  way["highway"~"unclassified|residential|tertiary|secondary"]["postal_code"!~".*"](area.searchArea);
);

In case this temp layer thing should be part of the osm.org stack, this has been suggested by a several people in the past. Frequently mentioned use cases are facilitating imports, QA, approval workflows, conflation. All the usual suspects.

None of this is really feasible, as the entire stack (including all data consumers) is not prepared for such things. And it would certainly be a huge effort to add it.

The comments seem to be correct, I don’t see any changes affecting the area of Taiwan: achavi (experimental fork), changeset map (experimental fork).

The most notable effect is the drop off in new contributors in the 2nd half of 2021 […]

I’m not exactly sure if maps.me ever supported Basic Auth. In any case their “automated sign up process” was likely impacted by a security fix in https://github.com/openstreetmap/openstreetmap-website/issues/3241 some time around July 2021.

By the way, Organic maps fixed the issue pretty much on the same day.

I tried the previous example on Python 3.5.3 on Win10, and i’m unable to reproduce your error message. It works just fine here, even without “backslashreplace”. Ubuntu 20.04 is pretty much the same.

>>> "𫙮魚坑溪".encode(encoding="utf-8").decode(encoding="UTF-8")
'𫙮魚坑溪'
>>> "𫙮魚坑溪".encode(encoding="utf-8", errors="backslashreplace").decode(encoding="UTF-8")
'𫙮魚坑溪'
>

TBH, I’m running a bit of of ideas here.

I also tried this Overpass query on my patched instance with ICU Regexp support, looking for any signs of surrogate characters: https://overpass-turbo.eu/s/1eNy (this won’t run on any other public instance)

I couldn’t find anything, though.

By the way, U+D800 and U+DFFF would be rejected as invalid already: https://coliru.stacked-crooked.com/a/1cf38225f38a1acf

So, the fact that OSM contains these surrogates, is at least discouraged from the point of view of UTF-8 conformance (“…have to be rejected.”).

Do you have an example for this? Our previous example https://decodeunicode.org/en/u+2B66E is not part of the U+D800—U+DFFF range.

Thanks. I guess this must be the one with two question marks in front (??魚坑溪), which is is probably 𫙮魚坑溪 in osm.org/api/0.6/way/196994995 (version 11)

For the avoidance of doubt, everything in OSM is UTF-8 encoded, even this example. I don’t know exactly what your Python code was doing before. Without actual code we’ll never find out.

@mboeringa: apologies, we can’t really help you with your custom Python code. In case you want others to take a look at this, please include the exact OSM object id and version number and ideally also a minimum code snippet to reproduce your issue.

@lyx: maybe you should take a look at the maproulette instructions:

Add road names in Klang Valley, from the locations provided. Each location contains a KartaView link, in one of the tags, that could represent a road name. Please verify the image, as well as other images in the location’s area and provide one of the tags: name, alt_name or other tags mentioned in the wiki page…

(emphasis mine)

Example KartaView link would be: https://kartaview.org/details/3859749/611/track-info

Right, the API would only validate proper UTF-8 character encoding, but can’t validate if the data uses valid Unicode character codes. The issue I see is that the Unicode consortium keeps adding more and more characters over time (mostly Emojis), which is a massive pain for an API to keep up to date with.

However, I still think, we’re not giving any guarantees beyond UTF-8 character encoding, such as input data adheres to Unicode 14.0 Character Code (or whatever happens to be the current version).

I pasted the code here so you can give it a try for yourself, and check out different byte strings: https://coliru.stacked-crooked.com/a/9c90312fc8222ea8

In a quick test, it seems to adhere to the table shown on https://lemire.me/blog/2018/05/09/how-quickly-can-you-check-that-a-string-is-valid-unicode-utf-8/

In case you think we need something else, please provide concrete examples, pointers to relevant documentation, ideally even reference implementations.

I believe we have similar issues in other languages, like this one here osm.org/node/880591396 highlighting the incorrect é instead of é in the name tag.

It could be a result of copying data from Windows-1252 to UTF-8, as described in https://stackoverflow.com/questions/2014069/windows-1252-to-utf-8-encoding

That’s still all perfectly well UTF-8 on the technical level, but the information itself is crap.

Query: https://overpass-turbo.eu/s/1cqm

This one may be useful to start out with a small list of candidates, rather than processing an extract. Use “Export -> raw data directly from Overpass API”, and rename interpreter to data.osm.pbf (or similar): https://overpass-turbo.eu/s/1cq1

Your examples include nodes which have been edited by both Rails port and CGImap ( osm.org/node/3890664806/history ). If those strings are fulfilling the technical requirement of being a valid UTF-8 sequence, then that’s probably all the API guarantees at this time. I don’t think any syntax or semantic level validation checks for any language have ever been in scope for the API, hence your issue would be out of scope for the API.

If you like to further discuss this topic, my recommendation would be to start an issue on the Rails port and see how it goes. CGImap can be adjusted only after the Rails port adapted any respective changes first. (that’s a general rule, and applies irrespective of the topic at hand).